cRIO VI Called By Reference From Host Failing

[jpcottrill]

Hello,

I am attempting to call VIs on a cRIO by reference from my PC. The VIs are deployed to the cRIO via a source distribution. My initial test case was a VI that simply blinks the user LED on the cRIO. This worked well with no issues by using the following code on the host PC to make the call.

My next step was to add a simple HTTP post request to log data to an API. Shown below is the remote VI on the cRIO. Everything in the orange block was the original code that worked. The http code is tested and working in several other areas. I have also proven the cRIO can see the API by issuing calls from the command line via wget.

When I call this from the host PC, I get an error saying the VI is broken. If I run this remote VI directly from the IDE, it works fine and I see my data in the database as expected. The only way the remote call works is if I first manually click Deploy on the VI which causes it's front panel to open. Having a visible front panel for this is not desired.

What am I screwing up that is causing this to fail as soon as I add in the working HTTP client code?

[Bob_Schor]

Your first example (I'm assuming) is code on the Host that, when runs, blinks an LED on the Target (cRIO, 192.168.135.219).  The second example is code on the Target (again, I'm assuming) that tries to do something on a system with IP 192.168.135.180.  [I'm sorry, I really hate trying to squint and figure out what is going on with teeny tiny pictures of LabVIEW code that I can't examine closely -- at least you don't have hidden wires or Case structures, but woe is me if I want to test run your code and see what it does ...].

Is the second piece of code supposed to live on the Target, and is it trying to "reach back" to the Host?  How does it know the Host's IP (or did you just "code it in")?

Are you trying to develop a Real-Time Project here?  What tasks do the Host and Target have to do?  Are you planning "one-way" or "two-way" communication between them?  How?  Do you know about NI Network Streams?

Bob Schor

[jpcottrill]

Hey Bob,

Thanks for the reply and sorry about the image. I was hoping with the forum's click to zoom feature that it would be good enough given it is a better image than the Labview IDE can provide. Can't wait until we can switch to the latest version and finally get the ability to zoom. Hopefully, the following shows up better.

The first piece of code runs on the host and simply runs whatever VI we pass in dynamically. In this case, it happens to be a remote VI that blinks an LED.

The second bit of code lives on the target and does two things. Inside the orange box it simply blinks the LED. When that is done, it makes an HTTP call to 192.168.128.180 to record data. It doesn't "reach back" to the host. It doesn't know or care about the host running the first bit of code so there is no need for it to know the original host's IP. It just needs to know the reporting IP (192.168.128.180) which is hard coded for this example. The "bundling" part of the code is just setting up a data structure to pass to the HTTP reporting function.

We are developing a simple sequenced project here. The host loops through a list of VIs and dynamically runs them using the first block of code. These VIs can exist locally, or on remote targets such as a cRIO. It can see the results of the dynamic VI based on the input/output contract (Exit Code, Is Passed, Is Failed, Error Out) but otherwise doesn't care what the dynamic VI is doing. The dynamic VI is able to record data to a SQL database via HTTP calls to a web server.

Everything works perfectly until the HTTP call is added to the VI on the target (cRIO). Once added, the remote dynamic call no longer works. Even though the VI is perfectly operational, when run by itself. And I know for a fact the cRIO can see the web server as I can run the same calls from the cRIO command line using WGET without issue. Hopefully this is more clear.

[jpcottrill · Accepted solution]

Solved! Documenting this in case someone else has this issue in the future.

I had some time to review this with an NI Engineer (Chuan) and have this resolved. There were a few more improvements I needed to make to the information I provided. First off, thanks to Bob for pointing out some of my shortcomings of my first post which lead me to finding a couple more omissions I had.

Next, I had the errors flowing through the dynamic VI in the Call By Reference. I re-routed these up to the Call By Reference error in and out ports and received more meaningful error messages.

Doing so led to the following error message...

Being fairly new to LabVIEW and the cRIO, I wasn't keyed in to what may be missing in the build. Chuan immediately pointed out to ensure the highlighted Additional Exclusion options below are unchecked.

After unchecking all of these, I was able to re-build, deploy and had a working system.