Hi All:

I have been following the threads on Non-Volatile Store and UPS Hack and have several questions/comments:

On restart after power failure what is the status of the outputs: OFF or LAST-STATE?
I suggest that they default to "OFF" with a PLC programmer option of "LAST-STATE"
Depending on the process or equipment that the LPLC is controlling the "best" or "safest" option may be either one.

Do we have a "1st Scan" Status Flag in the LPLC?
If we do not, I think we should include one. I find this type of flag very useful even in the PLCs that have battery backed data tables. It allows the PLC program to initialize correctly after a start/restart.

If we have both "1st Scan" and "Non-Volatile Store OK" flags it allows the PLC programmer to include logic for both a "warm" and "cold" restart.

Glad to see the progress that is occurring:

Ralph


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

 

Ralph G. McDonald:
> On restart after power failure what is the status of the outputs: OFF or
> LAST-STATE? I suggest that they default to "OFF" with a PLC programmer
> option of "LAST-STATE" Depending on the process or equipment that the
> LPLC is controlling the "best" or "safest" option may be either one.

Currently, LPLC has no concept of "output"[*]. However, I think we can simply apply the above to all points, with the same logic.

(Now, in the absence of non-volatile store, all points initial OFF or 0.)

> Do we have a "1st Scan" Status Flag in the LPLC?

In some ways this is up to the individual logic engine - programs written in C implicitly have this; stepladder is rather embryonic at the moment.

> If we have both "1st Scan" and "Non-Volatile Store OK" flags it allows
> the PLC programmer to include logic for both a "warm" and "cold" restart.

"Non-volatile store OK" is definitely a good idea. Or perhaps have a separate program that is run when non-volatile store failed before the
normal program - will that be more practical?


Jiri

[*] It does, of course, have outputs themselves; it just doesn't have a concept for them. They are simply points that happen to be replicated in
the physical world.
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World! Step 1 - bid for SMOFcon

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

 

I think that should be user selectable per point, it could simply be done by selecting what the initial value of each point should be, defaulting to 0 and with an option to reload last state. Only values having this flag need to be stored.


/Johan Bengtsson

----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------


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

 

Be carefull. It is not usually safe to have an output that physically goes off during a power failure be able to return to its last state on power up.

Generally internal memory can hold its last state but real world outputs must start in a safe state ( usualy off ) and later get driven on by the PLC
logic ( eg. someone pressing the 'start button' ).

This early in the project it is probably ok to allow a 'reload last state' option for all memory locations but we must consider carefully what we
allow and disallow down the track.

Phil.

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

 

Philip Costigan:
> Be carefull. It is not usually safe to have an output that physically goes
> off during a power failure be able to return to its last state on power up.

> Generally internal memory can hold its last state but real world outputs
> must start in a safe state ( usualy off ) and later get driven on by the
> PLC logic ( eg. someone pressing the 'start button' ).

Remember, formally there's no such thing as an "output" in the LPLC. [*]

This, combined with the occasions where an output really should be
last-state, suggests that we warn about this in the manual, but allow it.


[*] In fact, I don't think we can even agree on any useful definition of
the word "output". All the ones I know are fairly arbitrary and useless for
this kind of safety distinction.

Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World! Step 1 - bid for SMOFcon

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

 

As someone mentioned, the linuxplc don't know the
concept of outputs, it is just a point as anyone
else that happens to have a physical output somewere.
I don't see enough reason to actually disalow this
feature on outputs (as long as the user have to
manually choose to have it like that). Some cases
might exist where this would be quite helpful and
the user selecting this option is the one
responsible anyway.
The future configuration tools should however have
some kind of warning that this might be unsafe
behaviour whenever the user selects it for an output.


/Johan Bengtsson

----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

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