LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Deploying to cRIO is effectively impossible.

I am at my wits end. The number of hoops I have to jump through to develop RT applications is insane. The number of times I have seen some form of this error is crazy.

BBSim_0-1701087457989.png

Then I'll lose connection to the cRIO so I'll spend another minute waiting for that.

 

I'm already using a direct usb / ethernet (neither make a difference) connection, with no switches to go through, and the problem persists.

 

It's every. Single. Time.

 

I've read the many threads discussing the same issue, and they all suggest the same things:

  • Clear compiled cache
  • Mass recompile
  • Deploy the built application instead.

And yes, they do - rarely - work. But at this point I'm spending hours trying to test single changes. I've attempted to make as much of the code runnable on the host computer for testing, but I'm at a point where I need to test on hardware. I'm using EtherCAT devices so deterministic code is essential. 

 

Then some other suggestions are on the lines of:

  • Don't use classes.
  • Don't use Networked Variables.
  • Don't use the scan engine.

Well that's great and all, but if I'm not going to use any of the advantages LabVIEW gives me, then why use it? I'd still likely have half the deployment errors.

 

Apologies for the rant, but please, can someone suggest some more material ways I can improve my deployment process.

Message 1 of 6
(1,399 Views)

What is your version of LabVIEW ?

 

I had exactly the same problem while deploying code to a PXI (Phar Lap) with LV2016. It happened to me at every single deployment, for several VIs. So my first solution was to force recompile the "incriminated" VI by removing and recreating a wire on the block diagram. Then I tried again the deployment until the next error. Eventually all VIs could be deployed and it worked… until I modified my code again…

 

I think this problem arises when you combine classes (or maybe libraries) with the option "separate compiled code from source file". What I ended up doing was removing this option for all VIs in my project (Right-click on project root -> Properties -> Project -> Uncheck "Separate compiled code from new project items", then click "Mark Existing Items", select all and click "Unmark Selected Items"). Also ensure it is unchecked for libraries and classes as well (in the library/class properties). So far, after doing that, the problem disappeared for me.

 

Regards,

Raphaël.

Message 2 of 6
(1,381 Views)

Hi Raphaël, thanks for your response.

I am running LabVIEW Professional 2023 Q3 (64 - Bit), but have had similar issues with 32 bit.
I will attempt your idea of turning off separate compile code - however there are a couple times when I use vi's from vi.lib, that are part of locked NI libraries, such as NI_FileType which appear to have it on by default, so I can't turn it off there.

0 Kudos
Message 3 of 6
(1,342 Views)

It only matters on code that you regularly modify throughout your project (and thus that requires frequent recompilation).

Anything from the dependencies can be ignored (unless you also develop your own vi.lib / user.lib / instr.lib tools, which should be managed by their own project anyway).

0 Kudos
Message 4 of 6
(1,335 Views)

Hi BBSim,

 

Did the solution work ?

I am trying to evaluate whether this can be applied as a general guideline for our further RT developments.

Reporting the bug to NI could also be a good idea.

0 Kudos
Message 5 of 6
(1,243 Views)

Hi there,

Apologies for the slow response. I do think that is has improved my situation, but I wouldn't say solved. Deployment is generally more successful, but still far from perfect. 

Thanks for the suggestion.

Message 6 of 6
(1,213 Views)