How can I get two sub-VIs to run simultaneously?

[JPHickey77]

I have a VI with a sequence structure. Inside the first frame of it, there are two VI's (one to control a platform, and one to read counts from a photon detector) that I must have running at the same time. What can I do with what I have here?

[Ben]

Hi Joe,

Now that I've seen your code, I my be able to help.
First, let me say that what you are trying to do is not trivial. From what I can see it looks like you are trying so scan using one of your analog outs along the the x-axis and while this is going on, count some evenets from a photon detector. The important word here is "WHILE". This means your are going to have to work some method of syncronizing the AO and counting.

in general, this means you are going to more closly couple the two operations. More specifically, you will have to take all of the counter set and config operations to your "first try" VI such that all of the set stuff for both the AO and the counter are done before you enter any loops. As a finial setup step you should configure the count
ers to start based on a trigger that comes from your AO process. The details of how to configure the triggering is going to be dependent and you hardware. The have been many questions and posts regarding triggering on this exchange. I suggest you search for discussions of triggering.

Two additional notes that;
When ever I intend to do more than one operation with a device (like repeated analog outs), I will do one config when I start the program, and just work with the same taks ID over and over again. The config operations take a long time.
Second, upgrade to 6.0.2, 6.0 is buggy and crashes alot.

This is in no way intended to be the last word from us. As you encounter problems fire away.

I hope this gets you moving,

Ben

[mikeporter]

If all you want is for the two subVIs to run at the same time, you're done. In LV the execution run is that any node with all its inputs satisfied will begin executing.

However, there are some other issues that you really need to address. The biggest is that you don't really have any systematic error handling. Some of the VIs pass errors internally but they usually end in a "General Error Handler" VI. The result is that when your code hits an error it will simply stop. No deinitialization, no bringing things back to a safe state. The process will still be going, just now there won't be any software control over it.

In addition, the lack of error handling is what makes the sequence structure you used necessary.

I'll play with your code a little over the
weekend and post a tweaked version Monday morning...

Mike...

[mikeporter]

As promised, here is the first pass tweak of your code. You'll notice that I have added a couple subVIs for managing errors that arise in the code. First, "Error Fork Stacker.vi" takes two error clusters and combines them into one. The other, "Error Stacker.vi", allows you to trace back an error to the exact instance of a vi that is generating an error--which can be helpful if your code uses the same subVI in several places. Finally, "Error Handler.vi" is sort of a shell that you need to customize a bit. As is, if the input error cluster is presenting an error it presents the user with a dialog box that allows them to either ignore the error and continue, or quit the application. The customizing you need to add is code for shutting down the external devices safely and bringing things to a safe condition.

Beyond that, a few things to be careful of is passing error clusters and refnums through FOR loops. You almost always want to pass them through using shift registers. First, without shift registers, if the FOR loop executes zero times signals originating inside the loop are passed out as default values which will hide any incoming error. Likewise, any refnums will be invalid coming out. If you use shift registers though, with zero iterations LV will set the right side of the SR to equal the left side, thereby preserving any input values. Second, without SRs any errors that occur on loops before the last one will be lost.

Another style point that can become very important, is to take the few extra seconds to route your wires neatly and make sure they don't run under other parts of your code. In the short term, I know it doesn't seem like a big thing but that's because right now you remember where everything connects. Give is 6 months or so and the memories grow dim and you'll spend a lot of time trying to remember where things go. I learned a long time ago that if you write your code such that its operation is apparent by ***reading*** it, you don't have to worry about ***remembering*** how it works. Which a the lady on TV says, is a GOOD thing...

Also note that I haven't addressed what your code actually does. By that I mean I haven't looked at any potential synchronization problems that might arise from the two routines that are operating in parallel--though I noticed another poster has addressed that issue.

If you have any questions on any of this, feel free to contact me directly...

Mike...

PS: remember that the hardest LV application you'll ever write is your first one because if you did it right, the second application you write will be half done when you start it...

mporter@arielcorp.com