S
Ok gentleman, this is what I see as the basics for my assumed task.
1) SharedMemoryManager
This process creates the SharedMemory space. The memory space is allocated taking into account all the memory specified by the VirtualIO configuration files. I can ignore the PhysicalIO configuration files as these must be mapped into the VirtualIO map for them to be used, providing independance of the PLC Engines from the IO configuration itself.
The SharedMemoryManager is responsible for data persistence. All registers in the VirtualIO map must have a persistance priority assigned to them
(something like critical, important, normal) allowing flexibility in the volume of data to be written.
2) VirtualIO configuration
The VirtualIO are the IO points available to the PLC Engines. At the start of a scan the PLC Engine will request a copy of the Input data, at the end of a scan the PLC Engine will submit it's output data. The SharedMemoryManager is responsible for extracting/merging this data.
The VirtualIO would be defined by something like
<io type> <element> . <sub element> <tag> <description>
A PLC Engine may request the current value of a single IO point, or a set of IO points, or the next updated value of an IO point/set of IO points.
Questions:
Can each PLC Engine have its' own VirtualIO table that maps onto the global IO table?
What is the harm of more one process updating an output (apart from the programmers sanity)?
Any more ideas before I start coding?
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
1) SharedMemoryManager
This process creates the SharedMemory space. The memory space is allocated taking into account all the memory specified by the VirtualIO configuration files. I can ignore the PhysicalIO configuration files as these must be mapped into the VirtualIO map for them to be used, providing independance of the PLC Engines from the IO configuration itself.
The SharedMemoryManager is responsible for data persistence. All registers in the VirtualIO map must have a persistance priority assigned to them
(something like critical, important, normal) allowing flexibility in the volume of data to be written.
2) VirtualIO configuration
The VirtualIO are the IO points available to the PLC Engines. At the start of a scan the PLC Engine will request a copy of the Input data, at the end of a scan the PLC Engine will submit it's output data. The SharedMemoryManager is responsible for extracting/merging this data.
The VirtualIO would be defined by something like
<io type> <element> . <sub element> <tag> <description>
A PLC Engine may request the current value of a single IO point, or a set of IO points, or the next updated value of an IO point/set of IO points.
Questions:
Can each PLC Engine have its' own VirtualIO table that maps onto the global IO table?
What is the harm of more one process updating an output (apart from the programmers sanity)?
Any more ideas before I start coding?
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