Duet Web Control 2.0.0-RC5

fma

@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.

deckingman

@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.

fma

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!

deckingman

@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.

Red Sand Robot

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.

AlexLin

@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

chrishamm

@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.

AlexLin

@chrishamm Today I had no problems with the refreshing of the height map...keep my fingers crossed

garyd9

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.)

chrishamm

@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.

wilriker

@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.gcode change it to path/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).

fma

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.

kraegar

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.

chrishamm

@kraegar Yep, I think that has been fixed in RC6.