Slow cRIO Deployment in LabVIEW 2009

[JackDunaway]

Here's a screenshot of the CPU usage we see during deployment. 

1. At t=0, the "Run Arrow" is pressed.
2. It takes 5 seconds or so for the deployment window to show up.
3. The deployment window goes away at t=125sec, after deploying 494 items.
4. Just a few seconds later, you can see the executable has begun to run (presence of the yellow high priority items, and it is properly controlling outputs)
5. At this point, the FP of the RT executable is unresponsive, and has not updated since deployment.
6. Also, during this period, the CPU is shaky between 6-10% higher than the steady-state application. It appears to be due to heightened normal priority (white) tasks.
7. Also, during this period, there is ethernet activity (orange "Link Activity" light sporadically blinks/stays lit on cRIO)
8. At t=190sec, we see the FP fly through a "queue" of "deferred updates", at which point it behaves like a responsive FP
9. From t=190 and on, everything happens as expected.

As a side note, the second tab "VIs" on the RT System Manager has "Track VI States" unchecked. As a second side note, the "t=" markers were added to the screenshot using a paint program (So don't take a ruler to your screen and try to make exact t axis measurements!).

Regards,

Jack

Message Edited by JackDunaway (mechelecengr) on 09-14-2009 09:07 AM

[JackDunaway]

My chart shows that our "wait" is now about 65sec rather than my previously reported ~80sec. We have whittled down the deployment in the past few weeks in order to mitigate lost time due to this slow deployment problem. Since our optimizations, we look forward to the cRIO deployment happening faster than ever once these issues are resolved!

[AnthonV]

Hi we are having the same problem using a Desktop Dell PC since upgrading to RT 9.0 from 8.6.1.  I see that this thread has had little activity since 9/14, does this mean that a solution is available or the opposite?

We are finding the exact same behaviour:

1) Click the Run arrow on the front panel of the vi targeted to the PC running LabVIEW RT 9.0.

2) Watch the vi's being downloaded to the target (takes a couple of seconds)

3) Wait in amusement as nothing happens for 30 seconds ('nothing' means that the vi doesn't execute even though the 'stop' button is active on the FP).  I know that it isn't just the front panel that isn't responsive as I can watch the CPU activity on the RT screen and there is no activity assigned to Timed Loops during these 30 seconds (all our code is in timed loops).

4) Executing starts after 30 seconds delay.

5) Stop and start it again without changing any code and this delay doesn't occur.

6) It also happens when a startup exe is created and it tries to run at start-up.

We have also found that this delay doesn't happen for small applications or when using 8.6.1. 

Any help will be appreciated. 

[JackDunaway]

AnthonV, thanks for more details about another platform. We do not know the current status of the solution. Ping, CAR 176549?

[Kristen_K.]

I checked on CAR 176549's status.  It looks like R&D is testing a possible fix.  Depending on how the tests go, I wouldn't be surprised if there is a solution soon. 

Kristen H.

[AnthonV]

Even though there is no solution posted yet, just having found this thread has saved us a lot of time in that we didn't have to rip into our own code to find the cause.

Let's hope there is some light soon.

Cheers. 

[straki]

Hello everybody,

I would like to report the same problem with one exception. I am using the PXI 8196 as HW platform for running the RT code. All other symptoms are pretty much the same...long hang up time after successful completion; 50% of CPU usage on my laptop during the hang up time, which drops down after it passes away and I am finally able to manipulate the front panel of the vi. Is there any solution?

Thank you,

Straki

[straki]

My first reply was based on the information from the first page on this topic. Now I went through the rest....Sorry about that:-)

[xkenneth]

Hi,

Still having the same problem here. Nearly identical to what the original authors posted.

Regards,
Ken 

[JackDunaway]

We have been running 2009 SP1 for a few weeks now, and it appears the problem has gone away. What version are you running, xkenneth?