So I have a lot of while loops that need to not run concurrently.

[Ralph@NES]

I'll attach the VI at the end.

This seems to be working very well overall as far as functionality, but the timing is getting funky.

I've tried to use a Wait and Wait for next ms multiple to prevent these loops from running at the same time and causing hardware conflicts.  It seems like I'm really messing up the loop counts, though, as I've got indicators on the loop iterations which are telling me that some of the loops are running a lot faster than the others.

I got this idea for Wait For Next Ms Multiple on here in a search and it seems to work great on my simple two-loop program on my other system, but isn't working out well with this many loops.

Basically, I'd like for these 7 or 8 loops to each run every 10 seconds or so, but NOT start all at the same time so that they aren't trying to access the same DAQ and causing hardware conflicts.

Other than that, I know my code isn't pretty and I've abused local variables like crazy, but it's basically doing what I want.  Just not WHEN I want.

What's the secret to this loop timing?

Thanks in advance!

[smercurio_fc]

"Other than that, I know my code isn't pretty and I've abused local variables like crazy,"

I'll let altenbach comment on the local variables. He loves to pounce whenever he seems them being overused.

Multiple processes all trying to access a shared resource is typically solved using semaphores. You can use these to control access to your shared resource so that only one loop can talk to the DAQ card at any one time.

What's not clear is how the loops are supposed to recover from "missed timing". For instance, if the file I/O takes an inordinate amount of time (since it's dependent on the OS), how should the loops recover? You may want to loop at timed loops to better control your loop timing. You can find the Timed Loop in the Structures->Timed Structures functions palette.

Tip: In the one loop off to the right you're taking a plethora of local variables, converting them to dynamic data, and using the Merge Signals primitive. You do not need to first convert them to dynamic data. You can wire them directly to the Merge Signals primitive.

[Ralph@NES]

Nice, I'll undo that conversion.

Actually I really don't need these to happen at any specific time or in any specific sequence, I just need to make sure they're all running roughly at the same iteration and not firing concurrently.  This is going to run unattended 24 hours a day and I can't have hardware conflicts causing stops.  Beyond that, everything else is trivial.

And can you point me in the direction of some info on how to use semaphores?

Message Edited by Ralph@NES on 08-10-2007 10:17 AM

[johnsold]

You appear (I say appear because too many wires run left to right and behind things to be sure) to have a large amount of duplicated code: the case structures with the Elapsed time and Write to Text File VIs. Make subVIs. Then you can reduce the size of your diagram to one screen where it can be perceived and comprehended. Look at the Style Guide.

What is the purpose of having both a Wait and Wait until next multiple in each loop?

I suspect that a fairly straightforward state machine architecture would get you to one or two loops with no resource contention problems and much more robust timing control. It would also let you get rid of the local variables.

Lynn

[Ben]

Timed loops let you define loop rates and offsets between execution of each (provided the code executed finishes before the next one fires).

Ben

[Dennis_Knutson]

I don't understand why you don't avoid the hardware conflicts but just using a single DAQ Assistant for each task. Why have two separate ones for analog input when one will do? With a little bit of effort, you could combine the analog output tasks into one as well.

[altenbach]

---

Ralph@NES wrote:

What's the secret to this loop timing?

---

Dennis and otheres already gave you some good advice on the DAQ part, so I won't repeat it.

There are some real glaring errors besides the problems you are telling us.

FIrst, your idea to run both a wait and a wait next ms multiple in the same loop is flawed, because they will both run in parallel and the longer of the two will fully and exclusively determine the loop time. The shorter of the two will  complete earlier and will have absolutely no influence on the loop timing. You need to familiarize yourself better with dataflow programming.

Notice that you open all these files, but depending on the cases, you loose the file reference when exiting case structures (tunnel set to use default if unwired). The default is an invalid reference and this means that the "file close" cannot complete under this condition.

From an UI perspective, it seem ridicuous that the user needs to press a dozen stop buttons to stop the program, with no way to recover if e.g. one of the stop buttons has been pressed only by accident.

I am pretty sure your entire code could be reduced in complexity by 90% with a bit of effort. You are doing way too many duplicate things.  A state machine comes to mind. It would automatically protect states for executing concurrently.

Your FP could be simplified by using arrays of indicators for example.

I would probably not try to fix the current code. This is a case where a complete teardown and rebuild would be approriate. Good luck! 🙂

Message Edited by altenbach on 08-10-2007 08:09 AM

[Ralph@NES]

I was going to address the multiple stops shortly.  I just left them there for the time being, as well as the iteration indicators, for troubleshooting.

As far as a 'tear down and rebuild goes', I'm going to be honest.  I have absolutely no training on Labview and little experience.  Everything you see is 'the best way I know how'.

As far as programming experience, basic and a tad bit of C+ are all I have, and that was years ago.  Frankly I'm the wrong man for the job, but the only one in my facility with any capability whatsoever.

I have no idea how to use a subVI, and most case structures beyond what you see in that VI are completely beyond me.

The reason for the multiple file writes is that I want multiple and discreet output files.

My employer is planning on sending me to the Labview courses this fall but until then, I'm making due with what I've been able to glean from trial and error.

I'll see what I can do about combining some tasks, because that's something that I thought about already, but I'm still going to need a way to keep the remaining loops from conflicting.

[johnsold]

I can understand the confusion.

Try taking one bite at a time. Spend some time with the tutorials and examples. Case structures and subVIs are fundamental concepts in LabVIEW. Without understanding these, you will never be able to get something like what you want to work except by accident.

Then make a subVI which takes your data and writes it to a file. The file names, data, and error clusters will be input parameters and outputs will at least include error out. The elapsed time fucntions could be in there also with the time as an input, but the program probably will work beter it the timing is handled otherwise. This will take the place of blocks of code in case structures which you have all over your diagram. Seeing how the commonality of all those pieces can be made to work for you will help you gain some confidence that you can make this thing work.

Then work on another issue. and so forth.

After the tutorials and some practice with some of these concepts, walk away from LabVIEW for a while and DESIGN the program. By that I mean that you must specify what happens and when. Each block will have inputs and outputs. The inputs determine what a given block does and the outputs determine what happens next. This can be a flow chart or a state diagram or an epic poem, but it is not a LV program. You use the design document to guide you in writing the program. When you start working on this document you will find that questions like "How do you avoid DAQ resource conflict?" can be resolved by defining the access to the resource.

Lynn

[Ralph@NES]

OK, I just spent the past couple hours trimming and aligning everything so that it makes more sense.  I've only got three loops now (historically the timing loops containing the stopwatch VI's work better separately).  Hit the run button a couple of times and noticed no exceptions.

Now, I have multiple DAQ assistants calling the same two cards and resources.  Thus far, none of them seem to be causing conflicts but as was mentioned, this is probably by sheer luck.

How can I go about using the error function or similar to make sure none of these are going to conflict?  Also, I am a little concerned about the case structures that are connected to analog out for fan control.  Once those are on, I would like them to stay on until the low temperature is reached.  Since they're in a loop, will they not reset every iteration?

Message Edited by Ralph@NES on 08-10-2007 02:23 PM