USB-6211 - Getting Error 50103 when attempting to use two counter method

[CBJohnson]

I am using a USB-6211 and want to measure the speed of a motor by counting pulses coming back from sensors on the motor. Speed will vary from 0 to about 5k Hz.

My strategy is to use "Method 2" in the manual to measure using two counters.  To do this I am attempting to generate pulses of known duration with Counter 0, route these pulses to the gate of Counter 1, send the motor pulses into the source of the counter1 and letting the counter determine and report the number of pulses that occur during the "gate time".

To get the pulse generator going at 8,333 Hz I do this:

AGniDAQmx_CreateTask(instrHandle,"TimingPulses, Task_Handle8)
AGniDAQmx_CreateCOPulseChanFreq(instrHandle, Task_Handle8,"Dev1/Ctr0","Out",DAQmx_Val_Hz,0,8.333,0.5)
AGniDAQmx_CfgImplicitTiming(instHandle, Task_Handle8, DAQmx_ValContStamps,1000)
AGniDAQmx_StartTask(instrHandle, Task_Handle8)

This works fine.  (By the way, I do stop and clear the task before exiting.)

Now I add this code in a new task to try to use the Counter0 pulses to measure the input pulses with Counter1.

AGniDAQmx_CreateTask(instrHandle,"MotorPulses, Task_Handle5)
AGniDAQmx_CreateCIFreqChan(instrHandle,Task_Handle5,"Dev/ctr1",MotorPulses,0,10k,DAQmx_Val_Hz,DAQmx_Val_Rising,DAQmx_ValHighFreq2Ctr,0.12,10,"")
AGniDAQmx_ReadCounterScalarU32(instrHandle,Task_Handle5,10,E)
AGniDAQmx_ClearTask(instrHandle,Task_Handle5)

This function fails on the CreateCIFreqChan() call with an DAQMXError 50103.

Apparently Counter1 resources are being tied up by Counter0.  Is this true?

Any suggestions?

Thanks,
-CBJohnson

[mallorim]

Hi CBJohnson,

If I understand your application correctly, you want to determine the speed of a motor by counting the frequency of pulse returned from sensors connected to the motor. In order to determine the pulse frequency, you are continuously generating a pulse train with Counter 0 that you then use to gate Counter 1. Counter 1 will then determine the frequency of the motor pulses. You know that this frequency will be from 0 to 5 kHz. Is my understanding correct?

I understand “Method 2” to be the High Frequency 2 Counter Method. When you create a Counter Input Frequency Task and use the DAQmx_Val_HighFreq2Ctr measuring method, the DAQmx driver automatically divides down the 80 MHz Internal Timebase using one counter. The driver will internally route this slower signal to the Gate of the second counter, which will then use this known period to determine the frequency of the signal connected to the counter’s Source. As such, the driver will reserve both counters for this task. This is most likely why, when you try and generate the pulse train and do the routing manually, you are receiving this Resource Reserved Error. You do not need to do this pulse train generation, just run the CIFreqChan task and all the signal routing will be done for you.

Something to consider is that Method 2 is meant to be used when the frequency of the signal you desire to measure approaches the frequency of the internal timebase used by the counter, which is generally 20-80 MHz. Since your motor speed is significantly slower, I would suggest using Method 1, or the Low Frequency 1 Counter Method. This method uses the Timebase as the Source Signal and the unknown frequency as the Gate then internally does the math. In C, the measurement parameter for this method is DAQmx_Val_LowFreq1Ctr.

Note: I am unfamiliar with the language that you are programming in, but as it looks similar to C code, in the Implicit Timing line of your Task_Handle8 could you have meant ContSamps, without the t?

I hope this explanation helps, Mallori M.

[CBJohnson]

Hi Mallori,

Thanks for the great reply message.  I do appreciate your help.

Yes, I think you understand my application.  The motor can turn from zero to about 5K RPM and one pulse is generated with each turn of the motor.

This application is using Agilent VEE but the statements are "C-like" so that's why I posted them like that.  I can't "cut-and-paste" directly from the VEE statements and I have to type them.  I mis-typed the Implicit Timing statement.  It was missing an "_".  It should have been:

AGniDAQmx_CfgImplicitTiming(instrHandle,Task_Handle8,DAQmx_Val_ContStamps,1000)

I think I understand what you are saying about DAQmx_Val_HighFreq2Ctr using the resources from both counters  That explains why I get the message about resources not being available.  

I have tried to use Counter Method 1 and it *almost* worked.  A problem comes about when the motor speed is zero (stopped) and, since these motor pulses are being fed into the Gate of the counter, the zero value makes it simply time out.  Increasing the timeout value to infinite (-1) makes the entire program hang.  I need it to go on -- looking for other user input, reporting other data being collected, etc. If the counter is waiting for the Gate signal to rise to start counting and to drop to stop counting and do the calculation, it will not work since it just times out.  I went to this counter method (actually called counter method 3 in the DAQ manual) because then I am trying to generate the pulses of known period and send these pulses to the Gate.  Then I am feeding my pulses into the Source of the counter and letting it determine how many pulses occured during the "gate time".  In this case, zero pulses during the "gate time" should be OK; it should simply report that zero pulses were detected and start counting again on the next rise of the Gate pulse.  I thought I could simpy adjust the length the "gate time" to measure my range of frequencies.

Make sense?  Any way to do this with the two counters of the USB-6211?

Thanks, Mallori,

-Craig

[Kevin_Price]

I just got done answering a similar question about reading counter frequencies that approach 0 using single counter freq measurement.  Have a look at this suggested workaround.

-Kevin P.

[CBJohnson]

Thanks, Kevin.  That's a good thought.
Do you have any idea how accurate the timeout spec is?  With pulses to the Gate I can measure them with an oscilloscope to see that the
measurement period is what I want.  Is there any proof that the timeout period is accurate and repeatable?
-Craig

[Kevin_Price]

I'm sure the timeout spec is a little bit approximate and is probably subject to some whims of the OS.  So it'll probably usually be correct to within some msec, but the read function may occasionally take a little longer to timeout. 

But remember that the timeout only happens as you approach that low freq threshold and fail to get a pulse within the time limit you choose.  The rest of the time you *don't* timeout and you get true measurements with oscilloscope-like accuracy based on timing between gate pulses. 

-Kevin P.

[CBJohnson]

Kevin,
Ah!  Very true.
I'm going to give it a try.  Thanks for your help!
-Craig

[CBJohnson]

I tried the "timeout" method and it almost works.... except.... when I start sending pulses again I cannot get it restart the counting.  The timeout persists.
The other functions keep operating, during the period timing period no pulses and after the pulses are started again. 

Do you know if it's necessary to clear the device after a timeout?  I really doubt it since I really don't think the USB-6211 knows anything about
the timeout occurring.   Still, I thought I'd ask.  It may be my driving software that needs to be cleared out after the timeout.   So far I can only
accomplish this by shutting everything down and restarting.

Thanks.

-Craig

[stilly32]

Hey,

Just my two cents: Along with just waiting for a timeout, you can set the number of samples to read to -1, and if no values are in the PC buffer then the read will return without an error. That way you don't have to worry about the timeout. The only real downfall of this is that once you get up and running, you'll probably get a large indeterminate number of samples from the read - which can be a pain when allocating memory. After your first set is acquired and your machine is up and running you can grab a specified amount.

Also, I haven't tried the wait for a timeout method but it should work. I believe it is the case that you will have to restart your counter task, but you can reduce the setup time by commiting your task before you start it with DAQmxTaskControl ().

Cheers,

Andrew S

Message Edited by stilly32 on 12-17-2007 01:59 PM

[CBJohnson]

Thanks, Andrew,
I'm not sure I'm tracking 100% with you but I tried setting the "minimum value" to -1 and then it just times out immediately.

I'm still trying to figure out a way to clear the timeout condition with resets or whatever.  It's not a hardware issue but possibly a
driver issue.  Something associated with the task name is being remembered and cannot be cleared or reset without restarting
everything from scratch.  The hardware continues to operate after the timeout lockup has occurred.  I know this because I can
add a new task to the project with a new task name after the timeout lockup has occurred. The new task then operates properly
(counts, reads the count, etc) while the original task remains locked with the timeout. 

Not good - it's a "show stopper" for me. .

-Craig