rungs and other rungs (was: [Fwd: ENGR: Ladder Logic, Automation replacing people])


Thread Starter

Jiri Baum

> It's not like the rungs pass arguments around to each other and examine
> result codes. The action of a rung modifies the values in the state
> table, and if the next rung happens to examine that value in one of its
> conditions it gets it from the state table, not from some "output" of the
> previous rung.

Actually, in a way they do.

The mnemonics ANB (and block) & ORB (or block) combine the current rung
with the previous rung. Several other mnemonics discard the current rung
and resurrect the previous one (POP and the conditional jump/return ones
when they do jump/return). The END instruction (in a subroutine) leaves the
current rung as-is.

Sometimes, this just makes a big compound rung, and that's fair enough. But
it also means you can do stuff like:

SUB get_input
LD X001

And then wherever you called that subroutine you could just keep going on
the rung that the LD X001 started.

> How well this model translates to allowing online edits in things besides
> ladder logic I haven't tried to think through yet. I'm sure there is some
> situation where it won't work worth a hoot.

For some things well, for some things not so well. I'll write a separate
e-mail about that on the other thread.

Jiri Baum <[email protected]> the MAT LinuxPLC project at

LinuxPLC mailing list
[email protected]