LV RT development time?

[Götz Becker]

Hi,

how much more development time do you usually expect when planning a LV RT application in comparison to Windows?

My current guess is about a factor 3-10. Included all the little extra times of deploying, rebooting (restarting or crashed LV and/or LVRT), extra code for debugging e.g. reentrant code, extra test time etc.

Greetings

Götz

[Neville D]

My guess is about 30% more time. In general its quite easy. Develop the application for windows, try to minimise use of property nodes & too much UI flim-flam (pop-up config windows, subpanel VI's and such), and you can port the exact same application to RT with a minimum of fuss.

I have a vision application that started out windows-based and then was ported to RT. If you have a target with lots of memory (like a PXI controller) then it becomes easy to run the code directly on it for debugging (in development mode) without needing to build executables.

Also, you need to add additional code to log errors/state transitions etc. for debug, and specific code to check file paths for development mode and executables, but then I would assume you already did when you developed the windows version .

Neville.

[Grampa_of_Oliva_n_Eden]

QUOTE (Neville D @ May 7 2009, 12:33 PM)

My guess is about 30% more time. In general its quite easy. Develop the application for windows, try to minimise use of property nodes & too much UI flim-flam (pop-up config windows, subpanel VI's and such), and you can port the exact same application to RT with a minimum of fuss.

I have a vision application that started out windows-based and then was ported to RT. If you have a target with lots of memory (like a PXI controller) then it becomes easy to run the code directly on it for debugging (in development mode) without needing to build executables.

Also, you need to add additional code to log errors/state transitions etc. for debug, and specific code to check file paths for development mode and executables, but then I would assume you already did when you developed the windows version .

Neville.

I agree with Neville provided this is not your first RT app or if the RT app does not have to run 24 X 7 error free. I put that restriction on my estimate because RT is less forgiving than Windows when it comes to memory usege. In Windows you can walk off into Virtual Memory Land (Using more memory than available physical memory) and you may not even notice. In RT it just dies.

If the app has to be deterministic then throw in another fudge factor to learn how to get info into and out of a deterministic loop with blowing the timing.

The good thing about developing on RT is when you come back to Windows you will good habits that will make your Windows based apps ever better.

Ben

[Neville D]

QUOTE (neBulus @ May 7 2009, 09:51 AM)

I put that restriction on my estimate because RT is less forgiving than Windows when it comes to memory usege. In Windows you can walk off into Virtual Memory Land (Using more memory than available physical memory) and you may not even notice. In RT it just dies.

Yes, and you can monitor memory usage using the Real-Time System Manager found under Tools>RealTime Module>Syst Manager, though when the remote system tends to run out of memory, one of the first things it does it stop communicating with the System Manager.. but you can trend the memory increasing if there is a memory leak of some sort.

Neville.

[Götz Becker]

Only 30% surprises me.

Just hitting the deploy button takes currently about 2-3 minutes and after a hopefully successful deploy (sometimes I get just the message "Deployment completed with errors" without any indication what went wrong, restarting LV usually fixes it) it takes additionally 2-3 minutes until LV is aware of all VI states and is usable again.

Using probes often leads to a local LV crash which means loading everthing again (opening the project alone takes about 2 minutes with SCC disabled).

Memory leaks usually not a problem and if we suspect something we log the CPU/Mem status over night in a TDMS file.

Our PXI targets are 8106/8130/8108/8110 and the development machines are all dualcore notebooks.

Götz

[Rolf Kalbermatter]

QUOTE (Götz Becker @ May 8 2009, 03:20 AM)

Only 30% surprises me.

Just hitting the deploy button takes currently about 2-3 minutes and after a hopefully successful deploy (sometimes I get just the message "Deployment completed with errors" without any indication what went wrong, restarting LV usually fixes it) it takes additionally 2-3 minutes until LV is aware of all VI states and is usable again.

Using probes often leads to a local LV crash which means loading everthing again (opening the project alone takes about 2 minutes with SCC disabled).

Memory leaks usually not a problem and if we suspect something we log the CPU/Mem status over night in a TDMS file.

Our PXI targets are 8106/8130/8108/8110 and the development machines are all dualcore notebooks.

Götz

Well 2 to 3 minutes sound quite bad. I did recently a project on an cFP-2020 controller (77MHz RT controller) and while it takes some time to deploy it was less than 3 minutes for sure. There were a few problems on that system that made it take up more time than I had suspected but the deployment was not the big factor on it.

1) one was that the source code debugger sometimes caused the controller to die completely when single stepping through the code. This is a known problem with the used LV 8.2.1 version but an upgrade was for other reasons not desirable.

2) Enabling VI Server on the controller made the system grind to a crawl so it was not able to do its task. I had to integrate all the parameter downloads into the controller into my already existing TCP/IP server instead of just remotely call the according VIs.

3) As the system integrated more and more functionality I had to find out that normal while loops are a bad thing on a real time controller. It worked perfectly and blazingly fast on my notebook system but started to slow down on the controller. Replacing all long running loops with timed loops made the system fully responsive again.

4) last but not least but this was not because of the LabVIEW environment or real time nature, but because of the customer application: It had been a monolithic application running on a desktop system before, with countless global variables scattered throughout the controller part and the user interface part influencing each other back and forth. When calculating the needed development time I had vastly underestimated the time needed to separate this more or less cleanly into a user interface application running on the desktop machine, and an independant controller application running on the RT controller. All in all I guess the time needed to do this would have been not less than writing the whole application from scratch again, but the LabVIEW diagram was unfortunately more or less all that was there in terms of documentation of the existing system and its interaction between the different instruments and IOs.

Your 3 to 10 times development overhead is definitly way to overestimated. There is some extra time to find out about the specific details of the RT system and the used hardware but not that much. I would really recommend to start with a good system design that works on your local desktop too and then port the controller part to the RT hardware. This should be quite a simple step considering that LabVIEW on a RT system is really quite like on the normal Desktop.

An interesting starting point might be also the NI System References Designs, specifically for RT and HMI applications http://zone.ni.com/devzone/fn/p/sn/n23:1.7489,n24:RefDesigns.

I've been using my own system reference design from earlier projects which have the advantage that I have the complete source code of every part of the system but the Reference Designs have some good ideas and even components you can take into your applications.

Rolf Kalbermatter

[Neville D]

QUOTE (Götz Becker @ May 8 2009, 01:20 AM)

Just hitting the deploy button takes currently about 2-3 minutes and after a hopefully successful deploy (sometimes I get just the message "Deployment completed with errors" without any indication what went wrong, restarting LV usually fixes it) it takes additionally 2-3 minutes until LV is aware of all VI states and is usable again.

Couple of comments:

1) I get the deployment errors as well (when there is a built exe set to run on startup and it is stopped, OR when the ini file specifies some startup exe that is not there). But I generally hit OK on the error, and then click on the RUN arrow again, this time it runs fine. No need to reboot, or restart LV. Its annoying, but I can live with it.

2) I have a quad-core desktop as RT target, connected over Gigabit Ethernet to my development PC (quad-core Windows desktop 2GB). I suspect your laptops are 100MB/s slowing down the deployment considerably. Also laptops in general seem to be MUCH slower in development mode than a desktop. When visiting customers, I use my dual-core 2GB laptop and its definitely slower to open the project/open the VI/download the project/build and executable. Probably due to slower hard drives and slower ethernet on the laptop.

3) I find that if I open the VI's I want to debug and set probes on them, then deploy, things go smoother.

4) What version are you using prior to LV-RT 7 and targets like cFP, CVS etc, deploy/build was quite painful but with the newer versions (and with fast targets with lots of onboard memory) things are a lot better.

QUOTE (Götz Becker @ May 8 2009, 01:20 AM)

Using probes often leads to a local

LV

crash which means loading everthing again (opening the project alone takes about 2 minutes with SCC disabled).

Memory leaks usually not a problem and if we suspect something we log the CPU/Mem status over night in a TDMS file.

Our PXI targets are 8106/8130/8108/8110 and the development machines are all dualcore notebooks.

Hmm.. what kind of probes? I use custom probes (consuming lots of memory) of arrays of complicated structures, as well as image display probes (custom and standard), and various flavours of history probes with seldom a crash.

How much memory do you have on your targets? I have 2GB on my quad-core RT (ETS), and 512MB on an older PXI-RT 8187 and they both generally run fine, but of course everything is slower on the single-core 8187.

Do you have very high sample-rates or thread starvation issues on the RT? Maybe its too busy and can't deal with the debugging updates, I dunno. I usually add one of these into the main loop to get an idea of CPU loads:

And throw in a plot on the main VI so I can look at the front panel with VIServer:

Neville.