Error -201314

[ry78]

Hi, I'm trying to build a program that allows me to acquire data from an analog and digital input synchronously.  In this particular case force from a strain gage and frequency from a TTL level logic input.  When I execute this program I get the following error: 

Multiple Sample Clock pulses were detected within one period of the input signal. Use a Sample Clock rate that is slower than the input signal. If you are using an external Sample Clock, ensure that clock signal is within the jitter and voltage level specifications and without glitches.

I don't know if the error is in my code or possibly an incompatibility with my hardware setup.  (I'm having troubles with the Sample Clock)

Which includes the following:

-cDaq-9178

-NI 9401

-NI 9237

I have attached a copy of my code.

All information will be helpful.

Thanks for your time.

Ryan

[Patrick_NI]

Hello ry78, 

Here is some information on the error message and how to get rid of it:

http://digital.ni.com/public.nsf/allkb/18E8B27384BBCC7B86257A6800618056?OpenDocument

To be successfullly synchronized, you must also take care of the filter delay created by the ADC of your 9237.  Information on how to do this can be found here:

http://digital.ni.com/public.nsf/allkb/F989B25FF6CA55C386256CD20056E27D

[ry78]

Hi, Patrick thanks for the two links.  

The second link I understand with the "filter delay" issue.  (I will use this recommendation)  I'm just surprised Labview couldn't deal with this delay little more efficiently.  (Instead of creating "dummy" counts in the code itself)

The first link still is confusing me.  It basically is telling me I should be using Implicit Buffered Pulse-Width Measurement.  Is this the same as Implicit (Counter)?  I tried using that (Continuous Samples) and I get the following error "200077 - Requested value is not a supported value for this property. The property value may be invalid because it conflicts with another property."

My next question:  Is it really necessary in the code to have the digital portion of this code start first before the analog side to make sure the two start together?  I thought the two would execute in parallel regardless.

Ryan

[Patrick_NI]

Based on the error, what the first link is saying is the sample clock is occuring faster than your TTL digital signal.  This is causing an error because the program is requesting a measurement, the measurement is starting, and then the card is requesting another measurement before the first measurement has been completed.  To avoid this, the sample clock just needs to be slowed down to be slower than the period of the signal that you are making the measurement on.

I hope this helps, please let me know if there is more that I can do to clarify.

[ry78]

Well Patrick, I tried adjusting the sample rate.  I dropped the sample rate constant to 1 instead of 1000 and it still gave me the error?  My TTL signal is coming in at a faster rate then this.

How do I adjust the Sample Clock rate?  I thought the constant governed that?

I tried using the 80/20MHz and 100KHz sample clocks and I received an error stating the rate was basically to high.  (I believe for my NI9237 50KHz)

Can I adjust my program to accept a higher rate sample clock?

Thanks for you time.

Ryan

[Patrick_NI]

Ryan, 

Yes, changing the constant currently 1000 on your code should change the sample rate.  Tell me a bit more about your TTL signal - what frequency ranges does it operate on?  Is there any period of time where it is not outputting anything?

Also, how are you physically wiring the signal to the 9401?

[ry78]

Well on my current setup I have the signal wire in port 16 and the ground wire in port 1.  The sensor is used to measure rotating shaft speed.  The shaft being only 1/4" dia has a small 12 tooth gear connected to it.  A hall effect sensor picks up the tooth movement coming across it and outputs a 0-5 vdc square wave. (Or as tested 5.02 vdc)  So yes there might be periods of time with no shaft movement.  But the majority of the time it will be rotating at different speeds.  For this particular application no more then 8000 RPM.  (1600 Hz's)

As a side note, I can acquire the TTL signal by making a separate stand alone program but with Implicit timing control.  I can also acquire the analog signal from the strain gauge using a stand alone program.  I can even acquire both on the same vi separate from one another.  But for some reason I'm having difficulties acquiring them synchronously.

Thanks

Ryan

[Patrick_NI]

Hello ry78, 

In order to have the two tasks acquire synchronously, you must use sample clock timing.  This will allow you to share the sampling clock between the two tasks, an option implicit timing does not allow.  However, this means that the sample rate is fixed.  If your sampling clock ever pulses high twice before a pulse of your TTL signal, this error will occur.  This will happen during the periods of time with slow or no shaft movement.  

There is a workaround you can try.  Because the sampling clock should work for shaft rates above the sampling clock rate, you can just ignore this particular error.  This will allow you to successfully acuire synchronously at rates above the sampling rate.  Here is documentation on how to ignore a specific error:

http://digital.ni.com/public.nsf/allkb/BF72229C53F7633386256EDD0069331B

Please let me know how it goes!

[ry78]

Well Patrick I tried the work around but I couldn't get it to work.  I don't think I implemented it correctly in the code.  I sent a copy of what I did.

When you choose sample clock timing is the rate defined by the constant for "rate?" Or is it fixed to the on board time bases of 100KHz, 20MHz, 80MHz?

Thanks

Ryan

[Patrick_NI]

In order to properly handle the error, you need to do it inside of your while loop.  Otherwise, the error wire will cause your loop to exit before you can ignore the error.  

The sampling rate is defined by the constant for rate.  It is based off the timebase, but is not at the same rate as the timebase.

I did notice a potential problem in your code for the rate.  First of all, you are reading only one sample every time the loop iterates.  This means you are only pulling one sample off of the buffer every iteration of the while loop.  This while loop's timing is controlled by the software in your computer, and each iteration likely takes more than 1 ms to complete.  However, samples are being put on the buffer at a rate of 1kHz.  This could lead to buffer overflow problems in the future.  To avoid this, try reading multiple samples at a time.  I attached 2 VIs, one containing this edit and one without.  Try running the first one to check how many available samples are piling up on the buffer.  The second one changes this by reading multiple samples and outputting to waveform charts.  I also took the liberty to fix your dataflow so that your read functions could operate in parallel.

Let me know if this helps!