Duet Web Control 2.0.0-RC5

[dc42]

Yes I did mean M201, not M203.

The M204 S/T/P is a Marlin thing. They originally defined is to use S, then when some slicers were already using it, changed their minds and decided to use T and P instead. I had to look inside the Marlin source code to see how M204 is supposed to behave. Maybe some slicers are using T and P now, don't know. For RRF it's often better to use DAA instead.

[Phaedrux]

@dc42 @deckingman

This is what Slic3r uses for acceleration control. It's present in both original and PE versions. Setting the values to 0 will use the default, and setting default to 0 will use the firmware values. Default entry is used for travel moves. It uses M204 S# to change acceleration per move. At the end of the print it issues M204 S with the default value for travels.

Cura also has acceleration control, but uses M204 T and P when set to RepRap flavor. And at the end of the print will set both M204 P and T to the configured travel acceleration.

At least they use M204 instead of M201. They are optional, and disabled by default.

[deckingman]

@phaedrux Ahh. So if you set the "default" in the slicer to be the same as the configured value (as in config.g) at the end of a print, it will issue an M204 which should get you back to the configured (as in config.g) value yes? With the caveat that Slic3R will still use M204 S so if you use M204 with different T and P in config.g this will still be screwed yes?

[garyd9]

@chrishamm
Very minor issue with Duet Web Control 2.0.0-RC5:

1. The interface shouldn't give the option to "simulate file" or "start file" while it's already simulating a file. (It also should disable those options if a print is already running, but I didn't check that.)

or

2. If disabling the options isn't possible, it should pop up the resulting duet error message ("Error: M37: cannot simulate while a file is being printed")

[DocTrucker]

Likewise pressing the refresh button upsets an active print.

[Phaedrux]

@deckingman said in Duet Web Control 2.0.0-RC5:

@phaedrux Ahh. So if you set the "default" in the slicer to be the same as the configured value (as in config.g) at the end of a print, it will issue an M204 which should get you back to the configured (as in config.g) value yes? With the caveat that Slic3R will still use M204 S so if you use M204 with different T and P in config.g this will still be screwed yes?

Yes. But if you're already using the acceleration values in the slicer the next time you print the proper values will be applied anyway. So you'd only have a problem if going from printing a file that used slicer acceleration control to printing a file that doesn't use it.

[DocTrucker]

Not a huge fan of the way Slic3r handles the dynamic acceleration at the moment. I've commented about this on either this forum or RepRap quite recently. It issues the following two lines before a geometry block:

M201 X500 Y500
M204 P500 T500

I'd much rather the M201 value be left alone as this is set as a maximum in the config.g file.

[deckingman]

@doctrucker I'm getting confused now because @Phaedrux is saying that Slic3R only issues M204 "S" commands and doesn't use M201 at all. Now you are telling me that the dynamic acceleration changes both the M201 and the M204 P and T values.

Personally I find that having a config override file is bad enough because you have configuration settings in two different places. So I don't use it. Having the slicer messing with these things is even worse so I'm certainly not going to use that.

I'm not a fan of changing accelerations on a per move basis apart from print and non-print moves, because personally I think that hot viscous filament being forced through a nozzle has too much damping to react in a predictable way to sudden changes in force (which is what attempting to accelerate it comes down to).

[DocTrucker]

I think we need to move this out of the DWC thread? I realised it may have started due to a link the the DWC.

I'll download the latest dev and confirm that's still the way its done after ordering a few bits...

Edit: I'll start a new thread: - https://forum.duet3d.com/topic/9378/slicer-based-dynamic-acceleration-control

[DocTrucker]

The posative is that RC5 is much more stable than RC4.

The area to work on is the text entry bug. It keeps ocuring. I have to close my browser tab and reopen to clear it, F5 or ctrl F5 doesn't cut it.

[appjaws]

@doctrucker I can now add temperatures after a reload of DWC

[appjaws]

@appjaws still missing even after a reload of DWC

[kraegar]

RC5 is more stable than RC4 for me, but the files menu is now more annoying with the single click / double click mechanics. And I can't find any way to navigate back up in the directory tree, other than to refresh the page.

[NicoLab28]

Keyboard issues (arrows and others) in the editor
Print time wrong under S3d, tells me 1h 0s instead of 1h 35m
No print time, after printing, when you arrive late.
The time of the simultation not updated.

Bug on the selected tool, it appears in dark mode, but not in light. I still have not validated everything, but it seems that in dark mode, it always displays tool 0 even unsorted.

[chrishamm]

I just figured out why the inputs stop working, it's due to an update of the 3D library THREE that somehow blocks keyboard inputs once an instance of it is created. I will provide RC6 with a downgraded version of THREE later today.

@appjaws said in Duet Web Control 2.0.0-RC5:

The connect / disconnect button is missing

At the moment the Connect / Disconnect button is only available when running from localhost. I will add an option as soon as multi-machine support has been fully added (should be no big deal since the backend is already finished).

@wilriker said in Duet Web Control 2.0.0-RC5:

@chrishamm: one thing that I always do and that never works - but worked in DWC1 - is to use ESC to close the editor without saving.

Good point, I'll add this again in RC6.

@garyd9 said in Duet Web Control 2.0.0-RC5:

@chrishamm
Very minor issue with Duet Web Control 2.0.0-RC5:

1. The interface shouldn't give the option to "simulate file" or "start file" while it's already simulating a file. (It also should disable those options if a print is already running, but I didn't check that.)

or

2. If disabling the options isn't possible, it should pop up the resulting duet error message ("Error: M37: cannot simulate while a file is being printed")

Good point, these options will be hidden in RC6 if a file print is in progress.

@kraegar said in Duet Web Control 2.0.0-RC5:

RC5 is more stable than RC4 for me, but the files menu is now more annoying with the single click / double click mechanics. And I can't find any way to navigate back up in the directory tree, other than to refresh the page.

You can go up by clicking on the links that are displayed above the file list once you enter a sub-directory. I understand the concept of click/double-click needs to be changed for touch devices (which I will do in RC6) but what's the problem with activating items via double-click on a standard PC?

@nicolab28 said in Duet Web Control 2.0.0-RC5:

Keyboard issues (arrows and others) in the editor
Print time wrong under S3d, tells me 1h 0s instead of 1h 35m
No print time, after printing, when you arrive late.
The time of the simultation not updated.

Bug on the selected tool, it appears in dark mode, but not in light. I still have not validated everything, but it seems that in dark mode, it always displays tool 0 even unsorted.

Thanks for the bug report concerning the active tool highlighting, it will be fixed in RC6. Are the keyboard issues related to the height map problem I mentioned? The print stats will remain on the jobs page after a print finishes in RC6.

[wilriker]

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

[NicoLab28]

@chrishamm said in Duet Web Control 2.0.0-RC5:

Are the keyboard issues related to the height map problem I mentioned?

I was not in the heightmap, but in the macro editor. But I may be open at one point the heightmap.

I also noticed that I could not edit gcode anymore in the top bar. Neither do F5, I had to close the window for it to work again. So it's probably the same problem.
I must say that the DWC window is open 24/24, by the way, when I turn off the printer, and that I turn it on, the temperature curves are extremely long, it seemed to me that it resynchronized on the last minutes.
To check that library three.js do not have this problem too.

[AlexLin]

@wilriker yeah first couple of times I was annoyed but you get used to it. And it probably more common to select with one click and open/print with 2..

[kraegar]

@chrishamm Might be a personal thing. I find it unintuitive.

The "go up a directory" wasn't appearing for me previously, but is now. May have been due to a restart being needed or something odd.

[garyd9]

@chrishamm

More feedback on RC5 (used with Chrome 72.0.3626.119 on 64-bit windows):

Every now and then (and I can't seem to figure out steps to repeat) aspects of the UI stop working or disappear. Two areas I've seen so far:

1. The ability to move to a parent directory in the "G-Code Jobs" (the navigation breadcrumb disappears.)

2. The ability to manually type a heater temperature. (The drop down works to change temp, but clicking/highlighting the active temp and typing a new temp doesn't work - the page doesn't seem to see any keystrokes.)

Edit: Both of the above two issues can be resolved by reloading the page (F5 on Win10/64.)

Another issue which is disturbing is that the page doesn't update when it's not in the foreground. To be specific, with Chrome 72.0.3626.119 on 64-bit windows, if I have DWC2 in a tab, and another page in another tab - DWC only updates if the DWC tab is in front. This results in the title of the page (which shows the percent complete) NOT updating. Once the DWC tab is brought to the front, DWC plays "catchup" with any graphs and percentages. (It's actually amusing to watch.)

DWC1 would update even if not the foreground tab (which meant I could at least monitor the percent complete of a print job while doing things in other tabs.)