J
Has there been any agreement on how the structure of this system would fit together? I have been slogging through the email archives, but January is fairly daunting to get through, so I will risk repeating something that was discussed.
I would like to make the following suggestion. Whoever does the ladder engine would be passed an I/O table (or pointer to) and a Linked list( or
whatever) of op-codes, p-code, or however that individual wants it. The engine would perform one scan, update the I/O, and return. This way, if I wanted to run an IL instead of ladder, I could 'plug in' the engine of my choice, and give it the appropriate user code. I would think this would make it very easy for a 'controlling skeleton' to be able to execute a ladder
program, a flow chart, an IL, etc. The editors would then compile the human readable language into the executable. Since most online data monitoring is just deciding how to display the data table, the editor could do the tricks
with lighting up the instructions that are true, etc. based in the data tables.
Online edits would be easily accomplished, just make the edits in a mirrored copy of the file, and when the user commits, change the pointer
reference.
I/O drivers would also be plugged and unplugged based on what the user has. The driver would function as the "abstraction layer" so that the processing engines did not need to be concerned with what was out there.
The control skeleton would then simply execute I/O drivers, then execute each processing engine that was needed, either sequentailly or multi
threads, then update I/O again. If the editor was needed, it would spawn that process.
I am not a C programmer (yet), so what I suggested needs to be run through the reality checker. However, I will be taking classes starting in April, and would be interested in self-teaching now while trying to write an IL
processing engine. I would like to have some guidelines, however, on what the interface needs to look like. As I said, I would like to see the
engines passed a pointer to the I/O tables, and the p-code linked list. I think this would maximize our ability to adapt to what the user wants to run, and makes it easier for us to implement something VERY simplistic now, and have the ability to add more engines, and refine existing engines, without messing everything else up.
As I mentioned at the beginning, if this has already been covered, tell me to get lost, and I will go along with what has been determined. If not, then let me know what everyone thinks.
In the meantime, I will try to find time to learn C enough to hack together a dumb-simple IL processor.
As a side note, I think that for testing the engines, everything could be done with simulated I/O. An I/O simulator might also be the best driver to write first, and the "real life" hardware drivers can write to the same interface.
Comments? This is my $.02 worth..........
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
I would like to make the following suggestion. Whoever does the ladder engine would be passed an I/O table (or pointer to) and a Linked list( or
whatever) of op-codes, p-code, or however that individual wants it. The engine would perform one scan, update the I/O, and return. This way, if I wanted to run an IL instead of ladder, I could 'plug in' the engine of my choice, and give it the appropriate user code. I would think this would make it very easy for a 'controlling skeleton' to be able to execute a ladder
program, a flow chart, an IL, etc. The editors would then compile the human readable language into the executable. Since most online data monitoring is just deciding how to display the data table, the editor could do the tricks
with lighting up the instructions that are true, etc. based in the data tables.
Online edits would be easily accomplished, just make the edits in a mirrored copy of the file, and when the user commits, change the pointer
reference.
I/O drivers would also be plugged and unplugged based on what the user has. The driver would function as the "abstraction layer" so that the processing engines did not need to be concerned with what was out there.
The control skeleton would then simply execute I/O drivers, then execute each processing engine that was needed, either sequentailly or multi
threads, then update I/O again. If the editor was needed, it would spawn that process.
I am not a C programmer (yet), so what I suggested needs to be run through the reality checker. However, I will be taking classes starting in April, and would be interested in self-teaching now while trying to write an IL
processing engine. I would like to have some guidelines, however, on what the interface needs to look like. As I said, I would like to see the
engines passed a pointer to the I/O tables, and the p-code linked list. I think this would maximize our ability to adapt to what the user wants to run, and makes it easier for us to implement something VERY simplistic now, and have the ability to add more engines, and refine existing engines, without messing everything else up.
As I mentioned at the beginning, if this has already been covered, tell me to get lost, and I will go along with what has been determined. If not, then let me know what everyone thinks.
In the meantime, I will try to find time to learn C enough to hack together a dumb-simple IL processor.
As a side note, I think that for testing the engines, everything could be done with simulated I/O. An I/O simulator might also be the best driver to write first, and the "real life" hardware drivers can write to the same interface.
Comments? This is my $.02 worth..........
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc