Order of ladder execution

mylespetro said:
My understanding is that it depends on the processor. For example, I believe older Allen-Bradley processors (PLC5, SLC etc) executed synchronously (top to bottom), whereas the newer Logix (Control/CompactLogix) execute asynchronously. Can't speak to other manufacturer's PLCs.
Click to expand...

Asynchronous just means the I/O updating and other comms tasks aren't tied to the program execution task. At the program execution level, the code is still processed left-to-right, top-to-bottom. In a synchronous processor, the input data table is always updated before the program scan and the output data table is always updated after the program scan. In an asynchronous processor, it's updated at the RPI you set in the module setup. So in an asynchronous processor, the data table might be updated in the middle of a program scan, so an input boolean that's false on one rung will be true on another in the same scan. To get around this, you can map the hardware input data table to internal tags and use a program instruction to copy the data over, guaranteeing any given input will have the same state at every point in the program scan.
 
No matter the how the "asynchronicity" is handled, the logic must be deterministic else your 'PLC' or whatever you want to call it is an unpredictable entity when programmed with ladder logic or whatever language one chooses. No way and no how should any bit of memory be subject to time-slice preemptive changes. Sure, time-slice in and out of processes can occur but the memory should be in a predictable state no matter what. That is the 'charter' of a PLC. A 'PC' is different and control software running on a PC has to be very guarded to assure the same determinism.
 
chud said:
Be carefull now.
For normal modicons yes (m340,premium,micros, quantums,m580)
M241 is codesys plc. Not sure how codesys scans but not necessarily the same as above mentioned
Click to expand...


Thanks chud, I'm still learning my way through and ran into some funky stuff that I haven't figure out yet and thought maybe it was execution order. I should figure it out with a bit of time and head scratching.
 
kalabdel said:
Compared to a CPU that I am current testing and still figuring out how it works, it seems that is far superior.
Click to expand...


I don't know what CPU you are referring to, but Siemens behaviour is inferior to any sane approach.


For example, say I designed a program that has a three-state output: I want it in state A for 1000ms, then state B for 1000ms, then state C for 1000ms (ignore deviations of timers' behaviour from nominal .PVs). Instead of three cascading .PV=1000ms timers, I can use a single .PV=3000ms timer, and set it to state A when .EV<1000ms; to state B when 1000ms<.EV<2000ms; to state C when 1999ms<.EV.


With the insane Siemens timers' operation, I could naively do my .EV comparisons and have two states defined in the same scan. That may not make a difference, but it could just as easily generate some infrequent and hard to debug behaviour. The fix is obvious, of course: buffer the .EV value once per scan and use the buffered value throughout, equivalent to the common practice of buffering input values at the start of the ladder scan, when changing inputs during a scan is undesirable. But the fact that the fix is necessary in the first place puts the final nail in the coffin in my mind; KISS is better.



A fundamental original design specification of PLCs was that the PLC scan period was faster than "contacts and coils" (e.g. 100ms for a relay ca. 1980), so the scan period does not become a significant part of the system response.


It is understandable that inputs may be asynchronous; treating a timer as an asynchronous input is a poor design choice that will far more often leave the user scratching their head than it will provide any benefit whatsoever.
 
drbitboy said:
A fundamental original design specification of PLCs was that the PLC scan period was faster than "contacts and coils" (e.g. 100ms for a relay ca. 1980), so the scan period does not become a significant part of the system response.
Click to expand...

Nice homage to the inventors and early adopters (Clark, Morley, et al.), whether intentional or not.
Current practitioners would be well informed to do a little research on "the old days", in order to fully appreciate just how hard this work used to be, and the kind of problems that needed to be solved just to get us to this point.
 
jdbrandt said:
Nice homage to the inventors and early adopters (Clark, Morley, et al.), whether intentional or not.
Click to expand...


Definitely intentional.



Btw, I have no history in this field, but my brother does, which is where I learned about that 100ms metric.


That said, any digital technology, where I do have some history, must address this same problem i.e. we model as piecewise linear and discrete a world that is decidedly non-linear and (near-)analog; the problem then becomes the size of the pieces i.e. discretization samples.


This analog (as an approximation for quantum effects) world can usually be adequately, but never perfectly, modeled if the steps are small enough, but cost goes inversely with step size.
 
drbitboy said:
I don't know what CPU you are referring to, but Siemens behaviour is inferior to any sane approach.


For example, say I designed a program that has a three-state output: I want it in state A for 1000ms, then state B for 1000ms, then state C for 1000ms (ignore deviations of timers' behaviour from nominal .PVs). Instead of three cascading .PV=1000ms timers, I can use a single .PV=3000ms timer, and set it to state A when .EV<1000ms; to state B when 1000ms<.EV<2000ms; to state C when 1999ms<.EV.


With the insane Siemens timers' operation, I could naively do my .EV comparisons and have two states defined in the same scan. That may not make a difference, but it could just as easily generate some infrequent and hard to debug behaviour. The fix is obvious, of course: buffer the .EV value once per scan and use the buffered value throughout, equivalent to the common practice of buffering input values at the start of the ladder scan, when changing inputs during a scan is undesirable. But the fact that the fix is necessary in the first place puts the final nail in the coffin in my mind; KISS is better.



A fundamental original design specification of PLCs was that the PLC scan period was faster than "contacts and coils" (e.g. 100ms for a relay ca. 1980), so the scan period does not become a significant part of the system response.


It is understandable that inputs may be asynchronous; treating a timer as an asynchronous input is a poor design choice that will far more often leave the user scratching their head than it will provide any benefit whatsoever.
Click to expand...


Thanks drbitboy, I appreciated you insights.


Just a correction with regard to the Modicon M241 I am testing, it does execute the timer instruction inline (when it is scanned) like almost any other software not at the end of the function block as I feared.


You're not the first one to have strong views on Siemens' timers and this is not the first time I counter that I like exactly how it works. As far as I'm concerned the timer is based on asynchronous counter anyways and if there's is a way to gain access to it or close to it then that's just fantastic. The Timer.ET and Timer.Q are basically system functions that provide that kind of access. Timer.Q does throw people off in the beginning and then we learn the potential for race condition and how to avoid it, Timer.ET has never come up as a concern at least not that I recall and yours is the first one.

I use it all the time and at the matter of fact because I couldn't find a similar method in CodeSysm, when I need to I call the timer instruction with the same parameters just before I access the .ET to get the most accurate value; with CodeSys there are "Method" and "Property" that can be used for such task, maybe even "Action". I'm still in the learning phase and who knows there may actually be a Siemens like way to access those values.


Thanks again.
 

Similar Topics

D
Ladder Execution Order
Does anybody have a good document that explains the Execution Order of "Nested Branches"? Thanks
2
Replies
16
Views
4,591
ASF
A
I
Ladder logic for values sorting in ascending order
Can anyone help Using Gx works 2 or Codesys Software Want to arrange values in ascending order from ex 1...10 to d1...d10 register after...
Replies
8
Views
3,837
Manglemender
M
B
Studio5000_Controlling the order of tags within a UDT
Afternoon all, I'm working on setting up a large excel recipe table for porting updates through the Linx Gateway RTD/DDE function into my recipe...
Replies
2
Views
110
basssteakman
B
Cotafam
Do I need to add our Gateway to the device list on the Allen Bradly CompactLogix 1769 in in order to communicate
We are trying to poll data coming from a PLC for remote monitoring we have the IP address of the PLC and the default port number and the path is...
2
Replies
25
Views
561
Cotafam
Cotafam
dalporto
Weird Structured Text execution order
Good morning. I'm doing a rehab and I need to recycle some part of the old code that won't change and that I need. This is a calculation that...
2
Replies
22
Views
1,351
I_Automation
I_Automation
Back
Top Bottom