Duet Web Control 2.0.0-RC5

DocTrucker

Getting lots of dropped connections to duet v0.6 and v0.8.5 boards.

"Failed to maintain connection to ormerod2.local

o.job.file is undefined"

The progress bar was automatically at 100% when I started. The time estimation based on filament usage is remaining at 0. I'm running volumetric extrusion if that make any difference.

pkos

@chrishamm another new weird error then (it's the same print still going).
Every now and then I get:

Failed to maintain connection to printer.local
CORS request failed

Phaedrux

@deckingman said in Duet Web Control 2.0.0-RC4:

They most certainly should not mess with with things that are in ones' configuration files like for example, changing acceleration settings.

Ian, I would agree that I don't want the slicer to make changes without my instruction, but Slic3r PE won't change your acceleration settings of its own accord. It's a setting controlled by the user and it can be set to use the firmware values. Personally I like being able to set different acceleration values for different moves (lower first layer, slower for perimeters, higher for infill). I do wish that it used M204 P and T values properly for RepRap flavour, but it uses M204 S which sets both.

samlogan87

@chrishamm I took those on my computer, which I am running Chrome at 100% scale with a screen resolution of 1920x1080. The other issue is still that active temp settings not getting populated between devices.

Kind Regards,
Sam

chrishamm

Thanks again for your feedback, RC5 is out now - see https://github.com/chrishamm/DuetWebControl/releases/tag/2.0.0-RC5. Here the changelog once again:

Finished i18n support
Restructured Settings pages
Added the Diagnostics button again to the Settings page
Improved upload button appearance and file selection when opening the context menu
Excluded JSON files from uploads to /www again
Removed HTML links from file lists
Updated Vuetify framework
Make Vue globally accessible via window
Bug fix: Compensation button wraps correctly on mobile devices
Bug fix: Move buttons became unresponsive after the first click when performing manual height compensation
Bug fix: Temperature inputs were not properly initialized in some cases
Bug fix: Uploads of very big files could cause a crash in Chromium
Bug fix: When printing a file, a missing firstLayerHeight property could cause an unwanted disconnect
Bug fix: When restarting a machine, the job path would not be reset to the default path
Bug fix: When navigating into empty macro directories, the 'Go up' option was hidden
Bug fix: Sometimes the layer chart stayed empty
Bug fix: The tool fan could not be hidden
Bug fix: config.g could not be created if it did not exist before and fixed possible related race condition

Please let me know if any other problems show up. Unless I need to change anything in the layout, I think I can provide a first translation in the next release (which will be the actual 2.0.0 release if everything goes well).

deckingman

@phaedrux said in Duet Web Control 2.0.0-RC5:

Ian, I would agree that I don't want the slicer to make changes without my instruction, but Slic3r PE won't change your acceleration settings of its own accord. It's a setting controlled by the user and it can be set to use the firmware values. Personally I like being able to set different acceleration values for different moves (lower first layer, slower for perimeters, higher for infill). I do wish that it used M204 P and T values properly for RepRap flavour, but it uses M204 S which sets both.

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.

Unless you are saying the slicer is somehow clever enough to read the config.g file to ascertain the original (firmware) value and then reinsert this into the end gcode. If that's the case, then I guess it would be acceptable.

I don't reply to many posts these days but I do read most of them and I have noticed an increase in the number of people have had print issues which mysteriously fix themselves. So I can't help wondering if the root cause might be slicers doing things to machine configuration settings?...........

DocTrucker

@chrishamm Can't type temperatures in? Having to manually use the G10 command to set tool temps.

Bed level reload works fine, hope to report it is more stable very shortly.

DocTrucker

It's not accepting any typed input on the gcode line, console or temperatures.

Reverted back to RC3.

Running through Firefox on Ubuntu onto a Duet v0.8.5.

chrishamm

@DocTrucker I'm sorry but I cannot reproduce your problem. It's all working as expected on Windows, Linux, Android and OS X. Is there anything particular that causes this behaviour? Does reloading the page help?

DocTrucker

Odd. It's working fine when reverted back to RC3.

I'll swap back after this test has completed in a few minutes.

DocTrucker

Yeah something odd there after the update. Seems fine now. False alarm!

Thanks.

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.