Please Note This forum exists for community support for the Mango product family and the Radix IoT Platform. Although Radix IoT employees participate in this forum from time to time, there is no guarantee of a response to anything posted here, nor can Radix IoT, LLC guarantee the accuracy of any information expressed or conveyed. Specific project questions from customers with active support contracts are asked to send requests to support@radixiot.com.
ModBus RS-485 TUF-2000M meters
-
The company I work for is having communication issues between Mango and a number of TUF-2000M meters using ModBus over RS-485. I have issued a ticket, #1146, which contains our Mango's configuration. The issue that we are having is that sometimes data appears to end up in incorrect locations; data that is from one data point ends up in another data point's table. The data is checksummed, so corruption is not the issue. The data is coming from persistent and instantaneous registers, and we are able to see corresponding values in the meters and in Mango sometimes being put in the wrong table, but this only happens occasionally. I was wondering if anyone has noticed similar problems. To me this seems like the kind of problem due to a race condition.
-
Hi Devin,
Interesting. I think it would be most helpful to have a log of the Modbus IO (which the data source will do), a time of occurrence, and the configured offset for the register that should receive the value and from the point that does receive the value. To take that a step farther, maybe experiment if you still occasionally get that problem with only the point and the point it swaps with enabled.
Can you describe the behavior more? Do many samples happen crossed together, or is it the odd sample fairly randomly? Why does this seem like a race condition to you (processing addressed data into the wrong address)?
I am not sure what to understand in "we are able to see corresponding values in the meters and in Mango sometimes being put in the wrong table"
-
how many meters are on the RS485 bus?
how many modbus masters are on the RS485 bus?
what is the polling rate?
I have seen issues with polling too fast, or multiple masters on one RS485 bus where the reply from a meter could end up as the response to the wrong query.
-
The configuration file for that particular Mango install is attached
to ticket 1146 on the support page. We have three TUF meters on a
single RS485 bus that are polled once every five seconds, with a
baud rate of 9600. We see one error about every two days. Mango is
the only master that we have at the install location, with each
meter being a slave to it. We are sometimes making multiple single
register read requests, sending out multiple request packets; we are
not sending multi-register-read requests. We have a number of TUF
meter registers that are persistent and store accumulative values,
so those values are very recognizable when they occur in the wrong
table or when a value not from that register occurs in its
corresponding table. My understanding is that each response packet
from a slave contains a header with the slave id and register id,so it
should be unambiguous to Mango where to store the data.
I'm guessing that this is happening when multiple packets are being
returned from different slaves or from the same slave for different
registers. -
are all the points on one modbus datasource in mango, or are there multiple modbus data sources?
If you want the problem to go away forever with the least amount of effort ditch the shared RS485 bus and move each device to its own dedicated RS485 connection.
-
One would think one should be able to daisy chain some devices, no? Certainly in our deployments we have daisy chained RS485 modbus devices and not encountered this. I don't dispute that your description sure does sound like it would eliminate any possibility of getting the issue, but it doesn't seem like it should be necessary. I do agree that it'll be the fastest, easiest path to resolution, though, since no more investigation would be called for.
I edited out Ed's email address. Partially because I don't know what Ed would like an Email about, and partially because I don't know Ed would like emails from anyone who wanders by.
I wonder if you're seeing two registers on the same slave ID cross, two slaves cross in the same register, or two different registers from two different slaves cross?
Judging from your configuration alone, nothing seems too unusual. My first question is if your serial data source reset logic would fire three times for this data source should the data source stop polling (I think it would, to hopefully no effect, but quite interesting). I may also try things like
- lowering retries to 1,
- lowering max read registers to 1 (for 2 byte data types, 2 for 4, 4 for 8) and unchecking contiguous batches
- Enabling data source alarms at a higher level than None, such that you notice if there's an ongoing error in polling. (For the version of Mango you're on, likely the only place you could see None level events is by directly querying the database's events table)
I may try to reference times your reset script had fired against moments of crossed data, also, because that script seems unusual to me.
