Duet Web Control 2.0.0-RC5
-
@deckingman said in Duet Web Control 2.0.0-RC4:
@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.
True; but:
Every layer change, I get:
Failed to maintain connection to printer.local
Cannot set property 'firstLayerHeight' of undefinedis a bug. RRF/DWC should not error out if the information wasn't found in the GCode file.
-
@deckingman said in Duet Web Control 2.0.0-RC4:
@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.
God dammit.... Changed from S3D to Slic3r PE due to S3D being to slow on devlopment, and now I might have to go to Cura? -.- Well, might be worth to try it with the new GUI.
-
I'm kinda looking forward to Pathio being the next big thing (way too feature starved at this point, but love the concept), or maybe, if S3D 5.0 is amazing - stick with that. I can't stand Cura
I chose Slic3r PE for my prints right now to get the strongest possible parts for a new HEVO, while not rattling the printer to bits with honeycomb. Gyroid is way easier on the printer. -
Thanks for your feedback so far.
@samlogan87 Are you using any kind of scaling in your browser? It looks good to me on both Windows and Linux at 100%
@pkos I'll expand theming support in the future but for now it is limited to internal changes. Would it help to make the links in the file lists look like the other cells (e.g. black in the normal theme and white in the dark theme)? Perhaps I could change the font colors of the fan selectors to white in the dark theme too.
Thanks for reporting the disconnect problem, I'll release another RC shortly which is going to fix it.
@deckingman As long as Slic3r PE generates proper G-code I see no reason why it would become incompatible to RRF.
Duet software engineer
-
@chrishamm I like the idea of the blue to set it aside from regular text.
I am wondering if maybe making it a way lighter blue - so the contrast between the text and the background is bigger - would help blind people like your's truly -
I see the same error:
Failed to maintain connection to printer.local
Cannot set property 'firstLayerHeight' of undefinedAnd I'm using Cura (3.6.0)
-
@martin1454 said in Duet Web Control 2.0.0-RC4:
God dammit.... Changed from S3D to Slic3r PE due to S3D being to slow on devlopment, and now I might have to go to Cura? -.- Well, might be worth to try it with the new GUI.
I use the latest dev build of Slic3R (non Prusa) https://dl.slic3r.org/dev/
It seems to be more actively developed than it used to be.
I've just downloaded the latest version although I haven't yet had time to play with it. My other version of 1.3.1 dev was dated June. This one is dated 10th Feb this year. New things I've noticed at first glance are:
"Use adaptive slicing" - automatically determine layer heights by the object topology instead of using a static value.
"Match horizontal surfaces"
"Minimum shell thickness" - Alternative method of configuring perimeters - additional perimeters and/or solid top bottom layers as necessary.
"Fill gaps"
A huge number of new options for generating support material.
Print server upload - can be set to Octoprint or Duet.Also tick boxes for:
"Use set and Wait Gcode extruder" and "Use set and wait Gcode bed"And it doesn't override configured acceleration settings and so forth, the way that PE does. And multi colour/material printing is still more "generic" rather than being biased towards using a Prusa style MMU.
For my particular usage case, non PE Slic3R is still by far the best slicer (but I do use mixing hot ends).
-
Mmm, I will give a try to Slic3r non-PE...
About slicer and firmware, it becomes hard to define where the first should end, and where second should start. A lot of ideas for improvement need that both evolve together (for example, canceling an objet when printing multiple objects at the same time). In another topic, Ian said he defines temperatures on firmware side, while another guy prefers defining them in the slicer... There are more and more overlapping features.
As E3D adopted Duet boards for their tool changer machine, and as they started to develop a slicer themselves, it may be a nice opportunity to have coherent devs between slicer and firmware
Frédéric
-
Just want to confirm the "cannot set property "first layerheight of undefined'" and disconnect issue. This is a file sliced with the latest S3D version 4.1.1.
-
@fma IMO slicers should be firmware agnostic. They most certainly should not mess with with things that are in ones' configuration files like for example, changing acceleration settings.
The danger is that the slicer cannot "know" how the machine has been configured and what hardware is in use. So if it makes changes to things which are in the configuration file, in order to slice a particular object, then it cannot "know" what value to reset things to at the end of a print. So for example, it can set speeds for various moves by inserting a feedrate ("F" parameter) into a G1 command, but it should not insert M203 commands to do the same thing (not that they do, but that's just an example of how it could be done incorrectly).
-
I agree. On the other hand, instead of setting the speeds, they could use different G-Codes for different parts (walls, infill, support), so the user could adjust the different speeds during the print, on firmware side.
This is an example where both slicer and firmware should work together to implement such feature, or each dev. team will wait for the other team to implement it first
I like the fact that I can use whatever slicer I want, but this also lead to keep old stuff for compatibility reasons, which is sometimes a pain in the bottom.
I don't suggest that a firmware must only work with a specific slicer, but having teams working more closely would lead to amazing features.
-
@pkos said in Duet Web Control 2.0.0-RC4:
Every layer change, I get:
Failed to maintain connection to printer.local
Cannot set property 'firstLayerHeight' of undefinedIt's even worse when you want to print something in the vase mode. Then you get that error every second. It's very annoying...
-
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.
-
@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 -
@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.
-
@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 -
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 conditionPlease 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).
Duet software engineer
-
@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?...........
-
@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.
-
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.
