LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Real-Time Startup Application with cRIO in Hybrid Mode

Brandon:

 

I just got a hold of a 9024 last Friday, and I put it on a 9104 today. I opened up the code, installed the Garmin and Microstrain drivers, and attempted to deploy. I don't have the vision libraries required for the camera controls in the global variable subVI, so I had to remove the two subVIs in your main VI that used it. That's the only change I made.

 

I successfully built the real-time application, and then selected "Run as startup" from the context menu. The system deployed with no issues. See software configuration and deployment window:

9024_SW_config.pngdeploy_status_window_successful.png

 

As best as I can tell, we're running identical software configurations. Since you're on NI-RIO 3.6.0, I assume you're using LabVIEW 2010 SP1? (That's what I put this on).

 

What stage in the deployment progress does the conflict resolution window come up at? Perhaps it will give us a clue.

 

Here's my next thought: since what you have configured should work, there might be something up with the current software installation. Try reformatting the controller from MAX, reinstalling the software/driver package on the cRIO, and re-deploying the RT startup app.

 

If you want to see if the subVIs make any difference, you can also try removing them and re-deploying. I took out "State Machine" and "Remote Main (RIO)."

 

Either way, everything should work. Since you can get it all running from the development environment, I'm hesitant to blame the cRIO itself. I think the software/driver package is the most likely culprit.

Caleb Harris

National Instruments | Mechanical Engineer | http://www.ni.com/support
0 Kudos
Message 11 of 26
(1,064 Views)

When I build and deploy the RT Startup App it does the same thing. I get the error when I then run the host VI. That's what throws the error window that I previously posted.

0 Kudos
Message 12 of 26
(1,057 Views)

Brandon:

 

I guess I'm a bit confused, then. In your original post, I thought you said your issue was when you created the RT startup app?

 

So, to clarify, you're getting the issue when running the "Main (PC)" VI on the host computer?

Caleb Harris

National Instruments | Mechanical Engineer | http://www.ni.com/support
0 Kudos
Message 13 of 26
(1,045 Views)

I'm getting the issue when I run the "Main (PC)" VI on the host computer. However the issue only occurs when I create the RT startup app, not when I run the RT code manually on the cRIO. Sorry for the confusion.

0 Kudos
Message 14 of 26
(1,033 Views)

Brandon:

 

Ok, I think I get it, but let's make sure I'm not still confused... Robot Sad

 

From what I understand, you can build and deploy your startup app, AND you can run the host VI from the project, correct?

 

The issue is occurring when you run the PC host VI while the RT app is running on the cRIO, but not when the RT code is being run manually on the cRIO. I'll run it that way and see if I can't figure out what's causing the conflict.

 

 

Caleb Harris

National Instruments | Mechanical Engineer | http://www.ni.com/support
0 Kudos
Message 15 of 26
(1,025 Views)

That's correct. That is the issue I am having.

0 Kudos
Message 16 of 26
(1,022 Views)

Hi

  Iam using crio controller, in real time vi i have opened reference for fpga vi,used invoke node in "run"method.

  created start up app for real time vi,included fpga vi as source file, build it and deployed it. after rebooting the crio controller only the real time vi is running,fpga vi doesn't.

 

Iam using fpga vi for only two fns

->to receive analog input

->to trigger a digital output

 

I have used read/write control  in real time vi to do all the calculations part.both the vi's run perfectly if i run it manually.the other problem i was facing is without start up app also i have to run both the vi's seperatly .

Eventhough Iam using invoke method to run the fpga vi in target from the real time vi it doesn't. i couldn't get the analog value from read/write control.                                               

is there anything else i should do?

 

 

kindly reply,

 

regards,

temin

0 Kudos
Message 17 of 26
(1,012 Views)

Brandon:

 

Ok, I got everything to deploy at the PC level as well, and I still can't get a deployment error to come up. Here are my thoughts thus far:

 

 - The deployment error is in regard to the scan engine service running on the controller, not the FPGA. Whatever the issue is, I'm pretty sure it's going to be relegated to the controller.

 

 - Have you performed a reformat/reinstall of the controller software? I know I recommended making sure  you had the scan engine software package installed on the cRIO, but we need to wipe and reinstall the software to ensure that there aren't any glitches or artifacts in the software configuration that could be causing this.

 

 

Does this occur when running both the PC executable AND the VI? I got it to deploy successfully with either.

 

There is one other thing you can try. Since the RT application should already have deployed the RT libraries on the controller, you can go into the build specification for the PC application and set it to not deploy the libraries hosted on the cRIO. Based on your original screen shot, it looks like those are the libraries causing the error on deployment. If they're already deployed on the cRIO, we should simply be able to connect to them from the PC based variables. You can get to the variable deployment settings in the "Shared Variable Deployment" section of the build specification.

Caleb Harris

National Instruments | Mechanical Engineer | http://www.ni.com/support
0 Kudos
Message 18 of 26
(1,004 Views)

Termin:

 

Have you tested your cRIO with an example analog input or output example?

 

If you run your real-time VI in highlight execution mode, does the block diagram return any errors? It should be running the FPGA VI, so if that operation isn't succeeding, then it should be returning an error.

Caleb Harris

National Instruments | Mechanical Engineer | http://www.ni.com/support
0 Kudos
Message 19 of 26
(1,002 Views)

Hi charris thanks for your reply,

 

        If i run the real-time VI in highlight execution mode, the loop runs for 1 iteration then returns a error dialog box "communication error occurered" ,if i press ok then another dialog box appears "warning:connection to the real time target has been lost" if i press ok then the real time vi stops running but the output of the first iteration is still there ie., in my case according to the logic of block diagram DIO 0 is high. even after real time vi stops running DIO 0 is still high.

 

so this is what happened when i deployed the real time vi as a stand alone real time application.. the DIO 0 was either continuosly high or continuosly low...depending upon the logic of the first iteration this has happened.

 

i have noticed this problem also- if i run the real time vi manually without highlight execution mode,the first time if i try to run it, the deployment will fail by popping  up the same errors.however if i run the vi again it will deploy successfully.

 

how to solve this problem... i desperately need to run this as a stand alone real time application. kindly help

 

regards,

Temin 

0 Kudos
Message 20 of 26
(996 Views)