Tell us about your large LabVIEW applications!

[atk_nut]

Well, we've been using labview since before 3.0.  We run the entire shop floor with LV apps.  Our library is 2000 vi's plus.(not including vi.lib or toolkits)  Our largest app is about 1500.  No, they are not all loaded at once.  After about 200, you need to start dynamic loading.

My two bits:  Labview is every bit as useful and powerful as any other language, just different.  There is nothing that we haven't been able to do with it.

[NavyJack]

I am involved in the system design and software development of automated test systems for the AIM-9M Air-to-Air Missile Guidance Control Systems.  These systems are used to test all aspects of the missile flight control systems.  LabVIEW is used to control the system and obviously to obtain all data collected by the system.  It takes over 90 minutes to completely test a system in fully automatic mode, and quite honestly has more VI's than I've ever cared to count. 

[mcsynth]

Hi Mike,

I completed a large project about 2 years ago using LV 6.1RT, 1 PC, 6 PXI-8175s and 12 FP-2000 modules.  The task was to durability cycle 36 automotive GDI (gasoline direct injection) pumps, each with independent test cycles, calibrations, and fuel control in an explosion proof test cell.

The arrangement was 6 test stands of 6 pumps each.  Each test stand required 1 PXI-8175, and 2 FP-2000 controllers.  Each set of 2 FieldPoints talked to a PXI, and each of the 6 PXIs talked to the PC, all on a isolated 24 channel ethernet hub.  The PXI program managed all the control, safety monitoring, and data collection.  One FP 2000 handled all high power switching, and one FP-2000 handled all DAQ.  The PC provided operator control of one test stand or one pump at a time (except for global shutdown), and data collection and analysis for all 36 pumps.  The overall system must run 24 hours a day, 365 days a year, with each stand and pump being totally independent of the others.

There were also numerous non-LabVIEW systems, such as closed circuit video, vapor and spark monitoring, and fire safety (CO2) systems.

The breakdown per test stand:

Located in a non-gasoline environment adjacent to the gas cell:

One PXI-6713 provided 6 analog outputs to control each of the six 5hp drive motors to spin 6 pumps.

One PXI-6602 provided the PWM control outputs to high current drivers to control the fuel output of 6 pumps

One FP-2000 with 2 FP-RLY-420s and 1 FP-DO-401s provided the power management of all 120VAC and 480VAC circuits.

Located near the ceiling of the gasoline environment, above the vapor line:

One FP-2000 for DAQ with 1 FP-AI-100, 3 FP-TC-120s, 2 FP-CTR-502s, 1 FP-DI-301, and 1 FP-RLY-420.

The biggest challenge were developing all the TCP/IP VIs.  Most important was to isolate from the house intranet, and to set the relative timing between the many commo loops on all platforms.  Another huge problem was to get the PC interface to disengage from one of the 36 control loops, and to engage any one of the other control loops, read the current status, and then take control without any crosstalk between commands or data.  The operator only interfaces with one stand/pump at a time, and it was tough to get in and out of each control loop without causing any adverse effects.

The system has been running 24/7 for 2 years now with an occasional shutdown (every few months) for mechanical and fluid maintenance.

Best regards,

mcsynth

[mcsynth]

Just to follow up on my last post, another huge part of the learning curve was to control memory leakage in the RT code so the the programs could runs for months or years without clogging up.  I learned to get rid of build arrays and globals, and to start using state machines and queues.  These were all new to me at the time, but made a huge difference in performance.  And, of course, proper task distribution and relative timing between various loops or even various platforms was most crucial of all.

mcsynth

[Uttam Kotdiya]

We had developed a Energy management system using Labview /Labview DSc ( 6.1 ) and Oracle and some delphi DLL. It had about 100 vi's. The software collects the data from energy meters using MODBUS protocol from 8 comports simultanouesly and show the data online in gauge , graph and tabular fasion. There program automatically tranfers Citadel data to Oracle database for power ful reporting.It also shows alamrs and generate about 150 different reports.  Though labview had some very good feature and looks very impressvie which increase the prodcutivity to develop such online monitoring applcation. We are able to read and log and view about 4000 tags within 30 seconds. We had more then 20 installation of the product. 

But the biggest problem with labview is that it is not stable and the functions mentioned in user manual do not work as it. and after wasting so much time you found that this is known bug of labview. Below is my mail which I had put in serval mail group and forum and got the answer that Labview new version may fix this. But I am afraid is Labview 8 is a stable/ bugfree version and Labview is bundled with so many features but it have frequent problem of data corruption and there is not easy way to recover. Also many times DSc engine stop working after some erros like "Input queue compacted". One more problem when using network tag it will continue showing the Last tag value even is the server is stopped

My suggestion is that NI should should also focus on quality of LAbview and Labview DSC along with the feature set. Unless NI focuses on quality,reliability  and stability it will remain as procuts for LAbs and academic purpose and cannot be used in commercial product.

my earlier mail

My application continueously monitors the energy meters and log data into citadel database. There are on average 2000 tags polled every 30 seconds. I am getting Citadel corruption problem very frequently (every 20-25 days). Once the data base is corrupted I am not able view in historical data viewer/ Max explorer or query through ODBC.
Also archive vi also does not work on that data and only option is to manually delete that data using windows explorer. As we are product based company and the sale of software is picking up so it is difficult to support if database is not reliable.
Can anyone tell me the ways/tip to minimise the database corruption possibilities. I had tried to keep the data for only 15 days in Days to keep historical files in Tag confiuration editor but that does not help as it does not remove data automatically. I had increased the polling time to 60 seconds but this also does not helped
I am having very bad time explaining such frequent corruption to my customers as we pay big license fee for Labview DSC Runtime and it works so badly.