Triggering two functions: AI read and CITime, when reading from the same source (USB-6351)

[did.rider38]

Hello,

I want to read and determine the delays between each pulse of a waveform from an external source.

To do this, in my VI, I measure the time/delay between each pulse and, at the same time, the voltage value of the signal. This is so that I can reconstruct the signal.

To do this, I used the “CITime” function to determine the high and low times of each pulse, and at the same time, I used the analog reading of the signal to obtain the voltage value. I created the VI attached to the email.

It does not quite meet my needs. The reading of these two pieces of information is not triggered at the same time.

Despite setting the “task start” function for reading the times (CITime) after triggering the voltage reading, so that both tasks start on the same trigger signal, which is located on the voltage reading task, the two tasks are not triggered at the same time.

I noticed that the CITime function starts as soon as the VI starts, while the AI reading is triggered on demand. So I tried to add a trigger to start the CITime function, but it does not accept the addition of this function. CITime is a function integrated into DAQmx in the virtual task creation function.

Do you have a solution? As a reminder, I am looking to trigger two different information readings, one from the analog reading of the AI, and the other from the time between each pulse from a counter, from an external source. The goal is to reconstruct the recovered signal in order to analyze it.

If you have any ideas or explanations, I would love to hear your thoughts.

And I use USB-6351 Card

Did.rider38

[ZYOng]

What's the signal frequency and duty cycle? What's the minimum pulse?

How about just acquire the analog signal and extract the pulse width using Transition Measurements VI?

[did.rider38]

My signal is form pulse like this , cf picture

 

I will see this fonction : "Transition Measurements VI". It's seem complicate to use it. But I try because I whould like too control the trigger of measure when I whant
I will take a return about it

[Kevin_Price · Accepted solution]

For reasons that remain a mystery to me, NI's counters cannot use a "regular" start trigger for *input* (measurement) tasks, only for output (generation) tasks.   Instead, you must configure what's known as an "Arm Start" trigger using a DAQmx Trigger property node.  I don't have LV here to illustrate, but a little searching here should find you enough of a road map to try it.

I don't know why they didn't just abstract this away by *actually* configuring an Arm Start trigger for input tasks when the programmer calls the "regular" start trigger config function. (See notes for the curious below.)

-Kevin P

Notes for the curious:

1. Here's a scenario that I've seen to catch people off guard where an Arm Start trigger can help.  Suppose you have an encoder position measurement task where you "borrow" the sample clock from an AI task that gets triggered at some unknown time after starting.

    Without an Arm Start trigger, the encoder task will start tracking position without sampling it from the time you start the task until the time the AI task gets triggered and starts generating the sample clock needed for sampling.  So the very first sample will be some variable position, depending on how much motion happened before the AI task got started.

   But if you configure the encoder task with an Arm Start trigger that watches the same signal as AI, then position tracking won't start until the trigger asserts, giving you the more expected 0 starting point.

2. An "Arm Start" trigger is subtly distinct from a regular start trigger.  In certain circumstances, an output task can make good use of both at once.  That might often be a case of generating a retriggerable pulse or pulse train in response to an always-present external trigger.  As an example, let's consider an encoder on an already-running engine shaft. 

    The task would configure the encoder signal to be a regular start trigger.  But it could then *also* configure some other one-time-only signal as an Arm Start trigger.  Thus when the task is started, it'd get all prepared to start doing it's retriggering behavior EXCEPT that it would then ALSO have to first wait for the Arm Start trigger signal to assert to fully arm the task one time only, thus enabling it to start responding to regular triggers. 

[did.rider38]

Hi Mr Kevin,

Thank you for these explanations. Arm Start Trigger is not explained very well on the NI website. This does not encourage its use.
I have taken your note 1 into account as it makes more sense to me. I will study the second one, which seems more complex, for the next step.

By applying the Arm Start Trigger function to the counter task, something I didn't have before (see attached image), I can trigger the period measurement from an independent external signal. Wonderful!
Thank you, it works!

I will now test it with the second part of the VI, with parallel measurement of the analogue channel.

I have another question that comes to mind. Is it possible, I have tried but haven't found a way, to add a condition to the trigger? That is, I would now like the counter task to be triggered when the signal changes state but also at a certain level. For example, at 4V, the task is triggered.

Kind regards

[Hugo_Hauet · Accepted solution]

Hello did.rider38,

To answer your question, yes it is possible to trigger a function from a condition using DAQmx functions. You can follow the next link and follow the “Developing Triggered Applications with LabVIEW and NI-DAQmx” part: NI-DAQmx Data Acquisition Triggering Techniques Using LabVIEW. There are several parts to explain and give you templates of LabVIEW codes to guide you as best as possible.

Have a good day,
Hugo

[did.rider38]

Thank you Hugo for your help.

I may have found a solution to another problem!!!

Here is the solution I chose for my request. I attached the VI to the message.

It uses the special CI Period function to measure the periods of the input signal. It is triggered using the ArmTrigger Digital function. As I want to link a voltage level to this trigger, I use the analogue channel and its AFPI0 trigger function in parallel to ‘play’ with the level. This part is important because the ‘real’ input signal would theoretically be noisy. Here I am working with a reconstructed signal.

Reading Hugo's suggestions, there is another solution using hysteresis triggers. Something to keep in mind!

Thank you all for your help!

Have a nice day.

Best regards,