SMM ready

J

Thread Starter

Jiri Baum

Hello,

the SMM is ready for use.

Well, enough of it is implemented that it can be used, anyway. Probably the biggest limitation right now is that it can only handle 1-bit-wide points. In other words, relays only; no data registers. Maybe next week :)

All points must be listed in the linuxplc.conf file. The syntax is:

point ID "full name" owner at x.y

where:
- point - the word `point' (or `pt' for short)
- ID - name, eg X75, Q03, etc. (btw, what formats should we
support?)
- full name - human name of the point (in quotes)
- owner - module with write access to that point
- at - the word `at'
- x.y - physical address in the global map in the format word.bit,
eg 3.1, 2.31, 57.12 etc. Bit numbers are 0-31.

Eg:

point X75 "sample point" foo at 3.1

See smm/test/linuxplc.conf for another example.

(The other syntax is `variable=value' for setting option values.)

Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

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

Johan Bengtsson

Good!

What formats we should support: is there any reason for the system to have any kind of idea about that? Let the user name the points to whatever names and formats they like best.


Keep up the good work!


/Johan Bengtsson

----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
[email protected]:
[about point names]
> What formats we should support: is there any reason for the system to
> have any kind of idea about that? Let the user name the points to
> whatever names and formats they like best.

Yes. I was thinking whether it needs to allow colons or slashes or something (for N:1/57). Right now it's letters, digits and underscores.


Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

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

Johan Bengtsson

Ok, I would suggest all characters >32 or <0, easy to code and noone missing their favorite characters. <0 might not really be necesary, but why exclude them?

/Johan Bengtsson

----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
J
Is there a length limit on "full name"?

-> point ID "full name" owner at x.y
->
-> where:
-> - point - the word `point' (or `pt' for short)
-> - ID - name, eg X75, Q03, etc. (btw, what formats should we
-> support?)
-> - full name - human name of the point (in quotes)
-> - owner - module with write access to that point
-> - at - the word `at'
-> - x.y - physical address in the global map in the
-> format word.bit,
-> eg 3.1, 2.31, 57.12 etc. Bit numbers are 0-31.
->
-> Eg:
->
-> point X75 "sample point" foo at 3.1

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Jansen, Joe:
> Is there a length limit on "full name"?

At present it's not used for anything, so no, there isn't.

Hopefuly if/when there is a limit, the full name will simply be truncated to fit when necessary, so there's no limitation on its natural length.

> -> point ID "full name" owner at x.y

Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

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

Curt Wuollet

Hi Jiri, Johan

Something I'm missing.... Your config file relates a bit of an int in memory to a name. Wouldn't we want to relate that to a particular physical input or output at the same time? Or are you thinking of a parallel map? Should we
relate a pin to a name or to a bit in memory. There has to be a tie someplace. Are you planning on the great namer dealing with this also? I would think we have to allow arbitrary assignments there as well.

cww

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

Johan Bengtsson

I think that have to be a parallel map actually defining what I/O processes to have and what points they should each handle.

/Johan Bengtsson

----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

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

Gilles Allard

Hi Jiri!
I'm glad we move.
Can I suggest that your physical adresss (the x.y field) may be segmented into three parts (eg dd:n.aa:x.y)

dd would be the name of a driver (a protocol handler) n would be a network port (may be serial,parallel or Ethernet. We need some
nomenclature here) nn would be an address on the network x.y would be word.bit as you proposed.

There should be a warning:
driving a bit in a word is only possible if all bits are driven from a common source.
How can you set a bit in a word if the protocol does not support bit setting? (many PLC protocols do not). If you update a word with a new value for a bit, how do you know that other bits have not been changed by other sources (eg PLC)?

My wishes for phase 2:
There should be a way to put a "mapped structure" or "structure in the map". For example, if I wan't to send a recipe (a structure), I do not want to specify the address of all components (members). In phase whatever, we may want to send complex structures (objects). How will we set the syntax for that address.

Cooperatively your's
Gilles

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Curt Wuollet:
> Something I'm missing.... Your config file relates a bit of an int in
> memory to a name. Wouldn't we want to relate that to a particular
> physical input or output at the same time?

No, because:
- some points aren't tied to any physical I/O (internal coils) and
others may be tied to more than one physical I/O (traffic cop)
- format of physical I/O addresses depends on the I/O process

> Or are you thinking of a parallel map?

I was assuming that it would be part of the configuration of each I/O process, just like which points a logic engine reads and writes is part of its program.

There may even be quasi-physical I/O, such as `emulate an XY-brand PLC on the fieldbus', where it's not really I/O, but (if there's something else on the bus that'll read the exported `internal' coils) still affects the Real World. Now do you call that I/O?

> Should we relate a pin to a name or to a bit in memory.

To a name, definitely. For one thing, the I/O process must interface with the SMM which wants the name, for another the bit in memory is a bit too low-level for me.

> Are you planning on the great namer dealing with this also?

Probably, though - as I wrote - I'm not all that proud of it; if someone has a better idea go ahead. (Let me know so I stop maintaining GN.)

> I would think we have to allow arbitrary assignments there as well.

I'm not sure what limitations you were thinking of, but `allow arbitrary assignments' sounds good.


Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
[email protected]:
> Ok, I would suggest all characters >32 or <0, easy to code and noone
> missing their favorite characters.

Well, we really would want to reserve some characters for syntax...

> <0 might not really be necesary, but why exclude them?

Because they don't have standard meanings? (Some of them aren't even easily printable.)

Remember, these aren't the human names, these are identifiers in a program. We should restrict them to ASCII, unless/until we want to do Unicode.


Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

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

> Can I suggest that your physical adresss (the x.y field) may be segmented
> into three parts (eg dd:n.aa:x.y)

The `physical address' is just the address in the global map.

Sorry, that was probably poor phrasing on my part.

The physical I/O address(es) (if any) will be specified separately.

> dd would be the name of a driver (a protocol handler)
> n would be a network port (may be serial,parallel or Ethernet. We need some
> nomenclature here)
> nn would be an address on the network
> x.y would be word.bit as you proposed.

I think the syntax should depend on the driver itself. Some drivers need network ports, some need IO addresses, some need strange and wonderful
setup. No way are we going to put all that into a uniform syntax.

> There should be a warning: driving a bit in a word is only possible if
> all bits are driven from a common source.

Yes, some I/O processes will have that limitation.

> My wishes for phase 2:
> There should be a way to put a "mapped structure" or "structure in the
> map". For example, if I wan't to send a recipe (a structure), I do not
> want to specify the address of all components (members). In phase
> whatever, we may want to send complex structures (objects). How will we
> set the syntax for that address.

As long as the structure is fixed-size, no problem.


Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

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

Johan Bengtsson

Isn't space and tab enough of separators for the syntax?

ok, skip the <0 part, but I don't see any reason to exclude anything in the range >32, except perhaps "

/Johan Bengtsson

----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
[email protected]:
> Isn't space and tab enough of separators for the syntax?

Yes, but we'll be able to design nicer syntax if we leave ourselves some room.

For instance, we might want to have comma-separated arguments somewhere, or things in brackets.

> ok, skip the <0 part, but I don't see any reason to exclude anything in
> the range >32, except perhaps "

And backslash.

Brackets might be good to exclude on the grounds that if they're unbalanced they'll give us trouble.


Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

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