Lookout

cancel
Showing results for 
Search instead for 
Did you mean: 

integer vs. bits communications load

This is a re-post of a question from a reply to a previous issue.

Can anyone comment on the communication load a driver object endures when reading blocks of integers vs. blocks of bits? For example, is the load the same if reading 10 integer values vs. 160 bit values (assuming all memory is contiguous)? How would this degrade if the blocks were not contiguous? I am trying to evaluate how to design my application. I/O count is not an issue, will be using an unlimited license. But in either case there will be a high I/O count (estimating 3000+ points), to be scanned every 3 seconds via TCP/IP to a Siemens PLC, and I am trying to evaluate how best to minimize the communications load.

Thanks for any help.

0 Kudos
Message 1 of 3
(3,237 Views)

Here's whatever little I know..

Firstly, not all Lookout drivers have the same architecture, i.e., some driver Objects do single reads, some do reads in blocks, etc.  This mainly depends on the communication protocol.  I believe Lookout developers have tried to employ the best strategy for the given protocol. 

I a not sure about integer versus bits, but reading contiguous versus non-contiguous data will definitely make a difference (again, depending on the protocol -- but most do support this feature).  For instance, with a single read query, you can request a bunch of contiguous Modbus registers (by specifying the starting address and ending address along with the function code in the Modbus message frame).  If the data wasn't contiguous, we would need a single query for each register read! 

Lookout, as I mentioned earlier, tries to be as smart as it can.  If the data being read is not contiguous but still close to each other, Lookout goes ahead and does a block read for that range of registers.  It then throws away the data which wasn't requested. 

If you have an easy way of parsing out the bits from integer data, it makes sense to read integers versus bits -- just a pure guess though.

For your particular driver Object, you can test the communication for registers versus coils, and contiguous versus non-contiguous by monitoring the Serial/Ethernet traffic.  There are some very nice tools out there for doing this.  I personally like Portmon and TDIMon from Sysinternals (http://www.sysinternals.com). 

Hope this gives you some ideas.  Disclaimer: I don't claim ALL Lookout driver objects behave the way I described.. please don't sue me  Smiley Very Happy

-Khalid

Message 2 of 3
(3,226 Views)

Wanted to add one point about setting up communication for large number of IO points:  rather than polling all the points at the same rate, use multiple driver Objects (thru' the same port/address) but with different polling rates.  Group tags which do not need to be polled faster (temperature data, e.g.) and use an Object with a slower poll rate for these. 

-Khalid

0 Kudos
Message 3 of 3
(3,223 Views)