LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Multiple analog inputs and outputs via daq

Hello all,

 

I am fairly new to LabView (started learning it earlier this week) and I need some help Smiley Happy The system I am trying to control is a piston controlled by a motor that will be extending and retracting multiple times. This is for reliability testing.

 

My two inputs are sensors for when the piston is fully extended (100% extension) or completely retracted (0% extension). I have configured the sensors so when they sense the piston they output about 2.5 V otherwise they output about 0 V.

 

My two outputs go to the motor. One output for retracting the piston, the other for extending it. If both outputs are on or off, the motor is idle. For example to extend the piston, the extension output is on while the retracting output is off.

My goal is to have the piston extend when the 0% extension sensor is triggered and have the piston retract  when the 100% extension sensor is triggered. When either switch is triggered there will be an idle time (about 5 sec) when the piston is not moving by turning off both outputs.

 

I have created a simple program that oscillates the piston by simple timing. I have also created a couple charts to verify my sensors are working.

 

Where I'm having difficulty is "coding" with LabView. I'm not sure how to create 2 states and have them switch when certain conditions are met (i.e. a sensor being triggered). I have tried a case structure, but I'm having troubles getting the sensor input converted to a string or to something else the case structure can recognize. Also, the case structure can handle when the sensors are triggered, but I'm confused if it could handle the transition time while extending/retracting.

 

I am running LabView 8.2.1 on Windows XP. Also, My DAQ device is a NI PIXI - 1033 (I know pretty old haha) However, I'm not having trouble interfacing with the device, only coding in LabView.

 

Sorry for a wall of text, but I wanted to make my intentions clear - hopefully I accomplished that but please ask if you have any questions :). I have attached my prototype program and a jpeg of the program running. The overlapping square waveforms are my simple way of driving the outputs.

 

Thanks for any advice,

Ben

Download All
0 Kudos
Message 1 of 7
(3,429 Views)

Ben,

 

Sounds like you may be able to use you DAQ read vi and tie the output to one of the comparison function VIs.  The other input to the comparison would be a threshold constant, for example 2 V or whatever would mean a triggered sensor.  The output of this function would be Boolean which you can then tie into a case structure.  If you need more conditions you could also try embedding one case structure in another.

0 Kudos
Message 2 of 7
(3,425 Views)

Nightman-

 

Thanks for you response, I took your idea a ran with it. I have my program working correctly now but, there seems to be about a 3-4 sec delay in the system when a sensor is triggered. I believe that this delay is from my pxi machine instead of LabView. I have put charts on the output in LabView and there is no delay. However, when I hook up an Oscope to the physical outputs, there is a large delay.

 

Again thanks for your help 😄

 

Ben

0 Kudos
Message 3 of 7
(3,401 Views)

Have you tried using Measurement & Automation Explorer test panels to check your instrument.  Also I believe if you leave highlight execution on that it might slow things down.  Without knowing your full implementation that is the best I can think of.  Do you have an idea at which VI the delay is occuring?

0 Kudos
Message 4 of 7
(3,393 Views)

I have just tried the Measurement & Automation Explorer test panel and the delay disappeared. I'm confused now since LabView is saying it is outputting the correct values with no delay and there is no delay in my circuitry however, there is delay in the motor operation.

 

I'll attach my labview project. I know that it is horrendously ugly programming haha. If you have any suggestions about improving it, they would be greatly appreciated.

 

Currently my program detects when a sensor is triggered and then reverses the direction of the piston movement. Also, it keeps track of how many cycles have occurred. Finally, I'm working on the detection of failure by measuring how long the piston has not triggered a sensor. If a sensor has not been triggered in say 10 sec => the piston has stopped moving. I would also like to add an idle state for when a sensor is triggered. Thus there would be a bit of time where the piston is not moving when it reaches either min or max extension.

 

As a side note, the charts attatched to the output signals are timed correctly, but my piston does not start to change directions until a few seconds after the output signal has changed.

 

 

Thanks for your help,

Ben

Download All
0 Kudos
Message 5 of 7
(3,385 Views)

Hello Ben,

 

Looking at this code I can't find any reason for the delay in your motor.  All I can think of is that something between your DAQ Assistant2 express VI and you motor.

 

A couple other notes on your programming that may help.  At your inputs, following your split signals VI, you may want to add an Index Array VI so you can get the current value of your input signal.  Also I don't believe the true case of your interior case statement will ever execute.

0 Kudos
Message 6 of 7
(3,341 Views)

Ben, there shouldn't be any reason for a delay with magnitude of seconds in your hardware.  I suspect some inefficiences with your code are the route of the problem, especially if you are running on an older machine.

 

A few things I see:

 

1.  You only need to generate your simulated signals once, at the beginning of the code.  From what I see, they never change.  Therefore they should be outside of the while loop.

 

2.  We really want to avoid the use of local variables, if at all possible.  Instead I would recommend harnessing the power of shift registers on your while loop.

 

3.  I don't understand the use of a stacked sequence structure in your False>True case.  LabVIEW executes code by going through data flow, and the operations you are doing in the first frame don't need to be completed before the part in the second frame.

 

4.  You seem to be heavily relying on strings to pass data around, but you would probably be better benefitted by a more efficient data type.

 

I tweaked your code to demonstrate 1,2, and 3.  For 4, you would have to decide on a better system to use.

 

For the problems with your code. :

 

1.  You have your first Assistant (acquisition) set to acquire 1k samples, at a rate of 10k Hz.  This means, that you will have data available 10 times a second (1000/10000 = 1/10), or every 100ms.  With the other inefficiencies in your code, and the heavy reliance on Expres VIs, it's very possible that you computer is not capable of acquiring data every 100ms, meaning that the data you are acquiring is old, which could explain the mismatches in what you are reading and what your are outputting.  Acquiring with a higher samples to read will result in data needing to be read less often, meaning that it will be less likely that you will be viewing old data, but you will be dealing with larger chunks of data.

 

2.  The output of your DAQ Assistant is an array of data.  You are using it as a scalar component, hence LabVIEW is coercing your data, and only using the first piece of data (out of the 1000 pieces as you currently have it configured).  So, what gets used for your case structures probably isn't being chosen in the best way.  You'll have to choose how you want to do this, but you may want to do an average, or look at a certain part of the array, or do it some other way.  It's just important to understand what you are using here. 

Paul Davidson
National Instruments
Product Owner - ni.com Chat
0 Kudos
Message 7 of 7
(3,322 Views)