LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Thermocouple Enabling a DO

Solved!
Go to solution

I am trying to do something very simple, but can't seem to get it to work. I am trying to read a thermocouple, compare it to a high temperature value, and turn on a DO on if the temperature is below the value, with the default being off. Also, I am trying to change state, not write to the DO constantly. So on when it is true, and then switch to off when it's false.

 

I have looked at various examples (Thermocouple - Continuous Input, Digital - Continuous Output, Analog Input - Voltage and Thermocouple in a Single Task, etc.) and have been able to get each of the steps to work, but I can't get it to function as a whole program. I tried using a queue or a notifier to pass the boolean out from the temperature loop to enable the DO, and I tried using a local variable but neither worked. I am collecting temperatures with a NI 9213, sending DO signals with a NI 9375, and using LabVIEW 2018 SP1. It kind of works when I nest the DO loop in the other while loop, but it bogs the program down significantly. I have attached the program. Any advice would be appreciated.

0 Kudos
Message 1 of 13
(3,256 Views)

You are seriously over complicating this:

 

Lets break it down into steps...

  1. Measure Temperature (Temp)
  2. IF Temp < HighLimit
    1. THEN set DIO HIGH
  3. ELSE Set DIO Low
  4. Goto 1

A state machine is probably the architecture I would chose to do this.

These would be the most probable states

  1. Initialize: Setup all of your data acquisition, DIO, etc.
  2. Measure: Take a measurement
  3. Control: Check the measurement against the limit and turn the DIO off or on
  4. Exit: Shutdown your DAQ and program cleanly
  5. Error: Handle any errors

 

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 2 of 13
(3,225 Views)

I'm posting from a phone so I haven't seen your VI yet, but the Boolean Crossing node sounds like it might be useful.

 

You could then try just a case structure and on-demand sampling for the DO?


GCentral
0 Kudos
Message 3 of 13
(3,213 Views)

Not over complicating it as much as downright wrong.  Two loops, one with enqueue, other dequeue,  that will never exit to do anything productive with the boolean they are passing.

0 Kudos
Message 4 of 13
(3,200 Views)

I do not have an FGPA module, so I don't believe I can access that palette. That sounds like a very useful function.

0 Kudos
Message 5 of 13
(3,160 Views)

The issue is that this is a monitoring system that may be running for weeks or months. I have 10 thermocouple inputs, 3 analog inputs, an analog output, and a digital output. The inputs will be monitored continuously and then the data logged, this is just the part that controls the DO after doing the compare operation with one of the thermocouples. I am trying to get it working before I stuff it into the larger program. An IF statement would handle this well, I was using a case structure in lieu of that. I just need to get something (boolean, double, string, etc.) out of the while loop while it is running to control the case structure. Also, I did get it to work how I intended by placing the case structure inside the while loop. I figured this was wrong, though, because the program bogged down and when I ended it the computer would hang for several minutes. I will look into some examples for a state machine.

0 Kudos
Message 6 of 13
(3,158 Views)
Solution
Accepted by topic author burak84120

@burak84120 wrote:

I do not have an FGPA module, so I don't believe I can access that palette. That sounds like a very useful function.


Sorry - bad link from Google. Go to Signal Processing > Point by Point > Other Functions > Boolean Crossing.

 

The VI you attached won't work because the Dequeue output boolean is a tunnel that won't pass data until the loop (with Dequeue) ends.

You would need to have it in the same loop, but you don't want to be doing all of that setup and cleanup in the loop.

 

Set up your digital task beforehand, cleanup after you're done, and in the loop do nothing unless you detect a change with the boolean crossing (use a case structure).

To get on-demand sampling, DON'T use the DAQmx Timing node. Just wire to the Write node in the Case structure when you get the situation you want (i.e. the specific edge).


GCentral
Message 7 of 13
(3,151 Views)

The issue was to get the write to operate without bogging down the program. The boolean crossing works great to run the write loop on demand to avoid the bogging down issue, thanks for pointing out where that is, and I moved the create virtual channel outside the loops as you advised.

 

One remaining issue was that when the DO was enabled (line 1, by writing an array to it and changing the second byte from 2 to 0 via a case structure), the output was only passing 0.6 V, while I have 24 V wired to the VSup. I verified that when I enabled line 1 in the Measurement and Automation Explorer I got 24 V.

 

I had originally used 1Chan NSamp because that is what was used in the Digital - Continuous Output example. I got it to work, partially, with a nested while loop but it bogged down and the program would lock up. I tried 1Chan 1Samp, because that makes more sense, but it wouldn't even work partially. I stuck with the 1Chan NSamp after I made the most recent modifications, because that is what worked. When I got it working but was only getting 0.6 V I tried switching to 1Chan 1Samp and then everything worked as intended. I have attached the working program. Keep in mind this is a small part of a larger program, and because of that it isn't a complete program.

0 Kudos
Message 8 of 13
(3,140 Views)

Please take those LabVIEW tutorials. Your VI still has serious problems showing you don't understand dataflow.

 

1.  Your inner most case structure, the true and false case are identical.

2.  You have a while loop.  Why?  if you have a True going in from the boolean crossing. that loop will run forever.  If you have a false, then it will only run once.

3.  Your boolean shift register is basically unnecessary.  All it does is delay the result of the comparison for one loop iteration.

 

Try running your code in Highlight Execution mode and you'll understand.

0 Kudos
Message 9 of 13
(3,126 Views)

I was just trying to get it to work, which I accomplished with the last iteration. However, you make some good points. I decided to make some modifications as an exercise. I removed the case structure that was left over and the inner while loop as well. I left the boolean shift register because I want to default to off initially.

 

The Highlight Execution mode is amazing. I just started using LabVIEW about a week ago and have been trying to figure things out via NI's examples and help. I have been struggling to understand the task system and how things flow, and the probes don't tell you much if your task fails to execute. Highlight Execution is exactly what I needed. If I would've known about that when I started I could've probably finished the entire program by now.

0 Kudos
Message 10 of 13
(3,114 Views)