Help Acceleration

Hello,

I'm debating with a problem concerning fast moves with mine 3D Printer (Prusa i3).

I've seen in reprap.org that, for example, the following code:

G1 F1500
G1 X90.6 Y13.8 E22.4 F3000

Will set a feedrate of 1500 mm/minute, then do the move described above accelerating to a feedrate of 3000 mm/minute.

However the current version of Merlin will use the new feedrate from the beginning of the move and not change it (http://reprap.org/wiki/G-code). Therefore does not take into account the acceleration. Or am I wrong?

Why change the values ​​of acceleration if this is not take into account?

if the direction of x and y axes were first set and in motion this would be true;

I think a lot of assumptions are on the first 5d code written 3 or more years ago. that was from point to point and acceleration was controlled for each line.

marlin uses velocity as part of its acceleration ramping, so if you are going the same direction most of this should hold true, if your asking if speed ramps up and continues to ramp up. marlins acceleration is velocity.

try this and see if the machine ramps speed. also you are limited by max speed in firmware.

G1 X0 Y0 F1500
G1 X10 Y1 F1500
G1 X90.6 Y13.8 E22.4 F3000

also ramp is quick as physics will allow, top speed is reached much sooner. the original 5d code peeked at center of line and then ramped back down at end of line to whatever the next line feed rate was at. this is slower as most ramping in acceleration happens within a few millimeters, rather than a long ramp of say 20 to 100 millimeters of one line.

read up on Constant acceleration [en.wikipedia.org]

Edited 1 time(s). Last edit at 08/11/2014 04:18PM by jamesdanielv.

Quote
jrosado
I've seen in reprap.org that, for example, the following code:

G1 F1500
G1 X90.6 Y13.8 E22.4 F3000

Will set a feedrate of 1500 mm/minute, then do the move described above accelerating to a feedrate of 3000 mm/minute.

What you describe is "RepRap-style acceleration". Firmwares in the Darwin and early Mendel timeframe did indeed work this way. It allows to do lookahead calculations on the host PC.

However, this very same firmware didn't have a movement buffer, so every time it completed one move it first had to wait for the next one to come in over the serial line. These short pauses often caused sudden motor stops. Instead of fixing the missing buffer problem, the big recommendation was to turn off acceleration altogether. There was no fix until firmwares with self-calculated acceleration came up (Teacup, Sprinter). If you're interested with experimenting, Teacup firmware still has this code inside, with some luck it still works. And it has a movement buffer, of course.


Regarding "what you found" ... if you see such descriptions, please add at least a note that they're outdated. Everybody is welcome to edit the wiki.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY