Thursday, March 12, 2009


New Wine Glass

I thought this picture was worth posting, the wine glass is 128mm high and 60mm dia at the rim.
They were both printed with the following settings:
192DegC / PLA
16mm/sec print speed
No Raft, no stops on the extruder (there are a few fine hairs inside the glass)
Both objects were made using the same file with one difference, the glass on the right has the comment lines, on the left it has no comment lines.

I think it clearly shows the effect of segment pausing as the reader takes time to get past the comments, the buffer runs out and the head stops for a fraction of a second between layers. The effect is less obvious in the stem as there are fewer comments to define the small layers and worse as it get higher in the glass with more comments required to define the larger layer.
The print on the right was terminated early to investigate the cause of the defects.
The ripple down the side of the left hand glass is the due to the Z move, its not quite fast enough for the extrusion rate.


Very nice and a good demonstration of the effect of segment pausing. I got a similar pimpled effect when I used Ethereal to monitor the Ethernet traffic to HydraRaptor. Every time it dumped its buffer to disk it blocked the network for a short time.
What firmware/software was this done with? Specifically, the latest arduino reprap firmware has internal buffering which should (in theory) entirely eliminate segment pauses. That's the one that's not possible to compile small enough to load unless you have the exactly correct versions of avr-gcc and avr-libc, or a sanguino.

Did you just prove that it doesn't work, or did you just prove that it's much needed?
What firmware/software was this done with?

The firmware/electronics are the PIC32/SD Card, there are a few notes on this if you scroll down this forum. The software uses a buffer that under normal circumstances eliminates any segment pausing. In the example the file contains many long text comment lines at the start of each layer. These lines have to be read but have no action for the machine, the buffer runs dry and the head pauses for a split second until it gets to the next G-Code instruction.

Did you just prove that it doesn't work, or did you just prove that it's much needed?

I just thought it might be of use for others seeing a similar effect on their printed objects. The original file was quite an old one, I did not realise that it still had the comment lines in.

Am I missing something here or would it be too hard to just strip comments from the G-Code before transmitting it to the MCU? :-s
Sorry Forrest, you are not missing anything, I ran an old file that was full of comments.
I normally run text files from the SD card without comments in them, the bad result was a bit of a novelty. In hind site it was not really worth posting.

On the other hand, the quality of the good print is the best I have managed to date and is the first picture I have posted using the RapMan firmware since I introduced the step buffering. Previous prints were done using in-line processing of the G_Code and relied on the raw power of the PIC32 to keep segment pausing to a minimum. It also represents the end of my testing with PLA, I don't think I can improve quality with this material any further. (using a 0.5 dia nozzle)

I mentioned that PP was on the list to test but this will have to wait now as a large coil of ABS has arrived and I am eager to get stuck into that and see if similar results can be realised.

Just because a problem is easy to solve once it's identified, doesn't make it necessarily easy to identify nor does it mean it can never occur, though.
Post a Comment

Links to this post:

Create a Link

<< Home

This page is powered by Blogger. Isn't yours?

Subscribe to
Posts [Atom]