FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

14455 questions

17168 answers

28195 comments

0 members

We are migrating to our new platform at https://community.teltonika.lt. Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
0 votes
371 views 2 comments
by anonymous
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...
by anonymous
Running a large fleet of RUT955s, also doing ModBus/RTU, via built-in RS485 interface. However, because of using official openwrt, and custom programming/image (private LUA code used for ModBus), no problem to get error codes (i.e. "No reponse to poll" etc.).

Only reasonable for industrial, mass installs, of coure.

1 Answer

+1 vote
by anonymous
Hi,

The latest firmware version should provide a little more information regarding Modbus errors.

The test function does send a command. You can try this by configuring Master to query the slave device at long intervals, then change the values on the slave and request them before the Master sends requests automatically. Essentially, the moment you change the register value, you can obtain it via 'test' functionality. The same when you write to a register.

Anyways, thank you for your feedback. I will forward your feedback and inform the development team that clients are looking for more informative Modbus error messages.

Kind Regards,

Andzej
by anonymous
Yes, thank you
I noticed that the latest firmware reports on the modbus error response
Previously the message just said something about "inappropriate message length" and that was it.
Now for example if the client sends back "illegal address" code 83 the RUT will reflect that in the error message