Mach3 RepRap stuttering and STL file quality

It's been a while..

Changing the extrusion nozzle from 0.5mm to 0.35mm had induced a rapid stuttering while printing.  This is usually a good indication that the queue depth isn't getting a chance to build up and languishes around 0 records deep.  A look at the diagnostics screen confirmed this.

When and how Mach3 starts building up the motion queue isn't very clear.  System resources aren't an issue, no more than 30% processor utilization and 512+ MB RAM available.  This is all conjecture but, Mach3 shouldn't be having a problem crunching numbers, or there is something bottle necking the process within the program.

Adjusted the base frequency from 100kHz to 65kHz, no improvement.

Turned off CV mode, stuttering still present and prints looked worse.

The stuttering always started during a radius-ed motion and would stop shortly after it reached a section of long linear moves.  The STL file was Skeinforge'ed using the 0.5mm nozzle diameter and compared to the 0.35 and the 0.5mm code was 1/10th the file size.  Upon further investigation the 0.35mm code generated many many more little vectors for the circular motions.

If Mach3 can't process the data, and it can't be limited in Skeinforge, then the only option to address it is in the STL generation.  Changing anything from a circle to a polygon in SW isn't an option. References are lost or non existent and it really impedes work flow.

Do the usual Save as.... .STL but this time clicked the advanced button and changed the resolution from fine to course via the radio buttons.  Skein the new STL and the file size has been significantly reduced.  Good sign.  Let Mach3 do it's thing and things start buzzing along with queue depth hovering between 1000 and 800.  The coarse STL output made no appreciable difference in the circular motions and resolved the stuttering.  Overall improvement on print quality.

Making Mach3 and Skeinforge Play Nice

RepRap Gcode uses 'E' as the identifier for the extruder axis, which makes sense to some degree, but Mach3 recognizes Axis extra to X, Y, & Z as A, B, & C. The extruder will have to use one of these three identifiers, I chose A.  Skeinforge does provide a nice tool in the export module to help facilitate this.  Locate the Skeinforge alterations directory, create a new text file with your favorite text editor like notepad.  Skeainforge parses the records in the file using the tab character.  The contents of the file should look like this

E[tab key] A[Enter]
M[tab key]; M[Enter]

save the file as text only.

From now on skeinforge will search and replace the E axis identifier with A and comment out all the M codes.

The reason for removing the M codes is because they serve no practical purpose and delay Mach 3 during the printing process as it tries to locate the undefined macros.

Mach3 began to chew through the g code and the print head danced lightly footed across the bed.  Quite the contrast to the rigid and jerky boxing like cadence.  Previously any motion with a radius sounded like the ratcheting report of a Thompson machine gun and now it pirouettes around any radius with out effort or wasted force.  To say the transformation was impressive is an understatement.

There was one minor annoyance.  Just before the head would make a non extruding series of movements, the extruder would retract the filament in an effort to stop molten plastic from oozing onto the print.  Once the head is in position to print, the extruder is primed and then the extruder axis is reset to 0.  It would take approx a second for the axis to zero which is confusing to me.  It may not sound like a lot of time but, having it occur a dozen or more times per layer over tens to hundreds of layers it starts to add up.  Not to mention effect the print quality.

The first attempt to work around the issues was to use the extruder axis relative distance mode option in skeinforge. Apparently the methods employed by RepRaps doesn't agree with Mach3, as all axis began to move using relative distance.  No good.

Digging through the dimension.py for skeinforge this was found.


elif firstWord == 'M101':
self.addLinearMoveExtrusionDistanceLine( self.restartDistance )
if not self.repository.relativeExtrusionDistance.value:
self.distanceFeedRate.addLine('G92 E0')
self.totalExtrusionDistance = 0.0
self.isExtruderActive = True

Even with my weak Python Fu it looked like the code responsible for zero'ing the extruder.  A couple quick flicks of the # key and the offending code was neutralized.

elif firstWord == 'M101':
self.addLinearMoveExtrusionDistanceLine( self.restartDistance )
#if not self.repository.relativeExtrusionDistance.value:
# self.distanceFeedRate.addLine('G92 E0')
# self.totalExtrusionDistance = 0.0
self.isExtruderActive = True

Setting the extruder back to absolute coordinates the new g-code no longer zero'ed the extruder again.

For the first time, I am substantially satisfied with the RepRap. 

RepRap and Mach3

After months of slowly improved mediocre prints from a Mendel Sells I hit a wall with the hacked Gen 3 motion controller.  It would appear that the right sequence of G code would cause the Arduino based controller to end a move prematurely and the remainder of the print would be out of index.  It was time to try something a little more proven.

I dusted off a license file for Mach3 I purchased and never used some time ago and got work.  Breaking out one end of DB25 printer cable and attaching it to the stepper controllers for each axis was a simple and quick task.  Then configuring the axis and motor profiles in Mach3 was even simpler.  It was nice to make a small change and it not requiring to recompile and flash the old RepRap controller.   Two hours and the whole process was complete.

The extruder controller was hard coded to maintain the extruder's hot end temperature since Mach3 doesn't have any means of communicating with the controller... yet.  For now, the plan is to use a dry contact driven by Mach3 to switch power to the controller.

Running all the axis through the manual pulse generator, a successful integration was confirmed.