From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Timed Shutoff

Hi all,

 

I’m a recent ME grad and have a little bit of LabView experience from university. Timing is a portion of LabView that I never really dealt with and it’s causing me a bit of trouble. I'm working on a program that will control a series of autoclaves. I currently have a working code that measures temperature from a  thermocouple connected to an NI-9211 and then, using an NI-9472, turns an oven on or off depending on whether that temperature is above or below the desired temperature and the system is turned on. After a little bit of thought, I decided there should be a timer that can be set to make sure that an oven turns off on its own in case an operator can’t get back to it in time.

 

Before posting this, I tried doing some research on the matter and found that this is a pretty common question. After some reading, I looked into the example “State Machine” but I don’t really know how to apply it to what I want.

 

Ultimately, I would like to be able to input a time, say 15 minutes, and have an indicator count down to 0 and then turn off the signal to the oven so it turns off. I tried playing with the Elapsed Time and Time Delay VIs, but I couldn't figure out how to use them properly. Would anybody be able to help me out with this? I have attached a screenshot of the program if it should help.

 

Thanks!

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

@DeanAK wrote:

I have attached a screenshot of the program if it should help.

 


Not so much, but attaching your VI (or "code") is immensely helpful.  If you have several VIs (more than 3), put them in a folder, compress the folder, and attach the ZIP file.

 

Bob Schor

0 Kudos
Message 2 of 13
(3,753 Views)

Hi Bob, rather than upload the whole program, Here are a couple samples of what I am looking to accomplish.

I have a Timer VI that I made - it works fine on its own. I also have a Button VI that turns on my DO when I push the button. The 3rd VI is where I'm trying to combine the two. It seemed like I was able to get it working for a moment, but then I think it started looping.

 

I would like to be able to run the VI, then push the On/Off button and start the timer so that the signal goes out and turns on. After the timer runs out or I press stop, then the led should go out and data stops.

 

Thanks again!

0 Kudos
Message 3 of 13
(3,744 Views)

If I'm correct, you want a Timer that has the following properties:

  • When "Off", you can set an "On Time" (for simplicity, let's specify this in milliseconds) that, when you turn it "On", will stay On for that length of time, and then turn Off.
  • If "On", you can also "manually" turn it Off.
  • The output of this Timer is a Boolean that I'll call "Gate", as you will use this to "Gate" another signal (i.e. pass it if On, block it if Off).

The system being Controlled is a DAQ Digital Output device (one channel).  For goodness sake, DAQmx is so simple that you should absolutely banish the Dreaded DAQ Assistant and use the 2 or 3 DAQmx functions appropriate for your Device to do the work for you (your DAQ code will be simpler and will work).  To learn more, go on the Web and look for "Learn 10 Functions in NI-DAQmx" and read the referenced White Paper.

 

So let's look at what you want in a Timer.  You want a Boolean Control I'll call "Go", the one that when you turn On starts the Timer and, if On, can be pressed again to turn it Off, and is also turned Off by the Timer expiring.  You want an "On-Time (ms)" Control that says how long "Go" will be on (if you don't turn it off, yourself).  You want an output, "Gate", that is always present and always reflects the current state of "Go".  And, as a bonus, you'd like this little routine, which basically does almost nothing (it "waits" and responds to button presses) to take almost no time.  Sounds impossible, right?  But this is LabVIEW ...

 

Do you know about Event Structures?  This is something that can sit idle (taking essentially no CPU time) waiting for "Something to Happen".  The three "Somethings" are (a) you push "Go" to turn it On, (b) you push "Go" to turn it off, or (c) your timer "times out".  What do you want to happen in each case?

  • You turn Go On.  You want to start a timer with whatever value is stored in "On-Time (ms)" so that the Timer will Time Out after the specified Delay.  You set Gate = True.
  • You turn Go Off.  You stop the Timer.  You set Gate = False.
  • The Timer "times out".  You set Go Off.

 An Event Structure will handle most of this for you using two Events -- the TimeOut Event and a Value Changed Event for Go.  So just for fun, I built such a Timer, probably with some "new things" you haven't seen.  Here it is, responding to the "Go" button, either going On or Off.

Timer Go.png

Start with the Event Loop on the left.  When Go is pressed (whether turning it On or Off), this Event is activated.  If Go has been turned on, the True Case, shown here, puts the On Time on the Shift Register (let's say it is 1000, meaning "Wait 1000 msec = 1 sec") and also puts the value of Go on the funny thing that seems to have a Green Pipe coming out of it.  I'll get to that.  This finishes the Event, and the While Loop "loops", loading the value put on the Shift Register (1000, remember?) onto the Hour Glass (time) input of the Event Loop.  When Go goes Off (the False Case), -1 is put on the Shift Register.

 

So what is the Green Pipe?  It is a Tag Channel Wire, something introduced in LabVIEW 2016 (and in hidden form in LabVIEW 2015).  Remember Data Flow, which says that nothing can get out of a Structure until it finishes?  Well, Channel Wires can "bypass" this Principle (notice the Pipe goes over, not through, the edge of the While Loop).  It goes into the adjacent While Loop, where it is connected to the Gate Indicator.  Hence when Go goes On, Gate will follow (and the same is true when Go goes Off).

 

So pushing Go wires On Time (ms) or -1 to the Shift Register, where it gets wired to the HourGlass.  Here is the TimeOut Event:

Timer Timeout.png

 

Timeout waits the number of milliseconds wired to the HourGlass, then "fires" its Event.  In this case, the Event is to turn Go Off, but to do it in such a way as to Fire the Go Event, which as we've seen, resets the Timeout to -1 (which means "Never Time Out".  So this waits however many milliseconds you specify, then turns Go (and thus Gate) off.  Good.  So how do you stop this monster?

 

 

 

Message 4 of 13
(3,729 Views)

If I'm correct, you want a Timer that has the following properties:

  • When "Off", you can set an "On Time" (for simplicity, let's specify this in milliseconds) that, when you turn it "On", will stay On for that length of time, and then turn Off.
  • If "On", you can also "manually" turn it Off.
  • The output of this Timer is a Boolean that I'll call "Gate", as you will use this to "Gate" another signal (i.e. pass it if On, block it if Off).

The system being Controlled is a DAQ Digital Output device (one channel).  For goodness sake, DAQmx is so simple that you should absolutely banish the Dreaded DAQ Assistant and use the 2 or 3 DAQmx functions appropriate for your Device to do the work for you (your DAQ code will be simpler and will work).  To learn more, go on the Web and look for "Learn 10 Functions in NI-DAQmx" and read the referenced White Paper.

 

So let's look at what you want in a Timer.  You want a Boolean Control I'll call "Go", the one that when you turn On starts the Timer and, if On, can be pressed again to turn it Off, and is also turned Off by the Timer expiring.  You want an "On-Time (ms)" Control that says how long "Go" will be on (if you don't turn it off, yourself).  You want an output, "Gate", that is always present and always reflects the current state of "Go".  And, as a bonus, you'd like this little routine, which basically does almost nothing (it "waits" and responds to button presses) to take almost no time.  Sounds impossible, right?  But this is LabVIEW ...

 

Do you know about Event Structures?  This is something that can sit idle (taking essentially no CPU time) waiting for "Something to Happen".  The three "Somethings" are (a) you push "Go" to turn it On, (b) you push "Go" to turn it off, or (c) your timer "times out".  What do you want to happen in each case?

  • You turn Go On.  You want to start a timer with whatever value is stored in "On-Time (ms)" so that the Timer will Time Out after the specified Delay.  You set Gate = True.
  • You turn Go Off.  You stop the Timer.  You set Gate = False.
  • The Timer "times out".  You set Go Off.

 An Event Structure will handle most of this for you using two Events -- the TimeOut Event and a Value Changed Event for Go.  So just for fun, I built such a Timer, probably with some "new things" you haven't seen.  Here it is, responding to the "Go" button, either going On or Off.

Timer Go.png

Start with the Event Loop on the left.  When Go is pressed (whether turning it On or Off), this Event is activated.  If Go has been turned on, the True Case, shown here, puts the On Time on the Shift Register (let's say it is 1000, meaning "Wait 1000 msec = 1 sec") and also puts the value of Go on the funny thing that seems to have a Green Pipe coming out of it.  I'll get to that.  This finishes the Event, and the While Loop "loops", loading the value put on the Shift Register (1000, remember?) onto the Hour Glass (time) input of the Event Loop.  When Go goes Off (the False Case), -1 is put on the Shift Register.

 

So what is the Green Pipe?  It is a Tag Channel Wire, something introduced in LabVIEW 2016 (and in hidden form in LabVIEW 2015).  Remember Data Flow, which says that nothing can get out of a Structure until it finishes?  Well, Channel Wires can "bypass" this Principle (notice the Pipe goes over, not through, the edge of the While Loop).  It goes into the adjacent While Loop, where it is connected to the Gate Indicator.  Hence when Go goes On, Gate will follow (and the same is true when Go goes Off).

 

So pushing Go wires On Time (ms) or -1 to the Shift Register, where it gets wired to the HourGlass.  Here is the TimeOut Event:

Timer Timeout.png

 

Timeout waits the number of milliseconds wired to the HourGlass, then "fires" its Event.  In this case, the Event is to turn Go Off, but to do it in such a way as to Fire the Go Event, which as we've seen, resets the Timeout to -1 (which means "Never Time Out".  So this waits however many milliseconds you specify, then turns Go (and thus Gate) off.  Good.  So how do you stop this monster?

 

 Timer Stop.png

Well, we add a Stop Button Value Change Event, and wire it to the Stop Indicator of the first While Loop, which stops this loop.  How do we stop the second Loop?  Use another "Loop-spanning" Tag Channel Wire, of course.

 

Now, I'm not sure what you want to do with your DAQ task (I think you can do much better than using the Dreaded DAQ Assistant), but that code could potentially be placed in the second Loop.

 

I'm attaching the entire VI.  I see you have LabVIEW 2016, so you should be able to play with this and see both that it works and maybe even how it works.  Have fun, and be creative.

 

Bob Schor

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

Hey Bob, thanks for all the information!

 

I'm going to have to pour through it for a little while to try and understand all of the different things you used. You're right, some of these are very new to me - mainly the shift registry and channels.

 

Before opening your demo, thank you again, by the way, I'm going to try to build the program on my own so I can figure out where everything is. I will report back within the next day or two.

 

Before I go, I'll tell you why I went with the DAQ Device. Plese, feel free to tell me if it's still not worth my time. Aside from force of habit from school, I am planning on having up to 8 outputs. Since I will use that many, I figured I will just have all the data outputs feed into an 8-element array that should run through the respective channels. That's my thought process anyway...

 

Thanks again!

0 Kudos
Message 6 of 13
(3,711 Views)

I highly recommend to take tutorials (like Core 1-2 online training)! You say shift registers were new for you. Shift registers are one of the fundamental basics in LabVIEW, usually covered in any tutorial at the very beginning.

 

Another thing about controlling ovens/heaters. I do not know the regulations in your workplace/laboratory, but at most places it is not allowed to use simple software controlled heaters. Imagine what happens if your Windows / LabVIEW application crashes/hangs? The heater loses control, and might keep heating. This can lead to serious accidents! In our laboratory we always use a redundant hard wired "safety shut-off" circuit. This is independent of the LabVIEW app/PC, and uses a second thermocouple. If a pre-definied temperature threshold reached, the circuit cuts the heating power off.

 

Another approach is to use a so called watchdog. There are different options, including hardware and software solutions from NI. Imagine it works in a way, that your LabVIEW application sends to the hardware (DIO, relay, whatever  you use) a watchdog signal periodically. If Windows hangs for example, the hardware will go into a pre-definied safe state, like shutting down the heater output.

About watchdog options in DAQmx you can read here: http://www.ni.com/product-documentation/14616/en/

0 Kudos
Message 7 of 13
(3,699 Views)

Hi Blokk,

I will definitely start the tutorials. I did a few sometime last year while in school but with all of my school work taking precedent, I clearly didn't retain all of it - I managed to learn enough to do what I needed to do for my experiments, I guess.

 

The dangers of controlling heaters by software, thank you for bringing this up as I hadn't thought about this. We do currently have a system where control of the heaters is done manually. We will certainly incorporate these controls to have a manual shutoff, but I really like the watchdog idea that you mentioned as an additional form of redundancy. I will look into this further!

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

Pardon the late response, this project got shelved for a few days while another piece of work got in the way. I was able to get the timer to work as I want it to, so thank you!. The only question I have now, is how to keep track of how much time has passed? I tried adding an Elapsed Time function but I can't seem to use my input time without breaking the program or the indicator not live updating. As I have it attached, the indicator isn't updating.

 

Thanks again!

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

There are a couple different methods for keep track of elapsed time in the link below.

 

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P839SAC

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