turn on a case structure with rising edge trigger

[Kevin_Price]

---

@g_bress wrote:

Something I should have mentioned earlier is that I need to find my rising edge with sub-ms precision, as in since the rising edge is found I need to set the input value of the case structure selctor to "true" as fast as possible to record data at 1 kHz, without missing the first events!

---

Umm, yeah, you definitely should have mentioned that earlier.    What's the actual "big picture" here?  For example -- when you want to record data at 1 kHz, you definitely shouldn't be doing it 1 point at a time.

I have a suspicion that once we understand the overall system better, there's going to be a much better approach than the one you've taken and are trying to optimize.

-Kevin P

[mcduff]

What DAQ are you using? If supported you can do a change detection event on a digital line.

[g_bress]

Dear Kevin, 

what I am trying to do is to synchronise two devices operating at 1 kHz, hardware synced to the same master clock. "device 1" is streaming data at 1 kHz and produces the gate pulse (5.5 V, >30 ms) I was mentioning earlier when such streaming starts. the rising edge of this gate is what I wanted to use to start data acquisition with "device 2", by putting the vi that runs the acquisition inside a case structure whose switch is connected to the rising edge detector. the voltage acquisition channel sampling the gate pulse uses the rising edge of the 1kHz master clock as a start trigger.

My idea, which is apparently not working, was to read, at 100 kHz, 50 samples from the gate input channel, so that every 0.5 ms I am checking if streaming of "device 1" has started, and if so, I start the acquisition in "dev 2" by running the subvi contained in the case structure. I am not sure if, best case scenario, this approach will make "device 2" lose the 1st shot.

The NI devices I am using are PCI-6221 connected to a BNC-2110. 

[mcduff]

I suggest you look at Kevin's old posts as he is an expert in this field.

---

@g_bress wrote:

Dear Kevin, 

what I am trying to do is to synchronise two devices operating at 1 kHz, hardware synced to the same master clock. "device 1" is streaming data at 1 kHz and produces the gate pulse (5.5 V, >30 ms) I was mentioning earlier when such streaming starts. the rising edge of this gate is what I wanted to use to start data acquisition with "device 2", by putting the vi that runs the acquisition inside a case structure whose switch is connected to the rising edge detector. the voltage acquisition channel sampling the gate pulse uses the rising edge of the 1kHz master clock as a start trigger.

You can use the gate pulse in a counter task and use the output as a sample clock for the data acquisition part, if I am understanding your requirements correctly. Google Kevin Price, counter task, data acquisition, and you will find many of the solutions he has posted over the years.

[Kevin_Price]

Whenever possible, you should sync your devices via hardware signals rather than putting a layer of software between them.

Your scheme isn't clear to me.  From what I can gather, it sounds like you should just use the gate pulse directly as a hardware start trigger for the 2nd acquisition.   Let the hardware do the work!  That's both easier and more effective than the mucking about with software-based decisions. 

Note that you may need to use a simple voltage divider to bring it down from 5.5V to normal 5.0V logic levels. 

-Kevin P

[g_bress]

I get your point, you suggest to configure one of my DAQ channels as a counter output, set the number of rising edges and its frequency to match the frequency and number of acquisitions I need for my detectors and use as a start trigger for the counter output the rising edge of the gate pulse. although, this might cause two problems with my setup: 

1) measuring a whole set of data requires me to collect 1080 datapoints i.e. it takes 1080 ms, while the aforementioned gate pulse, after the first rising edge, switches to low and high again (within 1 ms) every 36 ms. Will the counter ignore all the rising edges after the first one or will it "restart" every 36 ms?

2) and this is my main issue at the moment and the reason why I was trying to implement a software controlled solution, if the subvi taking care of the detectors acquisition is run before a trigger is provided to the detectors it makes LabVIEW freeze and then crash and apparently there's no way to set it up in such a way that once it is run it waits in an idle state until the triggers begin.

That is way I came up with the idea of providing a constant trigger to the detectors and only running the acquisition subvi according to the state of the gate pulse...

[mcduff]

This is Kevin's territory, can't really help much here.

Another question - When the gate goes high is that when you want to take a sample or "stream" of samples? (One point or multiple points?) I understand you want to take data when the gate goes high, but do you need a single data point or a stream for the next 36ms?

Disclaimer - No idea how well this would work.

For a single point at each low-high transition, you could set the sample clock in the DAQmx Timing node to a PFI input on your card, set active edge to rising. Put your gate signal in the PFI input and use that as a sample clock to get a single point every low-high transition.

Probably best to see what Kevin says.

[Kevin_Price]

Please do us a favor and describe *all* the signals and timing requirements *thoroughly* and with lots of detail.   I for one tend to avoid or bounce out of threads when I feel like it's taking more effort for me to extract needed information than the questioner is spending to provide greater clarity.

Thus far, odds seem pretty high that I can help (probably others too), once you make your system, signals, requirements, and constraints more clear.  Posting code for your data acq tasks would surely also help, as the freezing and crashing is *not* inevitable.

-Kevin P

[g_bress]

ok sorry, thought it was clear. My system is constitued of:

-an optical modulator (I was previously referring to it as device 1)

-a CCD camera (I was previously referring to it as device 2)

-a master trigger at 1 kHz

The optical modulator, at each rising edge of the master trigger (1kHz), plays a waveform in a crystal through which the light is transmitted. It is configured in such a way that it streams a train of 1080 different waveforms. This train of waveforms is referred to as "sequence". Each "sequence" is split into a number of portions of the whole sequence, each portion is called a "pattern". the number of waveforms each "pattern" can contain is hardware limited. In my system, each "pattern" contains 36 waveforms. The aforementioned gate signal corresponds to each of these patterns being played, that is the reason why the gate stays high for 36 ms. As I previously mentioned, for every "sequence" the gate channel sees 1080/36=30 rising edges. The optical modulator does not have a readily available "sequence gate" TTL output in case you were wondering. 

DzNetRem_Example_2DSpectroscopy_connections.vi controls the modulator operations: it computes the waveforms first and then starts to play the first "pattern" of the "sequence", and goes through all of them until the last waveform contained in the last pattern. due to the computations and upload times there is a >1000 ms (jittering) delay between the .vi being run and the streaming of the first pattern starting (i.e. between DzNetRem_Example_2DSpectroscopy_connections.vi being run and the first "pattern gate" rising edge). The whole execution time of this .vi will then be t_{comp+upl}+t_{streaming}.

t_{comp+upl} jitters but it is always greater than 1 second while t_{streaming} is always equal to 1080 ms.

The CCD is externally triggered and is configured to acquire 1080 spectra in total (a spectrum for each waveform played by the optical modulator), each rising edge of the external trigger signal causes a spectrum acquisition by the CCD. Apparently, if readfFFloop.vi which takes care of acquiring a  burst of 1080 shots from the CCD, is run when the camera is not receiving a trigger signal it freezes/crashes labview, and this is what is causing me problems...

As you can see from the attached code, I tried to get around this issue by using two timed sequences with a delay between them to make sure the modulator .vi runs before the burst acquisition vi, triggering the cameras with the master 1kHz trigger and "turning on" the acquisition of a burst of 1080 spectra with the rising edge of the gate signal from the optical modulator. this idea it did not work. 

Hope this explanation is understandable... 

vis and subvis attached (they won't run anyway as they need to be connected to the hw in order to run/ need huge library files)

thanks a lot for helping

giovanni 

[mcduff]

I am getting ready for travel, so just some quick observations:

1. You will need to learn Basic DAQmx functions to do what you want; the DAQ assistant won't cut it.
2. Timed Structures really only belong in Real Time Applications; on a Windows system they can cause more problems than they solve.
3. If you are reading samples from a DAQ device, its sampling rate, number of samples, etc, controls the timing of the loop. Once again no need for a timed structure.
4. This is my Pet Peeve, won't make a significant difference. Check if your DLL for the camera is thread safe, if so configure it to run in any thread. LabVIEW excels at parallelization, no need to stymie it.

The learning materials at the top of the discussion forums are a good reference if you have access to them.