I have noticed that it takes about 100ms before a message sent by the device is matched on the element. The response does not have a trailer, but the third and fourth byte contain the size of the payload, so the driver uses:
communicationOptions="makeCommandByProtocol;packetInfo:2,2,false"
As the size of the response is known, there shouldn't be any significant delay.
The following parameters make up the response:
<Param id="2"> <Name>IpHeader</Name> <Description>IP Header</Description> <Type>fixed</Type> <Interprete> <RawType>other</RawType> <Type>string</Type> <LengthType>fixed</LengthType> <Length>2</Length> <Value>0x000x0C</Value> </Interprete> </Param>
<Param id="3"> <Name>CommandLength</Name> <Description>CommandLength</Description> <Type>length</Type> <Interprete> <RawType>unsigned number</RawType> <Type>double</Type> <LengthType>fixed</LengthType> <Length>2</Length> <Endian>big</Endian> </Interprete> <Length> <Content> <Param>2</Param> </Content> </Length> </Param>
<Param id="5"> <Name>Response</Name> <Description>Response</Description> <Type>read</Type> <Interprete> <RawType>other</RawType> <Type>string</Type> <LengthType id="3">other param</LengthType> </Interprete> </Param>
100ms doesn't sound like much, but the device does not support any bulk commands, so this 100ms adds up quickly when I need to retrieve data for over 1000 parameters.
I created a small driver and console application as tcp server to reproduce the result. The element and console application ran on the same server to eliminate network latency and system clock differences.
These are log lines from the application and element respectively:
2022/01/06 11:51:11.601 Send: Packet 3
2022/01/06 11:51:11.700|SLProtocol - 9816 - latencyTest|22476|CParameter::MatchParameter|DBG|2|-> Response new data (Packet 3) 000000 5061636B65 742033 Packet 3
What could reduce this delay?
Do you have a way to build a simple application in Python or another language that could replicate a serial command and receive and log the response to validate that the unit itself is not responsible for a substantial portion of this delay?
Hi Michael
Fortunately, the device did have a desktop application.
With Wireshark I was able to confirm it uses the same API and was able to manage up to 5000 packet transfers per second.