2. speed: you must specify the sampling rate for Reading Incremental Encoder. You can say for example 10kSamples/second. If Sample[n] = 110 increments and Sample[n-1] = 100 increments. Then you have: 10 increments * 10k / second. 100k increments / second. If an increment is 0.001mm you have 100mm/second. <<<--- See my previous post. Use Sampling Clock vi.
On a side note, (granted I have mostly used a quadrature encoder and FPGA), I find sometimes that if your time slice is too long it makes the screen update look crummy. For example, if you are only sampling your count every 1 second, the RPM or velocity indicator can make what looks to the user like large jumps if your are accelerating quickly. You don't get a smooth feel to changes in velocity. For example, think about your car speedometer. It obviously doesn't update only 1 time every second! It has a very smooth transition as you accelerate. What I have recently found to work quite well is you can shorten the sample time. The only problem with this is you will get less counts with each sample, and less counts can mean each small fluctuation in count effects your RPM more. In order to compensate for this you can use an IIR filter (I think this is in the LabVIEW base package) which will smooth out any bouncing around in your velocity calculation.
There, that was clear as mud.
Also, be careful when you choose what to use as your clock for the time slice interval for which you are counting pulses over. A Windows OS is not going to be deterministic which may cause fluctuations in RPM that aren't there if you are using PC time to calculate your timeslice.