Duet Web Control 2.0.0-RC5
-
Some more minor RC5 issues:
When printing something that hasn't been simulated, "Current Job - Status" shows a time estimate based on simulation. (I'm guessing that it's actually showing the useless time WAG that my slicer generates? Is so, should the label be "based on slicer" instead of "based on simulation"?)
While simulating a print, "Current Job - Status" is showing an estimation "based on simulation." (Again, I'm guessing that this number is actually based on the slicer WAG if the file hasn't been simulated before.) Even if there was an accurate simulated time in the gcode file, this number should be BLANK while simulating (as it can't possibly make sense.)
-
@chrishamm I think I have found another issue. I don't remember if this did it in the v1 DWC but if a job finishes, the baby stepping doesn't clear. It seems that when you relevel your bed and do not clear the baby stepping, it sets the zero point at the particular baby stepping height and you need to baby step down again to suit the print.
-
@samlogan87 Think that's a firmware rather than DWC issue. There's been some discussion about it recently.
I've still got to get my head around why baby stepping exists rather than just having a wrapper around say 'G10 P0 Z...' for the first tool.
-
@ctilley79 said in Duet Web Control 2.0.0-RC5:
@deckingman said in Duet Web Control 2.0.0-RC5:
@pkos Unfortunately, Prusa version of Slic3R is becoming more and more biased towards it being used with Prusa firmware and every release sees this integration becoming tighter and tighter.
So should we expect RepRap firmware to be changed to support a specific slicer? To my mind, the slicer should be firmware agnostic but Prusa Slic3R has started doing things differently.
I disagree with this statement. For example, they added the option to upload directly to a Duet WiFi from within slic3r pe. Not sure how your statement is in the least bit accurate.
Fair enough. You are entitled to your opinion. Mine is based on certain facts so I'd be interested to know what yours is based on. Let's leave aside the upload to Duet feature because that's common to both versions of slic3r and as @Phaedrux pointed out, the request for that integration originated here on these forums, not from Prusa.
I use mixing hot ends. So I might have say a 5 colour Diamond hot end with 5 filaments fully loaded at all times, each filament being driven by a single extruder. A tool can use any number of these extruders so for example to produce say Orange, I can mix Red and Yellow. Or if I wanted say dark Green, I might use Blue, Yellow and Black. And so forth.
So having 10 or more tools defined is not unreasonable. Plain "vanilla" slicr3r" doesn't care about this. For multi coloured objects, I can assign any tool number to any part. Even tool number 9,999 if I wanted to. All the slicer has to do is insert the correct tool number at the appropriate point in the file, which "vanilla" slic3r does admirably well.
Prusa printers don't have mixing hot ends. For multi colour printing, they use their own MMU unit. So the concept of mixing hot ends is alien to Prusa and they have disabled some of the features of slic3r in their version. For example, Prusa slic3r won't allow me to assign any tool to an object part if that tool number is greater than the number of extruders defined in the printer profile. It assumes that every tool must have a single extruder - not only does it assume that - it forces me to set up my printer that way. So if I want to assign say tools 3, 7 and 9 to parts of an object, I'd first have to define a printer profile with 10 extruders even though only 5 physically exist. Then to make matters worse, the slicer can put filament specific commands into the gcode file. But for that to work, every tool has to have a single filament assigned to it and every fiaments has to have a "profile".
So if I define a tool as say tool 15, I don't need to do anything differently using "vanilla" slic3r. If I want to use that on PE Slic3R, I'd have to define a machine with 15 or more extruders, and the set up filament profiles for 15 different filaments, even though they may all be combinations of the same PLA.
So, in my opinion PE Slic3R is becoming too biased towards Prusa printers and I continue to hold that opinion.
-
@deckingman said in Duet Web Control 2.0.0-RC5:
So, in my opinion PE Slic3R is becoming too biased towards Prusa printers and I continue to hold that opinion.
I agree. Another annoying example: if you choose Marlin as flavor, it always set speed/accel/jerk params defined in Slic3rPE...
But this does not mean that a slicer and a firmware teams should not work together: I think it is mandatory to introduce new robust features. And it is possible to do it without breaking compatibility with other firmwares; it is just a matter of options to turn on/off.
And once these features are there, other firmware teams may add them.
-
@fma Yes. It'd be nice to see the Duet team, or someone closely allied to them, write a slicer. I wouldn't be at all averse to using a RRF specific slicer - one that is actually tailored specifically to our firmware and which would evolve as the firmware continues to do.
-
Maybe E3D's Pathio, as they chose the Duet for their tool changing machine? But hoping they won't make the same mistakes as Prusa did on Slic3rPE!
-
@fma AFAIK, Pathio is (or will be) another "universal" slicer, which is fine.
I wouldn't necessary say that Prusa have made any mistakes. It's just that it's closely aligned to Prusa's printers and way of doing things - which is fair enough. Nobody has to use it. I guess people choose to use it because they perceive some benefit in some of the features it offers. For me, the price I have to pay if I wanted to use those features is losing functionality in other respects and that functionality is more important than the new "features". So the price I have to pay is too high.What we need is a Slic3R DE - "Duet Edition" rather than PE which is Prusa Edition.
-
So I updated to RC5 because I was also having an issue where my mesh grid height map would not display, but RC5 has not fixed this issue either.
The software compensation for printing is still working like a charm, I would just like to see the actual height map so I can tell if my gantry is parallel to my print bed.
-
@red-sand-robot agree I always have to switch back to reprap.html to perform levelling and see the updated mesh.Previously I got 'no file found' but F5 helped... , now it doesn't work at all
I think this such a vital function that it should be fixed before release -
@wilriker said in Duet Web Control 2.0.0-RC5:
@chrishamm said in Duet Web Control 2.0.0-RC5:
but what's the problem with activating items via double-click on a standard PC?
Mainly because we are all used to using single-clicks to open the editor/start the print.
Fair enough, I'll change that again in RC6.
@garyd9 said in Duet Web Control 2.0.0-RC5:
Some more minor RC5 issues:
When printing something that hasn't been simulated, "Current Job - Status" shows a time estimate based on simulation. (I'm guessing that it's actually showing the useless time WAG that my slicer generates? Is so, should the label be "based on slicer" instead of "based on simulation"?)
While simulating a print, "Current Job - Status" is showing an estimation "based on simulation." (Again, I'm guessing that this number is actually based on the slicer WAG if the file hasn't been simulated before.) Even if there was an accurate simulated time in the gcode file, this number should be BLANK while simulating (as it can't possibly make sense.)
Yes, that makes sense. I will introduce a new column for the slicer-based estimation. When simulating a file both the slicer-based and simulation-based estimations will be hidden.
@samlogan87 said in Duet Web Control 2.0.0-RC5:
@chrishamm I think I have found another issue. I don't remember if this did it in the v1 DWC but if a job finishes, the baby stepping doesn't clear. It seems that when you relevel your bed and do not clear the baby stepping, it sets the zero point at the particular baby stepping height and you need to baby step down again to suit the print.
This is more a configuration issue than an issue with DWC - the values it displays are correct so you may want to clear the babystepping in your end G-code.
@Red-Sand-Robot @AlexLin Can you provide your heightmap.csv so I can try to reproduce your problem? I haven't had any issues with it so far. RC6 will also reload the heightmap automatically once 'heightmap.csv' shows up in a G-code response.
-
@chrishamm Today I had no problems with the refreshing of the height map...keep my fingers crossed
-
Ummm.. perhaps a stupid question, but with DWC2 (RC5), how do I copy gcode files from one directory to another?
In DWC1, I could just drag them and drop them into the destination folder (or to a parent folder if I drop the file on the breadcrumb.) When I try to do the same with DWC2RC5, the mouse cursor turns into a circle with a line through it (indicating something that isn't allowed.)
This is especially annoying when used with a slicer that uploads gcode files to the root g-code directory of the duet...
(My current work-around is to force DWC1 when I need to move files around.)
"I'm not saying that you are wrong - I'm just trying to fit it into my real world simulated experience."
-
@garyd9 said in Duet Web Control 2.0.0-RC5:
Ummm.. perhaps a stupid question, but with DWC2 (RC5), how do I copy gcode files from one directory to another?
In DWC1, I could just drag them and drop them into the destination folder (or to a parent folder if I drop the file on the breadcrumb.) When I try to do the same with DWC2RC5, the mouse cursor turns into a circle with a line through it (indicating something that isn't allowed.)
This is especially annoying when used with a slicer that uploads gcode files to the root g-code directory of the duet...
(My current work-around is to force DWC1 when I need to move files around.)
Thank you for your report, it looks like drag&drop was no longer working in Chrome-based browsers due to "security reasons". Apparently Chrome does not allow reading user payloads from the object being dragged whereas Firefox allows this. It's been fixed in RC6.
-
@garyd9 said in Duet Web Control 2.0.0-RC5:
This is especially annoying when used with a slicer that uploads gcode files to the root g-code directory of the duet...
Don't know which slicer you use but when uploading through Cura RRF plugin you can specify the path it should end up by simply adding it to the file name, e.g. instead of just using
sliced_object.gcodechange it topath/it/should/go/sliced_object.gcode.This might also work for other upload plugins. I am not sure though if the path has to exist or not (I think it will be created if missing).
-
It also works from Slic3rPE (the version I have fails if using spaces, but it may have been fixed in latest releases).
I think missing dirs are created. -
I think I've figured out why sometimes the ability to navigate up one directory is missing. If you're in a subdirectory and lose connection (say, due to powering off), when I reconnect it displays the file list for that sub directory I was in previously, but then when I try to print one it says that file isn't found, but is listing the main gcode directory, not the subdirectory for the file list it's displaying. There is no ability to move up one directory (because it already thinks I'm at the "root". If I refresh, it takes me back to my main gcode directory, and I can then navigate around normally.
Co-Creator of the RailcoreII CoreXY printer
https://www.thingiverse.com/thing:2407174 -
@kraegar Yep, I think that has been fixed in RC6.
