A
In regard to Curt Wuollet's shared memory and Modbus map posts:
Thanks Curt for getting us started into some concrete details with your posts. I agree with your proposal of shared memory re the NIST information and also don't see a need for use of the ring buffer concept.
In this concept does each type of vendor IO have its own separate shared physical IO memory map? For that matter, should each individual IO device (a physical rack generally) have its own separate map, regardless of vendor?. An alternative could be a more generalized struct of arrays to handle any vendor device but I'm not sure how to implement this given the many differences in IO
modules. Is a linked list an appropriate solution here? There is a lot of auxillary data in modern IO modules beyond just the IO data such as configuration data, status and timestamp that the logic engine needs.
I haven't heard discussion on the subject of how to handle the asynchronous nature of real IO data. I would lean toward the conventional approach of having an intermediate memory map between the device drivers physical IO map
and the ladder logic engine that is updated in full on a periodic basis. I have seen some commercial PLCs that make the machine integrator themselves handle the asynchronous IO data problem (such as AB's ControLogix). Maybe
there are deeper design issues here?
BTW, I haven't used Modicon equipment. Does anyone have some links for Modbus info?
Alan Locke
Controls Engineer, Boeing
"My opinions are my own and not necessarily those of my employer"
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
Thanks Curt for getting us started into some concrete details with your posts. I agree with your proposal of shared memory re the NIST information and also don't see a need for use of the ring buffer concept.
In this concept does each type of vendor IO have its own separate shared physical IO memory map? For that matter, should each individual IO device (a physical rack generally) have its own separate map, regardless of vendor?. An alternative could be a more generalized struct of arrays to handle any vendor device but I'm not sure how to implement this given the many differences in IO
modules. Is a linked list an appropriate solution here? There is a lot of auxillary data in modern IO modules beyond just the IO data such as configuration data, status and timestamp that the logic engine needs.
I haven't heard discussion on the subject of how to handle the asynchronous nature of real IO data. I would lean toward the conventional approach of having an intermediate memory map between the device drivers physical IO map
and the ladder logic engine that is updated in full on a periodic basis. I have seen some commercial PLCs that make the machine integrator themselves handle the asynchronous IO data problem (such as AB's ControLogix). Maybe
there are deeper design issues here?
BTW, I haven't used Modicon equipment. Does anyone have some links for Modbus info?
Alan Locke
Controls Engineer, Boeing
"My opinions are my own and not necessarily those of my employer"
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
