M
Jiri and all,
Now that I have written a couple of io modules I think I have started to understand the issues involved. I would say that almost 50% of the
effort goes into parsing the config file for the io mapping parameters, i.e. the io mapping table.
Issue 1
-------
Is there any way we could abstract this away and make it common to all io modules? This would also make all io modules more coherent when it
comes to configuring them... For example, I added an invert option to the parport module that tells the module to invert the linuxplc point before copying to the parallel port (or vice-versa). I think all io modules should probably also support this. This is an example of what could be placed in the common library. Maybe we could even write a
complete abstract io module, with some callbacks to:
init()
this would read and parse module specific config data, such as io base address, IP address, etc...
parse_point()
this would parse the module specific parameters to to a specific point, this would be called for every line in the io mapping table...
read_point()
read a point from physical io
write_point()
write a point to physical io
close()
any cleanup that the module may have to do before terminating.
To write a module, the author would only have to write the above five functions, and presto, the module was ready to go. Like this he could
concentrate on the specific physical io details, and not have to spend time re-doing all the boring stuff related to interfacing with the
linuxplc.
Maybe this would not be enough for every type of io module, but for those for which it isn't, then the module can always be coded from scratch, using the linuxPLC library API.
|--------------------|---------|
| IO module 1 | io 2 | io |
|--------------------| module |
| Generic io module | 3 |
| API | |
|------------------------------|
| linuxPLC library API |
|------------------------------|
Issue 2
-------
For logic type modules, these will have many scratch variables that maybe don't need to be interfaced to any other module. This raises the
'philosophical' question of whether these variables should be mapped onto linuxplc points.
Take the iec compiler for example. We can take the route of (a) having every Mx.y 'variable' be a linuxplc point, which means they all have to
be configured, or (b) we can choose to assume that this memory is private to the iec logic module, and only explicitly configured memory
locations would be mapped onto linuxplc points.
Which is the correct way to go? I think we really must discuss this now. It will influence how the memory manager (a.k.a. the smm, which
actually is now called the gmm in the library) will be coded, and what types of linuxplc points will be supported.
I wanted to start tackling online configuration changes, but I feel we should lay the ground rules for this first, before charging into
something that would probably have to be changed later.
Just throwing some ideas around... ;-)
Cheers,
Mario.
--
----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
Now that I have written a couple of io modules I think I have started to understand the issues involved. I would say that almost 50% of the
effort goes into parsing the config file for the io mapping parameters, i.e. the io mapping table.
Issue 1
-------
Is there any way we could abstract this away and make it common to all io modules? This would also make all io modules more coherent when it
comes to configuring them... For example, I added an invert option to the parport module that tells the module to invert the linuxplc point before copying to the parallel port (or vice-versa). I think all io modules should probably also support this. This is an example of what could be placed in the common library. Maybe we could even write a
complete abstract io module, with some callbacks to:
init()
this would read and parse module specific config data, such as io base address, IP address, etc...
parse_point()
this would parse the module specific parameters to to a specific point, this would be called for every line in the io mapping table...
read_point()
read a point from physical io
write_point()
write a point to physical io
close()
any cleanup that the module may have to do before terminating.
To write a module, the author would only have to write the above five functions, and presto, the module was ready to go. Like this he could
concentrate on the specific physical io details, and not have to spend time re-doing all the boring stuff related to interfacing with the
linuxplc.
Maybe this would not be enough for every type of io module, but for those for which it isn't, then the module can always be coded from scratch, using the linuxPLC library API.
|--------------------|---------|
| IO module 1 | io 2 | io |
|--------------------| module |
| Generic io module | 3 |
| API | |
|------------------------------|
| linuxPLC library API |
|------------------------------|
Issue 2
-------
For logic type modules, these will have many scratch variables that maybe don't need to be interfaced to any other module. This raises the
'philosophical' question of whether these variables should be mapped onto linuxplc points.
Take the iec compiler for example. We can take the route of (a) having every Mx.y 'variable' be a linuxplc point, which means they all have to
be configured, or (b) we can choose to assume that this memory is private to the iec logic module, and only explicitly configured memory
locations would be mapped onto linuxplc points.
Which is the correct way to go? I think we really must discuss this now. It will influence how the memory manager (a.k.a. the smm, which
actually is now called the gmm in the library) will be coded, and what types of linuxplc points will be supported.
I wanted to start tackling online configuration changes, but I feel we should lay the ground rules for this first, before charging into
something that would probably have to be changed later.
Just throwing some ideas around... ;-)
Cheers,
Mario.
--
----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc