Hello,

some thoughts on the Great Namer...

Mario has rewritten/suggested the GN to use shared memory rather than sockets, which is probably a good idea - we have the shared memory anyway, might as well use it for everything. Perl can handle shared memory, if we want to keep using it for parsing.

One thing that the Great Namer has to have is per-module configuration. Variables shouldn't be in the config file all in one big list, they should
be divided into sections according to what module they apply to.

That way, we can have two logic engines or two I/O modules of a particular type without their configurations clashing.

Preferably, there should provision for variables to be set not only for a particular module, but also for all modules of a particular type
(basically, defaults). Allowing variables (and points) to be defined in terms of other variables would be good (preferably with fairly late
binding, so that defaults can refer to individualized settings).


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

 

Following up on myself...
> One thing that the Great Namer has to have is per-module configuration.
> Variables shouldn't be in the config file all in one big list, they
> should be divided into sections according to what module they apply to.

It also needs to be able to somehow provide lists of tuples/structs, because I/O modules (and others) will need lists of points with module-dependent *things* with them (physical addresses or whatever).

Physical addresses, unfortunately, can be arbitrarily complicated.

The shared memory will probably end up being a linked list, with relative pointers, to be able to cope with all that.


On a completely different note, I think we should specify UTF-8 encoding for the config. For now, I guess we just discard any character in the range
0x80 to 0xbf and replace any character in the range 0xc0 to 0xfd with a question mark (or underscore), but I think UTF-8 is the way to go.


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

 

Jiri Baum wrote:
> Hello,
>
> some thoughts on the Great Namer...
>
> Mario has rewritten/suggested the GN to use shared memory rather than
> sockets, which is probably a good idea - we have the shared memory anyway,
> might as well use it for everything. Perl can handle shared memory, if we
> want to keep using it for parsing.>

Agree for this pass. Might be a complication later for RT or embedded. Will the owner thing I was hearing about complicate attaching from an
init process?

>
> One thing that the Great Namer has to have is per-module configuration.
> Variables shouldn't be in the config file all in one big list, they should
> be divided into sections according to what module they apply to.>

Yes, and we should think it through well as some of this may endure sucessive passes. I'm still thinking through how we do init and an IO process so we can add devices without destabilizing the code. First pass, we can simply call an init function but, rewriting the IO proc every time we want to add a new IO type is a recipe for headaches.

>
> That way, we can have two logic engines or two I/O modules of a particular
> type without their configurations clashing.>
> Preferably, there should provision for variables to be set not only for a
> particular module, but also for all modules of a particular type
> (basically, defaults). Allowing variables (and points) to be defined in
> terms of other variables would be good (preferably with fairly late
> binding, so that defaults can refer to individualized settings).

I'm still thinking we will need a setup/config so we can show options and pick and choose. It'll save a lot of questions and problems. Maybe something like the new kernel config ESR is working on.
_______________________________________________
LinuxPLC mailing list
[email protected]> http://linuxplc.org/mailman/listinfo/linuxplc

 

Curt Wuollet wrote:
> Agree for this pass. Might be a complication later for RT or embedded.

Well, we are using shared memory anyway for the global map, so that's not going to be a problem.

Perl might be, but if it's really a problem we can have Perl parse the file and write the image to a file (instead of shmem), which can then be loaded by anything.

> Will the owner thing I was hearing about complicate attaching from an
> init process?

Shouldn't; the init process will just have to be the right user (or root). It'll be optional, anyway.

> > One thing that the Great Namer has to have is per-module configuration.
> > Variables shouldn't be in the config file all in one big list, they
> > should be divided into sections according to what module they apply to.

> Yes, and we should think it through well as some of this may endure
> sucessive passes. I'm still thinking through how we do init and an IO
> process so we can add devices without destabilizing the code.

One reason to have separate devices in separate processes...

> First pass, we can simply call an init function but, rewriting the IO
> proc every time we want to add a new IO type is a recipe for headaches.

Definitely. We could have some sort of (semi-) automatic thing writing the relevant list into the IO process source, but it'd still require
recompiling (and restarting the *whole* IO process, rather than just starting the newly-attached device).

> > That way, we can have two logic engines or two I/O modules of a
> > particular type without their configurations clashing.

> > Preferably, there should provision for variables to be set not only for
> > a particular module, but also for all modules of a particular type
> > (basically, defaults). Allowing variables (and points) to be defined in
> > terms of other variables would be good (preferably with fairly late
> > binding, so that defaults can refer to individualized settings).

> I'm still thinking we will need a setup/config so we can show options and
> pick and choose. It'll save a lot of questions and problems. Maybe
> something like the new kernel config ESR is working on.

That'd be good, but designing that right is an order of magnitude harder again than designing a text file right.


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

 

Hello,

here's a quick idea for the syntax of the config file:

Each section begins with a word in square brackets (a la Windows INI), which the name of the module to which it applies. A section may appear any number of times, with the same effect as if the parts were concatenated in one place.

Within each section, the following syntaxes are legal:

word = value
word - word:value...
word value...

(Where "..." indicates repetition.)

"word=value" is the ordinary variable setting. Each variable may only be assigned once (for each module).


"word - word:value etc" is a generic struct; Each field may only be set once, but the whole struct may be repeated any number of times. Eg it might
indicate a hardware point to be driven:
output - name:LiftMotor rack:5 pos:3
output - name:Clamp rack:5 pos:4

The module would get this in an `output' list, and would surmise that the point known to the SMM as "LiftMotor" should be go to rack 5, position 3
and the point known as "Clamp" should go to rack 5, position 4.

The last syntax, "word value etc" is a shortcut for the previous, where the field names have been pre-defined. Thus,
point P0.0 "full name 0" STEPV at 0.0
is a shortcut for (and equivalent to):
point - name0.0 fullname:"full name 0" owner:STEPV loc:0.0

Eventually, there'll be a general mechanism for defining these, for now just "point" and "pt" are predefined.


In the above description, "word" and "value" are either a quoted string, or a sequence of non-whitespace characters with some restrictions. A word (unless it is quoted) is basically a sequence of alphanumerics (with underscores and dots allowed). A value is more relaxed - most punctuation is allowed, though a few are still reserved.


What do you think?

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