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 to set a data point to read communication status?
-
How to set a data point within a datasource of Modbus TCP to read communication success or fail status, I want to use this point value.
-
Hi mothgo990,
Have you considered the "Create slave monitor points" option on the Modbus data sources? These are boolean points that reflect if a ModbusTransportException occurred in trying to read the points on a given slave ID, as opposed to a successful read or an error response.
-
aha, I got it, that's what I need, thank you!
-
@phildunlap said in How to set a data point to read communication status?:
Create slave monitor points
Another question, is there a way to "Create slave monitor points" to read point communication failure? I mean if the data source communication is good, but some point failed, is that also feedback a point value that we can read?
-
Most certainly, but not as directly.
The data points will be marked unreliable, which should appear in the UI. This could also be pulled out in a meta point if you wanted a point's unreliability to be a data point (I would update such a meta point on update events to the slave monitor points, since those will get an update every poll, and have the other point in context, then get the unreliability attribute like,
return CONTEXt_POINTS["p123"].getAttribute("UNRELIABLE") === true;). If you register for a point value websocket, the attributes should also come through in those messages.There will be an event raised on the data source which could be handled. I believe for Modbus this has the potential of happening many times in a single poll, so it's not necessarily the cleanest solution. Specifically, reads are batched based on the contiguous batches and batch size settings, and register ranges because of the protocol. Any particular request could have an illegal address in it, in which case all the points covered in the request would be marked unreliable, and the event could be raised and returned to normal several times as the data source processes the responses.
-
yes, people may need that point status value to control a .gif etc.
how about to feedback 0 or some special value for point value to indicate communication failed?
