Slow cRIO Deployment in LabVIEW 2009

[JackDunaway]

When I run RT code in development mode, I have noticed that there is a very long pause (90-100 seconds) between the time the code deploys and when the application actually starts running. This is new for LabVIEW 2009 - it did not happen on LV 8.6.1.

Also, when running the VI for a second time, there is no new file transfer because the target code on the cRIO matches the source, and the app starts running in 5 seconds. However, if a change is made in the code, or if the RIO is rebooted, and new code has to be deployed, the long wait comes back again.

Anyone else seen a wait like this?

[JackDunaway]

The total amount of wait seems loosely proportional to the total number (or total kB?) of VI's deployed. With 47% free memory after deployment, the wait is ~90-100sec. With 70% free memory, the wait is ~10-15sec.

A small VI can be deployed and run with "virtually no wait" - it's a very fast deployment.

Keep in mind, when I say deploy, I mean press the "run" button on the RT FP. I'm not talking about building a rtexe and deploying it as a startup app.

This has been verified using two computers (one Vista, one XP) on two cRIO 9014's.

[Kristen_K.]

Hi mechelecengr,

 Is the delay during deployment (when the green status bar is going across) or after deployment and before running?  

Also, how big is the VI and which version of the RIO driver are you using? 

Kristen H.

[JackDunaway]

Using NI-RIO 3.2.0.

I am not deploying one VI... it's a top level VI that has a few hundred subVI's. The total size of the full project is dozens of MB's.

The delay happens AFTER it has been fully deployed (in other words, the deployment window goes away since "Close on sucessful completion" is checked), but BEFORE the top level VI begins to run.

The length of this delay seems nearly equal to the amount of time it took to deploy. Things that deploy in about 10 seconds have about an additional 10 second delay, things that deploy in about 90 seconds have an additional 90 second delay. In other words, the time to deploy in 2009 is approximately double that of 8.6.1.

My thoughts: 1) It is "redeploying" a second time, but without visual feedback, or 2) it is doing a secondary verification of the original deployment. Not based on fact, but this may trigger a response from someone who knows what's going on here.

[Kristen_K.]

Hi mechelecengr,

How are you determining when the VI begins to run?  If you turn on highlight execution, is the delay after the "deploy complete" message and before the data begins flowing throught the wires on the block diagram?

Kristen H.

[JackDunaway]

If I deploy with Highlight Execute initially turned on, the very first "orb of data flowing through the wire" does not even move until the "wait" has expired.

Timeline:

1. Turn on Highlight Execute 

2. Click "Run" arrow

3. Wait about 100sec to deploy the top level project and hundreds of VI's

4. Wait about 100sec (this is the NEW wait that we have never seen until using LabVIEW 2009)

5. See the first orb of data flowing

Regards,

Jack

[JackDunaway]

I am absolutely positive that I have not made some change in my code that makes the code hang up for 100 seconds. There are no new intensive or inefficient algorithms. And remember: the code deploys and begins executing VERY quickly (~5 seconds to deploy, and 5 seconds to wait, then it's running) on subsequent runs after the first deployment, as long as I do not reboot or change the code.

There's one more way that I know the code is not yet running until after the 100 second wait: the very first code to run is an initialization state machine with an indicator on the current state, and it does not change to the second state until after the 100 seconds has expired. However, on subsequent runs, the second state shows up about 10 seconds after pressing Run (5sec deploy plus 5sec wait... with both of those times being reasonable compared to 8.6.1).

Finally, keep in mind that the 100sec deploy is comparable to 8.6.1. It's just the additional wait that's new.

I cannot give any further information. Please keep me informed on what you find - thanks Kristen.

[JackDunaway]

Ping. 

Alright, I have a few more helpful pieces of information:

1. During the wait, the CPU usage on my host laptop is just fine, but LabVIEW is very unresponsive. For instance, while waiting, I cannot edit another VI, or even right click the BD and get a palette to come up.

2. During the wait, the CPU on the RT is around 10-15%, mostly normal processes (white)

[devchander]

Hello mechelencengr,

Can you please share an additional information?

What kind of functions ( for example: types of express VIs) do you use the most, in your application/VI?

Will try and reproduce the scenario that you are facing

Regards,

Dev

[JackDunaway]

There's some network communications (TCP and UDP), some serial VISA, some FPGA deployment and communication.... typical things you would find in embedded control. I have even diagram disabled very large portions of the code that contain most of the functions, and the wait is still present (although abbreviated, but still loosely proportional to the amount of code deployed).

Are there any functions that you would expect to cause the RT to be delayed for a very long time on the first run, but get up and running very quickly on subsequent runs? If it ran slowly EVERY time, I would point fingers at our code (which is what we did for about two days).

Thank you for all your help! I hope you're able to reproduce the problem.