M
Hi all,
Like Jiri, I didn't like the idea of a great namer (gn), so I got to hacking the smm code a little.
I have submitted the changes I made to Jiri, but it seems he hasn't much time available to check them out.
Basically, this is what I did:
a) all functions returning void now return an int
0 for success, -1 on error
b) the gn has disappeared. This is replaced by a second shared memory area where the plc configuration is stored.
All modules access the conf. area directly through the smm and confmap (configuration map) managers.
c) The globalmap remains as it was.
d) I have added a whole set of options to the smm-mgr that now allows it to startup and shutdown the plc. It can also dump the configuration data stored in the confmap, and dump it's interpretation of the linuxplc.conf file.
e) I created a very simple test program to test the plc. With it we can set, get, and reset points. The -m option controls the module name with which it will connect to the plc.
f) I added a new plc_init_opt(...) function to the smm.h interface. This function accepts (int argc, char **argv) arguments inside which initialization options can be passed.
If a program (like the test program) passed its command line options to this functions we can control how the plc is initialised using command line options.
The main options allowed are --PLClocal (default behaviour) and --PLCisolate.
--PLCisolate allows the module connecting to the plc to become completely isolated from the globalmap. This protects the globalmap from becoming destroyed by any stray pointer the module program may have. This is accomplished by having a second process (automatically launched) doing the synchronisation between the global and local maps. The module does not attach the globalmap memory area.
--PLClocal has the module attach both the configuration and globalmap memory areas. This is dangerous for poorly tested modules as these may destroy the data in the globalmap un-intentionally through stray pointers. The data may even be related to another module which may then not behave properly.
The code is not very clean. Especially the code used for reading the linuxplc.xonf file. This is just a quick hack to make it usefull. The plc cleans up after itself if all goes well. I still
need to write the cleanup code in case anything goes wrong during initialisation. It shouldn't be too difficult. I have the structure waiting for it. I jus think it would make more sense to put
out the code to see what you all think before I spen any more time hacking out something nobody is interested in.
I don't know what to do with this code. If anybody is interested please suggest a way for me to make it available.
Best regards,
Mario.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
Like Jiri, I didn't like the idea of a great namer (gn), so I got to hacking the smm code a little.
I have submitted the changes I made to Jiri, but it seems he hasn't much time available to check them out.
Basically, this is what I did:
a) all functions returning void now return an int
0 for success, -1 on error
b) the gn has disappeared. This is replaced by a second shared memory area where the plc configuration is stored.
All modules access the conf. area directly through the smm and confmap (configuration map) managers.
c) The globalmap remains as it was.
d) I have added a whole set of options to the smm-mgr that now allows it to startup and shutdown the plc. It can also dump the configuration data stored in the confmap, and dump it's interpretation of the linuxplc.conf file.
e) I created a very simple test program to test the plc. With it we can set, get, and reset points. The -m option controls the module name with which it will connect to the plc.
f) I added a new plc_init_opt(...) function to the smm.h interface. This function accepts (int argc, char **argv) arguments inside which initialization options can be passed.
If a program (like the test program) passed its command line options to this functions we can control how the plc is initialised using command line options.
The main options allowed are --PLClocal (default behaviour) and --PLCisolate.
--PLCisolate allows the module connecting to the plc to become completely isolated from the globalmap. This protects the globalmap from becoming destroyed by any stray pointer the module program may have. This is accomplished by having a second process (automatically launched) doing the synchronisation between the global and local maps. The module does not attach the globalmap memory area.
--PLClocal has the module attach both the configuration and globalmap memory areas. This is dangerous for poorly tested modules as these may destroy the data in the globalmap un-intentionally through stray pointers. The data may even be related to another module which may then not behave properly.
The code is not very clean. Especially the code used for reading the linuxplc.xonf file. This is just a quick hack to make it usefull. The plc cleans up after itself if all goes well. I still
need to write the cleanup code in case anything goes wrong during initialisation. It shouldn't be too difficult. I have the structure waiting for it. I jus think it would make more sense to put
out the code to see what you all think before I spen any more time hacking out something nobody is interested in.
I don't know what to do with this code. If anybody is interested please suggest a way for me to make it available.
Best regards,
Mario.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc