Having migrated from Skeinforge 40 to SFACT and print print a couple of small calibration objects things were looking up for SFACT. The first printed object started okay, but as it came time to lay out the exterior shells of some small diameter holes Mach 3 began to stutter.
Initially it was thought the problem stemmed from an overly detailed STL file, which did help with the symptom, but not on every print. In order to keep the buffer depth at a reasonable level print speeds were dialed back to 25 mm/s and even then there were problematic spots. Which is real disappointing given it was printing smoothly before at 70 mm/s with out breaking a sweat.
As it turns out, the motion buffering algorithm in Mach3 gets a little hung up if there is an F parameter in a G1 instruction. Comparing old SF40 to SFACT g-code, the old SF40 only set the the velocity every time it changed. SFACT, and SF40, will add the speed to every line by default. Turning on 'small g-code' in the export plugin removes the redundant F parameters.
With a queue depth hovering around 1000 and building almost instantly, things are back to their old screaming selves. So keep your g-code small!
Friday, December 2, 2011
Thursday, December 1, 2011
SFACT impressions
Having a lot of time invested in tuning Skeinforge 41, I wasn't keen on trying something else. Print quality still suffered a few issues, mainly hole dimensions, but the parts were strong and were very close to the intended dimensions.
A couple of months ago in #reprap on IRC there was some buzz about a modified version of Skeinforge. Previous experience has taught me that the 'latest and greatest' is always the former but rarely the latter. Having switched nozzle sizes and not wanting to go through the tuning process again it would be a good time to at least try something else.
SFACT installs the same as Skeinforge without over writing any previous profiles. Made the same changes to the Skeinforge modules as outlined here. Followed the directions from the SFACT webpage and was getting better quality prints out the door. The author has really taken the time to go through all the python modules to understand how the myriad of ratio-metric parameters interplay and distilled them into a few, easy to understand and, intuitive parameters.
It is as simple as measuring the diameter of the extrusion, picking a layer height slightly smaller than the measured diameter and a width slightly wider.
For example;
extrusion diameter = 0.37mm
layer height = 0.34
width = 0.40
The only way it could be more simple is if it let you enter the measured diameter and then set a single +/- value for the height and width.
Take a quick measurement of the diameter of the raw stock filament and you're in business.
Can't emphasize this enough, you must use a very precise measuring tool like a micrometer. Calipers don't cut the mustard for these measurements.
My recommendation on SFACT is simple. Go get it!
Bookoo kudos to the developer(s)
Thingiverse - SFACT
A couple of months ago in #reprap on IRC there was some buzz about a modified version of Skeinforge. Previous experience has taught me that the 'latest and greatest' is always the former but rarely the latter. Having switched nozzle sizes and not wanting to go through the tuning process again it would be a good time to at least try something else.
SFACT installs the same as Skeinforge without over writing any previous profiles. Made the same changes to the Skeinforge modules as outlined here. Followed the directions from the SFACT webpage and was getting better quality prints out the door. The author has really taken the time to go through all the python modules to understand how the myriad of ratio-metric parameters interplay and distilled them into a few, easy to understand and, intuitive parameters.
It is as simple as measuring the diameter of the extrusion, picking a layer height slightly smaller than the measured diameter and a width slightly wider.
For example;
extrusion diameter = 0.37mm
layer height = 0.34
width = 0.40
The only way it could be more simple is if it let you enter the measured diameter and then set a single +/- value for the height and width.
Take a quick measurement of the diameter of the raw stock filament and you're in business.
Can't emphasize this enough, you must use a very precise measuring tool like a micrometer. Calipers don't cut the mustard for these measurements.
My recommendation on SFACT is simple. Go get it!
Bookoo kudos to the developer(s)
Thingiverse - SFACT
Wednesday, November 30, 2011
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.
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.
Saturday, July 23, 2011
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.
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.
Subscribe to:
Posts (Atom)