A look at firmware output quality

I put up a quick blog post on some initial quality firmware quality findings.

[jv4779.blogspot.com]

I have not been able to get the official firmware to run correctly so it is missing from the results.

Some ideas for future studies include step pulse jitter, verify that input gcode and output path agree, verify the max movement speed matches the gcode F value, time gaps between G1 commands, max step rates, max gcode command rates, and what happens to the step pulses when either limit is reached.

Jeremy

Edited 1 time(s). Last edit at 04/29/2011 04:35PM by jv4779.

Accuracy? I suppose that's one test.

Teacup is known to do "some small geometric distortion" this is due to the internal representation of floats - it's all fixed point rather than true floating point. This should make it much faster, (and smaller, fits on a atmega168) and was part of the reason for writing it. The standard firmware does true floating point math - some of it in interrupt context even. This makes it slow.

*Much* more interesting would be a look at maximum step rates, command turn around times, segment pausing between "queued" commands, and error response stuff. I.E. if you send an invalid command in a string of valid commands, does it correctly ask for the invalid one, and does it still execute the commands in the correct order? That's a tricky one!

On maximum step rates, the standard firmware should be the bottom of the heap, due to floating point math in interrupt context. Teacup is probably the best, as that's one of the things it's optimized for.

On command turn around times, I'd think all firmwares will be about the same b/c it should be mostly delay introduced by the USB buffers.

On segment pausing, the teacup firmware should come out on top. There's not even a hesitation between consecutive moves, the step timing shouldn't miss a beat between moves going the same direction.

On correct error response, I'd not be surprised to see every firmware failing to one degree or another. It's a tricky problem, and introduces a lot of latency. If the firmware drops all subsequent commands it'll have to ask for a resend on the ones it missed. Otherwise it'll have to queue those "not yet" commands up somewhere, and dump them into the real queue when the invalid command is resent. One is very complicated (thus error prone), the other involves resending lots of stuff, and the third option (accidentally printing out of order) would really screw up your print!

How was this data generated? Some fancy logic probe and plotting the resulting lines?

I'm looking forward to further results!

---

--
I'm building it with Baling Wire

jv4779 Wrote:
-------------------------------------------------------
> Teacup suffers from some small geometric distortion
> on the ends or a move

that's one of the things in my todo queue, as part of a sizeable overhaul of the whole acceleration subsystem

jgilmore Wrote:
-------------------------------------------------------
> On correct error response, I'd not be surprised to
> see every firmware failing to one degree or
> another. It's a tricky problem, and introduces a
> lot of latency. If the firmware drops all
> subsequent commands it'll have to ask for a resend
> on the ones it missed. Otherwise it'll have to
> queue those "not yet" commands up somewhere, and
> dump them into the real queue when the invalid
> command is resent. One is very complicated (thus
> error prone), the other involves resending lots of
> stuff, and the third option (accidentally printing
> out of order) would really screw up your print!

If the host does proper handshaking, this should be a non-issue- it sends one line only, and the firmware responds ok or resend. if it gets ok, send the next line, otherwise send the same line again. The firmware is responsible for queueing, the host should do none.

Having said that, I hear that some hostwares actually do some multi-line sends, which works great with firmwares that lack buffering (tonokip) but cause all sorts of trouble with ones that do have a queue- because the 2nd line has the wrong line number, it gets rejected after the first one has a resend requested, so we already do dump all the pre-fed lines while complaining quite loudly about it. We don't however ask for them to be resent as 1) they weren't what we asked to be sent so they're simply rejected while we ask for the first one to be resent again and 2) the host will send them anyway after we correctly receive the line we did ask for

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Jeremy, very nice work. It is always good to back check outputs and the goal of improving the quality of Reprap prints is only going to be achieved if someone spends the time to track down the cause of the inaccuracies.

I added another "firmware" to the results. Running the same gcode via EMC2 has some rather surprising results. I know the path planner in EMC2 can be adjusted to different following thresholds. On the plus side the circles are round again.

I would love to hear about any methods to get a good metric for the step timing jitter. The timing artifacts on the minor moving axis caused by Bresenham's algorithm is one of the deficiencies in all of the firmwares we have (I didn't test temporal acceleration in Teacup). I am hoping that tests on max step speed could allow for an easy band-aid fix by just running the current system at 2x or more clock rate to give the off axises half the error.

Jeremy

Edited 1 time(s). Last edit at 04/30/2011 12:35AM by jv4779.

jv4779 Wrote:
-------------------------------------------------------
> The timing artifacts on the minor moving axis
> caused by Bresenham's algorithm is one of
> the deficiencies in all of the firmwares we have
> (I didn't test temporal acceleration in Teacup).

I have said myself quite a number of times that bresenham detracts from print speed and quality, however it's the best way to prevent geometric errors. I have worked out a way to do the math "properly" (see per-axis accel thread) but I am finding that it's simply beyond the ability of our atmegas to perform the necessary calculations in a usably small timeframe and with a small enough ram and flash footprint, however they're quite capable of generating the step pulses at the appropriate times if the math is pre-calculated. I've been spending a lot of time thinking about ways to support this pre-calculation while maintaining backwards compatibility, along with a slew of other protocol upgrades.

Some of my latest commits add experimental SD card support, with architectural decisions and todo notes regarding doing precalculation between receiving serial data and writing to SD, so that the saved file can contain results of long-running operations such as floating point square roots and fine-grained acceleration data. I can't experiment with this myself until I get a larger atmega, my '328 simply doesn't have enough flash for both teacup and Fat filesystem support.

> I am hoping
> that tests on max step speed could allow for an
> easy band-aid fix by just running the current
> system at 2x or more clock rate to give the off
> axises half the error.

sure, higher clock speeds will reduce jitter, but we're already running fairly close to the max speed of the atmegas. Most run at 16MHz, mine is set to 20MHz and there's really not that much difference. For a significant difference, we would have to use something like an arm at 72MHz or similar. There's plenty of reasons to upgrade to an arm, and I think the community will go that way soon, especially since cortex M3 and similar arm chips are well within the same price range as the far less capable atmegas.

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

I believe the next evolution is a host side talker that accept gcode, preprocesses it for path planning and step profiles, and handles all the serial protocol with the micro. Aka the nophead method without a network link. That might be the only fix for the off axis step jitter. I have not published this, but the steps of EMC2 are beautiful. They do it with a constant 25us step loop that steps each when required. Simpler than finding the least common denominator for the axis rates and stepping by that.

I agree. I've been thinking about such a beast. Using basically G-code, but with the numbers in hexadecimal (for easy conversion) and all distances in steps (for axises) or pre-calculated times (for distances) or 14.2 fixed point notation for temps. Require some things (timing information) and it's basically done. It could be saved just like a g-code file - "corner_bracket.pgcode" For pre-digested gcode And we'd still retain the ability to debug it with a serial terminal.

Though debugging with a serial terminal isn't strictly required, it is nice. Nophead uses a python terminal, after importing his communication classes it works out about the same. I like python, and it's got a great interactive/command line mode. The only real beef I have with it is that it doesn't store command line history between invocations.

I'd love to write such a thing. To bad I start a new job on Tuesday, and I've got a lot of prep to do for that.

---

--
I'm building it with Baling Wire

I'm very much in favor of the idea of processing the gcode on the pc side and just doing the pulse generation on the controller side. It allows for much easier experimentation, for one.

Jitter in the stepper pulses is an interesting issue. It is easy to expend a lot of time eliminating it only to find that it does not really make an observable difference in any actual print. I hacked some code on an XMOS chip that is able to run simple GCODE with pulse resolution and jitter in the 20ns range (the code depends on the XMOS hardware so it is not portable to the Atmel chips). A test cube was printed using it and another using the Teacup firmware. There really was not any significant difference between the two prints. I don't consider the results definitive yet, and reducing jitter is always a good goal, but even if the pulse resolution and jitter is perfect there is apparently little real world advantage as most issues of resolution and jitter are mostly filtered out by the inherent momentum of the mechanical components.

Jeremy, could you run EMC2 again but this time with the path smoothing turned off (G61). That would make a better comparison to the other plots.

Acceleration is another interesting problem, but for a different reason. My Repstrap is a Taig run by EMC2, which needs lots of acceleration to print at rates competitive with a Reprap. However, when doing so there are lots of artifacts that show up in the prints that I believe are due to the phase lag between when extruder motor is moved and plastic is extruded, so simply syncing the extruder stepper to the axis steppers (which EMC2 does do) is not enough.

Right, there's the pressure buildup, ooze, etc. I don't have a mathematical model of the process, though it is predictable. The real question is: If we had such a model, and could tune it to exactly predict how much plastic is actually coming out of the end of the nozzle at any given time, could we then use that to adjust the E values to match acceleration to actual extrusion? My inclination is to say no, we couldn't. It acts somewhat like backlash, and I know that cannot be completely compensated for in software. But maybe this could.

---

--
I'm building it with Baling Wire

I had been using EMC2 as a constrast to how normal reprap firmwares operate. I ran with G64 of 0.05 as value that meets the repraps usual goal of 0.1mm resolution and still get some thing out of a robust path planner. The example with default tolerance should effect print quality.

Step timing jitter doesn't have much effect on quality as long as the jitter isn't faster than the steppers can keep up with anyways. If the feed rates get faster it could lead to missed steps.

My measurements are just to determine what is the current performance and a next step is to determine which of these matter more.

Jeremy

@jv4779: great article! I hope to see more of these comparisons in the future.
BTW, Klimentkip and caruKlip now merged in a new fork, and the firmware is now called Sprinter.

@JohnGilmore: I don't know what you mean by standard firmware, but Sprinter doesn't do any floating point math in interrupt context. So we are obtaining both geometric precision and high max step rates, maybe a little at the expense of command turn around time. It would be interesting to see a comparison on the latter too, but as you say most of it should be serial lag.

jgilmore Wrote:
-------------------------------------------------------
> The only real beef I have with it is
> that it doesn't store command line history between
> invocations.

[docs.python.org]

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

I finished by accuracy analysis and the firmwares perform very well.

post

Jeremy

Great analysis, Jeremy. I wish I had such equipment.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I'm quite supprised by the differences that you have shown.. Very interesting plots..

Given the nature of the print material sagging into its final shape.
I wonder how we could start to define the optimum accuracy that is needed to get the best print.

As using a higher accuracy could be wasted by the natural sagging of the molten plastic.

---

Bodge It [reprap.org]
=======================================

---

BIQ Sanguinololu SD LCD board	BIQ Stepcon	BIQ Opto Endstop
BIQ Heater Block PCB	BIQ Extruder Peek clamp replacement	BIQ Huxley Seedling
BIQ Sanguinololu mounting	BIQ standalone Sanguinololu or Ramps mounting	Print It Stick It Cut it

My rep strap: [repstrapbertha.blogspot.com]

Buy the bits from B&Q pipestrap [diyrepstrap.blogspot.com]
How to Build a Darwin without any Rep Rap Parts [repstrapdarwin.blogspot.com]
Web Site [www.takeaway3dtech.com]