LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Deployment to NI 9068 failing

Hi,

 

I'm having a baffling problem with deploying my RT project to the NI 9068 chassis.

 

I get no errors during deployment, but once the system boots up it does log quite a few errors (claiming that every single VI is 'broken', see attachment).

 

Key features of the system:

- 9068 chassis, mounted with c modules:

--- 9411

--- 9421

--- 9472

--- 9219

- Using EtherCAT 

- A dusin AKD drives

- Festo pneumatics

- Touch screen HMI

 

Everything works perfectly as long as I start the system through the host I develop on.

 

I'm looking for any tips on how to make this deployment happen, ideally a check-list of possible sources of error.

 

I'm at my wit's end, and under severe time restrictions. Please help.

 

0 Kudos
Message 1 of 10
(3,590 Views)

It's been a while since I did RT on a cRIO, but I know when I deploy to my PXI, I need to set the VI to "Run as Startup".  Deploying just moves it over to the Remote, but does nothing about getting the code to run.  If you are in Development mode, you can run the Remote code from the Project, but once you disconnect, the code needs to "know" how to run itself, and the Usual Way is for you to tell the Remote that it should run it when it reboots as the Startup routine.

 

Bob Schor

0 Kudos
Message 2 of 10
(3,570 Views)

I have had the same baffling errors with RT executables. I put a long 10 sec wait before the bulk of the real time main app code, but after opening and running the FPGA hybrid mode bitfile and this seemed to help.

 

 

0 Kudos
Message 3 of 10
(3,557 Views)

Hi Bob_Schor,

 

Thanks for taking the time.

 

I did set the main VI as 'Set as Startup', both under the build configuration that I deploy, and directly in the project (right click on vi). 

 

I should perhaps mention that whenever I boot up the system and see that it fails to start up on its own, I then manually start the main VI (for testing other things), and it always warns me that "Another start-up application is already running, and would I like to overwrite this?" (or words to that effect). 

 

I have succesfully deployed a simple test project. Using the VI "RT LEDs", I made the chassis light up as expected. In other words, there's nothing inherently wrong with the deployment process.

0 Kudos
Message 4 of 10
(3,537 Views)

Hi MarkCG,

 

Thanks for your time.

 

We're using the Scan interface, so not sure if the this FPGA hybrid mode will apply to our situation. 

 

Inserting a wait at the right place might work, though. I will certainly look into it in the morning.

 

Please keep the suggestions coming!

0 Kudos
Message 5 of 10
(3,533 Views)

@Ehlert wrote:

Hi Bob_Schor,

 

I did set the main VI as 'Set as Startup', both under the build configuration that I deploy, and directly in the project (right click on vi). 


No.  You want to open the Build Specifications for the Remote, right-click your Build, and select Run as startup.  I'll be honest, I'm not sure of the difference, but we choose Run as startup.  Incidentally, when we finish the Build, LabVIEW informs us that we'll have to reboot the Remote for this to take effect, and offers to Reboot it for us -- I always say "Yes".

 

Bob Schor

0 Kudos
Message 6 of 10
(3,504 Views)

I'm sure I've tried that, but I will give it a another try in the morning and let you know how it went.

 

Thanks again 🙂

0 Kudos
Message 7 of 10
(3,487 Views)

Well, neither inserting waits at boot-up nor 'Run as startup' had any effect at all.

 

I'm back to square one. 

 

Any other suggestions are desperately welcome.

 

Spells, curses and lucky charms accepted as well!

0 Kudos
Message 8 of 10
(3,375 Views)

hi ehlert,

 

i ran into something similar looking the other day.

 

when i wanted to deploy to my crio 9068 i got strange error, that some vi was compiled for a wrong architecture.

the error message was not helpful.

first image in this post http://forums.ni.com/t5/LabVIEW/Can-t-deploy-Builds-to-cRIO-after-Labview-2014-SP1-F3-update/td-p/31...

my lvrt error log had similar entries like yours, all VIs broken or somehting.

 

two suggestions, set autorun to false with MAX, restart, and then try again to deploy,

or/and delete the startup.rtexe und such in /c/ni-rt/startup

 

maybe this helps you too

 

:cheers:


If Tetris has taught me anything, it's errors pile up and accomplishments disappear.
0 Kudos
Message 9 of 10
(3,341 Views)

jwscs:  "Compiled for a wrong architecture" sounds right to me, too.

 

I have some code that runs on several different cRIO racks, and it depends how I open each .vi before I deploy, whether it will work or not.  In my case, I need to open each .vi in the context of the target cRIO rack and save it back to be certain.  It actually only matters if I've opened the .vi in another context since saving, but it's easier to be safe.

 

That said, I suggest you check a few things:

* every .vi that you use (especially the ones in the error log) are in your project under the rack, but NOT under the FPGA.

* load each .vi by double clicking the reference in the cRIO (if it appears more than once).

* if you 'run' the .vi without deploying, it should work, but in interactive mode.  It does deploy, but slightly differently.  See if it works.

  - you can usually do this with any .vi, not just your top-level one, so try some simple sub-vis.

* (if you can't get it fixed other ways) drag any .vi in Dependencies into your cRIO.

* make sure simulation is off.  It's an FPGA Target option (Debugging).

 

BTW, the run-as-startup means it will run after a power-cycle.

___________________
CLD, CPI; User since rev 8.6.
0 Kudos
Message 10 of 10
(3,243 Views)