Stopping regeneration at a particular cycle

[George_Cs]

Sorry, I miscalculated the buffer-size. In fact this is 10 kHz * 8 hours * 1 DO port = 288 MB. One pattern-cycle is about 300 kB. However, the conclusion is the same.

- George -

[Kevin_Price · Accepted solution]

RE: problems

1. 6-8 hours.  No problem.  Maybe it wasn't clear in my writing, but the (# cycles)*(# samps per cycle) calculation is *ONLY* to determine the scalar value to specify as the # of finite samples to generate.  The actual output buffer only needs to contain 1 cycle of the waveform (or some other integer > 1).  In my little trial-and-error, I actually made a buffer that held 5 cycles and verified that I could end a finite acquisition after exactly 11, 12, etc. cycles of the waveform even though those stopping positions are not at the end of the buffer.  John P's code snippet shows how to implement it in LabVIEW, but the driver capabilities are available for c programmers too.  Which leads me to...

2. Sorry, I'm no help for particulars about daqmx in c.  For non-regeneration mode, you'll need to do some of your own coding to keep track of what you've put into the buffer.  That way when it comes time to stop the generation, you'll know what you need to do to send a final chunk that cleanly transitions from wherever-you-happen-to-be to your desired end state.

   (I actually just wrote up a related feature request on the data acq idea exchange yesterday.  Check it out and give it a vote if you like it...)

   For what it's worth, the time you spend working around the the limitations of hw-timed DIO on your E-series board might make it worthwhile to look into an M-series or X-series board.

3. I'm apparently still not getting what you mean by cycle-counting.  I assumed you just want to know how many total waveform cycles you've generated.  The DAQmx task will let you query the total # samples generated at any time.  And if your code creates the waveforms, then you know how many samples/cycle you have.  Even in the non-regeneration case, you're in control of the writes and can devise ways to track #'s of cycles, right?  What am I not understanding?

-Kevin P

[John_P1]

Hi George,

E Series boards do not have support for sample-clocked digital tasks.  However, the 6025E was one of the two E Series DAQ cards with the 8255A PPI chip (see E Series User Manual) which supports interrupt-driven handshaking on the DIO lines.  So, you're not actually generating a sample clock in the traditional sense, but rather using interrupt-driven handshaking to pass data from the DAQmx buffer to the 8255 outputs.

Anyway, the proposed solution should still work in the regeneration case (using a finite task with a higher number of samples than the buffer size).  The DAQmx buffer will be configured by default to contain exactly the number of samples written to the task, and the data can be regenerated multiple times by specifying a higher number of samples when you configure the timing of your task.

For the non-regeneration case, you can also configure the task to be finite so it will stop after N samples are generated.  You just have to make sure to continuously write new data to the buffer or you will underflow. 

It's true that the Every N Samples event is not supported on your hardware.  A couple of alternative suggestions:

• The write function will block until enough space is available in the buffer to contain the number of samples that you have tried to write (or the specified timeout is reached).  If you're writing to the task in a separate thread anyway, this should probably be adequate.
  
  
• You could poll to determine the number of samples generated rather than use the event if desired.

If the Every N Samples event is a must-have, you'll need to look into other hardware. 

Best Regards,

[George_Cs]

Hi Kevin,

finally I understood your suggestion 🙂
It's easier than I thought!

Here is the solution:

DAQmxCreateTask("", &taskDO);
DAQmxCreateDOChan(taskDO, "Dev1/port1", "", DAQmx_Val_ChanForAllLines);
DAQmxCfgHandshakingTiming(taskDO, DAQmx_Val_FiniteSamps, buf_size*cycle_num);
DAQmxRegisterDoneEvent(taskDO, 0, DoneCallback, NULL);
DAQmxSetWriteRegenMode(taskDO, DAQmx_Val_AllowRegen);
DAQmxWriteDigitalU8(taskDO, buf_size, 0, 10, DAQmx_Val_GroupByScanNumber, &data, &written, NULL);
DAQmxStartTask(taskDO);

So no need for "DAQmxSetRegenCycleNumber" function, this method is doing exactly what I want!

Many thanks for the help!

- George -

[George_Cs]

Hi John,

Although the main question (topic title) already has been answered, I don't understand this EveryNSamplesEvent-problem completely..

When I'm trying to start the task (not the above mentioned but another in which I'm trying to use DAQmxRegisterEveryNSamplesEvent function), I get this error message: "DQmx Every N Samples Event is not supported within non-buffered tasks. To receive Every N Samples Event notifications, configure your task to use buffering."

Actually I don't understand it. As far as I know, this event will be sent when the device gets a specified amount of samples from the buffer, i.e. buffered operation means writing buffer to the device's memory (fifo). I'm in handshaking mode, it's ok, but I'm using buffered I/O. So why I can't register EveryNSamples event? In traditional ni-daq I was able to use Config_DAQ_Event_Message with EveryNScans option even in hadshaking mode! Why this event is limited in daqmx?
Software-sided polling or other continuous buffer-status checking is not too resource-efficient (and elegant) solution.

Since we don't want to force our users to throw away their older (but well-functioning) instruments, our softwares must support many different devices (PCI-6025E, USB-6221, USB-6341 and others). (Moreover this is not a hardware but a driver limit.)


Thanks,

- George -

[John_P1]

Hi George,

Technically it is a buffered task so the error message is a bit misleading, but the fact remains that the feature is not supported.  Since Traditional NI-DAQ has the feature it sounds like the limitation is indeed with DAQmx.  Given that there are only two E Series products that have the 8255 chip it's quite possible that the developers simply put a higher priority on other features.  This is the first time (to my knowledge) that this specific issue has come up, but this is not the only example of behavior that is not included in DAQmx but is possible in Traditional DAQ.

Moving forward, do you think the workarounds I suggested earlier might be suitable for your applicaton?  How do you handle the DIO for the cards which don't support handshaking at all?  The 6025E's handshaking is a pretty specific use-case given that your software must support such a wide variety of DAQ cards.  I'm assuming you just use clocked DIO on cards that support it, and don't support other E Series cards (which have static DIO only) at all?

Best Regards,

[George_Cs]

Hi John,

Some of our applications originally designed for 6025E, but with a few limitations (or extended functionality) these apps must be able to use other "similar" multifunction cards too. Since many of our partners are still working in 6025E-based measuring environment, we must keep the backward compatibility, even if we are using already newer devices and technologies.
Our applications must support many other ni devices, such as 6023, 6024, 6221, 6341 and others. Of course, if the given card doesn't have DO capabilities, then this feature is disabled in the application. But if it does have, the application must select and use the appropriate method what the given card offers.
For example:
PCI-6023E -> timed DO is disabled
PCI-6025E -> interrupt-driven handshaking DO /no internal clock source/
USB-6221 -> timed DO /GPCTR as clock source/
USB-6341 -> clocked DO /independent own clock source/

All in all, since EveryNSamples event is not supported by daqmx in hadshaking mode, I must implement a totally different method (separate thread) for this. 😞

Regards,

- George -

[John_P1]

Hi Geroge,

It sounds like you are updating code from Traditional DAQ to DAQmx and have found that the Every N Samples Event is not supported for DI Handshaking tasks.  I filed a Corrective Action Request on the matter (297836), but I'm not sure how high of a priority we can give the issue given that it is a corner case that is specific to certain legacy hardware and the behavior has been the same since the release of DAQmx.  My recommendation for now would be to work-around the issue.  I apologize for the inconvenience, if you need any help implementing a workaround please let us know.

Best Regards,

[George_Cs]

Hi John,

Yes, I'm updating our softwares from traditional daq to daqmx and the most part of the code has been "translated" without any problem.
As for the missing callback-event, I figured out a workaround: I'm creating a dummy AO task and using its EveryNSamples event to manage (fill and write) the actual DO-buffer block. In this way I can stay in standard daqmx code-structure, and I can easily update the code later if the mentioned correction (#297836) is done (if done at all).
Since DO generation (in this case 2 kHz) is timed by GPCTR, the only open question is whether these callback-events can be synchronized with GPCTR clock.
I note that there's no need for very frequent AO events, because I want to refresh DO buffer in every 4 sec, so 1 event/sec is more than enough. But if I choose a little bit higher event-rate (1 event/500 ms), I can control asynchronicity safely.
(In addition, since AO task is used only for event-generation, in this case the sample-frequency in AO is indifferent, SR can be even 1 sample/event.)
I think it will be a good (and "daqmx-friendly") alternative to the missing handshaking-event.

Thanks

 - George -