Capturing a time stamp train in .NET from a 6602

[MrSethT]

I thought I had gotten through this, but was seeing errors in my data and realized I never explicitly set the timebase to 80Mhz.  

I thought it might be task.Timing.ConfigureSampleClock() but it's not.  I have already configured implicit.  Where can i set the timebase source to the 80Mhz clock?

[Kevin_Price]

I don't know the syntax for the .net API.  In LabVIEW, at the time of creating the period measurement task there are inputs for the expected min and max period.  If you pick a short enough minimum period, DAQmx will know to use a faster timebase.  Similarly, if you pick a long maximum period, DAQmx will know to use a slower timebase to avoid counter rollover.  If there are similar parameters in the .net function call, I recommend you lie to the function and claim a minimum period of around 25 nanosec.  25 is probably the minimum allowed at 80 MHz - many counter functions require a minimum of 2 timebase edges per measurement.  

There's also a way to set it explicitly, but again, I'm away from any DAQ machine and don't recall the exact terminology.  I'm not sure how it'd translate for .net anyway.   For the moment, I can just say that I'm pretty sure there *is* a way for you to get there from here.  It's worth pursuing.

-Kevin P

[MrSethT]

Thanks, been trying variations of that already.  

var channelA = counterReadTaskA.CIChannels.CreatePeriodChannel(encoderPaths[0], "", 25.000000e-9, 26.000000e-9, CIPeriodStartingEdge.Rising, CIPeriodMeasurementMethod.LowFrequencyOneCounter, 31200, CIPeriodUnits.Seconds);

Also tried shortening the time, and trying CIPeriodMeasurementMethod.HighFrequencyTwoCounte but always 

counterReadTaskA.Timing.MasterTimebaseSource still equals "/Dev1/20MHzTimebase"
counterReadTaskA.Timing.MasterTimebaseRate still equals 2000000

Am I even looking at the right properties?

[Kevin_Price]

I did a quick trial that worked in LabVIEW.  The property to look for is found in the LabVIEW API as

DAQmx Channel property -> Counter Input -> Counter Timebase -> Source.  It gets abbreviated

on the diagram as CI.CtrTimebaseSrc.   (There's a similar one for Rate, but that doesn't need to be

set when using a known internal timebase).  

I ran a couple shipping examples, one to generate a pulse train, the other to read period values in

integer count form.  I set the property above CI.CtrTimebase.Src to various internal timebases and

confirmed that the # of counts in the period measurement were correct for the freq I was generating

on the other counter.  Specifically, while generating at 1 kHz, the 20 MHz timebase gave me count

values of 20000 while the 100 MHz timebase gave me count values of 100000.  Your board will

have choices for 100 kHz, 20 MHz, and 80 MHz for the timebase.

Hopefully someone else can translate into the .net syntax, but at least you be assured that it *can*

be done.

-Kevin P

[MrSethT]

Very helpful!  I found that property.  (channelA.CounterTimebaseSource and channelA.CounterTimebaseRate)  Bad news is that they have been set to 80Mhz the whole time.  So, that means, if I am seeing bad results, the fault lies elsewhere 🙂  

Thanks so much again Kevin!