Provisional firmware 1.16 work list
-
Regarding having a "factory default version" of the config.g. The advantage of it being a text file is you can have as many copies of it with changes as you want, or have all the variations you are interested in in the same file, commented out except for the active one.
Tony, I was actually going to make a comment about the possibility of having multiple config-override "profiles", but I decided it may further muddy the waters so I decided against it. My argument is simply that, at least for me, I'd rather have the ability to adjust and save my configuration without the need for touching the config.g file(s). In my mind the config.g should be a last resort when a major fundamental change is made such as going from 1.8deg steppers to 0.9, changing the dimensions of the robot, switching from thermistor to thermocouple, etc.
Anyway I think I've certainly made my point so I'll refrain from beating a dead horse.
-
Personally I like the config-override thing (in the way smoothieware does it). You can save multiple overrides in case your printer has multiple configurations (like my current printer I can pull the V6 heater block out of the Kraken by loosening 2 set screws, unhooking the connector, and then I can pop a volcano in. A cool feature would be if the main config.g file got run (without tools/probing settings, etc) and then I could select one of a few different config-override files to setup the rest of my printer. This really would be even more useful for someone who wants to run several tools on one machine (printer, laser, router, etc). I'm not sure how some g codes work when you re-run them (like tool codes) but you could potentially setup your tool paths to automatically switch config-override files after a pause to switch tools, or just save some time not having to restart your machine when you switch things live.
About knowing what codes are in effect. Several of the codes (M666, M665, etc) output what values are being used currently when you send the code with no parameters. Important configuration codes could be setup in the firmware to respond with current values if an empty code is sent (no X, Y, Z, S, F, etc following the M or G code)?
-
Well thanks for that. I suspected this mature conversion might sink to getting personal, and I'm sorry to see I was right. Between your prior "WiFi is insecure" arguments and now this, whatever credibility you brought to this forum is now gone, in my opinion…
If you think that is a personal attack, maybe you need to take a step back from 3D printing and not take everything so personally. I could care less about your opinion of my credibility.
-
Regarding config-override.g, my plan is to have M500 save a small number of values to it. These will mainly be values obtained from automatic calibration processes, in particular the M665 and M666 parameters obtained by auto delta calibration, and the M307 parameters obtained by heater tuning. Perhaps also the G31 Z probe trigger height.
Regarding multiple configurations, you can define a macro file for each configuration. All the commands used in config.g except for the network configuration commands can be used at any time. On my Cartesian printer, I have a macro that resets it into CoreXY mode, which I use for testing the CoreXY support in firmware.
-
Reading this thread I don't think anyone was deliberately attacking anyone else. It just seems that the marlin/smoothie way of doing things with a mechanism to save settings by sending a m500 (which almost all of us are more familiar and comfortable with at the present time) and the duet way of doing things which has many merits, are just different.
I have been grappling with the notion that I can do an auto calibrate, but then I have to write the settings down and update my config.g why can't I just hit save? But Tony explained it best, in order to do that the config.g can't just be a simple text file or the data could not be appended to it reliably or read back from it when needed. It would need to be a tabulated, formatted file which loses some of the elegance and simplicity of a simple text file.
It might be nice to have some sort of undo function so that you could make a change to config.g then just hit rollback to go back to say config.g_old which would be an automatically generated backup.
Also wondering if it's possible to have in the gcode console in the web interface the ability to recall previous commands using the up and down arrows?
-
I had not thought of using a macro to reset the configuration. I have a seperate config.g files saved on my PC for different configurations (such as chimera vs cyclops) and then just cut and paste them into the web interface.
Sounds like the proposed solution makes it easier and as already pointed out makes no difference if you don't want to use it.
-
Reading this thread I don't think anyone was deliberately attacking anyone else. It just seems that the marlin/smoothie way of doing things with a mechanism to save settings by sending a m500 (which almost all of us are more familiar and comfortable with at the present time) and the duet way of doing things which has many merits, are just different.
I have been grappling with the notion that I can do an auto calibrate, but then I have to write the settings down and update my config.g why can't I just hit save? But Tony explained it best, in order to do that the config.g can't just be a simple text file or the data could not be appended to it reliably or read back from it when needed. It would need to be a tabulated, formatted file which loses some of the elegance and simplicity of a simple text file.
It might be nice to have some sort of undo function so that you could make a change to config.g then just hit rollback to go back to say config.g_old which would be an automatically generated backup.
Also wondering if it's possible to have in the gcode console in the web interface the ability to recall previous commands using the up and down arrows?
Regarding M500, a lot of people running Marlin run into problems because they make changes to the firmware configuration and then wonder why they don't work (which is because they are being overridden by values saved with M500). I already spend a lot of time supporting RRF so I want to implement changes that reduce the support load, not increase it. That's why my focus is on a mechanism that serves a genuine need (I.e. capturing values obtained by automatic processes) and is fully transparent (i.e. writing those values in human-readable form, and having config-override.g invoked explicitly from config.g).
Regarding command history in the Console page of DWC, I agree. PanelDue provides this already.
-
I forgot macros are a thing. Thanks for clarifying that those commands can be re-run.
-
Here is an update. The priority for release 1.16 is now support for the DueX2/DueX5, including support for dual X-carriages. The DueX5 is imminent but I have a major exhibition coming up in my other line of business (which is proving that safety-critical software is correct). So I need to alter the 1.16 feature list. Here is the original list, annotated with updates:
- Change heater tuning method to work with unusually weak or strong heaters without having to change the P parameter deferred to 1.17
- Support Steinhart-Hart C coefficient for thermistors deferred to 1.17
- Allow any commands from different input sources to be executed concurrently as long as they use different resources deferred to 1.17
- Make triggers execute immediately instead of waiting for macros etc. to complete first. Only one trigger will execute at a time, however trigger 0 will preempt any other trigger. deferred to 1.17
- Support config-override.g file in conjunction with M500 and related commands deferred to 1.17
- Stepper drivers beyond the first 5 will be assumed to be simple enable/step/direction drivers and not TMC2660, unless the DueX5 is detected already implemented in 1.15e
- Relative option in G92 command (for baby stepping) deferred to 1.17
- Investigate/fix "Temperature rising much more slowly than the expected 0.0C" heater fault message, and other unusual heater fault reports already fixed in 1.15e
- Investigate/fix reports of incorrect behaviour when using small amounts of extruder pressure advance already fixed in 1.15e
- Investigate/fix reports of Z probe type 4 not working can't reproduce this
- Investigate/fix reported issue of print pausing at the corners of a print can't reproduce this
New major items added:
- DueX2 and DueX5 support
- Support for two independent X-carriages
A couple of new minor items (already implemented):
- Support for bed tilt calibration on delta printers
- Support for the S parameter in the G4 command
And some more bug fixes that have already been done:
- Generic messages (e.g. some error messages) were not sent to PanelDue in the correct format, so they were not displayed
- When using an analog Z probe, probing sometimes terminated earlier than it should have done and this resulted in an incorrect Z position
- If probing fails (either because the Z probe was triggered at the start of the probing move, or because it wasn't triggered before the end of the move), bed compensation or delta calibration was attempted anyway.
-
Grid Leveling
-
-
Here is an update. The priority for release 1.16 is now support for the DueX2/DueX5, including support for dual X-carriages. The DueX5 is imminent but I have a major exhibition coming up in my other line of business (which is proving that safety-critical software is correct). So I need to alter the 1.16 feature list. Here is the original list, annotated with updates:
- Change heater tuning method to work with unusually weak or strong heaters without having to change the P parameter deferred to 1.17
- Support Steinhart-Hart C coefficient for thermistors deferred to 1.17
- Allow any commands from different input sources to be executed concurrently as long as they use different resources deferred to 1.17
- Make triggers execute immediately instead of waiting for macros etc. to complete first. Only one trigger will execute at a time, however trigger 0 will preempt any other trigger. deferred to 1.17
- Support config-override.g file in conjunction with M500 and related commands deferred to 1.17
- Stepper drivers beyond the first 5 will be assumed to be simple enable/step/direction drivers and not TMC2660, unless the DueX5 is detected already implemented in 1.15e
- Relative option in G92 command (for baby stepping) deferred to 1.17
- Investigate/fix "Temperature rising much more slowly than the expected 0.0C" heater fault message, and other unusual heater fault reports already fixed in 1.15e
- Investigate/fix reports of incorrect behaviour when using small amounts of extruder pressure advance already fixed in 1.15e
- Investigate/fix reports of Z probe type 4 not working can't reproduce this
- Investigate/fix reported issue of print pausing at the corners of a print can't reproduce this
New major items added:
- DueX2 and DueX5 support
- Support for two independent X-carriages
A couple of new minor items (already implemented):
- Support for bed tilt calibration on delta printers
- Support for the S parameter in the G4 command
And some more bug fixes that have already been done:
- Generic messages (e.g. some error messages) were not sent to PanelDue in the correct format, so they were not displayed
- When using an analog Z probe, probing sometimes terminated earlier than it should have done and this resulted in an incorrect Z position
- If probing fails (either because the Z probe was triggered at the start of the probing move, or because it wasn't triggered before the end of the move), bed compensation or delta calibration was attempted anyway.
I will have my printer ready for IDEX at the weekend. Anything I should be concerned or look out for?
-
I will have my printer ready for IDEX at the weekend. Anything I should be concerned or look out for?
Version 1.16alpha1 is already on GitHub. It supports the extra U axis that you need for IDEX, including configuring and homing it. I will probably commit beta2 tomorrow, which allows tool X axis mapping to be defined and reported, but not used yet. By the weekend I hope to have beta3 released with X axis mapping fully implemented.
-
Thanks
-
Version 1.16 beta 2 is out. New features in this release:
-
More work on supporting a variable number of axes
-
X axis mapping can be defined in the M563 command. This is not yet complete, so although the mapping is stored and reported to DWC, movement is not mapped yet.
-
The number of axes is reported to DWC and to PanelDue
-
Sending M307 A-1 C-1 D-1 disables the PID for a heater channel, allowing its pin and driver to be used for other purposes
-
Fan minimum speed support. You can set a minimum speed for a fan such that any request to use a lower speed other than zero selects the minimum speed instead. The default is 5% which is the lowest that works for me.
-
Fan blip support. When a fan is turned on, it is run at full power for a configurable blip time (default 0.1 seconds). This lets you use PWM values that are too low to get the fan moving but high enough to keep it moving.
Along with this I have released version 1.15 of PanelDue firmware to support additional axes if they are configured - just U on the 4.3 inch panel, but U. V and W on the 5 and 7 inch panels.
-
-
Thanks for the fan stuff, I just tried it out and it works flawlessly!
-
How do you find time to do all this David when a lot of other firmwares have large teams and seem to move very slowly?
-
Some things - like the fan blip - need little design effort and are quick and easy to implement. Other things - like IDEX and particularly grid-based bed compensation - need a lot more thought beforehand and care to get right, because there are important usability considerations and they interact with other existing or planned features
It helps that the Duet WiFi is a joint venture between my company and T3P3, giving me a get a share of the profit on Duet WiFi sales. So this is no longer just a spare-time activity for me.
Large teams sometimes slow down development too.
-
Version 1.16 beta 5 is out. New in this release:
-
X axis mapping. This completes support for independent dual X carriages.
-
The I1 parameter in M558 command is supported, allowing the Z probe reading to be inverted.
-
Better error handling when Z probing fails.
-
Commands such as M201 and M906 show the correct number of extruder values
-
Bug fix: remapping the bed heater to another heater channel was supported in the M140 command but not in most other bed heater related commands.
Now I need to finish adding support for the DueX2 and DueX5 before I release 1.16.
-
-
Version 1.16 beta 10 is out. New in this release:
-
Added DueX2/DueX5 support, including up to 10 drives, 8 heaters and 8 fans on the Duet WiFi. You will need DWC 1.13 if you want to use heater 7.
-
Report expansion board type in electronics string (displayed by M115 and by DWC 1.13)
-
Added Z probe type 6 (switch on E1 endstop connector)
-
Support heater 6 on Duet 0.8.5 (untested and probably incomplete). You need to send a M307 H6 command with valid model parameters to enable heater 6, and Fan 1 will be disabled (they share the same control signal).
-
Changed M42 pin numbering, see https://duet3d.com/wiki/Using_servos_and_controlling_unused_I/O_pins
-
Added M280 servo support, see https://duet3d.com/wiki/Using_servos_and_controlling_unused_I/O_pins
-
Allow separate firmware un-retract speed to be configured in M207
-
Allow negative extra un-retraction in M207
-
You can disable a fan by sending M106 P# I-1, then its control pin can be used as for general purpose output (M42) or a servo (M280). Caution: the polarity may not be what you expect.
-
If you disable a heater using M307 H# A-1 C-1 D-1 then its control pin becomes available for general purpose output (M42) or a servo (M280).
-
Removed support for Duet WiFi prototype 1 board
-
Support expansion connector pin PB6 and use it by default for a cooling fan tacho input
-
