Hello Scuzzy,
One thing that would help you would be to expand your shift registers on the left hand side of your loop. Shift registers may be expanded to have multiple values. The top left shift register holds the value from the previous iteration and the one below it holds the value from two iterations ago and so on--it makes taking the difference between the previous values much easier. You should expand one shift register to hold the last two values you read on the Boolean input. This will allow you to compare the previous two values easily.
Since RPM is Rotation/Minute the goal is to obtain a measurement for a number of rising edges which correspond to the number of rotations and divide by the amount of elapsed time. You can convert the difference between the starting time and current time in ms to minutes by dividing by 60000 (you don?t need a shift register for this, just use one Tick Count (ms) VI before the loop and then subtract it from the Tick Count (ms) VI value from each iteration), and then you can divide the total number of revolutions (rising edges / 2) by this time to get RPM.
Since each loop iteration can only count either 0 or 1 rising edges it doesn't make sense to calculate the RPM each iteration--you need to count a number of rising edges and divide by the total time to average out inconsistencies. If your fan is not moving at a roughly constant speed then you'll need to change your current loop into a for loop that executes X times and then put that for loop inside of a while loop. This will allow you to average the RPM for X iterations and get a much more accurate count. You'll need to play with the number X b/c you're making a tradeoff between accuracy and time it takes to get the measurement. If your actual RPM value is changing quickly then if X is large you won't see these changes as clearly, however if X is small then you'll see the effects of jitter in your loop execution time since loops in a Windows environment don't necessarily take the same amount of time to execute each time they iterate.
Once again I want to stress that this is certainly a work around and counters are really the way to go. If you run this loop at 200 Hz then you'll have difficulty accurately counting all the rising edges of a digital signal that is near or larger than 100 Hz. If the digital signal is in sync with the loop then you can accurately measure 50% of your loop speed, but any faster than that and you will be losing rising edges for sure, and even if you're slower you'll still miss rising edges occasionally unless the incoming frequency happens to be an exact factor of the loop iteration rate (Note: the loop iteration rate when using software timing like this is not constant--Window's processes can and will interfere with VI execution) The reason for this is that since we're counting rising edges based off the digital input changing from 0 to 1 it takes at least 2 iterations to get 1 rising edge since after we get one rising edge we have to sample the signal at a low value before we can count another. Really I wouldn't be comfortable measuring a signal that was more than 10% of my loop rate--if the incoming signal is really that much slower than this may be a fairly accurate way to measure the frequency.
Have a good night,