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

 

The internal function of the timers ( and counters )is not important as long as the programming, debugging, and operator interface GUI software can recover and display the timer / counter setpoint, running mode, and current time,
or count data.

It should be transparent to the application ( PLC ) programmer and the operator.

Whatever works best for the C/C+ coders, is the most error resistant internally, and quickest is what should be used. CPU cycles spent on packaging timer / counter data for transmission to other programs should be at a minimum as only that information that is currently needed should be sent.

Keep up the good work:

Ralph

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

 

Hello List,

I been thinking about how the timer should be implemented...

Timers should have (using allen-bradley terms):
1. Accumalate Value ( Integer or better )
2. Preset Value ( Integer or better )
3. Enable bit
4. Timer Timing bit
5. Done bit
6. Time base ( 1, 0.1 sec ... maybe we can expand on this)

Memory will have to be reserved for all of these, just like the other bits and values, so that it can be called by any process at anytime.

So, this would require the timer status to be updated before the program scan...and probably after the input table has been updated.

To implement this, I think internally the timers should have a start time recorded, and before each program scan, the timer status be updated. The accumalate value will then be the difference between the current time - start time ( in the terms of its time base.)

Anyways, that is how I did it in my own PC controls software that I designed and programed with Visual Basic.

Dan B.


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

 

Having used many different timers in many different PLC's I have found the timer TON & TOF representation complying with the IEC61131-3 to be the most useful. These accept and display time values in the form t#WdXhYmZms where W,X,Y,Z are your values. If you enter t#1575ms this is also acceptable and the Accumulator displays this as t#1s575ms. Similarly t#635s displays as T#10m35s.

> 1. Accumalate Value ( Integer or better )

See above.

> 2. Preset Value ( Integer or better )

See above

> 3. Enable bit
> 4. Timer Timing bit

This is the same as the enable bit, if it's not enabled, it's not timing.

> 5. Done bit

> 6. Time base ( 1, 0.1 sec ... maybe we can expand on this)

Irrelevant if "real" time is entered. The LPLC engine will sort out how often the Accumulated time is updated

Alastair

 

Hello,

Daniel Boudreault:
> Timers should have (using allen-bradley terms):
...
> 6. Time base ( 1, 0.1 sec ... maybe we can expand on this)

I'll probably make a response to the rest later, but for now just a quick question on this point.

Is there any need to have a time base? It seems to me that it would only be needed when timer size is fairly limited; wouldn't it make more sense to just make a timer big enough that we don't have to worry?


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

 

Hi All

Reluctant as I am to wade into this one, that model seems to carry a lot that is
infrequently used. We have very little cost for added functions. Why not light weight timers for general use and implementing heavy weight timers in code for those occasions when they are necessary. I'd hate to maintain a lot of state that is used only infrequently.
I'm fading back in the woods now......

cww

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