Why is acceleration being done in firmware?

Why is acceleration being done in firmware? The microcontroller seems to be at its limit in terms of processing g-codes fast enough in order to keep up with the feed rates that the printer is capable of. I get segment pause on short moves like when printing circles if I try to print above 20 mm/s for this reason. Wouldn't it make more sense to do this on Skeinforge or whatever sw is generating the g-codes since it's running on the host computer that has way more processing power than the Arduino? This way , the Arduino can just concentrate all its resource in running the machine as fast as possible. This also opens up acceleration schemes that can't be done in firmware.

Edited 1 time(s). Last edit at 10/03/2011 07:38AM by brnrd.

The pausing has NOTHING to do with the speed of the microcontroller. It is an effect of the acceleration taking place at every point in the gcode.

If you would like to see what acceleration without the pauses is like and proof it has nothing to do with the processing power try Marlin. [github.com] NON-gen6 Marlin.

---

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

I don't agree since I also used to see this with five-D firmware with acceleration off and I continued to see it with Sprinter. I also see it in other people's youtube video. My understanding is that Marlin looks ahead to the next move so it does better but I wonder if it's also slowing down short moves.

Here's a RAMPS board with Sprinter: [www.youtube.com] . The gcode is SF41 at 150mm/s infill, 75mm/s (IIRC) perimeter and 450mm/s travel. Yes, acceleration is probably keeping it from hitting those speeds most of the time but the video shows pretty clearly that this thing is screamin' along with lots of small moves.

Unless you're printing little circles with an insane numbers of edges, something else is wrong. A Mega with Sprinter has more than enough power to deal with 20mm/s.

I am referring to circles. I see it when I print circles that are around 20 mm in diameter. In that video, all the edges are sharp and so you can't really notice blobs that would result in a circle or rounded corners due to segment pause.

brnrd,

You really can't make any judgements based on "FiveD". It blocks interrupts for a long time making it unusable above about 38400 baud. It has math errors that weirdly limit top speed. Try one of the newer firmware options like Sprinter or Marlin.

Ben - As I already wrote in this thread in response to Sublime, I was seeing segment pause with Sprinter ( all the versions that I've tried up to the latest printing from the host computer or from SDRAMPS) that was the same as I was getting with FiveD. Also, I was using RAMPS 1.2 with Sprinter and Techzone Gen 3 Remix with FiveD. As I understand, the processing power is the same on both microcontrollers. I thought that using RAMPS with Sprinter would fix the problem but it didn't.

Segment pause also occurs with small circles (<<20 mm diameter) but they don't result in blobs because the pauses are too close together. Instead, the filament comes out wider and holes appear smaller that they should. At very large diameters (>>20 mm), the time to draw each segment is long enough and the microcontroller is able to keep up so the head moves smoothly without much pause.

brnrd Wrote:
-------------------------------------------------------
> I am referring to circles. I see it when I print
> circles that are around 20 mm in diameter. In that
> video, all the edges are sharp and so you can't
> really notice blobs that would result in a circle
> or rounded corners due to segment pause.

There are no circles. There are only series of straight lines that make something look circular.

I don't think the firmware cares what the resulting object looks like. It can handle tons of tiny moves at a high rate or it can't. The video was to show that it can.

The printing has three steps, each of it can cause pauses during print, especially if you have many short moves in a row, the printer may have problems keeping up.

1. Receive line and parse it. Normally, the delay between USB and Serial conversion is the limit here. 120 Lines/s are no problem, so this shouldn't be the reason.
2. Preprocessing: Before the line is drawn, some more or less heavy precomputations are necessary. It includes square roots and some divisions, which the avr doesn't support directly. Each eachoperation takes ~650 Cycles and there are quite some divisions needed. If too much lines/sec are needed, this may become a bottleneck.
3. Executing the line draw. Thanks to precumputation, each step is fast and no pauses during this phase should occur. But the execution reduces the time available for step 1 and 2.

Doing step 2 on the host is possible, but not with modiefied G-Code. You need a complete new host parsing the G-Code and sending it to a special firmware using a new binary format. Each line will need ~80 bytes. With 250000 baud you could easyly send 300 segments and the printer just needs to execute step 1 and 3. The best way would be a filter in an extisting host. The price you pay is of yourse compatibility. You need always a matching Host/Filter/Firmware combination and I see a lot of different Hosts/Firmwares already around.

With a move buffer, you should normally get no pauses in normal prints. A new communication chain is not really needed, until you want to do much more complicated precomputations like bezier curves. Or you take a faster controller (I never understood, why the xmega boards use 16 MHz. The XMega CPU can run 32 MHz).

Dave Durant Wrote:
> There are no circles. There are only series of
> straight lines that make something look circular.
>

Yes, I understand that circles in CAD files are converted to line segments when it's converted to STL. But when we print these line segments, we don't want blobs where they meet. I'm not questioning whether it can print at the feed rate when it prints each segment. The question is whether it connect these segments without pausing.

This is a comparison of Marlin against Sprinter using the exact same gcode done by "blddk"


As you can see the pauses are caused by sprinter but not marlin. This tells me that the processor can keep up.

blddk's video of Marlin
[www.youtube.com] 260mm/s
Finished part
[farm7.static.flickr.com]
[farm7.static.flickr.com]

---

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

I've been encountering the same problems in [forums.reprap.org]. I'm gonna try using Marlin with an object that I just printed using Sprinter and see what happens.

Printer: Prusa/Sanguinololu/Sprinter/Pronterface/SFact/directly connected via USB to Mac OS X host/White PLA

Yup, Sublime is right. Printing the same gcode file after loading Marlin onto my Sanguinololu results in smoother curves with no blobs where the straight segments meet. Sprinter on the left, Marlin on the right:



Edited 2 time(s). Last edit at 10/02/2011 04:11PM by Pointedstick.

@Pointedstick

Just remember that Marlin is still in alpha and you may encounter bugs which cause very negative results. Or maybe you will find it works perfect and no bugs.

What version of Sanguinololu do you have?

---

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

Pointedstick Wrote:
-------------------------------------------------------
> Yup, Sublime is right. Printing the same gcode
> file after loading Marlin onto my Sanguinololu
> results in smoother curves with no blobs where the
> straight segments meet. Sprinter on the left,
> Marlin on the right:
>
> [techpaladin.com]
> sprinter-vs-marlin.jpg

I'm sorry but I don't think that the part from Marlin is free of blobs. They're not as sharp as the blobs as in Sprinter but they are still there.

Sublime Wrote:
-------------------------------------------------------
> @Pointedstick
>
> Just remember that Marlin is still in alpha and
> you may encounter bugs which cause very negative
> results. Or maybe you will find it works perfect
> and no bugs.
>
> What version of Sanguinololu do you have?


Sanguinololu 1.3a. I already found one such bug, I think: I tried to print [www.thingiverse.com], but the printer did something wacky: it correctly moved the nozzle to the center of the print bed, then it made the same movement again and started printing in the top-right corner. It printed the outline and the perimeter, then it stopped. This was printed to the console log:


Printer is now online
Serial Error: Line Number is not Last Line Number+1, Last Line:0
Resend:1
Marlin 0.9.9L
start
Printer is now online
Serial Error: Line Number is not Last Line Number+1, Last Line:0
Resend:1

brnrd Wrote:
-------------------------------------------------------
> Pointedstick Wrote:
> --------------------------------------------------
> -----
> > Yup, Sublime is right. Printing the same gcode
> > file after loading Marlin onto my Sanguinololu
> > results in smoother curves with no blobs where
> the
> > straight segments meet. Sprinter on the left,
> > Marlin on the right:
> >
> >
> [techpaladin.com]
>
> > sprinter-vs-marlin.jpg
>
> I'm sorry but I don't think that the part from
> Marlin is free of blobs. They're not as sharp as
> the blobs as in Sprinter but they are still there.

Those are called corners. As said before its made of small line segments. You will always see the corners unless the firmware does curves or trajectory smoothing like EMC2.

---

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

Pointedstick Wrote:
-------------------------------------------------------

> Sanguinololu 1.3a. I already found one such bug, I
> think:


Be sure to post a bug report on the GitHub page.

---

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

Sublime Wrote:
-------------------------------------------------------
> This is a comparison of Marlin against Sprinter
> using the exact same gcode done by "blddk"
> [farm7.static.flickr.com]
> f0c6027.jpg
>
> As you can see the pauses are caused by sprinter
> but not marlin. This tells me that the processor
> can keep up.
>

Yes, the part from Marlin looks better than the one from Sprinter. But this doesn't prove that the processor is fast enough to keep up with short moves. It proves that Marlin is doing a better job at dealing with it. Have you verified that the actual speed of the head going around the rounded sections of the perimeter is the same as when it goes through the long straight sides? And what is that speed?

Sublime Wrote:
-------------------------------------------------------
> Pointedstick Wrote:
> --------------------------------------------------
> -----
>
> > Sanguinololu 1.3a. I already found one such bug,
> I
> > think:
>
>
> Be sure to post a bug report on the GitHub page.


Looks like it's already known: [github.com]

I commented anyway.

Sublime Wrote:
-------------------------------------------------------
> brnrd Wrote:
> --------------------------------------------------
> -----
> > Pointedstick Wrote:
> >
> --------------------------------------------------
>
> > -----
> > > Yup, Sublime is right. Printing the same
> gcode
> > > file after loading Marlin onto my
> Sanguinololu
> > > results in smoother curves with no blobs
> where
> > the
> > > straight segments meet. Sprinter on the left,
> > > Marlin on the right:
> > >
> > >
> >
> [techpaladin.com]
>
> >
> > > sprinter-vs-marlin.jpg
> >
> > I'm sorry but I don't think that the part from
> > Marlin is free of blobs. They're not as sharp
> as
> > the blobs as in Sprinter but they are still
> there.
>
> Those are called corners. As said before its made
> of small line segments. You will always see the
> corners unless the firmware does curves or
> trajectory smoothing like EMC2.

You won't see them like that if you slow down your feed rate to 20 mm/s and below and turn of acceleration. Then you would see the corners without blobs in them. It comes from extra plastic that ends up in the corners, as you prefer to all it, when the head pauses there a bit. When you extrude slowly and the microcontroller is able to keep up, there are no pauses at the corners and you can actually recognize the straight segments that approximate the circle without blobs.

> Yes, the part from Marlin looks better than the
> one from Sprinter. But this doesn't prove that the
> processor is fast enough to keep up with short
> moves. It proves that Marlin is doing a better job
> at dealing with it. Have you verified that the
> actual speed of the head going around the rounded
> sections of the perimeter is the same as when it
> goes through the long straight sides? And what is
> that speed?


Ok but with that said, Marlin is doing more processing than sprinter by doing look ahead and planning. So on the same Gcode file Marlin is doing more processes per second than Sprinter and yet causing less bumps.

I believe the bumps are caused by flow not being linear to pressure. At low speeds the nozzles pressure is low and the material flows really well, but as you speed up the pressure increases faster than the flow rate. This causes a thinner extruded filament at high speed than a low speed. To test try printing a large single wall box at 10mm/s and one at 50mm/s. Then measure the wall thickness in the middle of the box and you will see the wall of the high speed print is thinner than the wall of the low speed print (which should be height * W/T). This is all because the plastic flow decreases with pressure. You can then increase the temperature to print at lower pressure but you can't print slowly because the plastic runs out of the nozzle like water (and still flows more a lower pressure than at high pressure creating bumps)

But with marlin because it only accelerates and decelerates when changing direction so it can keep the pressure up and the flow even.

I have recently designed a new cheaper plumbstruder and I'm now printing 20c lower than I did before. This lowering of temperature really helped keep the pressure equal over a larger speed range and has reduced my bumps to ZERO at 22.5mm/s perimeter and 1000 times better at 60mm/s. My issue was to long of melt zone and too much of the filament being molten. I solved this by cooling the thermal barrier to where its at or below room temperature. This also had the result of having far less friction, less ooze, more definition and less curling of layers.

Note: I am not using Marlin, I am using Teacup because I never have communication errors with Xon/Xoff and really like the way Teacup is written. I have tried Marlin but was never able to keep communications clean.(my hardware I think)

---

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

repetier Wrote:>
>...
> Doing step 2 on the host is possible, but not with
> modiefied G-Code. You need a complete new host
> parsing the G-Code and sending it to a special
> firmware using a new binary format. Each line will
> need ~80 bytes. With 250000 baud you could easyly
> send 300 segments and the printer just needs to
> execute step 1 and 3. The best way would be a
> filter in an extisting host. The price you pay is
> of yourse compatibility. You need always a
> matching Host/Filter/Firmware combination and I
> see a lot of different Hosts/Firmwares already
> around.
>
> With a move buffer, you should normally get no
> pauses in normal prints. A new communication chain
> is not really needed, until you want to do much
> more complicated precomputations like bezier
> curves. Or you take a faster controller (I never
> understood, why the xmega boards use 16 MHz. The
> XMega CPU can run 32 MHz).

I also think that going with a faster controller is the best solution in the end.

Another alternative is to accept the fact that the microcontroller needs a minimum amount of time to process a G-code command and then generate g-codes so that the time for each move is always equal to or longer than that time. This can be done by reducing the feed rate on short moves. This can't be simply done on a single move basis since it could result in the feed rate changing from one segment to the next. I actually tried this by modifying the Unpause plug-in in Skeinforge but it failed since the size of each segment around a circle from an STL file is not always the same. In fact, I found that the STL file from Solidworks has alternating short and long segments. This actually worsened the problem. The way to approach it is to analyze a series of moves to make sure that the feed rate is not changing too fast. I read from someone's post that Marlin looks ahead to the next move perhaps to do the same thing.

brnrd Wrote:
-------------------------------------------------------
> Sublime Wrote:
> --------------------------------------------------
> -----
> > This is a comparison of Marlin against Sprinter
> > using the exact same gcode done by "blddk"
> >
> [farm7.static.flickr.com]
>
> > f0c6027.jpg
> >
> > As you can see the pauses are caused by
> sprinter
> > but not marlin. This tells me that the
> processor
> > can keep up.
> >
>
> Yes, the part from Marlin looks better than the
> one from Sprinter. But this doesn't prove that the
> processor is fast enough to keep up with short
> moves. It proves that Marlin is doing a better job
> at dealing with it. Have you verified that the
> actual speed of the head going around the rounded
> sections of the perimeter is the same as when it
> goes through the long straight sides? And what is
> that speed?


Both of them were printed at 45mm/sec for the perimeter and 80 mm/sec for the infill.

Sublime Wrote:
>
> Ok but with that said, Marlin is doing more
> processing than sprinter by doing look ahead and
> planning. So on the same Gcode file Marlin is
> doing more processes per second than Sprinter and
> yet causing less bumps.
>

This would be true if the actual feed rate is the same when going through the same region with short segments. Did you or anyone measure this?

> I believe the bumps are caused by flow not being
> linear to pressure. At low speeds the nozzles
>

I can see the carriage vibrate as it pauses and starts again (stutters) while making short moves as it goes around circles. I think this is convincing enough for me that the blobs at the corners (end of each segment) is a result of this, When the head moves smoothly, there are no blobs.

brnrd Wrote:
-------------------------------------------------------

> > I believe the bumps are caused by flow not
> being
> > linear to pressure. At low speeds the nozzles
> >
>
> I can see the carriage vibrate as it pauses and
> starts again (stutters) while making short moves
> as it goes around circles. I think this is
> convincing enough for me that the blobs at the
> corners (end of each segment) is a result of this,
> When the head moves smoothly, there are no blobs.

Exactly, Because the pressure changes as it speeds up and slows down. This speeding up and slowing down is how Ramping acceleration works. If you would like proof of this being how Ramping works just set your acceleration to 10mm/s^2 and not 1000mm/s^2 (sprinters default). You will see it speeds up and slows down at every point. Even the longest ones.

---

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

Sublime Wrote:
-------------------------------------------------------
> brnrd Wrote:
> --------------------------------------------------
> -----
>
> > > I believe the bumps are caused by flow not
> > being
> > > linear to pressure. At low speeds the nozzles
> > >
> >
> > I can see the carriage vibrate as it pauses and
> > starts again (stutters) while making short
> moves
> > as it goes around circles. I think this is
> > convincing enough for me that the blobs at the
> > corners (end of each segment) is a result of
> this,
> > When the head moves smoothly, there are no
> blobs.
>
> Exactly, Because the pressure changes as it speeds
> up and slows down. This speeding up and slowing
> down is how Ramping acceleration works. If you
> would like proof of this being how Ramping works
> just set your acceleration to 10mm/s^2 and not
> 1000mm/s^2 (sprinters default). You will see it
> speeds up and slows down at every point. Even the
> longest ones.


At this point, I'm not sure whose theory this supports, but when I printed the first part in Sprinter, the carriage was vibrating terribly when it had to do the circular perimeters. With Marlin, there was almost no vibration as it did the circular perimeters. Again, same gcode file.

> At this point, I'm not sure whose theory this
> supports, but when I printed the first part in
> Sprinter, the carriage was vibrating terribly when
> it had to do the circular perimeters. With Marlin,
> there was almost no vibration as it did the
> circular perimeters. Again, same gcode file.


This makes sense, Because Marlin has look ahead to try and keep up the speed base on the amount of "jerk" any change in direction will impart on the machine. You can set the amount of jerk in the config file. And on curves it maintains a speed which will not be above the set limit of jerk.

EDIT:
Normal ramping acceleration has no look ahead so it has to speed up and slow down on every move because the next move may be in the opposite direction.

Edited 1 time(s). Last edit at 10/02/2011 06:26PM by Sublime.

---

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

Again, the vibration associated with segment pause also happens without acceleration. I have seen that acceleration can make it worse but it's there even without acceleration.

brnrd Wrote:
-------------------------------------------------------
> Again, the vibration associated with segment pause
> also happens without acceleration. I have seen
> that acceleration can make it worse but it's there
> even without acceleration.


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?