K
Thanks Jiri for Clarifying some of these issues.
Each part (module) of the lPLC runs as a separate process, each linked against the linuxplc.a library[1].
OK ... I'm all for multiple processes ...
Example modules might be: logic (RLL) program, HMI, http-server, I/O [2], bus I/O/comm. Any particular installation will run only a few of the
available modules.
Hmmmm..... How do drivers get synchronized with the logic solve??
From this description they are all running asynchronously to each other through separate processes. Are we using system events to
synchronize these processes or what?? Ideally you want Input Driver Scan to run, logic to run, and then Output driver to run. IS this being done??
The linuxplc.a library provides various services, perhaps the most important being config, data map and synch. In turn:
- config - provides for the configuration of various lPLC
parameters from a single file, by default linuxplc.conf.
There
are private sections for each module (there is provision
for
several of a given module to run simultaneously), as well
as
sections used by all modules, eg [PLC] and [SMM].
OK.
- data map - provides the familiar data points, corresponding
to
PLC inputs, outputs and internal coils/registers. Points of
0 to
32 bits are supported, 1-bit points corresponding to simple
coils
or relays.
OK ... This sounds like a master IO table (even though internals are included) Steeplechase uses what they call a universal IO Table as their mechanism, which works great. Tags get compiled to a pointer and an offset into this table and then get modified and read by the logic scan. It is interesting to note that they include "Force" data in the table so that they can quickly mask tags to see if there is a force condition applied by the debugging program. There should be added data types to this, resembling "C" except they will not be compiler/machine specific (I.e. Integers are 32 bit signed always and floats are always 64 ..... you get the idea.) I think I saw mention to some data types in earlier discussion. IO types of 8 , 16, and 32 bit words need to be
supported as well.
As in a standard PLC, the data map is buffered so that
changes to
a point do not appear on the outputs (or HMI screen, or to
other
modules) until the end of the cycle.
OK
Unlike a standard PLC, no distinction is made between
inputs,
outputs and internal coils. It is recommended that the user
adopt
a naming scheme that avoids confusion.
I don't see how this is going to fly. How will driver modules know which tags to process if they don't know which ones are inputs and which ones are outputs?? Is this done as a part of this data map you were discussing??
- synch - this provides for (optional) synchronisation between
the
cycles of the various modules. By default each module runs
free;
synchronisation can lower CPU usage and provide more
uniform
latencies.
Some modules (eg PID) require that they be synchronised to
certain of their inputs, as they calculate deltas.
All my experience tells me that syncronization should not be optional. I have seen numerous occasions where NOT having synchronization of input, logic, and output stages has caused
extremely flakey program errors. Also it requires more careful programming practices.
[1] This should be linuxplc.so, but I've no experience creating shared libraries and neither, it seems, has anybody else. So linuxplc.a for
now.
[2] There is some argument whether there should be one I/O module or many, but in practice I think the point is moot as most installations will
only use one kind of I/O anyway, and hence only one I/O module.
This is definitely not moot. A lot of applications use different types of IO at the same time. Some industrial plants use dozens of IO
systems across their floor (although for the first stage of this project, we can assume a few different devices will be connected, since IO drivers will have to be written first!!!) Since we are on the subject, what are the hooks between the IO Table and the device Drivers?? I suggest that each device driver gets linked to the IO
table at compile time by the use of some IO config file.
~Ken
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
Each part (module) of the lPLC runs as a separate process, each linked against the linuxplc.a library[1].
OK ... I'm all for multiple processes ...
Example modules might be: logic (RLL) program, HMI, http-server, I/O [2], bus I/O/comm. Any particular installation will run only a few of the
available modules.
Hmmmm..... How do drivers get synchronized with the logic solve??
From this description they are all running asynchronously to each other through separate processes. Are we using system events to
synchronize these processes or what?? Ideally you want Input Driver Scan to run, logic to run, and then Output driver to run. IS this being done??
The linuxplc.a library provides various services, perhaps the most important being config, data map and synch. In turn:
- config - provides for the configuration of various lPLC
parameters from a single file, by default linuxplc.conf.
There
are private sections for each module (there is provision
for
several of a given module to run simultaneously), as well
as
sections used by all modules, eg [PLC] and [SMM].
OK.
- data map - provides the familiar data points, corresponding
to
PLC inputs, outputs and internal coils/registers. Points of
0 to
32 bits are supported, 1-bit points corresponding to simple
coils
or relays.
OK ... This sounds like a master IO table (even though internals are included) Steeplechase uses what they call a universal IO Table as their mechanism, which works great. Tags get compiled to a pointer and an offset into this table and then get modified and read by the logic scan. It is interesting to note that they include "Force" data in the table so that they can quickly mask tags to see if there is a force condition applied by the debugging program. There should be added data types to this, resembling "C" except they will not be compiler/machine specific (I.e. Integers are 32 bit signed always and floats are always 64 ..... you get the idea.) I think I saw mention to some data types in earlier discussion. IO types of 8 , 16, and 32 bit words need to be
supported as well.
As in a standard PLC, the data map is buffered so that
changes to
a point do not appear on the outputs (or HMI screen, or to
other
modules) until the end of the cycle.
OK
Unlike a standard PLC, no distinction is made between
inputs,
outputs and internal coils. It is recommended that the user
adopt
a naming scheme that avoids confusion.
I don't see how this is going to fly. How will driver modules know which tags to process if they don't know which ones are inputs and which ones are outputs?? Is this done as a part of this data map you were discussing??
- synch - this provides for (optional) synchronisation between
the
cycles of the various modules. By default each module runs
free;
synchronisation can lower CPU usage and provide more
uniform
latencies.
Some modules (eg PID) require that they be synchronised to
certain of their inputs, as they calculate deltas.
All my experience tells me that syncronization should not be optional. I have seen numerous occasions where NOT having synchronization of input, logic, and output stages has caused
extremely flakey program errors. Also it requires more careful programming practices.
[1] This should be linuxplc.so, but I've no experience creating shared libraries and neither, it seems, has anybody else. So linuxplc.a for
now.
[2] There is some argument whether there should be one I/O module or many, but in practice I think the point is moot as most installations will
only use one kind of I/O anyway, and hence only one I/O module.
This is definitely not moot. A lot of applications use different types of IO at the same time. Some industrial plants use dozens of IO
systems across their floor (although for the first stage of this project, we can assume a few different devices will be connected, since IO drivers will have to be written first!!!) Since we are on the subject, what are the hooks between the IO Table and the device Drivers?? I suggest that each device driver gets linked to the IO
table at compile time by the use of some IO config file.
~Ken
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc