Provisional firmware 1.16 work list
-
I don't believe the pressure advance issue that has been reported has anything to do with under or over extrusion. The usual cause of needing an extrusion factor that is not very close to 1 is the filament diameter being out of tolerance. Have you measured it?
Yes the plan is for M500 to write certain parameters to config-override.g, for example M307, M665 and M666. Other suggestions for parameters to be saved will be considered.
Interesting that M558 P4 with FSRs works for you, when 2 other people say it stopped working for them at version 1.15c and I can't find any explanation for that.
-
Yes, I've absolutely measured very carefully. The under-extrusion seems to be chronic and occurs with every one of the maybe dozen different spools I've used since installing the Duet WiFi.
Those exact same spools when used with a different controller/firmware in this Kossel-as well as two other printers not using Duet Wifi-extrude those same spools exactly as I'd expect.
I'll disable the pressure advance tonight and see what happens. I'd quite forgotten I enabled that when I deployed the Duet WiFi…
As far as the FSRs, I did initially receive the error during calibration that the others reported but that cleared up after I power-cycled the board. It occurred when the nozzle moved into position where it would normally start it's 5mm dive to find the bed surface, but instead reported the error and moved on to the next point where it continued to report the same message for every point. As soon as I power-cycled it cleared up and has been working fine.
I don't believe the pressure advance issue that has been reported has anything to do with under or over extrusion. The usual cause of needing an extrusion factor that is not very close to 1 is the filament diameter being out of tolerance. Have you measured it?
Yes the plan is for M500 to write certain parameters to config-override.g, for example M307, M665 and M666. Other suggestions for parameters to be saved will be considered.
Interesting that M558 P4 with FSRs works for you, when 2 other people say it stopped working for them at version 1.15c and I can't find any explanation for that.
-
Yeah I had the same thing. I was running some prints and had the issue so I just disconnected the jumper on the FSR board and it ran fine. The next day after it being off for a while it inexplicably switched back so I had to reconnect the jumper. Its still fine now with 0 changes to my config.g.
-
I understand that if you are used to M500 and saving to EEPROM being the only easy way to.modify your config then config-overide.g makes sense however I can't see the benefit out weighs having to check in more than one place for what settings are in force. Adding the commands to config.g is easy in the web interface and then you have one source to check.
I am not saying we should not implement it, just that it may not be the optimum way to save settings.
-
Can I request a more aggressive response to heater faults? I know it's on the todo list, but it seems to me that it's a safety issue, and so I'd like to see it move up the priority list.
Specifically, I'd like to see heater faults trigger an emergency shutdown, including turning off the 12/24V supply if the user has configured such a setup. Alternatively it could do what it does now (shut down the heater but continue trying to print) and then call a macro, which I could then set up for emergency shutdown.
-
Like anything else I believe it's all just a matter of personal preference. If David want's to implement this I'm totally in favor of it, since coming from Smoothieware that's the workflow I'm familiar with–and quite fond of.
Further, if you send M503 it should display every configurable option and it's currently saved setting so there is no need to go looking through configuration files anyway. Just send M503 and you get all of your relevant settings in one nice easy to read format.
I understand that if you are used to M500 and saving to EEPROM being the only easy way to.modify your config then config-overide.g makes sense however I can't see the benefit out weighs having to check in more than one place for what settings are in force. Adding the commands to config.g is easy in the web interface and then you have one source to check.
I am not saying we should not implement it, just that it may not be the optimum way to save settings.
-
David, maybe there's already a method to do this in RepRapFirmware but one thing I really miss coming from Smoothieware is the M306 command for adjusting the Z=0 offset. If there isn't already a way to achieve this, would this be difficult to accomplish in firmware?
Basically if I need to quickly adjust the nozzle height when at 0, I would just baby step up or down a little bit then send M306 Z0, then M500 and I was good. The method I use now use with the Duet is figure out how much I need to change the offset, then tweak the homed height in M665 and then re-home. Then if that got me were I need to be I edit config.g and make the change there. I guess once config-override is implemented, sending a new M665 H parameter than M500 to save won't be that different, but it's nice not having to calculate a new homed height when using M306.
I have several pieces of glass of varying thicknesses and some with PEI material applied, so when swapping glass around it's helpful to have a quick way to adjust the first layer height and go.
And before anyone says it, I realize using G32 should also work. The problem with using G32 is since I have FSR's and PEI, I try to keep the nozzle from touching the PEI as much as possible–ie avoid re-calibration.
Thanks!
-
David, maybe there's already a method to do this in RepRapFirmware but one thing I really miss coming from Smoothieware is the M306 command for adjusting the Z=0 offset. If there isn't already a way to achieve this, would this be difficult to accomplish in firmware?
Basically if I need to quickly adjust the nozzle height when at 0, I would just baby step up or down a little bit then send M306 Z0, then M500 and I was good. The method I use now use with the Duet is figure out how much I need to change the offset, then tweak the homed height in M665 and then re-home. Then if that got me were I need to be I edit config.g and make the change there. I guess once config-override is implemented, sending a new M665 H parameter than M500 to save won't be that different, but it's nice not having to calculate a new homed height when using M306.
I have several pieces of glass of varying thicknesses and some with PEI material applied, so when swapping glass around it's helpful to have a quick way to adjust the first layer height and go.
And before anyone says it, I realize using G32 should also work. The problem with using G32 is since I have FSR's and PEI, I try to keep the nozzle from touching the PEI as much as possible–ie avoid re-calibration.
Thanks!
That is exactly what David meant by this item on his list:
…
- Relative option in G92 command (for baby stepping)
...
- Relative option in G92 command (for baby stepping)
-
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 - doneIf 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)
...
- Relative option in G92 command (for baby stepping)
-
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.
-
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 - doneIf 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.
- Relative option in G92 command (for baby stepping)
-
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.
-
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?
