Generating a finite waveform using an external clock, and retriggering

[BseeMcm]

I need to generate a finite waveform that's driven via an external clock.  This waveform will have about 900 different tick counts for low and high ticks.  I also have an external trigger signal that I want to use to fire this finite waveform again (using the task retriggerable feature).

I have 2 main questions. First, CreatePulseChannelTicks() only takes a single value for high and low ticks.  If I start this task, those 2 values are generated on repeat.  I have defined my array of values in a CODataTicks[].  If I write this array out using CounterSingleChannelWriter.WriteMultiSample(doDataTicksArray), does that still use the external clock I defined in ConfigureSampleClock?

2nd, is it possible to use the finite waveform, external clock source, and retriggerable feature together?  If I'm reading this correctly, this page suggests it may not be possible: https://www.ni.com/docs/en-US/bundle/ni-daqmx/page/gensnglefinconttrains.html If this is supported, can you point me to an example?

[Kevin_Price]

What DAQ device are you using?  It needs to be one that supports buffered counter output operations.  Such support has been pretty common for devices designed and released within the last decade or so, but there are some exceptions.

The help file you linked was not as helpful as it should have been - things weren't explained very well, IMO.  The operating mode illustrated there is one I haven't personally tried and don't know what devices do and don't support it.  Are you sure that's the mode you need, one where each incoming sample clock pulse causes the counter to advance by one sample in its array of high/low times?  And each of those specific high/low pairs might repeat indefinitely until the next external sample clock pulse arrives?

If so, then you *probably* also need to watch out for a case where 2 sample clock pulses arrive before the first high/low pair can finish generating.  I would expect that to produce an error.  I *do* know that in non-buffered mode, it's an error to change high/low times on the fly before the previous pair has completed at least 1 full cycle.

I would expect that a more common use case for buffered output is one where *every* pulse timing high/low pair is defined by the buffer of values.  Then you would configure for "Implicit" timing which will simply advance through the set of high/low pairs in sequence.

Either way, any device that supports buffered counter output should also support retriggering and the Implicit timing option.  Presumably *some* devices exist that support the external sample clock approach shown on the help page, I just don't know which ones they are.  But I'd bet they would also support the retriggering you want.

-Kevin P

[BseeMcm]

I'm currently testing with the USB 6421.  However, this is for a new project, so if the feature is missing in this model then I could consider different hardware.  As far as the API calls, I'm guessing based on NI example code.  This is my first time experimenting with waveform generation.  The guide for pulse generation on the USB 6421 is pretty good: https://www.ni.com/docs/en-US/bundle/usb-6421/page/counter-output-app.html#GUID-359C8778-8866-4360-B...

Physically, we are taking a 4000 pulse per rev encoder, with a 1/rev marker pulse and converting that to a custom waveform.  The waveforms are to be synced, so the generated custom waveform must stay synced to the source encoder.  Does an application like this need buffered output?  The number of high/low pulse ticks I output are predefined, but they're driven by the external clock that has jitter.  After my 900 pulses are written, I want to stop outputting a waveform until the next trigger signal comes in.

Thank you,

Brandon

[Kevin_Price]

This sounds like the more common use case I referenced.  Configure for "Implicit" timing and Finite Sampling using a buffer that contains 900 high/low pairs.  That will simply advance through the 900 defined high/low times in sequence.  The whole task can then also be configured to be retriggerable using the 1-per-rev pulse as a Start Trigger.

If your 900 pulse pair "waveform" represents less total time than 1 rev of the encoder, you'll be able to retrigger once for EVERY rev.  If it represents more time than 1 rev of the encoder, you'll miss 1 or more triggering opportunities, but the task will still retrigger on the NEXT one and maintain its alignment with the encoder's rotational position.

-Kevin P

[BseeMcm]

Am I correct in assuming this means I need a different DAQ model?  Buffered pulse generation seems to be limited to 63XX models (X series).  I don't think it's included in the 64XX series that I currently have.

Assuming I get the correct model, is the following code the right way to configure this?

//Array contains roughly 900 different values
CODataTicks[] crankshaftSignal = GenerateCrankshaftSignal(timebaseFrequency, totalTeeth);

counterTask = new Task("CounterOutputTask");
counterTask.COChannels.CreatePulseChannelTicks(
    outputCounter, 
    "CrankshaftSignal",
    clockSource,  // External clock (with jitter)
    COPulseIdleState.Low,
    0,  
    2,   //For init only
    2);  //For init only
	
counterTask.Timing.ConfigureImplicit(SampleQuantityMode.FiniteSamples, crankshaftSignal.Length);

// Configure the external trigger to restart the sequence
counterTask.Triggers.StartTrigger.ConfigureDigitalEdgeTrigger(
	inputSignalSource,  
	DigitalEdgeStartTriggerEdge.Rising);
counterTask.Triggers.StartTrigger.Retriggerable = true;

// Write the 900 values
CounterSingleChannelWriter writer = new CounterSingleChannelWriter(counterTask.Stream);
writer.WriteMultiSample(false, crankshaftSignal);

counterTask.Control(TaskAction.Verify);
counterTask.Start();

 -Brandon

[Kevin_Price]

I only program LabVIEW and can't vouch for any text language syntax details.  But overall, what you posted looks sensible and at least "on the right track".  Reading through it, it sounds like it's trying to do what I suggested in msg #4.

I also haven't used (or really even explored specs for) the 64xx MIO devices.  However, I'd *still* be start by expecting them to support buffered counter output.  Each of the major MIO generations has generally improved (or at least retained) counter capabilities from E-series to M to X and so presumably now to mioDAQ.

LabVIEW comes with a shipping example for buffered counter output.  Maybe there's an analogous example available for your language so you can test this out?

-Kevin P