I'm back now; it's been a rough couple of weeks...
chrisb wrote: ↑Mon Nov 27, 2017 1:18 pm
I am not sure about the objective of your approach. If it is maximizing speed - as OP's issue was all about - or is it kind of smoothness or something else.
My attempt was at consistency. Think about the X-Y plane. On that plane, you're cutting with the "elliptical" solution every day and you don't give it a second thought. In the X-Y case, the ellipse simplifies to a circle so you're always using the same feed rate regardless of angle from X-axis.
chrisb wrote: ↑Mon Nov 27, 2017 1:18 pm
If it is about smooth start and stop we should think separately about it, because to pin down the acceleration in GCodes would heavily overload the GCode files.
Agreed. I'm not trying to manage acceleration; that's the machine's job.
chrisb wrote: ↑Mon Nov 27, 2017 1:18 pm
If it is about speed, please have a look at your Excel sheet, e.g. Xcut=20, Zcut=5. The contribs in X and Z directions are only half of their possible max values.
I agree the "linear" solution turns out very conservative -- i.e. always slower. I wouldn't use it, but it sounded to me like other's may. What the linear solution means is that the farther the tool is from horizontal or vertical motion, the more conservative it gets in feed rate. The notion of 'conservative' is probably too general; it would suck to slow down for a material like plastic -- it'll melt. Again, multiple people have pointed out, this needs to be configurable so the user can pick the best for their situation.
chrisb wrote: ↑Mon Nov 27, 2017 1:18 pm
I think that the error lies in what you call the linear approach. My solution is in fact not following the (blue) linear solution. In your terms it might rather be called a quadratic or rectangular solution, because the speed stays at the maximum of at least one direction. I have added it in magenta to your picture.
You are correct. I'm sorry I glossed over that part too quickly.
I didn't think of the magenta/rectangular solution because it seemed like the general desire was slower rather than faster. It'll be great if the limit is machine-induced and it's OK to feed faster. Again, think of the X-Y plane. It would be a surprise to most people to have feed rates varying based on angle -- up to sqrt(2) faster at 45degrees. That's how a G0 rapid works on my GRBL controller. In any case, it should be an option for the user.
I'll also address the fixed feed rate. That's OK too, but it puts the user at a bind in cuts where the ramp angle is changing. E.g. a helix drill that goes through multiple diameters. There is no one fixed feed rate for that given everything else we've discussed.
My vote is for options:
- Slowest (Pick Vx or Vz)
- Fastest (Pick Vx or Vz)
- Linear solution
- Elliptical solution (My vote for default)
- Rectangular solution
- Custom/Fixed rate
This should apply for any move where both X-Y and Z direction motion is mixed.