To store, or not to store, that is the question

S

Thread Starter

Simon Martin

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
 
H

Herman Chrisstoffer

Hello all,

Until now I just sit and read all interesting mails regarding the LinuxPLC project. I now feel I can contribute a few humble words regarding the storage of io-points. I do have a scada background
and have expierence with a package called FAST/TOOLS. In this package all tags are located in an incore table. An image of the incore table is maintained on disk (this image contains also all tags with a value and status and some
additional information). When starting the package this image is used to build up the incore table with a value/status for each tag.

When defining a tag one is able to:
- never save value/status updates to disk
- save every value/status update to disk
Furthermore there is a possibility to save the whole incore table to disk (e.g. at a shutdown of the system) or to force a save of an individual tag to disk.

For most applications we use these options as follows:
- output tags (setpoints, etc)
save every value change to disk (they normally do not change very often)
- input tags
do not save value changes to disk.
All input tags will have a "save" value (= no alarm) defined in the image on disk. This means that when the package is starting all input tags will have a normal "save" value. The first I/O scan will update these tags from the field.
My expierence is that this covers most applications.

Conclusion: Implement a similar mechanism in the LinuxPLC and it will cover most applications.

Regards
Herman Chrisstoffer
Project Engineer
Yokogawa ISS bv
mailto: [email protected]
_______________________________________________

LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
On Tue Jan 18 09:07:48 2000 Simon Martin wrote...
>
>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.
....<clip>....
>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

I like this, however I would suggest that the default be persistent.
>
>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)?

It's absolutely applicable. It tells which shared memory segment the reference is to.

--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.

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