S
Hi all,
I come from a motion control background, so maybe my point of view is not completely applicable to this scenario, but anyway here goes.
The applications that I have worked upon in continuous processes (such as bag making) we get the following scenario. Operator sees problem, hits e-stop. Power is removed from everything (including controls), problem is corrected, power is reapplied, system comes up, recovers internal state, checks all interlocks, homes all axes (unless using absolute single/multi turn feedback) to come to a known state, realises it's halfway through a bag, ejects as scrap the current bag, works like crazy to pick up the slack
developed in the lazy loop between the extruder and the bagger.
I envisage similar things happening in the PLC, all internal status is recovered, Physical Inputs are read and stored, Physical Outputs are set to
0, PLC Scan is activated.
I would suggest a flag per iopoint specifying persistent or volatile. The SharedMemoryManager will store all persistent data to disk and retrieve it at power up and initialise all volatile data to a value specified.
So out config file is something like:
<type> <file> : <point> / <element> {persistent | volatile [= <initial value>]} <owner>
For example:
N7:0/0 persistent lazyloop
N7:0/1 volatile master
F1:23 volatile=3.14159 master
What is the AB meaning to the FILE parameter? Is it applicable to the Puffin PLC, or is it to make it look more like an AB PLC? If this is the case, why don't we just write a little front end to translate AB/Modicon/Omron/etc configuration files to our own internal format (which could be
AB/Modicon/Omron/OurOwn/etc)?
Debian GNU User
Simon Martin
Project Manager
Isys
mailto: [email protected]
There is a chasm of carbon and silicon the software cannot bridge
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
I come from a motion control background, so maybe my point of view is not completely applicable to this scenario, but anyway here goes.
The applications that I have worked upon in continuous processes (such as bag making) we get the following scenario. Operator sees problem, hits e-stop. Power is removed from everything (including controls), problem is corrected, power is reapplied, system comes up, recovers internal state, checks all interlocks, homes all axes (unless using absolute single/multi turn feedback) to come to a known state, realises it's halfway through a bag, ejects as scrap the current bag, works like crazy to pick up the slack
developed in the lazy loop between the extruder and the bagger.
I envisage similar things happening in the PLC, all internal status is recovered, Physical Inputs are read and stored, Physical Outputs are set to
0, PLC Scan is activated.
I would suggest a flag per iopoint specifying persistent or volatile. The SharedMemoryManager will store all persistent data to disk and retrieve it at power up and initialise all volatile data to a value specified.
So out config file is something like:
<type> <file> : <point> / <element> {persistent | volatile [= <initial value>]} <owner>
For example:
N7:0/0 persistent lazyloop
N7:0/1 volatile master
F1:23 volatile=3.14159 master
What is the AB meaning to the FILE parameter? Is it applicable to the Puffin PLC, or is it to make it look more like an AB PLC? If this is the case, why don't we just write a little front end to translate AB/Modicon/Omron/etc configuration files to our own internal format (which could be
AB/Modicon/Omron/OurOwn/etc)?
Debian GNU User
Simon Martin
Project Manager
Isys
mailto: [email protected]
There is a chasm of carbon and silicon the software cannot bridge
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc