Using DAQ to trigger non-DAQ event.

[Norbert_B]

Jhensi,

try something like this. Software timed, but most likely solving your requirements.....

In the loop, call your DLL.

Norbert

 EDIT: You see, you do not need any DI nor "events". The only thing, which is also true about the event based approach my first screenshot showed, is that this is not suitable for frequencies getting close to 1kHz. A lower frequency (e.g. 10 Hz) is just doing fine. Getting faster than 1kHz requires an approach as my first screenshot but still it could be impossible to solve (depending on execution times of the DLL, background tasks, ....). If you require a frequency of more than 1kHz, you might have a chance using a real time system (if the DLL is compatible at all!). If this doesn't help, you would have to re-write the DLL and e.g. use an FPGA to solve the requirements.

[js777]

Hi Norbert:

Thank you for reply.

It looks like something might helpful, but I still have some problem on it.
In this example, the DLL is triggered every loop, which is software timed by a certain freq .
At the same time, the AO is running at a speed according to its crystal oscillator (or an equal component to be the hardware tick reference.)
So it seems to me that the AO and the DLL won't be running at the physcially same freq.
(I think it is likely that the crystal oscillator on the daq device is not exactly the same to the one on pc)

On the other hand,  in my very first method, the DI takes signals from the counter, and the AO's clock is refered to the counter's clock (on the same hardware).
So, both the AO and DLL are refered to the same crystal oscillator, and I think it should be more accurate.
(except the latency part, but if the latency is quite constant, which is what I get so far, this should be fine.)

If the "CO pulse freq" can send the trigger signal to the DLL by a case/event structure (without using a DI !), then it should be working, but I dont know how.

Many thanks
jhensi

[John_P1]

Have you tried something like this?

There is also a counter output event but it seems that the counter was just a means to clock the AO so why not just use the built-in AO sample clock?

I'm not sure how well signal events are implemented for USB DAQ devices (I remember some buggy behavior in earlier DAQmx versions anyway, and I know not all USB devices support signal events).  I don't have one to test out but I get no errors on a simulated USB-6341 (and the code does work on a PCIe X Series).

Best Regards,

[Sincrono]

While trying to start a task of Counter Input in continuous Change Detection mode (digital edges) with an arbitrary function "registered" to the hardware event (change detection), an error in Labwindows/CVI appears regarding timing.

After reading some documentation (NI-DAQmx Help->NI-DAQmx Device Considerations->Digital I/O->Sample Clock Timing), I got to what I think is a list of devices that can "interrupt" any system process to prioritize the operations contained in an arbitrary function.

Am I right?

[js777]

Hi John:

Thank you for the reply, I think this solution is closer to what I need. 
Here is some further problem.

Actually my AO is a finite pattern of signal, but runs continually.
The triggering rate to trigger the DLL should be the same as one round of AO pattern.
In your suggested structure, the trigger has the rate of sampling rate of the AO signal, which is too fast.

What I can do is to count the trigger times, and the actual trigger only occur when the count number reach a certain amount.
but it seems to be less direct, and might cause some unstable latency. (maybe it is not that serious, and worth trying, not sure)

Instead of doing that,
does a counter output support "change detection"?
If so, I can use the counter, pulse rate of which is defined according to AO, as the trigger.

Many thanks
jhensi

[John_P1]

The easiest way would be to just use the counter output event.  The counter can divide down the AO Sample clock by toggling every N Samples of the AO clock.  When it does this it will issue an event.

Best Regards,

[js777]

Hi John:

Thank you for this suggestion.

This likes like what I need, I will try it when I get my device back.

Many thanks
Regards, Jhensi

[Sincrono]

If this works to me, it would be great too. However, I don't use LABVIEW but Labwindows/CVI. Is there a way to transform those circuit diagrams into C code?. If not, can you provide me the .VI to try it exactly as it is. I would spend some great time just copying the blocks and arrows in the picture, but if you pass the running file I would learn faster how to work it around and verify if it works. It looks more elegant than the change detection way requiring an output physically linked with and input.

A few questions. What happens when counter reaches terminal count (N samples)? It has to be retriggered? 

Maybe finally I turn into LABVIEW

[John_P1]

The DAQmx C API has equivalent functions (mostly a 1:1 mapping), but there isn't any automated way to translate the LabVIEW code into C code.

The code posted previously is a VI snippet, if you save the image you can drag it into LabVIEW and the code should be generated.  I have attached the VI in LV 2011 to this post as well.

The counter reaching terminal count isn't a concern--this is actually how a counter output task works normally:

1. Starts with a count Initial Delay away from terminal count.
2. When it reaches terminal count, toggles state (high by default), generates an event usable by software, and resets to a count High Ticks away from terminal count.
3. When it reaches terminal count, toggles state (low by default), generates an event usable by software, and resets to a count Low Ticks away from terminal count.
   
   -Repeat between 2 and 3 until the task is stopped-

By default the output task will toggle the state of the output line every time TC is reached, but you can also change the output behavior to have it issue a short hardware pulse instead.  This isn't necessary if you're only using it for the software event though.

If Initial Delay, High Ticks, and Low Ticks are all equal then the counter will generate an output event every N ticks.  In this example the source of the ticks is the AO Sample Clock, so we now can generate an event every N Ticks of the AO sample clock.

I suppose if you want to generate the event every N ticks of the AO sample clock where N is 2^32 or greater then the rollover would be a concern, but I don't think this is what you were referring to.  At the max rate of the 6341 (900 kHz) the counter would take just shy of 80 minutes to roll over (and would take longer at lower AO sample rates).

Best Regards,

[js777]

Hi John:

I just modified to my system, and it can work well.

Just a remind to some other users, the event detection wont be supportive in some DAQ device.

For example, this can work for my USB-6341, but not my USB-6211.

To use USB-6211, I think I still need to use the DI as the signal detection (looks redundant, but practically working.)

Many thanks

Jhensi