First time deploying standalone application - questions about front panel objects.

[CaseyH_UI]

This is my first plunge into standalone deployment, so please bear with me.

I've been peppering the forum with questions about this project for the last several weeks, and I've gotten some very helpful insights - thanks to all who've helped.

I'm programming a cRIO-9045 as a headless data acquisition system. My application is built from the "continuous waveform acquisition and logging" shipping example with a queued message handler, so I've got the critical stuff communicated to host UI via a network stream and (only a couple) of network-published shared variables. The whole thing will be on a moving vehicle, to which I'll be connecting over WiFi. I'm not confident my connection will remain uninterrupted, so running the RT target VIs interactively isn't going to work. I'd like the RT to remain running headless in the event that I lose my network stream on the host end. 

I'm familiar with windows-hosted data acquisition, and I've carried some of my bad habits from programming in that setting with me to RT applications. Namely, the use of front-panel indicators or controls as a lazy means of signaling / throwing flags between asynchronous loops. I've kept it to a minimum, and I'm sure that I can get my project cleaned up in a matter of hours.

After reading through the cRIO dev guide (skimmed the second half), I haven't been able to figure out the answer to a couple of questions:

1. If front panel objects don't exist when running the application as a standalone executable on the RT target, what about all of the controls/indicators used as terminal connectors for subVIs? Is there any other way to pipe data in and out of subVIs?

2. As a poor-man's time-base synchronization approach, the RT VI pulls a GPS-derived timestamp from the FPGA whenever it receives a software trigger to begin an acquisition. That's being accomplished using read/write nodes. I can't find any documentation on whether the front panel indicators/controls to which those nodes are linked continue to function when deployed on a standalone target. I assume not, in which case, how to do I get data from the FPGA to the RT target?? All of the NI Timekeeper examples dealing with the trading of timestamps between targets use front panel objects on the FPGA side and read/write nodes on the RT side. Are those examples all non-functioning outside of interactive mode?

3. In my ignorance, have I missed any other workaround? It seems that, by definition, a front panel requires an interactive session with the host, which in turn requires an uninterrupted connection to the host, so it's probably wishful thinking... I have no problem with running the VIs interactively. They perform fine, and I can tolerate some non-determinism since I'm just performing buffered acquisition and logging. But is there any way to prevent the RT VI from stopping in its tracks if the network connection gets broken?

Thanks in advance

[Artem.SPb]

1) SubVI work absolutely correctly and in realtime. Even local and global variables work correctly.

2) the interaction with the FPGA occurs again through the controls / indicators or via DMA channels.

All your questions are removed by the simplest examples. which are in the standard package. There is also an standalone application examples. Everything that is configured for the controller (in your project) can start up there and continue working after the loss of communication.

[wiebe@CARYA]

---

@CaseyH_UI wrote:

1. If front panel objects don't exist when running the application as a standalone executable on the RT target, what about all of the controls/indicators used as terminal connectors for subVIs? Is there any other way to pipe data in and out of subVIs?

---

When building a normal executable, front panels are not included when not needed. Of course sub VIs will keep working! RT systems did not get GUIs until a while ago, before that it was possible to use sub VIs (again, of course).

The mechanism of passing parameters to a sub VI does not go through the front panel. It's just that the front panel is the programmers interface to connecting controls and indicators to the connector pane (in CG LabVIEW, as I understand NXG does not require controls to be on the front panel)

---

@CaseyH_UI wrote:

2. As a poor-man's time-base synchronization approach, the RT VI pulls a GPS-derived timestamp from the FPGA whenever it receives a software trigger to begin an acquisition. That's being accomplished using read/write nodes. I can't find any documentation on whether the front panel indicators/controls to which those nodes are linked continue to function when deployed on a standalone target. I assume not, in which case, how to do I get data from the FPGA to the RT target?? All of the NI Timekeeper examples dealing with the trading of timestamps between targets use front panel objects on the FPGA side and read/write nodes on the RT side. Are those examples all non-functioning outside of interactive mode?

---

Same goes for the FPGA. Reading\writing controls\indicators from the "front panel" of the FPGA is an entirely different mechanism. But like sub VIs it will still work in an executable.

BTW That FPGA code is always compiled, the way it runs in an executable is exactly the same as running it in development environment. You can check, there's no recompile needed.

---

@CaseyH_UI wrote:

 3. In my ignorance, have I missed any other workaround? It seems that, by definition, a front panel requires an interactive session with the host, which in turn requires an uninterrupted connection to the host, so it's probably wishful thinking... I have no problem with running the VIs interactively. They perform fine, and I can tolerate some non-determinism since I'm just performing buffered acquisition and logging. But is there any way to prevent the RT VI from stopping in its tracks if the network connection gets broken?

---

A RT system with a front panel should not stop running when it has no physical front panel (e.g. a connection). The VI simply runs and a connection just opens a view to its front panel. That should not interfere with the operation of the VI. Haven't tried this in a while, I'm not completely convinced there will not be any interference. There might be some CPU jitter when connecting\disconnecting, but it should be minimal.

You might be overcomplicating things: expecting things not to work, while you should be expecting things to work. On the extreme, both ways are bad, but I think you need to shift a bit to "it might just work". And then test if it does of course.

[CaseyH_UI]

Thank you. All very helpful answers. Just one point of clarification:

---

A RT system with a front panel should not stop running when it has no physical front panel (e.g. a connection). The VI simply runs and a connection just opens a view to its front panel. That should not interfere with the operation of the VI. Haven't tried this in a while, I'm not completely convinced there will not be any interference. There might be some CPU jitter when connecting\disconnecting, but it should be minimal. 

This sound promising. At the risk of repitition, I want to make sure I'm not providing a confusing description of my use case.

I would like to have the option of running the VI on the RT target interactively (by clicking run from within the front panel or block diagram), and without the necessity to maintain the connection to keep things running. When I've tried this, I start the RT VI, disconnect  the ethernet cable unintentionally, and receive the "warning. cRIO disconnected..." (or similar) message and my VI stops on the host. That's fine. But when I reconnect ethernet, I'm unable to re-initiate my network stream to the host UI. I had assumed that to occur because the RT target VI had terminated along with the network connection, but maybe I was mistaken? It sounds like I was, which is good news.

In the last hour, I stumbled across KB article that suggests I disconnect from the RT target from within the project explorer. Let me try that.

[BertMcMahan]

Throw a "Blink the LED" loop on your RT target. You'll know if your whole program stops running when disconnected or not. Some (all?) of the cRIO chassis have user LED's on the front somewhere.

Your issue may be that your Network Stream disconnects and returns an error, stopping the program. I haven't needed to do this exact thing before, but I'd suspect you may have to "handle" the network stream dropping out if it's been set up by the host. I don't know if there are automatic buffers that try to fill up if the stream dies or not, but I'd suspect not until I saw something saying otherwise.