CLX Input value changing mid rung?

I'm running a CLX setup with the high speed analog I/O cards. I have a rung where I am doing a calculation, and check the divisor variable to make sure it is above zero.

I was getting some weird results every once in a while for a couple scans and determined that the CPT statement was executing when the dividing variable was below zero, despite my GRT 0 statement at the beginning of the rung.

I knew that the CLX I/O updates independently of the program scan, but I never thought that the I/O values could change between instructions on the same rung. Is buffering the I/O the only way to get rid of this problem?

yes, the input values can change at ANY point in the scan - even part way through the execution of a rung ...

if this is an issue with your application, a buffer is probably the best way of taking care of it ...

see page 67 of the following link for a handy chart of what/when/why issues related to the input and output data ...

http://literature.rockwellautomation.com/idc/groups/literature/documents/um/1756-um001_-en-p.pdf

I guess I never would've thought they would change a value mid-rung, it seems potentially dangerous and I can't think of any reasons why you would want it to function that way.

If you had a rung of [X GRT 0]-------[Z DIV X] you could get into divide by zero issues or other problems because X could go from non-zero to 0 after it passes the GRT instruction.

I think of it a little differently:

Not understanding how the processor actually works is potentially dangerous.

Complaining that the processor doesn't work the way you think it should is mostly futile. Not always, sometimes they listen but don't hold your breath.

That said, we've all been there and can identify with your struggle.

from mellis:

Not understanding how the processor actually works is potentially dangerous.

Click to expand...

words of wisdom ...

Paul351W said:

I guess I never would've thought they would change a value mid-rung, it seems potentially dangerous and I can't think of any reasons why you would want it to function that way.

Click to expand...

It makes writing firmware for the PLC easier and for the PLC user more difficult.
I prefer making everything synchronous.

If you had a rung of [X GRT 0]-------[Z DIV X] you could get into divide by zero issues or other problems because X could go from non-zero to 0 after it passes the GRT instruction.

Click to expand...

Yes, IF x is an input. If X is a variable you can copy the input into X first and then execute your rung. Now you are sure you have the latest version of the input but X will not change during the execution of the rung.

The moral is that I/O can change at any time but variable change when you assign values to them.

While I agree that the features of the Control Logix are very powerful. I would like to see a Parameter you could set on them that would switch between Synchronous and Asynchronous I/O Update.
For most of my applications, having the I/O Update during the regular housekeeping time would work fine, and avoid any gotchas.
If you need to have the latest data, then you can set the Parameter for that. Perhaps even allow even more flexibility by separating out Digital I/O, Analog I/O, and other types of I/O etc. Something to think about.

Stu......

The main pain I guess is that I have been working with PLC5's and 1400e's for the last 5-6 years and am getting into a few CLX projects, so the way we had been doing things doesn't work so well anymore, or we have to do work that the processor used to do behind the scenes.

Coupled with the quirkiness of the 5000 and RSView software, its a bit frustrating to say the least.

Asynchronicity can be a problem on PLC5s, SLCs, Micrologixes, and also on every other brand/model of PLC on the market as well. HMI data writes, messages from other devices, block transfers, etc are all asynchronous. If you've been working with RSView you've had to deal with asynchronicity whether you realize it or not.

Just don't work on I/O directly.
Sure you are doing a little extra and must think more but there is an advantage too. A traditional PLC scans all the I/O at the beginning of the scan and by the time the program that uses the I/O gets to the rungs that process it I could have changed but with the asynchronous I/O updates you can read the I/O before the rung where you use it and get the latest update.

The only other way to do this would be to turn off interrupts when executing a rung so the I/O doesn't update in the middle of a rung. This would make programming easier but it would also cause sample jitter for those I/O that require being read at regular time intervals.

Peter Nachtwey said:

Just don't work on I/O directly.

Click to expand...

As a person who works on other peoples' projects a lot, I think this should be a golden rule. I alias everything. I also did this in the PLC5 world as well as the CLX stuff. Different method, but it works either way. When you alias, there are no hidden surprises, and it makes tracking down where the actual input is used much easier.

Having direct inputs used all over the PLC makes me want to scream. The simple "boss says add a timer to your input" scheme becomes a really big chore that could have been saved by a simple rung on startup.

/endrant

Greetings Tom ...

I think I'm missing something – or more likely I'm just misinterpreting what you've posted ...

making an alias for an input doesn't keep the input bit/box (aliased or otherwise) from updating midway through the ladder execution ...

specifically, the alias isn't a "new bit/box" which is updated at the beginning of the ladder execution ... instead, the alias is just another name for the same original bit/box ...

as a specific example, if the bit/box Local:1:I.Data.0 contains a status of ZERO – then there is no way for its alias My_Tag to contain a status of ONE ...

PS edit: I just re—re-re-read your post ... I think what you're calling "ALIASING" is what I call "mapping" or "buffering" ... in other words, a rung for XIC Local:1:I.Data.0 to control OTE My_Tag at the top of the ladder routine ... specifically, My_Tag would be a completely new bit/box with its own individual ONE or ZERO status ...

yes, in that case, there will be no "part-way-through-the-logic" surprise changes to My_Tag ...

if that's what you meant, then I was (apparently) confused by your use of the word "alias" instead of "buffer" or "map" ...

party on ...

I don't have a problem with the I/O updating throughout scanning the program as long as it is between rungs, not in the middle of one. I never observed an instance on a PLC5 that the input value changed in the middle of a rung.

I have a big problem with values changing in the middle of scanning a rung though, which is what CLX seems capable of doing. If the input values were updated only between rungs you would still have faster update rates without all the potential problems.

It seems to me like they cut a lot of corners at the programmer's expense when they switched to the new hardware platform. Instead of taking the functionality of the PLC5 software and improving on it, its like they started over from scratch

Ron Beaufort said:

if that's what you meant, then I was (apparently) confused by your use of the word "alias" instead of "buffer" or "map" ...

Click to expand...

That's what I meant. There's a big difference between aliasing and buffering. I DO alias, because using the actual input isn't always what you need, and I DO buffer, changing the input to another location before going off willy nilly down the PLC programming road.

...sometimes I type well, other times I, well, TYPE...

I have a big problem with values changing in the middle of scanning a rung though, which is what CLX seems capable of doing.

Click to expand...

yes, that's exactly what it's capable of doing ...

the picture below illustrates one of the lab experiments that I occasionally run through to convince disbelievers ...

basically we set up another/separate PLC to toggle a relay ON and OFF about once per second – and let it clunk-clunk-clunk away all night ... when we come back in the next morning the ADD will show about 30 to 50 occurrences where the bit/box status of the real-world field device (the relay's contacts) made a change from ONE to ZERO right between the execution of the XIC and the execution of the XIO ...

note that the number you'll get will be random – but making the relay cycle faster will "load the dice" and increase the odds that you'll see some "midway-between-the-rung" changes ...