LOGO! unexpected behavior

[drbitboy]

[Update: fixed a typo in the image.]

See the image below, especially the blue-ish annotations.

The three rungs ending in output coils -( ) are part of the business logic of the program I was writing.

The diagnostic counters (C003 and C005) were inserted to investigate the behavior I thought I was seeing in the simulator control widgets at the bottom. The counters' middle input pins being used are the counter pins; the pin above that is the Reset pin; the pin below that is the Direction pin (for counting up or down; if not connected it counts down).

From this test, I would guess that, for Siemens LOGO!, the order of evaluation of the rungs is indeterminate, which would I think be quite a problem for a programmer writing ladder code.

Am I missing something? Is this a bug in the LOGO! Simulator, or does LOGO! hardware behave the same way? Is it a bug at all?

I apologize in advance for the oversized image.

​

 

[el greco]

if you turn the simoulator with fuction block it does the same?

 

[drbitboy]

if you turn the simoulator with fuction block it does the same?

yes.

 

[Puddle]

I apologize in advance for the oversized image.

Well I had to zoom in to read the text!

From this test, I would guess that, for Siemens LOGO!, the order of evaluation of the rungs is indeterminate, which would I think be quite a problem for a programmer writing ladder code.

There may be some reasoning behind this for performance reasons, which will be known only to Siemens. I wonder if it scans the smallest rungs first, meaning it would run 1-3-5-2-4? If you add more logic to rungs 2 and 4 does change?

 

[drbitboy]

The full program is attached below as PDFs and annotated PNGs. LOGO!Soft does not correct the rotation in the PDFs, but Firefox can do it when displaying them.

The basic program is a homework assignment to turn on three lights according to a sequence of patterns:

• System off (on PLC startup and after pressing Stop button): all lights off
• System on (after pressing Start button), over 5s intervals:
  • 0-5s: 1-- => Light 1 on; Lights 2 and 3 off
  • 5-10s: 12- => Lights 1 and 2 on; Light 3 off
  • 10-15s: 123 => all lights on
  • 15-20s: --- => all lights off
  • after that, repeat last two patterns (all on for 5s; all off for 5s)
    

 

[drbitboy]

I didn't mention that the FBD version of that program was converted from the LAD version; the only changes were rearranging the blocks for clarity and removing spaghetti.

Here is the FBD code, with the counters inserted manually, running in the simulator. Again, I would not expect the value of Q2 to ever be 0 when the value of Q3 is 1, and the same for Q1/Q2 but the counters indicate the opposite is true.

​

 

[joseph_e2]

Slightly OT, but I use PDFTK Builder portable to merge, split, and rotate pdf pages:
https://portableapps.com/apps/office/pdftk_builder_portable

 

[drbitboy]

And finally, here is one more LAD version that was converted from the FBD version, which FBD version was converted from the original LAD version.

It has the same anomalous behavior; the ordering of rungs is mostly in the reverse order from the original LAD program.

It's a puzzle.

​

 

[drbitboy]

Slightly OT, but I use PDFTK Builder portable to merge, split, and rotate pdf pages:
https://portableapps.com/apps/office/pdftk_builder_portable

@joseph_e2: thank you! What a great app, the installer doesn't even add a shortcut to the start menu, let alone on the desktop. Finally, someone that respects the user.

Anyway, here are rotated versions of the PDFs.

 

[L D[AR2P#0.0]]

Not related to the problem but how are the counters showing positive numbers when the direction pins are not connected?

 

[joseph_e2]

Take a mosey through the rest of the Portable Apps site. They have portable versions (no installation required) for a LOT of things, including Gimp and Libre Office. Their version of Zenmap/Nmap isn't 100% portable since it requires WinPCAP to be installed, but there are a bunch of useful programs there.

 

[drbitboy]

Not related to the problem but how are the counters showing positive numbers when the direction pins are not connected?

I don't know if it's documented as such, but if the Dir(ection) pin is not connected to anything it essentially has a virtual "pulldown resistor," so it "reads" a 0 for the Dir input and counts up only.

 

[drbitboy]

I added Break-contacts of the SF002* to the rungs feeding the light output coils, because I thought perhaps the shift register block was not being evaluated until after the outputs were assigned, but it made no difference.

* the shift register block; I changed its output to be bit S1.8, which is always 0 for this application, so the Break-contact will always evaluate to True.

 

[I_Automation]

There is an order, but it's not left to right, top to bottom.
Basically it doesn't use the graphical representation the programming software shows you.
If I am remembering correct from a class too many years ago it goes by the order the objects were created, or wired maybe it was.

 

[drbitboy]

There is an order, but it's not left to right, top to bottom.
Basically it doesn't use the graphical representation the programming software shows you.
If I am remembering correct from a class too many years ago it goes by the order the objects were created, or wired maybe it was.

Yes, I found a post on the Siemens forum that described the behavior something like that: the blocks are processes in the order of function number (SF002, T001, etc.), but if a higher number's result feeds (in the equivalent FBD diagram) a lower number's result, then the feeder is evaluated before the feedee.

But in this case I put SF002 feeding the output coils, and it still did not work.

Also, that behavior of still does not explain why Q2 can be 0 when Q3 is 1, unless the rung feeding Q2 coil is being evaluated before the rung feeding the Q3 coil, which would be inconsistent with that description of the behavior.