New firmware 1.20 Release Candidate 2 - please try it!
-
Installed on kossel XL, 9-hour lithophane print completed successfully.
-
I'm about to start a print but can already confirm that M28/M29 is working as expected again, thanks!
-
-
So, in practice, I'd set all four heaters to my target temperature (e.g. 80°C) and the Duet takes care that each zone reaches 80°C and stays at it. I know the zones will affect each other, but in the end, the Duet will figure out which zone to heat, right?
Yes, that is right.
-
So, in practice, I'd set all four heaters to my target temperature (e.g. 80°C) and the Duet takes care that each zone reaches 80°C and stays at it. I know the zones will affect each other, but in the end, the Duet will figure out which zone to heat, right?
That's correct. Currently you will need to send M140 P0 S80, M140 P1 S80, M140 P2 S80 and M140 P3 S80. Then M116 to wait for them all to reach temperature. M140 with no P parameter defaults to P0.
I am considering making a couple of changes:
1. Use M140 H0:2:3:4 to configure multiple bed heaters, instead of M140 P0 H0, M140 P1 H3 etc.
2. Make M140 Sxxx (also M190) with no P parameter set the temperature of all bed heaters. So the bed temperature commands generated by slicers would apply to all bed heaters by default.
These changes would also apply to the M141 command to configure and control chamber heaters.
Thoughts?
-
I don't have a multiple-zone bed, but that seems like a sounds scheme, if you don't specify then it applies to the entire bed, if you want to zone things off then you would expect to have to be more specific.
-
So, in practice, I'd set all four heaters to my target temperature (e.g. 80°C) and the Duet takes care that each zone reaches 80°C and stays at it. I know the zones will affect each other, but in the end, the Duet will figure out which zone to heat, right?
That's correct. Currently you will need to send M140 P0 S80, M140 P1 S80, M140 P2 S80 and M140 P3 S80. Then M116 to wait for them all to reach temperature. M140 with no P parameter defaults to P0.
I am considering making a couple of changes:
1. Use M140 H0:2:3:4 to configure multiple bed heaters, instead of M140 P0 H0, M140 P1 H3 etc.
2. Make M140 Sxxx (also M190) with no P parameter set the temperature of all bed heaters. So the bed temperature commands generated by slicers would apply to all bed heaters by default.
These changes would also apply to the M141 command to configure and control chamber heaters.
Thoughts?
Exactly what I thought of as a final solution. Sounds awesome. In the meantime, I have no problem to set each heater to temperature, since I use Macros on my Duet to control hotend/heatbed temperature (I have macros for each filament I use, with settings for retraction, pressure advance, etc …) so I don't have to bother with the Slicer settings/profiles (Simplify3D). Maybe the DWC could have a third filament macro type, like "print", beside the "load" and "unload"
Will it be possible to add an additional thermistor to that heater combination? E.g. have a fifth one sitting in the center of the bed? Since the silicone heaters may have a different temperature than the actual build platform itself, that'd be handy to have the possibility to add more thermistor than heaters.
-
having trouble with Wifi disconnects in RC2. I updated from an earlier beta where everything was fine. Cant seem to stay connected for more than 5 mins now. I just added a duex5 and rewired everything so there is a chance I tweaked something in the process but im pretty sure I had no issues after the rewire until RC2…. Anyone else? Is the last 19 beta living somewhere to roll back to?
anything I can do to help identify a bug in either the version or my own work? Im not super familiar with the debugging process but im pretty good at following directions.
Also the new web interface killed my dark theme. I had to roll that back to 19.3
Which version of DuetWiFiServer are you using?
I was using 1.20beta11… Ill try beta10. I thought the update notes said to use beta11 when it was available
-
I printed overnight with it on my corexy, no issues though I didn't have time to check the console this morning before leaving.
-
Hi David
1.20RC2 ok for me on Scara
Thanks ! -
I wrote this post when testing RC1 with DWC 1.19.3 but then realised it might have been a slicer issue so changed the text to strike through. However, I am printing another set of parts which are sliced correctly and am having the same issue, so here is the post again:
I've just noticed something that may be a firmware issue but may be a DWC thing. I'm currently printing an object using all 5 extruders with a mixing ratio of 0.20:0.20:0.20:0.20:0.20 and notice that on the Print Status page of DWC, in the Machine Status panel top right, under Head Position I have Extruder Drives but it's only showing incrementing values for Drives
3 to 52 to 4 - Drives1 and 20 and 1 are showing 0.0. (and yes, all 5 extruders are indeed moving and all at the same speed). To be clear, the values for drives 2 to 4 are increasing as the print progresses but drives 0 and 1 are stuck at zero.I've no idea if this issue applies to other mixing ratios - it's not something I take much notice of. For the same reason, this issue could have been present for some time and not specifically related to 1.20RC1 release.
So the issue was first noticed using firmware 1.20RC1 and DWC 1.19.3 and persists using 1.20RC2 and DWC 1.20-RC2. But as stated above, the problem may well pre-date both of these and may have been present for some considerable time.
I can't see anything obviously amiss with the gcode file, all the commented stuff looks to be correct but if someone tells me what to look for, I'll check.
I'm only about 18% into this print but the estimations are 4 hrs for filament, 8 hrs for file and 15 hrs for layers and for this particular print, I'd say that's correct. By that I mean that the print time based on total filament usage is probably correct and is being based on all 5 extruders despite 0 and 1 showing zero in the display area.
One other teeny weeny thing in DWC. On the print status page, bottom right is "Extrusion factors" and they are all set to 100% but the lable for the top one (Extruder 0) is offset to the right whereas all the other labels are directly above the blue dot.
-
I am testing the gcode M81 S1 and found that the ATX shutdown is occurring at a temperature well below that programmed in the thermostatic fan.
For example, here I use the following fan:
M106 P0 L0.7 I0 F500 H1 T80
and the atx shutdown temperature is occurring at 44C.
Was this supposed to be happening?ps. I'm using 1.20rc2 in a duet wifi.
-
One other teeny weeny thing in DWC. On the print status page, bottom right is "Extrusion factors" and they are all set to 100% but the lable for the top one (Extruder 0) is offset to the right whereas all the other labels are directly above the blue dot.
Thanks for the hint, I'll fix that.
-
I am testing the gcode M81 S1 and found that the ATX shutdown is occurring at a temperature well below that programmed in the thermostatic fan.
For example, here I use the following fan:
M106 P0 L0.7 I0 F500 H1 T80
and the atx shutdown temperature is occurring at 44C.
Was this supposed to be happening?ps. I'm using 1.20rc2 in a duet wifi.
I expect you have left Fan0 at its default setting of thermostatically controlled from heater 1 at temperature 45C.
-
Im having the same web interface issues. Upgraded to the latest of ALL firmwares (machine,WebUI, WIFI), and has trouble connecting via browser. According to my router it IS showing up with a good signal, but I cant seem to get it to connect - and stay connected after 5 mins.
-
This is very strange behaviour. Using the sliders on DWC to adjust the extrusion factor, what happens is that if I use the top slider which is extruder 0, I can drag it back and forth as normal but when I release the slider, the extruder below (extruder 1) jumps to the value that extruder 0 was at when I released the slider, and extruder 0 jump back to 100% The same happens for all the others. So for example, if extruder 1 is at 100% and I drag the slider to 90% then release it, extruder 2 will jump to 90% and extruder 1 will jump back to 100%. The same happens for all the others with the slight exemption that the last one (extruder 5) will jump back to it's value before the slider was moved but none of the other sliders move. I suspect that if I had a sixth extruder, this is the one that would change.
It's rather as if the labels have been changed from what used to be 1 to 5 to what is now 0 to 4 but somewhere else in the code, a "1" is being added to the drive number (or the old numbering system is being used).
Oh, and for some reason, the offset on the label for the top extruder that I reported earlier, has fixed itself and I can't reproduce it.
Firmware Name: RepRapFirmware for Duet Ethernet
Firmware Electronics: Duet Ethernet 1.0 + DueX5
Firmware Version: 1.20RC2 (2017-12-13)
Web Interface Version: 1.20-RC2Edit. What I wrote above is not quite accurate. The slider for Extruder 0 seems to adjust both extruders 0 and 1 when released. So dragging the slider for extruder 0 to say 88& then releasing it, will cause both extruders 0 and 1 to jump to 88%. But the dragging the slider for extruder 1 to say 95% then releasing it, will cause extruder 2 to jump to 95% and extruder1 will jump back to 88%.
Further edit. Sending M221 S98 D0 from the console causes the slider for Extruder 1 to move to 98%. M221 S98 D1 causes slider for extruder 2 to move. etc.
-
Thanks again, it should be fixed in my new RC3 which is available here: https://github.com/chrishamm/DuetWebControl/blob/dev/DuetWebControl-1.20-RC3.zip
Please let me know if you find anything else.
-
having trouble with Wifi disconnects in RC2. I updated from an earlier beta where everything was fine. Cant seem to stay connected for more than 5 mins now. I just added a duex5 and rewired everything so there is a chance I tweaked something in the process but im pretty sure I had no issues after the rewire until RC2…. Anyone else? Is the last 19 beta living somewhere to roll back to?
anything I can do to help identify a bug in either the version or my own work? Im not super familiar with the debugging process but im pretty good at following directions.
Also the new web interface killed my dark theme. I had to roll that back to 19.3
Which version of DuetWiFiServer are you using?
I was using 1.20beta11… Ill try beta10. I thought the update notes said to use beta11 when it was available
I may have fixed the issue. The name of the printer on my router was different than the name of the printer in the config.g file. For some reason the new firmware made my router unhappy. I have this issue sometimes with raspberry pi's and esp8266 boards that have static IPs. Not sure what changes made this happen or if it was just coincidence. I wonder if others have this issue.
Cheers
-
The only remark I can make is the general waste of new M-codes.
E.g. why do you implement a new M913 command to reduce stepper current? There is the well known M84 ( stepper off ) that could be enhanced with M84 X50 Y50 Z50 to reduce current. That's much easier to remember for customers
I have many other examples from earlier RRF releases, where I shrugged it off by thinking:"They might have a bigger picture about it, than me"
M568 extruder mixing on/off: could have been a simple parameter in the M567 mixing ratio definition.
M550 ( name of the printer) and M667 ( type of the printer ) could be one command. Just add the type of the printer as parameter.I could rant on, but I have to be careful with my weak heart
Q: Am I right, that V1.20 will be be the last RADDS compatible version?
Best regards
O_Lampe -
If you read the Wiki M568 isn't a new command - it's been deprecated and is no longer necessary.
M913 isn't new in this release either - it's been around for ages. However I do agree that it seems pretty pointless when we can use M906 to set/change motor current at any time.
M667 looks like it's being deprecated too as M669 serves the same purpose. I guess M667 could be taken out but that would mean that everyone using a Duet on a CoreXY would have to change their config.g to use M667 instead. However, M550 serves a completely different purpose and I personally wouldn't want to have the machine name in the same line that defines the kinematics.
