Petri nets and synchronisation

J

Thread Starter

Jiri Baum

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
 
M

Mario de Sousa

OK. I would like to take this one step further.

I have been trying to get an example of where asynchronous associations between transitions and modules would be required, but I haven't been able to come up with one yet. Nevertheless, I would like to propose a framework where both could be supported (and yet more extravagant stough, maybe to be done in the future). I am sure someone will come up with an example where asynchronous firing would come in handy once we start to try and use this LPLC in some serious demos.


Here is my sugestion:
We create a new entity for the LPLC, i.e. a synchronisation point (plc_sp_t).
Modules only need to synchronize with synch points using a simple function plc_synch(plc_sp_t sp).
They would use two distinct synch points at the beginning and at the end of their loop. They could get the handles to the synch points with a plc_sp_t
plc_get_sp_by_name(char * name) function. They could get the name of the synch points to use through a name = value pair. We may even write a plc_sp_t
plc_get_sp_conf(char *name) to get the handle to the synch point directly from the name = value pair in the config file.
Synch points would be defined in the config file with a syntax similar to points.
[SYNCH]
synch_point name (... other stough to be explained later)

Each synchronisation point must be associated to one of the following:
1) the start sequence of the firing of a transition
2) the end sequence of the firing of a transition
3) the firing of a transition
...) other stough to be added later if time and OS system calls allow.

1) and 2) allow us to synchronise the begining and end of a module synchronously to the firing of a single transition. We would use two synch
points, one for the begining of the loop (with association type 1 to a transition), and another for the end (with association type 2 to the same
transition).

Association type 3 allows us to do an asynchronous association between the synchronisation point and the transition.

The main advantage of creating the new entities synch points is that it allows us to be able to specify in the config file how we want the module to synchronise without having to change or recompile the code. (Note that otherwise we would need two different functions to synchronise the module to the transitions, one to be called at the begining, and another at the end of the loop).

The other advantage is that we may later add other association types between synch points and the petri net, and these can be used by the modules without requiring to change their code (they would need to be relinked to the lplc
object code, though this won't be a problem if we later change to .so files). Other possible association types could be to fire the synch point when a place becomes empty, ...

Note that a module may need to synchronise at intermediate stages of its logic. With this scheme the user can completely configure what the module will synchronise to.

This scheme does have the drawback that it requires a little bit more effort in configuring the system, though some people will not really see that as a drawback, but as an advantage ;-)

Mario.

----------------------------------------------------------------------------
Mario J. R. de Sousa [email protected]
----------------------------------------------------------------------------




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

Curt Wuollet

I'm impressed guys, it's brilliant, of course. and would be truly innovative. Of course, it's also rather occult and opaque. I can't imagine too many people wanting to deal with it. Can we make it simple to use if you're not too curious about how it works? Playing devil's advocate again. I try to imagine explaining things to a plant engineer who's up to his knees in raw
sewage and it's rising. I'll bet the educational folks would love it as a practical example. It's kinda like a parallel state machine with active
condition monitors and status tracking.

regards

cww

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

Mario de Sousa

Curt,

I haven't been too woried about how convoluted it might seem if you are writing the config file yourself. I am imagining that we will shortly have a GUI to generate it for us. For simple sequencing of modules, it could even have a
graphical interface that would be inteligently mapped onto transitions, places, synch points, etc...

On the other hand, and regarding manual configuration, I am sure what we have come up with is within an engineers grasp. Of course, it does reqiure reading a few manuals. A technician might require some training...


Mario


----------------------------------------------------------------------------
Mario J. R. de Sousa [email protected]
----------------------------------------------------------------------------

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

Curt Wuollet

Hi Mario

I guess what I'm getting at is: Can we have some sort of reasonable default behaviour? And frankly, I think your assesment of PLC users is very generous. While some are actual engineers and technicians there are a lot of folks doing automation who are neither and they tend to be the ones most receptive to PC solutions. This isn't a putdown, simply a fact. That's why I'm tweaking you guys a little:^) I don't want to discourage you, just remind you who the target audience is and that at some point, even having the source doesn't do them any good. I make a living with Linux and some of this is a reach. It's a long ways from doctorate level CS to the factory floor. I'm in a fairly good position to see this, I work with a full spectrum of people every day. I wasn't being sarcastic though, it is a good fit for the problem from what I understand and quite impressive.

regards

cww


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

Ralph G. McDonald

Hi Jiri

If I understand your example of a simple Petri net correctly and I wanted to translate it to Ladder Logic would it be like :

Example One
A B PID
|---[ ]-----[ ]--|---(SS)---
|
|--(L)----
|
| A
|--(U)---
|
| B
|--(U)---

If (A and B) then (do PID once and then (Latch C and then (Unlatch A and B)))

Or Example Two
PID
|---[A>0]-----[B>0]---|---(SS)---
|
|---[C=C+1]---
|
|---[A=A -1]---
|
|---[B=B -1]---

If ((A>0) and (B>0)) then ( do PID once and then ( Increment C and then (( Decrement A ) and ( Decrement B ))))

I suspect example Two is closer because it allows for more then one token in A, B, or C
Could be modified by changes such as [C=C+2], [C=C+D], etc.

Hope I am on the right track?

Thanks

Ralph

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Ralph G. McDonald:
> If I understand your example of a simple Petri net correctly and I wanted
> to translate it to Ladder Logic would it be like :

> Or Example Two
...
> If ((A>0) and (B>0)) then ( do PID once and then ( Increment C and then
> (( Decrement A ) and ( Decrement B ))))

> I suspect example Two is closer because it allows for more then one token
> in A, B, or C Could be modified by changes such as [C2], [CD], etc.

Yes, except:

a) the decrement happens first, so that it's

If ((A>0) and (B>0)) then (( Decrement A ) and ( Decrement B )) and
then ( do PID once and then ( Increment C ))

b) the condition and the decrement happen "atomically". That means it works the way you'd expect it to even if there's something else waiting to do an
If (A>0) then (Decrement A) ...

In that case, if A is 1, only one or the other will happen, never both and never tangling up over it. That's why it has to have the fancy "semaphore" thing rather than just being plain C code.


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
 
R

Ralph G. McDonald

Hi All

As one of the engineers who works with the users in the field, including a lot of sewage treatment plants, I agree with Curt that the "normal" LPLC system has to be relatively easy for the plant technician to use for troubleshooting and minor program changes. As an example of that sort of system, see Allen-Bradley's RSLogix. You need to have standard defaults for the most common uses that hide unnecessary complexity from the user that just wants to program, use, and troubleshoot a LPLC.

However to agree with Mario, there can be options that are only used when required. (Example AB M0/M1/G fields for certain I/O modules ). As long as the documentation is there for the user that needs extra capability, he will either figure it out or call in some one who can.

Quite often I work helping my clients do initial setup and addition of new I/O modules which require the configuration of AB M0/M1/G fields and interface logic. Later the client performs most troubleshooting and minor program changes on their own with only a little phone support.

Having been in the situation where the home phone rings on a Sunday afternoon, the least experienced plant operator is on duty and he calls me because the sewage is rising and he can't get into the PLC, I wouldn't want to specify a system that only a few people can understand and deal with. At least at the level of restarting, reloading, basic troubleshooting, etc.

Also thanks for the explanation on Petri nets. I am going to do a little more digging on the subject as it looks interesting.

Ralph

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Mario de Sousa:
> Nevertheless, I would like to propose a framework where [asynchronous
> associations] could be supported
...
> Here is my sugestion: We create a new entity for the LPLC, i.e. a
> synchronisation point (plc_sp_t). Modules only need to synchronize with
> synch points using a simple function plc_synch(plc_sp_t sp). They would
> use two distinct synch points at the beginning and at the end of their
> loop.

(See my other post for more explanation.)

I would suggest that those two synch points be automatic, and even declare a couple of shorthand functions for them:

plc_synch_begin(void)
plc_synch_end(void)

as well as the generic plc_synch(plc_synch_t synch). The idea is to simplify the common case.

> They could get the handles to the synch points with a plc_sp_t
> plc_get_sp_by_name(char * name) function. They could get the name of the
> synch points to use through a name = value pair.

I think there doesn't need to be a name=value pair. The plc_get_synch() function would just prepend the module name and a dot.

> Each synchronisation point must be associated to one of the following:
> 1) the start sequence of the firing of a transition
> 2) the end sequence of the firing of a transition
> 3) the firing of a transition
> ...) other stough to be added later if time and OS system calls allow.

I would limit this to number 3.

As per my other post, 1 and 2 can be faked by magically expanding a module name into "module.end" or "module.begin" depending on where it occurs.

> Association type 3 allows us to do an asynchronous association between the
> sycnhronisation point and the transition.

> The main advantage of creating the new entities sycnh points is that it
> allows us to be able to specify in the config file how we want the module
> to synchronise without having to change or recompile the code.

We need to insert the synch points into the code, though.

> The other advantage is that we may later add other association types
> between synch points and the petri net,

Yes.

> Other possible association types could be to fire the synch point when a
> place becomes empty, ...

Yes, linux has that, but I can't see where that'd be useful. Easy to do if someone asks for it, though.

> Note that a module may need to synchronise at intermediate stages of its
> logic.

Yes, if it makes sense. A lot of the time it probably won't, but the option is there.

In the common case, the only change to the module would be to insert calls to the plc_synch_begin() and plc_synch_end() functions, like this:

while (TRUE) {
+ plc_synch_begin();
do_io(in);
plc_update();
do_io(out);
+ plc_synch_end();
sched_yield();
}

(We might even put the sched_yield() into plc_synch_begin(), to be called if there's no synchronisation to be done.)

Comments?

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
 
Curt Wuollet:
> I guess what I'm getting at is: Can we have some sort of reasonable
> default behaviour? And frankly, I think your assesment of PLC users is
> very generous.

That's basically what I had in mind when I wrote

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.

How about this: by default, there are "beginning of cycle" and "end of cycle" synchs, and if you just use the module name then incoming arcs go to
the begin-synch and outgoing arcs go from the end-synch.

The syntax might even have some (or all) the places anonymous, so that if you have modules A and B, the syntax
A -> B
translates to:

--------- A.end
|
v
(.) anonymous place
|
v
--------- B.begin


At that point you mostly use the words "Petri net" when you want to impress your boss, otherwise you just read "A -> B" as "A before B". But the rich semantics is still there, if you have the skill and opportunity to use it.

I just realized, the synchs probably don't need to be specified in the config file, because they can always be "module.foo" - can anybody think of
a situation where that wouldn't work?

(It's not like points, which need to be accessed by several modules; each synch is specifically for a particular module.)

The config file syntax I would imagine like this:

A place is declared like this:
petri A B 2 -> C D.foo

Where to the left of the arrow are transitions that have arcs leading into that place (and optionally an initial number of tokens) and on the right transitions to which arcs lead out of that place. Bare module names will be appended ".end" and ".begin" resp. Weighted arcs are "number*synch".

A.end B.end
------- -------
| |
\| |/
(.) init. 2 tokens
/ \
v v
------- -------
C.begin D.foo


Usually, it will be like this:

[synch]
# make A, B and C cycle in sequence, A first
petri A -> B
petri B -> C
petri 1 C -> A


> While some are actual engineers and technicians there are a lot of folks
> doing automation who are neither

Is this a worry or have I been reading too much comp.risks?


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
 
M

Mario de Sousa

Jiri Baum wrote:

> Mario de Sousa:
> > Nevertheless, I would like to propose a framework where [asynchronous
> > associations] could be supported
> ...
> > Here is my sugestion: We create a new entity for the LPLC, i.e. a
> > synchronisation point (plc_sp_t). Modules only need to synchronize with
> > synch points using a simple function plc_synch(plc_sp_t sp). They would
> > use two distinct synch points at the beginning and at the end of their
> > loop.
>
> (See my other post for more explanation.)
>

I have read it through but I need some more time to think it over.

>
> I would suggest that those two synch points be automatic, and even declare
> a couple of shorthand functions for them:
>
> plc_synch_begin(void)
> plc_synch_end(void)
>
> as well as the generic plc_synch(plc_synch_t synch). The idea is to
> simplify the common case.
>

OK. I can go with that.

>
> > They could get the handles to the synch points with a plc_sp_t
> > plc_get_sp_by_name(char * name) function. They could get the name of the
> > synch points to use through a name = value pair.
>
> I think there doesn't need to be a name=value pair. The plc_get_synch()
> function would just prepend the module name and a dot.
>

Actually I would still prefer the name=value pair. This allows us to copy and paste the configuration of a module to another module by simply changing the module name.

e.g.
[module_A]
synch_beg=...
synch_end=...

would simply become
[module_b]
synch_beg=...
synch_end=...

If we had
[module_A]
synch module_A_synch ...

we would have to change the name at several places.


We can have the name=value pair for the two default synch points read by synch_init() under the module_name section. This is how the SMM currently works. It reads the location=... and localmap_key=... under the module_name section. The module doesn't need to parse them. The plc library does it for the module.
Maybe we can have the synch_init() defaulting to some prepended name if it doesn't find the name=value pair. Maybe that could be confusing. I need to think a little bit more on this.


>
> > Each synchronisation point must be associated to one of the following:
> > 1) the start sequence of the firing of a transition
> > 2) the end sequence of the firing of a transition
> > 3) the firing of a transition
> > ...) other stough to be added later if time and OS system calls allow.
>
> I would limit this to number 3.
>
> As per my other post, 1 and 2 can be faked by magically expanding a module
> name into "module.end" or "module.begin" depending on where it occurs.
>

Yes, it's true. It does require an extra (anonymous) place though, and Linux currently being limited to 128 semaphores for each semaphore set could become a problem in big setups. But I guess we can later implement 1) and 2) if the need arises. That's the beauty of the synch points...

> (...)
> > Other possible association types could be to fire the synch point when a
> > place becomes empty, ...
>
> Yes, linux has that, but I can't see where that'd be useful. Easy to do if
> someone asks for it, though.

There are Petri Net model extensions that support this, and sometimes it does come in handy. But we can leave till later.

> (...)
> In the common case, the only change to the module would be to insert calls
> to the plc_synch_begin() and plc_synch_end() functions, like this:
>

> while (TRUE) {
> + plc_synch_begin();
> do_io(in);
> plc_update();
> do_io(out);
> + plc_synch_end();
> sched_yield();
> }
>
> (We might even put the sched_yield() into plc_synch_begin(), to be called
> if there's no synchronisation to be done.)
>

Yes, that would be a good idea.

****
I get your general drift though. Keep the underlying framework, but allow a shorthand (and simpler) way of specifying the synchronisation in the config file.

Mario.

----------------------------------------------------------------------------
Mario J. R. de Sousa [email protected]
----------------------------------------------------------------------------

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

Mario de Sousa

Jiri Baum wrote:

> (...)
> > we would have to change the name at several places.
>
> Just a two-line reply - I was actually thinking there'd be no declaration
> of synch points in the config file at all.
>
> It's not important, anyway - it's in a library, we can add a name=value
> pair later if we think of a use for it.

OK Jiri and others,

Here is my take on the simpler semantics of synch configuration, and using Jiri's idea of having two plc_synch_begin() and plc_synch_end() functions, besides the simple plc_synch() function.

Initially I was thinking that at the config file level we would have all the synch point and petri net complexities, and then have a configuring program (with GUI if necessary) that would have all the smarts and map the simple synch semantics onto petri nets and synch points.

Taking what Curt said into account, I guess we can take another approach. Let's put the 'smarts' of mapping simple synch semantics onto a petri net and synch points within the synch sub-module config file parsing.

What we will have will then be ANY semantics you would like to have that would be simple and cover the basic requirements of most of the
applications. Choose whatever you want. It doesn't matter. In the synch sub-module, the config file parser will map it into synch points, petri nets, and whatever else is needed.

We will still support the full semantics, for which a different semantics in the config file will be required. At first, before we actually implement this thing, it will probably be difficult to understand all the mappings
completely to be able to support both at the same time and merge them together, so at first we only support EITHER method of configuring the synch
sub-module. Maybe later we will be able to support both concurrently. I guess we will have to deal with that later.

Taking the above approach, we start with a clean slate in defining the simple synch config semantics. No need to speak about petri nets,
transitions and what not. So here is my suggestion:

example 1

[synch]
synch A -> B
synch B -> C
synch C -> A
init A

Would be start with A, then go to B, then C, then loop to A


example 2

[synch]
synch A -> B C
synch B && C -> D
synch D -> A
init A

Would be start with A, then go to B and C (executing simultalneously), when _both_ B and C have finished, go to D, then loop back to A.


example 3

[synch]
synch A -> B C
synch B || C -> D
synch D -> A
init A

Would be start with A, then go to B and C (executing simultalneously), when _either_ B or C have finished, go to D, then loop back to A. Note that if B finishes earlier, then when C finishes no other module is started, and vice-versa.
This, although seemimgly easy at this level, actually will require a rather complex petri net (which woud require the extra threads to just wait on some transitions). If we want to make it really general, we need null arcs (note: I can't remember if this is the correct name for the arc type), i.e. an arc from a place (P) to a transition (T) that only enables the transition T to fire when the place P is empty (and doesn't remove any tokens from that place P). Unfortunately, this type of arc is not possible to implement with semaphores (Jiri, do you know better?)
Mapping this onto a petri net without 'null arcs' means that we can't have one of the modules (B or C) advance on the other, i.e. we can't have a
situation where B is always faster than C so B gets a backlog of loops to execute. Assuming that B is the faster module out of B and C, what we will be able to support is:
- A finishes and launches B and C
- B finishes first and launches D
- D finishes and launches A
- A finishes and launches B and C (Note C has not yet finished executing its first loop, but it is OK, the place will get an extra token and will
remember the backlog of C)
- B finishes BUT DOES NOT LAUNCH D until C finishes its previous loop.


example 4

[synch]
synch A -> 6 B C
synch 6 B && C -> A
init A

Would mean start with A, then loop B 6 times and C once simultaneously, every time B finishes 6 loops and C one loop, launch A.


Using the above semantics, we could have:

example 5

[synch]
synch 6 B && C -> 6 B C
init 6 B
init C


example 6

[synch]
synch A1 -> B1
synch B1 -> C1
synch C1 -> A1

synch A2 -> B2
synch B2 -> C2
synch C2 -> A2

init A1
init A2

Two loops executing in parallel with no synchronisation between them.


example 7

[synch]
synch A1 -> B1
synch B1 -> C1

synch A2 -> B2
synch B2 -> C2

synch C1 && C2 -> A1 A2

init A1
init A2

Two loops executing in parallel, synchronising when both C1 and C2 finish executing.


OK, what do you think? I'm sure there must be some ambiguities in the semantics I have just explained. Maybe you can come up with a better one?


Mario.

----------------------------------------------------------------------------
Mario J. R. de Sousa [email protected]
----------------------------------------------------------------------------

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
I wouldn't worry much, there's not much we can do the change it.

I have observed, in a long career of technical persuits, that there is a certain ratio of people who know what they are doing to people who do not. The problem is, that no title, degree or certification seems to materially alter that ratio. Only accomplishment sorts it all out.

On the rest, I will need some time to form an intelligent reply. I am hard pressed at the moment and up to my arse in alligators.

Regards

cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Mario de Sousa asked (in a long article which I'll reply to later):
> null arcs
...
> Unfortunately, this type of arc is not possible to implement with
> semaphores (Jiri, do you know better?)

It is possible. Quoting from semop(2):

If sem_op is zero, the process must have read access permissions on
the semaphore set. If semval is zero, the operation goes through.
...
Otherwise semzcnt is incremented by one and the process sleeps
until one of the following occurs:
- semval becomes 0, ...
- ...

No problem.

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
 
Mario de Sousa:
> Taking the above approach, we start with a clean slate in defining the
> simple synch config semantics. No need to speak about petri nets,
> transitions and what not. So here is my sugestion:
...
> OK, what do you think? I'm sure there must be some ambiguities in the
> semantics I have just explained. Maybe you can come up with a better one?

Do you have an algorithm in mind for implementing it?

I'm worried that we will somewhat simplify boilerplate specifications but make *understanding* the meaning much harder. There's the beauty of Petri nets that, when you get lost, you can take a piece of paper and a handful of machine nuts[1] and work through what's going on.

I haven't thought through all your examples in detail, but I think most or all of them can be specified fairly easily using Petri nets directly. If I get time I'll go through them (make a start on a "synch cookbook").


Jiri
[1] or washers, but washers are harder to pick up.
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World!

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

Mario de Sousa

Jiri Baum wrote:

> Mario de Sousa:
> > Taking the above approach, we start with a clean slate in defining the
> > simple synch config semantics. No need to speak about petri nets,
> > transitions and what not. So here is my sugestion:
> ...
> > OK, what do you think? I'm sure there must be some ambiguities in the
> > semantics I have just explained. Maybe you can come up with a better one?
>
> Do you have an algorithm in mind for implementing it?

All the situations I gave are easily mapped onto Petri Nets if I do it manually, but thinking of an algorithm to do it will but a bit more work.

The main point is the approach I intend to take. This means I can go ahead and implement the petri net synch model, and once this is done we go ahead and try to simplify its use for the most common usage paterns. Since nobody has yet
voiced an opinion against this, I think everybody kind of agrees with the approach.

> I'm worried that we will somewhat simplify boilerplate specifications but
> make *understanding* the meaning much harder. There's the beauty of Petri
> nets that, when you get lost, you can take a piece of paper and a handful
> of machine nuts[1] and work through what's going on.
>

As I said, we will still support the petri net synch model. Actually I intend to implement this first, and only then simplify its use.


> I haven't thought through all your examples in detail, but I think most or
> all of them can be specified fairly easily using Petri nets directly. If I
> get time I'll go through them (make a start on a "synch cookbook").
>

Yes, that would be neat. It would make life easier when it comes to developing the algorithm to do the mapping onto petri nets.

Mario.


----------------------------------------------------------------------------
Mario J. R. de Sousa [email protected]
----------------------------------------------------------------------------

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