J
Jiri:
> > Timers will probably best be stored as "starting time", with the IL
> > executor making note of wall time at the start of the scan, then the
> > TIMER instruction will just compare the difference between the two with
> > the given value.
...
Scott Cornwall:
> OK, but what ever is monitoring the system (on same Linux box or remote)
> will want to see the current value of the timer in some form. If only the
> starting time is being saved then some calculation needs to be invoked to
> determine the current value.
Yes. However, the calculation is fairly simple relative to the conversion into printable form, so it shouldn't be a problem.
> When monitoring remotely then the comms protocol will have to invoke this
> calculation, which may place some limitation on the choice of protocol
> for this sort of communication.
Not really - if the protocol doesn't have a "starting-time timer" data type, then we'll just have to convert it into an "elapsed-time timer" at
transmission time. No problem.
I just don't see elapsed-time as being a good storage method for timers, that's all. Even if we implement it carefully enough to avoid losing
precision, it's still a calculation on every scan for every timer, whether or not a particular timer is being used (there's no way we can tell), and a complication to the otherwise relatively elegant plc_update().
(The timer might be only used in one part of the machine cycle, or only with a particular recipe. The logic program might even reset a timer
whenever something happens, but never actually read it - the only point being to show up on the monitor, if it's running.)
Besides, starting-time timers can be sent around all over the place, converted, written to disk or whatever, and they still keep ticking!
Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
> > Timers will probably best be stored as "starting time", with the IL
> > executor making note of wall time at the start of the scan, then the
> > TIMER instruction will just compare the difference between the two with
> > the given value.
...
Scott Cornwall:
> OK, but what ever is monitoring the system (on same Linux box or remote)
> will want to see the current value of the timer in some form. If only the
> starting time is being saved then some calculation needs to be invoked to
> determine the current value.
Yes. However, the calculation is fairly simple relative to the conversion into printable form, so it shouldn't be a problem.
> When monitoring remotely then the comms protocol will have to invoke this
> calculation, which may place some limitation on the choice of protocol
> for this sort of communication.
Not really - if the protocol doesn't have a "starting-time timer" data type, then we'll just have to convert it into an "elapsed-time timer" at
transmission time. No problem.
I just don't see elapsed-time as being a good storage method for timers, that's all. Even if we implement it carefully enough to avoid losing
precision, it's still a calculation on every scan for every timer, whether or not a particular timer is being used (there's no way we can tell), and a complication to the otherwise relatively elegant plc_update().
(The timer might be only used in one part of the machine cycle, or only with a particular recipe. The logic program might even reset a timer
whenever something happens, but never actually read it - the only point being to show up on the monitor, if it's running.)
Besides, starting-time timers can be sent around all over the place, converted, written to disk or whatever, and they still keep ticking!
Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc