Problem with dual counter tasks

[scott312]

I have two counter tasks which I just discoverd that if one stops they both stop. Is there a work-around for this case besides a counter card?

See attached screen capture.

sc

[Bob_Schor]

A picture, such as you have attached, is frustrating and useless (and makes my blood pressure rise).  You show a piece of a VI, I can't look at other Case elements, I can't follow wires that go off the page, I can't say "I don't recognize that VI, let me pull up the LabVIEW Help by right-clicking it and choosing "Help", etc.

If you really want someone to look at your code, attach your code (the easiest way to do this it to attach the VI, itself).  Now we can examine it properly, see all of it, see the "invisible" Cases, get Help outselves for functions we don't recognize, maybe even run the code and study its behavior (or errors).

Bob Schor

[scott312]

Bob,

Thank you for the advice. I will follow your guidance going forward.

The vi is attached (Labview 2015)

sc

[Bob_Schor]

Am I correct that the two counter tasks to which you refer are the Speed Sense Counter and the Encoder Counter, both going into the lower While loop?  The reason they both turn off together is that you programmed them that way -- when the lower loop exits, you stop both tasks.

If you want them to run independently, you need to put them in independent (parallel) loops.

Some suggestions for tightening your code a little and making things fit on a single screen (so you can See the Forest for the Trees).  Consider a State Machine model, with an Initialize (where you set up the DAQ), Run (where you do basically what's in the While loops), and Stop (where you clean up and stop things).  That will shrink your VI from left to right.

To shrink from top to bottom, consider "hiding" some of the messy details in (one or a dozen) sub-VIs.

I notice you have a Queue whose status you check, and if full, you discard an element.  Take a look at the Lossy Queue, which does this automatically for you.  You might want to consider whether or not you want a Lossy Queue, as it contains the possibility of "losing" data.

Bob Schor

[Bob_Schor]

Oops, I didn't look carefully enough at your Block Diagram.  I think you missed the point of the Queue -- you want to use the Producer/Consumer Design Pattern, and you've made a good start by enqueuing the data you want to write into your TDMS file.

Now create a (third) While Loop, which will become the "Consumer" part, and bring a branch of the Queue (after it is created but before it goes into the Producer, middle, While loop) into it.  Put all of the code that handles Dequeuing and sending the data to the TDMS file into this third loop.  Note that you might also want a State Machine-like pattern here, too, as you want to Initialize the TDMS stuff, Run it (which is where your Dequeue would go), and then Close it when the middle (Producer) loop exits, releases the Queue, thereby generating an Error in the Consumer Dequeue function, which you trap, clear, and send the Consumer loop into its Close state (where it closes the TDMS file).

That's the whole point of the Queue, to get multiple loops running independently at their own inherent speed, with the Queue serving as a "buffer" to let the loops "adjust" their speed to keep the data flowing.  I suspect that if you use the Queue in this way, you can safely use an "unbounded" Queue as it is unlikely to grow very big (simplifies your code, and you never lose any data).  [See my comment on Lossy Queues in my previous post].

Bob Schor

[scott312]

Bob,

Your suggestions are very much appreaciated and I will take to heart everything you've suggested. As I'm sure you've already know this is my first, an maybe last attempt as Labview. I volunteered to write the program to help address and short term need to capture shaft deacceleration data in the field durning braking period when the motor is coming to a stop. The time-frame is very short and I'm about 6 or 7 weeks in.

I was having trouble running independent counter loops before, getting an error code. I will separate them into two loops and see what happens.

Thanks,

sc

[Bob_Schor]

Oh, dear -- do you mean that this is "serious work", possibly for tests done on real devices that some of us might use some day, and there's a "hurry-up-and-get-me-something" task, to be developed in LabVIEW, given to someone who doesn't know LabVIEW and doesn't plan to continue learning and using it?  Not very encouraging sign of Modern Industrial Development.  If this is for a commercial entity, may I respectfully suggest that you share this communication with your boss(es) and suggest that they invest in hiring a skilled LabVIEW Developer on a short-term basis and get a product that will (a) work, (b) produce reliable, "trustable" data, and (c) get it all done in a few (2-3, I'd estimate) weeks?  Such people do exist, and they are really worth the small cost (compared with lawsuits if tests are not done in a reliable manner).

Bob Schor

[scott312]

Bob,

I separated the counter inputs whiched solved the 1-off both off issue but it did uncover another: if the task times out waiting for sensor input it will generate and error code (50103) and not restart. Can the tasks be restarted or the error handled such that it will come back online? If for some reason the sensor failed the task would need to restart w/o restarting the hardware.

I've attached a smaller revised part of the code I was testing uncovering this issue.

Thank you,

sc

[Bob_Schor]

You don't understand the Producer/Consumer Design Pattern!  Read this White Paper and check out the Producer/Consumer Template that NI provides (create it by clicking the File Menu, choose "New ...", and under From Template, find Producer/Consumer Design Pattern (Data).  

Your Producer loops (with the DAQmx Reads) need to be where the data are Enqueued, and your Consumer loops (below) just do the Dequeue.  Study the examples, and try again.

Bob Schor