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

J

Thread Starter

Jiri Baum

Michael:
> 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
END

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
--
Jiri Baum <[email protected]>
http://www.csse.monash.edu.au/~jiribvisit the MAT LinuxPLC project at http://mat.sf.net

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top