stop button sync

[djsunkist]

Here is the basic gyst of my code: at 5 different stations, i randomly turn on an L.E.D., then wait for a user to flip a switch at that station, ackknowledged by the VI, then randomly light the next L.E.D. and so forth (durability reasons), all while monitoring current in the system. I cannot figure how to make one boolean a "master" to stop execution of the VI. "Abort" works for a couple of tries, then it's a pre-emptive reBoot !!  (I think one of my loops is racing)

Any help is greatly appreciated. I've looked at numerous threads in more than a couple forums here, and can't find a solution that matches my particular problem.

Thanks for the help,

1hungryhobbit

[DianeS]

I'm not trying to be offensive -- I believe you looked -- but this particular question has been discussed extensively on this forum.

For a great discussion on how to stop multiple loops with one stop button, look here.  There are about a zillion others, but that's my favorite.

Another problem you're having is that you are using DAQ Express VIs, which create and destroy the DAQ tasks every time they execute.  This results in a memory leak, which can and does cause the problem you're having with having to abort your VI instead of stopping it with your stop button.  This issue has also been discussed extensively on this forum.

Don't use DAQ Express VIs.  Use the DAQ primitives.  Create and start your tasks before your loop.  Run them in your loop.  Stop and clear them after the loop has finished executing.  Look under "Find Examples...Hardware Input and Output...DAQmx..." for example code which shows you how to use the DAQ primitives.  Use these primitives for all of your DAQ operations and get rid of all the Express VIs.

Finally, your architecture isn't the greatest.  You can simplify things quite a bit. 

You do not need a separate loop for your current monitor.  You can have all three of your DAQ operations in the same loop.  All you really need is a single while loop, containing all three DAQ operations, coded using DAQ primitives.  This, of course, also solves your problem with the stop button.  Use the error wire to enforce dataflow if you want your digital output function to occur before your digital input function.  Right now you have nothing which forces any kind of execution order, so I assume it doesn't matter which one executes first.  If it does, then you need to do something to make sure that happens, and the error wire is the best way to do that.

Hope this helps a little!

[JÞB]

Megga Dittos to what Diane said.  Great advice.

As an aside but a point that should be cleared up is the distinction between vi's and primitives on the functions palattes.

the DAQmx API is a collection of vi's (and polymorphic vis) with FP's ,BD's  and everything they reside in vi.llb.  They are distinct from "LabVIEW primitives" like the array functions or most functions on the comparision palatte (there is an express.vi there)  Primitives are not vi's they have no FP, or BD just terminals that may adapt to a wire datatype and icons I don't really know where they hang out on disc.

[djsunkist]

Okay, being completely new to these primitives, I have two questions. Firstly, what "data" specifically gets routed into the data port of the DAQmx read node for my application? Right now I have just a true constant, so all L.E.D.s turn on eventually, but I want only the number initially generated to turn on ( I'm thinking there's a loop placement involved). Second, how do I differentiate which of my digital ins have gone high?, because I need that high to equal the # that was generated at the start in order to continue.

Here's my butchered up vi so far:

All of the examples I've seen are either too basic or way too frickin' complicated.

Any help is greatly appreciated!

[DianeS]

Remember how I told you that you need to create your tasks outside your loop, and clear them after your loop is finished executing?

You need to do that.  Otherwise you'll have the same memory leak problem as you had with the Express VIs.

As for what to write to your output task...the state of your LEDs, of course.  You know that boolean array you generate?  That's the state of your LEDs, so that's what you want to write.

Remember how I told you to use the error wire to dictate the order of execution?  You need to do that too.  You don't want to read the state of the LEDs before you set it, right?  Especially since the state of your LEDs might change with every loop iteration.  What if your READ happened before your WRITE?  How would you know if the correct LED had been activated?

As for finding which input went high, create an indicator on the front panel which displays the output from your Read function.  I don't think you want a waveform -- use a boolean array.

See attached.  I know you're new and I sympathize, but it looks like the only part of my advice you actually followed was switching to the DAQmx functions and getting rid of those extraneous while loops.  The other stuff I told you to do is important too.  The way you wrote your code, with the task creation / clearance inside your loop, will result in exactly the same problem you had before with having to abort instead of using your stop button.  And with nothing forcing your read to happen after you write, you have no way of knowing if your write was successful.