search

MaikStohn / UP3D

UP 3D Printer Tools
GNU General Public License v2.0
80 stars 33 forks source link

Document settings for gcode generation #15

Open dfyx opened 8 years ago

dfyx commented 8 years ago

I know it's not strictly the focus of this project but it would be nice to have some documentation about which settings to use when generating gcode for the different Up printers. As far as I'm aware there's no official documentation of the printers' max speed, max acceleration, etc. and I assume most users that use the code from this repository (such as myself) are used to the Up3D software and rather inexperienced with Simplify3D, Slic3r, etc...

MaikStohn commented 8 years ago

Hello,

this is something I will ask for help from the community.

I know it is a very difficult thing to find out how the undocumented UP is working and to make programs to translate a standard (G-Code) to this unknown format - this is what I'm doing.

I gave a brief overview of my quick settings for one of the many slicing programs here:

http://www.up3d.com/dami/viewtopic.php?f=28&t=55250

However reading some slicer manuals on internet, trying things, tuning settings and writing a documentation for it is something I wish somebody else will take care of.

Maik

dfyx commented 8 years ago

Well, I guess including the link to your forum post to the readme would be a good start.

adrianbear commented 8 years ago

Maik has just made a new version, which appears busted in windows. Once we/I have that sorted I'll document my settings and calibration procedure in here. Adrian

kscheff commented 8 years ago

Right now I try to match the original UP software settings to Slic3r. However all the settings do not really translate to the Up 1:1 since the slicers are way different. Some question I got was, what the different speed setting of the UP Software translate to. From Maik I extracted so far the following:

FINE mode is about 20/30/40 mm/sec (perimeters/infill/support) NORMAL mode is about 40/50/60 mm/sec FAST mode is about 50/60/60 mm/sec

Acceleration and max speed is handled in the up3dtranscoder itself and is typically handled by the printer itself (and not the silcer), so I am fine with this approach.

The main issue I am expirienceing is that the Slic3er generated code running through up3dtranscode prints so much slower (2x slower!) than the UP Software, despite the max speed and acceleration seems to be faster in up3dtranscode than in the UP software (the printer actually moves the head really hectic and fast around, but at the end the total time is slower). So I was trying to compare the Slic3r vs. Up "umc" code by capturing the umc data (via FixUp3D) and reverse it to g-code (via the tool convg in this package) in order to put it to a viewer. As a result I see that the UP software slicer generates nice corners instead of edges, this leads to higher "corner speeds" and contributes largely to the faster printing time. Slice3r does not have such feature and I am unaware if Simpify3D does. My comparison was done with a simple 10x10x10 mm3 cube results are printing time reported inside converted G-Code:

Up settings are: 0.3mm, loose fill, no raft Fine: 330 sec. Normal: 219 sec. Fast: 183 sec. Slic3r: 753 sec.

I was not able to get even close to printing time with the Slic3er. cube_10x10x10.zip

MaikStohn commented 8 years ago

Hi kscheff,

here some notes from me about time difference and "nicer" corners:

BTW: Your slic3r config is doing 2 perimeters at low speed, the up software is only applying a lower speed to the outside perimeter. Also it looks like your slic3r perimeter speed is very slow (compared to up software). Can you check the settings or provide the slic3r generated gcode?.

Maik

kscheff commented 8 years ago

Hi Maik,

I have read through the grbl stuff. In fact the 2nd post on the cornering algorithm is exactly what I meant. It states that on right angular path the speed is almost zero. The max deviation only comes into play on smaller angles. The approach tiertime is using is different, they create a path with no right angle moves, meaning when there is a right angle corner, they break it up in small segments with less than 90 degrees. This allows for higher "corner" speed at the price of slightly less sharp resulting corners. In my observations these softening is not visible on the resulting printed part. In my opinion the extruded plastics cannot follow a right angle anyhow.

Yes, the number of perimeters and speeds do not really match, but the principle for the different slicers is evident. Here are some numbers I extracted from the resulting g-code via http://gcode.ws

Print time for Layers 1,2,3(infill) and top:

Fine      69.6  16.3  9.4  17.6
Normal    35.9   9.4  5.4  10.0
Fast      34.4   7.5  4.9   7.9
Slic3r    31.4  24.5  7.5  27.8   <-- updated value

Slic3r 31.4 24.5 7.5 31.4

Here is the original g-code Slic3r produced: Cube_10x10_slic3r.gcode.zip

Here are the pictures showing the various top layers. Unfortunately the legend with the different speeds exceeds the available screen size and color palette, so that piece is useless.

test_fine_top Fine

test_normal_top Normal

test_fast_top Fast

test_slic3r_top2 Slic3r

test_slic3r_top Slic3r - first layer (not to compare)

MaikStohn commented 8 years ago

Hi,

form your pictures you might get the idea you described... But in reality this are just some artifacts from bad math from UP software when cutting the acceleration/deceleration into a lot of small segments. This is just not needed and gives very bad results. I improved the mathematics for this a lot. I think you are on a wrong track here.

I just analyzed your original slic3r gcode and it is having same slow speeds like up3dtranscode output. So I think this is not an issue of up3dtranscode, more likely it is caused by your slic3r settings (you configured very slow perimeter on top infill speed).

UPDATE: check if you enabled "auto cooling" (Filament->Settings->Cooling->Enable Auto Cooling). This will slow down the print if a layer is printed under a specific amount of time (this will help to prevent molten parts when printing small objects very fast).

Maik

dfyx commented 8 years ago

Is there any reason why some of the values in the last screenshot are way different from what you'd expect?

kscheff commented 8 years ago

Hi Maik,

don't get me wrong here, I don't believe either that is is an issue of up3dtranscode. I believe this is due to Slic3er. However this contributes to the usefulness (at least for me) of up3dtranscode. If this is the wrong place for such discussion, please suggest an other place...

I checked the cooling time, in Slic3er I have activated auto cooling when the layer is < 5 seconds, so I there should be no additional cooling taking place.

I don't believe this is bad mathematics on the UP software, it looks like making this on purpose. Looking at the resulting print, I cannot see that it generates bad objects. So I am curious how they archive faster printing time. Via http://gcode.ws you can see all the other layers and compare it, e.g. the infill layer above 3 is much faster on the UP software using the same number of perimeters.

@dfyx Thanks, you are right. I inserted the correct picture and updated the table times

MaikStohn commented 8 years ago

Hi kscheff,

of course we should discuss all this here. I was just confused that you might think it's an up3dtranscode issue. ==> Your speed issue is from the G-Code you use ==> we have to look at slic3r output.

The other thing you observe I want to explain in detail, since both outputs (UP software and transcoder) are equivalent, even if the (back translated) G-Code looks different (in your viewer):

UP machine format uses following parameter for a "extrusion move" (notes/structs.txt):

unsigned __int16 SegNum;
unsigned __int16 SegPeriod;
__int16 XSpeed;
__int16 YSpeed;
__int16 ASpeed;
__int16 XAcc;
__int16 YAcc;
__int16 AAcc;

So every segment (can be any length fitting inside the 16bit values) is having a speed and a acceleration value for each axis. UP software decides (for no real reason) to limit itself and cut segments into many many small, max. 500 "SegNum" long segments. This leads to an output where a straight line is stitched together by many many smaller segments. Even acceleration/deceleration is cut into segments (this is not required at all since acceleration/deceleration is constant and does not change over time). As a result the UP software just outputs much bigger data than it needs to do. The result is same (if you cut a line in 5 pcs and all pcs have same parameter it is same as just having 1 pcs).

What you observe is an artifact from back-conversion. Since G-Code does not have acceleration values your visualizer does not show them. When "convg" converts them back it just uses the "average" speed of the segment. In case you do not cut acceleration / deceleration into small segments nothing will be shown at all for them. Since UP software cuts them into smaller pcs. the average speed for each of this segments is different. This will produce the output of your visualizer.

So a correct G-Code viewer which would show the acceleration/deceleration within every line would have the exact same output for both (UP software and up3dtranscode).

Maik

MaikStohn commented 8 years ago

Hi kscheff,

I loaded your slic3r g-code in Simplify3D and it looks exact same as the back translated up3dtranscode output.

Slic3r Input: slic3r_input

Back Translated UMC: backtranslated_umc

The faster "green-yellow" line on top is just a travel move which is not shown on first picture.

So your print speed selected in Slic3r is around 20mm/sec (which is slower than UP).

Maik

MaikStohn commented 8 years ago

@kscheff I just fixed a bug in v0.4.1/0.4.0 version (wait for heated bed was not working). Since your UMC output contained heat bed wait I ask myself which version of up3dtranscode you used for your tests (0.3.0 or lower)? I just wanted to mention that version 0.4.x is having big corrections for accuracy and speed inside.

Maik

kscheff commented 8 years ago

Yes, the results are based on a pre 0.4 version. I will check with the newest one.

adrianbear commented 8 years ago

Hi All,

In an attempt to answer the original question of this issue..... For the UPBox, I've just used the FixUP3d and CONVG tools to extract the UP speed ranges I can see in the Simplify3d gcode previewer.

image

The above results were taken from a large print with straight lines almost the width of the print bed. Even given the above results, I have still been able to print at 7200 mm/min (120 mm/sec) from Simplify3d, although the resulting quality is pretty poor.

I hope this helps

Adrian

adrianbear commented 8 years ago

Hi All,

After a fair bit of testing to get extrusion width settings in Simplify3d correct, I can only conclude that each printer is going to need to be calibrated, most likely for each new Material you plan to use. But regardless, using as filament diameter of 1.75 mm (which was a pretty accurate diameter), my extruder settings are below. image

Adrian

adrianbear commented 8 years ago

Hi All, For those using an UPBox I have attached my current Simplify3d factory file and 2 batch files for nozzle height settings. UPBox Simplify3d Factory File Calibrated for PLA 20160515.zip

The factory file is currently set to a 0.25 mm z resolution, but the same settings have worked at 0.1 mm. I also have the default speed reduced to 3600 mm/min but this could be increased to 4800 mm/min. I am still fine tuning the retraction settings but this is fairly close for my purposes.

I hope you find it useful :)

Thanks

Adrian Bear

highground88 commented 8 years ago

Quick question - is it possible to convert a .UP3 file back to a Gcode/STL? Having problems with our printer and think that the upgraded extruder parts may help, but need to print with a different printer. Great job on your work!

adrianbear commented 8 years ago

Hi @highground88, You can use the FixUP3d tools to extract gcode, but it will be offset and not really useable on another printer. I don't think its possible (at least not easily) to decode the UP files to extract the STL's back out.

Your best bet would be to ask your UP printer supplier to either send or print you some replacement parts. I think that would be the easiest and fastest solution.

If your in Adelaide, Australia I would be happy to print them for you and you could just pick them up. Or you could cover the cost of postage :)

Adrian