LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

temperature based valve control

Hi,

 

I am trying to incorprate the following operation, where a soleniod valve would be controlled (opened/closed) based on acquired temperature data in a flow field. I am using a normally closed valve, NI 9188, NI 9263 AO, NI 9215 AI and NI 9213 for temperature with K type thermocouples.

 

Step1: Start the labview program and waits for an external trigger from a sensor. 

Step2: When the trigger is activated, immediately send 5V to open the valve and start acquiring temperature data. I also have an input from the NI 9263 output channel to an input voltage channel in NI 9215 to see the state. 

Step3: AFTER 2s from start of the trigger - Compare if the acquired temperature is greater than a threshold value.

Step4: If the temperature has crossed the threshold value, do nothing - keep the output voltage to 5V (let the valve remain open)

Step4A: If the temperature is below the threshold, send 0V to the valve (close the valve immediately)

Step 5: For either case Step 4, or 4A after ~ 10s or so hit the stop button to stop the program and reinitialize the outout voltage to 0V (make it closed again) at the end of run. 

 

What I have got the code to work so far is upto Step3 and part of Step5 where I reset the output voltages to zero, but that too for low output data sampling rates (~10hz). Whenever I try to increase the sampling rate on AO ~ 100hz or so, the code retruns an error 200621 (onboard memory device underflow...reduce sampling rate..etc.) or 200018 (DAC conversion attempted before data to be converted...). Any thoughts on how to get rid of these errors?

 

At Step3 to wait for 2s, I increased the loop time to 2s, thereby I can compare the conditional statement after 2s. I am not sure if this is the correct way as I forced to run the loop slower. If there is a better way please suggest. 

For Step4 and 4A, I feel somehow I would need a case structure based on the threshold condition is true or false and also implement that in a separate while loop. But just can't figure out how to send a different signal through same ports in a  continoius sampling mode without getting the error - specified resource/channel is reserved. 

 

I would really appreciate any help on implenting this operation. Attached is what I have tried so far. 

 

Thanks,

Roy

0 Kudos
Message 1 of 8
(3,752 Views)

What are you using a sample rate for the Analog Outputs just to put out a DC level?  Just use a single 5 to set the output to 5V and 0 for 0V.  And since you are talking TTL, why not just use a Digtial IO module like a 9401?


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 8
(3,743 Views)

hi crossrulez,

 

i started from a different code for which i had to send only a square wave continuously, so just made the offset 5 and all other inputs zero.  I have ordered a diigtal module, but that will take time to come, for the time being need to work this out with NI 9263 only.

 

I hope that is not affecting any of the wait time set up or case structure i want to implement based on the conditional statement. Any suggestions on how to implement this..

 

-Roy

0 Kudos
Message 3 of 8
(3,733 Views)

I removed the trigger condition from the analog output to immediately send a constant 5V to the valve when I start the program.

 

Also I tried out the conditional statement and here are the issues I am having:

 

1. When the temperature threshold is crossed, output remains at 5V, but when I STOP the operation, throws up an error 200018 - DAC conversion attempted before data to be converted..

2. When the threshold is not crossed, the output doesn't go to zero and throws up the same error at the end of 1st loop time - error 200018.

 

Therefore, at the end of operation when I stop the run, the output voltage doesn't go to zero also. 

 

snippet-v3.png

 

Any comments/help/suggestions...

0 Kudos
Message 4 of 8
(3,687 Views)

Hi Roy.a

 

I think what we should check is the two analog writes that you have for the 5V and the 0V near the bottom half of your code. I would suggest actually trying to do this in a separate program to verify the functionality for the analog write. Also it looks like you only have one stop task for the first Analog In task. You might need a second stop task for the Analog Out as well that should be connected at the end of your code. I would try to simplify the procedure and verify that it is feasible.

John H.
Applications Engineering
National Instruments
0 Kudos
Message 5 of 8
(3,648 Views)

Hi John,

 

Thanks for your response.. I made the analog data writing and input voltage reading into two separate loops and the code seems to be working logically with a warning and some delay, but I would like to have better understanding on the timing considerations of the output and input loops. Following are the issues I would like to resolve/better understand:

 

1. While stopping the code, I am stopping the output loop first (Stop-1) and then the input loop (Stop-2). For both TRUE and FALSE cases when I stop the input loop, I get a warning 200015 - "While writing to the buffer during a regeneration, the actual data generated might have alternated between old data and new data. That is, while the driver was replacing the old pattern in the buffer with the new pattern, the device might have generated a portion of new data, then a portion of old data, and then a portion of new data again. Reduce the sample rate, use a larger buffer, or refer to documentation about DAQmx Write for information about other ways to avoid this warning."

- How to get rid of this warning?

 

2. With 10,000 samples/s and 10s/ch timing setting on the output loop and 100Hz frequency/200s/ch on the data reading input loop, if I put a threshold (say 15degC) below the actual temperature (say 20degC), there seems to be a delay of ~ 4s. Ideally the voltage should read 5V after 1st loop iteration (because threshold is crossed after 1st loop), but it's showing 5V at the end of 2nd loop iteration.

 

3. While keeping the input timing setting same, if I decrease the output sampling rate say to 1000Hz and 10s/ch the 5V output is delayed even more e.g it happens after the 3rd or 4th loop iteration.

 

4. If I increase the sampling rate to 100kHz and 10s/ch, then code ouptuts 5V even for the FALSE condition and stays there even after data writing is stoopped by Stop-1 button (should go to zero) and finally gives an error -200292 "some or all the samples could not be written to the buffer yet. More space will free up...."

 

5. Instead of slowing down the input reading loop, how do I make the input loop faster and only wait for 2s at the first time after the trigger (not wait for 2s every loop iteration).

 

Thanks for your suggestions again. I am trying my best to make this to work and also understand the entire operation. I really appreciate your help to get me through the final bit of the puzzle. 

 

Best,

Roy

 

0 Kudos
Message 6 of 8
(3,593 Views)

Hello Roy.a!

 

1. The situation that you are seeing here can be identified as 'glitching'.  Glitching occurs where there is potential for previous samples in a buffer to be mixed in with newer samples written into the buffer, causing a signal output that is a mix between the old and new data you are trying to output.  In the DAQmx Help document, search for 'glitching' and you will be directed to an article which explains glitching, mentions Warning 200015 is thrown where there is a potential for this to happen, and then offers suggestions on how to work around this issue, as well as two pictures that clarifies what could happen with glitching.

 

This warning pops up in your application since you are writing one set of data and then writing a second set of data afterwards.  If you do not see glitching on your signal, you can modify your code to ignore this warning.  Read through the help document for suggestions on modifications that will work for your application.

 

2, 3, 4 (and 5). I think you could revisit the logic that is inside of the input loop related to the "Threshold crossed?" boolean. I'm not exactly sure what the current functionality is doing. It seems like only the first value of the generated array from the read function is being compared to the threshold temp when it should be the live streamed value. You could delete the indexing portion of the code to check for the max and min values of the entire array, not just the first value. Maybe you could explain what it is doing currently?

 

Also do you have two Analog Input tasks for a specific reason? I see there is one AI Temp Thermocouple task as well as an AI Voltage task. Do you need both of these? Or only one? If they are both trying to measure the AI of the thermocouples, you only need one of them (probably only need the TC task).

 

 

 

John H.
Applications Engineering
National Instruments
0 Kudos
Message 7 of 8
(3,567 Views)

Thanks John.. I will look into glitching and update on what I get soon..

 

The AI voltage channel I have along with the TC in the same task, is reading the AO voltage sent out to the valve. I wanted to read it to check on the AO voltage value. I kept it in the same task because the sampling rate can be same as live streaming the TC data.

 

That is why I use the indexing on the DAQmx Read data to select the TC channel reading and as I mentioned earlier, whenever any value of the TC array crosses the threshold at 2s after the trigger first time, the boolean "Threshold Crossed" is TRUE and keeps the AO voltage out to be 5V (the valve remians open). Otherwise, if the threshold is not crossed, it sends out 0V to the valve (closes the valve). Finallly, when the test ends Click on Stop-1 to initialize the AO output to 0V (closes the valve). Since, I have the loop timing to be 2s, therefore when the threshold is crossed after the 1st iteration (2s), the AO output that I read in the AI channel should go to 5V immediately, which it doesn't for my case. It only goes to 5V after 2nd iteration - I hope I tried to make it clear what I am trying to acheive and on what logic I coded it. Any suggestions?

 

It's a fairly straighforward logic I believe, just the implementation in Labview is tricky! 

 

-Roy

 

0 Kudos
Message 8 of 8
(3,559 Views)