Programming methods

[The Plc Kid]

I have to say, I have not had any problem with ControlLogix once I understood an I/O input can change at any time and starting writing my code accordingly.

I have seen that statement twice in this thread so could you please explain exactly how that is done?

Buffering is the only sure way I know to prevent IO from changing state mid scan in contrologix but I am always open to learn something new.

Can you give some details please?

 

[Clay B.]

I don't use mapping either.
It adds an additional step to troubleshooting to find which input is holding up the sequence or causing the fault unless the mapped bits are documented well

Not sure the point here. If you had just extraced a program from a machine and opened it without comments then the inputs and outputs would be devoid of discriptions as well. You would basically search for the inputs and if they are mapped then you would see the map bit right away and start looking for the mapped bit instead.

Another reason to map I/O's is for transfer between PLC's, HMI's etc.

 

[OkiePC]

I have seen that statement twice in this thread so could you please explain exactly how that is done?

Buffering is the only sure way I know to prevent IO from changing state mid scan in contrologix but I am always open to learn something new.

Can you give some details please?

Rather than buffering, some people only reference each digital input once per program section which is pretty much like normal ladder logic, but they are buffering with internal logic bits whether they call it that or not. Doing this makes scan order much more critical. I am an I/O mapper myself...unless I am literally down to my last few bytes of memory, I always map I/O. Yes, it is one extra step in troubleshooting to find the real world input if you are back tracking through the code, but that's as simple as right-click, find all, click on the OTE instruction in the list, and bang, there she be.

 

[brucechase]

I don't map the I/O in most of my programs. That does not make me a poor programmer or lazy. But I also deal mostly with SLCs.

Most of the techs I work with say they prefer that it is not mapped. When they are troubleshooting, they would rather see the real world I/O. If they change something, I'm pretty sure that they will just use the real world I/O anyway. This really is more of a personal preference.

Outputs are typically used only once so there really is no benefit. So the big difference is inputs. Now I guess I live in a sheltered world since I rarely see an input go bad (but I have seen them). At that point, it really is easier for us to change out the card than to rewire (the process is usually down anyway which lead us to the bad input) and reprogram.

As for mapping for data transfer (I have lots of RIO panelviews), I use the COP command for the entire word. This is only 1 rung and it serves my purpose without having lots of rungs with one input turning on a bit.

To me, it all comes down to what is needed in the program. If you need to buffer the inputs because it will mess up your program if the I/O updates in the middle of a scan, then you need to handle that in your program. To say that it always needs to be done a certain way usually winds up getting you painted in a corner.

 

[Paullys50]

I don't map the I/O in most of my programs. That does not make me a poor programmer or lazy. But I also deal mostly with SLCs.

Most of the techs I work with say they prefer that it is not mapped. When they are troubleshooting, they would rather see the real world I/O. If they change something, I'm pretty sure that they will just use the real world I/O anyway. This really is more of a personal preference.

I don't think anyone is implying not mapping means you are a poor programmer or lazy. You are right, it is personal preference AND experience. Someone mentioned UDTs and inputs, and it's a thought I didn't mention. But it is valid as you can create an input AOI, which creates more functionality from the field input. Such as inherent denounce times, scaling, alarms...etc. So by mapping to that AOI, you extend the flexibility of that input.

But, that's all experience and process specific and "standardization" that may exist in your work place.

It's a "horse-a-piece", I think most were explaining some advantages of mapping. Which I do believe is more evident on a Logix platform rather than a PLC5, SLC or Micro.

 

[williamlove]

I was asked to explain this statement I made earlier: “I have not had any problem with ControlLogix once I understood an I/O input can change at any time and starting writing my code accordingly.”

The questioner also said: “Buffering is the only sure way I know to prevent IO from changing state mid scan in ControlLogix but I am always open to learn something new.”

I don’t try to prevent the I/O from changing state mid scan, I just write each instruction that references an input knowing that the input may not be in the same state it was earlier in the scan. This is not much different than writing it knowing it may be different than it was last scan. But if you don’t know about this “new” behavior in ControlLogix, you can have problems such as what another poster referred to as a “race problem.”

Rockwell decided to implement this new feature of updating I/O faster. They also do not promote mapping. And that’s understandable since mapping would negate that advantage of updating the I/O faster.

I guess we should ask Rockwell why they did it. I think they would probably say that some users wanted the updated I/O information as fast as possible and not have to wait for the next scan. But I’m guessing.

Anyway, to answer the question posed to me, once I knew about the faster update and coded accordingly, I never had any race problems or any such problems. But I admit that before I knew about it, I did have a vexing troubleshoot one afternoon, which ended when I was made away of the new, faster scan update.

Like another reader, I too, was annoyed by a comment made earlier by someone else that failure to map is lazy or poor programmer. I would respond, somewhat petulantly, that it is lazy and poor programming to fail to understand and take advantage of the new faster scan update, LOL.

 

[GeoffC]

Yes Mapping is required in Controllogix, but when you consider other brands the reasons stated by others are not so compelling.

As for being able to write the code and use mapping to set the addresses later, if you are using a tag based system then it is just as easy to make all your tags and add an address to the tag at any time - without the need for search and replace - particularly easy in Schneider UnityPro

Using mapping makes it less clear which bits in a program are from real io

Using mapping makes it more difficult to use forcing. (force an io point the io variable is highlighted as forced but throughout the program where the mapped input is used there is no indication that it is forced)

Using mapping means every search for where an io point is used requires multiple searches - search for the io address find the mapped variable then search for where that is used

 

[williamlove]

Sorry to disagree, but mapping is neither required nor actively promoted (by Rockwell) for ControlLogix.

I chatted with someone at Rockwell tech support yesterday (I was dealing with a FactoryTalk issue but we digressed into this topic) and he agreed with my view that mapping would negate the “advantage” of faster I/O scanning which is so detested by some of the proponents of mapping but which was added to improve performance. If I think of it, at the next RSTechEd I will around about this.

This seems to be one of those topics that takes on emotional overtones (like memory garbage collection in the C++ vs. Java vs. .net world). But clearly mapping is an optional feature added to a program by some users for the reasons covered above (some of which are interesting and worth consideration).

I do some service work and have seen a lot of programs. Only a "modest" number used I/O mapping. I never understood why anyone would bother with it until this topic came up here. I must note that the mapping had fallen into a state of partial disuse in some of these applications which was why I hated it, aside from just thinking it was an unneeded pain. In fact in one case we just took it out and solved a problem introduced by a maint tech who did not follow it and ended up with, in effect, two OTEs, if I remember correctly.

 

[I is a noob]

Not sure about AB's(or much other for that matter) but in the move from the 90-30 & VersaMax(GE) to the newer PAC, a lot of m coil mapping is going by the way side as my company is going heavily into user defined function blocks written either in C(++?) Or using symbolic variables in ladder logic written blocks. In this way all programing can be uniform and only a few inputs and registers will be needed to make the logic work. The only draw back I have found is that some older HMI's will not look at the symbolics so we are having to buy better(more expensive) HMI's to make up for this.

 

[Nick B]

I'll give the no side a crack.
1. Based on other platforms I don't find it advantageous.
2. Another layer of complexity and place to make mistake(s)
3. Forces do not show up in your program
4. Not possible for safety I/O

I see the possible advantages but personally I don't recommend it.

Nick

 

[PeterW]

I don't understand this argument that Control Logix IO is faster.

The scan time is the scan time!

Most PLC's update IO between scans, AB now updates at any time, but the scan time is still the limiting factor.

Other PLC's update the IO then you process the code, all the code uses the same status for the IO.

Control Logix updates at any time, so you could be making decisions within the same scan based on different conditions.

With Siemens if certain IO is important enough you can update the image within the scan, mostly you'd just use the image as it was updated between scans.

Can't really see the advantage with AB, can see the downside though.

 

[BobB]

I do not think anyone actually understands my meaninug of mapping from comments here. I am just going to bed and then off to a job 4 1/2 hours away in the morning at 3.30 AM. will be away for most of the week. Will explain on my return.

 

[brucechase]

I use mapping on all plc systems I use. It's just good design practice. When I see a program that does not have it that tells me it was written by a poor programmer or a lazy programmer.

.....

I don't think anyone is implying not mapping means you are a poor programmer or lazy. .....

Yes PLC Kid did state that. And that is the problem. We can't have a discussion without someone getting all wound up and making it personal.

 

[williamlove]

I don't understand this argument that Control Logix IO is faster.

If the I/O is updated immediately, you have the opportunity to use that information sooner…you don’t have to wait until the same line of code executes in the next scan.

The immediate update technique (mentioned above with Siemen) is not required, thus there is one less thing to document and maintain. One less thing that someone years later might overlook.

It would be illogical for Rockwell to promote mapping I/O because it would obviate the feature they decided to implement.

I did have a race problem one time until I understood the new behavior and modified my code. I have not had any more problems like it since.

I think Nick B above did a nice job summarizing some other objections to mapping.

I wish the original poster would comment now on whether he intends to map, now that we’ve all given our two cents.

 

[PeterW]

If the I/O is updated immediately, you have the opportunity to use that information sooner…you don’t have to wait until the same line of code executes in the next scan.


The ControlLogix IO is not updated immediately it is asynchronously, which means it updates during the scan, you don't know when.

When you use an input, you are unsure when in the scan it was updated (it is not immediate) when you turn on an output it will be updated at some point in the scan (again not immediate), maybe more than once, who knows Same goes for when you read the status of an output.

Most applications this would have no real effect on what you are controlling.

EDIT: forgot to add, you only do the logic for an output once per scan, so I repeat, the scan is the control of how fast your IO updates.