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
Showing posts with label 3D printing. Show all posts
Showing posts with label 3D printing. Show all posts
Thursday, December 1, 2011
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
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)