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

[whydontu]

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

?? so after 20 cycles with the extend stroke longer than the retract stroke the ram falls off the end of the frame? <grin>

 

[Susquatch]

My original rpm meter methodology works independently of the stroke length and is dead nut simple... just sayin.

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.

 

[Former Member]

 

[Susquatch]

mildly flogging a dead horse

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.

 

[YYCHM]

Haven't given up on this yet....




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?

 

[whydontu]

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.

 

[Former Member]

Haven't given up on this yet....

View attachment 19691


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?

OCD? And too much free time?

 

[Susquatch]

OCD? And too much free time?

Bad case of it too. Almost as bad as me.

Doubt he has any free time though. The older we get, the less of that we have. Life turns into choosing our priorities instead.

 

[YYCHM]

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

 

[YYCHM]

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.

Craig

 

[YYCHM]

Fab'd up a bracket and mounted the US sensor on the shaper.....



That helped a lot to settle down repeatability.



40 and -57 FPM doesn't give an average of 54 FPM though

The code boiled down to this....

--------------------------------------------------------------------
const int pingPin = 7; // Trigger Pin of Ultrasonic Sensor
const int echoPin = 6; // Echo Pin of Ultrasonic Sensor

// Include the library:
#include <LiquidCrystal_I2C.h>
#include <NewPing.h>

// Set the LCD address to 0x27 for a 16 chars and 2 line display
LiquidCrystal_I2C lcd(0x27, 16, 2);

#define MAX_DISTANCE 60

NewPing sonar(pingPin, echoPin, MAX_DISTANCE);

// Create variables
float c_cm = 0.0;
static float p_cm = 0.0;
float d_cm = 0.0;
unsigned long c_ms = 0;
static unsigned long p_ms = 0;
float d_ms = 0.0;
float d_sec = 0.0;

float cps = 0.0;
float fpm = 0.0;

static float maxfwdfpm = 0.0;
static float maxrevfpm = 0.0;
float dispfpm = 0.0;

float c_dur = 0.0;

void setup() {
Serial.begin(9600); // Starting Serial Terminal

lcd.init();
lcd.backlight();
lcd.clear();
lcd.setCursor(0,0);
lcd.print("FWD FPM ");
lcd.setCursor(0,1);
lcd.print("REV FPM ");
lcd.setCursor(0,1);

pinMode(pingPin, OUTPUT);
pinMode(echoPin, INPUT);
}

void loop() {

c_dur = sonar.ping_median(5);
c_cm = microsecondsToCentimeters(c_dur);

if (c_cm > 0)
{

if (abs(c_cm - p_cm) <= 0.3) p_cm = c_cm;

d_cm = c_cm - p_cm;
c_ms = millis();
d_ms = c_ms - p_ms;

d_sec = d_ms / 1000.0;
cps = d_cm / d_sec;
fpm = (cps / 30.48) * 60.0;

bool fwdfpm = false;
bool revfpm = false;
bool zfpm = false;

if (c_cm > p_cm)
{
fwdfpm = true;
if (fpm > maxfwdfpm) maxfwdfpm = fpm;
dispfpm = maxfwdfpm / 2.0;
}

if (c_cm < p_cm)
{
revfpm = true;
if (fpm < maxrevfpm) maxrevfpm = fpm;
dispfpm = maxrevfpm / 2.0;
}

if (c_cm == p_cm) zfpm = true;

if (fwdfpm)
{
lcd.setCursor(8,0);
lcd.print(" ");
lcd.setCursor(8,0);
lcd.print(round(dispfpm));
}

if (revfpm)
{
lcd.setCursor(8,1);
lcd.print(" ");
lcd.setCursor(8,1);
lcd.print(round(dispfpm));
}

if (zfpm)
{
// maxfwdfpm = 0.0;
// maxrevfpm = 0.0;
// dispfpm = 0.0;

lcd.setCursor(8,0);
lcd.print(" ");
lcd.setCursor(8,0);
lcd.print("0.00");
lcd.setCursor(8,1);
lcd.print(" ");
lcd.setCursor(8,1);
lcd.print("0.00");
}
}
else
{
// maxfwdfpm = 0.0;
// maxrevfpm = 0.0;
// dispfpm = 0.0;

lcd.setCursor(8,0);
lcd.print(" ERROR ");
lcd.setCursor(8,1);
lcd.print(" ERROR ");

}

p_cm = c_cm;
p_ms = c_ms;

} //loop


float microsecondsToCentimeters(long microseconds) {
return ((microseconds / 29.0) / 2.0);
}
--------------------------------------------------------------------

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

 

[Susquatch]

40 and -57 FPM doesn't give an average of 54 FPM though

I don't think it will ever average out @YYCHM. The time is also different for both halves.

 

[YYCHM]

I don't think it will ever average out @YYCHM. The time is also different for both halves.

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

 

[whydontu]

I would suggest that peak fpm is the only concern. Peak is what breaks tools and trashes finishes.

 

[Susquatch]

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.