Restarting the executable until all communications are established

[KWaris]

I wonder if I could be very clever and find the way out of my problem here.

I am communicating with a device over UDP and for some reason, the device doesn't often establish communication with my Labview Executable on the first attempt.

I run it, it fails, I then use CTRL+ALT+Delete to shut it down. I donubleclick the executable ICON on the desktop again and I sometimes do it five or six times then finally the communication is established and it all works.

I wonder if I could add some code in the application to automate this process. One of the way I could now think to do is by creating another vi and call my current vi dynamically and add all those conditions into cluster, call this cluster (by wiring to the output terminal of the current main vi into new main vi) and monitor my cluster in the new main vi to see if the conditions are true if so continue or reload the current vi until those conditions are met? Is it the right way to do this? Or can I make my life easier and applcation more stable by doing something different?

Kind Regards

Austin

[ned]

Why do you have to use ctrl-alt-del to shut down your program? That to me says you have an error in your programming. Perhaps you could be more specific about the failure. Do you have an infinite timeout somewhere? Consider replacing it with a fixed length of time, and if it times out, retry a certain number of times before giving up.

[KWaris]

A very odd this happened to my project!

One concept I still get to grasp fully is error handling! This project is a multiloop project. All the vis have auto-error handling enabled.

When I started doing this few weeks ago, I always had thought why if there was an error, labview is showing that dialog box with message number and an option to continue or stop.

Then now all of sudden when I plugged in my computer, the application started throwing those messages. So I am here not aware what changed between yesterday and today. Any ideas!

[Rolf Kalbermatter]

A very odd this happened to my project!

One concept I still get to grasp fully is error handling! This project is a multiloop project. All the vis have auto-error handling enabled.

When I started doing this few weeks ago, I always had thought why if there was an error, labview is showing that dialog box with message number and an option to continue or stop.

Then now all of sudden when I plugged in my computer, the application started throwing those messages. So I am here

not aware what changed between yesterday and today. Any ideas!

What messages? How does your code look? Is auto error handling the only error handling you do in your code?

Network communication is not something that you can simply expect to work always. Your code needs to be able to handle all kinds of possible errors such as timeouts, the peer disconnecting etc. in order to get a reliable operation. Depending on the error and your application you can sometimes ignore it (read timeouts for instance) or should close the connection and attempt to reconnect (client) or wait for another connection attempt (server).

[KWaris]

Hello Rolfk,

These are the timeout and peer disconnecting messages. Error 56 and Error 66.

It is suitable for this application to be restarted so attempting to reconnect is very convenient. This is 10 loops architecture, all other starts fine and all the codes in other loops work. It is only these 3 loops where I am calling the devices over UDP which sometimes donot initialize properly. As I said the Error 56 and Error 66 occur when this happens. There is no set rule here sometimes it is Error 56 and sometimes it is Error 66. But if I keep closing the application and re-opening it then eventually the connection is established successfully. I could think the only best way here is perhaps to completely close down the application and restart it again and I can only do it by doing CTRL+ALT+DEL. There is something stopping these three loops to shut down. I used Clear errors thinking if there is an error which is stopping the loop to shutdown, it will be then ignored. It is still not working.

Any suggestions?

Kind Regards

Austin

[ned]

I think it would help if you share your code. It sounds like you have not taken the time to find out where the problem occurs and are instead trying random solutions such as inserting Clear Errors in the hopes that it will work, without knowing why. This is not a good way to go about programming. When you run your program in the development environment, do you ever see this problem? If so, you should be able to determine where the problem is. If your development machine does not have the hardware necessary to test the code, try building an executable with debugging enabled and connect to it with the debugger remotely. Instructions for this are in the LabVIEW help.

[Rolf Kalbermatter]

Hello Rolfk,

These are the timeout and peer disconnecting messages. Error 56 and Error 66.

Incidentally exactly the error codes I mentioned in my reply that you can't just always honor or ignore, as it depends on the situation where they occur, what you should do about. Timeout means usually that there simply hasn't been data and you should retry after a reasonable amount of time whatever you tried to do that gave you a timeout. This can be a Read, or a Connect or a Write operation. You should build some retry limit into it as it makes usually little sense to try endlessly. If after several minutes there is still no peer to connect, there might be a bigger problem like a disconnected network cable. Peer disconnected is another error that can happen because of network failure and that you can handle totally transparent by closing your network connection and attempting to reconnect again.

It is suitable for this application to be restarted so attempting to reconnect is very convenient. This is 10 loops architecture, all other starts fine and all the codes in other loops work. It is only these 3 loops where I am calling the devices over UDP which sometimes donot initialize properly. As I said the Error 56 and Error 66 occur when this happens. There is no set rule here sometimes it is Error 56 and sometimes it is Error 66. But if I keep closing the application and re-opening it then eventually the connection is established successfully. I could think the only best way here is perhaps to completely close down the application and restart it again and I can only do it by doing CTRL+ALT+DEL. There is something stopping these three loops to shut down. I used Clear errors thinking if there is an error which is stopping the loop to shutdown, it will be then ignored. It is still not working.

Last but not least you should of course consider the timeouts you use for the various functions. When you do a connect with a 120 second timeout the connect will wait that long likely preventing your application to quit when you hit the quit button until it gets the requested operation (connection for a connect or data for a read), encounters and error or the the timeout occurred. This is probably the reason that you believe that you can only Ctrl-Alt-Del your application as the network functions simply sit in a timeout waiting for something.

One thing that usually works to terminate most network functions in LabVIEW is to actually Close the network refnum that they operate on. This is not really good programming for normal network refnums and might fail sometimes but the perfect way to terminate the listener loop, when you would have a TCP Listener somewhere in your program. So wherever you handle your Application close request, get a handle on those network refnums and close them. That "should" make any network operation that is waiting on that refnum to return with an error. Better would be to make your network communication use much smaller timeouts and handle the close request themselves by polling a global close state controlled by your application close handler or if you start to do real software design some day , use some producer consumer framework throughout your application to handle those 10 loops correctly and in a fully controlled manner.

[KWaris]

Hello Rolfk

Believe me this is real software engineering .

When I want to quit, I click stop button this resides in Producer loop. This triggers an event and a command is sent to the consumer loop to shutdown the application. Shutdown case in the consumer loop contains the queue references to all the loops and send the command to execute the shutdown cases. In the shutdown case, the while loop loop termination input is wired to true to stop all the loops.

7 of them stops, three of them containing these UDP loops dont stop. I will follow your tips and hopefully it all works.

[KWaris]

I have now managed to close my application (all loops). As I had used the shift registers for error wires in all the loops, I just used the clear error vi outside all the cases just before the shift register to the right side of each loop. I could have perhaps created an error handler vi to handle the errors here and then merge the error wires outside the while loops and used simple error handle vi to find what error occured in the application. I have however realized that merging all the error wires and using simple error handle vi will only report the first error and ignore all the others. I searched for SEH (structured error handler library)for labview 2011 but been very unsuccessful.

Is this library available free? Or are there some other third party libraries which could be used to handle the errors (e.g retry, ignore, report etc)

Thanks for the help