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.
How can I tell which point is causing an error?
-
I get this exception on every 5 min poll.. How can I find the source of the issue?
VELO CONTROL POINTS': Exception from modbus master: No recipient was found waiting for response for key com.serotonin.modbus4j.ip.xa.XaWaitingRoomKeyFactory$XaWaitingRoomKey@cdebAdd comment
-
Hi Phillip,
I believe those waiting room messages to suggest that your timeout is very near the actual timeout of the communication (or at least one request in the communication), so the request is being returned from the modbus device but after the request is deemed to have timed out. So, I would try raising your timeout. It is odd that would happen every poll. It might be possible to use a few consecutive error messages to find out the slave ID and function code, by working backward from the hashCode (but it probably isn't worth it): https://github.com/infiniteautomation/modbus4j/blob/master/src/com/serotonin/modbus4j/ip/xa/XaWaitingRoomKeyFactory.java
I think it would be more effective to binary search the points for the cause by disabling them, if it were caused by a point and not the device pausing briefly during communication.
-
Thank-you, that's perfect; I have been searching for the point at issue using this disable/enable approach however there are about 104 slaves and 900 points in this data set. It never occurred to me that this could be the result of a connection timeout. I changed it to 3 secs and the issue has gone away. Thank-you Phil, this has been bothering me for a while.
-
Certainly! Glad we got it figured out. I would wonder if a particular request took a lot longer than others (perhaps there's something like virtual registers the device is computing upon request?) if there was cause to go deeper.
