sizing help - when printed box completely looses corners
-
@dc42 I don't have a delta nor do I know much about them but, I'd have thought that if the B parameter isn't present in config-overide.g, then it needs to be present in config.g (or somewhere else at least). So one would end up with two separate M665 commands, each one having one or more parameters that the other instance does not have. If a change needs to be made at some point in the future, one would need to remember in where each of the commands exists.
The OP has discovered that having the same command in two different locations can lead to confusion, so I'd have that having two different instances of that command, each with one or more parameters that the other does not have, would merely increase the risk of confusion.
-
@deckingman I agree. The config-override thing is a weird feature brought over from ancient firmwares. The confusion is already there. Keep the confusion consistent.
Users should decide if they will be using config-override or not. If they choose to use it, then use it. Set all parameters with G codes in console and then save them with M500. If you want to start manually editing config.g -- DON'T USE CONFIG-OVERRIDE!
The problems only arise when people start poking around the files themselves without being fully aware of what is located where.
-
@bot Well actually, I don't use config-override.g at all - nor will I ever. I know why it was introduced and I guess it saves doing a copy and paste, but I'd rather have all my setting in one place so it's not for me.
-
@deckingman I agree with that too!
One thing I don't want is for David to waste too much time working on "improvements" to "features" like this which were introduced for people who are essentially unwilling to learn new ways of doing things on modern systems.
-
@bot You could be right but it's not for me to say how anyone else should manage their system and files. We both think that not using config-overide.g is a better approach but I wouldn't propose that we should should force that way of doing things on everyone else. The override file was introduced to emulate writing to non-volatile memory and like most things, it stemmed from user requests so.....
-
@deckingman Sure! I agree, let them use config-override. It already works! Why mess with it. My thoughts were in response to David seeking input as to whether the functionality should be changed. I think not. It's consistent as it is. Input gcode into console. Like the change? Send M500. End of story. Do not open config.g to edit it if you are using config-override.
-
@deckingman @bot I think where a system like config-override to save computed values is useful is in the context of say an OEM situation where the end user and the system designer are not the same person. Having a macro that automates a calibration process means needing a way to permanently store those computed values. Since the firmware can't edit config.g and there is no eeprom, we're left with a secondary macro that the system can overwrite.
-
@phaedrux said in sizing help - when printed box completely looses corners:
system like config-override to save computed values is useful is in the context of say an OEM situation
i agree. config-override in current implementation is a kind of storage for calibrated values. in theory it can be renamed to 'calibration_data.csv' (similar to mesh bed file)
my call was to make software architecture consistent and keep calibration data in config-override, separating it form values that calibration can not change. B parameter (bed size) is one of those user-defined values that system can not change, thus it should go to config.g
-
@c310 That seems like a valid approach. Although it does leave situation where one could have two instances of a command in two different places, each instance having some parameters that the other instance does not have. This in itself could lead to misunderstanding and confusion.
Perhaps a better approach (and I have no idea if this is possible) might be to split the "calibration generated" parameters from the "non-calibration generated" parameters into two separate gcodes, the intention being that the former would reside in the override file (if the user chooses to use it) and the latter would reside in config.g. This would avoid the possibility of having two instances of the same gcode command.
I doubt that David will find a compromise that will suit everyone but as things stand, users have the choice whether to use config-override or not, so whichever solution he chooses isn't likely to be a huge upset. If he does find an acceptable compromise, maybe he can solve the Brexit impasse that our politicians have created
-
@deckingman said in sizing help - when printed box completely looses corners:
Perhaps a better approach (and I have no idea if this is possible) might be to split the "calibration generated" parameters from the "non-calibration generated" parameters into two separate gcodes,
that exactly i was talking about: keep all commands in config.g and all calibration data (not commands) in config-override
also auto-calibration should not modify and/or add non-calibrated options and parameters.firmware scenario than will be:
- read config.g to memory
- append and replace data from config-override (or from calibration_data.csv to avoid misunderstanding) to memory
- enjoy the print
-
@c310 You did slightly mis-quote me there by omitting the "into two separate gcodes,". That's a fairly important part of the point I was trying to make, as it would negate the need for duplicate commands.
-
@deckingman added that important part
