motor + pulse train

[paulak]

Hello All and happy new year,
 
I have LabView 7.1, NIDAQmx 8.3 and a PCI-6281 M serie card.
 
I am trying to drive a motor and read the encoder counts. Basically I would need to send a ramped pulse train (accelerating frequency till a given frequency (say 1kHz) and then decelerating) to drive the motor. In parallel, I have to count the pulses sent by the encoder.
 
My problem is the following:
The PCI-6281 card has only 2 counters so if I generate a finite pulse train I use the 2 counters of the board therefore I cannot count the encoder with anyother counter. I tried to use the DO (software timed) to generate the finite pulse train to drive the motor but this doesn't work properly. I saw that there is a possibility to count pulses with synchronised DO with M series board, but unfortunately using LabView 8.
 
My question:
What is the best solution to send a finite pulse train to my motor and (in parallel) count the pulses sent by the encoder, taking into account my system configuration? 
 
Thank you for your help,
 
Polak

[Kevin Price]

For a finite ramping pulse train, I'd definitely recommend using correlated DO.  You'll have to pre-define a fairly large buffer for the DO bit that will generate a pulse train.  You can use 1 counter to generate a pulse train that acts as the "sample clock" for the DO task.  (In a pinch, you could save this counter by creating a dummy AO task that continuously generates 0 volts, and then using the AO clock as the DO sample clock).
Your other counter can now read the encoder position.
There are several options for syncing the two, depending on your needs.  Here's a brief outline of the basic ideas:
1. A simple one would be to use the same sample clock signal for your encoder position measurement that you used for your DO task.  This will probably produce a lot of redundant data, but will give you a look at system dynamics.  
2. Another way is to wire the DO bit to a PFI line and use the PFI line as the encoder position sampling clock.  That would give you one encoder measurement per step command and greatly reduce the quantity of data collected.  I've found that sync'ing the encoder measurement to the step command signal this way does a lot to "filter" out the step response dynamics and produce a nicer-looking overall curve.  However, you must remember that the data is *not* equally-spaced in time -- it's equally-spaced in position.
3. You can wire the DO bit to a PFI line and then count edges on that PFI line.  You could then use the dummy AO task idea to generate a preferred sampling clock rate, and sample both the encoder position and step command edge count with the AO sample clock.
I can vouch for the M-series boards under LabVIEW 7 -- they definitely DO support correlated DIO.  Starting with DAQmx 8.0, they also support "change detection" as a means for hardware-syncing and sampling.  However, as outlined above I'd use the DO to *generate* the pulse train while using a counter to measure the encoder.
-Kevin P.

[paulak]

Kevin,
Thanks to your recommandations, I have now managed to generate the pulse train through a DO (using counter0 as the sampling clock for the DO task) and read the encoder with the remaining counter (counter1).
I now want to send not a simple pulse train but a pulse train that will increase its frequency up to a certain frequency and then decrease its frequency again (trapezoidal velocity profile for the motor). Do you know how I could do that properly with the DO solution I described above?
Best Regards,
Polak


generate_PT_DO.doc:
http://forums.ni.com/attachments/ni/70/6130/1/generate_PT_DO.doc

[Kevin Price]

Only have time for a couple quick hints and tips:
 
1. Be prepared to create a pretty big DO buffer.  The frequencies that are actually possible to generate will depend on the freq of the sample clock pulse train you create.   This is a little easier to demonstrate by talking instead about the step periods, defined as 1/freq.
   You'll define the step periods based on how many samples are in the DO buffer between rising edges.  This # will necessarily be an integer, so you can only generate step periods that are integer multiples of the sample clock period.  Thought experiment: suppose the sample clock is 100 kHz for a period of 10 usec.  You will be able to generate step periods that are 20,30,40,50,... usec.   Near your target of 1 kHz, you can generate a period of 1000, 1010, 1020, ... usec.  These correspond to step freqs of 1000.0, 990.1, 980.4 Hz.
   If this resolution is sufficient, you'll now need to create a buffer containing 100 thousand samples per second of motion.  If you need better frequency precision, you'll need a faster sample clock and a larger buffer.
 
2. Most of the DO buffer will consist of long stretches of identical samples with relatively rare transitions that define the step pulses.  There's a chance that the digital waveform datatype *may* help to compress this information, but I couldn't say for sure.  I personally always use raw arrays because I can manipulate them and interpret their contents directly, so I just haven't played around with the digital waveform.
 
3. Supposing there's 1 second of motion with a sample clock at 100 kHz, here's what I'd do:
a. Initialize an array of 100 thousand Booleans set to False to represent a 1 second buffer.
b. Come up with a ramping algorithm that defines where all the step times are within that second.
c. For each step time, locate the corresponding index into the Boolean array and write several consecutive True values using "Replace Array Subset".  (The reason for several consecutive True values is to meet the requirements many drivers have for minimum step pulse width.)
d. Write the final result into the DO buffer using DO Write and then start the Task as needed.
 
-Kevin P.

[paulak]

Kevin,
Thanks a lot for your advice. It was really helpful!
Best Regards,
Polak