Duet Web Control 2.0.0-RC5

[dc42]

@deckingman said in Duet Web Control 2.0.0-RC5:

Yes, I take your point. But you are an experienced user so you will have the sense to put your "normal" (as set in config.g) M204 in the slicer end gcode - at least I hope you do.
The danger lies with inexperienced users who tick the box to see what it does. Then they find it gives unexpected results so untick the box, only to find that they still get unexpected results because the last M204, issued by the slicer, will be retained - at least until the printer is power cycled and M204 from config.g is read in again.

If this is a serious issue, then perhaps the M204 settings should be set per job/per input channel, in the same way that feed rate and relative/absolute extrusion is?

[appjaws]

On the machine setting page I cannot input another temperature.
I can delete but not add, the curser just sits by the number but the field will not accept an input.

[appjaws]

The connect / disconnect button is missing

[DocTrucker]

@appjaws That happened to me too. Installed RC3 for a build wnet back to RC5 and it was fine. CTRL & F5?

[DocTrucker]

The default behaviour of left clicking on the builds @ system files has changed. Was this intentional? I now have to right click on builds to select start, or right click and edit to tweak config.g etc.

[deckingman]

@dc42 said in Duet Web Control 2.0.0-RC5:
......................

If this is a serious issue, then perhaps the M204 settings should be set per job/per input channel, in the same way that feed rate and relative/absolute extrusion is?

In the slicer you mean? Maybe. But it's not quite the same thing as feedrate and absolute/relative extrusion. We don't set feedrate per move in config.g - just the maximum feedrate limit. So having the slicer set feedrate for a move doesn't override a configuration setting and it isn't a "global" setting the way that M204 is. We set the firmware to expect either relative or absolute extrusion, then set the slicer to generate those types of move.

Although I do take your point and always have an "M83" as part of the start gcode file even though that is what I have in config.g. But then again, that's the point about letting the slicer change the acceleration values. I guess it's OK if users remember to add their "default", as configured, setting to their end gcode so that another print would start by using that value, rather than a value which is a legacy of the last move from a previous print.

[dc42]

@deckingman said in Duet Web Control 2.0.0-RC5:

@dc42 said in Duet Web Control 2.0.0-RC5:
......................

If this is a serious issue, then perhaps the M204 settings should be set per job/per input channel, in the same way that feed rate and relative/absolute extrusion is?

In the slicer you mean?

No, I meant in RRF. At the start of every job, the M204 acceleration would default to 10000 as it currently does for the first job (so the M203 M201 limits will be used instead), unless you chose to include a M204 command in config.g.

[wilriker]

@doctrucker said in Duet Web Control 2.0.0-RC5:

The default behaviour of left clicking on the builds @ system files has changed. Was this intentional? I now have to right click on builds to select start, or right click and edit to tweak config.g etc.

I noticed this as well. Primarily the editing of config.g. I realized that a double-click will open the editor.

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

[deckingman]

@dc42 said in Duet Web Control 2.0.0-RC5:

No, I meant in RRF. At the start of every job, the M204 acceleration would default to 10000 as it currently does for the first job (so the M203 limits will be used instead), unless you chose to include a M204 command in config.g.

Sorry, I'm a bit under the weather right now (Kidney infection again) so my mental faculties, are performing even less well than usual.

I guess you meant the M201 (max acceleration) and not the M203 (max feedrate)?

But I'm still not sure how your suggestion would help. I do use M204 in my config.g to set different print and travel accelerations. I thought that's whole point of it. I guess on reflection, your idea would effectively cancel out the legacy M204 setting generated by the slicer but only for users who don't use M204 in the first place.

And as @Phaedrux tells me that the slicer uses M204 Snn instead of "T" and "P" parameters, that means that the slicer would effectively disable the separate print and travel acceleration settings that I have in my configuration files. Which means that not only is the slicer messing with configuration but it is effectively disabling a firmware feature. That's not how it should be IMO.

[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