turn on a case structure with rising edge trigger

[Kevin_Price]

That was very helpful!  However, I still have a few more questions.

1. Re: the 1000 Hz master trigger.   Where is it coming from?   Is it a continuous 1000 Hz digital pulse train?   If not, what makes it start and stop?   

2. Can it work for *you* to create and control the 1000 Hz master trigger signal with one of your NI 6221 data acq boards?

3. Re: the optical modulator.  You say it will play a waveform for each rising edge of the master trigger but does not have a "sequence gate" TTL output.  Apparently you must preload your sequence of patterns to it.  You also mention a delay caused by computing and delivering those waveforms before they start "playing".   

   What causes them to start?  Is it some kind of command from you to its driver?  Or does it just auto-start as soon as it receives all the patterns it expects?  Or something else?

4. You made reference again to a "pattern gate" rising edge?   Who generates this signal?   Does it occur once per "pattern" of 36 waveforms?  Is it a short duration pulse?  How do its edges line up with those from the "master trigger"?

5. Re: the CCD.  You say it's externally triggered.  By the 1000 Hz master trigger signal?

6. I thought the freezes and crashes were avoidable b/c I thought your device 1 & 2 referred to PCI-6221 boards.  But since it has to do with some 3rd party dll with cryptic-to-me function arguments, I have no good ideas to offer.

Overall, I think you'd be well-served to try to put yourself in *control* of the shared 1000 Hz master trigger signal and perhaps also some version of your "pattern gate" pulse.   It may turn out that you only have to prep both your modulator and CCD imager first and only then start generating your 1000 Hz master trigger for 1080 cycles. 

I've done a lot of things related to syncing NI DAQ tasks, but only a little of it has relevance to your situation where you need to sync 3rd party products with interfaces I know almost nothing about.  It'll take detailed knowledge of the hardware and its interfaces (including the software driver) to make this all happen.

I'm still inclined to think that all the timing coordination needs to happen in hardware somehow and that attempts to do it in software aren't going to get you there.  Not if you need reliable sub-msec software reaction times.

-Kevin P

[g_bress]

1) the "master trigger" is the repetition rate of a laser which is driving the whole experiment, so it is always on when the laser is on i.e. when the  experiment is running.

2) no, as the whole thing has to be synced with the laser pulses

3) once the .vi taking care of the streaming operations is running the streaming will automatically start once the first waveforms are uploaded onto the FIFO of the modulator.

4) the pattern gate signal is generated by the optical modulator and it stays high for the pattern playing time, and it rising edges should match the rising edges of the master trigger as the modulator itself is triggered by the laser.

5) I tried to trigger the CCD by using both the master trigger (in which case the software runs fine but of course the detection is not synced to the optical modulator streaming) or by a gated square wave obtained as the result of a AND between the master trigger and the pattern gate pulses, and delaying the CCD vi start with respect to the modulator vi start using a time delay constant plugget to one of the timed structures. In this way the software crashes because the CCD vi is run "too early" so there is no trigger coming yet, or "too late", so that the triggers stop before all the 1080 spectra are acquired.

6) you are correct, the freezing is caused by the third party CCD vis/library

[Kevin_Price]

Something like your AND gate is probably the right hardware approach to take.  Then the problem boils down to the CCD and its interface, including the driver dll's and suchlike.

That's where (IMO) you really need to dive in to understand its modes of operation and how to engage with them.  You *don't* want to rely on software timing delay guesses, you want the hardware signals in charge of timing.

Can the CCD capture and store the 1080 "responses" for you to come in and retrieve them all in a batch at the end?  If so, you just need a way for your program to know when to ask for them.  That could just be a data acq task that uses the AND output as a sample clock, which you query for the # samples available until there are 1080.  Then read and discard them, followed by retrieving your CCD data.

Another thing that you *might* want: use a 3-input AND where you can control one of the inputs with a DO line.  That gives you more control over when you do or don't let those pulses through to the CCD.

-Kevin P