Using DAQ to trigger non-DAQ event.

[js777]

Hi everyone: 

I am trying to use the counter in my DAQ device to trigger a non-DAQ event.
What I am currently doing is to link the counter to one of the digital input(DI) on the hardware, and then link the DI signal to a case structure, which contains my non-DAQ event.
In this case, I can trigger my event by the counter through a DI, rather than directly trigger

(the attahced picture is what I am doing now)

Is there any more direct method?
(The triggering VI for DAQ can only be used for DAQ event).

Many thanks, js777.

[Norbert_B]

What is the device you are using?

If it provides "Change Detection Event", code like this should do the trick:

Norbert

[js777]

Many thanks for the reply.

But it looks like using the counter input here to take the signal, so I still need to link a counter output to this counter input.

In this case, it is very similar to using digital input as I did (I use ) boolean checker and the case structure ( you use event structure.)

Are them different?


I was trying to use the change detection on the counter output, (link the change detection after the start of the counter ouput)
but it doesn't work.

Any idea?

Many thanks, js777

[Norbert_B]

Why do you use counter OUTPUT for such an event?

Depending on the hardware, change detection works on Digital Input (DI).

For counter output, this doesnt make much sense as

a) The counter either creates a single pulse which is most likely software timed
 or

b) is continuous with a specific rate (which is likely faster than the software can execute).

Norbert

[js777]

Hi

I think I'd better explain my whole application.

I have a AO signal, non-DAQ event, and one TTL signals to generate.
(my TTL is just a digital signal, I can use DO as well, but just the counter is simpler to set up.)
They all need to be syncronized.

What I come up is: (btw I am using USB-6341)
I use the counter to generate the TTL signal (I thought the counter is timed on hardware, rather than softeware, no?), and then use its clock as the reference to AO signal.
To deal with the non-DAQ event, I use a DI to receive the signal from the counter (I parallel connect the signal), once the signal is on, the case structure is triggered, so is my non-DAQ event.

If the counter is timed on software, and not suitable here, what is your suggestion for this application?
(There are many syncronization examples, but I dont see one for the none-DAQ event.
And actually, in some example, the syncronization between one AO and one DO is achieved by a counter, and that is also why I think it should work, and it does work at this moment)

So my issue is back again, except the way I mentioned at the very begining, is there any better way to trigger a none-DAQ event.
(The last example you suggest seems just the same as I said, isnt it?)

Many thanks
Regards, js777

[Sincrono]

Answer to that would help me too. In my case, I came to the same idea of "unifying" the counter output with input. I think you can only read from counter inputs, so, making that the same hardware-timed component acts as output and input would be great. 

Apart from that, my problem is that it seems that USB-6215 doesn't support the C function RegisterSignalEvent with "edge detection", which enables a hardware event (such as input digital change) to trigger, as js777 says, a non-DAQ event.

How should I know which cards support that, excluding trial-and-error via simulated devices?

[Norbert_B]

Hm, i see some contradicting information here.

To clear things up:

1. The DAQ device owns an oscillator which is clocking the device. If using finite or continuous IO and selecting a clock source, you will select a hardware clock (internal most often). Defining the sample rate will devide the oscillator frequency to the closest available frequency for the task.

2. Synchronizing tasks by using reference/"forwarded" clocks makes sure that concurrent running tasks are not drifting. "Forwarded" clock means that you export the sample clock from one task to the other, which is common for synchronizing AI and AO.

3. "Edge detection" is commonly a feature of digital input. Counter Input already has "change detection", but that is not directly forwarded to the driver for export to the calling software. Counter can use the external change event for clocking though. If a device is capable of "edge detection" should be stated in the manual or spec document.

4. Depending on the rate of events, your complete system might be hogged by that until being completly unresponsive. In my experience, these events can be handled up to something like 1kHz properly, faster is questionable and very system dependend.

5. The term "non-DAQ event" is used very...inconsistently in this thread. I assume that you refer to it as "event captured in software where the source of the event is a DAQ hardware. The event registration node is exactly what you are looking for in this case. As you can see when playing around with it: There is only a limit amount of sources selectable. If the source you are looking for is not available, your only option is to poll the DAQ device continuously for the "trgger event" and either generate a user event or directly execute the code (like you have already done with your example in this thread).

hope this helps,

Norbert

[js777]

Hi Norbert:
Thank for the reply.

May I confirm if I understand it correctly?
so basically, the solution is to use the counter (or a DI) to take the pulse signal (from a counter output or a DO) with the edge detection.

This looks like what I was doing at the very begining : DI to take the signal from a counter, and use the boolean event, rather than the edge detection to trigger.
I think these two approaches are pretty similar, although I am not sure if the boolean event has any disadvantge, or the edge detection is simply faster?

--

So here is another question,.
As you can notice, the counter output is linked to a counter input (or a DI), so basically the signal is just passed from the hardware to another port of the same hardware.
I was wondering if the edge detection can be moved to the "coutner output" directly, to avoid physically passing the signal, which looks redundant.

Many thanks
js777

[Norbert_B]

js777,

really, what you are doing makes no sense. Instead of having an external signal to "occur randomly" and trigger some (short) algorithm whenever it occurs, you try to "clock" your software by using a static, hardware timed DAQ device.

This adds enormous overhead to your application, hogging the complete system in the worst case.

So, please simply add a waiting time in your loop instead of using DAQ for this at all. As you probably don't know: the time to wait is fed into the "wait" function each iteration. So iteration waiting times can differ.....

Hint: "Clock" describes a periodically repeating signal with, in most situations, has a static frequency.

Hint 2: As you create your "clock" (CO), you know the desired frequency. So no "magic" here to compute equivalent wait times.

Norbert

[js777]

Hi Norbert:

Actually, I am confused about what you said.

1.
the "clock" I was talking about is the hardware thing. something like the crystal oscillator used as the "timer" o hardware.
and I found this timer is different for my AO and counter on USB-6211. Although, I dont know the exact hardware details.
That is why I think the AO and counter might have different hardware timer (something like crystal oscillator), which I called clock before.

2.
The signal is produced from the same DAQ device (counter 1), why it "occur randomly"?
I thought once I define the counter, it generates the signal at the static frequency I want.

3.
As for "trigger some short algorithm", I think you mean the event I want to trigger.
It is a DLL library controlling my another device.
That device doesnt support a close loop for me to syncronize, so I need to use a open loop here.
So yes, it is software controlled.
And yes, you are right that there might a be short time between the calling of this DLL library and the actual running of the device.
But after testing, this latency is quite stable, so I can compensate that by tuning the signal (from the counter) phase.
Therefore, this part is fine.

4.
When you say "add a waiting time in my loop" to syncronize.
I think you probably didnt get my difficulty. I can explain again here.

I have a AO signal (continucal) and the DLL linrary event (which I called non-DAQ event in previous replies) to syncronize.
The AO signal keeps running, and my DLL library needs to be triggered periodically accodring to this AO signal.
Adding a waiting time means to use the software pause time for the syncronization, and this wont be accurate.
So what I was doing, is to find a periodic digital siganl (like what the counter generates) as a reference.
The AO is clocked with that counter. (referred to the counter's clock by calling the "DAQ timing")
And then I use the digital signal to trigger my DLL library. By doing this, they can be syncronized well.
And that is also why I link the counter back to one of the DI (to link back to computer and then trigger my DLL library.)

What I was asking is euql to:
when I set up the counter output, is there any edge (maybe like any inner feedback signal from that counter) I can detect, so that I dont need to link to the DI, which looks redundant.

5.
It is intuitive to think the syncronization should be done directly from the DAQ and my another device.
But the thing is, it doesnt support TTL control, but communicate with pc through USB only.
So that is why I syncronize them like this, which might look redundant, but I dont know if there is other method.

Many thanks
Jhensi