LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Loop Termination/Camera Reinitialization in Master/Slave or Producer/Consumer Format

I am using Labview to program a camera to take a single shot on a hardware trigger. In the program, I would like to reconfigure the camera settings if there is a change in the user interface controls (exposure time, delay time, gain, etc). All of this is composed in a while loop where if there is a settings change, the code breaks out of the while loop and reconfigures the camera (see attached). Unfortunately, most of the loop duration is spent in pause waiting for the trigger, thus rendering the code inert. After a settings change, it thus takes one more photo to change the settings. The camera’s temporal response is critical due to the small timescales of the experiment (femto- to microseconds). We would like for the camera to be waiting for the trigger for as much time as possible.

 

Is there any way to break a while loop even if the loop has not fully executed? I have read for non-parallel processing this is the case. Master/Slave and Producer/Consumer parallel formats seem promising for the purpose of this code, but are they limited by the same stopping limitation as non-parallel codes?

 

Thanks!

 

Download All
0 Kudos
Message 1 of 3
(2,609 Views)

@lpuppy79 wrote:

 

 

Is there any way to break a while loop even if the loop has not fully executed? 


No.  Everything in the loop must finish.  What you can do is use a state machine architecture and break any given state down into smaller states that will execute more quickly.  If you need to stop and reconfigure, then you detect that and move on to the reconfigure state directly rather than having it move on to the next state you had planned.

 

I don't know IMAQ or how camera triggers work, but if you spend a long time waiting for a trigger to timeout, you need to plan to detect that you want to reconfigure before you start the wait for trigger, or set the trigger to a smaller wait and repeat that state of waiting for the trigger more often.  There is always a risk that whatever you are waiting to trigger on happens to happen right after your trigger timeouts and before you have a chance to wait for the trigger again.  But you'll have to figure out for you special circumstances the risk/reward.

 

With just a couple partial screenshots, we can't help you with the overall architecture any more, except for a few comments.

 

Tthe flat sequence structure is often not needed.  The fact you have it tells me that each of those frames probably belongs as a separate state in a state machine.

 

Why are you using all of those value property nodes?  You should be using the terminals themselves.  And if you can't use that, then a local variable would be better than a property node.

 

You have multiple AND functions strung together.  Instead of that, use a Compound Arithemetic Node.  Set it for AND mode.  You can then put in multiple inputs you want to AND together and get rid of all the extra AND functions.

0 Kudos
Message 2 of 3
(2,598 Views)

I completely agree with Ravens Fan, but will make a few additional (or maybe the same, said a different way) comments.

  • If you need help/comments on your code, attach your code.  This is most easily done by attaching the VI itself.  We need to be able to examine all aspects of the code (including looking at each case of a Case Statement, asking LabVIEW for "Help" on a function we might not recognize, etc.), including being able to modify and/or execute it (or parts of it).
  • If your Block Diagram is bigger than a "normal" screen, it is too big.  Make sub-VIs (and, for goodness sake, make an Icon for them with at least the name of the sub-VI showing).
  • There's a Design Pattern that might work well for you in this case.  Do a Web Search for "Event Driven State Machine".  This uses Front Panel Events (like changing the value of a Control, to which you want to react) and User Events (which you can name "User State").  Suppose you have a Gain control on your Front Panel.  You would create a Gain (Value Changed) Event, would put the new Gain on a Shift Register (so everyone using the Loop can see and use it), and then put "New Gain" on the User State Queue.  For this to work, you can't have a "Pause" waiting for a trigger.  So you ... don't wait for the trigger.  You set everything up, gain, delays, thresholds, then put "Wait for Trigger" on the User State Queue.  What this should do is to start whatever process runs that allows a trigger signal to be acquired (without seeing your code, I don't know how you do this).  When this occurs, you fire off another User Event called "Got Trigger" that starts your acquisition loop running.  
  • Again, without seeing your code, I can't comment on how you process the Acquisition, including how you decide to stop acquiring.

Do try to "hide the messy details" by judicious use of sub-VIs -- it is extremely difficult to understand a piece of code if wires, controls, and functions are running all over the place.

 

Bob Schor

0 Kudos
Message 3 of 3
(2,534 Views)