Oven Demo (was Big Demo)

J

Thread Starter

Juan Carlos Orozco

Just to be sure, the Big-Demo is now called "oven demo" the first partial (but operational) release is in the linuxplc cvs under /demo/oven/

Could someone help me answering the next questions:

Is it possible to fire (wait for) a synchpoint from a c function? I mean the equivalent of writing plctest -w synchpoint. I want to be able to control the program flow directly from c modules. I know there are predefined synchpoints in each module scan_beg from plc_scan_begin() function and scan_end from plc_scan_end() function. What I want is custom made synchpoints that I can use to have for example conditional execution of certain modules. Looking at the synch.h header, I found that the answer could be (Is this correct?):

plc_synch(plc_synchpt_by_name("my_synchpoint"));
// my_synchpoint has to be defined in the linuxplc.config file.

What timing functions are there available in the project?

I am studying the linuxplc petrinet to use them in the demo. From the demo-synch linuxplc.conf.complex I was able to draw flow diagram, the only thing that is not clear to me is why do you have a weight of 2 in the arc
from T_chaser_beg to P_chaser_running? What is the effect on this, changing it to 1 seems not to affect the program. From my diagram it looks like
tokens are going to be acumulating in the P_chaser_running place because it receives 2 tokens but it only gives away one when firing to T_chaser_end transition?

Regards,

Juan Carlos Orozco

ACElab Industrial Automation
[email protected]
www.ace-lab.com

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

Mario de Sousa

Juan Carlos Orozco wrote:
>
> Just to be sure, the Big-Demo is now called "oven demo" the first partial
> (but operational) release is in the linuxplc cvs under /demo/oven/
>
> Could someone help me answering the next questions:
>
> Is it possible to fire (wait for) a synchpoint from a c function? I mean the
> equivalent of writing plctest -w synchpoint. I want to be able to control
> the program flow directly from c modules. I know there are predefined
> synchpoints in each module scan_beg from plc_scan_begin() function and
> scan_end from plc_scan_end() function. What I want is custom made
> synchpoints that I can use to have for example conditional execution of
> certain modules. Looking at the synch.h header, I found that the answer
> could be (Is this correct?):
>
> plc_synch(plc_synchpt_by_name("my_synchpoint"));
> // my_synchpoint has to be defined in the linuxplc.config file.

The above is correct!

May I sugest you first call, during setup,
plc_synchpt_t my_synchpt = plc_synchpt_by_name("my_synchpoint");

You can then use plc_synch(my_synchpt) whenever you wish to sycnhronise.

It is best to use this approach, as the xxx_by_name() functions are not guaranteed no execute quickly.

It is nice to see that you are finding usefull what some people initially considered overkill when we were designing the synchronisation
library.

> What timing functions are there available in the project?

If you are programming in C, you can use the POSIX timer and clock functions. With these timers you can have event driven code. If you need help with these, just send me an email...

Jiri also wrote a timer library, but it is supposed to be used in polling mode. Check /lib/timer

Use whatever is most apropriate for you.

> I am studying the linuxplc petrinet to use them in the demo. From the
> demo-synch linuxplc.conf.complex I was able to draw flow diagram, the only
> thing that is not clear to me is why do you have a weight of 2 in the arc
> from T_chaser_beg to P_chaser_running? What is the effect on this, changing
> it to 1 seems not to affect the program. From my diagram it looks like
> tokens are going to be acumulating in the P_chaser_running place because it
> receives 2 tokens but it only gives away one when firing to T_chaser_end
> transition?

Once again, you are correct!

The weight of 2 is a bug! It should be 1.

Actually, I did it on purpose to see what would happen when the semaphore used to store all the places reached it's limit. What happens is not nice. In the future we will have to protect against it somehow...
Anyway, I must have commited the change to the weight of 2 by mistake. I was testing on my own copy. It was never meant to get to the cvs...

By the way, I am still working on the correct version of the period library. Half way I found out that Linux *does* suport POSIX timer
functions, so I threw away some code, and had to write a new version again... It shoudln't take long now.


Cheers,

Mario.

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

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Juan:
> Looking at the synch.h header, I found that the answer could be (Is this
> correct?):

> plc_synch(plc_synchpt_by_name("my_synchpoint"));
> // my_synchpoint has to be defined in the linuxplc.config file.

You should probably do that separately - call the plc_synchpt_by_name() at the top of the program and call just plc_synch() in the loop.

Theoretically, at least, the *_by_name() functions are not guaranteed to be particularly timely. Also, this lets you bail out of the program early if the synch point doesn't exist.

> What timing functions are there available in the project?

There are two groups:
- Mario's recent period library (lib/period)
- the timer library (lib/logic/timer.h)

I'm not familiar with Mario's library (yet), but with the timer library you declare timers as ordinary C variables of type plc_timer_t. They work a bit like stopwatches: they can be either running or stopped, and you can read their value and reset them.

When reading the timer.h file, ignore the _fn functions. (This is where documentation would've been really good.)

> I am studying the linuxplc petrinet to use them in the demo.

Not sure about this one - I'd have to go draw it too...


Jiri
--
Jiri Baum <[email protected]>
"[Microsoft] cleverly associate the word 'open' with XML. What they don't mention is that to see the XML file definitions for Microsoft Word, you
have to sign a file license that says you will never use the code."
-- http://www.itworld.com/Man/2685/IDG010503source2/

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

Mario de Sousa

Jiri Baum wrote:
> (...)
> There are two groups:
> - Mario's recent period library (lib/period)
> - the timer library (lib/logic/timer.h)
>
> I'm not familiar with Mario's library (yet), (...)


The period library is simply to control the rate of execution of a module. Say you want a module to run only every 100 ms. You can then set it in the configuration file...

[module_name]
scan_period_sec = xxxx
scan_period_nsec = yyyy

The scan_period would be the sum of the two. The first is given in seconds, the second in nanoseconds.

Actually, the above syntax will only be correct once I finish the changes to the period library. Currently it is

[module_name]
module_period = zzzz

Where zzz is the period in miliseconds.


The module can change it's own period during runtime by calling the
plc_period_set() and plc_period_get() functions.


Mario.

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

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Jiri:
> > I'm not familiar with Mario's library (yet), (...)

Mario:
> The period library is simply to control the rate of execution of a
> module. Say you want a module to run only every 100 ms. You can then set
> it in the configuration file...

Ah, ok. Not so useful in itself for timing, then.

> [module_name]
> scan_period_sec = xxxx
> scan_period_nsec = yyyy

> The scan_period would be the sum of the two. The first is given in
> seconds, the second in nanoseconds.

I'd be tempted to make it a float... (The config setting - in the program it'd immediately get converted into a pair of ints, so that no further loss of precision occurs; I guess that's how I did the timer library.)


Jiri
--
Jiri Baum &lt;[email protected]>
"[Microsoft] cleverly associate the word 'open' with XML. What they don't mention is that to see the XML file definitions for Microsoft Word, you
have to sign a file license that says you will never use the code."
-- http://www.itworld.com/Man/2685/IDG010503source2/

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

Mario de Sousa

Jiri Baum wrote:
>
> Mario:
> > [module_name]
> > scan_period_sec = xxxx
> > scan_period_nsec = yyyy
>
> > The scan_period would be the sum of the two. The first is given in
> > seconds, the second in nanoseconds.
>
> I'd be tempted to make it a float... (The config setting - in the program
> it'd immediately get converted into a pair of ints, so that no further loss
> of precision occurs; I guess that's how I did the timer library.)
>

Yes, that makes sense. I guess 10 digit precision should be enough for the period.

Mario.

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

The box said it requires Windows 95 or better, so I installed Linux

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