compact field point slow to start

[MarkCG]

Sounds like a memory leak . What is the timescale on that graph? Maybe the memory allocation used by your application is expanding to the maximum available that is not taken up the RTOS and other services?

[Alisha_P]

Hi iTm,

I've been looking over some of the previous posts and doing a little research.

From what information I can find, a packed project library is currently downloaded to the target as separate VIs rather then a whole unit so I wouldn't think that would be causing the problem (i will see if I can verify this).

How are you using the packed project libraries in your application? (Do they contain your LabVIEW classes? What kind of code is in the library?)

Have you had the same start-up results when running the application on a cRIO (just curious if you've tried it since you mentioned a cRIO in your last post)

[Timmar]

Mark,

This is definately not a memory leak (In my code anyway),

It does this memory climb before a single wire of code is executed.

Once executing the memory is stable.

[Timmar]

Alisha,

Apart from extensive use of Labview Classes, I haven't done anything fancy in my build.

Include Main_.VI and let the builder figure the rest.

Strip unused.

I only mentioned packed library because I see it in the list when I deplay the .rtexe.

The cRIO 9075 behaves the same way (No surprises, it is almost identical spec to the cFP) although it feels like it deploys faster and is a little more stable.

The only place I actively use libraries is in the Network Published shared variables, Technicaly I guess classes are managed as libraries.

[Timmar]

P.S. I don't see this behavior when I build the same code for a PXI target.....

It could be that we are comparing a 2.5 GHz Dual core against a 400 MHz power PC (Theoreticaly 12x faster), I would still expect a 15 second startup delay.

[Timmar]

Alish,

Have you got any further in your research,

I am now under pressure to Drop NI cFP and cRIO hardware If I can't get this resolved.

Thanks

[Alisha_P]

Hi Timmar,

I haven't heard any other reports of this specific issue.

Have you tried paring down your program, perhaps replacing the packed project library or some other complexities, to see if anything drastically reduces the start-up time?

Overall, it sounds like its a performance issue; my guess is that the cFP and cRIO 9075 don't have the memory/processing speeds to start up your application as timely as you'd like. If you need higher start-up times, my recommendation is to move to a higher performance cRIO or PXI. 

If you need more in-depth assistance with this, I recommend contacting our support team more directly.

Good luck with everything!

[Timmar]

Thanks Alisha,

Just to be clear, I'm not using a packed library,

I am using a collection of 30 or so Labview Classes,

It is these that appear to be taking the time to load.

I have an equivalent GOOP application that doesn't have this problem.

My suspicions are that they are being treated as packed libraries and that they are being unpacked each time it starts.

I would like to find out if my suspicions are correct and if so, if there is a setting/workaround to prevent this.

Do you have acees to the labview creators to ask them "How it works"

CRIO offer at best a doubling of CPU power Cost changes from $1700, to $7300. These to devices aren't even in the same league, and at best \i could only expect my boot time to change from 5 minutes to 2:30.

PXI are not an option as I need low power and harsh environment specifications.

My best alternative at this stage is an embedded PC, so.. no more Business for NI hardware. 

Tim L

[Alisha_P]

Hi Tim,

It's very difficult to help you with this level of a problem over a forum post. Understanding of what is happening probably requires a thorough knowledge of your application as well as more direct conversations about possible tests.

If you'd like further assistance in troubleshooting this issue, I strongly recommend contacting NI support at 1-866-275-6964.

[syang]

I guess we are on the same boat...

My company develops products mainly based on LabVIEW + cRIO. 

During our upgrade from LV8.6 to LV2011 last year, we found that the load time for our cRIO executables (.rtexe) has increased drastically... about 30sec in LV8.6 vs. 3min45sec in LV2011 to be exact...

I had spent a lot of time on this issue, even got the NI staffs came to our company to work on this altogether for a couple days, it seemed that we reached the conclusion it is what it is in 2011.

my team product is not using LVOOP, but it has 1200+ VIs and the rtexe is about 12~13MBs, which takes almost 4min to load on a cRIO 9014 controller.

the other team tested it with cRIO 9025 (more cpu+mem), it started faster, but still unbelievably slow.

I also monitor the cpu+mem usage during load time. i observed the exact same thing as you posted. during load time, cpu is almost always @ 100% (this makes sense), but memory climbs up really slow: starting @ 35mb then operational @ 110mb (takes about 3+min).

just to share the information i have, hope one day this can be addressed and solved.