LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Highlight execution chaning vi functionality

I have been experiencing problems with a program I have been writing.  One of the most perplexing problems I've had is that using the Highligh Execution button changes how my program runs...  I am trying to output multiple TTL trigger pulses.  Depending on whether or not the Highlight Execution button is depressed, different parts of my code works or doesn't work.  I never get any error messages...it is just that not all of the pulses that I am asking for come out. 
 
So, I thought I would start a new broader thread with regard to this problem.  Has anyone else experienced a problem with the Highlight Execution function?  What exactly could be causing this?  Any suggestions or thougths would be appreciated!
 
Here is other thread that more specifically outlines the problems I've been having. 
0 Kudos
Message 1 of 11
(4,334 Views)
If highlight execution changes the outcome, you're always dealing with either a race condition or a timing issue. There must be a flaw in your code.
 
I'll have a look at your code in the other thread.
Message 2 of 11
(4,330 Views)

Are you talking about "Test Pulse Generators.vi"?

I don't know what your code does, but in each sequence frame you have two independent code fragments. ("output ttl ..." and "Generate 1 ttl..."). Does it matter which one executes first? Can both execute independently or is there some dependency e.g. via the hardware?

Why is there a wait 2000ms in the second frame? This does not make sense because the VI is over by then. Do you possibly need also a wait in the first frame?

Are you possibly running this using the "Continuous run" button??? That's NOT recommended!

Message 3 of 11
(4,324 Views)
If you're still talking about the Test Pulse Generators.llb in your other post, then you have a major problem with dataflow. In each of the sequence frames, you call two different subVIs. There is no data connecting the subVIs so LabVIEW will attempt to execute them in parallel. Simply putting one subVI to the left of another does not control execution order. When you turn on execution highlighting, it's like going into single step mode so then there is some order but you can never depend on it. At the very least, create some error in/error out connections on your subVIs. Then you can wire an error out  to an error in and control dataflow. With dataflow, you do not require a sequence structure.
Message 4 of 11
(4,324 Views)
Thank you so much for your help...I have been trying to figure this out for at least a month.   So do I understand correctly that there is no sequential case structure in LabVIEW?  The only way to do sequential executions is through data flow?  I largely taught myself how to use LabVIEW and this is a subtly that escaped me.  I would think that is a useful functionality.
 
 
0 Kudos
Message 5 of 11
(4,311 Views)
Well, yes there is a sequence structure, and you were already using it. It can be used to force strict execution order. Each frame cannot finish until all elements in it have finished. Everything in the next sequence frame must wait until the previous frame has finished. And so on... However, within each frame, you have no control of execution order if there is no data dependency.
 
Your problem was that your  first sequence frames contained two independent items without data dependency between them. The second frame contained 3 items (including the wait). Once everything in the first frame has finished, all three items in the second frame will start at roughly the same time. The wait will not influence anything, it would only delay stuff in a next frame, but there isn't one.
 
While data flow is always preferred you can achieve defined execution order by using e.g. a 5 frame sequence and aranging the 5 elements. As show in the example picture everything will occur nicely in sequence from let to right. Mix&match as needed.
 

Message Edited by altenbach on 08-08-2005 10:29 PM

Message 6 of 11
(4,310 Views)

Okay, so if this is a sequencing structure, then I don't think my problem is fixed (I am not in the lab right now and can't physically check it). 

I know that the subvi called TTL Pulse AO1 will run simultaneously with the Gen TTL subvis.  It is supposed to.  When the Gen TTL subvi runs, it needs a trigger pulse, which it gets from the TTL Pulse AO1 vi.  The TTL Pulse AO1 sends out multiple pulses so that the Gen TTL is triggered regardless of exactly when the TTL Pulse AO1 program started. 

Now, I can try adding error in and outs to my subvis and threading them throught my sequence structure so that there is data flowing between the structures to make sure that it is actually sequencing.  But if what you say is true about these really being sequencing structures and that no data flow is required...then this shouldn't make a difference.  I will try it anyway because I am desperate.

The guy from National Instruments who has been helping me on the other thread says my program works perfectly on his hardware. 

0 Kudos
Message 7 of 11
(4,306 Views)

I can't look at the code, but like Altenbach said, this is probably a timing issue. Placing the VIs in the same frame does not gurantee simultaneous execution. Theoretically, one VI could execute and the other will only start 2 minutes later.

You say the pulse VI sends multiple pulses, but what happens if the gen VI listened before the pulse VI started? Another option - is there some sort of timeout (listen only for n ms)? If you want to run one VI and then start running another while the first is running you can use the Run VI method with Wait Until Done set to F or you can use some synchronizing mechanism (for example, a global or something from the Advanced>>Synchronization palette) to make sure things happen in the proper order.

Another point is that in general it is very important to handle the errors properly. You should use the error clusters, if only for that.


___________________
Try to take over the world!
0 Kudos
Message 8 of 11
(4,292 Views)


@snidjer wrote:

Okay, so if this is a sequencing structure, then I don't think my problem is fixed (I am not in the lab right now and can't physically check it). 

I know that the subvi called TTL Pulse AO1 will run simultaneously with the Gen TTL subvis.  It is supposed to.  When the Gen TTL subvi runs, it needs a trigger pulse, which it gets from the TTL Pulse AO1 vi.  The TTL Pulse AO1 sends out multiple pulses so that the Gen TTL is triggered regardless of exactly when the TTL Pulse AO1 program started. 


There is no reason that LabVIEW cannot do what you want. Maybe you can solve your issues by combining the "TTL pulse AO" and "Gen TTL" into a single subVI and mesh the functional parts on a finer scale. Maybe the two tasks need to start in a defined order? Can the "TTL Pulse AO" run all the time? Start it at the beginning of the program in an independent code segement.
0 Kudos
Message 9 of 11
(4,285 Views)
I will try running the Gen TTL AO1 application continuously while I sequentially run Gen 1 TTL and then Gen TTLs.  As you say, this should avoid a timing out problem.
 
I think it may be useful for me to describe my observations more specifically.  So, the first sequence in my case structure runs properly, regardless of whether it is Gen 1 TTL or Gen TTLs (it is triggered properly by the AO1 application within its structure.  However, the second sequence never works, although I can watch the AO1 trigger pulses so I know that they are being output properly. 
 
Now, if I push the highlight execution button, the Gen TTLs vi stops working regardless of its position in the sequence (first or second).  I can get it to work again if I place a 2 second delay in its case structure (that is why the delay you saw was in my program).  I've tried really long delays in with it and then not highlighting execution, but that does not work.  I have also tried adding a structure with only a delay in it in between my pulse generating vis, but that doesn't work either.  The Gen 1 TTL vi always works when highlight execution is pressed.
 
0 Kudos
Message 10 of 11
(4,270 Views)