Windows VI does not start RT vi, and I must use Abort to stop them.

[Dhouston]

Hello all.  This is a two-part question.  The first part is an age-old issue, but it just will not be solved for me.  I have a vi developed on a Windows PC that is supposed run the project on my RT target.  So I open and run the vi on the Windows PC.  Nothing happens.  The run arrow turns black, but no indicators update.  I have to open the RT vi and run it.  The RT vi has indicators, and when I run it, those indicators will update.  I have my Build Executable set to "Set As Startup,"  so why do I have to open and run the RT vi before the Windows vi starts updating.

On the flip-side, if I open the RT vi by itself and run it, the vi won't update.  I believe the reason for this is because I am using Network Streams between the RT vi and the Windows vi.  So that may make sense that both vi's need to be open before I see any indicator updates, although this goes back to my problem of why I need to manually run the RT vi when it is supposed to run automatically.

So to clarify, my process is:  Open and run Windows vi-->Open and Run RT vi-->both VIs update and run.

If I run either VI by itself, I get nothing.  They used to be able to work individually before I used Network Streams, although I still had to open one, then the other.

Now the second part.  I have to use the Abort button to stop the VIs.  I have a stop button on the Windows VI, and use a network shared variable to link this button to both my RT vi and the FPGA vi.  When I click the stop button, I see the indicators on the Windows VI and the RT vi stop updating, but the Run arrow stays black.  I have to click Abort on both VIs to really get them to stop.  I've used probes to check the values of the Stop shared variable, and it is True in every spot I use the variable when I hit the Stop button.  The only place I can not check is the FPGA, but I am using a Read-Write control in my RT vi to stop the loop in the FPGA vi since I can't put a network shared variable there.  With all this, I am not understanding why I have to keep using Abort to stop my program.

[Hooovahh]

Well your network streams have a -1 on the write timeout on the RT side, meaning it will wait forever (causing the loop to not iterate, and controls to not be read or written in that loop) until that node finishes executing which will only happen when that function returns.  That being said I would think that if no valid connection is made it would just error out and return immediately.  What you likely need is a retry mechanism that tries to connect to the host continually trying to reestablish a connection.

Similarly your host has a read with a -1 timeout meaning it will never read the stop button if that timeout never occurs.  Again a retry mechanism might help trying to reconnect every second or so if a connection was lost for some reason.

What might help find these types of issues is proper error handling.  Where errors from one iteration might stop the loop, use simple error handler, or pass the errors with a shift register to the next iteration.  Also probing around in the running VI should make it obvious that a timeout is or isn't happening, and that your controls are or aren't being read.

As for startup applications, this might be disabled in a few places.  I would check MAX and make sure that RT startup applications aren't disabled.

I use network streams all the time on RT applications and can run with or without them, and with or without a UI.  Having this technology in a project alone shouldn't cause other features to stop working.

[Dhouston]

Thank you for the information.  I looked into the disabling situation.  I do not see this "Controller"  tab that MAX help speaks about.  I did see that the DIP switch for NO APP on my controller cRIO-9014 is set to OFF, so there should not be a problem there.  I did not change any settings in MAX to affect RT targets, so unless startup apps are disabled by default, nothing should have happened to disable this.

I thought Network streams automatically retried to make connections if an endpoint connection was lost.  This is what I understood from the cRIO Full Development Guide.  So you are saying I have to manually code a retry mechanism?  What was the guide talking about when it said network streams retry forever to make a connection?  The statement is on page 63 under Create the Endpoints.

[Bob_Schor]

The more "loops" you have, the more attention you need to pay to the process of an orderly shutdown of your program.  When you are talking about a Real-Time routine, which typically involves a Host and a Remote running the RT code, you want to shutdown both the Host and Remote.

Here's how I've configured one of my RT Projects.

• The RT side is set to "Run on Startup".  The first thing it does is wait for the Host to make the required Network Stream connections.  I typically give 15 seconds for this to occur, and if it doesn't, I simply loop again.  Once the connection is made, the RT code enters its main processing loop.
• Similarly, when the PC side start, it tries to connect with the RT's Network Streams, again with 15 second timeouts.  Here, if it fails to connect three times in a row, the Host exits with a message "Be sure the RT side is running".
• Shutdown is initiated by the Host.  It sends a message to the RT side telling it to shut down.  The RT side closes what it needs to close, sends an acknowledgement back to the Host, then reboots itself (so it will be ready for the "next time".
• When the Host gets the acknowledgement from the Remote, it closes the Network Streams, cleans up after itself, then closes all of its parallel loops.  How you do this depends a bit on how your loops are structured and communicate with each other.  Once all of the loops have stopped, the program will simply exit.  No Abort VI should be needed -- if you do need one, then you almost surely have a loop or a Clone VI (running in a loop) that hasn't been properly stopped.

Bob Schor

[Dhouston]

Bob_Schor.  Thank you for that.  I just had the absolute weirdest thing happen.  If you will notice in my Windows Main VI, I have the Network stream set to read 10 elements.  Well, I didn't mention that the values coming from the stream were all squirrely.  I was getting some kind of "sequential ladder" of values, with each number going into a different indicator sequentially.  I changed the read element number from 10 to 3, and the values synced up with the values from the RT vi.

The miracle and relevance of this is that doing this made the VIs work with the Stop button!  So now I press the Stop button and the VIs stop like they should.  Why in the world would changing the Network Stream read value affect how a VI runs or stops?

So now that leaves the startup problem.  I'm looking into both your and Hooovleh's solution and see what happens with that.

[Bob_Schor]

Confession -- I tried to answer your question "in a general sense", so I didn't look at your code.

A possible explanation for your Network Stream conundrum is that it is really a stream.  If you put in 10 elements but only take out 3, then the Stream isn't empty.  So lets say you put in one series of 10, then stop the Sender.  The receiver takes out 3 (leaving 7), three more (leaving 4), three more (leaving 1), then hangs, waiting for another 3-some.  Oops ...

Bob Schor

[Dhouston]

I used a Network Stream Property Node to check for a connection, and put a 1500 value for the timeout in my Windows VI.  When I run it, the Boolean never lights and I do get an error.  However, if I open up my RT vi, then run the two VIs in sequence (Windows vi-->RT vi), the Boolean lights up and things proceed as normal.

So this brings me back to one of my original issues.  Why do I have to open the RT vi when it should be running already?  It also is weird that when I run the Windows VI, I get a deployment screen showing everything getting deployed to the target.  Then when I run the RT vi right after that, I get the same screen, even though it says <already deployed> for all the shared variables and such.  Why is there a double deployment?

[Hooovahh]

---

@Dhouston wrote:

TI do not see this "Controller"  tab that MAX help speaks about.  I did see that the DIP switch for NO APP on my controller cRIO-9014 is set to OFF, so there should not be a problem there.  I did not change any settings in MAX to affect RT targets, so unless startup apps are disabled by default, nothing should have happened to disable this..

---

If you select your controller under Remote Systems in MAX, then go to the System Settings tab, there should be a setting to disable RT app on startup.  This should be off by default.

http://digital.ni.com/public.nsf/allkb/7BE1A1F4363C0465862569A6000319F9

[Dhouston]

Attached is a screenshot of my MAX screen.  I still do not see this setting, unless it has a name which is non-intuitive.

[Hooovahh]

No you're not crazy, that's where it is on my controller.  Maybe that controller can't be disabled with software, and only though the dip switches.