DoNotAllowRegeneration

[Morten_Hvidberg_Knudsen]

Hi All,

Aparently  SampleQuantityMode.ContinuousSamples and DoNotAllowRegeneration does not work for digital output on a 6229 board.

For analog output, a DAQ-mx task correctily raises the Done event  when all the supplied values have been clocked out of the buffer(s):

    {
        private void a()
        {
            var Device = "Dev1";
            var ByteRate = 100; ;
            var SamplesPerChannel = 100; 
            var BufferLen = 2000;
            var  AOtask = new Task();
            AOtask.AOChannels.CreateVoltageChannel(Device + "/ao1", "", -10, 10, AOVoltageUnits.Volts);
            AOtask.Timing.ConfigureSampleClock("", ByteRate,
                SampleClockActiveEdge.Falling, SampleQuantityMode.ContinuousSamples, SamplesPerChannel);

            AOtask.Stream.WriteRegenerationMode = WriteRegenerationMode.DoNotAllowRegeneration;

            AnalogSingleChannelWriter AOwriter = new AnalogSingleChannelWriter(AOtask.Stream);
            AOwriter.WriteMultiSample(false, new double[BufferLen]);

            AOtask.Done += new TaskDoneEventHandler(AOtask_Done);
            AOtask.Start();
        }

        void AOtask_Done(object sender, TaskDoneEventArgs e)
        {
            Debug.Print("Output buffesr now empty");
        }

However for a Digital output task the Done event is never raised:

        void b()
        {
            var Device = "Dev1";
            var ByteRate = 100; ;
            var BufferLen = 2000;
            var DOtask = new Task();
            DOtask.DOChannels.CreateChannel(Device + "/port0/line0:7", "", ChannelLineGrouping.OneChannelForAllLines);
            DOtask.Timing.ConfigureSampleClock("/" + Device + "/PFI8", ByteRate,
            SampleClockActiveEdge.Falling, SampleQuantityMode.ContinuousSamples, BufferLen);

            DOtask.Stream.WriteRegenerationMode = WriteRegenerationMode.DoNotAllowRegeneration;

            var DOwriter = new DigitalSingleChannelWriter(DOtask.Stream);
            DOwriter.WriteMultiSamplePort(false, new Int32[BufferLen]);

            DOtask.Done += new TaskDoneEventHandler(DOtask_Done);

            DOtask.Start(); 
        }

        void DOtask_Done(object sender, TaskDoneEventArgs e)
        {
            Debug.Print("The Done event is never raised");
        }

Is there a trick to get the Done event raised when the output buffer is empty, or is there any other way to tell when the last pieces of data has been clocked out of the buffer(s)  ?

Best regards

Morten

PS: I am aware that in my simple examples above I could have used SampleQuantityMode.FiniteSamples, but in general this is not an option

[A.E.M]

Hi Morten.

This is expected behavior for our M-series DAQ cards. The correlated DO hardware doesn't have the ability to generate interrupts, which would be necessary to produce a Done Event. The circuitry on a X Series card does have the ability to generate interrupts.

Now, for a "work-around" for your M-series card, you could use a Counter Input task to constantly count the number of ticks from the used sample clock to monitor how many samples have been written. In LabVIEW this could look like this:

If you continuously output digital signals, you will need to make sure that you are keeping track of how many digital values are written to the buffer with each iteration.  It is this value that you will need to compare against the CI-task value to make sure that all of your values have been written out. 

I would properly also add some kind of triggering so that the CI task is started at the same time as the DO task. In the example above, I have made sure that my counter does not start before the DO task is started. However, the DO task may generate a couple of samples before the CI task starts, since I have not used a trigger.

It is also worth paying attention to how many samples you plan on sending out during the execution of the code.  M Series cards have 32-bit counters which can only count up to 4294967296 before they roll over and start counting up from 0 again.  If the code is going to be executing at fast sampling rates or for long periods of time, you may need to also write some code to make sure you handle this correct.