Why is acceleration being done in firmware?

> I guess it would make sense then that the
> look-ahead acceleration is what seems to improve
> the situation. Any chance this awesome feature
> could be ported to other firmwares?


Its actually from GRBL [dank.bengler.no] which is for CNC other than RepRap but is just the original RepRap firmware worked over to have curves, acceleration and look ahead. But they dropped all the RepRap specific G and M codes. And since sprinter is based on the original tonokip firmware which was based on the original RepRap firmware it must have been fairly easy to create Marlin. So it is implemented in sprinter in that sense.

But Teacup is another firmware entirely and the developers goal is to have look ahead but it may be part of SoupCup instead because Teacup is designed to be small so it uses integer math only (no floating point).

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

So the way ramp acceleration is implemented, if there are two moves back to back where the direction doesn't change, will it slow down between these moves? If it does, then that is wrong because it would result in blobs. The reason for the blob is the extruder control is not as good as the control in movement of the axes (x, y and z). The extruder that we use can't stop and start as well and so it results in excess plastic where it pauses.

Obviously, if the change in direction is large, for example 180 degrees, then the carriage or bed need to slow down to 0 and then speed back again. The problem is how to decide when to use acceleration and when not to use it when it's somewhere in between the two extremes. This would probably be better implemented in the host while preparing the g-code when you have more time than in the firmware while running the printer in realtime.

BTW, one of the negative effects of acceleration is that the build times are much longer than what Skeinforge calculates since the feed rate averages out to be slower than what it should be. It also doesn't seem right that the firmware is not executing the command it receives, and is at liberty to change it.

brnrd Wrote:
-------------------------------------------------------
> So the way ramp acceleration is implemented, if
> there are two moves back to back where the
> direction doesn't change, will it slow down
> between these moves?

Yes it slows down because it has no look ahead.

If it does, then that is
> wrong because it would result in blobs. The reason
> for the blob is the extruder control is not as
> good as the control in movement of the axes (x, y
> and z). The extruder that we use can't stop and
> start as well and so it results in excess plastic
> where it pauses.

Again Marlin has extruder advance which should be able to compensate for this effect. But as far as I know it only works on the Gen6 optimized version of Marlin.

>
> Obviously, if the change in direction is large,
> for example 180 degrees, then the carriage or bed
> need to slow down to 0 and then speed back again.
> The problem is how to decide when to use
> acceleration and when not to use it when it's
> somewhere in between the two extremes. This would
> probably be better implemented in the host while
> preparing the g-code when you have more time than
> in the firmware while running the printer in
> realtime.

This is how RepRap style acceleration works. But the only host software that creates code for it is the Java RepRap host. It only accelerates or decelerates when the gcode changes speeds. An f60 move followed by an f1200 move results in an accelerated move and a f1200 move followed by an f60 move results in deceleration. This is why the RepRap firmware tries to move the Z stage at full speed when using Gcode created by anything other than the Java host. The java host sets the speed lower the move before so it has already decelerated.

>
> BTW, one of the negative effects of acceleration
> is that the build times are much longer than what
> Skeinforge calculates since the feed rate averages
> out to be slower than what it should be. It also
> doesn't seem right that the firmware is not
> executing the command it receives, and is at
> liberty to change it.

Yes but a Mendel without acceleration only runs at a constant of 16mm/s but with acceleration it runs at 60mm/s infill and 20mm/s perimeter resulting in a much faster build than without while keeping strength and exterior quality high.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Just a quick note : Smoothie is a firmware for ARM mcus ( LPC17xx, 100Mhz ), which uses grbl motion planning. Also, R2C2 firmware has grbl motion planning since recently.

Quote
sublime
Yes but a Mendel without acceleration only runs at a constant of 16mm/s but with acceleration it runs at 60mm/s infill and 20mm/s perimeter resulting in a much faster build than without while keeping strength and exterior quality high.

Just because you entered 60 mm/s in Skeinforge, it doesn't mean that you're printer is running at that speed when you have acceleration turned on in the firmware.

I run my printer at 20 mm/s perimeter and 40 mm/s infill without acceleration most of the time.

Edited 1 time(s). Last edit at 10/28/2011 01:54AM by brnrd.

I agree with the topic here. It makes more sense to do path planning and acceleration/deceleration management host side, where there's larger memory, no real-time requirement, cheap floating point math, etc.

The "reprap" acceleration method in teacup should allow all calcs to be done host-side, and it shouldn't be hard to write a post-processor (in python) to read g-code and output modified g-code with acceleration properly handled.

I've been meaning to do that, and it's be simplicity itself to include an "bias extruder axis forward by an amount proportional to the current feedrate" option. IIRC, that was the end result of a great deal of math posted to the mailing list. Essentially that any extruder can be characterized by a single constant. (Of course later somebody posted some stuff shoing that it's not really that simple, but it's probably close enough) That would have the effect of automagically fast-forward at the begining of isolated moves and retract at the end of them.

Now all we need is that post-processing program... A lot of math in there though, it's been a long time since I did that sort of math.

Not saying I'll do it anytime this month though. I'd say "this year" but it amounts to the same thing at this point.

---

--
I'm building it with Baling Wire

There must be a better way here somewhere.. the issue with host side data processing is speed because the amount of redundant error checking done on the hardware end. we should be using forward error correction, that automatically corrects errors, without need to verify or resend data. this has the effect of a 10-50 fold increase in bandwidth to hardware as the long turn around time for the ftdi chip is 1-16ms.

There is that project [reprap.org] of a minimal electronics board, based on the teensy which have a direct USB connection - that would solve the PC <-> board bandwidth problems.

It needs some software then.

Quote

we should be using forward error correction

Can you come up with with an algorithm to do that? And do I assume correctly it's no longer possible to process the G-code as it comes in, like Teacup does?

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I've been wondering lately why RepRap software wasn't an extension of EMC, instead of starting over from scratch. Was it just to avoid using a parallel port?

Yes I think so. The requirements in low latency could be a reason.

It is also to allow it to run on any OS. EMC only runs on Linux with real time extensions.

I have always done my acceleration host side and send a table of step delays to the firmware. I use Ethernet instead of USB. It has a number of advantages: -

Is electrically isolated so you don't have problems with motor and / or PC ground currents flowing down the cable as you do with USB.
Low latency.
Higher bandwidth (than USB full speed).
Doesn't need a driver installing.
Can have the printer anywhere, not limited to 5m cables.

---

[www.hydraraptor.blogspot.com]

Traumflug, i came up with an method months ago for for it [forums.reprap.org].

[reprap.org]

the issue with speed of data transfer to host is simple. the delay time from usb limits reply response by up to 16ms. now with the teensy usb and the arduino running at1mhz baud rate there is another issue and it is speed of buffer processing. the only way i can get either to work correctly is with small buffers that write directly from the ftdi chip hardware buffer, or the 64 bytex2 usb buffer on teensy.


as long as data needs to be verified by checking it as it is done now, the speed issues of communication and pauses will be there, and pauses are not what you want when sending acceleration data directly from host because inertia and velocity will not match the physics.

teacup has software flow control that prevents buffer overflows, so as long as teacup is run without checksum checking enabled it probably would be the fastest firmware out there. i have not used or looked at that firmware in a while, but as long as it can use a drop in configuration.h file then i would recommend it. Sprinter still has more potential.

if whatever method we use uses serial then what is needed is for time sensitive positioning and speed gcode information to go one way only.


now this is one area for teensy as it is a true usb device and incorporates error correction in hardware, so there is virtually no chance of corrupt data as long as the buffers have been copied before being overwritten.


I had suggested that what we need is a compression method that allows for small amounts of data for short moves, and larger data for longer sized moves partially for buffering processing, but mostly for speedy communication.

The main thing is we should not send data back to host to verify, or we should use a program such as repsnapper that keeps the buffer full , by purposely sending several lines of data at a time, even before knowing if they are ok or not.


if one of us, or any of us can post a method that ensures high speed communication with few errors, then they could cause a shift in where acceleration happens from firmware to host side.

Looks like nophead has a method that seems to work. I'd hate to put him on the spot, but his setup may give insight...

I simply send a UDP packet for every line segment that has the destination and step delay in binary and list of step delays for the acceleration. I don't use any buffering.

---

[www.hydraraptor.blogspot.com]