Modbus TCP/IP Error 62

[Terry_S]

I am getting an error 62  when running a vi.  My vi has 3 loops and each loop is communicating with a different device using modbus.  I have used this programming before with other applications and the only difference is the the computer OS, Windows 11.

Reading other messages, this error is comming from a connection that is closing due to inactivity, however I am reading each device at a rate of 1 sec.  I have attached an example of my vi.  Keep in mind, in my real application I am reading more than one register for each device, but no more that 10 register for each device.

My application will start reading the devices and then after some time period I will get the error and the error is not necessarily on the same device.  Also each loop will eventually generate the same message (my real app has a case structure around the read function that will on read if there is no error, so the vi will still run if there is an error).

Any ideas on where I should be looking to fix this.

Terry

[Jay14159265]

---

@Terry_S wrote:

I am getting an error 62  when running a vi.  My vi has 3 loops and each loop is communicating with a different device using modbus.  I have used this programming before with other applications and the only difference is the the computer OS, Windows 11.

Reading other messages, this error is comming from a connection that is closing due to inactivity, however I am reading each device at a rate of 1 sec.  I have attached an example of my vi.  Keep in mind, in my real application I am reading more than one register for each device, but no more that 10 register for each device.

My application will start reading the devices and then after some time period I will get the error and the error is not necessarily on the same device.  Also each loop will eventually generate the same message (my real app has a case structure around the read function that will on read if there is no error, so the vi will still run if there is an error).

Any ideas on where I should be looking to fix this.

Terry

---

Try reading faster than once per second and throwing away what you don't want. There is too much data on the bus. 

[Terry_S]

I should have mentioned that I also have Gigabit camera on this same network.  If I monitor the performance in the task manager for this network, with everthing running it is around 100 Mbps.

Will changing the read rate of my loops be reflected in the value being read in the perfromance monitor?

The network is made up of Gigabit network card, Gigabit switch, and Cat6 cables.

Terry

[Terry_S]

Update

I increased the reading rate of the loops to 100 msec and removed the camera from the network and I am still getting the Error 62.

Terry

[Jay14159265]

---

@Terry_S wrote:

Update

I increased the reading rate of the loops to 100 msec and removed the camera from the network and I am still getting the Error 62.

Terry

---

Why not try letting the loops free run with a timeout on the read? what is the point for the wait?  I tried to look at your code but it was missing a VI so I could not see the actual read that is happening. 

A short story about waits in code: I used to use waits in my code until my code mentor (and boss) told me that if he ever found another wait in my code he would fire me. I told him you simply could not write code without using waits and he told me that I better figure out a way to not use waits if I wanted to keep my job so I did, and I have never used another wait to this day : ) 

[rolfk]

No waits or delays at all is a bit radical but about 90% of the ones I see in most code are useless or even misplaced! If you place them in instrument communication, you are basically always doing bandaids rather than proper instrument communication.

But sparsely placed in UI loops, they often can make the difference between a greedy loop doing very fast nothing but waiting for a user input and burning an entire CPU at maximum energy consumption, or a loop that still reacts faster than any human ever could notice and utilizing that same CPU barely, with a fraction of the energy consumption.

So yes, don’t use delays (or waits) liberally in your code, but they do have their place! For someone beginning with LabVIEW (or other programming languages) a complete ban of them may be a good exercise, because they are more often than not indeed abused.

[Jay14159265]

---

@rolfk wrote:

No waits or delays at all is a bit radical but about 90% of the ones I see in most code are useless or even misplaced! If you place them in instrument communication, you are basically always doing bandaids rather than proper instrument communication.

But sparsely placed in UI loops, they often can make the difference between a greedy loop doing very fast nothing but waiting for a user input and burning an entire CPU at maximum energy consumption, or a loop that still reacts faster than any human ever could notice and utilizing that same CPU barely, with a fraction of the energy consumption.

So yes, don’t use delays (or waits) liberally in your code, but they do have their place! For someone beginning with LabVIEW (or other programming languages) a complete ban of them may be a good exercise, because they are more often than not indeed abused.

---

Yea, waits are not totally useless but I needed to learn a lesson so I had to learn the hard way.

[billko]

---

@rolfk wrote:

No waits or delays at all is a bit radical but about 90% of the ones I see in most code are useless or even misplaced! If you place them in instrument communication, you are basically always doing bandaids rather than proper instrument communication.

But sparsely placed in UI loops, they often can make the difference between a greedy loop doing very fast nothing but waiting for a user input and burning an entire CPU at maximum energy consumption, or a loop that still reacts faster than any human ever could notice and utilizing that same CPU barely, with a fraction of the energy consumption.

So yes, don’t use delays (or waits) liberally in your code, but they do have their place! For someone beginning with LabVIEW (or other programming languages) a complete ban of them may be a good exercise, because they are more often than not indeed abused.

---

I agree.  Relying on waits in communication code usually means you don't fully understand the communications protocol.

[Terry_S]

I have removed the timing and I am still getting the same error.  You mentioned that vi's were missing from the example that I attached.  I am using the Modbus Library that comes with labview, however I have attached a zip file that contains all the files associated with the vi's I am using from the modbus library.

Also, when it comes to timing, I am not sure having no timing is the absolute answer.  I deal with a lot of older devices that are still serial communications and they are not asyncronous (most only use tx, dx and gnd for hookup). Some don't even send an end of transmision character. They would fail if you sent requests at too high of a rate.

But ethernet communications are a bit new to me, however like I have said I have been using the same programming style and hardware for the past 5 years and have not had issues until now.  The only change I have are the windows operating system, now on Windows 11 and the brand of usb to ethernet adapter (still Gigabit).  Also this network is dedicated to the hardware I have attached.

The error message states that there is a serial port overrun (seems like poor wording as I am not using a serial port), but is there a way to monitor my network to determine if timing is the issue?  Or is it just a trial and error thing?

[Jay14159265]

---

@Terry_S wrote:

I have removed the timing and I am still getting the same error.  You mentioned that vi's were missing from the example that I attached.  I am using the Modbus Library that comes with labview, however I have attached a zip file that contains all the files associated with the vi's I am using from the modbus library.

Also, when it comes to timing, I am not sure having no timing is the absolute answer.  I deal with a lot of older devices that are still serial communications and they are not asyncronous (most only use tx, dx and gnd for hookup). Some don't even send an end of transmision character. They would fail if you sent requests at too high of a rate.

But ethernet communications are a bit new to me, however like I have said I have been using the same programming style and hardware for the past 5 years and have not had issues until now.  The only change I have are the windows operating system, now on Windows 11 and the brand of usb to ethernet adapter (still Gigabit).  Also this network is dedicated to the hardware I have at

The error message states that there is a serial port overrun (seems like poor wording as I am not using a serial port), but is there a way to monitor my network to determine if timing is the issue?  Or is it just a trial and error thing?

---

I see, I am on a mac today and it does not have the modbus library installed. Before there was modbus over tcp there was modbus over serial, Without looking at the modbus library, there might be a point that a virtual serial port is created and the gagabit ethernet connection is jamming too much data onto the virtual serial bus. Any way, that is speculation. 

What you can do is monitor the data between the PC and the instrument with wireshark: 

https://www.wireshark.org/

On a side note, I have used modbus for many applications but I have never used the modbus library in labview, I'm not saying it is bad but I have had some bad experiences with other labview libraries (see labview XML library) that might indicate that you would want to roll your own way to handle MODBUS over TCP. MODBUS is not that hard of a protocol to implement from scratch on the PC side.