I am currently mucking around getting serial modbus RTU traffic going from an rs485 device.
I notice that there is no modbus response code processing - like at all - and hence no capability for error notification.
It seems to me that each modbus requestor should have, at minimum, an UP/DN status indication based on the last message and ideally an averaged aggregated UP/DN status for each device - based on IP and/or ID
Even better would be for the modbus error message to be either retained, or else processed and the associated error code retained so that one knows _why_ the transaction failed.
I know on the other modbus devices I implement I always show the error codes to aid in troubleshooting.
I have been farting around with configuring the RS485 as OverIP , server/client and as Modbus gateway...
most of my initial attempts resulted in no response from the device at all (those should show up as timeout errors)
my latest attempts, as monitored using modbusPoll/mosbusSlave have shown that the responses produce responses from the device, but no resultant data transfer.
My suspicion is that when using the Test function to verify data transfers, it does not actually initiate a new message to the device,
it simply examines the internal structures associated with each modbus requestor and shows the data stored (or not) by the last transaction.
The message "unexpected length" is quite a useless message. At minimum the actual length of the received response should be shown.
Is the length 0? is it too short ? Is it too long ?
I know that in the past I have used a vlinx modbus gateway to enable an RTU master telemetry device to poll data from a TCP slave device (PLC)
I am trying to do the inverse of that as a test - in case the RUT955 cannot correctly poll modbus data from a direct-serial-RS485 connected slave device - maybe I need to use the vlinx as a gateway-crutch.
So far, initial attempts have not succeeded in polling the device from a TCP master...
