-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document settings for gcode generation #15
Comments
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 |
Well, I guess including the link to your forum post to the readme would be a good start. |
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. |
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) 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 I was not able to get even close to printing time with the Slic3er. |
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 |
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:
Here is the original g-code Slic3r produced: 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. |
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 |
Is there any reason why some of the values in the last screenshot are way different from what you'd expect?
|
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 |
Hi kscheff, of course we should discuss all this here. I was just confused that you might think it's an up3dtranscode issue. 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):
So every segment (can be any length fitting inside the 16bit values) is having a speed and a acceleration value for each axis. 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 |
Hi kscheff, I loaded your slic3r g-code in Simplify3D and it looks exact same as the back translated up3dtranscode output. 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 |
@kscheff Maik |
Yes, the results are based on a pre 0.4 version. I will check with the newest one. |
Hi All, In an attempt to answer the original question of this issue..... The above results were taken from a large print with straight lines almost the width of the print bed. I hope this helps Adrian |
Hi All, The factory file is currently set to a 0.25 mm z resolution, but the same settings have worked at 0.1 mm. I hope you find it useful :) Thanks Adrian Bear |
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. |
Hi @highground88, 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. Adrian |
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...
The text was updated successfully, but these errors were encountered: