• Scam Alert. Members are reminded to NOT send money to buy anything. Don't buy things remote and have it shipped - go get it yourself, pay in person, and take your equipment with you. Scammers have burned people on this forum. Urgency, secrecy, excuses, selling for friend, newish members, FUD, are RED FLAGS. A video conference call is not adequate assurance. Face to face interactions are required. Please report suspicions to the forum admins. Stay Safe - anyone can get scammed.

Someone check my math please.... Arduino Shaper Ram FPM Sensor

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. Ergo IF you calculate the results for both strokes the forward FPM must exceed the FPM of the reverse strokes.

If you are not at least getting such numbers you have a fundamental error somewhere in your calculations, program or hardware

I counted the number of times the ram struck my hand over the course of a minute, so total forward strokes. 27 FPM is what everyone else came up with as well. My Arduino implementation appears to be recording a value that is too high IMHO. Mind you maybe it's not, I'm recording peak velocity. The ram is accelerating and deceleration through a stroke.
 
Last edited:
Just a reminder the only one you should be using is the forward stroke as this gives you the ipm you need, factoring in the reverse changes this value. Using the reverse value in the equation is for calculating the working time which is dependent on both, better is to use a full cycle count & time for that.
exactly, count the total cycle at the bull gear in rpm. Calculate forward stroke time as a percentage of the time for one full revolution/stroke cycle
 
Just a reminder the only one you should be using is the forward stroke as this gives you the ipm you need, factoring in the reverse changes this value. Using the reverse value in the equation is for calculating the working time which is dependent on both, better is to use a full cycle count & time for that.

I'm only recording rev FPM out of curiosity.
 
I counted the number of times the ram struck my hand over the course of a minute, so total forward strokes. 27 FPM is what everyone else came up with as well.

I'm only recording rev FPM out of curiosity.

I expected as much on the count methodology. That is as direct observation as you can get and as effective as a hall effect sensor. Unless you suffer a stroke while observing things.

That you did record the fpm speed in reverse is helpful too because it helps identify any potential issues. What I really want to know if what the shaper set-up was when you took the readings.

The short form calculation that everyone got 27 fpm is not at all accurate, while the long form is.

The long form calculation of your original set-up is"

L x 60 x spm / divided by 40 = the inches per minute cutting speed

Where L is the total length of the stroke the user enters

60 is the number of seconds in a minute

spm (strokes per minute) is the observed rpm hand count

40 is the number of seconds in a minute that the shaper is taking the forward stroke.

So the more accurate result is

6.25 x 60 x 52 spm / 40 = 487.5 IPM
487.5 IMP / 12 Inches/feet = 40.62 FPM forward speed much faster than the simplified calculation


The speed in the reverse stroke is as follows:

6.25 x 60 x 52 / 20 = 975 inches per minute
975 IPM / 12 IPF = 81.25
 
This is interesting. That's close to the mean of my recorded 77 if you consider the ram is accelerating from zero to peak, how ever I don't think the velocity curve is linear.

Nope, your velocity curve will not be linear in either the positive or negative direction. I don't believe that linkages are set up for harmonic motion
 
This is all the reason why I advocate measuring the linear velocity of the ram itself across a section of the middle of its stroke - the working portion.

Although I love math and love all the complexities of this mechanism. I don't see any reason to complicate the matter needlessly.

We want to know the cutting speed right? So measure the cutting speed and skip the math. It's also very easy to do. KISS.

There is no need to worry about encoders, bull gear speed, gear math, geometry math, acceleration and deceleration, averaging, short stroke, long stroke, etc etc etc. Just measure the velocity of the ram during the working portion of its shortest stroke and you are done. Easy Peasy.
 
This is all the reason why I advocate measuring the linear velocity of the ram itself across a section of the middle of its stroke - the working portion.

Although I love math and love all the complexities of this mechanism. I don't see any reason to complicate the matter needlessly.

We want to know the cutting speed right? So measure the cutting speed and skip the math. It's also very easy to do. KISS.

There is no need to worry about encoders, bull gear speed, gear math, geometry math, acceleration and deceleration, averaging, short stroke, long stroke, etc etc etc. Just measure the velocity of the ram during the working portion of its shortest stroke and you are done. Easy Peasy.
except that it is far harder to accurately measure the linear speed of the portion of the ram during the forward cutting stroke.

my proposed methodology requires minimal effort (entering one number) and relies on technology that and coding that is literally child's play. If I had any I'd ask my grandkids to code this for me.
 
Just measure the velocity of the ram during the working portion of its shortest stroke and you are done. Easy Peasy.

I can't use two fixed points on the ram to measure by because the ram can be adjusted for stroke (0-8") and position on the bed (about 6" of fwd/rev adjustment). I am attempting to measure ram velocity in it's simples form dx/dt. The US sensor provides dx and the Arduino clock provides dt, should be Easy Peasy.........
 
Last edited:
I can't use two fixed points on the ram to measure by because the ram can be adjusted for stroke (0-8") and position on the bed (about 6" of fwd/rev adjustment). I am attempting to measure ram velocity in it's simples form dx/dt.

Hmmmm. Nothing in the article you provided said anything about zero stroke or fwd/rev adjustment. That does complicate a simple velocity measurement.

But yes, I agree that what you want is dx/dt. And that is what I proposed. However, your additional adjustments throw a monkey wrench into the design parameters I thought you were working with.

Obviously, a stroke of zero has no velocity. So is there a reasonable minimum stroke?

And could your fwrd/rev adjustment be accommodated by an adjustable or moveable scale?
 
And could your fwrd/rev adjustment be accommodated by an adjustable or moveable scale

Never quoted myself before.....

@YYCHM - After a moments thought, I don't think an adjustable scale is a good idea. It would have to be recalibrated too. However, I think that a moveable scale would be perfect. The idea would be to move the scale to follow the fwrd/rev adjustment, but keep the spacing and hardware intact (just relocated) so no re-calibration is required.
 
Hmmmm. Nothing in the article you provided said anything about zero stroke or fwd/rev adjustment. That does complicate a simple velocity measurement.

But yes, I agree that what you want is dx/dt. And that is what I proposed. However, your additional adjustments throw a monkey wrench into the design parameters I thought you were working with.

Obviously, a stroke of zero has no velocity. So is there a reasonable minimum stroke?

And could your fwrd/rev adjustment be accommodated by an adjustable or moveable scale?

Ya, a movable scale arrangement could be made I guess, seems complicated for something so simple though. Might as well just make a graph and be done with it.

The zero stroke setting scared the hell out of me the other day. I was adjusting the stroke length and managed to take her down to zero. Started the machine and nothing but a turning motor. Panic set in.... what the hell have I broken?
 
Ya, a movable scale arrangement could be made I guess, seems complicated for something so simple though. Might as well just make a graph and be done with it.

Well, I was going to support other suggestions to do that but I knew you wanted a readout so I resisted the temptation. I like simple graphs. There are quite a few posted around my shop.

My eyesight isn't that good anymore so the axis of a graph isn't always easy to read. But I can still interpolate in my head pretty easily so simple charts work well for me too.
 
Well, I was going to support other suggestions to do that but I knew you wanted a readout so I resisted the temptation. I like simple graphs. There are quite a few posted around my shop.

My eyesight isn't that good anymore so the axis of a graph isn't always easy to read. But I can still interpolate in my head pretty easily so simple charts work well for me too.
My original rpm meter methodology works independently of the stroke length and is dead nut simple... just sayin. ;)
 
mildly flogging a dead horse

a rack, a gear, a rotary encoder. Known pulses per foot. Rotary encoder can distinguish between cw and ccw rotation.


possible interesting side effect would be the chance to use the shaper to make a gear rack
 
mildly flogging a dead horse

a rack, a gear, a rotary encoder. Known pulses per foot. Rotary encoder can distinguish between cw and ccw rotation.


possible interesting side effect would be the chance to use the shaper to make a gear rack

Yes this will also work. But requires more mounting effort than a hall sensor without gaining significant advantage other than to make a rack and implement a non-typical arduino project becoming the envy of the interwebs
 
Back
Top