Provisional firmware 1.16 work list

W3DRK

Maybe I'm just being thick, but my understanding of G92 is that it's temporary. Or will there be a way to easily store the current offset to future config-override.g with a simple command?

The beauty of G306 is it sets your home offset based on the current tool position. So if you need to adjust your Z0 height:

Jog Z until it "pinches" a piece of paper
G306 Z0 - done

If you want to store the current offset, M500 - done

That is exactly what David meant by this item on his list:

…

Relative option in G92 command (for baby stepping)
...

T3P3Tony

You are right, G92 is reset on homing (its whats used in the homing gcode files)

G306 is an alternative to setting the bed height in calibration (M665) as you said before, rather than an alternative to G92.

bot

@W3DRK:

Maybe I'm just being thick, but my understanding of G92 is that it's temporary. Or will there be a way to easily store the current offset to future config-override.g with a simple command?

The beauty of G306 is it sets your home offset based on the current tool position. So if you need to adjust your Z0 height:

Jog Z until it "pinches" a piece of paper
G306 Z0 - done

If you want to store the current offset, M500 - done

That is exactly what David meant by this item on his list:

…

Relative option in G92 command (for baby stepping)
...

If you have to adjust your z height so often, what is the use in easily saving the current value to firmware, if you're just going to change it again soon?

I have a safe homed height in my firmware, where the nozzle is not too close when ambient temperature is low, and if the ambient temperature is higher, I can set homed height accordingly. This way, every print starts with the same value, which is often close if not exact, and if needed I can babystep or start and restart to get the correct z height.

From what I understand, you want an easy way to set a new homed height based on the current offset you've added. I don't see the point in this, and agree with Tony that the config override doesn't make much sense with the duet ecosystem. It's very easy to reference and change the current settings, you just have to remember that unless you changed it in the config file, everything is temporary. This is a much better way of doing it, IMO, because it is more reliable, as you're not constantly (accidentally) changing settings and losing track of what is set. I guess this comes down to preference.

W3DRK

I do appreciate the Duet platform and think it's fantastic that I can adjust any aspect of my machine's configuration with a simple G-code. But isn't the next logical step to have a method that actually commits those settings to a non-volatile space (file, NVRAM, whatever) with a G-code like M500? The whole Duet eco-system is G-code based, yet the user currently has no way to save changes with a G-code. Instead we must currently navigate to a web based file manager and edit a txt file to actually save any settings so they survive a power-cycle or reset. David is planning to implement an override file so I'm not certainly complaining and will patiently wait…but why discourage this when users like myself would appreciate such a feature? We're not talking about some wild out-of-scope feature that jeopardizes the stability of the firmware, it's merely a refinement to the manor in which running configurations can be stored. If you don't like it, don't use it.

Besides, your argument is that it may be confusing to keep track of what temporary settings may have been changed. Well that's the WHOLE POINT of a config-override. You keep your master config.g in an established "factory defaults" like state, and commit any short-term settings to the config-override. It's an elegant way to return your printer to exactly the same running configuration it was using before a reset. Forgot what you changed and want to drop back to your defaults?....no problem just send M502 to reset the config-override and move on. No need to modify a text file, you can do it all from the same G-Code console. In fact I argue that it's easier to forget what to change to config.g if you need to make an adjustment and want to get-on with a print job instead of tinkering in the config file--I've run into this several times already.

I may swap my build service every few hours, or every few days. Why does it matter? I change my glass, set a new Z0 (M306 without needing to calculating home offsets in Smoothie), M500, and done. From that point I know i can power cycle my printer and begin printing without auto-calibrating or touching a single setting until I choose to swap my build surface. Please explain to me how this is a bad thing?

So, I guess my point is...personal preference? Absolutely... But I fail to see how having a config-override available inconveniences your workflow since you could merely choose to ignore it. But advocating that we don't need a config-override feature because you don't see the point DOES inconvenience me and undoubtedly many others who would prefer to use one.

W3DRK

@bot:

If you have to adjust your z height so often, what is the use in easily saving the current value to firmware, if you're just going to change it again soon?

I have a safe homed height in my firmware, where the nozzle is not too close when ambient temperature is low, and if the ambient temperature is higher, I can set homed height accordingly. This way, every print starts with the same value, which is often close if not exact, and if needed I can babystep or start and restart to get the correct z height.

From what I understand, you want an easy way to set a new homed height based on the current offset you've added. I don't see the point in this, and agree with Tony that the config override doesn't make much sense with the duet ecosystem. It's very easy to reference and change the current settings, you just have to remember that unless you changed it in the config file, everything is temporary. This is a much better way of doing it, IMO, because it is more reliable, as you're not constantly (accidentally) changing settings and losing track of what is set. I guess this comes down to preference.

bot

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.

T3P3Tony

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.

W3DRK

@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.

W3DRK

@T3P3Tony:

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.

curieos

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)?

bot

@W3DRK:

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.

dc42

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.

DjDemonD

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?

T3P3Tony

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.

dc42

@DjDemonD:

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.

curieos

I forgot macros are a thing. Thanks for clarifying that those commands can be re-run.

dc42

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.

Adamfilip

Grid Leveling

dc42

@Adamfilip:

Grid Leveling

That is the headline item planned for 1.17.

iDevelo

@dc42:

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?

dc42

@iDevelo:

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.