Timestamp for each TTL signal input

[limp]

Thanks for the useful tips.

My device is a USB DAQ device (NI USB-6221).

The signal never stops while I am taking the measurements and it is always connected to the timer gate input,

I see in my vi that the "Number of Samples Per Channel" in the "DAQmx Timing VI" is set to 1000. Shouldn't this be 1? Every time I try to change this to something other than 1000, the program runs, but I got the same error as before and the value goes back to 1000.

Another thing is that, although there are multiple "data fields" in the "Front Panel" window (there are 8 data fields) that should be filled in with different timing measurements, only the first field is updated and the rest of them remain empty.

Many thanks,

Ioannis

[John_P1]

Oh... I thought I linked the "Continuous" example, but if you're running the DAQ card in finite sample mode then you shouldn't call the read after the task has completed or you'll get the same timeout error.  Try something like this:

I don't think the progress bar is going to work very well on the USB device, but other than that it should work while avoiding timeouts and giving you the option to abort the acquisition mid-run if you need to.

Best Regards,

[limp]

Thank you very much John.

Yes, you are right that you linked the "Continuous" example, but I mistakenly thought that by just changing the sampling mode in the "DAQmx Timing.vi" to finite and by setting a fixed no. of samples I will turn it to a "finite" version.

Anyway, the version you attached seems to work much better, without throwing any errors.

As you correctly guessed, the progress bar doesn’t seem to work that well (especially, as you decrease the number of samples). A couple of issues is that the data label is not being updated and that the execution of the program does not stop after all the required samples are acquired.

I am wondering if all these bells and whistles of LabView (e.g. progress bar, updating values, etc.) have any impact in the acquisition. Is it possible to somehow disable all these live updates? As far as I am concerned, I don't really care seeing anything until the acquisition is over.

Do you think that this could be done easier in Matlab? Is this even possible?

Finally, how can I see the acquired data and export them into a file, so that I can process them with Matlab?

Kind regards,

Ioannis

[John_P1]

Data wouldn't be updated until the end of the acquisition.  If you're just seeing 0s though, it's probably the formatting of the indicator on the front panel--you'll want "%0.8f" to show the full 10 ns resolution (sorry, I forgot to adjust it).

I'm surprised that the program doesn't stop after all of the samples are acquired--it does so when I tested it on my PCIe device.

The progress bar is a simple calculation, but even if you were using 100% CPU the measurement wouldn't be affected since it is clocked completely in hardware.

The most efficient way to write to a file is to use DAQmx Configure Logging.vi--it bypasses having to read the data into LabVIEW and streams to a binary (TDMS) file directly from the DAQmx driver.  So doing this would disable the live updates and then some:

I haven't personally used TDMS files in MATLAB, but I found a utility here that you might find helpful.

As far as programming the DAQ task itself in MATLAB--I don't have experience with this but you could look into the Data Acquisition Toolbox.  DAQmx also has an ANSI C API.

Best Regards,

[limp]

Thanks John,

I replicated the program showed on the figure you posted in your last post and I am glad to say that this seems to be working much better than the previous (no logging) version. Now the program stops when it has acquired all the samples. I am wondering what could be wrong in the last version, but anyway.

Just a few notes: At the end of the acquisition, the “task done?” Stop button gets pressed. I guess that this is the desired behaviour.

A thing that I don’t get is the purpose of putting the “Wait Until Next ms Multiple” VI. Could you please explain this?

Finally, the results that I am getting in the log file are indicating measurements of the signal period and not of its semi-period. For 10 samples, I got the following results (second column indicates the timing in ms):

Dev1/ctr0
0.018115588	18.1155875
4.8375E-06	0.0048375
0.099987763	99.9877625
4.2125E-06	0.0042125
0.099988388	99.9883875
4.6875E-06	0.0046875
0.099987913	99.9879125
0.000004675	0.004675
0.099987925	99.987925
4.6125E-06	0.0046125

Regarding the Matlab implementation, thanks for the example reading TDMS files. I have already managed to read TDMS files on Matlab, but I haven’t managed to design the DAQ program in there yet.

Many thanks,

Ioannis

P.S. How do you include these nice vi screenshots?

[John_P1]

Yeah, the idea was to stop the acquisition code once you have acquired the number of samples you had asked for.

To detect the end of the acquisition, the code is just polling to see if the task is done.  The wait function is to keep the polling loop from consuming unnecessary CPU cycles (i.e. there's no point in polling it as quickly as possible).

Regarding the results, I'm not sure what your signal looks like.  You'll have to provide a scope capture to convince me that the semi-period task isn't behaving as it should.

The screenshots are VI Snippets, which can actually be dragged into LabVIEW to generate code (though not directly from your browser without the use of plugins, save the image to your local computer first).

Best Regards,

[limp]

Thanks John,

I see, I couldn't see how the wait function is related to the polling loop. So, if we don't put it, the program pools the task status as fast as it can? I wonder why such a functionality cannot be done in an event-triggered manner.

Now, regarding the results. The testing signal is a square wave signal of a 100 ms period with a semi-period of 50 ms. So, it looks like this:

I don't quite remember the appplitude of the signal, but is should be somehwere between 3 and 6 V (most likely 5 V).

Unfortunately, I can't include a scope capture to convince you at the moment, but I will do so on Monday.

Something else that concerned me about the last version of the program you posted is that you don't specify the counter timebase anywhere. The "semi-period" example that you directed me to a few posts ago specifies the Maximum and Minimum Values of the signal period in order to select the best internal timebase possible. How is the timebase selected in your program?

Is there any possibility that my device is not capable of measuring the semi-period using the counter (i.e. could this be a missing functionality)?

I also tried to achieve the same functionality by using the DAQ assist, but I couldn't really make it work ;( Could you please make a small example for measuring the semi-period using the DAQ assist so that I can test this as well? Sorry if I am asking too much here (I really tried to make it work by myself, but I don't really know how to create all the necessary input signals for the DAQ assist vi). 

Please let me know if I can test anything else so that we can make this work.

Really appreciate all your effort.

Many thanks,

Ioannis

[John_P1]

It can certainly be done with events (use DAQmx Regiser For Events)--I was just trying to keep it simple since it sounded like you are pretty new to LabVIEW.

Are you sure you have the task configured as "CI Semi Period" instead of "CI Period"?  It's either that or the DAQ card isn't seeing the signal you think it is.  A logic low is below 0.8V, a logic high is above 2.2V (i.e. the transition between low and high is somewhere between 0.8V and 2.2V).

Maximum and Minimum are used to pick a timebase--if left unwired they default to 100m and 1u respectively.  As long as the maximum picked is less than ~53.69 seconds then the 80 MHz timebase will be used as the default.  I have gotten in the habit of leaving these inputs unwired and if I need a specific timebase other than the fastest one I specify it directly using the DAQmx Timing Property Node.

There is essentially zero possibility that your device is missing the semi-period functionality.

Best Regards,

[B._Beeman]

Hello john,

I'm tring to time stamp events which may be only 50ns apart but I would like 5ns resolution, total aqusition time would <2us. I came across an old conversation regarding using a NI cDAQ-9174 Chassis with a NI-9402 which is very close to what I hope to achieve, though I'd like to run a bit faster.

You mention 80Mhz capability of the 9174 but the 9402 claims 20Mhz, can you really timestamp with 12.5ns resolution with this setup?

In the years since this thread, has new hardware been released which run closer to 5ns resolution?

Thanks

Bart

[John_P1]

The 9402 would be used to route the external signal to the backplane counters, but the 80 MHz backplane clock can be connected directly to the counters and so isn't limited by the max switching frequency of the I/O lines on the 9402.  So indeed, this setup would give you 12.5 ns of timing resolution.

Anything in the X Series family (get the cheapest one in the desired form-factor if you don't need any analog features, e.g. PCIe-6320) uses a 100 MHz internal timebase, so that would get you slightly closer.  However, you have to be careful with the minimum pulse width spec on the PFI lines.  Based on the specs, the input pulses should be at least 20 ns long in order to be detected (this is not explicitly specified unfortunately, but derived from the 25 MHz "external base clock frequency" spec @ 50% duty cycle).  In practice you can probably go a bit lower (e.g. here is a KB that indicates M Series requies 12 ns pulses, I couldn't find an equivalent for X Series though but from experience they should be similar...).

The PCIe-6612 is a newer counter-only board that is similar to X Series (same 100 MHz timebase as well).  I haven't actually experimented with one yet, but based on the spec (specified in a more straightforward manner thankfully) you don't get any extra bandwidth unless you use the pre-scaling feature (pre-scaling ruins the whole idea of timestamping individual events however).

If your events are very short (significantly below 20 ns), you might want to look into the older PCI-6602.  While it only has an 80 MHz timebase, the input PFI lines have much higher bandwidth than the more recent DAQ products (should accept pulses as low as ~6 ns, though with signals that short it depends on how you are driving the line and how the signal is connected to the 6602).

In short, there isn't anything in the DAQ family of products with a timebase faster than 100 MHz.  Nothing in the DAQ family with a 100 MHz timebase can accept external signals as short as the 6602 though (which uses an 80 MHz timebase).  

By front-end bandwidth:

X Series  < cDAQ with 9402 < 6602

By timebase resolution:

cDAQ with 9402 = 6602 < X Series

If money were no object and you strictly need 5 ns timing resolution, you could potentially use one of the NI-HSDIO or Flex-RIO products to sample the line(s) at 200 Mhz (or more) and buffer the data to determine the relative timestamp of each event.

Best Regards,