06-22-2021 09:05 PM
DurationInSeconds
ch.Frequency
test = daq.createSession('ni');
ch=addCounterOutputChannel(test,Device_ID,'ctr0','PulseGeneration');
ch.Frequency=100000; % Palse per second
test.DurationInSeconds=60;
06-23-2021 11:14 AM
You *might* be running into an integer overflow situation. With your device's default 80 MHz timebase, your device's 32-bit counter will reach its max u32 value and rollover in a little less than 54 seconds (2^32 / 80e6).
A finite pulsetrain on your M-series device will use both counters -- the one you specify in the config is the one that produces the output pulses while the other "helper" counter acts as a timing gate to control the duration of time those pulses are generated.
I think I recall a long ago thread where it was necessary to configure things more explicitly in order to force the helper to use a slower-than-default timebase in order to prevent the rollover effect. But I can't seem to find it now.
Experiment a bit and see whether there's a breaking point between 50 sec worth of pulses and 60 sec worth. If so, that's a pretty good indicator that rollover is the culprit.
On the other hand, I have no idea what Matlab does with your "DurationInSeconds" setting. I don't know the Matlab API at all, but it ought to support the DAQmx functionality for a finite pulse train with a specific exact # steps. Maybe you just need to do your Matlab-based configuration differently.
-Kevin P
06-24-2021 08:33 PM
Thanks Kevin.
This might not be the rollover effect. I can generate the pulse train of the same finite number in same time consumption using LabView VIs like this.
This is mainly caused by the inaccurate clock signal or pulse frequency when I use MATLAB to control the card. (This also may caused by my wrong used code)
For example, I want to generate 10000 pulse in about 2 second, in LabView, I set 'Sample per channel' to 10000 and the ' low Time' & ' high Time' to 1e-4. This program give me just the number of pulse and the time consumption I expect. In MATLAB, I set the Frequency (pulse per second) to 5000 and the time duration to 2s, but it gives wrong output pulse number. (The LabView code indicated the card had the ability to achieve this)
In fact, I focus mainly on the Number of pulse rather than the time duration (I need exactly 10000 pulse and the time of 2s is not such necessary). I want a method that I could directly control the number of the pulse in MATLAB rather use the product of time and pulse frequency.
I think this can be also achieves by MATLAB, but I didn't find any solution yet. Thank You Anyway.
HZY20
这应该不是采集卡的"rollover effect"导致的,因为我在LabView中能够在相同时间内产生相同数量的脉冲信号。MATLAB中我用脉冲频率×时间的方式产生指定数量的脉冲,我觉得是因为脉冲频率或者持续时间没那么准确导致的。我需要精确的脉冲数量控制,时间只要差不多就行。我暂时没有找到MATLAB中直接控制脉冲数量的函数或者程序。
感谢大家的帮助,祝大家工作顺利!
06-25-2021 08:26 AM
Does your Matlab code produce slightly different total #'s of pulses on different runs? If so, it sounds like the config you've used is measuring the 60 sec duration in software somehow, then reacting with a software command to stop what was otherwise a continuous pulse train.
Take note of the fact that your LabVIEW config had to set up several distinct parameters and properties that are not accounted for in the Matlab code. Particularly, nothing similar to your call to DAQmx Timing where you can choose Finite Samples (rather than Continuous), while explicitly setting the # samples to generate (and have that # controlled at the hardware level).
Dig a little deeper in the Matlab API, I expect there are functions to let you do the config you're after. I just don't have any idea what they're called or where to find them.
-Kevin P