Ccounting 3 different signals with up to 20.000 min-1 motor revolutions per minute - PCI-6601 or PCI-6602 or what ?

[hemmerling]

Hello,
for a project we must determine the proper hardware.

So we need to count 3 different signals with up to 20.000 min-1 (motor )revolutions per minute.

Is PCI-6601 sufficient, or do we need PCI-6602 ?

From my point of view, I calculate
20.000 min-1 * 60 sec = 1,2 Mhz

I am unsure about, because the NI website claims

PCI-6601
Highspeed data transfer on  *ONE* DMA channel
http://sine.ni.com/nips/cds/view/p/lang/de/nid/12787

PCI-6602
Can do *THREE* Highspeed data transfers at at time
http://sine.ni.com/nips/cds/view/p/lang/de/nid/12785

Do I need this highspeed data transfer at all for just counting the speed of a motor ?

Especially with a standard PC, which additionally must interface a cDAQ system
or alternatively one or two PCI cards for instrumentation,
is it a good choice to let calculate the (motor )revolutions per minute. with such a card ?

This calculation of the motor speed should not be a burden for the PC.
Sincerely
Rolf

[Kevin_Price]

1. I'm not sure I'm understanding your units.  Are you saying there's 20 thousand per minute of something, maybe 20 thousand revolutions per minute?  Or maybe "min" stands for something other than "minutes?"   What kind of signals are you counting?  Are they encoders or are they simple little 1 pulse per rev?

If 1 pulse per rev, I suspect you've got your calcs backwards.  You'd only be looking for (20000 / 60) = 333 1/3  rather than 20000 * 60.

2. Data transfer rates are important for buffered measurements where the hardware tries to measure every single time interval.  Some apps don't need to perform buffered measurement.  They would just use software to regularly poll a single time interval measurement.  Is that an option for you?

-Kevin P.

[hemmerling]

Hello,
20.000 revolutions per minutes,
means of course
20.000 / 60 = 333 1/3 revolutions per second
ups, sorry for that blackout.

The signal of a "spindle device which measures the torque"
is described
"Open Collector ( 15 Ohms in series ), max 30 VDC,  short circiut - safe"

The ONLY thing we need to know is the speed in revolutions per minute,
the signal itself is not used any further,
so we need no action after each revolution,
so we just need an average speed value, in Labview.
The motor is always running, its NOT a stepper motor.

May the driver of the 6602 or 6601 calculate that value automatically, and may provide it as service to Labview ?

Or do we need to handle the signal in Labview and count there ?

As I said, we have to handle the signals of 3  motors ( i.e. 3 x revolutions per second to calculate ).

Sincerely
Rolf

Message Edited by hemmerling on 01-16-2007 11:07 AM

[Jochen]

The PCI-6601 should be ok for this task. DMA transfer is only needed for high speed buffered operations (e. g. if you want to transfer a counter's value to the PC's memory each time an external trigger signal occurrs). But even in this scenario you can use buffered operations for each counter on the board. With the PCI-6601 one counter could use DMA to transfer the data to the PC's memory without an impact to the CPU while the others could use IRQs for the same task. In contrast to DMA, IRQ transfers add some load to the CPU. Thus buffered operations with IRQ data transfer are limited in their data rate compared to DMA.

For your application the number of DMA channels should be irrelevant as I don't see a need for a buffered operation. You should be able to measure the frequency of your three signals with a PCI-6601.

I hope that helps,

Jochen

[Kevin_Price]

I'd agree with Jochen -- you could do unbuffered period measurements on the 3 signals.  Each time you want to query speed, you would just start the tasks and then read the result.  (I'm not certain if you'll need to explicitly stop the tasks or whether they are already stopped after producing the measurement).  At your speed, the measurement should be done within 3 to 6 msec.

One small caution: if you query fairly rapidly and chart the speeds, you might see crazily erratic looking variations.  Real-life motion systems typically have a few characteristic frequencies of speed variation.  Think of them as small sine waves & their overtones superimposed on your flat speed response.  A true high-speed capture would show a speed response representing the sum of all these contributions.  It would osciallate about the nominal speed, but the oscillations would look fairly smooth.

In your app, the speed snapshots you take will not be in sync with the system at all.  Your sampling rate will not be constant since it's software-driven and will not be fast enough to avoid aliasing.  The net effect is that you will take sort-of random samples out of the true response, so any chart you make will appear to have a sharp jagged trajectory.  As long as you're aware ahead of time, you'll know not to believe it.

-Kevin P.

[hemmerling]

Hello,

the "alternative" is to use a simple
display device for torque, frequency = revolutions per minute and consumed power,
by the manufacurer of the torque measurement device,
which can report by RS-232 with 115.200 bps to Labview, if asked by GPIB like commands.

So thanks for the comments.

Sincerely
Rolf

[Kevin_Price]

If you just need a measure of steady-state speed / torque, you should consider querying data serially.  The mfgr will probably have some filtering between the raw signal and the serial stream, so you'll get a less erratic looking signal.  There's a decent chance that the filter will even be configurable.

Just be very careful about serial port settings and any special characters to mark end-of-transmission.  Communication can be pretty simple if you've got good docs, but not nearly so simple with not-so-good docs.

-Kevin P.