Question

We currently have a setup were we have a TRB140 reading out modbus TCP data from a third party device. When we test the modbus requests in the WebUI we consistently get values around 230 (we read out voltage data floats). We want to send this data with Data to Server to our server.

With the TRB140 the data we receive ranges from 0 to absurd large negative or positive numbers but never consistently within our expected ranges.

We also got a TRB255 from which we consistently receive data within the expected ranges. We have checked all configurations between the TRB255 and TRB140 and notice that the only difference is the firmware version where the TRB255 is running on TRB2_R_00.02.06.1 and the TRB140 is running on TRB1_R_00.02.06.1 both downloaded from their own firmware release page.

Our Data to Server configuration is the following :
Data source: Modbus data
Protocol: HTTP(s)
JSON format: {"TS": "%t", "D": "%d", "data": %a}
Segment count: 1
Send as object: on
Data filtering: All data
Retry on fail: on
Use TLS: off
Custom Header: Content-Type: application/json

We also have configured an URL and one more additional header.

We would like to know if a configuration on our side could cause this problem.

Comments

I have just noticed something similar.
I am using the RUTX11.

I have set up the MODBUS master and slave.
And have set up the "Data to Server" function to send the MODBUS data to an MQTT broker.

The MODBUS registers containing INT, ASCII data are being received by the MQTT broker correctly but any 32 bit FLOAT data has the byte order reversed.

When testing the modbus config in the MODBUS MASTER setup, each entry works correctly. In my case I'm sending GPS lat, long, and a few others which are 32 bit int and set to byte order 1,2,3,4.

If I set up the modbus master to the reverse byte order 4,3,2,1 then the MQTT gets the correct float values, but the browser test screen has the wrong values.

So this is certainly a bug.

Answer 1

Hello,

As far as I understood, the modbus request in the WebUI is right, but the data to server is sending corrupted data?

How are you getting the data? From server side? Did you test a TCP server like Hercules, beeceptor or some app like that?

Did you restore the device to the default settings to avoid any other configuration that can be affecting this service?

Comments

Hi,

Thanks for your reply. We validated through an AWS Lambda which just prints the JSON as plain text. To be absolutely sure we did the same with Beeceptor and see the same results. Also we restored the device to factory default with only this config to make sure nothing affects this device. Weird thing is when we do exactly the same steps (from factory default) with the TRB255 it works as expected.

Here some more details. 

We got the TRB140 attached to a Modbus slave device which is configured as follows:

 

As you can see when we request a value from U_L1 we read out a value of around 230 (voltage).

Secondly we configured the data to server as follows:

  

Problem is the JSON outputted by the data to server contains completely different values from the ones expected (around 230):

 {"timestamp": "1616836325","slave_id":"1","start_reg":"19001", "data": -0.000000}

{"timestamp": "1616836285","slave_id":"1","start_reg":"19001", "data": 0.000000}

{"timestamp": "1616836275","slave_id":"1","start_reg":"19001", "data": 525174880.000000}

{"timestamp": "1616836255","slave_id":"1","start_reg":"19001", "data": -0.056988}

{"timestamp": "1616836215","slave_id":"1","start_reg":"19001", "data": -1961541215275985485200763402584064.000000}

{"timestamp": "1616838295","slave_id":"1","start_reg":"19001", "data": 8296095672285933002313833644032.000000}

To validate it is indeed a device problem we set up the TRB255 with exactly the same configuration and here it works as expected (we consistently get values around 230). Also to make sure it is not related to this register we set up a lot of other registers as well. These also show the same behavior.

---

Hello,

Sorry for the delay, I'll perform tests and as soon as possible I'll let you know about results.

Regards.

---

Hi,

Can you please perform the following test inverting the byte order in your request? I've perceived the same issue using TRB1_R_00.02.06.1

I've selected data type "32bit float, Byte order 1,2,3,4" and I got the right data in WebUI, but when I've checked the Beeceptor, it received the inverted value.

I've tested using a different byte order in the WebUI "32bit float, Byte order 4,3,2,1". So I've received the wrong value in TRB WebUI, but the beeceptor received the right value.

Seems it's a bug, the data to server is getting the inverted order and sending to server in a wrong way. Please perform this tests and if you have the same result I'll inform to the responsible department.

It's only happening with float data. the other data types are working as expected.

Regards.