P
Hi,
I'll probably never finish modifying and tweeking modbus_tcp. I have reached a point now where I believe It is possible to start stripping the code into two libraries. One which could be designed as a standard linuxplc I/O interface library and then the other which is the real I/O driver interface which will always be vendor specific.
I think that the code that I have developed is starting to head in the right direction but it is very much modbus_tcp specific which I don't particularly like. I would prefer to have some generic I/O module that then tells external vendor specific real I/O what to do. This would use some standard messaging system between the two processes that hopefully is easy to setup and
understand. (The smm is sort of this I suppose).
Its just that with each I/O module that gets developed, there must be a reasonable amount of code that would be duplicated by each developer. If we can identify what every I/O module developer is going do at the smm end of their
code then we can supply a set of functions for all to use.
we already have plc_update() which is standard for all modules.
we do not have a standard for io_update() or io_in() , io_out() and this is understandable because somewhere inside these functions is where the vendor specific code will probably sit..
<IDEA>
Is it feasible to pass pointers to functions that the vendor must use into io_in() Like.
int io_in( int (*standard_io_in_func)() );
io_in( vendor_read_function );
where vendor_read_function must be structured in a format that is the standard linuxplc I/O format for io_in(). The function that they produce must accept the arguments that we specify but they can do what they want from there.
Does this make sense? :-J
</IDEA>
I'll be OS for a little while but I want to take some ideas with me to think over for when I'm being idle.
Phil.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
I'll probably never finish modifying and tweeking modbus_tcp. I have reached a point now where I believe It is possible to start stripping the code into two libraries. One which could be designed as a standard linuxplc I/O interface library and then the other which is the real I/O driver interface which will always be vendor specific.
I think that the code that I have developed is starting to head in the right direction but it is very much modbus_tcp specific which I don't particularly like. I would prefer to have some generic I/O module that then tells external vendor specific real I/O what to do. This would use some standard messaging system between the two processes that hopefully is easy to setup and
understand. (The smm is sort of this I suppose).
Its just that with each I/O module that gets developed, there must be a reasonable amount of code that would be duplicated by each developer. If we can identify what every I/O module developer is going do at the smm end of their
code then we can supply a set of functions for all to use.
we already have plc_update() which is standard for all modules.
we do not have a standard for io_update() or io_in() , io_out() and this is understandable because somewhere inside these functions is where the vendor specific code will probably sit..
<IDEA>
Is it feasible to pass pointers to functions that the vendor must use into io_in() Like.
int io_in( int (*standard_io_in_func)() );
io_in( vendor_read_function );
where vendor_read_function must be structured in a format that is the standard linuxplc I/O format for io_in(). The function that they produce must accept the arguments that we specify but they can do what they want from there.
Does this make sense? :-J
</IDEA>
I'll be OS for a little while but I want to take some ideas with me to think over for when I'm being idle.
Phil.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc