Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

sync 2 period measurement tasks

Hi all,

 

I'm using the PCIe-6341 and Labview 2009.

I'm trying to sync 2 period measurement tasks in time. On older cards (e.g. 6608, pci-6251) the first data point was always the period between the beginning of the task and the first edge recorded. This data point is now removed automatically and one does not have access to it. What this means is that even if I arm trigger 2 counters at the same time the first data point will correspond to the first edge on the specific counter. This also means that the 2

counters are not synchronized.

 

I tried to manually perform period measurements via count edges task (vi attached). This way I do have access to the first data point but when I use 2 counters I get an error (image attached). My signals arrive at pretty random intervals and I think this results in the error.

 

Any suggestions on how to sync my period measurements tasks in time?

 

Thanks,

Eyal

Download All
0 Kudos
Message 1 of 20
(3,124 Views)

Howdy Eyal,

 

I think the reason you're getting the 201314 error is that you're receiving a sample clock before you're receiving a signal on your gate (input terminal). Unfortunately, there is no way (in hardware) to prevent this from happening. However, it may be possible to work around this by configuring a hardware arm start trigger on the same source as your input terminal.  Please let me know if this resolves the issue.

 

Regards,

Barron
Applications Engineering
National Instruments
0 Kudos
Message 2 of 20
(3,089 Views)

Hi Barron,

 

Thanks for the reply.

 

I tried to connect the input (in this case the sample clock source) to the arm trigger and I still get the error.

I tried every possible arm trigger (input signal, internal clock, external signal) and I still get the error. When my input signal is at lower rate I don't get the error but this is not practical for my actual experiments.

 

How difficult would it be to retrieve the first data point (in the period measurement task) that is now automatically removed? This would resolve all the problems I'm having.

 

Eyal

0 Kudos
Message 3 of 20
(3,076 Views)

It will not be possible to recover the first data point since it is thrown away by the hardware.  You are on the right track towards working around it.

 

How fast is the input signal that you are sending to the sample clock?  If it is too fast and a pulse does not occur on the counter input terminal then an overrun error will occur.

 

If your input signal going to the sample clock is slow enough but you are still getting errors then the problem may be caused by noise on the signal.  Please try using digital filtering on the sample clock input by implementing this property node:

PropertyNode.jpg

Regards,

Barron
Applications Engineering
National Instruments
0 Kudos
Message 4 of 20
(3,066 Views)

My input signal is random (at least 2 out of the 4 I'm going to use eventually). I get the error while trying 10KHz signal (same signal on both channels).

 

If I use the period measurement task I don't get any errors. What I'm doing should be similar to how the period measurement task works. The period measurement task records the signal without any noise so I don't think it's the problem. Anyway, the digital filtering does not work with this task -  it gives me an error. I typically check my signal before I record it to make sure that the edges don't ring.

 

It is a big problem that the first data point is thrown away by the hardware. It didn't use to be this way. Anyone who wants to use time tagging (i.e. getting the absolute arrival time of the signal) on more than one counter will have the same problem as I do. 

 

Thanks,

Eyal

0 Kudos
Message 5 of 20
(3,061 Views)

Hi Eyal,

 

I think you might be using the wrong instance of the Digital Filtering property node (there are several depending on which terminal you need to filter and which task type).  Try the attached code:

John Passiak
0 Kudos
Message 6 of 20
(3,053 Views)

OK. I double checked the quality of my signal and it is not as clean as I thought. 

 

I also tried the last code with the digital filter and now I get a different error (200774). Could it be because of the daqmx channel node?

 

Is there some hardware filtering with the period measurement task? Because I don't have an error when I use that. 

 

If noise is the problem, worse comes to worse I can use an external circuit to filter my signal.  

 

Thanks for the help,

Eyal

0 Kudos
Message 7 of 20
(3,044 Views)

Hi Eyal,

 

There is configurable internal filtering on TIO, M Series, and X Series DAQ Devices so you shouldn't necessarily need external filtering.  M and X Series boards implement filtering a bit differently--for more information on the 6341 I would refer to chapter 8 of the X Series User Manual (see page 195).

As far as the error you're getting now, the likely explanation (after re-reading the previous posts here) is that you are trying to use the same PFI line for multiple purposes (e.g. Arm Start Trigger + Sample Clock).  If you do want to do this, you would need to enable the same filter for each purpose of your PFI line.  For simplicity, I would simply remove the Arm Start Trigger since I don't think that this is the problem you are seeing.

 

 

Also, 90 ns might be too short to adequately remove the noise--if this is the case you can modify the cutoff period of the lowpass filter if necessary (see the X Series User Manual link above).  The filtering is also configurable for period measurements but the default is still "off".  I'm not sure why the older hardware doesn't have the same problem, we'd probably have to look at the input signal for clues.


Best Regards,

Message Edited by John P on 05-17-2010 04:41 PM
John Passiak
Message 8 of 20
(3,022 Views)

Great. I think the code actually works.

 

For some reason one of my instruments generates a signal that is too noisy for the card. This is really odd since I have 2 identical instruments and one is recorded on the card just fine and the other is not. I also don't understand why the period measurement does fine with exactly the same input signal. I just need to figure out why the signal is too noisy for the card (it actually looks reasonable on an oscilloscope with 50 Ohm termination)

 

The error I was getting (200774) was indeed because I used the same PFI line for several purposes. I just realized that filtering is not going to work in my case because my signal has a constant pulse width of 40ns. It is possible to filter that by using the input signal as a trigger in a pulse generation task but unfortunately I'm using all of the counters already.

 

Thanks again for all the help.

 

 

0 Kudos
Message 9 of 20
(3,017 Views)

If your sample clock signal is 40 ns then the 90 ns filter isn't going to allow this through.  You can actually set the filter all the way down to 20 ns (just change the constant in the VI), so I would give this a try.

 

Are you using BNC or screw terminal connectors?  40 ns is fairly fast--if you have a BNC terminal block I suggest to give that a try if possible.  If not I think the 20 ns digital filtering should still work (it might not be a bad idea to enable it anyway just in case).  The only downside is that the filter introduces a jitter of 1 timebase tick (10 ns).  It will guarantee to pass pulses greater than 20 ns and reject pulses less than 10 ns.


Best Regards,

John Passiak
0 Kudos
Message 10 of 20
(2,991 Views)