ModbusTCP Control of ATV71 Drive

[kjon]

I am trying to setup Modbus TCP control of a Schneider Electric ATV71 VFD which controls a pump for a heat exchanger. I have worked with Schneider Tech Support and gotten the Modbus communication set up and working using a free modbus scanner called QModMaster. Using this program I am able to continuously write (at 1Hz) the speed to run the pump and it changes accordingly. Now when I try to do the same thing in LabView I get an error. I've attached the code I wrote (using LabView 2018). When I run with the while loop disabled, it runs correctly and starts the pump/changes speed depending on the current status of the pump. However, when I enable the while loop, on the first iteration, the write single register command always returns "Error 538193: Modbus Exception: Response Transaction ID doesn't match Request. This usually occurs on network error." I don't understand why repeating the exact same write to register code that I did less than two seconds prior would not work in LabView but the continuous write in the modbus scanner works just fine. Any ideas why I am getting this particular error? I understand that the errors returned are Error 538180+Modbus exception code, but I haven't been able to find anything about an exception code 13 anywhere.

Thanks in advance!

[Kyle97330]

The NI Modbus library you're using is unfortunately password-locked so delving into the code to see exactly what's going on isn't possible.

However, on a basic level, the transaction ID it's complaining about not matching is supposed to be there to make sure that the reply from the instrument that you're processing matches the query you sent out.  If it doesn't match, then it indicates a possible data transmission error.  There's no chance you're running any other queries on this device in parallel, is there?

Since it seems like you're just starting off, any chance you can switch to another Modbus library and see if it works instead?  There's at least 3 other Modbus libraries for LabVIEW, and one of them might either work unchanged, allow you to add a flag to ignore the transmission ID mismatch, or let you look at the raw data coming in from the device and trace the error that way.

[kjon]

Kyle, Thanks for the response. I'm obviously new to modbus. The thing that doesn't make any sense to me is that if I disable the loop, it works just fine no matter how many times I run it, but if I add any commands after the Read Registers step, I get the transaction ID error. There are no other Modbus devices on the network and no other programs running that could access the device. I haven't tried any other libraries but I only know of one other than the NI one and it has all the exact same functions.

[Kyle97330]

Well, it seems a bit silly to suggest, but if you don't want to switch Modbus libraries maybe you could try closing and re-opening the connection each time before the VI that triggers the error, and see if that helps?  It might take a small amount of extra time but I see you have a 1 second wait in there in any case so you probably won't notice.

[kjon]

Yeah I guess that's an option but in the grand scheme of things is probably not a good approach. This is going to be part of a much larger system that will require PID control of the pump for changing input conditions. I'm just starting at the basics and trying to scale it up once I get individual components functioning properly.

[RavensFan]

---

@kjon wrote:

Kyle, Thanks for the response. I'm obviously new to modbus. The thing that doesn't make any sense to me is that if I disable the loop, it works just fine no matter how many times I run it, but if I add any commands after the Read Registers step, I get the transaction ID error. There are no other Modbus devices on the network and no other programs running that could access the device. I haven't tried any other libraries but I only know of one other than the NI one and it has all the exact same functions.

---

Try the library here.  http://www.ni.com/example/29756/en/

It was never officially supported by NI, but I've used it for years.  It works, and all the subVI's are open for you to see how the communication works.

[Kyle97330]

I've actually used the library RavensFan linked to above.  It seems to work fine, but the only downside is that it has different wires for TCP versus Serial, and the other libraries have the same wire for each.  If the device you're using doesn't have an option to use both, then there's basically no downside to trying it.

[RavensFan]

One thing about that library is that I don't use the Init subVI for serial it provides.  I find it makes assumptions about stop bits that may not be valid.  I just use a regular Serial Port Initialization to set all the port parameters.

I have not done as much with the TCP version of it.

[kjon]

Thanks for the replies guys! I wrote the same code using the other Modbus functions you mentioned and still get an error but now it is an Error 66. Do you think this means there is an issue with the slave refusing the connection after reading one time? Or is this still a coding error?

[Kyle97330]

Error 66 does usually mean that the other side has closed the connection.

Try opening and closing the TCP connection each time it runs the query.  Assuming this device is on a local network it should only take a few extra milliseconds to do this each loop.