Provisional firmware 1.16 work list
-
I agree, it's personal preference. I guess you are used to machines that require constant calibrating and messing with settings, whereas I prefer a machine that has a set of values that may change based on new information, but remain nearly constant. The config-override only seems useful during the commissioning of a printer, and becomes very confusing once the printer works properly. See the eeprom vs configuration.h file on repetier/rambo based machines. People are constantly forgetting that the eeprom overrides the base settings, so re-flashing the firmware does nothing.
I certainly have no problem with having the feature - I may end up using it, but I'm trying to understand how you still aren't achieving what you want right now; G92 being temporary doesn't prevent you from using it for what you want.
-
I did not mean my post as a discouragement to implementing M500 type functionality, only that (for my way of thinking) it did not appear optimal. As everyone agrees its personal preference to edit the config.g or have a config-override.
Another alternative is to formalise the formatting of the config.g a bit and have changes save directly to that. I am actually not a big fan of this idea because it means alot of work parsing the config.g and ensuring the right lines are changed, if we did this then a more structured format would make sense and we loose the ease of a human readable file that just contained gcode and comments.
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.
-
@bot:
I guess you are used to machines that require constant calibrating and messing with settings, whereas I prefer a machine that has a set of values that may change based on new information, but remain nearly constant.
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. Since I believe it may still add some value I will continue this discussion anyway, hopefully not in vein.
@bot:
The config-override only seems useful during the commissioning of a printer, and becomes very confusing once the printer works properly. See the eeprom vs configuration.h file on repetier/rambo based machines. People are constantly forgetting that the eeprom overrides the base settings, so re-flashing the firmware does nothing.
I've already clearly articulated my use-case for a config-override and it has nothing to do with commissioning new machines OR the necessity for constant calibration. You simply choose to ignore it so you can continue to try and drive your opinions home without bothering to understand why others like myself prefer to do things differently.
@bot:
I certainly have no problem with having the feature - I may end up using it, but I'm trying to understand how you still aren't achieving what you want right now; G92 being temporary doesn't prevent you from using it for what you want.
As I've already explained, with my previous controller (Smoothieware)-The method I'm familiar with (and preferred over the current Duet solution) setting my Z0 height is:
-
Jog Z down to do the paper "pinch" adjustment
-
Send M306 Z0 to store current position to home offset
-
Send M500 to store running config
That's it. Simple. Easy. From that point on EVERY print will start flawlessly after re-homing, rebooting, whatever. No need to calculate homing offsets and update M665 (which then requires additional steps to navigate to config.g and manually save the new H attribute), no need to worry about a re-home blowing away G92 offsets, no need to bang up my PEI sheets with auto-calibration. Until I need to swap my glass for another piece (when printing in rapid succession and not wanting to wait for the glass to cool so I can remove the parts, for example) I never need to worry about my Z0, it's always right where I last configured it.
-
-
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?
