Deploy To Compact Rio

[ajsdwilson]

I have deployed a simple VI to my CRIO to ensure I could do it...was feeling great because it went easily.  Now, I want to move my more complicated program...when I drag it down to the AVC Chassis, it loses all of the SUB VI's.  There are all kinds of help files and such, but after sifting through so much of it, can't figure it out.

I want to send the 'Main.VI" to the AVC CRIO...but it says it can't find all of my second-party VIs.  The MAIN.VI runs great if I run it through the RIO from my Laptop.  Lost!!!

[natasftw]

If your main.vi is under "My Computer," you're not running it from the RIO.  You're running it directly from the laptop.  Only things that are under the chassis will run on the RIO.  They can be run either interactively (hitting run while on your laptop) or setup as an executable and sent to the RIO to run on their own.

We'd need to know a lot more about your third-party VIs you're hoping to send.  Keep in mind, the RIO runs autonomously.  It is its own computer.  If it doesn't have the files you're trying to use, it won't work.  You generally want to develop your application under the chassis the entire time you're developing.  It really doesn't make sense to develop under "My Computer" and then drag down to the chassis.  They're different systems and operate different ways.

With these third-party VIs, what are they doing?  Are they making calls to dll's that you'd need to include?  Are they making calls to ActiveX that you couldn't pass down?  Have you tried dragging the subVIs down under the chassis as well?

[ajsdwilson]

Sorry...should have clarified.  We had begun development of the 'MAIN.VI' prior to purchasing the CRIO, so the development always remained on the PC...I'm new to Labview and CRIO, but have been making progress.  Everything works fine on the PC, but I need to put it onto the CRIO...lots of good information about to deploy when it is developed under the CRIO, but struggling to figure out how to move it from the PC to the CRIO.  I suspect the problem isn't with the SUBVI's, I suspect it is because I don't know how to transfer it from one environment to another.  I did a simple one on Friday, moving a VI that didn't call any other VI's and moved/deployed it to the CRIO...so, I know it works...just don't know how to deploy a more complicated VI. 

[ajsdwilson]

I guess the easiest way to summarize...how do I relocate a fully functioning VI, along with it's applicable DLLs and other required parts, from a PC to a CRIO.  Is there a function that pulls it all together so you can send it to the CRIO without the MAIN.VI becoming inoperable?

[RavensFan]

I don't think you can run .dll's on a cRIO because I a cRIO is running a Windows OS.

[natasftw]

---

@ajsdwilson wrote:

 I suspect it is because I don't know how to transfer it from one environment to another.  I did a simple one on Friday, moving a VI that didn't call any other VI's and moved/deployed it to the CRIO...so, I know it works...just don't know how to deploy a more complicated VI. 

---

This is not a sufficient test to show your theory.  This is similar to saying "I don't care that Bob is allergic to peanuts.  He's not dying due to eating peanuts.  I've fed him grilled cheese before and he lived just fine so I know he can eat."  Your simple test had almost nothing to do with what you're actually wanting to do. 

You don't want to develop for a cRIO by developing on the PC, ever.  It simply doesn't make sense.  The cRIO is going to be running some version of a RTOS and not Windows.  Functions that you build relying on the Windows OS won't function.  There's no amount of learning how to change the environment that will make sense here.  There are different tools that are available in each environment. 

This is what Ravens is referring to: http://digital.ni.com/public.nsf/allkb/2EA49B05E67DDECF86256F9A006FB315  Depending on your target, the dll itself could be the problem.  You need to have it compiled for the target you're working with. 

[RavensFan]

A working link

http://digital.ni.com/public.nsf/allkb/2EA49B05E67DDECF86256F9A006FB315

[ajsdwilson]

Thanks...it is our first project and the cart came before the horse, that is why we are in this situation.  We knew we had to get the programming started, but the CRIO was going to be delayed while some other pieces of the project came together.  Let me see if I can get this figured out from the provided data...I agree, should have been developed correctly, but this situation didn't really allow it.