I wish you'd have shown your work in that first post because I get a different result. I'll assume the methodology to derive the 52 forward strokes per minute is correct because it was likely from direct observation with a stopwatch.
6.25 inches/stroke x 52 strokes/min = 325 inches per minute
325 inches/min divided by 12 inches/ft = 27.08 feet/minute
6 inches is almost precisely 0.5 feet so you should have been able to see that the result should have been approx. 26 FPM.
Concerning your results at the shaper, the number of forward and reverse strokes MUST be equal. The travel on the forward stroke is LONGER than the reverse stroke based on the configuration of the bull gear linkages.
EDIT: I made a mistake I will correct here.
Ergo IF you calculate the results for both strokes the reverse FPM will be approximately twice the forward speed, due to the shorter stroke length.
If you were not getting such numbers you'd have a fundamental error somewhere in your calculations, program or hardware
I originally started with the idea of using an rpm measurement too. And like you I figured it couldn't get easier.
But I don't have a shaper so I listened to the requirements that @YYCHM established which dictated that he wanted to differentiate between the extend and retract velocities which can vary significantly. So a direct rpm readout won't satisfy that requirement. He is the user so he gets to decide if it is good enough or not - although I might try and convince him to the contrary.
Trying to stick with the simple rpm approach, I volunteered to do the complex math to translate the rpm into velocity. He sent me an article to explain the geometry so I could do that for him. To my disappointment, the article also did the math for me.
Then I realized that it would be better to just measure the velocity directly. Hence our exchange.
All that is not to say that I disagree with you. The rpm measurement is the simplest of all to do. But it might be too simple if a more accurate discernment of ram velocity between extend and retract is required. In that case, I believe it is easier to measure the velocity directly.
Ps - we all have to laugh at ourselves sometimes. I try to be humourous in the way I say things, but it might not always come across that way.
This is such a cool way to say it! I'm gunna remember that saying and shamelessly use it.
I do love the way you think.
I think I am coming around to your way of thinking about this.
The rotary encoder is a nifty way to handle the adjustments that @YYCHM needs to make and does turn the true linear velocity into an easy to measure signal. It needn't be too complicated.
Have everything in an enclosure now. Got smarter this time and created a port to allow a USB cable to be connected to the NANO without opening the box.
Also, I removed all my distance averaging logic (probably wasn't appropriate in the first place since the ram is in constant motion) and checked the shaper again. This time I got 92 peak fpm fwd and 120 peak fpm rev. Maybe try averaging fpm next?
Jeez, you real coders do stuff I never think of. Nothing I've ever written prints out error messages. Usually they just let out the magic smoke, or the readout shows something impossible.
Have everything in an enclosure now. Got smarter this time and created a port to allow a USB cable to be connected to the UNO without opening the box.
Also, I removed all my distance averaging logic (probably wasn't appropriate in the first place since the ram is in constant motion) and checked the shaper again. This time I got 92 peak fpm fwd and 120 peak fpm rev. Maybe try averaging fpm next?
As I was starting to doubt my sanity, I backed up and programed the nano to provide the total feet the ram travels in 30 sec. Low and behold it came up with 27 which matches my manual measurement of 52 FPM. I also came to the realization that the peak instantaneous velocity I was seeing is probably correct. 86 fpm fwd, 120 fpm rev, hence to translate that to an average you have to divide it in half, 43 fpm fwd, 60 fpm rev which gives a overall average of 52 fpm. Now to see if this is repeatable........... OR maybe make some chips instead, this project is getting stale....
Looks like a lot of my confusion was self inflicted..... I was holding the sensor by hand behind the ram and any tilt or shift can pick up an extraneous reading that is forever trapped in the peak FPM variables. I've added some additional initialization and should probably implement a periodic initialization. A fixed sensor mounting arrangement is the next step.
It will track increases in FPM but not decreases AND somehow every once in a while it will jump into the 0 FPM code with the shaper running steady state. Can't for the life of me figure how to code around that.....
It's kind of a hard one to get one's head around. Each fwd/rev stroke involves acceleration and deceleration and the rate fwd is different from that of rev. I questioned whether or not averaging was valid in this case. I should be seeing something like 68 fpm on the rev stroke to make the average work. On the other hand maybe peak FPM is the real value that matters? In this case it would be 80 fpm fwd and 112 rev (not that rev matters).
It's kind of a hard one to get one's head around. Each fwd/rev stroke involves acceleration and deceleration and the rate fwd is different from that of rev. I questioned whether or not averaging was valid in this case. I should be seeing something like 68 fpm on the rev stroke to make the average work. On the other hand maybe peak FPM is the real value that matters? In this case it would be 80 fpm fwd and 112 rev (not that rev matters).
I'm not sure what you really have. So I'm maybe not as much help as I could be otherwise.
Just laugh if the rest of this is already obvious to you.
The best way to get a quick idea of what it should be would be to find out what it is for the total first. Change the sign for the reverse stroke so both are positive. You just want an average velocity. Doing so, is basically just the stroke length x2 per total time for one cycle. Then assume each half of the cycle is the same as that overall average biased by the leverage ratio of the drive arm. Obviously reverse will be faster. You can prolly get close by just taking the arm ratios. Or get dead-on using the math in that article you provided for me.
The objective is to get some close numbers that will help you determine if your US system is reliable or not.