What Causes the Warts?

Printing with Warts

On all of my prints there are little warts in the layers. These are caused by excess plastic being deposited at various points during the print.


At first I thought these were caused by the oozy nature of PLA. Just turn on the extruder to heat and without running the motor molten PLA will ooze out of the extruder, seemingly forever.


However, I was determined to stop it from happening. I started playing with both Oozebane and retraction speeds and distances in Skeinforge to no avail. These settings only affect the end of a thread, these warts appear in the middle of a thread run.


I started to watch my printer more closely to see what was causing them. It became apparent that the warts are caused when the printer stops for a fraction of a second and PLA oozes out on to the print. Why was my printer pausing?


I reviewed the firmware code to see if I could spot the cause. It's complex as there are so lines of code for other printer configurations in the firmware that you get lead down a particular path only to discover that piece of code isn't compiled into your specific printer. Nothing obvious jumped out.


Then I wondered if the GCode buffer was running dry so I started to review the RepSnapper log files. The timing information in them wasn't sufficient to spot buffer under-run, so I switched to PortMon, my favorite serial monitor. It didn't appear that there was any noticeable delays in getting the GCodes on chip at a baud rate of 19,200. A few quick calculations confirmed this. 


I did note two things in the log file though. The first was there were loads of retransmissions. Mainly caused by Skeinforge generating M101 and M103 extruder commands, which aren't used by Mendel. I'm not sure how to prevent Skeinforge from generating these, if anyone knows let me know. When the Gen6 electronics receives these commands it responds with a 'Huh - I don't know what this is' and then it asks for the last packet before that to be resent. Perhaps this was causing the buffers to run dry as the firmware flushed the previous commands? So I wrote a quick Python script to remove the duff M10x commands and retried the prints. They were still warty.

Wart-less Test Print

The other thing I noticed were lots of M105 commands, these are temperature requests generated by RepSnapper. The firmware takes sometime to process these commands as it has to take multiple temperature readings and average them. Switching this feature off in RepSnapper instantly removed the warts on the test prints. The Atmega should be capable of performing these measurements while still printing, but without a real scheduler perhaps the timing is too complex - I need to spend more time with the firmware.


From now on, I'll switch off the temperature monitoring in RepSnapper, but I'll still continue to run my pre-processor script as it prevents thousands of re-transmissions per print. I've also added the ability to substitute the Skeinforge start-up code with my preferred start-up GCodes.

Before and After