Invoke Mode Restart - How used?

[Froboz]

I was thinking that the invoke mode of restart would be a means of Labview VI restarting, but I am getting a message that the method is invalid even though the wire does not appear to be broken.  I am working on a Windows System where I thought Restart was supported.

[playerm1]

It looks like the Restart method is application-level specific.  I can only reproduce what you have by selecting the restart method when the VI server class is set to "Application", and then updating the VI server class to "VI".  This may not have been intended by NI to leave the block diagram objects as unbroken.

You may want to take a look at the VI methods "Run VI" and "Abort VI" to get the functionality you are looking for.

[Bob_Schor]

According to the LabVIEW "Help", the Restart Method is used to restart LabVIEW, itself. 

From the Help file -- "This method is useful for restarting LabVIEW after you change the environment in a way that requires you to restart.   For example, in an application that activates a license for a LabVIEW third-party add-on, you can use this method to programmatically restart LabVIEW, which then updates the status of the license."

Bob Schor

[Froboz]

You have to open application reference and then invoke restart.  Not the behavior I was hoping for though.  I was looking to do the equivalent of hitting the stop button followed by the run.  This closes Labview then automatically reopens

[tst]

---

@Froboz wrote:

I was looking to do the equivalent of hitting the stop button followed by the run.

---

The relevant methods from the VI class are Abort VI and Run VI.

You should note two things:

1. You can't actually do it for the current VI, since once you abort it it stops running and won't execute the next method. It should be possible in principle to launch a separate VI to do this process for the current VI, but...
2. This is unlikely to be a good idea. There are some cases where the abort button can be useful, but in general, you should not see the toolbar at all. Your VIs should simply run and be called/stopped in the code, as opposed to being aborted. It's possible you have a use case that does justify it, but I doubt it. What is your actual need?

[Froboz]

I am running TCP communication where I have a loop issuing commands to a device and another loop that is listening for responses.  I didn't want them to be separate this way, but it is the only way I could make it work.  I works fine except for when I reset the device I am communicating with - either via a soft reset or a hard reset - in which case Labview locks up, so I need to restart it.  I was hoping to do this automatically with the soft reset which I can control from Labview.  Hard reset is another matter and Labview will need to be manually restarted.

[Bob_Schor]

To me, it sounds like your LabVIEW program, which is connecting to (and working with) a remote Site, cannot detect when the connection to the Site goes "off-line", either because of a Network failure (maybe even in your Host machine!) or a hang-up on the remote side.

One way to guard against this is to be able to detect Network and Site failures.  Once you establish communication with the Site, for example, you could have it (when idle) send out a "Hello, I'm just resting" message back to you every 5 seconds -- if you fail to get them, you know something has gone wrong, and you can take appropriate measures.

Bob Schor

[rolfk]

---

@Froboz wrote:

I am running TCP communication where I have a loop issuing commands to a device and another loop that is listening for responses.  I didn't want them to be separate this way, but it is the only way I could make it work.  I works fine except for when I reset the device I am communicating with - either via a soft reset or a hard reset - in which case Labview locks up, so I need to restart it.  I was hoping to do this automatically with the soft reset which I can control from Labview.  Hard reset is another matter and Labview will need to be manually restarted.

---

This sounds like bad error handling in your VIs. Unless your network card does very weird things, all the TCP/IP nodes should eventually return with an error when the connection is lost. The secret to robust TCP/IP communication is to selectively treat errors from the functions as real errors or something that is safe to ignore.

Generally when you call TCP Read, it can return all kinds of errors including that the connection was lost, the host was unreachable and of course the timeout error. A timeout error simply means the other side hasn't send anything yet and can be normally safely ignored and you just need to go and loop again after possible some extra Wait to give the system extra breathing space since obviously there wasn't anything received yet and your process likely isn't going to explode if you wait a few extra 100 ms before checking again if there is any data.

Any other error means usually that something happened to the connection, network cable or computer that won't let the connection ever resume again. Abort, close the connection and go back to trying to open a new connection (in the case of the client side) or wait for new connections from the listener (in case of the server side). In all these loops you have to watch out to not use any indefinite timeouts but rather use a limited timeout and be prepared for the timeout error from this function. Anytime you decide to loop again to go and attempt another operation of connecting to a server/waiting on a new connection in the listener/reading data you also check a global signal if your application send you a shutdown signal. If so don't reloop but stop the loop, clean and  close everything properly and terminate your VI.

It's all a little involved the first time to get everything right but once you have done that system fully you can hack out new servers and clients with robust error handling, resuming and shutdown in a matter of few hours. Basically in TCP/IP (and many other programming interfaces) not every error is fatal and is rather an indication that something perfectly valid happened such as no data yet from the other side, connection lost or remote side has shutdown. These errors should not be ignored but usually interpreted as an indication to try again after some reasonable delay. Unless your application has indicated that you want to shutdown! And to make your application not hang for long periods your timeout for all these functions should be chosen such that you can live with the extra delay they may introduce. If you want your application to shutdown within 2 seconds, you should make the timeouts for all these functions never more than 1 seconds and of course when you detect that you need to shutdown the loop you can also skip the extra delay in the loop to make it not add extra time to the loop termination.

[Froboz]

Thanks for the explanation.