NI LabVIEW Modbus API Discussion

[Mark_Yedinak]

I have an application running controlling an external device device using Modbus/TCP. I am using the latest NI Modbus library which I downloaded from VIPM. I open the connection to my device and communicate for a few minutes. At that point I get an error 538193, which indicates the that there was a transaction ID mismatch. The Modbus library closes the connection at this point. I captured the network trace of the communications and I did see a point where the device returns an unexpected transaction ID. However, once this error occurs I cannot communicate with the device. I close the connection and re-open it yet every communication with the device will throw this error. My captured data does not show this to be the case. After the new connection is opened the query and response from the client have matching transaction IDs. My only recovery has been restarting the application. I have not tried destroying and recreating the Modbus Master in the application but this seems a bit drastic.

How can I recover from this error without having to restart my application? I can't even filter this error in my application because the library is throwing the error and it is too late by the time the application catches. Once in this state the Modbus library will always generate this error and close the connection.

[JÞB]

Quick answer, MGIMODBus TK.

[Mark_Yedinak]

I'm not finding it on VIPM, at least not in LV 2017.

[S1ack]

---

@Mark_Yedinak wrote:

 a point where the device returns an unexpected transaction ID.

---

Does this not implicate your slave device? Perhaps run your code against a Modbus poll slave setup in the same manner as your device www.modbustools.com

I've never seen this error dealing with varied TCP and serial slaves using the latest / supported Modbus API (there have been so many flavors of the years).

[Mark_Yedinak]

---

@S1ack wrote:

---

@Mark_Yedinak wrote:

 a point where the device returns an unexpected transaction ID.

---

Does this not implicate your slave device? Perhaps run your code against a Modbus poll slave setup in the same manner as your device www.modbustools.com

I've never seen this error dealing with varied TCP and serial slaves using the latest / supported Modbus API (there have been so many flavors of the years).

---

I agree, this looks like an issue with the device. However, I do not have control over any modifications to the device and the larger issue is that the modbus library gets stuck in an unrecoverable state. I should still be able to use the library and do some sort of error recovery should this error occur. I shouldn't be required to restart the application in order to recover from the error. Once in this state, the library will terminate all further connections with the device with this error regardless of how the device responds.

See the trace below. Each TCP-RST is an error 538193 in LabVIEW.

[Porter]

You might also want to try the Plasmionique Modbus Master. The latest version has an improved handling of transaction IDs. You can download the VIPM here: https://lavag.org/files/file/286-plasmionique-modbus-master/

It handles transaction IDs quite differently from the NI Modbus Master. Maybe it would help.

You can test using the Modbus Comm Tester (located in the Tools -> Plasmionique menu).

[Mark_Yedinak]

---

@Porter wrote:

You might also want to try the Plasmionique Modbus Master. The latest version has an improved handling of transaction IDs. You can download the VIPM here: https://lavag.org/files/file/286-plasmionique-modbus-master/

It handles transaction IDs quite differently from the NI Modbus Master. Maybe it would help.

You can test using the Modbus Comm Tester (located in the Tools -> Plasmionique menu).

---

Thanks, I'll have to take a look at this.

[carlos_camargo]

I can use "Create TCP Master.vi" to create a link to a Modbus slave.  I think though that there is no way to add another slave to this master.  Is that in fact the case?  For each slave I need to create a master?  Snippet is just a cut from the built in "Modbus MasterExample.vi".

[AinaFr]

Hello all,

I previously posted to the "Instrument control" forum, but maybe my question fits better this thread...? By the way, please excuse me for the multi post.

I need to solve communication problems between a labview VI and a system (designed by my company). They are communicating on a half-duplex RS485 wire, using modbus RTU as protocol. My system is linked to my PC through an USB to RS485 adapter. I am using NI modbus library (1.2.1.42) to send modbus frames with labview.

The labview VI is sending endlessly read holding registers commands to the board, and most of the time everything is working fine. But after a random amount of time, I get a timeout error (error 56) on my modbus VI. Looking at frames exchanged through RS485 port with a sniffer shows that, when everything works fine, my system is responding in less than 100 ms. And when the timeout occurs, the answer happens slightly after 100 ms. So I guessed the problem was due to timeout definition... But when I look at my VI, I see that read timeout has been set to 2 seconds, so it shall not happen!

I tried to increase the timeout value, and got the same problem. Looking at Modbus Master.lvclass:set timeouts.vi's context help says: "This function takes effect immediately, and will change the timeouts of any future operations using the instance returned by Modbus master out", so for me the VI should not issue a timeout error less than 2 s after the sending of the last modbus frame. Right? 

Any idea of the reason of this timeout?

[AinaFr]

I need to solve communication problems between a labview VI and a system (designed by my company). They are communicating on a half-duplex RS485 wire, using modbus RTU as protocol. My system is linked to my PC through an USB to RS485 adapter. I am using NI modbus library (1.2.1.42) to send modbus frames with labview.

The labview VI is sending endlessly read holding registers commands to the board, and most of the time everything is working fine. But after a random amount of time, I get a timeout error (error 56) on my modbus VI. Looking at frames exchanged through RS485 port with a sniffer shows that, when everything works fine, my system is responding in less than 100 ms. And when the timeout occurs, the answer happens slightly after 100 ms. So I guessed the problem was due to timeout definition... But when I look at my VI, I see that read timeout has been set to 2 seconds, so it shall not happen!

I tried to increase the timeout value, and got the same problem. Looking at Modbus Master.lvclass:set timeouts.vi's context help says: "This function takes effect immediately, and will change the timeouts of any future operations using the instance returned by Modbus master out", so for me the VI should not issue a timeout error less than 2 s after the sending of the last modbus frame. Right? 

Any idea of the reason of this timeout?

[AinaFr]

Hello,

Again with my read holding register problem...! I am communicating on RS485 half-duplex with a system designed by my company, and using release 1.2.1.42 of NI's modbus library.

My VI sends 4 "read holding register" commands, normally one after the other. But by looking at frames exchanged on serial port with a sniffer, I noticed that today's error was due to the fact that labview sent a read holding register command while the slave had not finished responding to the previous request. I am astonished that read holding register function does not wait for the response to be received before stepping out... How can I force it ?