Timing Issues, Connectivity Issues, Error Issues

[StevieNewRoad]

I am hoping that someone in the know will be able to help me with some issues I have with my code. I have a test rig that I want take some measurements from using:

2x K type thermocouples

1x load sensor (0-500kg, 700ohm bridge resistance)

2x proximity sensors

I am also controlling a solenoid valve.

I am using a USB cDAQ chassis with 4 modules, which are:

cDAQMod1 = NI 9219

cDAQMod1 = NI 9401

cDAQMod1 = NI 9472

cDAQMod1 = NI 9237

I have used the examples within LabVIEW to write my own code, but being a newbie I am having some issues.

1. The proximity sensors do not work and I get a timeout message.
2. I am unsure of how to scale the load cell. In max I see a change on the graph when I apply pressure to the load cell, but on my LabVIEW screen I see no change.
3. The stop button needs to be pushed a few times before it works.
4. I have recently acquired another fault: ‘Requested value is not a supported value for this property. The property value may be invalid because it conflicts with another property.’

I have tried not to use DAQ assistants so that I can see what is going on, but I have timing issues and I don’t know it I am collecting data to file properly.

Any help and/or direction will be much appreciated. I have attached my code.

[Bob_Schor]

Here are some suggestions and comments (in no particular order):

• Bravo in not using DAQ Assistant.  There's a White Paper here that you might find very helpful.
• You have a lot of things going on.  Try simplifying your code to handle just one (like the Thermocouple).  When you get that working, do another "simple" one.  When you have two working, try putting them together.
• Often when sampling, you want to sample at one speed and look at the data (or save to disk) at another.  This is where the Producer/Consumer pattern comes in handy, two parallel loops connected by a Queue.  The Producer (the DAQxm sampling task)  makes data at, say, 1KHz, puts it in a Queue (which buffers it), and delivers it to the Consumer loop that displays it, saves it to disk, etc.
• I must confess I don't use Dynamic Data Types ever.  I find them confusing and "unnecessary" (but maybe that's because I'm Old Fashioned).  

Bob Schor

[Bob_Schor]

Forgot to comment on the Stop button.  You have the same control being used in multiple loops (not a good idea).  Also, notice that the control is True until it is released.  Also, remember LabVIEW uses the Principle of Data Flow.

Consider any loop.  You start a loop with the button not pressed, so Stop = False.  You now press it, then release it while in the same loop iteration.  If Stop got read when you entered the loop (which probably happened, but there's no way to tell using Data Flow), then it took on the values False, True, False, but only the first False was sent to the Stop Indicator, and the loop doesn't stop.

What you need is a "latch", something that, when Stop is pushed, "stays pushed" even if you let go of Stop.  Do you know about VIGs (VI Globals), also called Functional Global Variables?  These are little VIs, which means that they can be called from several places, that "remember" things.  One easy implementation is a While loop with True wired to the Stop indicator and a Shift Register used as a memory, like this:

This has two inputs, Reset and Stop.  The purpose of Reset is to set False into the Shift Register, so that when called, the Stopped output is False.  This VI should be called early in the program with True wired to Reset to "initialize" it -- for all other calls, leave Reset unwired (which will default to False).  The Error line allows you to place this sub-VI on the Error line and thus to make it execute before other VIs that also sit on the same error line.  If you wire this VI to all of your Stop indicators in your While loops, then if it is ever called with the Stop input = True, it will "remember" it (even if the Stop button is released) and all your loops will stop.

One more piece of advice -- Front Panel controls such as Stop buttons are most often handled in something called an Event structure, another parallel loop (with, you guessed it, a While loop that can have this Stop VIG's "Stopped" output wired to stop it) that has an Event Structure inside it.  This is something that sits idle, doing nothing, until an "Event" occurs (such as changing a Front Panel Control, such as pushing the Stop Button).  You could have the Stop Button Event just be to call this VIG with the Stop input wired to True.  When it subsequently gets called by your other parallel While loops, they will stop.

BS

[StevieNewRoad]

Thanks for your time and help BS.

I will spend some time reading through and understanding the material you have written and directed me to.

Cheers

Steve