Why don't you use Cura slicer?
-
Incidentally, I shall be meeting some of the Cura devs later this month so I shall be sure to quiz them as to how the manual support capability is coming along.
Thanks, will be interesting to see what they say!
-
I just published a new Cura-DuetRRF plugin version to fix an incompatibility with Cura 3.2:
https://github.com/Kriechi/Cura-DuetRRFPlugin/releases/tag/v0.0.5This plugin allows you to directly upload a g-code file to a DuetWifi/DuetEthernet/and older Duets and start the print.
You can even "just upload", "upload & print", or "upload & simulate" - all from within Cura.
https://github.com/Kriechi/Cura-DuetRRFPlugin -
resam, thanks for the hard work!!! Just FYI it crashes on Cura 3.2.1. It happens on print or simulate.
Is it possible to make this plugin work for the monitor screen and allow movement and temp changes?
-
meh - I can't keep up with Cura releases
I'll take a look in the next days…
-
Since I just butted my head against it here is stupid, trivial UI suggestion; a way to 'clone' a printer definition.
At the moment the only way is to add a New printer via the wizard/dialog, but I wanted to make a new config for my machine while it is (temporarily) wearing a much bigger nozzle.
I did it by following the dialog, then copy + pasting start/stop gcodes from the old config, and it was rather tedious. [Maybe I culd have hacked it more easily directly in the config but I wasnt in the mood]. It was trivial to do this in slic3r, so I was a bit narked when the same operation in Cura turned into a 'open,copy,close,open new,paste,close,open old,copy next' session
-
-
Thanks resam! I was somehow using an old version. Updated to 0.0.6 and I will try later. I'm looking forward to trying out Cura again
-
Since I just butted my head against it here is stupid, trivial UI suggestion; a way to 'clone' a printer definition.
At the moment the only way is to add a New printer via the wizard/dialog, but I wanted to make a new config for my machine while it is (temporarily) wearing a much bigger nozzle.
I did it by following the dialog, then copy + pasting start/stop gcodes from the old config, and it was rather tedious. [Maybe I culd have hacked it more easily directly in the config but I wasnt in the mood]. It was trivial to do this in slic3r, so I was a bit narked when the same operation in Cura turned into a 'open,copy,close,open new,paste,close,open old,copy next' session+1 for this
-
Where is the setting in Cura to use a higher temperature for the first layer? I couldn't find it when I sliced a model today and ended up changing the temperature manually.
-
Material : Printing Temperature Initial Layer on 3.2
-
Slighty off topic as I am giving Cura slicer a try, Just started using version (3.2.1) and found I'm having this issue outlined in the image below.
Please correct me if I'm wrong but I'm pretty sure this is a problem generated by Cura.
-
Not sure what's wrong there, could you please post a link to the gcode so I can investigate.
-
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
