Monitoring the pulse generation

[radiumman]

Hi all,

I am using a USB-6210 card and measurement studio with VStudio2003. I would like to drive a stepper motor (which turns a miror in a spectrometer) by sending digital pulses to a motor driver. Using another channel on my card, i would also like to read a voltage (from an IR detector) every time i send 100 pulses to the stepper motor on the other channel. The purpose is to be able to log the voltage against the position of the motor.

I am not sure what the correct method is... I can think of different options :

1. Use \National Instruments\MeasurementStudioVS2003\VCNET\Examples\DAQmx\Counter\Generate Pulse\GenDigPulse + incrementing a variable that counts each time i send a single pulse. When the variable reaches 100, i take a reading. This concept is simplistic, however with this method i am concerned about having to often start/stop the task.
2. I have seen interesting examples in the following directories, using a continuous pulse train + counting digital events.
   
1. \National Instruments\MeasurementStudioVS2003\VCNET\Examples\DAQmx\Counter\Generate Pulse\GenDigPulseTrain_Continuous
2. \National Instruments\MeasurementStudioVS2003\VCNET\Examples\DAQmx\Counter\CountDigEvents\
• How can i integrate these two examples to be able to count the pulses?
  
• Shall I just physically connect the counter pin and the pulse generation pin on the connector block of my card?
  
• To decide whether the motor has arrived to the aimed position I could use the a "counting class" to drive (=start/stop) a "pulse generation class" ?
• However the counting methods are driven by a Timing function (which runs every 50ms max), so i will always end up being slightly over positionned because of the lag time of the OnTime method? (i guess it doesnt really matters, as long as i know where i am)
  
3. Use a finite pulse train. This imply using my two counters and then i would not be able to know where my motor is if the software was to end prematurely.

Let me know if you have any suggestion, it will be very much appreciated!

Thanks
Laurent


Message Edited by radiumman on 02-15-2008 07:56 PM

Message Edited by radiumman on 02-15-2008 07:58 PM

[radiumman]

another solution would be acquiring a voltage on an external clock using the option number 3.


Does anyone know what is the right option??
   

[DanBrowne]

Hi,

What time period are the 100 pulses apart? I would suggest going for the most basic option (number 1) if the pulses are not too close together, and then once you have that stable and working reliably, perhaps moving to a more processor efficient method of monitoring the position. How critical is this project? Are you looking more towards a solution that will work quickly, or a solution that is more elegant? I will get back to you with more information if necessary, once I have looked into this in some more depth.

Regards,

Dan - Applications Engineering, NIUK

[radiumman]

Thanks for your interest Dan.

We would actually take a reading about every 5 pulse i imagine. We would be driving the motor at max 600Hz (extreme worst case would be 2000Hz = stepper motor driver input max frequency). With option number 1 how can i make sure we drive it to the right speed ?

I have to say i like option nb 3. If i am going this way, can i use both

• the GenDigPulseTrain_Continuous example from the NI example library. To change this example into a finite pulse train, i believe i would need changing the following line m_task->Timing.ConfigureImplicit(DAQSampleQuantityModeContinuousSamples) into m_task->Timing.ConfigureImplicit(DAQSampleQuantityModeFiniteSamples, 1000) ?
• the AcqVoltageSamples_ExtClk example from the NI example library, adding the following line m_task->SetSampleClockTimebaseRate(5); to specify that i want to take a reading only every 5 pulses ?

I haven't bought that USB6210 card yet. Is it going to comply with what i want to do?

Thanks again,

Laurent

[Kevin_Price]

Dunno about the rest of the motion system, but steppers will tend to give you some noticeable vibration superimposed on the average speed.  The dominant freq is likely going at the step rate due to the torque impulses. 

For circumstances where you don't want to see that vibration, you should derive the analog sample clock from the step pulses.   This will tend to filter out all of the step response vibration -- much like sampling a sine wave at exactly the sine wave's freq, which just looks like DC.

On the other hand, perhaps you *do* need to be aware of how much vibration is being superimposed on your nominal motion.  In that case, you should sample at ~10x or more of your step rate, and you'll see a much noisier looking response.

Now, other things:

1. It's pretty straightforward to use your step pulse as an external sample clock and take readings on every step.  Personally, I'd start this way rather than trying schemes that sample on every 5th pulse.  You can always discard or ignore 4/5 of the samples later in post-processing if you wish.  (Aside: I know the older driver that isn't compatible with M-series boards had a method allowing you to specify an integer divisor of an external timebase for analog sampling.  I've never explored whether that capability is available under DAQmx.  If so, that'd be the cleanest implementation to use.)

2.  I agree that you should track your commanded position with 1 of your counters.  I would also recommend some kind of method for repeatably establishing a reference ("home") position somewhere.  If the system has been designed and spec'ed well, commanded steps should reliably produce actual steps of motion.  If not, then maybe not, and you'll need to verify or re-establish home now and again.

3. If 1 counter is tied up with counting steps, the other counter will need to do continuous generation.  You won't be able to move exact distances because you'll need to issue software-timed task stoppages.  But since your other counter is counting pulses, you'll at least know where you *did* stop.

4. A possible sneaky trick idea if you can get a DAQ device with analog output.  If you can route the AO task's sample clock to one of the PFI terminal pins, you could generate exact #'s of step pulses with a finite AO task.  Then 1 counter can count the pulses and the other counter could, if you choose, divide by 5 to create an AI sample clock.

Hope these ideas help.  Sorry, I'm only a LabVIEW and hardware user and have nothing to offer on syntax.

-Kevin P.