For Loop timing

[majoris]

Just to cover all our bases: what device are you using? For the record, when I mock up the code with my own device (6361), I can externally trigger no problem though I don't stream to file. It does seem that it doesn't care if retriggerable is wired correctly or not (by default, the task has retriggerable to false, but it behaves as retriggerable anyways).

Also what version of Labview and DAQmx.

[Zakhar]

I am using 6361. LabVIEW and DAQmx ver.17.

Thanks.

[majoris]

So I have exactly your setup (software and hardware). However, I tied a DO line to a PFI line and was able to trigger it by manually turning the DO on and off with a button. What do your timestamps look like? How much are they off by? I'll try it out with the TDMS logging function and a counter and see how it works.

[Zakhar]

1:19:35.712

1:19:35.867

1:19:36.084

1:19:36.258

1:19:36.461

1:19:36.682

1:19:36.864

1:19:37.110

1:19:37.360

I.e. 155 ms; 217 ms; 174 ms; 203 ms; 221 ms; 182 ms; 246 ms; 250 ms

Again triggering is at 100 Hz (10 ms). I don't think writing 9000 points to tdms is a problem. Most likely the issue is related to when the program starts writing to tdms file.

Thanks.

[majoris]

How do you get these numbers? Maybe I am overlooking something, but your log file should have an initial time and a dt. From there, it should be hard to reconstruct the time between acquisitions the way you have. I think typically you have to save the timestamps for each data point in a separate channel. You can do this by using the t0 and dt to make an array of timestamps and saving those as well in another channel in the TDMS file.

For instance, see TDMS Write Help:

https://www.ni.com/docs/en-US/bundle/labview-api-ref/page/functions/tdms-write.html

Caution  When you write analog or digital waveforms to a new channel, LabVIEW includes the timestamp information in the waveforms. However, when you append analog or digital waveforms to an existing channel, LabVIEW might discard the timestamp information in the new waveforms.

So yeah, just be aware that storing all the data in one channel and hoping to preserve the time information might not work. I've been using the attached vi for reference.

[Zakhar]

I will need some time to digest your references. Thanks.

As for numbers, I have converted tdms to Excell. The header looks like this:

_unnamedTask<0> #1

Channel

Datatype

Unit

Length

Minimum

Maximum

Description

NI_ChannelName

NI_UnitDescription

wf_increment

wf_samples

wf_start_offset

wf_start_time

Dev4/ai0

DT_DOUBLE

Volts

9000

Dev4/ai0

Volts

1E-06

1

0

03/12/2018 01:19:35.712 PM

[celia97]

Hello,

I'm currently working on a program for my internship, and I think I have the same problem as you do.

I want to acquire a signal at f_acq=100kHz, with a trigger signal at f_trig=10Hz. Every 100ms, I want to acquire N=f_acq*t_m samples (t_m is the duration of the measurement). The problem is that if t_m>60 ms (ie the duty cyle is superior to 60% ), the cycle lasts 200ms instead of 100ms. I need a better duty cycle for my work.

The task is finite, I have the same acquisition set up as Zakhar. The only difference is that instead of a for loop, I have a while loop.

I tried the continuous mode, but it's not trigged properly. I tried changing properties of reading VI and triggering VI (using property node), but it didn't help.

It looks like the VI read waits around 30 ms before ending, though the "rest time" is 0.

If you have any idea to improve this duty cycle, it would help a lot!

[Bob_Schor]

Celia,

     This is Zakhar's Post -- you shouldn't "hijack" our efforts to help Zakhar by saying "I think I have the same problem as you".  You should either:

• Wait until a Solution has been found for Zakhar's problem, and see if that solution works for you;
• Send Zakhar a Private Message saying "I have the same problem as you -- please tell me what you found that worked";
• Or, best, start a new Message and clearly state what you want to do, what works, and what doesn't work.  When doing so, you should also post your code (no pictures of Block Diagrams, please, but the actual LabVIEW code, or a compressed Folder of your VIs attached as a .zip file).

Bob Schor

[celia97]

Bob_Schor,

Sorry I acted like a Labview terrorist, I'm not used to this forum.

I thought it could help to also solve Zakhar's problem, as it is the same timing problem.

Thank you for your help!

[Bob_Schor]

Celia,

     A LabVIEW Newbie (I was once a Newbie, too (and made more than my share of mistakes -- I still do, in fact)) is not the same thing as a LabVIEW Terrorist -- to become that, you need to be really obnoxious, and you seem much to gracious for that!

     You did provide one small piece of information, namely that the problem isn't "While vs For Loop".  Keep monitoring Zakhar's post -- if you don't see much progress, I'd suggest starting your own post, but for maximum effect, be sure to do the following:

• As clearly as possible, describe what you want the code to accomplish.  Don't worry about "how" to do it -- if we think there are better ways to do it, we'll suggest them.  But we do need to know such things as "What devices are involved", "What data rates and types of data are involved", and "What do you need to do with the data (i.e. "save to file", "plot on graph", "FFT", etc.).
• Attach your code!!  If you are using LabVIEW Project (which I hope you are), and have a Main VI and some sub-VIs in the Project, compress the folder containing the Project and its files and attach the resulting .ZIP file.  It wouldn't hurt in your Post to tell us which Version of LabVIEW and any special Tools you are using.

Bob Schor