RT file close function causing disconnect from target

[faustina]

When my application on the PXI Target terminates, it closes serveral files using Close File function.  Now when it is the process of closing I get the "Waiting for the target to respond" message followed by the "Warning:  Connection to target has been lost.".  I didn't have this problem before when I was using LV RT 2009.  Now I'm using LV RT 2015.  The errors suggest a communications problem between the host and the target.  But what communication is occuring when the target is calling Close File function?

[AB@17]

The issue would be with the TCP\IP communication between host and target. As your RT Code is stopped you get this warning..

[faustina]

I've seem to corrected the file issue but I still do have the same problem.  The Target code completes after the Host code and both Target and Host end without any errors.  However, the Target remains running after all the code is completed while the Host stops.

[faustina]

I'm thinking this problem doesn't have anything to do with closing files on my PXI.  There is definately a problem in communication between the PXI and the PC.  I've enclosed a PPT file when I try to access VI States from Distribute System Manager.

[Bob_Schor]

Strange -- I thought I responded to this post (maybe I forgot to click "Post").  My guess is that your code in the PXI is either shutting down or going into some kind of Halt or Error state when the Host says "Time to Quit".

Are you using the "RT Project Model" where you have LabVIEW Project configured with both a Host and Remote section, and you built an RT Executable, set to Run as Startup, on the Remote?  If you do that, then the Host should "expect" to "see" the Target when it starts, and as long as the Target either keeps running or reboots itself (and you patiently wait for that process to occur), the Host should continue to be connected.

So what do you do after you close the Files on the RT Target?

Bob Schor

[faustina]

There are no stand-alone executables in my project.  The main VI for the Target is started by the user and when it has started appropriatly the main VI for the Host is also started by the user.

When it is time to QUIT, even if the main VI on the Host is still running, I get the "Waiting for target to respond" message.

I've inserted probes to find out where the problem lies and it is still with a Close File function.  (see the enclosed PPT file) I've done this same piece of code for other files in the QUIT process on the target and have not had a problem.  Only in this particular location.  It was thought that maybe the filename was not compatible; but I'm running LV 2015 on Win7 on the host and LV-RT 2015 on the target, not Linux or VxWorks.

[faustina]

There are no stand-alone executables in my project.  The main VI for the Target is started by the user and when it has started appropriatly the main VI for the Host is also started by the user.

When it is time to QUIT, even if the main VI on the Host is still running, I get the "Waiting for target to respond" message.

I've inserted probes to find out where the problem lies and it is still with a Close File function.  (see the enclosed PPT file) I've done this same piece of code for other files in the QUIT process on the target and have not had a problem.  Only in this particular location.  It was thought that maybe the filename was not compatible; but I'm running LV 2015 on Win7 on the host and LV-RT 2015 on the target, not Linux or VxWorks.

[Bob_Schor]

So far, you've not provided any code for us to examine (a Powerpoint slide or two does not count -- it limits what we can see to what you choose to show us, which is probably not the source of the problem).

The "dance" of shutting down an RT system must be done carefully, particularly if they are communicating using TCP/IP.  I use Network Streams, which handles a lot of the TCP "busy-work" for me.  When I want to stop my RT system, I do the following:

• Host sends "Exit" message to RT Target.
• Host shuts itself down, including shutting down its end of the Network Streams.  However, it waits 1 second to allow the Remote to read the final Exit message before exiting.
• When RT gets Exit message, it closes its end of the Network Streams, then reboots itself.

Basically, Host tells Remote to quit, waits for Remote to "get the message", then immediately severs contact, preventing any need to "wait for target to respond" (because there is no more contact with the Target).  It then exits.  Similarly, the RT side gets the "Drop Dead" message, kills its connect to the Host, and Drops Dead.

Somewhere, you are (probably) continuing to "talk" between Host and Target over your still-active TCP/IP connection.  Without seeing the VIs of your Host and Target main loops, it is (almost) impossible to tell you what to fix, other than be sure to shut down TCP/IP first.

Bob Schor

[faustina]

enclosed you will find the code.

The problem resides in the final frame of the Sequence structure.  I don't think it is a TCP/IP problem because I can move the TCP Close Connection function in the final frame to outside the frame, having it run after the after the Sequence ends and I get the same problem at Close File function.  LV RT hangs at the call, no errors have be inputted into the function. 

[Bob_Schor]

OK, thanks for including the code.  Here are some thoughts.

• It looks, to me, like this code runs, then stops after closing the file.  If this is running on a Real-Time OS, then it's like the Remote simply stops, hence it might be reasonable for it to respond by doing nothing if the Host asks "Are you there?", i.e. it will appear to be disconnected.
• There's some strange code mid-VI going into the final large While loop.  You open a TCP listener on Port 5000, then immediately close it (the upward-going wire) and start waiting for a connection.  It wouldn't surprise me if it never connected.
• The Block Diagram covers about 10 screens, making it difficult to "see the Forest for the Trees".  One of the advantages of sub-VIs is they pack a lot of (single!) function into a 32x32 pixel area.  If you do go this route, be sure to make an Icon for each sub-VI identifies the function of the sub-VI (a Glyph or two lines of text) so your code will "self-document".

Bottom line -- while there is strange code in your sub-VI, it looks like the code is supposed to simply stop, rendering the Remote unresponsive (and thus probably appearing "disconnected" by the Host).

In our RT systems, we don't let the Target stop -- the last thing it does is to issue commands to reboot itself (and hence start running the StartUp code defined for the Target, which simply restarts the program that just ended, which begins by listening for a TCP/IP connection from the Host).

Bob Schor