Why don't you use Cura slicer?
-
Not sure what's wrong there, could you please post a link to the gcode so I can investigate.
https://drive.google.com/file/d/1Ziml3INWFtu665eZGyqOi_tRXTQ8ulAn/view?usp=sharing
I should have added that everything was working fine in the print status window until I updated to 1.21RC2 firmware then subsequently to RC3. It doesn't help that at this same time I switched to Cura from S3D and have not yet tried S3D on the new firmware to see if it displays the same issue. At the end of this current 15 hour print I'm on I'll switch to S3D and see what happens. Everything was fine before I upgraded firmware and started using Cura.
The only possible thing that tipped me to blame Cura was a thread (cant remember which one) where others were having the same problem where the DWC print settings wouldn't update for files sliced with cura.
-
Thanks for the file. Yes, there's a problem in there as it reports the filament used at the top of the file as zero. I don't know why that is right now but will investigate. I am using a later version of Cura and the filament used is correct so perhaps there was a bug and it has been fixed?
-
Thanks for the file. Yes, there's a problem in there as it reports the filament used at the top of the file as zero. I don't know why that is right now but will investigate. I am using a later version of Cura and the filament used is correct so perhaps there was a bug and it has been fixed?
Interesting! I see that now as well and checked my other files generated by cura and the same 0m value is there for filament. Is there a later version than cura 3.2.1? When I look on their website it says 3.2.1 dated February 18 is the latest.
-
Hi, tbahre, looking at the Cura code, it appears to only report the filament used by extruder 1 and so I'm guessing you have a dual extruder machine and have sliced for extruder 2 only. Is that true?
-
@dc42, I can change the filament used comment in the gcode file to either report the total length (sum of all extruders) or as individual lengths, maybe like this example for two extruders:
; Filament used: 3.2m, 6.5m
i.e. just list the individual lengths separated by a comma (+ optional whitespace).
What do you think?
-
Hi, tbahre, looking at the Cura code, it appears to only report the filament used by extruder 1 and so I'm guessing you have a dual extruder machine and have sliced for extruder 2 only. Is that true?
Yes this is right as I’m using a e3d chimera. I’ve told cura to use extruder 2 (tool 1) since that’s the extruder I’m using right now (physically it’s the right hand nozzle).
Extruder 1 (tool 0, left hand nozzle) is empty and I’m not printing with it right now.
-
@dc42, I can change the filament used comment in the gcode file to either report the total length (sum of all extruders) or as individual lengths, maybe like this example for two extruders:
; Filament used: 3.2m, 6.5m
i.e. just list the individual lengths separated by a comma (+ optional whitespace).
What do you think?
RRF can handle multiple filament usage data, so we'd prefer the per-material usage. However, the format you propose doesn't match any of the 5 formats that we currently recognise. See line 1090 onwards of https://github.com/dc42/RepRapFirmware/blob/dev/src/PrintMonitor.cpp for the code we currenty use.
There is just time for me to add additional code to that function before the 1.21 release if there is a good reason not to use one of the existing supported formats.
What I would really like is for all slicers to provide a standardised (probably JSON) format comment at the start of the file, or at the end, or both if necessary, that RRF and other firmware/software can extract the important parameters from.
-
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
