LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Program works when I STEP, but not when I RUN

Solved!
Go to solution

Can someone please help me understand the following:

 

I have a multiplexer circuit that has a few strain gage half bridges and a few thermocouples (TC) connected to it. The strain gage bridges need an excitation voltage (Vex) for me to read the correct data and the thermocouples do not. So, I'm trying to read the bridges by outputting a "1" which enables an excitation voltage and then turning it to "0" for reading the thermocouples (excitation voltage is OFF). A single strain gage and a thermocouple share one lead wire. This is why I need to turn Vex OFF when I want to read the TC.

 

My problem is that when I "step" through the program, it seems to work perfectly – I can see the periodic turning ON/OFF of the excitation voltage, my MUXs cycle through the correct channels and correct data is recorded from both types of sensors – for example the temperature reads about 24C. But when I just "run" the program, values from both of my sensor types are garbage (temp reads something like 1300C!!).

 

What is the difference here??!!

 

A high-level circuit diagram and my LabVIEW program are attached. Any comments/suggestions will be much appreciated. Thanks.

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

Does the digital output affect the analog reading?  Perhaps when you step through it, you give something time to settle after setting the digital output before the analog read, but at full speed you don't get that time.  Also, it's a bad idea to create, start, read, and clear the task over and over again inside the loop.  It would be better to configure the tasks once outside the loop, read or write to them inside the loop, and clear them outside the loop at the end.

 

You should also restructure your code to eliminate the sequence structures.  You're almost there already; if you need to dictate execution control further, use the error wire to introduce a dependency.

Message 2 of 7
(3,038 Views)

I think nathand is right on it!  I'm betting your MUX takes a discreet amount of time to complete its switching and debounce.  Try adding a 100mSec delay


"Should be" isn't "Is" -Jay
0 Kudos
Message 3 of 7
(3,030 Views)

Hi nathand,

 

Yes - a MUX has N channels (0 .. N-1). And the digital output is for selecting one of those N channels. So, yes, different digital value will (at least that is the idea) change the analog inputs.

 

I'm assuming that you are suggesting a program like what I show in the attached picture, right? But if this is the case, then how do you ensure a consistent flow? For examply, I MUST have the following happen in order: 1) Write a digital value (0 to N-1) to the MUX to select a channel 2) Read the analog value from that channel How do you ensure this code flow?

 

BTW - The datasheets for the MUXs I'm using tell me that these can be switched in the MHz range. I don't think I need to add a 100ms delay.

0 Kudos
Message 4 of 7
(3,000 Views)
Solution
Accepted by topic author JG001

Connect the output error of the Digital write to the input error of the Analog read, that will ensure they happen in that specific order. You could even add a small delay in between.


Ton

Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas

LabVIEW, programming like it should be!
0 Kudos
Message 5 of 7
(2,989 Views)

Thank you nathand and TCPlomp!

 

Now that I have connected the error out from the digital write to the error in of the analog read, my program nicely scans and records the correct values from all the sensors.

Thanks again.

0 Kudos
Message 6 of 7
(2,926 Views)

I suggest that you mark Ton's answer as solution, not your own.

0 Kudos
Message 7 of 7
(2,919 Views)