New Edge firmware 1.18beta1
-
I have just released this on github. Here is the change list:
New/improved features:
-
Baby stepping is now implemented using the M290 command. The accumulated baby stepping amount is reported in M408 replies.
-
Faster and easier-to-use auto tune algorithm with more consistent dead time measurement. You no longer need to provide a P parameter unless you have an over-powered heater and you normally set a PWM limit on it.
-
M109, M190 and M191 commands now send the temperatures once a second if the command came from the USB port and Marlin emulation is chosen
-
The name of the firmware file to load is now passed to IAP, so that iap4e.bin can be used on both the Duet WiFi and the Duet Ethernet
-
Reduced the Duet WiFi VIN over-voltage detection threshold from 29.5V to 29.0V
Bug fixes:
-
On the Duet WiFi, if you sent command M122 while the machine was printing then occasionally it would stop and reset due to a watchdog timeout
-
If multiple input sources sent overlapping G4 (dwell) commands, either or both of them would not be executed correctly
If you decide to install this firmware, please try the new auto tuning algorithm and let me know how well it works for you.
Important: the G92 R1 command that was used to command baby stepping in version 1.18alpha is no longer supported.
If you want to test baby stepping, then for now I suggest you create a "Baby step up" macro file containing command M290 S0.05 and a "Baby step down" macro containing M290 S-0.05. Change the value 0.05 to be a suitable value for the first layer height you normally use. Baby stepping buttons will be added to DWC and PanelDue in due course.
-
-
Hi David,
thanks for responding with the aid fit the G92 R1 Z0.05 command fit the previous instantiation of the firm; i noticed that command is now deprecated and we are to use M290 based make going forward until the incorporation into DWC and Paneldue. The one question I had forgotten to ask of you on that thread, but that still very much applies here is whether the command given fire babystepping is absolute or relative, ie. Can I press the macro repeatedly for incremental 0.05mm adjustments up until the 1mm range limit, or need I write multiple macros for 0.05, 0.10, etc? -
Baby stepping is cumulative. See https://duet3d.com/wiki/G-code#M290:_Baby_stepping.
-
Just tried the auto tune on your 1.18beta1 firmware. It performed really well and was close to the previous settings, all except the time constant for the bed heater which ended up at 1084.8 which is almost 10 time the previous setting.
Entered the settings in config and restarted the printer and all is OK.I think the difference in the bed settings is the fact that I now have a base board under the heater with glass on top, previously I just had the heater and glass on top (no base board)
So thank you for your continued support, all is well in the world of duetwifi.
-
I had a problem with my hotend not beeing stable at 240° when printing. After a PID tune with the 1.18beta1 the problem is almost gone, I still have a fluctuation of 2-4° when printing, but it prints OK. It measured a D of 5.0, with 1.17 it was something around 12.0.
-
So is baby stepping similar to the first layer adjustment on the Prusa I3 MK2? Like you print the first layer and you can adjust it with the knob on the LCD, but instead use Macro's? If so this is a fantastic feature.. I really hope it is
-
Yes it provides similar functionality.
-
A few graphs comparing my auto tune settings for:
- RRF1.18beta1 vs
- RRF1.17e vs
- Marlin (2014-10) auto tune PID settings - utilised on DuetWiFi using the M301 (Custom PID override) command in config.g
Timing/Temperature schedule used to produce the charts in the following images:
INTERVAL | G-CODE | ELEAPSED TIME ----------------------------------------------------------------------------- +0m00s | G10 P0 S200 | 0m00s +1m55s | M106 S1 | 1m55s +0m40s | M106 S0 | 2m35s +0m56s | G10 P0 S0 | 3m31s +0m03s | M106 S1 | 3m34s (only to increase rate of hotend cooling) ```Timing for each run was performed manually with accuracy in the order of ± 2 sec per interval. A few test-runs were made to gauge the worst case settling time before deciding on the timing schedule above; not perfect, but good enough to highlight the differences within one temperature chart frame. If the images are downloaded and viewed sequentially in an image browser the differences are even more apparent. I did make a macro to automate the process, but gave up on it due to lack of any G-Code echo in DWC. Is there any way around this? The larger than normal Temp Chart in the images is the result of modding the DuetWebController v1.14a: [DuetWebControl-1.14a_hk0.01.bin](https://www.dropbox.com/s/uns5b7howmabala/DuetWebControl-1.14a_hk0.01.bin?dl=1) [DuetWebControl-1.14a_hk0.01.zip](https://www.dropbox.com/s/mioqg6atcr0usdf/DuetWebControl-1.14a_hk0.01.zip?dl=1) **Test setup:**  It's worth mentioning that the heater cartridge is the very same cartridge used for all three auto-tuning runs. When I first began commissioning my new machine in Dec, I ran into problems with cold extrusion protection kicking in, due to the part cooling fan blowing air on the E3Dv6 block after layer one (but no more air than the very same fan was blowing on the E3Dv6 block of my previous machine). Extending the permissible hotend temp envelope from 10 to 15°C stopped the cold extrusion protection kicking in, but I found the RRF auto-tune PID settings were only enough to return the temperature to the original setpoint, minus 5°C. Knowing that my previous machine's PID settings enabled it to function quite adequately despite the brutal treatment regarding fan air impinging on the heater block, I transferred my old machine's E3Dv6 40W cartridge to the DuetWiFi controlled machine's E3Dv6 heater block to eliminate the (newer machine's original 30W) cartridge as the cause of the cold extrusion protection problem. The power increase provided no immediate improvement, however reverting to the old PID values has noticeable improved performance. About now I can hear people shouting, "put a silicon boot on the hotend block and a duct on the fan!" - I will, however I have noticed that placing any duct on the typical 40mm fans used does result in a noticeable reduction in airflow compared to that from an un-ducted fan. A duct also creates more fan noise, which is another indicator of decreasing efficiency. Conclusion: - I found the 1.18beta1 auto tune function much friendlier to use in so far as it no longer requires the PWM fraction (P value) to be estimated for the M303 auto tune command. Thank you - this will be a real time saver! - 1.18beta1 auto tune generated even less aggressive PID parameters - particularly the P value. - My interpretation of the results below are: 1\. the 1.17 auto tune 'setpoint change' PID parameters are better than those generated by 1.18beta1, though even they (1.17) could possibly be made a little more aggressive without causing any initial settling oscillations, and 2\. if technically possible, consideration be given to using the auto tune algorithm used by Marlin to generate 'load change' type PID parameters. Compared to 1.17 and 1.18beta1, the Marlin values result in much faster settling after either positive or negative load change. **1.18beta1** M307 H1 Heater 1 model: gain 723.0, time constant 232.2, dead time 6.0, max PWM 1.00, mode: PID Computed PID parameters for setpoint change: P9.6, I0.041, D40.1 Computed PID parameters for load change: P9.6, I0.560, D40.1  **1.17e** M307 H1 Heater 1 model: gain 693.0, time constant 218.0, dead time 4.5, max PWM 1.00, mode: PID Computed PID parameters for setpoint change: P12.5, I0.057, D39.3 Computed PID parameters for load change: P12.5, I0.922, D39.3  **Previous Machine's Marlin PID settings** M307 H1 Heater 1 model: gain 693.0, time constant 218.0, dead time 4.5, max PWM 1.00, mode: custom PID Computed PID parameters for setpoint change: P26.0, I2.910, D57.8 Computed PID parameters for load change: P26.0, I2.910, D57.8  EDIT 2017-03-05: - Renamed/re-linked images to include heater model parameters in filename rather than PID values - for consistency with image names from more recent tests. - Added image showing test setup. -
Thanks for doing the comparison. However, I think you have made a mistake, because the M307 model parameters you list for 1.17e and 1.18beta1 are identical, which is too much of a coincidence.
-
Thanks for doing the comparison. However, I think you have made a mistake, because the M307 model parameters you list for 1.17e and 1.18beta1 are identical, which is too much of a coincidence.
Apologies for the elementary copy-paste schoolboy error; thanks for spotting it. I actually made an even bigger mistake in putting the 1.17 and 1.18 chart images in the wrong location due to mis-renaming the screen captures while trying to post just before dinner. Less haste, better work. Next time.
The errors in my earlier post have been rectified and I expanded a little on what I first wrote, adding some background and a conclusion.
Regarding "identical parameters", a question: Are the 'Heater 1 model' parameters reported by the Marlin run actually being used in any way, or are the subsequently specified M301 PID settings completely overriding the M307 model parameters, effectively rendering them superfluous? If so, why the need for the M307 command prior to a M301 command (in config.g)?
i.e. these lines echoed in DWC (the "mode: custom PID" is the only give-away that the Heater 1 model is being over-ridden):
M307 H1 Heater 1 model: gain 693.0, time constant 218.0, dead time 4.5, max PWM 1.00, mode: custom PID Computed PID parameters for setpoint change: P26.0, I2.910, D57.8And the actual config.g snippet:
M307 H1 A693.0 C218.0 D4.5 B0 ; (E3Dv6 40W cartridge tuned using M303 H1 P0.3 S240) Heater 1 model: gain 693.0, time constant 218.0, dead time 4.5, max PWM 1.00, mode: PID M301 H1 P25.95 I2.91 D57.82 ; Over-ride Auto-tune derived Kp Ki Kd values with old Marlin derived (Prusa Mendel) PID values. -
Thanks, that makes more sense now.
When you use your own PID parameters by putting an M301 command later than the M307 command, the M307 parameters are still used to predict heating rates and thereby detect heating faults.
The temperature graph from Marlin looks to me to be only marginally stable.
Can you try reverting to the M307 parameters found by 1.18beta1 except reduce the D parameter to about 3 and see how that performs?
-
Thanks for the clarification. I do now vaguely recall reading something similar on the forum. After re-reading the wiki documentation I didn't find the explanation(s) to be quite as clear or concise. Perhaps you might consider editing the following pages mentioning M301, to reflect your very clear explanation above.
https://duet3d.com/wiki/Tuning_the_heater_temperature_control
https://duet3d.com/wiki/Configuring_RepRapFirmware_for_a_Cartesian_printer
https://duet3d.com/wiki/G-code#M301:_Set_PID_parametersThe temperature graph from Marlin looks to me to be only marginally stable.
True, but I believe it's convergent instability rather than divergent instability - which AFAIU, (and interpret from the images) results in a slightly more responsive system. i.e. the Marlin PID settings do provide convergence with set point temp, albeit in a marginally unstable manner, under increasing or decreasing load. Compared to RRF auto tune, the settling times (to ±0.1°C) that Marlin PID settings provided were almost identical during initial heat-up, somewhat faster after load increase (fan ON) and about the same after unload (fan OFF).Below are three further runs made today using the RRF1.18beta1 auto tune settings, adjusting only the D parameter:
- D3.0
- D2.8
- D2.5
1.18beta1 M307 auto tune parameters, with adjusted D=3.0
M307 H1 with
Heater 1 model: gain 723.0, time constant 232.2, dead time 3.0, max PWM 1.00, mode: PID
Computed PID parameters for setpoint change: P19.1, I0.082, D40.1
Computed PID parameters for load change: P19.1, I1.884, D40.1
1.18beta1 M307 auto tune parameters, with adjusted D=2.8
M307 H1
Heater 1 model: gain 723.0, time constant 232.2, dead time 2.8, max PWM 1.00, mode: PID
Computed PID parameters for setpoint change: P20.5, I0.088, D40.1
Computed PID parameters for load change: P20.5, I2.126, D40.1
1.18beta1 M307 auto tune parameters, with adjusted D=2.5
M307 H1
Heater 1 model: gain 723.0, time constant 232.2, dead time 2.5, max PWM 1.00, mode: PID
Computed PID parameters for setpoint change: P22.9, I0.099, D40.1
Computed PID parameters for load change: P22.9, I2.592, D40.1
GIF animation comparison
six image gif animation of all runs to date, with RRF 1.18beta1 at start and Marlin custom PID at end:
Many thanks for your suggestion to adjust the D parameter. I think you'll agree from the images above there's now increasing similarity in responsiveness provided by the PID values derived from RRF auto tune model parameters, and Marlin's auto tune PID paramters. I'll try the D2.5 and/or D2.8 setting while printing next weekend and report back.
-
So here are my numbers:
Pre 1.18beta
M307 H0 A311.7 C649.8 D3.1 S1.00 B0
M307 H1 A423.4 C203.6 D5.1 S1.00 B0Post 1.18beta
M307 H0 A259.0 C444.7 D1.5 S1.00 B0
M307 H1 A425.3 C217.6 D7.0 S1.00 B0To be fair I had zero issues with heaters previously, it worked great before and works great now. a max of 0.8 deg C overshoot on either heater which in my books is no great shakes.
Interestingly the "overpowered heater" dire warning reckons my bed is only going to get to 278 deg C now before it reckoned 700! Luckily my thermal fuse will go long before that.
-
Interesting, the bed heater dead time has reduced but the hot end heater dead time has increased.
-
If you want to test baby stepping, then for now I suggest you create a "Baby step up" macro file containing command M290 S0.05 and a "Baby step down" macro containing M290 S-0.05. Change the value 0.05 to be a suitable value for the first layer height you normally use.
Many thanks for implementing Baby steps dc42 - a really wonderful feature to have easy access to!
Baby step macro naming tip:
After implementing I realised User-Defined Macros are sorted alphabetically, so initially the top of my macro list looked like this:Baby step down
Baby step up
.
.
.No big deal "down" appears before "up", but ▲ ▼ icons are faster to interpret and when sorted alphabetically, they display in a more intuitive order.
Now my macro list looks like this:
Baby step ▲
Baby step ▼
.
.
. -
PanelDue firmware 1.16beta1 and DWC 1.15beta2 have baby stepping buttons.
-
PanelDue firmware 1.16beta1 and DWC 1.15beta2 have baby stepping buttons.
Thanks. I'll take a look.
-
Just minor feedback regarding my heater tuning (as above) it does oscillate both the bed and hotend more now than it did before. Its only a +/- 1 degree for the bed, which is absolutely fine. Its around 2-3 degrees on the hotend. With the previous settings it was more stable. Not a gripe, as both settings are acceptable to me.
-
PanelDue firmware 1.16beta1 and DWC 1.15beta2 have baby stepping buttons.
Where can we find the DWC beta? Doesn't seem to be on github
-
Its in Chrishamm's repository https://github.com/chrishamm/DuetWebControl
