Stopping regeneration at a particular cycle

[George_Cs]

Hi all,

I'm doing a continuous pattern generation in "regeneration" mode. It works fine, but I would like to stop the procedure if regeneration is reached a given cycle-number. So, If I want to generate a given pattern-sequence for example 900 times (900 cycles) and then stop the generation, how can I do this?


Thanks,

 - George -

[Virdzs]

I suggest to use non-regeneration mode and count the cycles. In regeneration mode you can't know which sample is generated at the moment and from which sample will you overwrite in the circular buffer. So there will be always a glitch when you write new samples in regeneration mode.

Continuous non-regeneration mode can guarantee you there will be no gaps between the cycles.

Gábor

[bstreiff]

If you don't mind using a counter, you can create a finite pulse generation task that will generate (number of samples of your waveform) × (number of times you want it repeated) pulses, and use that counter as the sample clock for the AO task. Once the pulse generation task is complete, then you can stop the AO task.

[George_Cs]

Hi Virdzs,

I don't want to overwrite the buffer, I just want to regenerate it for N times, but I have some problems with this simple task:

1. Basic problem: in regeneration mode, I can not set anywhere the number of cycles.

2. I can't use DAQmxRegisterEveryNSamplesEvent function, because the system works with, inter alia, PCI-6025E boards, and this type of board doesn't allow to use DAQmxCfgSampClkTiming function for buffered DO operations. Timed DO generation can be done only in handshaking mode (DAQmxCfgHandshakingTiming), but in this case DAQmxRegisterEveryNSamplesEvent function is invalid - consequently, there is no callback event!.. 😕
However, If there's no callback, I can't count the cycles..

3. I'm using M and X series devices too. Though these devices offer callback event during DO generation, but in this case, when I start the task with "DoNotAllowRegen" option, the first few callback event occurs very fast immediately after the start. (The event fires when the buffer transferred from the PC to the device's onboard memory and not when the generation actually has done.)
So If I'm counting the cycles here (in the callback proc.) then my counter is out of sync with the number of the generated cycles.


Regards,

- George -

[George_Cs]

Hi bstreiff,

There is 2 gpctr, but these are already used for other tasks.

A "DAQmxSetRegenCycleNumber" function would be very useful..


- George -

[Kevin_Price]

I'm not sure I know exactly what you're asking.  There's an easy way to do this if you know how many cycles you want before you start the generation.  You would just program the task sample clock for "Finite Samples".  There are 2 other things to go with that:

1. be sure to explicitly specify that the task should "Allow Regeneration".  (In LabVIEW, use a DAQmx Write property node for Regeneration Mode.) 

2. make sure you write an integer # of cycles into your output buffer.  That makes sure that as the generation wraps around from the last sample back to regenerate from the beginning again, the actual waveform transitions smoothly without a big step function.

-Kevin P

P.S.  I see I was slow finishing this reply and some other conversation has happened since I first posted.  I just tried the idea I suggested under LabVIEW while looping back the output to an AI channel for verification.  It worked fine on the E-series board I tested so I expect it should be fine for you too.  The key point is that you can combine the "Finite Sampling" mode which lets you select a specific # of samples to generate with the "Allow Regeneration" mode which lets you set aside a smaller buffer containing N cycles of the waveform to be repeatedly regenerated.

[Virdzs]

There is no way to count the cycles in regeneration mode. And when you want to finish the generation you can stop the generation or keep generating zeros(=overwriting buffer), but you are not able to set the point properly where this should happen.

A workaround can be if you use a pulse train as sample clock as mentioned above. But please understand the regeneration is not for generation signals with defined length. What is the problem with the continuous non-regeneration mode? I am sure it will work for you.

[Kevin_Price]

The pulse train can work, and few people like using counters more than me , but I don't see why it's necessary here.  Maybe I'm making a bad assumption?  Let me list them:

1. Many cycles of a user-defined waveform are to be generated. 

2. The user/programmer knows the # samples per cycle of the waveform and also knows (?) the total # of waveform cycles to be generated.

3. Just multiply (waveform cycles) X (# samp per waveform) = # Finite Samples to specify.  All done.

Why do you say that regeneration isn't for waveforms with a defined length?  I made an example, it seemed to work fine on an E-series board.  The generation stops after the specified total # of samples, regardless of where the generation task left off within the buffer.  What's the problem?

-Kevin P

[John_P1]

I agree with Kevin, in this case the simple solution is just as good as the counter one without using extra resources and overcomplicating the code. Not that there's anything wrong with using counters to do this, but the way I interpret your question it seems like it is an unnecessary step.

Assuming you want to do what I think you do, the following code (based off of Kevin's suggestion) should be what you need (regeneration is enabled by default):

Best Regards,

[George_Cs]

Dear all,

I think I gave too little info. So, the facts are:

* All AI channels and counters are already in use.

* I'm doing pattern-generation on digital output (DO).

* I'm using daqmx c only.

The problems are:

* In some cases the regeneration must run continuously for 6-8 hours. So, not a good idea to build a (very) large buffer (i.e. pattern_cycles * samp_per_pattern) for a "one-step" finite generation, because in this case the buffer-size would be 10 kHz * 8 hours * 8 DO lines = 2.3 GB, while the base pattern-sequence (one pattern-cycle) is about 2 MB..

* Furthermore, in another application, I want to change pattern on-the-fly. In this case, the generation obviously must run in "non-regeneration" mode and the pattern-sequence must be broken into smaller chunks. It's ok, but in this case I need an "EveryNSamples" callback event, where I can update (change and write) the actual chunks. And here is the second problem: I can't register EveryNSamples event, because it's not available in handshaking-mode. (On the PCI-6025E card, the timed digital output pattern-generation works only in handshaking-mode.)

* Third problem: If I can manage somehow the above mentioned problems and create a callback-based cyclic generation, the cycle-counting is still problematic.


Thanks for all comments,

- George -