S
Hi all,
There was the suggestion of using a memory mapped file for sharing the data between processes, and the persistence being created by periodically
updating the associated disk file, as opposed to writing a memory block to disk. How about something different for persistence, and let the IO process itself store the statii of the different IO. This means that a given interface would keep a status file holding all the data for the IO it handles, just writing CHANGES to disk when they occur (at the end of a scan). This will reduce disk activity and improve throughput. One side effect of this approach is that there must be a VirtualIO interface that stores all internal registers.
Someone was talking about changing IO polarity, if we define this as an attribute for an IO point then the IO interface can handle this concept.
This is a patch. Design the PLC program(s) for the IO involved, but it allows a cop out clause...
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
There was the suggestion of using a memory mapped file for sharing the data between processes, and the persistence being created by periodically
updating the associated disk file, as opposed to writing a memory block to disk. How about something different for persistence, and let the IO process itself store the statii of the different IO. This means that a given interface would keep a status file holding all the data for the IO it handles, just writing CHANGES to disk when they occur (at the end of a scan). This will reduce disk activity and improve throughput. One side effect of this approach is that there must be a VirtualIO interface that stores all internal registers.
Someone was talking about changing IO polarity, if we define this as an attribute for an IO point then the IO interface can handle this concept.
This is a patch. Design the PLC program(s) for the IO involved, but it allows a cop out clause...
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