Updated period library

M

Thread Starter

Mario de Sousa

Hi all,

I have commited an update to the period library.

It now uses POSIX timers and signals to correctly execute the modules periodically. The use of POSIX timers requires that any executable also be linked to the librt library. For this reason all the Makefiles were also changed in order to add LDFLAGS = -lrt

Is there any other way to do this without having to change every Makefile?

Is this library present in every flavour of Linux?

I did not change the lang/tcl Makefile, as it is automatically generated by autoconf. Greg, do you think you could add this somehow to the Makefile.in file so we can get the tcl extension to work again?


The scan period of a module is now configured using the following syntax:
[module_name]
scan_period = xxxx

where xxx is a floating point number, representing the period in seconds.



Jiri, I don't think that using a f32 for the scan_period is going to work. I now feel that the f32 precision is not enough. I thought it gave
10 digit precision, but it seems I was wrong. For example, when I set a period of 0.3 sec, this gets read as 0 + 0.300000011 sec. (NOTE: the
period is counted and stored as two u32. The float is only used to read the value from the config file). Maybe if we read it in as a long double? Note that if we get 9 digit precision that would mean less than one second error every three years. What does everybody think? Is this enough?



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
 
J

Juan Carlos Orozco

Mario de Sousa wrote:

> Hi all,
>
> I have commited an update to the period library.

Will this be unified with the period parameter of the dsp modules? Any module will be able to use this feature just by assigning a scan_time? Is there a default scan_time in case none is defined?

What is the relationship between scan_time and module synchronization? Are
there any side effects? For example what happens when the module gets stalled by the synchronization for a time longer than the scan_time? A simple case where my concerns are easy to explain is, what happens in the next example if dsp1 has a 100ms scan time and dsp2 has a 150ms scan time?

[PLC]
synch dsp1 -> dsp2
synch dsp2 -> dsp1

synch_start dsp1

Sorry to ask you more questions instead of answering yours :^)

Regards,

Juan Carlos Orozco

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


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
G
> Jiri, I don't think that using a f32 for the scan_period is going to
> work. I now feel that the f32 precision is not enough. I thought it gave
> 10 digit precision, but it seems I was wrong. For example, when I set a
> period of 0.3 sec, this gets read as 0 + 0.300000011 sec. (NOTE: the
> period is counted and stored as two u32. The float is only used to read
> the value from the config file).
> Maybe if we read it in as a long double? Note that if we get 9 digit
> precision that would mean less than one second error every three years.
> What does everybody think? Is this enough?

I don't particularly like floats either, but in this particular example
(0.300000011 sec) the error is 11nS = 1/90MHz. Thats only ten clocks on a 900MHz CPU. So your talking about maybe three machine instructions. I really doubt that you will be able to acheive that level of accuracy anyway.

The precision becomes more of a factor once you get it up out of the noise. But at some point you have to ask yourself does it really matter. Does anyone care if after a three year timeout if it's off by one second or off by 100 seconds.

I'd be more concerned with the amount of CPU overhead required to maintain
hundreds of timers. I assume the code that decrements the timer counters will run quit frequently (otherwise you don't have any precision).

Gary James



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

Mario de Sousa

Juan Carlos Orozco wrote:
>
> Mario de Sousa wrote:
> >
> > I have commited an update to the period library.
>
> Will this be unified with the period parameter of the dsp modules? Any
> module will be able to use this feature just by assigning a scan_time? Is
> there a default scan_time in case none is defined?
>

Yes Juan, I am working on this. I thought it would take 5 minutes, but I have been interrupted by something else. The cvs server should be
going down sometime in the near future, so I will probably only commit this once we get the new server at sourceforge up and running.

> What is the relationship between scan_time and module synchronization?

The module will block for the longer of the two times. Actually, what happens is that first the module blocks until the period has elapsed, and only then will it possibly block on the synchronisation primitives.

There is a caveat:
The period is determined using absolute times. This means that, if the module is started at t=0, with a period of T=5, but only gets to execute
the scan at t=6 (which should have started at t=0) because of synchronisation delays, then it will imediately be ready to execute the second scan once the first has finished, as long as it can synchronise a second time. In other words, there is a counter that counts periods that were overrun, and let's the execution proceed while these have not yet been caught up.

> Are
> there any side effects? For example what happens when the module gets
> stalled by the synchronization for a time longer than the scan_time? A
> simple case where my concerns are easy to explain is, what happens in the
> next example if dsp1 has a 100ms scan time and dsp2 has a 150ms scan time?
>
> [PLC]
> synch dsp1 -> dsp2
> synch dsp2 -> dsp1
>
> synch_start dsp1
>

The above config wouldn't make much sense! Anyway, I think I answered your question already?

What will most probably happen in practice is the first module has a defined period, while all the other modules are left with the default
period of T=0, which means they will run as fast as they can, without any delays introduced by the period library.

> Sorry to ask you more questions instead of answering yours :^)
>

Sure. No Problem.

I usually explain these things in an example linuxplc.conf file inside the library directory. I haven't yet done this because I still don't
know how things will end up with the configuration syntax...

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
 
M

Mario de Sousa

Gary James wrote:
>
> > Jiri, I don't think that using a f32 for the scan_period is going to
> > work. I now feel that the f32 precision is not enough. I thought it gave
> > 10 digit precision, but it seems I was wrong. For example, when I set a
> > period of 0.3 sec, this gets read as 0 + 0.300000011 sec. (NOTE: the
> > period is counted and stored as two u32. The float is only used to read
> > the value from the config file).
> > Maybe if we read it in as a long double? Note that if we get 9 digit
> > precision that would mean less than one second error every three years.
> > What does everybody think? Is this enough?
>
> I don't particularly like floats either, but in this particular example
> (0.300000011 sec) the error is 11nS = 1/90MHz. Thats only ten clocks on a
> 900MHz CPU. So your talking about maybe three machine instructions. I
> really doubt that you will be able to acheive that level of accuracy
> anyway.
>

No, not on each cycle. But if you consider 3e9 cycles, it means you will execute an extra 11. This is so because the timers use an absolute
timer, that starts at the beginning of the first scan, and not a relative timer that is re-initialized every period.

Of course, this is assuming that the hardware clock is sufficiently precise. Most likely it will have a higher drift than the above
precision?

> The precision becomes more of a factor once you get it up out of the noise.
> But at some point you have to ask yourself does it really matter. Does
> anyone care if after a three year timeout if it's off by one second or off
> by 100 seconds.

That is exactly what I was asking the list, in diferent words, of course ;-)

> I'd be more concerned with the amount of CPU overhead required to maintain
> hundreds of timers. I assume the code that decrements the timer counters
> will run quit frequently (otherwise you don't have any precision).

The precision you have depends on the platform you will be running it on. If you run it on plain vanilla Linux, the best you will get is 10 ms. That is the clock resolution. Note that this does not mean my assertion above regarding the extra 11 cycles is not correct!

If you run it on the RK version of RT Linux, this will go down to 500 us. Of course, this will require the use of special function calls that
only exist on that version of Linux. It is not in the PLC code yet, but it won't be too difficult to add them later on. I haven't added them yet
because I want to make the code as portable as possible, and I would have to look into which conditional compilation directives I need to
insert.

Hopefully, the PLC code will eventually run on QNX too (it doesn't compile there yet because we are still using non POSIX semaphore function calls, besides a few other details). Does anybody know offhand the resolution we can obtain on this platform?

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
 
Top