G
Simon Martin a écrit :
>
> Hi all,
>
> I shall start coding this tomorrow (my personal customers are a bit nervous
> at the moment). I intend to have a working SMM and client API by the end of
> Feb. I'll post results as and when I have them. To recap on my design
> (please correct the things I have missed in my absence!!!):
>
> Config files reside in /etc/puffin. The IO Map is specified in the
> iomap.conf file. I expect this file to just be a set of global
> specifications and a sequence of "include" statements. The actual io point
> specifications being in individual files specified by the include. An io
> point is specified by
>
> <type> <file> : <point> / <element> {persistent | volatile [= <initial
> value>]} <owner>
>
> The SMM is responsable for persistance and handing each client a
> "photograph" of the IO on request. The API is defined as follows:
>
<snip>
Thanks Simon
You summarized your understanding of the huge amount of suggestions we read in the past few weeks. Before you start coding, I suggest we still
discuss about I/O files. From my point of view a file should be a collection of similar objects (aka an array of structures). I fear this will not be in your design. From my point of view, an application program should not care about I/O
addresses. Translation between a virtual I/O and a physical I/O is the chore of the I/O driver.
The application will be easier to understand if the tables are "object-oriented" instead of "type-oriented"
Here is a copy of a draft I wrote many weeks ago (I never sent it).
MANIFEST
Goals
- LinuxPLC must support communication with all actual I/O devices, either local, remote (eg OPTOMUX), through a gateway (a remote CPU, it
may be a PLC), or hierarchy (LinuxPLC would be a master of smaller LinuxPLCs or PLCs)
- LinuxPLC must support multiple logic engines (or languages) and enable integration of
external logic engines (open system)
-Linux PLC must support many locales
Model:
- HMI
- logic engine editors
- logic engines (should be FAST)
- I/O maps (should be FAST)
- I/O drivers (aka I/O scanners): may be FAST
Let me summarize my thoughts about the different components.
Application:
- an application is a set( one or more) of collaborative programs (Logic Engines or programs)
designed for a single application. They will usually be designed by a single programmer or a small group.
- programs in an Application may be asynchronous
Global Input map:
- the global input map is world readable (available to every Application) and writable by I/O drivers
- the input map should support many data types (bit, byte, word, float, string, etc)
Application Input Map
- the input map must support "force" for every data type. Please note that the Global Input Map will not be affected.
Global Output map:
- each Application should have a private Output map. This is not related to I/O racks. Application A may control output1 on module 3 while ApplicationB will control output2 on the same module. It is the I/O driver responsibility to merge info from different Applications before
sending to the actual I/O module.
- the output map should support many data types (bit, byte, word, float, string, etc)
Application Output Map
- each item in the Output map can be "forced", whenever the type.
I/O drivers:
- must be asynchronous (relative to Logic Engines)
- they should collect info from all private Output maps to generate the most efficient messages
- an output point should have only one source (one Application Output Map item per Global item). This should be enforced by the driver. Since the "force" is at the Application level, it would be useless to override it with data from other applications
- they should minimize traffic and enable the option of sending only changed values.
- a specific output may be transmitted to many destinations (many drivers would transmit the same data item to many destinations)
- a specific input (in the global Input Map) must be handled by only one I/O driver)
- a specific I/O driver should be supplied to transmit info from an Application Output Map to the Global Input Map (this will enable a peer communication between Applications)
Application Maps:
- is accessible to HMI to other programs in the same Application)
Simulation
- An Application may have an input simulator (for test purposes) and an output simulator, or both.
- The Application input map should be writable by the simulator
Logic (PLC) engine
- A typical scan would be:
- snapshot from Input Map
- simulator (if required and enabled) to manipulate input values
- real-time logic
- low-priority logic (time-limited)
- update of Application Output Map (transfer from Image Register to AOM)
Gilles
HMI
- can display (chart, report, alarm etc) from data in Global Input Map, Application Output Map, Application Input Map.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
>
> Hi all,
>
> I shall start coding this tomorrow (my personal customers are a bit nervous
> at the moment). I intend to have a working SMM and client API by the end of
> Feb. I'll post results as and when I have them. To recap on my design
> (please correct the things I have missed in my absence!!!):
>
> Config files reside in /etc/puffin. The IO Map is specified in the
> iomap.conf file. I expect this file to just be a set of global
> specifications and a sequence of "include" statements. The actual io point
> specifications being in individual files specified by the include. An io
> point is specified by
>
> <type> <file> : <point> / <element> {persistent | volatile [= <initial
> value>]} <owner>
>
> The SMM is responsable for persistance and handing each client a
> "photograph" of the IO on request. The API is defined as follows:
>
<snip>
Thanks Simon
You summarized your understanding of the huge amount of suggestions we read in the past few weeks. Before you start coding, I suggest we still
discuss about I/O files. From my point of view a file should be a collection of similar objects (aka an array of structures). I fear this will not be in your design. From my point of view, an application program should not care about I/O
addresses. Translation between a virtual I/O and a physical I/O is the chore of the I/O driver.
The application will be easier to understand if the tables are "object-oriented" instead of "type-oriented"
Here is a copy of a draft I wrote many weeks ago (I never sent it).
MANIFEST
Goals
- LinuxPLC must support communication with all actual I/O devices, either local, remote (eg OPTOMUX), through a gateway (a remote CPU, it
may be a PLC), or hierarchy (LinuxPLC would be a master of smaller LinuxPLCs or PLCs)
- LinuxPLC must support multiple logic engines (or languages) and enable integration of
external logic engines (open system)
-Linux PLC must support many locales
Model:
- HMI
- logic engine editors
- logic engines (should be FAST)
- I/O maps (should be FAST)
- I/O drivers (aka I/O scanners): may be FAST
Let me summarize my thoughts about the different components.
Application:
- an application is a set( one or more) of collaborative programs (Logic Engines or programs)
designed for a single application. They will usually be designed by a single programmer or a small group.
- programs in an Application may be asynchronous
Global Input map:
- the global input map is world readable (available to every Application) and writable by I/O drivers
- the input map should support many data types (bit, byte, word, float, string, etc)
Application Input Map
- the input map must support "force" for every data type. Please note that the Global Input Map will not be affected.
Global Output map:
- each Application should have a private Output map. This is not related to I/O racks. Application A may control output1 on module 3 while ApplicationB will control output2 on the same module. It is the I/O driver responsibility to merge info from different Applications before
sending to the actual I/O module.
- the output map should support many data types (bit, byte, word, float, string, etc)
Application Output Map
- each item in the Output map can be "forced", whenever the type.
I/O drivers:
- must be asynchronous (relative to Logic Engines)
- they should collect info from all private Output maps to generate the most efficient messages
- an output point should have only one source (one Application Output Map item per Global item). This should be enforced by the driver. Since the "force" is at the Application level, it would be useless to override it with data from other applications
- they should minimize traffic and enable the option of sending only changed values.
- a specific output may be transmitted to many destinations (many drivers would transmit the same data item to many destinations)
- a specific input (in the global Input Map) must be handled by only one I/O driver)
- a specific I/O driver should be supplied to transmit info from an Application Output Map to the Global Input Map (this will enable a peer communication between Applications)
Application Maps:
- is accessible to HMI to other programs in the same Application)
Simulation
- An Application may have an input simulator (for test purposes) and an output simulator, or both.
- The Application input map should be writable by the simulator
Logic (PLC) engine
- A typical scan would be:
- snapshot from Input Map
- simulator (if required and enabled) to manipulate input values
- real-time logic
- low-priority logic (time-limited)
- update of Application Output Map (transfer from Image Register to AOM)
Gilles
HMI
- can display (chart, report, alarm etc) from data in Global Input Map, Application Output Map, Application Input Map.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc