Tell us about your large LabVIEW applications!

[Michael_N.]

Hello all,

From time to time, I've heard non-LabVIEW users describe LabVIEW as a development tool that can't be used to create and manage large applications. I don't agree with this view because I've seen customers with incredible applications containing large numbers of VIs, but I'd like to learn more from you. What are some of the large applications you've built with LabVIEW? What do these applications do? How big are they (number of VIs, nodes, etc.)? How did you manage the development of these large projects?

Depending on your applications, we may even follow up with you directly to learn more.

Sincerely,

Mike Neal
National Instruments

[tbob]

We have a system that uses a third party sequencer (I would have much prefered TestStand but I did not have a say in the matter). The sequencer was written entirely in Labview. Over 200 vi's. This sequencer allows editing Labview vi's, configuration of instruments and sequence steps, administrative duties like user management and passwords, stop on fail, breakpoints, single stepping, and other features. Our entire test system including the sequencer and the test program vi's total to over 500 vi's. Other special tools written to assist in test programming brings the total up to around 800 vi's. It is all managed by subdividing the software into sections and assigning each section to a particular individual. One person is in charge of the system software, one person on the product specific testing, one person on self test and calibration, and an outside firm was hired to write the special tools. All vi's are controlled by Source Safe. We use VI Build Lists and build CAB files for installations and software package control. General planning is necessary when making modifications and additions so as to not adversely affect any subsystems. If conflicts arise, different versions of vi's can be specified in the build list so that everyone is happy. All in all, it works quite well, but requires a concentrated effort on everyone's part. The test system is used to test electronic medical devices. Since quality in the medical field is of utmost importance (people's lives are at stake), the test programs are quite extensive, and code reviews are imperative. Traceability must also be strictly maintained.

[Dushyant]

Hello Michael,
First of all, I would really like to thank all of NI support and people in discussion zone for being so cooperative and helping me out on different problems. Without the proper support, I would have not been successful in writing code for my application as I am quite novice in labview.

Needless to say that I again need some help. Please look at my other post titled "Newport controller ESP300: Time out error".
I am using Newport controller to talk to UTM25PP.1 series stepper motors(both from Newport) and photo diode and its controller from EdmundOptics.com. The whole setup is for optical microscopy and I am using laser as a light source.

In this operation, I am doing the following:
(1) I am scanning sample, let us say in 1000 micrometers X 1000 micrometers in step of 1 or 2 micrometers.I am using two motors stacked along Y and Z direction.
(2) First I move Ymotor by Y_Step from its initial position, it then stops and I record the diffracted intensity using photodiode. Then it moves by another Y_Step and again the same photodiode operation and it goes on till Y_Motor comes to Y_Final position.
(3) Then Z-motor moves by 1 Z_Step and Y-Motor again come back to Y_Initial and it goes on till Z_Motros comes to Z_Final and Y_Motor comes to Y_Final.

My code is running smoothly. Only sometime motion controller ESP300 reports and error of "Communication Timeout". I believe that I read somewhere that communication timout default value for this controller is 13 sec. I am also getting an error from labview saying:
LabVIEW: Generic file I/O error.
---
NI-488: I/O operation aborted..

What I am doing wrong? Can I increase communication timeout on Newport controller (I beleieve that I read somewhere that it's 13 sec)? IS there anyway that automatic error handler can click "OK" so that the whole operation can run smoothly?

You may want to look at my previous post.

Thanks again,
Dushyant

Message Edited by Dushyant on 04-28-2005 05:51 PM

[Dushyant]

Regarding my previous post,

Labview report this error first:
LabVIEW: Generic file I/O error.
---
NI-488: I/O operation aborted.

and then this is follwed by error report from Newport controller ESP 300.

Is something wrong in my code?

[DianSong]

Hi, Mike

I havn't ever built a "large" Labview application, but I really want to add a comment on this topic.

First, it's normal for many new-Labview developer to get a feeling that Labview is not good at large applications. I used Labview for 3 years. In most of the time, I was mentoring interns from universities to create Labview programs for test automation in product development and manufacturing. Almost every intern run into a situation where they couldn't handle their program when it becomes larger to some degree. Even a small modification in functionality was very difficult.
I resolved the problem by creating a program architecture with datasocket server, as following:
step 1: dividing a large application into several modules according to the functions.
step 2: for each module, besides their Front panel, another interface was defined with datasocket. we can sent commands to the module, and get result from the module, with Datasocket data.
step 3: also, for each module, test program was developed to make sure the module is functional right.
step 4: Combining all the modules with datasocket server to build a "large" application.

With this model, each developer could work well again because each module is simple enough for them to manage. And they could optimize their module without impact to other parts if they keep the same functionalities and interface of the module.

As I said at the beginning, the application is not large(13 VIs total). But I have found a way to build bigger programs than before. (I have several thoughts on using Labview; some of them are kind of crazy...maybe talking to you later)

best regards
Diansong

[Odd_Modem]

I have made a couple of test sequencers with editors; they run about 500 vis.

The key to making a big program is to install a machine that is easy to add to. Queued state machines work very well. One project was an assembler for a micro-cintroller, probably 400 vis. It had about 15 state machines and a few more queues. I used the rendevous to get everything started in the right state.

Now that the event structure is available the programs becomes smaller and easier to manage because you don't have to poll front panels.

As far as the perception that LabVIEW is not a real computer language, it has taught me more about programming except for Bentley's _Programming Pearls_.

[becktho]

Hi

I don't know if this goes as "large" LV application.

I once had to make a programm, which can run on several teststand with different hardware. Some of them are controlled using a DAQ-card and the other use fieldpoint.

The program itself contains 138 user-vis, 202 vilib-vis and several vi which are loaded dynamically in dependence of a config-file. To store measurement data I used a VB-ActiveX component which accessed a MS-Access DB on a separate computer.
To make testprograms I made a VB-application which stored the programs in the same DB. The LV app read the program and executed it in a kind of interpreter I wrote.

It was my first bigger LV app and it works well.

As Odd_Modem I used a queued state machine which made it easier to improve.

[Ben]

Part one of two.

The following is an application I devloped about a year and half ago.

It is somewhere between 500 and 700 VI's.

Ben

21 CFR 11 Compliant Environmental Monitoring and Reporting System

The Challenge
One of Data Science Automation’s (DSA) customers needed an application that allowed their existing customers to upgrade to a 21 CFR 11 compliant laboratory monitoring and control system. The application had to integrate seamlessly with their existing hardware, provide a customizable user interface while being fault tolerant (Figure 1).



The Solution
DSA developed an application based on a robust architecture that harnessed the power and flexibility of LabVIEW for Windows, LabVIEW Real-Time, NI-FieldPoint, and NI-VISA. The scalable application can be easily customized by the end-user to reflect their physical and organizational structure and uses cFP-20XX’s to provide fault tolerance at multiple levels (Figure 2)


Solution Overview
The new application maintains support for the legacy hardware and greatly expands the capabilities of the previous system by introducing a network of Compact FieldPoint (cFP) units running an embedded application. Each of the cFP nodes is considered a Remote Unit (RU). The RUs monitor all configured process variables (PV) while maintaining the state of local alarm devices (not illustrated). The RU also maintains a history buffer that is available for storing historical PV information in the event of network or Central Station PC (CS) failures. The CS will monitor the history buffer of all the configured RUs and update the database as required. The CS also provides ready access to the PV history and configuration through a web-enabled GUI. The CS also provides notification, event tracking and reporting functionality.


Challenges Enumerated
The challenges can be categorized as development, interoperability, or GUI, related and are listed below. The details of each of these challenges will be discussed further in the context of their solutions.

Development
• Short developmental cycle
• Complex application
Interoperability
• TCP/IP connection to RUs
• Serial compatibility with existing hardware
• Fault tolerant communication
• DTMF support for paging and voice notification
• Control and monitoring of local alarm enunciation devices
GUI
• Web-Access
• User Friendly
• Customizable GUI
• Secure (21 CFR 11)

Development Solutions
NI-LabVIEW and NI-LabVIEW-Real Time were selected as the development environment. The short development cycle was addressed by leveraging LabVIEW’s integrated source code control to enable multiple developers to work in parallel. The complexities of the application were addressed in the application design. A simplified diagram illustrating the architecture for a “one RU system” is shown in figure 3.

Message Edited by Ben on 04-29-2005 11:53 AM

[Ben]

part two of two


The simplified architecture illustrated in figure 3 shows how the functionality was shared between the CS and the RU and uses a TCP/IP connection to interact. The RU uses its local configuration information to acquire, process, and buffer all PV related readings and events (i.e. alarms, warnings, faults …). The RU also supports a “Security Window” that exposes a set of password protected methods that can be used by the CS to read the “History” buffer and permit configuration modifications.. The “history” buffer was implemented as a “round-robin” buffer capable of storing up to 8000 events without adding additional memory.

For simplification, the illustrated CS design omits the reporting and notification functions.. The “History Poller” (HP) maintains and monitors the state of the TCP/IP connection to each of the configured RUs. As long as the HP has a valid connection to the RU, the buffer is periodically checked for updates. If updates are found, the new information is used to refresh the “Recent History” buffer (used to provide quick access to the PV readings from GUI) and the Database. Once the Database has confirmed the updates have been written, the HP will mark the updates in the “History” buffer as saved. This handshaking ensures that no data is ever lost without being detected.

The CS User Interface allowed authorized users to view the PV history, or review and modify PV configurations. All configuration changes are logged to the Database after being confirmed by an appropriate password.

Interoperability Solutions
The TCP/IP connection shown in figure 3 was implemented using the “VI-Server” technology. This eliminated the need for all low level TCP/IP development and meant that the original version of the “Security Window” never had to be modified.

The serial compatibility issues were addressed by developing appropriate drivers that ran in the RUs under LV-RT and used the built-in serial ports of the cFP units. The cFP serial ports also were used to control and monitor the handshaking lines for use in the local alarm annunciation (not shown).

The fault tolerance was addressed by using cFP controllers. Compact FieldPoint controllers have the option for backup power supplies. The “handshaking” (described above) used by the HP also allowed the reading of updates from the history buffer in RU to be completely tolerant of communication failures and PC crashes.

Control and monitoring of the local alarm annunciation device used the handshaking lines of one of the PC’s serial ports using NI-VISA. NI-VISA was also utilized to control a voice modem to provide the pager and voice notification functionality. Modules were developed to provide voice and e-mail notifications.

GUI Solutions
The CS application was designed and written to take advantage of LabVIEW’s web server. This made it possible to provide the full local functionality of the CS to a remote user.

The CS made extensive use of the Tab Control to organize and control access to all of the applications functions. The Tab Control was combined with picture controls to implement a graphical interface that could be customized by the end user to configure the physical location of all PVs. An authorized user could specify a bitmap file as one of ten possible background maps. The state of each PV was illustrated by an icon overlayed on the background map at the configured location. A LabVIEW event was used to detect the mouse position while viewing the maps and provided a “mouse over” feature that used a tip strip to show the current reading and state of the PV. Mouse events were also used to access PV history (left clicking on PV icon) or configuration screens (right clicking on PV icon).


Summary
The solution described made extensive use of the power, flexibility, and features of LabVIEW, LabVIEW-Real Time and Compact Field Point to provide a fault tolerant, configurable application that is 100% compatible with legacy hardware and meets all other stated requirements. Testing has shown that “attacks” (i.e. power fails, crashes, network outages) on the system impact only the affected device and are completely recoverable.

[drval]

I have a LabVIEW project that includes almost 800 Sub-VIS and interfaces to three out of process servers, with calls to WMP v6x. I use the Database Connectivity Toolkit as well as the JTFA tools.

The application is for real-time recording of EEG with triggered multimedia feedback. It also includes extensive off-line analytic tools and options.

You can browse our website www.zengar.com and access the NCPro item to get some more details.