RS485ErrorCnt in RevPi Core S

[todor.v.dimitrov]

Hello world!

I've been setting up a configuration with RevPi Core, AIO and DIO and our HMI through Node-Red. I am reading about the RS485* registers in the Core and don't understand how I got the situation on the attached image. The image is showing a debug node I left in Node-Red showing the RS485ErrorCnt value changing briefly to "2" and then dropping back to "0". I would've thought they are being kept somewhere for diagnostics but can't find much about this. I am very curious how did we manage to cause an error but I see no way of debugging this. I haven't touched the error limit registers - they are set to 10 and 1000 respectively for 1 and 2, so I don't see where did our "2" disappear to or why did it appear. It would be precious to know exactly what didn't go through.

At the moment of the screenshot there was no PLC image loaded.

In general, should we panic if we see this register counting?
Does that mean that data may be lost during PLC operation with no indications?
Could you please provide more information about those RS485* registers in the Core?

Thank you in advance!

Cheers,
Todor

[stefanh]

Hi todor.v.dimitrov,

the RS485 backplane bus is designed to detect connectivity problems. The variable 'RS485ErrorCnt' plays a decisive role here. This variable is responsible for counting errors in the connection. It starts incrementing as soon as a connection problem is detected, which is a standard behavior for diagnostic purposes.

As soon as the connection is successfully re-established, the incrementing of RS485ErrorCnt is stopped and set to zero. This is a clear sign that the connection has stabilized. You also have the option of setting maximum values for the RS485ErrorCnt variable. Setting these threshold values can be beneficial to alert you to potential problems at an early stage before they become more serious.

More informations here: https://revolutionpi.com/tutorials/soft ... pi-connect

Regards
Stefan

Support | KUNBUS

[todor.v.dimitrov]

Hello Stefan,

Thanks for the feedback! I still don't get this part - the register is exposed to be visible to the user, but it is very tricky to actually observe any changes happening to it. How I got it is by accidentally adding a debug node in my Node-Red flow. Whatever value is seen on this register doesn't stick - as you explained, it rolls back to 0 as soon as the connection gets fixed.

The only diagnostic I could do with this register right now is to observe if whatever value it currently has, had been stuck for observable amount of time - because that would mean the connection failed to restart after whatever interference broke it.

Do you think it would be worthwhile to make this register a "stick at highest observed value" register in terms of how we drive its inputs? Then it could be cleared by writing to a bit in a different register. The reason to do the clearing on a separate register would be to avoid race conditions between an incoming update from HW side and the register clear access initiated by the user.

Cheers,
Todor

EDIT: Just to put this into context - I would use this data to figure out if a device performance deteriorates over time. You can think of predictive maintenance here.

[dirk]

Hi Tudor, I can understand your request, this is a latch functionality. So the only possibility currently I see is to create a small script, e.g. in Python with RevPiModIO2 Library, which can use a virtual device in PiCtory and thus uses the process image for data storage. The highest date or the last data is then written into the variables of that virtual device.

Take a look at the Revolution Pi Gateway tutorial, which also goes in this direction also regarding autostart via RevPiPyLoad.