compact field point slow to start

[Timmar]

I have deployed an application onto a cFP-2200 and a cFP-2100 and they both take about 2 minutes to start.

My application is based entirely on labview classes, lots of override methods, some up, some down.

I put some diagnostic code that timestamps each step,  the delay happens prior to the sart of execution.

Deployment download in development mode is of course slow, but after completion, it starts within 5-10 seconds.

Any insight?

iTm

[Zach-H]

I'm assuming you've set the application to run at start up correct? In that case to start the application you're actually restarting the controller as well. 

I believe the time delay you're noticing is the boot time on top of the start time. You could verify this by hooking up a null-modem serial cable and watching the console out of the cFP. 

[Timmar]

Zach, Thanks for the insight, I forgot about using the console

After A struggle, I got the info,

My Application uses COM1 (The Console), Enabling it, Crashed my App.

I was able to get hold of a 2220 which has 4 ports.

Here is what I see using hyper terminal

---

Loading LVRT...
* Loading nirtdm.out: nirtdm
* Loading nimdnsResponder.out: nimdnsResponder
* Loading vxfpsup.out: vxfpsup
* Loading tsengine.out: tsengine
Time sync source: rtc now active
* Loading nisvcloc.out: nisvcloc
* Loading niDiscSvc.out: niDiscSvc
* Loading RTWebServer.out: RTWebServer
System Web Server started
* Loading mxssvr.out: mxssvr
* Loading glogos.out: glogos
* Loading nisysrpc.out: nisysrpc
LogosXT server is successfully Loaded.
* Loading taggerrt.out: taggerrt
* Loading niserial.out: niserial
* Loading c:\ni-rt\system\FPLVMgr.out: FPLVMgr
* Loading sysstatepublisher.out: sysstatepublisher

Startup Application: /c/ni-rt/startup/WBCore2v0.rtexe

[TL: 2+ Minutes Pass, no activity]


Welcome to LabVIEW Real-Time 10.0.1

[TL: Application starts]

---

It is easy to see where the latency from this.

The deploymnet is not a simple .rtexe, there are several folders that have been added by the compiler (1 per Class)

I am guessing that this is how the compiler manages the name collisions caused by override methods.

iTm

[Zach-H]

So, that time delay is primarily on start up then. The Real-Time operating system says "Welcome to LabVIEW Real-Time 10.0.1" once its actually begun running.

You also may want to make sure that none of those classes have unnecessary large defaults tied to them. 

How large is your executable? You can always expect a larger application to take more time to start up. 

Is the boot time causing a problem for you?

[Timmar]

The application and associated VI's (In folders) are around 7 Meg.

The boot time is not a showstopper but it is a pain in the backside.

I am doing integration testing at the moment, I have to wait 2 minutes to find out if my small change worked.

It is being used in a remote, industrial environment, so in the field if there is a poer outage or it needs to be re-booted for any reason (History tells me it will)

We then need to wait, twiddling our thumbs until the Program Loop Counter (My Code) in the Network Published Shared Variable starts ticking Over.

As far as large defaults, What would I look for?

0All of my code is object based and initialised in a "Create" Method which is called after startup.

I have tried to put default values in an object before, but it seemed to forget at runtime.

2 Minutes is a long time, It's not like I am launching windows Vista on a Pentium 3.....;)

[Zach-H]

A 7mb application really shouldn't be causing this.

Since the two minutes occur before Real-Time actually starts running I'm thinking you may want to reformat and push new software back onto the controller through MAX. 

[Timmar]

This happens on 3 seperate controllers

2220,2200,2100

[MarkCG]

You used LV classes on a cFP? Pretty brave ! There is probably some overhead there... the cFP 21XX dates back ot the era of LabVIEW 7 I think, before LVOOP existed. My application is all classic LV, but now that I think about it it also takes about a while to boot up and start running, though I haven't measured it. I would say about 3-4 minutes from reset to being able to get a remote front panel. My compile startup VI is about 3.75 megs. 

[Timmar]

2100 is running LV10,

I use it for performance testing.

If it will run on a 2100 it should be pretty safe on a 22xx

Brave, Yes In hindsight I am feeling a bit that way,  I have stumbled into a few NI minefields already.

That said, I have tripled the performance of my application by doing it.

My predecessor programmed it in GOOP which made the code pretty easy to read.

The problem is that every time it read or wrote a value it would unpack the entire object, take a copy and then paste it back.

LVOOP is far more efficient as it only allocates memory for the data you ask for.

My gut feeling is that the time is spent deploying the override VI's (There are about 20 objects each with a "Create, Initialise, Read config, run, destroy"

The perils of polymorphism I guess.

The old one would be up and running within 30 seconds, that included the 20 seconds of OS Loading.

Everything comes with a price.

Thanks for the feedback on your app it puts things into perspective for me.

The Web support is a rescource Hog, I have been excluding it from my installs as I don't need it.

iTm

[Timmar]

This thread has been dead a while but still remains unresolved/unexplained.

More information:

as my coad"Loads" memory grows steadily from approx 60 meg until it reaches it's operatiional value around 110 meg

If I had to speculate it looks like my code is being decompressed before it is executed.

(Is this what a packed library does?)

This causes a few problems for me.

1. The startup time is a pain in the neck.

2. All this code loaded into memory is consuming an already precious rescource (cfp 2200, cRIO-9075 only have 128 Meg)

If my assumption is correct,

Is there a way to have my code reside and run from ROM, Uncompressed -

this should recover my precious RAM and  allow a fast start