Programming methods

Hi All,
A friend of mine called with a general question on ladder programming, this one happens to be AB, but could apply anywhere. I have seen over the years some programmers assign I/O to bits at the beginning of the program to aux relays (B3:xx) and use these in the rest of the program. I remember someone telling me it was done for transportability, but I don't get it. I personally don't do it that way, was wondering what the consensus is or the reasoning behind it?



Thanks for replies,
tommy23t

It makes changing an I/O point later in life easier if the actual I/O address is only used in one point. That's the only real advantage I've found for it.

I personally don't do it often. The only time I do it is if the machine in modular, and the input could be different things depending on what module is plugged in. Then I just assign all Inputs and Outputs to different bits depending on what module is plugged in.

Let's say an input is used 20 places in a program. Now, for whatever reason, that input function must be moved to a different terminal. You could do a search/replace, hoping to get all 20 references, or you could use the bit mapping as noted. Then only one bit mapping rung must be changed.

You talked about general ladder logic programming but when you get to higher level systems like ControlLogix the I/O is updated asynchronously to the scan and, conceivably, cause problem if the input status changed part way through a scan. By using the bit mapping the mapped state will remain the same through one scan.

B3 was used mainly on PLC5 and SLC500 just because they are the first binary option, but you can use a different one like B10,B11 etc. Even on controllogix tou can create bool tags like B3[YYY] where YYY are the numbers of bits in the array, but definitively if you do not want to use them, there is no problem.

I use Omron and allocate all my I/O - inputs, outputs, timers, counters, bits, words, network words (Ethernet IP) etc in Excel before I even start programming. By the way, in and out of Excel is just copy and paste.
That way I know where everything is - alarms in contigious channels, alarm acknowledges in contigious channels etc.
The greatest benefit here is I do not have to program using b****y symbols - hate them - just program using numbers. For digital bits just type in 20014 and the software automatically allocates it as 200.14 - channel 200, bit 14. I do not even have to type in the decimal point - all automatic.
The other great benefit is when offline if I want to move something I just change the address number in the symbol table and CX-Programmer automatically chnages the I/O address for me - I do not even have to do search and replace - it just happens.
Really speedy, automatic and I do not waste time and money fiddling about.
The quicker I do the job the more money stays in my pocket.

Why is the remapping a problem?

Can't you simply use symbolic names and recompile?

Peter Nachtwey said:

Can't you simply use symbolic names and recompile?

Click to expand...

Not on the SLC500, or PLC5. You can on the Logix platform, but that still requires a download (and shutdown of the process) to accomplish.

One other reason to buffer inputs that I didn't see mentioned, is that when someone changes the bloody NO limit switch to a NC limit switch, you only have to change one contact in the program to make everything work right again.

What bernie said

Helps maint tech with one ladder to go to to check input status and to forcea output if needed without them looking all over the program.


Also helps when designing a program and you don't yet have the IO layout.You can write your program using B or N references and then map the physical IO to it later sometimes even on site. Fun.

Also,

- Helps with being able to reuse the program on similiar projects.

- Helps with simulation logic, ie. turns on one bit and have simulation logic taking over controlling the IO.

Thanks for the input (no pun intended)
Makes sense on some points.
Thanks,
tommy23t

I've done it for years... for all the reasons given. I particularly like being able to write my logic using an IO arrangement that makes sense for the machine. That is, suppose you have something like a dial machine with, say, 200 IO points spread over 12 stations on the dial. You can then use your own bit ranges for each station. Why does this matter? Well, YMMV, but by buffering you can:
- Match output bits to input bits for things like cylinders
- Match HMI PB bits or HMI Radio bits to the output and input bits
- Match fault timers and fault bits to...

You get the idea. By setting up your own map, you can really simplefy programming. Once you've done one set of rungs for a cylinder, you copy them, then change the bit numbers. Next cylinder done. You can even get some traction from STN 1 to STN 2 or STN 3 etc, since many may have the same types of devices - nests, pick/places, part feeds or escapements, etc. With some judicious choices, you can quickly replicate your basic logic for each station. And, as has been said you don't care then whether or not the IO point is NO or NC, or whether I:0/0 or I:0/1 is wired to "RET." Or, if a linkage is used, it may be that "EXT" and "RET" are something you want to reverse (logically) for this cylinder anyway if the switches are still on the cylinder not the final element.

There are a lot of things you can "standardize" on for yourself if you buffer IO. Do you have to? Naw. But for me, it makes it so much easier to set up and debug a program that I just do it automatically for every job. For OEMs, this is really valuable when you have a family of machines that are similar. But even for the rest of us, doing a one-off process cell or custom machine, it can really help in setting up the logic and especially later in debugging, because you've got a lot of identical rungs.

I've never done it, and don't like it at all.

But with the ControlLogix platform, there's a reason to use this technique. The I/O update in ControlLogix can happen any time during a program scan. In other words, an input bit may change state in the middle of a program scan. In some cases this could cause some strange results.

If it is necessary to map the I/O, I like to see the physical I/O address in the descriptor for the remapped bit, and vice-versa.

I buffer all of my physical inputs and outputs without exception for all of the reasons stated above. If I have anything written for me I make it mandatory. I also do it with any fieldbus IO or signals between devices and usually use some sort of heartbeat signal to check that the data being read isn't getting old.

I can understand people not wanting to spend the time to do it, but I can't image the reasons for anyone NOT liking it being done in principal. I don't see the negatives.

As I have evolved in my PLC career, I have begun to map IO and will never not map IO.

1 - As mentioned with a ControlLogix you have asynchronous updates to IO and your program...
2 - If you are "testing" your program and you don't have all the IO required for the program, simply deleting your IO mapping will resolve any compile errors you have due to defined IO being missing...
3 - Standard logic...simply map the IO to standard logic and boom you are done. No need to re-write the same functions you use over and over again.
4 - "Cut and Paste", especially useful in the Logix platform where you can alias to program tags..
5 - Maintenance and Troubleshooting, I know exactly where to go for raw field IO feedback and control.