Why don't you use Cura slicer?
-
So if my example above looked like the following, would it be acceptable to the current RRF?
;Filament used: 3.2m Filament used: 6.5m
-
That should work; but I can implement the form you originally proposed if you prefer.
-
Cura 3.2.1 with the extension from the User above to link duet into Cura … I hadnt really used layer view and simulation much in the past ... But after adding the plugin/extension and trying to view the print in Cura in Layer View to see when where an how the supports wer going ot get generated, its just smashed my PC .. hard. Hardest crash Ive ever had. Blue screen and failed to start windows after for better part of a full day now ....
Im not sure its related to the plugin - purely anecdotal ... but Quad Core i7 4800 2.7 Ghz CPU and 16 GB of ram ... ATI video card - decent one. - smashed it ...
Removed Cura ... not sure if its safe to even go back to a prior version? or if I can find ... Thats why Im not using Cura ... atm
-
That should work; but I can implement the form you originally proposed if you prefer.
I would prefer that you do that rather having the words repeated. If it could accept one or more lengths (with the m suffix) separated by commas (or not, your choice), that would be great. Thanks.
-
Hi!
The current version pre-packaged on fedora is 3.0.3 … A more recent version would be appreciated!
-
Hi @denke, you will need to ask the fedora people for that as they will be creating it, not Ultimaker or the contributors.
-
While I'm here I'll just mention that my bridging code has now been merged into Cura as an experimental feature and so it is very likely to be available in the next release (3.3) which should be in beta within a few weeks. If you can build Cura from source, it's available now in the master branches.
I have tried to make it as flexible as possible so there are quite a lot of settings but most are pretty obvious. For walls and the first skin layer the print speed, %flow and %fan can be specified. Optionally, those settings can also be specified for the next 2 skin layers. I found I got the best results if the first skin was made from thin lines printed slowly with 100% fan, the next skin is printed with thicker lines with some gaps between them and no fan. The 3rd layer is printed thicker again with no fan. This produces bridges with very good layer bonding. Long bridges still droop a little in the middle but it's hard to see how that can be completely avoided.
One other feature is that the wall speed/flow/fan settings can also be applied to overhangs so that now if you have been printing walls slowly simply to improve the quality of overhang regions, then you can now print the walls at the normal speed where they don't overhang and where they do overhang, the bridge settings will be used.
Anyway, within a couple of weeks you can have a play with this if you wish.
-
While I'm here I'll just mention that my bridging code has now been merged into Cura as an experimental feature and so it is very likely to be available in the next release (3.3) which should be in beta within a few weeks. If you can build Cura from source, it's available now in the master branches.
I have tried to make it as flexible as possible so there are quite a lot of settings but most are pretty obvious. For walls and the first skin layer the print speed, %flow and %fan can be specified. Optionally, those settings can also be specified for the next 2 skin layers. I found I got the best results if the first skin was made from thin lines printed slowly with 100% fan, the next skin is printed with thicker lines with some gaps between them and no fan. The 3rd layer is printed thicker again with no fan. This produces bridges with very good layer bonding. Long bridges still droop a little in the middle but it's hard to see how that can be completely avoided.
One other feature is that the wall speed/flow/fan settings can also be applied to overhangs so that now if you have been printing walls slowly simply to improve the quality of overhang regions, then you can now print the walls at the normal speed where they don't overhang and where they do overhang, the bridge settings will be used.
Anyway, within a couple of weeks you can have a play with this if you wish.
That's great. Can't wait to try it out. Sounds like it will not only match what other slicers are doing, but surpass them.
-
That should work; but I can implement the form you originally proposed if you prefer.
I would prefer that you do that rather having the words repeated. If it could accept one or more lengths (with the m suffix) separated by commas (or not, your choice), that would be great. Thanks.
I have added code in RC4 to recognise this format:
; Filament used: 3.2m, 6.5m
where the "m" can also be replaced by nothing (in which case mm will be assumed) or by mm.
-
Thanks David, I will do the required change for Cura.
-
Could someone who uses Cura do a quick test for me? Slice something that has circles, like a cylinder and see if the segments are all the same size. With Slic3R (various versions inc PE) they aren't. IIRC from a previous post, I believe that S3D likewise generates different size segments for circles.
Whilst I do get true circles, it seems that the unequal segment sizes may trigger the pressure advance algorithm causing the print head to act in strange ways.
Also, is anyone using Cura with multi part (coloured) stls? Is it possible to assign different tools to different parts?
Thanks
-
Could someone who uses Cura do a quick test for me? Slice something that has circles, like a cylinder and see if the segments are all the same size. With Slic3R (various versions inc PE) they aren't. IIRC from a previous post, I believe that S3D likewise generates different size segments for circles.
Whilst I do get true circles, it seems that the unequal segment sizes may trigger the pressure advance algorithm causing the print head to act in strange ways.
Also, is anyone using Cura with multi part (coloured) stls? Is it possible to assign different tools to different parts?
Thanks
I just sliced a tube using Cura and as far as I can see, the segments are all very similar in length. Mind you, the model itself isn't very high resolution so the segments are all quite long (but uniform).
Edit: to put that into perspective, a circular wall made from line segments around 0.7mm long was showing min and max segment lengths of 0.706 and 0.708 so not much variation there.
-
I just sliced a tube using Cura and as far as I can see, the segments are all very similar in length. Mind you, the model itself isn't very high resolution so the segments are all quite long (but uniform).
Edit: to put that into perspective, a circular wall made from line segments around 0.7mm long was showing min and max segment lengths of 0.706 and 0.708 so not much variation there.
Thanks. That's interesting. Can you tell me what diameter the tube was so that I can see what Slic3R does with it? I've tried both low(ish) and high resolution in OpenScad by varying $fn or $fa and $fs and while the resultant stl file is vastly different, the sliced gcode file is identical. So Slic3R seems to discard much of the resolution and do it's own thing. Maybe there is a minimum segment size in the code somewhere? That doesn't explain why segment sizes for a given curve should vary though.
Also, do you have any information about multi part (more than 2 colour) printing with Cura?
Thanks
-
This is the STL I looked at:
https://www.dropbox.com/s/73grb7v7kluomer/pb4-vmon-enclosure-tube.stl?dl=0
Sorry, I know nothing about multi-part printing with Cura other than I know that it can support up to 8(?) extruders.
-
one thing with cura as I think I found yesterday a friend of mine said that if he tried to reprint a part sliced in Cura his printer went haywire and doing some very funny moves. Checking his code file found this at the end of it
M82 ;absolute extrusion mode
M107
M104 S0 ;extruder heater off
M140 S0 ;heated bed heater off (if you have it)
M107 ; Pump Off
G91 relative positioning
G1 Z200
M83 ;relative extrusion mode
M104 S0
;End of Gcodethis is his end script
M104 S0
M140 S0
M106 S0
;Retract the filament
G92 E1
G1 E-1 F300
G1 Z200 F6000
;G28 X0 Y0
;M84 Turn Off Stepperswhy is Cura putting that G91 in the ending part of the code file?
so do beware of that, not sure if it his config or not as I don't use Cura myself
Doug
-
Interesting, as far as I can tell, the G91does not get generated by the back end so it must be coming from the front end and that could either be because the front end code generates it or it is in the printer profile or the user has put it into a script.
I notice two things in the above gcode: (1) there is no ; between the G91 and the following comment and (2) the line above the G91 has a comment that includes the word Pump which cannot be found in the Cura git repos so I think that's something the user has put in (maybe along with the G91?).
-
OK got to the bottom of it he had that G91 line in one profile not the other! doh I have told him off lol
Sorry for the trouble.
-
This is the STL I looked at:
https://www.dropbox.com/s/73grb7v7kluomer/pb4-vmon-enclosure-tube.stl?dl=0
Sorry, I know nothing about multi-part printing with Cura other than I know that it can support up to 8(?) extruders.
Cheers for that. I tried the stl in the link and the sliced gcode from Slic3R looks fine.
Sorry to be a pain but if you get chance, could you try slicing this stl https://drive.google.com/file/d/1KkKqj7XFhuZ5ue1plYmIRYN014zYtFcB/view?usp=sharing. It's simply hollow cylinders of various sizes. I sliced it just as one or two perimeters (can't remember which) with no infill so all the segments for given cylinder should be the same but here is a random sample of the resultant gcode file from Slic3R.G1 X181.823 Y172.046 E0.08974 F2700.000
G1 X181.670 Y173.055 E0.08900
G1 X181.455 Y174.056 E0.08924
G1 X181.180 Y175.043 E0.08926
G1 X180.847 Y176.008 E0.08898
G1 X180.656 Y176.489 E0.04517
G1 X180.238 Y177.417 E0.08871
G1 X179.759 Y178.330 E0.08978
G1 X179.222 Y179.216 E0.09037
G1 X178.651 Y180.043 E0.08757
G1 X178.338 Y180.456 E0.04515
G1 X177.684 Y181.240 E0.08904
G1 X176.984 Y181.983 E0.08895
G1 X176.613 Y182.344 E0.04511
G1 X175.849 Y183.021 E0.08901
G1 X175.043 Y183.653 E0.08927
G1 X174.200 Y184.234 E0.08922
G1 X173.327 Y184.762 E0.08900
G1 X172.871 Y185.010 E0.04517
G1 X171.956 Y185.456 E0.08871
G1 X171.005 Y185.850 E0.08978Just looking at the "E" values, every now and then there is an odd one that's about half the value of the others. I haven't looked at the XY coordinates but I'd guess that the odd "E2 values are due to equally odd segment sizes.
It doesn't do it with every cylinder. Some are spot on, some have larger variances that those above - really strange.
Anyway, I'd be interested to know what Cura does with that file (or any other slicer come to that).
Thanks
-
Sorry, I only have small printers, your cylinders won't fit on the build plate. Can you put them inside each other please or otherwise arrange so that the overall area is reduced.
-
I put your sample of gcode into craftware (great gcode viewer) and most of the line segments were empty because the extrusion amounts are so ridiculously small (like less than 1um of extrusion). I don't know what your steps/mm are but I would be surprised if you have sufficient extruder resolution to be able to print that line at all, let alone good quality.
