Created Date: October 03,2016

Created By: jvian

**** This post has been imported from our legacy forum. Information in this post may be outdated and links contained in the post may no longer work.****

Can anyone help clarify how exactly the DoMore driver behaves in Point of View in comparison to other drivers? What I am looking for is clarification as to how the standard driver sheets work without a "Header " field being required. I have developed an application in Point of View which currently is communicating with an Allan Bradley SLC500 using the ABKE driver. I have spent a good deal of time optimizing communications by using multiple standard driver sheets with specific memory blocks defined in the AB PLC program such that I was always using "sequential blocks " and I split blocks up as necessary over multiple driver sheets to avoid any communication errors caused by exceeding the driver block limits. This was all fairly straight forward and all this information (block size etc.) was provided in the ABKE driver documentation. Now trying to use the same POV application with a DoMore PLC, the path is a little less clear. I have seen no reference to block size limits or "sequential blocks ", and the standard driver sheets do not require a "Header " field. So I could easily mix B/N/V/R etc. data types within a given driver. This seems very appealing and would give me great flexibility, but I am skeptical that this is too good to be true. Imagine a standard DoMore driver sheet was created to read at a timed interval with a mix of say N0-N10, N50-N60, and N100-N110 addresses. This range has "gaps " and traditionally (as with the ABKE driver) this would be very poorly done as the driver would request N0-N110 including all of the elements in between the ranges specified. Does the DoMore have this same limitation? Now I really get confused when I think of whats happening when a standard DoMore driver sheet is requesting N5, N10, R5, R10, and D5, D10 addresses at the same time. Ultimately I am required to squeeze every bit of communication performance out of my drivers to optimize my runtime performance of my application. If anyone has any insight as to how the DoMore driver operates and/or what its limitations are, I would love to learn more. I'm sure I know how to get where I need to be, but any shortcuts created by this potential driver flexibility would be incredibly useful. -J-