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 Gilles

I agree with you description. The SMM does not handle io, as Jiri mentioned yesterday I will change my nomenclature and use data points instead. A data point can be a bit, a byte (8 bits), an word (16 bits), a long word (32 bits), a float (32 bit floating point number), a double (64 bit floating point number). I intend to use the processor for maths handling, so no assumptions must be made about bit ordering in word, long word, float, double, i.e. whether it is big-endian or little-endian.

All bit points will go into one or more point pages, all byte points will go into one or more point pages, etc. Each point page will be at most 4KB long (to coincide with the Linux VM page size).

The IO Map process is responsible for converting data points into IO points and managing the various drivers.

Hope this helps

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

 

Gilles Allard:
> 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.

I would suggest that (as far as the SMM is concerned) a file ought to be just a flat region of memory, addressable down to the bit level.

The SMM shouldn't care what the bits mean.

> 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.

Yes.

> Let me summarize my thoughts about the different components.

I would like to simplify things a bit - I think what I'm about to write is equivalent to what you wrote, there's just fewer kinds of component to
worry about.

There are no designated "inputs" or "outputs". The manuals and user interfaces may use these words (see below), but they are labels
insignificant to the core of the linuxPLC (puffinPLC?). The core deals only with "points".

Application:
- consists of several tasks
- each of these tasks has some specialized function (I/O driver, logic engine, HMI), but from the point of the core they behave identically
- there may be any number of any kind of task, or none.
- an application may have several variants which differ in configuration, the mix of tasks, etc, but are still essentially the same application.

The global map:
- the global map is world readable (available to every task).
- the map directly supports only bits (called "points"); but in such a way that any sized data type can be handled (certainly bits, bytes, playtes and dynners, non-round multiples of bytes, perhaps also crumbs and nybbles).
- only one task has write permission to any particular point (WDIL: semaphore-based write permission).

The private maps:
- each task has a copy of the global map (possibly partial).
- at start and then whenever the task requests, the private map is updated to the current values in the global map.
- whenever the task requests, the values in the private map for the points to which the task has write access are copied into the global map.


Forces: this is not yet decided. They may either be handled in the I/O drivers or as the global map is being copied into the private maps. Both
possibilities have their advantages and proponents.

> I/O drivers:
> - must be asynchronous (relative to Logic Engines)

Yes. (Most of what you wrote I agree with; I'm just picking out items for emphatic agreement.)


Here are the words I dismissed earlier...

"I/O driver" is a task that communicates with a physical I/O device, either directly or via a bus or network.

"inputs" are points for which write permission is normally held by an I/O driver. (Any other task writing such points is termed a "simulator".)

"outputs" are points which are normally copied onto physical outputs by an I/O driver.

Note that in some applications, a point may be both an input and an output. Such applications are called "traffic cop". A point may also be an output several-fold (copied onto several physical outputs).

"internal coils" are any non-input, non-output points used as individual bits (rather than part of some larger data structure).


What do you think?

Jiri
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Hi Jiri and Simon and everybody!

I'm glad we agreed on these concepts.

I suggest that, to reduce risk of confusion caused by different terminologies, we create a lexical (a dictionary of all special terms we
will use during the design and documentation phases). Can a member of this group volunteer? (I can't since I'm not really fluent in English)

Concerning your reply, I still have a few remarks to add.

Jiri Baum a écrit :
< large interesting snip>
>
> Forces: this is not yet decided. They may either be handled in the I/O
> drivers or as the global map is being copied into the private maps. Both
> possibilities have their advantages and proponents.
If the "force" is used for debugging or to temporarily fix a bug, then
it would be better to implement it at the "private map" level. If the
"force" is used to replace a missing or defective sensor then it would
be better to implement it at the "global map" level. Both are useful. If
we have to implement it at only one level, my personal choice would the
"private map"; that would enable debugging of one application while the
others continue to use the real (field) input.

> "I/O driver" is a task that communicates with a physical I/O device, either
> directly or via a bus or network.
I think we should enlarge the concept (exclude the word physical). A
LinuxPLC output can be a PLC internal coil; this would enable us to
design a hierarchy of PLCs
>
> "inputs" are points for which write permission is normally held by an I/O
> driver. (Any other task writing such points is termed a "simulator".)
Similar to "force". A simulator should act on the private map. That
would enable debugging of one application while the others continue to
use the real (field) input.
If the simulator is at the "global map" level, this implies there is
only one simulator for the whole system, or, if using many simulators,
we have to define which one can modify a specific data point.
>
> "outputs" are points which are normally copied onto physical outputs by an
> I/O driver.
Remove "physical", and then we agree.
>
<snip>
> What do you think?
> Jiri

I feel enthousiasm.
Gilles

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Gilles Allard:
> I suggest that, to reduce risk of confusion caused by different
> terminologies, we create a lexical (a dictionary of all special terms we
> will use during the design and documentation phases). Can a member of
> this group volunteer? (I can't since I'm not really fluent in English)

Sounds like a good idea.

Maybe I should volunteer, but then again maybe I have too great a propensity toward abstract and obscure definitions

> Jiri Baum a écrit :
> < large interesting snip>

> > Forces: this is not yet decided. They may either be handled in the I/O
> > drivers or as the global map is being copied into the private maps.
> > Both possibilities have their advantages and proponents.

> If the "force" is used for debugging or to temporarily fix a bug, then it
> would be better to implement it at the "private map" level.

Oops, that's a *third* option yet - private forces.

The distinction I was talking about was whether forces are applied in the I/O drivers (for outputs, invisibly to any other task), or whether they are applied in the global map (visible to all tasks). This is a significant difference - for instance if outputs have explicit latching on them.

I don't think private forces justify the conceptual complexity they would engender. OTOH, if the forces are applied as the global map is being copied, then private forces will be easy to add later if we want them.

> If the "force" is used to replace a missing or defective sensor then it
> would be better to implement it at the "global map" level. Both are
> useful. If we have to implement it at only one level, my personal choice
> would the "private map"; that would enable debugging of one application
> while the others continue to use the real (field) input.

I think we have a terminology slippage between "application" and "task".

That said, though, if we have forces applied at the point where the global map is being copied into the private map, it's easy enough to MIAO.

> > "I/O driver" is a task that communicates with a physical I/O device,
> > either directly or via a bus or network.

> I think we should enlarge the concept (exclude the word physical). A
> LinuxPLC output can be a PLC internal coil; this would enable us to
> design a hierarchy of PLCs

The word physical was intended to apply more to "device" than to "I/O", but that's not really important. Since these are intended merely as human labels with zero significance to the core, the precise definition is merely a matter of convenience.

> > "inputs" are points for which write permission is normally held by an I/O
> > driver. (Any other task writing such points is termed a "simulator".)

> Similar to "force".

Oh, you're thinking of it differently than me. Doing the simulation by forcing rather than accessing the points in the ordinary way. That might be useful occasionaly, but I think most of the time the latter will be better. (You don't need a special tool for it; the simulator can be written using any of the available programming languages - stepladder, state, whatever.)

> A simulator should act on the private map. That would enable debugging of
> one application while the others continue to use the real (field) input.

You should probably *not* be doing debugging on the production machine. Certainly not against a simulator - if you have a simulator, you should do
your debugging on a different box.

> If the simulator is at the "global map" level, this implies there is only
> one simulator for the whole system, or, if using many simulators, we have
> to define which one can modify a specific data point.

I was thinking a simulator would simply be another task, equal to all the others; simply instead of loading the I/O driver(s), you would load the simulator(s).

> > "outputs" are points which are normally copied onto physical outputs by
> > an I/O driver.
> Remove "physical", and then we agree.

Yeah, but then it's vacuous. You are right, an I/O driver can affect the internal coil of another PLC, but:
- some (not me) would argue that's not a real output
- some would argue that it *is* an output, just mediated
- others would call it something else (quasi-output, request, signal, flag)
Maybe best to leave the definition as is, and wait for usage to decide between the three possibilities. Again, it doesn't matter to us; outputs are basically whatever the end-user thinks of as outputs.


Jiri
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc