J
It has been asked:
> OK, bravely admitting my ignorance for the common good, what's a
> Petri-net?
A Petri net is a particular kind of graph. (I'll borrow parts of Mario's draft explanation...)
There are two kinds of nodes: places and transitions. Arcs are directed, and always go from one kind of node to the other, never to the same.
In addition, there are "tokens", which are a bit like pieces in simple board games. Their number is not constant. Each place may contain any
number of tokens, or none.
Whenever possible, a transition "fires". The conditions for firing are that in each of the places leading to the transition there is at least one token. When a transition fires, it removes one token from each place leading to itself and puts one token into each place it leads to.
(A) (B) places
| |
v v
----------- t1 transition
|
v
(C) place
Here, whenever both places A and B have any tokens, transition t1 fires, which removes one token from each of A and B and puts one in C.
Obviously, this Petri net would fizz out pretty quickly; interesting Petri nets have closed loops, so that transitions keep firing - but not all at once. It is possible to arrange sequences, mutual exclusion, etc.
***
What has this got to do with LPLC modules?
One way to do synchronisation is to associate modules with the transitions of a Petri net. For example, we could associate module PID1 with t1. This module would be executed every time the transition is fired. Firing removes tokens from A and B, runs one cycle of PID1 and then puts a token in C.
This has a fairly neat implementation, in that places translate directly to semaphores and transitions correspond to modules. The module PID1 executes a wait on semaphores A and B (linux provides multiple-wait), runs one cycle and then signals on semaphore C.
It departs from the Petri net in that firing time is non-zero but can instead be significant, and obviously the module PID1 won't fire again until it's ready - but other modules may. In effect, there's an implicit "one at a time" loop on each module.
It would also be possible to synchronise asynchronously (remove tokens from A and B, put token in C, and simultaneously execute PID1). I think that'd be more confusing, though, as the first thing most people would do is to arrange for the above. Maybe it should, though, be an option. (Ie, it should be possible for the start of the cycle to also put tokens.)
Arcs in a Petri net can be weighted, so that a transition will remove or put several tokens. No problem with the semaphores, so let's support it.
Tokens can be coloured. I can't see an easy implementation of this, so I'd leave it out.
Places need to have an initial number of tokens specified.
Transitions must be associated with modules. This may prove to be a weakness of this scheme; however, if only a few additional transitions are
required a no-op module could be run for each, rather expensively.
***
Mario and I were discussing this and its details a few weeks ago, but I'm afraid I've been a bit tardy with my e-mail so the discussion got stuck a
bit by my fault. I hope it's OK the way I've put it - there were some open questions we were still discussing...
A fair bit of the above text is from a draft of Mario's presenting all this and several options, but I've rearranged it a fair bit and left out most of the options. Probably introduced a bunch of mistakes, too.
Mario, I hope you don't mind me doing it this way - I hope I haven't left out any of your good suggestions - let me know if I have.
Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World!
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
> OK, bravely admitting my ignorance for the common good, what's a
> Petri-net?
A Petri net is a particular kind of graph. (I'll borrow parts of Mario's draft explanation...)
There are two kinds of nodes: places and transitions. Arcs are directed, and always go from one kind of node to the other, never to the same.
In addition, there are "tokens", which are a bit like pieces in simple board games. Their number is not constant. Each place may contain any
number of tokens, or none.
Whenever possible, a transition "fires". The conditions for firing are that in each of the places leading to the transition there is at least one token. When a transition fires, it removes one token from each place leading to itself and puts one token into each place it leads to.
(A) (B) places
| |
v v
----------- t1 transition
|
v
(C) place
Here, whenever both places A and B have any tokens, transition t1 fires, which removes one token from each of A and B and puts one in C.
Obviously, this Petri net would fizz out pretty quickly; interesting Petri nets have closed loops, so that transitions keep firing - but not all at once. It is possible to arrange sequences, mutual exclusion, etc.
***
What has this got to do with LPLC modules?
One way to do synchronisation is to associate modules with the transitions of a Petri net. For example, we could associate module PID1 with t1. This module would be executed every time the transition is fired. Firing removes tokens from A and B, runs one cycle of PID1 and then puts a token in C.
This has a fairly neat implementation, in that places translate directly to semaphores and transitions correspond to modules. The module PID1 executes a wait on semaphores A and B (linux provides multiple-wait), runs one cycle and then signals on semaphore C.
It departs from the Petri net in that firing time is non-zero but can instead be significant, and obviously the module PID1 won't fire again until it's ready - but other modules may. In effect, there's an implicit "one at a time" loop on each module.
It would also be possible to synchronise asynchronously (remove tokens from A and B, put token in C, and simultaneously execute PID1). I think that'd be more confusing, though, as the first thing most people would do is to arrange for the above. Maybe it should, though, be an option. (Ie, it should be possible for the start of the cycle to also put tokens.)
Arcs in a Petri net can be weighted, so that a transition will remove or put several tokens. No problem with the semaphores, so let's support it.
Tokens can be coloured. I can't see an easy implementation of this, so I'd leave it out.
Places need to have an initial number of tokens specified.
Transitions must be associated with modules. This may prove to be a weakness of this scheme; however, if only a few additional transitions are
required a no-op module could be run for each, rather expensively.
***
Mario and I were discussing this and its details a few weeks ago, but I'm afraid I've been a bit tardy with my e-mail so the discussion got stuck a
bit by my fault. I hope it's OK the way I've put it - there were some open questions we were still discussing...
A fair bit of the above text is from a draft of Mario's presenting all this and several options, but I've rearranged it a fair bit and left out most of the options. Probably introduced a bunch of mistakes, too.
Mario, I hope you don't mind me doing it this way - I hope I haven't left out any of your good suggestions - let me know if I have.
Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World!
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc