Michael Lloyd

That's how I would think it would work. I don't know if this will help but you can "add" strings together in Excel with the & symbol. I've attached a worksheet that I used to create structured text based IO mapping. It might give you an idea that will help. I have category's for pumps and valves in Sheet 1. That's where the IO is defined. The strings are created in the rightmost column in the individual tabs to the right of the first tab IOM Builder Rev 2.xls

Make yourself a little "do nothing" application with a few tags in it and test the import / export on that. If it works and If I remember right: There's the tag in one column and then there's a ton of other stuff in other columns You could copy the tags that need to be replaced into a standalone NEW worksheet, then copy the tags from the Logix program to another column, then have a number column to establish the sort order. Like so: Oldtag 1  NewTag8     8 OldTag 2  NewTag27  27 Once you have the order done you could sort the New Tag and Number column on the number column Compare the result. Then copy all the new tags over the old tags (in the exported sheet of course) This assumes that you can get a block of the old tags so the copy paste is easy. 

It's been a long time since I used RsView (<--- obviously. It's been FTView for a long time) but I think you can export / modify / import tags with FTView.   

I always make my math routines work in Excel first BUT, sometimes you have to force the order of precedence with parenthesis in the AB boxes. Are you doing the calculation with structured text? Even if you want to do the averaging outside of structured text (MAVE is pretty nice and it works inside structured text and outside), I'd still do the math in a structured text routine. 

Either. For instance, I despise setting up analog cards, especially 16 point analog cards :o) So, I have a "base program" with one of each card that I normally use set up the way I normally configure them. For analog inputs I make them all 4-20mA and scale them 0-100%. Later, when I know the scale of the transmitter, I'll edit the config and change the 0-100 to be whatever the transmitter is. When I have a new program to write I'll drag a card from the baseline into the IO config of the new program, change it's slot as needed, redo the description (I like to document every spec of the program), and it's good to go.   Empty spot meant the first empty spot in the tagname database. The bottom of the stack of tags in other words

How is the L24RER on the network? I am not familiar with that model but looking online it's supposed to have two Ethernet I/P ports. This is jogging my memory. I think I had a similar problem but I found a workaround. I need to dig through some of my programs and see if it's the same issue.

Typically I just open two instances of the RSLogix, open both programs, select the tags in the source, select the first empty spot in the target, and hit Ctrl-V and paste them in. If I have forgotten to update the UDT's I'll get an error for the tags that are created with UDT's (User Defined Datatypes). So... copy and paste the UDT's first.  I also drag and drop routines. There's not much you can't do with Ctrl-C / Ctrl-V. It only takes one tiny little error to hose up a tag import / export. 

You can use Produced / Consumed tags (not my favorite way to move data between PLC's) Or a Message block. Message blocks are simple to do and fast. I can send an example (or attach it here) but you'll need to be able to open a structured text routine to see the complete picture. I vaguely remember doing a step by step writeup for a tech to do this. I'll look for that instead.  Personally, I don't do safety related data moves "softly". I always have those hard wired (motor start / stop, ESD, etc). 

I've programmed both the LOGO and ML1400 more times than I can remember. No... the ML1400 was not programmed with LOGO software. The LOGO is a Siemens product and the software isn't compatible with AB products.  My guess is that when you uploaded you uploaded the ML1400 program to different directory than you think you did

In your first screenshot, bottom middle, it shows Error Code 0102.

Extended Error Code 102: “To:” address not specified. Attribute 1 was not set with a “To:” address AND there is not a “To:” field header in the email body.  Page 76 http://literature.rockwellautomation.com/idc/groups/literature/documents/um/enet-um527_-en-p.pdf

I use Excel to create a structured text file for mapping IO. I'm on my Mac right now or I would post an example. Basically I create a table for types of IO (motors, valves, etc) and when I fill in the blanks it creates the structured text for mapping the IO point to the tag array created from a User Defined Data Type. Consistency in tag creation is the key to using the spreadsheet. It used to take days to map the IO on a large project. Now it's the last thing that I do and it takes less than 10 minutes for a large project. I also use it to create the documentation for an analog User Defined Data Type that I made a long time ago and use frequently. It's got 14 (? I think) points and when there are a couple of hundred analog IO points it's handy.  14 x 200 = 2,800 distinct lines of documentation that I don't have to type but one time and that is done in my IO sheet so it was going to be done anyway. This also used to take hours and it's now copy, paste, set the number of IO points, run... then copy and paste the result into the tag database dump (CSV file) and reimport. A friend of mine used his VB skills to make the spreadsheet work.

It's not working so something is wrong. As Will said, nobody here is laughing at you, part of learning to write a program is failing to write it correctly. Your routine may be perfect but you may have forgotten to call it. The output card may not be enabled. Maybe the "lab document" was written in such a way that it caused you to write logic that doesn't work, on purpose. Maybe this is the teachers way of getting you to step out of the book into the real world. You need to know what the logic is doing not what is in the lab document. I don't know how many times I've spent hours (or minutes when a customer is standing there wanting to know why his equipment isn't running) staring at logic that I KNOW is perfect when it wasn't. I've sent emails with logic attached that basically said - see if you can find something wrong with this but you aren't going to. :) Oftten the reply comes back with Check X and you'll see what the problem is.

If I only had a dollar for every time I did that

Admittedly turbidity is probably not a safety related IO point, however, rather than patch the problem with filters on the IO point, why not figure out why the reading is noisy? Turbidity shouldn't be a fast moving IO point. I'm more inclined to believe there is a noise issue. Slowing down or filtering an IO point is not something we do regularly in the oil and gas industry. We like our IO points to arrive intact and unmolested. If they are noisy we fix the problem. But, most of our IO is subject to Process Safety Management regs.

And... my personal favorite... are you calling the routine?

Why did you post the question twice? If the signal is erratic you may have a wiring issue. Grounding the shield on both ends can turn the shield into an antenna. Loose connections can cause noise.  The sensor could be screwed up. 

+1 best bang for the buck for communicating between AB and just about anything else

The # symbol is how you denote an indexed address. Page 632, Section E-10 in this manual http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1747-rm001_-en-p.pdf The brackets denote indirect addressing. Types of addressing are discussed starting on page 601 of the document referenced above If you can get your head around it (it's not that hard) indexed and indirect addressing can be very useful (or annoying depending on your thoughts on using it)

I can see that. Sometimes making an HMI work with a new project is more work than the PLC project

I've seen it done too but I can't come up with anything positive to say about it...

I'm trying to understand why your tag structure is SLC but your post says ControlLogix? Did someone use SLC structure in a CLX PLC???

Asking this question on numerous other posts is not going to endear you to anyone... Your question was answered. Your data format is a 16 bit integer. The number your trying to read with modbus is going to be in TWO 16 bit integers unless you explicitly ask for floating point or DINT data (which you didn't ). You need to assemble the two registers into one DINT. 

To expand on Zener's post Don't duplicate the AOI. It's not IO, it's a control or calculation methodology. If you have multiple inputs from the program, create a tag in the AOI called XC DINT[10] or however many you need. Then in logic I like structured text but this can be done in ladder too) IFXC.0 OR XC.1 OR XC.2...OR XC.9 THEN OC := 1; ELSE OC := 0; END_IF; Then use XC.0...XC9 in your logic or if you're a function block person drop the AOI into a function block routine and tie the IO in that way.  Alternately you could map the IO in the same structured text file like so: XC.0 := tag in logic 0; XC.1 := tag in logic 1; XC.2 := tag in logic 2; etc... Do yourself a favor and shorten your tags up. EXTEND_CLAMP.0... etc could be XC.0 etc. Less typing in the program and the HMI. Use the description if you need to get wordy. If I could go back 10 or 15 years and redo the programs that I wrote that were full of wordy tags I would.  If you really want to streamline (containerize) your logic learn to use User Defined Datatypes (UDT's)

I've attached the routine that I use.  AA_C.L5X