01-10-2019 12:02 PM
I'm not 100% certain I understand these last questions clearly. Let me re-describe how things would (need to) work on a 6602, and where the main difficulties would be.
1. The 1st counter generates the pulse signals. The task would be configured for *continuous* pulse generation, but you would use pause-triggering and very careful hardware timing config to implement finite bursts of pulses.
2. The 2nd counter generates the pause-triggering signal that acts to enable/disable counting operations on the 1st counter. Pausing is like disabling and when the 1st counter isn't counting, it basically "ignores time" until you unpause / re-enable it.
3. When the pause trigger signal changes from unpaused to paused, the 1st counter's output will *NOT* reset to its idle state. It will simply lock in at whatever state it happens to be in, high or low. (This was the reason I outlined the need for careful exact timing back in msg #6.)
4. Because the 1st counter is in continuous generation mode, you're allowed to change pulse parameters on-the-fly without stopping the task. If each "cycle" or "burst" of pulses needs to have distinct parameters, you should be reprogramming the pulse parameters during the brief time that the counter is paused.
You won't be able to achieve this perfectly because the OS won't allow you to rely on perfect software timing. But you *might* manage to succeed to an acceptable degree.
5. To control the # of cycles of finite pulse bursts means you need to control the # of times the 2nd counter gets re-triggered and generates the pause signal used by the 1st counter. You won't be able to do this via hardware config on the 6602. It will also be a software operation.
To accomplish it, your software has to be aware of the # of times the 2nd counter has been triggered. When you get to the magic # (let's say 18), you *then* need to wait for that particular cycle of pulses to finish. Then, *before* the next trigger comes in, you need to stop counter 1's task and then also counter 2.
Again, the timing would need to be really precise, and the OS isn't going to let you achieve it perfectly.
6. A newer board such as a 6612 has more advanced capabilities and would give you more ways to try to accomplish the timing-critical changes. Your *exact* needs may still not be trivial, but a 6612 would put you in a better position to try to accomplish your pulse generation requirements. Here are some of its features that the 6602 doesn't share:
- Kevin P
01-10-2019 05:42 PM
Will continous buffered counter output do the job? Generate a buffer of duty cycle - frequency pairs and continuously feed it to the counter. Simulated 6602 does not give an error, seems to support the mode.
Gen Dig Pulse Train-Buff-Implicit-Cont.vi from examples
01-10-2019 06:29 PM
Are you sure you were using an example for hw-timed buffered pulse generation? The example I found had a slightly different name. When I tried it with a simulated 6602 I got a -89125 error, saying it couldn't find any registered trigger lines between the devices in the route. The code shows no attempts to do any explicit signal routing, so I guess there must be something under the hood related to internal signals and buffered pulse generation.
In any event, that (mostly) confirms what I've been pretty sure of since about 1999 when I started wishing and asking for it -- the 6602 doesn't support hardware-timed buffered pulse generation.
I'm on LV 16 and DAQmx 16.0. I got the code from the example finder and then also found it under the <examples> folder in my LV installation. The same code ran without error on a real X-series PCIe-6341 which is known to support buffered pulse generation.
Alexander, can you post the code that ran without error on your simulated 6602? What version of DAQmx and LabVIEW are you using?
-Kevin P
01-10-2019 06:43 PM
Followup on why I don't think a pure buffered output will work. My understanding is that the OP needs to retrigger distinct finite bursts of pulses. Retriggering will happen at ~7 msec intervals and only a fixed # of retriggerings should be allowed.
It's the need to retrigger and sync to the external signal that makes things more difficult. I think that the pulse params for each individual 7 msec window can be predefined though. Some of the stuff I said back in msg #6 describes the beginnings of an approach that might turn into something that works.
-Kevin P
01-10-2019 11:24 PM
Thank you for your patient guidance and reply.
01-11-2019 08:35 AM
Kevin,
Example attached.
LV 2011, DAQmx 14.5.1
I believe it does not support buffered pulse generation from digital lines (newer 6612 does). But from the counter...
01-11-2019 08:46 AM
Alexander: your code does not throw an error for a simulated 6602 here either. Also no errors on a real 6341, but attempts to query the supposedly variable pulse train params return constant values. Gonna look into this a bit more. I'm not convinced that a real 6602 actually supports buffered pulse output, but it's worth some further investigating...
-Kevin P
01-11-2019 08:59 AM
Ok, dumb error on my part. The new example includes a default setting for programming the PFI pin to use for the output terminal. When I designated a counter on my simulated 6602 I never changed the output terminal away from the default of "/Dev1/PFI12", hence the routing error I got.
After dealing with that, I too no longer see any errors from a simulated 6602 with either the LV11 or LV16 example.
I'm about due for a reboot for other reasons soon anyway, I'll install a real 6602 and try again after. I feel pretty confident that a real 6602 won't do buffered pulse output, but it's better to investigate.
-Kevin P
01-11-2019 09:36 AM
Unfortunately, I couldn't come up with a real 6602 after all. We used to have a few in our spares cabinet, nobody seems to know what happened to them.
-Kevin P
01-12-2019 08:12 PM
the 6602 cannot do buffered pulse output,I need the pulses counting function,about this i have no idea.