Resource conflict when using two counters (pulse gen & position measurment)

[henderd]

Hello,

I would like to use one counter on my USB-6221 to generate a retriggerable finite pulse count to drive a couple of outputs, and to use the 2nd counter to measure position using quadrature encoding (see attached C++ code snippet).  As coded, this causes a resource conflict in DAQmx 8.6 - I believe due to setting the first counter to generate finite samples.  Could someone please explain how this causes a conflict and how best to work around it?  My basic requirements are to 1) measure position continually and 2) generate repeated, finite output signals including one analog output and one digital output, both tied to the same trigger.

Thanks!
Dave

[stilly32]

Hi Dave,

This is actually a HW limitation - M-Series devices (like the USB-6221) have two counter timers. In this case, the finite pulse train generation takes up two (one to generate the pulses and a "paired" counter to gate it) and the position measurement takes another - so that is the HW resource conflict you're running into. Luckily there are usually ways around this, depending on the application.

You mentioned using AO and DO - are you using the retriggerable finite pulse train as a clock for those? If so, you have another option, though it will take up additional resources: Single pulse generation only takes one counter. You can have a retriggerable single pulse train running, and use that to gate your AO sample clock - this will provide similar behavior, but since the AO sample clock is free running and not necessarily in sync with your trigger signal you could have a jitter of +/- a sample for each retrigger occurrence as well as some time jitter.

Another option would be to use the retriggerable single pulse as the sample clock for an AI task. Since AI acquisitions on M-Series boards are multiplexed, they use a sample clock and a convert clock (for Multichannel acquisitions). You can use the single retriggerable pulse as the sample clock, and then use the convert clock as the actual retriggerable pulses - which can be routed to the AO and DO sample clocks. This is assuming you aren't already using you AI for something else and unfortunately would limit the number of pulses to the number of AI channels on the device.

There may be other options based on why you need the retriggerable pulse train - what is is going to be used for? Also, please post back if you need more details on how to implement any of the options detailed above.

Cheers,

Andrew S   

Message Edited by stilly32 on 11-26-2007 11:04 AM

[henderd]

Hi Andrew,

Thanks for your quick reply, and apologies for my *very* slow one.  Yes - the retriggerable finite pulse train is used as a clock to drive the analog and digital outputs.  The analog output is a square wave (e.g. +5v, -5v, back to zero) used to drive motion of a piezo device.  The DO is a timing pulse for other devices.  What I didn't mention before is that I'd ultimately like the two to be tied together.  That is, on a specific distance interval (as measured by the position measurement), we want to trigger the series of analog and digital outputs.  It looks like I may be able to use one of your suggestions below, perhaps with a paired counter to get the spacing right.  Any additional help would be much appreciated, and meanwhile I am digging through the examples and documentation.

Thanks

Dave

[NI-Bongo]

Hi Dave,

Have you tried to implement any of Andrew's suggestions?  Let me know if you're having trouble getting any of them going.  Also, if you use the pulse train to clock the AO and DO, they should already be synched.  I may just not be understanding which signals you are trying to synchronize.

Here is an article on how to do retriggerable finite pulse generation with one counter that may work with your card as well, although I only tested it with a simulated M-Series card:

Using One Counter to Generate a Retriggerable Finite Digital Pulse Train with a PCI-6602 and DAQmx
http://digital.ni.com/public.nsf/allkb/4A9AF19480E50C6D862571B70058142A?OpenDocument

Let me know some more details about your application's specifics and I'll see what I can do to help.

[henderd]

Hi John,

My top-level requirement is to generate a series of synchronized analog and digital outputs at regular distance intervals while moving across a motorized stage.  The distance intervals have to be extracted from quadrature encoder signals (many encoder pulses per interval).  My original thought was to measure the stage position using an input counter configured for position measurement, and to somehow use the position to trigger the retriggerable pulse train that is used as a clock for the AO/DO.  Based on the information from Andrew and additional poking around, it now seems like a better idea would be something like this:

• Set up the first counter (i.e. ctr0) for position measurement using the A and B quadrature pulses as inputs
• Use the resulting counter pulses as a source for a second (output) counter (ctr1) that generates pulses at a slower rate (i.e. down-sample the position counter)
  
• Use the output of the 2nd counter as the sample clock for the analog and digital output, configuring the length and contents of the corresponding output buffers to give the desired repeat frequency

Using this approach, I wouldn't need to re-trigger the 2nd pulse train at all.  I don't really need direction information, so a simple pulse train would suffice, at least for the AO/DO signal timing.  The problem that I ran into implementing this approach is getting access to the ctr0 pulse train.   I expected this to be on Ctr0InternalOutput but did not see it.  Should it be possible to use the pulse train from a counter input application to act as a source for a 2nd (output) counter?  For now, I am using one of the encoder pulses directly as a source to the 2nd counter, and the AO/DO seems to be working fine.

By the way, thanks for this additional example.  I wasn't able to view it yet (we seem to have Labview 8 rather than 9), but I will see if I can take a look.  From the description, it looks like I would still need an external signal to gate the counter.

Thanks for your help and patience!

Dave

[NI-Bongo]

Hi again Dave,

Aittached is the VI saved for 8.0.  I know you’re working in C++, but maybe it will give you some ideas.  I believe it does require an external signal to gate the counter as you mentioned.

I am taking a look at your new idea to see if it will work.  Are you not able to get a pulse train from Ctr0InternalOut or is it that you are unable to route it to the source input of Ctr1?  I’ll see if I can make something similar work on my machine.

[henderd]

It turns out that I needed to call this function:

int32 DAQmxExportSignal (<taskHandle>, DAQmx_Val_CounterOutputEvent, <terminal name> );

to route the counter output event to the correct output terminal.  According to Counter Parts in NI-DAQmx in the C reference help, that route is made automatically for counter output applications, but not for counter input applications.  However, I still only get one pulse each time the counter reaches terminal count, rather than a pulse at each change of the counter value.   So for the time being, I am still using the A (or B) encoder input directly as the source for the second counter.

Thanks again
Dave

[NI-Bongo]

Hi Dave,

There isn't any signal on the internal or external output while the counter is configured for the linear position measurement by default.  Have you tried pulling the Ctr0Gate line up to digital high? That might pass the source to the Ctr0InternalOutput, but I have not yet tried it on my setup. That functionality of the counter may not work if the Linear Encoder task disables it for some reason.  I'll test it tomorrow.  From there you could try dividing down the source to get the sample clock you would like and add a trigger to this task.  Let me know if that helps.

[NI-Bongo]

Hi again Dave,

I did try putting the gate to high and I just get 5V from the output.  The gate should actually be configured to accept a Z input from the encoder, if one is used.  So it looks like we may have to try another approach.  Are either of Andrew's other solutions possible for you to implement?

[henderd]

Hi John,

I've been testing the system using the A encoder pulse as a source to the 2nd counter, and that seems to be working quite well for timing the analog and digital output signals.  Meanwhile, the first counter is configured for position measurement, and I can query the encoder position as needed from software to determine absolute position.  I think this will do the trick, at least for the short term.  Thanks again for all your help sorting out the options.

Best regards.

Dave