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

[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.

[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.

[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. :smileysad:
-Kevin P.