Best method to detect when RS-485 Modbus/RTU devices is offline

General
1

I have a Tulip Edge IO device connected to a Yokogawa oven controller via RS-485 and Node-RED.

As long as the oven is turned on I'm having very good success polling the controller. As the lab turns the oven off at the end of the day I need a way to reliably detect when the controller is off.

I can try using the states but that cycles through as reconnect attempts are made.

Anyone have a better idea?

2

Could you not hook something into the power circuit to tell you when the oven was energized ?

Or a CT clamp on the circuit that feeds the oven ?

Failing that there would be a time differential i would imagine between a successful read and a failed read/timeout because the device is offline - would be worth doing some testing

So

  1. Start time tracker
  2. perform read
  3. End time tracker

Compare the times for a succesful read as against a failed read and see if there is a noticeable and reproducible difference

Craig

3

Yeah, I was just seeing if there was a slick way to handle this using the Modbus/RTU handling.

The controller has outputs so there's a good chance there's one for monitoring whether it's up or not, but that would require removing it from the oven to access the terminals whereas I can toy with the NodeRED remotely :slight_smile:

4

Yep so try measuring the timeout on the query and see if that is a repeatable/measureable number with the unit on and off

Craig

5

What status values does the node provide when the device is off?

6

This seems to be the general flow of the connection attempts:

image
image295Ă—596 7.68 KB

7

I added picking up msg.status.text = failure which seems to work. Now I just need to wait until someone turns the oven on tomorrow to see what text is sent for success!

8

Assuming you are using the Getter node then, for me at least, it is "reading done"

9

Hello Richard .. instead of the states i used in my modbus project the option in the Modbus nodes
to send an empty msg on fail. (fail in this case would be the device being switched off and not replying to requests)

image

With this option checked i still get a msg from the mod. nodes that i later handle with a Function node after it.

if (msg.payload == "" || msg.hasOwnProperty('error')) {
// handle error
}
1 Like
10

That's an interesting method. I may convert to that, and I can even use a switch node instead.

Because this is for work I tend to use the simplest method that works because you never know who's coming behind you.

11

Is not it simpler to use the status node?

12

If you're an expert user then probably, because you understand what it does. For a more novice user the fact there's no connection to the Modbus getter node it could be confusing.

13

Why would there be no connection to the modbus node? Presumably when it is working you send the output somewhere. If you position the modbus and status nodes immediately one above the other then when there is good data it comes out of the modbus node, and when it fails the error comes out from a switch node following the status node. Give the status node a name such as Modbus Status and it should be clear what is going on. However if using the blank payload to split the flow into good data and failure fits your needs better then that is fine.

1 Like
14

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.