Using USB NI-6363 for hardware re-triggerable analog trigger signal(APFI0)

[Hasham622x]

Dear all,

Firstly, I apologise for any inconvenience. I am using a USB NI-6363 Mass Termination device, and I aim to capture multiple data points (one sample/channel) from 16 AI channels per trigger. My trigger signal is set to 360 Hz with a falling edge, the AI channels are configured in "RSE" mode, and the sample clock is set to "Onboard clock" and finite sampling mode. I initially set the sampling rate to 48 KHz, but I noticed that the code was running faster than expected, indicating that the data collection is not functioning correctly. I then tried lowering the sampling rate to 20 KHz, but the issue persisted. Could you kindly guide me on what sampling rate I should set to obtain accurate data from the channels? I've attached my code LV19 version for your reference.

Kind regards

Hasham

[ZYOng]

How slow were you expecting?

You specified the number of samples to be 250. For the sampling rate of 48 kHz, only 250/48000 = 5.2 mSec of data will be acquired.

[Hasham622x]

Hi,

Thank you for your response. I am aiming to capture two samples per trigger; however, the process is running too quickly. Despite providing an external hardware trigger signal at 360 Hz with a falling edge, it should take one second to complete, as I have selected one sample per channel (a total of 16 AI channels) in the read.VI. Ideally, it should collect 360 points per channel within one second. Still, it is completed in approximately 0.77 seconds, suggesting that the data I am receiving is not accurate. Could you kindly advise on where I might be going wrong?

Kind regards

Hasham

[Hasham622x]

I tried to run at higher sampling frequency and got these errors...

[Kevin_Price]

One main thing you're "doing wrong" is defining the # finite samples to acquire to be 250 in your call to DAQmx Timing.  For each triggering event, the task will want to collect 250 samples before it will rearm to look for the next trigger.   Given your description, you should configure for 2 finite samples per trigger instead.

However, when you expect 360 triggers per sec that means you need your reading loop to execute in < 3 msec consistently.   Under Windows, you can't expect 100% success at this.  If execution gets delayed, I *think* you're going to miss out on retrieving that trigger event's worth of data.   The hardware retriggering will want to keep restarting the task and writing data into the beginning of the task buffer over and over regardless of whether your software has yet managed to read the data that was there from the prior trigger.   I can't test the behavior now, so it's possible DAQmx will throw a warning or error, but I'm not sure.

So even though your X-series device *can* do retriggered AI directly, there are still some possible advantages to the scheme I laid out previously for your M-series device.   (Revisit the whole thread for some followup corrections & further troubleshooting suggestions).

Meanwhile, I did some minimal mods in-place that you can try with your X-series 6363 device.  See attachment below.

-Kevin P

[Hasham622x]

Hi Kevin,

Thank you for your suggestions and support. You're right, it is confusing that the code finishes faster than expected, yet it's still giving 360 points for each channel even though it completes early. I am also receiving a warning message.

Could you please guide me on how to retrieve data from the "value" part mentioned in the code? When I connect write.VI, outside the loop on the value part, only saves data from two iterations. However, when I place write.VI inside the loop captures data from all iterations.

I tried using the counter approach for the M series, as you suggested, and changed the polarity of the digital trigger from falling to rising. However, I didn’t notice any difference in the captured data. The signal didn’t exhibit either rising or falling behavior. I'm seeing the same behavior on the channels regardless of the trigger polarity change.

I will be very thankful, kindly please guide me as I have to conclude these both devices quickly and get some actual data as my whole project is delayed due to it 

Kind regards

Hasham

[Kevin_Price]

I just posted a suggested mod, then you mentioned a few observations that might be referencing my code or might be referencing the different version of code in your screencap.  It's unclear to me.

Here's a very simple way to use the chart's "value" property at the end of the run to do a one-time write of your accumulated data.   (Note: using a chart's value property is not a recommended long-term method.  It's just a simple way to accumulate 2D data while troubleshooing the real DAQ related issue.  It helps that your total # samples 760 is smaller than a chart's default History Length of 1024.

As to the 2nd half of the message, I have no real idea how to interpret your data.  I don't know your system or what to expect.  Have you tried the troubleshooting steps I suggested over in the linked thread?

-Kevin P

[Hasham622x]

Hi,

I apologise for the delayed response, and thank you for your previous guidance.

I am currently using the NI-6363 BNC and screw terminal with a retriggerable approach to capture points from a multichannel analog input (AI). However, I have encountered an issue while trying to run my code at the maximum sampling frequency (500 kHz for 4 AI channels) in RSE mode with finite sample mode.

At the maximum sampling frequency, the system does not appear to follow the expected falling and rising behaviour when using the hardware retriggerable approach with a 100 Hz trigger signal. Additionally, I observe transient behaviour in the raw data, which raises concerns about whether my code is functioning correctly. It seems that these anomalies may be causing the transient data and preventing proper adherence to the falling and rising behaviour at high sampling frequencies.

I have attached the code for both the hardware trigger retriggerable approach and the counters approach. In both cases, I am observing the same type of data.

I would greatly appreciate it if you could review the issue and provide your guidance on resolving this problem.

Kind regards

Hasham

[Kevin_Price]

I might be able to dig in for a closer look later on today, but in the meantime, can you show an example or clearly describe what you think the data *should* look like instead?   And discuss *why* you have that expectation?

I don't know anything important about your system so it's pretty hard to interpret "anomalies" in the data when I don't know the difference between normal and abnormal data.

What would be really helpful is an untriggered capture of normal data.  Then draw in vertical lines to show the region that *should* get captured when triggering operates correctly.

-Kevin P