-
-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Node does not send an error message #347
Comments
Hi @DmitrySidorow yes, the node has a new check for inactive connection. We can add to send out an empty message on each fail for input, but maybe it is in your case not an error from a failed Modbus function anymore. |
check the new warnings of the nodes |
Yes, it is definitely necessary for the node to send some kind of error message so that this message can be processed. Thank you |
If you are in trouble without an empty msg, then you send to early to the node and this is not to handle by the node. We have different interests and discussed the new behavior in a group and it makes more problems if you send way too early to the modbus nodes. To handle your case, which is another perspective, it needs a new option to separate it. |
Maybe a modbus state node is here a better solution to be able for asking the client node about its state. |
see #348 - it is a different meaning if the Modbus client could not send or fails or if a message is too early or in the wrong moment passed into to the node. To handle both situations it makes sense to get a new node to check if a used client is ready to accept msg. That is easier to handle in programming and the programmer knows exactly what to case is at the problem of a not to send msg. The empty msg will just be sent if the Modbus client has a problem or fails. |
In the most support requests we analyzed now, that more than 80% of the problems are too early sends into the node, while Modbus is not ready to accept and send the msg objects. It is not clear, which impact the deny of msg objects since v5.24 has in a project that uses the queue intensive. It would be great to learn more from the community about the needs in the different cases of the client and the nodes to handle the Modbus msg objects well. |
This issue is stale because it has been open 60 days with no activity. It will be closed in 30 days, but can be saved by removing the stale label or commenting. |
Hello @biancode .. i will agree with @DmitrySidorow that its important to send an "Empty msg on fail" when the option is checked because we also have the need to process this msg in order to update the status of a Disconnected device. The same way you log an error in the Debug window when the option is checked to log failures, can we also have a msg when there is a Failure ? Maybe the option "Empty msg on fail" should have been on the Modbus Client config node instead ? I believe this feature was working before but now when the latest versions, when we have the option to "Reconnect on timeout" it seems broken since the Modbus Client doesnt accept msgs when its in Reconnect state ? If you have time im sharing part of our flow to better visualize what we are trying to achieve
|
We reverted to version 5.23.3 and now we get a nice tidy error msg and with a Function node we can check if there is an error ( I hope "Empty msg on fail" gets fixed in the latest versions also like it was in 5.23.3 |
This issue is stale because it has been open 60 days with no activity. It will be closed in 30 days, but can be saved by removing the stale label or commenting. |
Which node-red-contrib-modbus version are you using?
5.24.0
What happened?
The function of sending an empty error message no longer works.
![image](https://user-images.githubusercontent.com/43705385/206445185-a77f7089-373c-4abd-a044-83d335d7910f.png)
Server
Modbus-Server Node
How can this be reproduced?
Use modbus flex write to unreachable tcp server
What did you expect to happen?
Node should send empty message if connection error. It helped me to keep track of communication with devices
Other Information
No response
The text was updated successfully, but these errors were encountered: