03-29-2007 11:04 AM
03-30-2007 06:51 AM
03-30-2007 08:24 AM
03-30-2007 09:14 AM
The way the board's counters work requires 2 counters working together as a pair in order to generate a "finite pulse train" with a specific # of output pulses.
DAQmx attempts to do some of the grunt work by configuring the helping counter automatically "under the hood." However, that fact seems not to be advertised prominently enough. Many people have posted before who didn't know why they couldn't do something with their 2nd counter when the 1st was set up for finite pulse train generation. Somewhere, somehow, NI should emphasize this side effect.
It's most fundamentally a hardware limitation, not specifically a DAQmx issue. The older driver also required 2 paired counters working together -- it just required more grunt work on the programmer's part. It was both more difficult *and* more clear.
Another item about the DIO stuff. As I recall one of the other threads, the problem arises because of wanting to have 2 separate hardware-timed DO tasks. Again, it's the board that doesn't support that. You can have a whole bunch of separate software-timed DO tasks, but then you may not get the precision you want due to your OS. The board only supports 1 hardware-timed DO task at a time.
I just reviewed two other threads you had about this kind of stuff. I found that I was in one of them. I think the "buffer merge" idea I presented could work, though I know it isn't trivial to implement -- what problems did you have? I can't say much about the other thread now because I don't have LV near me to look at the posted code.
-Kevin P.
04-04-2007 09:33 AM
04-04-2007 03:23 PM
I saved the code you attached and will try to take a look later when I can get on LabVIEW. However, your text description sounds like you're *still* trying to simultaneously run 2 separate hw-timed digital output tasks. If so, then STOP! It can't be done! The error you describe sounds consistent with this -- if you are trying to specify a 2nd simultaneous clock signal to be mapped to the DO timing subsystem, that's sounds like the kind of error you'd get. The first counter output has *already* been mapped to the DO timing subsystem, so the 2nd attempt fails.
You really *do* need to merge the data so you can create it with 1 DO task. The job of merging the data correctly will require some careful planning ahead on your part. In one of your other threads, I posted an approach for a fairly simple example. Did you follow that? Do you see how you would extend that idea to your own app?
Sorry I can't offer specific code to help. This kind of merge is, in general, non-trivial and I just don't have the time. Can you describe the nature of the two patterns in more detail? If by chance they are a special case that's easier to handle, maybe I could help a bit after all.
-Kevin P.
04-06-2007 08:16 AM
04-09-2007 09:53 AM