Welcome! Log In Create A New Profile

Advanced

getting smooth radius in my prints

Posted by stonewater 
getting smooth radius in my prints
March 26, 2015 08:52PM
Hi guys,

trying to get smooth printing of radius in my printer, it seems to pring radius in segments, this causes the head to stop and extrude a "dot" in the print. on small radius my corners are not smooth. and I am looking for it to be smooth. when you look at the layers after it is sliced the extruder path looks like it is in segements, seems to be a Gcode issue and wondering if i could get some advice, some settings I should check, maybe in eeprom, my segments are set to 80 in segment/s print radius.

rostock max V1
repetier .91firmware on mega board
tricklazer arms
1.2.6 experimental version of slic3r

Edited 1 time(s). Last edit at 03/26/2015 08:54PM by stonewater.
Re: getting smooth radius in my prints
March 27, 2015 10:30AM
An STL simulates a circle with a multi-sided polygon. It is a function of the CAD application that created the STL as to how many faces the polygon has - however that does not sound as if it is your problem because a polygon should print smoothly with no hesitations.

If your printer is hesitating when printing the segments, it is likely to be due to either (1) the acceleration and/or minimum speeds need adjusting in the printer's configuration or more likely (2) the printer is not getting the commands fast enough. A circle is made by executing many short moves, and each move is a separate command in the g-code file of around 30 characters or so. A single circle could take hundreds of lines in the g-code file, while a square of the same size will take only 4 lines. If you are sending the commands via a serial or USB link, the printer may well complete each short move faster than the commands can get through the link, and the printer will have to pause between each move waiting for the next command, which is what you are seeing. If you can avoid it, never print by sending the g-code file via serial or USB in real time, but instead upload the g-code file to the printer's internal file system and tell the printer to print from file - i.e. you should be able to disconnect the printer from your PC after it has started the print job. Smooth circles (i.e. made of a huge number of sides) will behave worse than coarse circles (fewer sided polygons) if you have a command speed bottleneck.

Dave
Re: getting smooth radius in my prints
March 27, 2015 12:01PM
Dave,

thanks, I should have mentioned that I have tried printing from USB and from an SD card. so is there a segments per radius I need to change ? something in EEprom? or can slic3r behave differently. I have seen deltas print nice and smooth so I know it can be done, as well as on cartezian machines. I have seen perfect circles done with spiral vase command, but even when I use it the machine still steps and draws a bunch of segments, however small. it is more about it depositing material when it stops between segments.
Re: getting smooth radius in my prints
March 27, 2015 02:24PM
Quote
stonewater
Dave,

thanks, I should have mentioned that I have tried printing from USB and from an SD card. so is there a segments per radius I need to change ? something in EEprom? or can slic3r behave differently. I have seen deltas print nice and smooth so I know it can be done, as well as on cartezian machines. I have seen perfect circles done with spiral vase command, but even when I use it the machine still steps and draws a bunch of segments, however small. it is more about it depositing material when it stops between segments.

The number of segments in the circle has nothing to do with either Slic3r or your printer, they come from the STL. Neither Slic3r nor your printer is aware that it is dealing with a circle rather than lots of short straight lines. While there is a "circle" command in the G-code command set, it is not used by Slic3r (except experimentally) and is probably not implemented on your printer in any case, and all the printers you have seen will be printing the same set of short straight lines from G-code sliced from any given STL. The resolution of the circle's circumference in the STL was set by the CAD application that produced the STL. If the design was made using OpenScad for example, you would set the number of segments in any circular section using the $fa, $fn or $fs variables.

If the printer is hesitating at each change of direction and it is *not* due to a data bottleneck, then it will be a function mainly of the acceleration and/or move speed. The printer should be able to print smoothly whether the circle is made up of only 3 lines (i.e. has become a triangle) or 1000's of lines. You could try increasing the X and Y accelerations (M201 command), but if you go too high you'll start getting missed steps, especially on the corners of large rectangles or triangles. Slowing down your print speed should also make it print more smoothly, though that is effectively masking the symptom rather than solving the problem. There is also the possibility that there is a bug or a poor move algorithm in the version of firmware you have in the printer's controller, so try a firmware upgrade if it is available.

Dave
Re: getting smooth radius in my prints
March 31, 2015 07:49AM
I found this post processor to convert line segments to arcs; [wiki.linuxcnc.org]

I haven't found a way to use it as a built in post processor in Slic3r on my PC. It doesn't like the network paths.

I have to copy the output file to a folder on my local disc and then run the processor.
Re: getting smooth radius in my prints
March 31, 2015 09:26AM
Quote
compton
I found this post processor to convert line segments to arcs; [wiki.linuxcnc.org]

I haven't found a way to use it as a built in post processor in Slic3r on my PC. It doesn't like the network paths.

I have to copy the output file to a folder on my local disc and then run the processor.

Try it by all means, but from what I have read that does not always convert correctly, and a bigger problem is likely to be that the printer firmware does not support circle commands. At the end of the day the conversion to an STL has resulted in lost information, and any application that attempts to recover that information can only do so by making a "guess" - sort of akin to upscaling a standard DVD to HD quality, you can extrapolate from what you have, but can never reliably replace the missing information.

Dave
Sorry, only registered users may post in this forum.

Click here to login