Start DAQ acquisition or reading on TTL rising front

[scozia123]

Good morning everyone,

What I have is a camera, an optical chopper, a NI DAQ 6221 and several other hardware elements.

The chopper is such to output a TTL signal (On and Off signal) thanks to a photodiode in front of it

The setup is such that the chopper is right after a beam splitter, so that the TTL signal actually tells me if I am acquiring the transmitted or reflected beam out of the BS, since the camera is triggered with a signal that doubles the chopper frequency.

What I want to do is to acquire the first frame always with the same beam (no matter which one of the two, but the same at any measurement).

In the attachments please find what I have done up to now, the software may look a little clumsy I know, but I am not a good Labview programmer.

At the moment I am sampling the TTL, notifying a change in its state for Ctr0 (2*fchopper signal), Ctr1 delays what is in Ctr1 and triggers the camera with trigger task.

Thank you for your time and kindness

[Bob_Schor]

Somewhere around LabVIEW 2014, "Snippets" (from the Edit menu, "Create Snippet from Selected") allowed you to create a .PNG file that not only was a static "picture" (helpful only to look at, but you could view it regardless of which version of LabVIEW you had) but also with enough NI Magic that if you dragged the Image to a Block Diagram, it became LabVIEW code.

I need to see LabVIEW code, preferable an entire VI.  This lets me look outside the boundaries of the Image, where the "real problem" might lie.

But never mind.  Without looking at your code,  I have a question -- you seem to have a TTL signal that can serve as a Trigger for your A/D acquisition.  Why not wire this to a PFI digital input, and configure your A/D to use that PFI input as the Analog Trigger?  You wouldn't need to use any "code" (with potential timing issues) to synchronize A/D conversion with its "Start" signal.  Less code = less room for mistakes and quicker responses.  It appears that your hardware supports this ...

Bob Schor

[Kevin_Price]

This is a pretty complex timing & sync scheme among your tasks and at a first glance it looks likely to be generally good.   [EDIT: no wonder I had that feeling of deja vu.  We had a related discussion a little while back.]

Let me rephrase to see if I understand your intentions correctly:

1. The *state* of your TTL chopper signal (Hi or Lo) tells whether you're acquiring the transmitted or the reflected beam

2. Your camera acquires on the output of Ctr0, which generates a single delayed pulse after every chopper transition.

3. You want to know (or perhaps control) whether the 1st acquisition is a transmitted or a reflected beam.

I think the most straightforward way to do that is to add an Arm Start trigger to the Ctr0 task.  It'll continue to use the ChangeDetect event as a retriggerable start trigger.  But the Arm Start will be a one-time-only way to control the initial polarity and thus select which beam type is acquired first.  (You may need to parallel wire the chopper signal to both digital port 0 *and* a PFI pin to make this work.)

[EDIT: with reference to the end of that previous discusion, it remains unclear whether the DO or Ctr1 tasks are actually important and useful or whether they're just clutter you can get rid of.]

-Kevin P

[scozia123]

Thank you all for your time and support,

Bob_Schor please fin in the attachments the entire VI of software, but I cannot use directly the TTL from the photodiode since I need the signal to have a frequency which doubles the chopper frequency, with also the possibility to introduce some ms delay between the TTL and the trigger signal, that's the reason of the dummy tasks.

Kevin_Price, you are probably right with your solution, I will try it as soon as possible.

Probably you are also right on your final comment, I will work on it.

Thank you all again for your precious help

Kind regards

[scozia123]

Good morning,

I tried with your suggestion, but the system recognizes the right front 90% of the time, reverting the two branches 10% of the time points.

Is there any way to avoid this?

Kind regards

[Kevin_Price]

Please post your latest code that shows those symptoms and describe the whole situation more completely & clearly.   I really don't know what you mean by, "reverting the two branches 10% of the time points".

-Kevin P

[scozia123]

Please find in the attachments my last version of the software with a snippet of the interested state.

I have the two branches, alternated by a chopper, and I want the chopper and the acquisition to be synchronized so that when I acquire, the first image always corresponds to one of the two paths (doesn't matter which one of the two).

I made a try with the property node "arm start trigger", as you suggested.

The try was that of starting several acquisitions with one of the branches stopped after the chopper by a shutter, so that ideally, over let's say 100 measurements, all of them would have started with the same first image (coming from the non stopped beam), and then a dark image (dark because the beam was stopped before shining the sample). What I measured is that over 100 measurements, almost 90 start with the ON image, while the other 10 images start with an OFF acquisition (like if they were triggered by the falling edge of the chopper TTL).

What I want is the first image to correspond always to the same branch, i.e. always to the rising (or falling) edge of the TTL output by the chooper.

Maybe it is simply too long, but I tried to explain it at my best.

Thank you again for your time and kindness

[Kevin_Price]

I'm still at LV2016 and can't open the full code.  Can you "Save for Previous Version..." back to 2016 or earlier and repost?

The clues I see in the snippet and your description of "usually but not always" behavior make me suspect that the needed sequencing for task starts might not be in place.  The hardware config settings ought to be able to give you consistent, predictable behavior. 

    Another possibility is that the Ctr pulse parameters delay your timing signals long enough that the chopper wheel has the chance to change state before the frame grab happens.  If the chopper speed can vary from run to run (as I suspect it can), that's another way you might get a 90/10 split in behavior.

I compared your recent screenshot with the snippet I posted previously in a related thread.  In my snippet, I used the "Merge Errors" function to enforce the sequencing of task starts.  Specifically, all the dependent tasks were started *before* the Merge while the master controlling task (triggered pulse generator) was started *after*.   Your screenshot doesn't show any of the task starts so I can't tell whether the correct sequencing is in place.  And note that the addition of the Arm Start trigger needs to be considered when determining the *right* sequence.

I just reviewed that other thread I linked to in more depth and I'd urge you to review it carefully as well.  It has some potentially important info about pulse timing parameters (including 'initial delay' that you've left unwired).   It also continues to sound to me as though DO and probably Ctr1 tasks are not necessary and may be adding unnecessary complication, possibly contributing to the 10% undesired behavior. 

The idle state and pulse parameters for Ctr0 give you the ability to control the timing of the edge that initiates a camera frame grab.  I don't think you need Ctr1 to add delay.  After all, the more delay you add, the more likely it is that the chopper signal changes state between the time you react to a specific edge and the time your pulse causes a frame grab to occur.

The following things should help make 100% consistent behavior:

- correct task start sequencing (I'll check after you back-save to LV 2016)

- extremely short durations (such as < 1 microsec) for all pulse params -- low time, high time, initial delay.

If your real app needs longer delays for a specific purpose, we'll come back to that.  Let's first demonstrate that we can produce predictable behavior 100% of the time.

 -Kevin P

[scozia123]

Good morning,

please find in the attachments the LV2016 version, with one of the main subVI.

For what I can say about the sequencing for task start, I think that is right.

Yesterday I tried the software with the chopper going at higher frequencies (20Hz), instead of the previous 5Hz, and everything worked as planned, I took 400 time points and any one of them had the first image synchronized.

The fact that I used maybe too many dummy task is beacause I want to make a delayed copy at 2 * fchopper, in order to synchronize the acquisition of one frame with a single branch, so that delay is necessary because of the photodiode position and the chopper mask.

I will also try to shorten the pulses.

Is it possible that the correct behaviour of the Arm.Start node is somehow influenced by the chopper frequency as I saw?

Thank you in advance,

Kind regards

[Kevin_Price · Accepted solution]

The task start sequencing looks ok for all the counter and digital tasks.  I think you should probably be starting your AI task *before* DigitalCounter Task though.

I would say that NO, it isn't possible that the correct behavior of the Arm.Start node is influenced by the chopper frequency.   I'd say the reason it kinda *looks* that way almost certainly has to do with my second point about all the parameters that control pulse timing.

You have a chopper wheel in motion.  From the moment you start the DigitalCounter Task, the very next chopper wheel *edge* of the chosen Arm Start polarity will arm Ctr0 and let it start doing its job of retriggered pulse generation.  The regular Start Trigger will register almost immediately (because the same chopper wheel edge caused a ChangeDetectionEvent that's used as the start trigger) and Ctr0 will begin its job of pulse generation.  In addition to the high time and low time you've wired, it's also crucial that you understand how the 'initial delay' value will be used for your particular device.  (It has varied over the years with different devices and driver versions.  Best to look it up then test & verify.)

Anyway, you're kinda setting up a race.  The time delay from the triggering edge until the chopper changes state again depends on the chopper speed.  Meanwhile, your pulse parameters control the delay from the triggering edge to the frame grab.  Further, I see that some of your pulse params depend on the estimated chopper speed while others depend on user input.  And the 'initial delay' parameter is left unwired so your code has no effect on it and you'll get some default behavior you'll need to investigate.

We're at 6+ months along since the original thread.  I think it's time to try some of the things you've been resisting such as removing Ctr1 and DO, at least temporarily.  You have a system with a lot of complex timing interactions and dependencies.  Let's simplify the system, clearly define the timing goals for this reduced system, and make it work 100% of the time.

Reduce down to the ChangeDetect DI task and the ctr0 task you call "Digital Counter Task."  Then *clearly* define the timing relationship between chopper wheel edge and each edge of the ctr0 pulse.  (Example: rising edge should occur at 5% of the chopper wheel's previously measured high pulse width.  Falling edge must occur between 0.1 and 1.0 msec later.)   Spend some time here researching "initial delay" for pulse generation, particularly on triggered and retriggered tasks.

Also, please try the thing I suggested in msg #8.   Use extremely short times <= 1 microsec for all 3 pulse params on ctr0 (high time, low time, initial delay).  Capture the chopper wheel signal and the ctr0 output on a scope or similar.   Trigger on the ctr0 signal.  Is the first pulse always occuring while the chopper is in the expected state (high for a rising edge Arm.Start trigger)?

-Kevin P