LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Help with LabVIEW DAQ application architecture

Hi all,

Let me preface this post by saying that although I’ve been a software engineer for the last 12 years, I’m pretty new to LabVIEW and its unique style of development. I've taken the beginner and intermediate training courses to familiarize myself with its capabilities.

I have recently been tasked with the development of an end-of-line production test cell data acquisition system built entirely in LabVIEW using all NI hardware. The purpose is to run predefined, 6-8 minute pass/fail style tests on motorcycle engines.

This system involves constant low speed data logging; intermittent high speed data logging; analog control of the engine dyno and a few other digital outs; facilities control (an oil heating unit); and safeties monitoring. The test sequences are predefined and are basically a series of ramping to a set point rpm, acquiring data and testing the bounds of that data for pass/fail limits.

I’m having a difficult time trying to come up with an architecture for this system. I’ve tried several variations of producer / consumer patterns and state machine patterns, but have had only marginal luck.

The reason for my post is that I would like to know if it’s appropriate to solicit ideas from this forum for an appropriate design. If so, I can post more detail about the project and hopefully this will spur some interesting conversation and opinions as to the best approach.
0 Kudos
Message 1 of 25
(3,912 Views)
I would highly recommend that you post more detail about the project and any vis that you have tried to get working (the more comments in the vis the better, easier to debug and work though).  Everyone is here to help everyone else, no question is too stupid.

I think that you will be surprised at the number of answers and different approaches everyone takes in working with the vis.

Kenny
Kenny

0 Kudos
Message 2 of 25
(3,898 Views)
You might to also consider another product from NI called TestStand. TestStand is a test executive that manages tests that you write in LabVIEW, LabWindows/CVI, Visual Basic, C++, etc. It does all of the pass/fail determinations, report generation, and database logging. While you can customize TestStand to your heart's content, it's extremely powerful as is out-of-the-box. The big advantage to TestStand is that it allows you to concentrate on just creating the actual tests and not all of the other executive tasks that you would have to create in LabVIEW. For more information, see http://www.ni.com/teststand/.
0 Kudos
Message 3 of 25
(3,892 Views)
Thanks for the fast reply.

Just to put a context around this implementation, the idea is to have a quick and easy to use system that has two parts. The first is an admin interface where tests are defined and saved along with other predefined information.

The other is an easy to use operator interface that implements a workflow like…

1. The operator scans the bar code on the unit under test (this will occur in a dialog box)
2. The bar code id is used to identify what test is associated with the unit (defined in the admin section) and to pull header information from a database for use in the data log files.
3. The test sequence is loaded from file (created in the admin module). This is basically a series of ramp time, set point speed and duration, and the test and alarm limits for each channel.
4. The operator clicks ‘start’ and the application runs through the test sequence.
5. The UI display is updated with:
a. The ‘real time’ values of the low speed channels (no high speed values are displayed)
b. The status of the facilities and safeties monitoring
c. The status of the oil temperature control
d. The cumulative test results at each set point.
e. The current set point being tested and the current speed and torque curves from the Variable Frequency Drive and Engine
6. When the test sequence is done, the engine is shut down and is shipped if it passes all the set point tests or is sent back to the tech’s if it failed at any point.

The following is list of the main technical requirements for the system:

1. Must monitor safeties and facilities while the application is running
2. Must monitor and control the temperature of the oil used in the UUT
3. Low speed data:
a. Acquired and logged during the entire test sequence
b. Data collected during each set point duration will be averaged and limit tested for each channel.
c. Acquisition speed is 1 Hz
d. Around 20 channels made up of a combination of AI, TC, CNT, and DO
4. High speed data:
a. Acquired during set point duration (does not need to be acquired during entire test sequence)
b. 3 channels of vibration which are run through an RMS function then through an FFT function.
c. The data from the FFT function is logged and tested against limits.
d. 2 channels of pressure which will be logged and limit tested.
e. Acquisition speeds can be as low as 16 kHz to as high as 80 kHz. This has yet TBD.
5. Must have the ability to abort a test if a safety switch is thrown or a channel has exceeded it’s alarm limits.
6. Data should be stored in a standard ascii text format (CSV or Tab Delimited)

I envision that this solution will entail a set of six or so major loops:
1. UI event management loop
2. Test sequence control loop
3. Oil temperature control loop
4. Safeties and facility monitor loop
5. Low speed acquisition loop
6. High speed acquisition loop

I have developed a UI for the operator interface and have been trying to work through a producer/consumer style implementation to design the low speed acquisition loop(s). What I’m really struggling with is the ability to synchronize these different loops. And to acquire the low speed data, but only process a segment of it.

Attached is a screen shot of the operator ui and also a VI (not from the UI) I’ve been working with for the low speed part. The VI will currently run, but it does not stop correctly as I was experimenting with the queue management and it's not sending the error code to stop the consumer loop at this point.

Any ideas on overall architecture and / or segments of the architecture would be greatly appreciated.

Thanks for the help,

- Chris
0 Kudos
Message 4 of 25
(3,886 Views)
I would love to use NI Teststand for this project as it would probably eliminate a lot of these issues as you said.

Unfortunately, it's not an option for this project as the client has required us to use labview. If it were an in-house project, I would definately use teststand.

- Chris
0 Kudos
Message 5 of 25
(3,883 Views)
I forgot to include the type def file in my previous post. It's included here...
0 Kudos
Message 6 of 25
(3,879 Views)
Actually, it looks like my original attachements did not make it either, so here they are too...
Download All
0 Kudos
Message 7 of 25
(3,877 Views)

Just a few quick comments:  In your consumer loop, you have the error cluster going to the stop on the while loop.  This may or may not leave your equipment in the last state, and not shut down "orderly".  That may cause a dangerous situation depending on where it is in the test.  Also, if there is an error, you will have to close the program to be able to run the test again, as it will stop the consumer loop and it will not take any more inputs from the producer loop.

You may want to initialize the Final Acq Array by wiring an array constant to the shift register, as well as the other shift registers in the comsumer loop.

In your Aquire, ramp, etc states, you may want to make a subvi that does some decision making.  It will test the values aquired and the ramp data to see if it is out of the limits.  If it is, it can then jump out and go to s stop or abort state and safely shut down the equipment.

Your producer loop has a wait ms of 900, so that means that even if you hit the stop button, it can take almost a second for it to register.  I am not sure how critical it is that you stop quickly or not.

I will keep looking at it through out the day, and try to make some more comments.

also, your global vi is missing you may want to post that as well, just to make it complete.

Kenny

 

 

 

Kenny

Message 8 of 25
(3,874 Views)

Sounds like quite a project for a 'newb'. Smiley Surprised Your software background will serve you well. Moving from text to icon programming takes some getting used to. No offense to the TestStand sales pitch, but you really don't need it. Don't be intimidated, but like most large appliations this is perfect for a state machine. Each piece of equipment you have can be run under it's own subvi, and even most of them can be run with a state machine if they have more than a few modes of operation. Learn how to open, run and close these with references as needed. Use shift registers and functional globals to store/retrieve data these subvi's generate. And stay away from global variables ... Smiley Happy

PaulG

7.1 moving to 8 very soon ...

PaulG.
Retired
Message 9 of 25
(3,872 Views)
Thanks Kenny and Paul for the advice so far. As Kenny suggested, here is the missing Global vi. Hopefully I'm not missing any other files. 🙂

I'm not sure how I'm going to controll all these loops without using a global (as Paul mentioned, Globals aren't a good idea in just about any kind of dev environment 🙂

What I really need to do is come up with a skeleton or shell of an overall arch. weather it's loops in the same vi or as set of sub vi's. I'm a bit lost with an appropriate approach as I'm not sure how to translate a general concept, like using a state machine, into this particular instance.

Is there a good - real life example of something similar to what I'm trying to do available anywhere?

Thanks again.
0 Kudos
Message 10 of 25
(3,864 Views)