Great Namer

J

Thread Starter

Jiri Baum

By the way...

I'm not all that proud of the Great Namer (smm/gn-mgr); certainly it'll at least need a re-work, maybe scrap it altogether.

If anyone has any better idea of how to read the configuration (including point assignments), pass it on...


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

Just a suggestion: It would be great if people didn't need advanced Perl skills to hack it. We may need an in-core table to support the traffic. If we have a setup/configuration utility we can use a non-text file that will be much easier to parse and easier to use as
well (no editing errors) Then just load it on init?. The Perl socket stuff is pretty cool though. I think the point config may be a bit to
complex (error prone) to do with a text file. We can have the util dump an ascii map for reference. What do you think?

Regards,

cww


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Curt Wuollet:
> Just a suggestion: It would be great if people didn't need advanced Perl
> skills to hack it.

Yes - I'll try to keep it comprehensible to C people...

(Because doing text-parsing in C is just a pain.)

> We may need an in-core table to support the traffic.

Well, the current gn-mgr does keep it in a table in memory.

> If we have a setup/configuration utility we can use a non-text file that
> will be much easier to parse and easier to use as well (no editing
> errors)

Text configs are a great Unix tradition :)

I don't think we'll be ready to design a configuration file-format any time soon, and with text-based it's easier for it to grow as needed...

> The Perl socket stuff is pretty cool though. I think the point config
> may be a bit to complex (error prone) to do with a text file. We can have
> the util dump an ascii map for reference. What do you think?

Yes, it probably would be a good idea to give some sort of trace of what was loaded - no problem. Just make it an extra routine in gn-mgr, and make a short script that connects to the gn and dumps it. (I already have a debugging script, anyway - did I check it in?)


> Jiri Baum wrote:

> > I'm not all that proud of the Great Namer (smm/gn-mgr); certainly it'll
> > at least need a re-work, maybe scrap it altogether.

And clean up the code so it's comprehensible.


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

OK, I'm not going to be religious about it, I think we'll need to do it for the I/O setup and we can look again then. In the meantime can I see
your demo config file, It's really tough trying to figure out what it looks like from the code and it's hard to follow without values.

Regards

cww


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Curt Wuollet:
> OK, I'm not going to be religious about it, I think we'll need to do it
> for the I/O setup and we can look again then. In the meantime can I see
> your demo config file, It's really tough trying to figure out what it
> looks like from the code and it's hard to follow without values.

Oops, sorry, I should have written that somewhere.

At present, it recognises two line formats:

variable = value
include "filename"

The value may optionally be in quote marks, but they only need to be used to protect leading and trailing spaces. Circular includes are handled
properly. Comment marker is hash (#), line continuation is backslash (\).

Example config might be:

#sample config
shm_key=42
shm_pages=64
sem_key=42


Obviously, there's a lot of things that aren't done yet.

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

Jiri Baum wrote:

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