Error 56 on reading Satec meter via TCP/IP, timeout & wait?

[J_K_er]

This VI successfully reads data from this Satec power meter. The issue I'm having is that it will over time through out Error 56. Whats interesting is if I place a Wait Function and increase the wait time (from 10ms to 800ms) it seems to last longer! I'm not sure whats going on. My goal is to get it to run continuously but increasing the wait may negate its usefulness. I have no clue whats causing this error 56 to show up, it certain can read the meter. Any thoughts?

[StevenD]

That's tough to say. The default timeout for the Modbus library TCP is 10 seconds. Quite a long time. Could be the device is not responding correctly after so long, could be a network problem. Are you going through a router or directly to the device? A workaround could be to shorten the timeout to something more reasonable, a few hundred ms to a second, then check for error 56. What you do next you have to figure out. Can you just try again and get a response or do you need to initiate a new TCP connection? 

[J_K_er]

sorry, meant to say throws out error 56, excuse my spelling/grammar mistakes

Yes, I have it running through a router but I have also tried directly to the ethernet port and the performance is about the same.

Wait function set to 100ms -> error 56 occurs around 1500 seconds

Wait function set to 750ms -> error 56 occurs around 5000 seconds or longer

So there's definitely a correlation between how long a loop occurs and how long the error 56 will show up, but it is inevitable in all cases. Is it possible there is a finite amount of data the Satec outputs and once it reaches it, perhaps through a buffer limit or something, then produces that error?

I have not tried to programmatically re-connect to the Satec meter but thats a good idea to work around this issue. I'll give a try and see what happens.

[J_K_er]

After some more digging I believe I found the cause and the solution to this error. The error occurs because there is an increasing number of sessions being opened to communicate with the device. After a certain amount of these sessions the network dumps the connection throwing out error 56.

The solution would be to close out these piling up sessions so there is no error thrown. That may have to be done on the VI coder's side, so an even easier solution is to simply ignore error 56 all together. I created a case structure for the error condition which resets to a False error. The VI will continue to run uninterrupted reading from the device indefinitely. This solution has worked continuously so far.

[billko]

---

@J_K_er wrote:

After some more digging I believe I found the cause and the solution to this error. The error occurs because there is an increasing number of sessions being opened to communicate with the device. After a certain amount of these sessions the network dumps the connection throwing out error 56.

The solution would be to close out these piling up sessions so there is no error thrown. That may have to be done on the VI coder's side, so an even easier solution is to simply ignore error 56 all together. I created a case structure for the error condition which resets to a False error. The VI will continue to run uninterrupted reading from the device indefinitely. This solution has worked continuously so far.

---

This is like driving off a cliff to avoid a pothole.  New (and more dangerous) issues await both scenarios.

[J_K_er]

A more elegant solution is desirable but so far so good! It has run continuously for 24 hours straight so far. Not a blip yet. It goes without saying the case structure only looks for error 56. A disconnect error (62) would halt the VI as it should. I'll be sure to update this thread should any complications arise from doing this.

[billko]

---

@J_K_er wrote:

A more elegant solution is desirable but so far so good! It has run continuously for 24 hours straight so far. Not a blip yet. It goes without saying the case structure only looks for error 56. A disconnect error (62) would halt the VI as it should. I'll be sure to update this thread should any complications arise from doing this.

---

More explicitly, keep an eye on your memory resources.  Every unclosed reference is a memory leak.

[StevenD]

I think you are using the NI Modbus library, but some of the names are different (Close instead of Shutdown). You might want to make sure you have the latest version. I have used this library on several projects and not had any issues.