Digital I/O

cancel
Showing results for 
Search instead for 
Did you mean: 

delay between 2 counters

I'm using the 6221 & attached is a VI where I need to adjust the initial delay between 2 counters. I get error  50103 : specified resource is being used. I guess it doesn't like the fact that I'm starting 2 tasks - one with each counter ?
I based this delay code from the delay example forum.vi posted on another post. It uses ctr0 & 1 start tasks without any problems apparently.

How come mine is having issues ?
Is this because ctr 0 & 1 are 'paired' ?

Thanks,
ak

0 Kudos
Message 1 of 8
(4,345 Views)
Yes, the problem is related to the fact that they are "paired."  Specifically, you configured both of them to generate a finite pulse train.  When you configure 1 finite pulse train, DAQmx uses 2 counters to do it.  That's why you can generate on either counter separately but not together. 

There may be workarounds, but it depends on what you need to accomplish with these signals and timing requirements.  What's the bigger picture about your app?  What do the pulse trains do?  Why must they last for a specific finite # of pulses?  What's the DO task doing & why?

-Kevin P.


ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 2 of 8
(4,341 Views)
Thank you - I understand. I've found a different way to incorporate the delay - literally padding the pulse trains appropriately with zeroes.

To be honest, I'm a little perplexed at why such seemingly simple tasks are that complicated in DAQmx.... I'm wondering if this is an inherent DAQmx balance between versatility & ease of use, or whether my 6221 card is just a low end DIO device ?

As an example, I have another post in the DIO forum where I've given up trying to find a solution - but the problem is amazingly simple : I want the user to supply a digital waveform & have that continously output together with 2 other fixed waveforms. I must have create 10 different vi's but none of them are error-free. Apparently my particular DIO task is considered difficult & that worries me.

Right now I don't have much confidence in DAQmx as a straightforward means of DIO & would opt for use of a microcontroller that, compared to at least my 6221, has no limitations on signal configuration.

ak

0 Kudos
Message 3 of 8
(4,337 Views)

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.

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 4 of 8
(4,330 Views)

I've modifed the vi to use continous samples. I have a dedicated counter that is delayed w.r.t to a 2nd counter. One waveform is written to each digital IO line that receives it's clock from its own counter.
I get error 89137 : Specified route cannot be satisfied, because it requires resources that are currently in use by another route.
What does this mean ?

All I want to do is to delay 2 digital waveforms a user specified amount.
A 2nd issue is that the internal while loop never exits because the task is never done (continous samples) ! I've tried many things in the past & can't get this part to work either.
I've looked & implemented examples & must have at least 20 simple vis but nothing works right. I'm not having much luck Smiley Sad

Any help would be greatly appreciated - specific code is best - I've been trying to implement this for a while & need specific help.

ak

0 Kudos
Message 5 of 8
(4,297 Views)

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.

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 6 of 8
(4,289 Views)

Thanks Kevin. I created the delay using your suggestion. I created a small timebase for all 3 signals that would allow me to modify a delay between them & it worked from a single task.

But wow, the 6221 bristles with inputs & outputs & yet only 1 hardware task can be performed at a time - my suggestion is that that be stated in somewhere in the product description.

Also, the 6221 data sheet on the NI website doesn't seem to open properly - I'm using Adobe Reader 7.0 & get an error 'file does not begin with %PDF-.

ak

0 Kudos
Message 7 of 8
(4,271 Views)
Hi AK,

I think a small clarification of the 6221 should be explained.  You can only perform a single hardware task of each type.  You can only have one Analog inpput task running.  You can have all the analog input channels as part of that task, but they are all going to be acquiring at the same rate.  At the same time you have this going on you can have an Analog output task occuring as well.  I just wanted to clarify the situation.  You can have more than one counter task running at a time, but depending on the type of counter measurement you have setup, it might occupy both available counter circuits on the board.  Let me know if this needs any clarification, but it is possible programatticaly to use every input and output on the board simulataneously.  I was able to open up the data sheet this morning, but please let me know if you are still seeing that behavior and I will bring it to the attention of our web team. 

Have a great day,

MIchael D
Applications Engineering
0 Kudos
Message 8 of 8
(4,254 Views)