You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Went to fix the Setting -> Maslow settings -> Z-axis Installed title text and found it defined in the defaultWebControl.json file. Problem is that the code comparison in config.py only compares the setting "Key" index and value, to make sure the setting exists, but does not compare anything else. So the "Title" index and value is ignored and the ~/.Webcontrol/WebControl.json file is not overwritten with changes. The WebControl.json has to be deleted for changes to take effect right now.
Before I take the time to fix this I wanted to confirm the way it should work.
I assume that basically only the Setting "Value" indexes should be kept from the current user configuration? If anything else changes then it should be loaded from defaultWebControl.json file and overwrite.
The other question is what happens if a Setting is removed or replaced by one with a different "Key" value. Should the old Setting be kept? Should this kind of update be dealt with manually in code per case or establish a default rule (keep/discard)?
Rather then comparing every index and value I though it might be easier/better to strip out the "Value" indexes from both, in new temp comparison copies, and then do a simple == comparison.
If they are not equal then copy the "Value" indexes from the current config (if they exist in both) and overwrite the WebControl.json file.
The updating (like most things) was an afterthought and I didn't get everything done that I would like to on it. Currently, it only adds new entries that don't exist but doesn't change anything if it does (as you've noticed). Ideally it would add/remove/modify. If that can be done, then adding in an order key (for how it is listed in settings) would be good as well. Right now, the settings page just shows them in the order they are in the json file.. but if you add something to the defaultwebcontrol.json file, regardless of where it is there, it will end up at the end of the webcontrol.json file (for a particular section). So having an order index would be good.
I assume that basically only the Setting "Value" indexes should be kept from the current user configuration? If anything else changes then it should be loaded from defaultWebControl.json file and overwrite.
Correct.
The other question is what happens if a Setting is removed or replaced by one with a different "Key" value. Should the old Setting be kept? Should this kind of update be dealt with manually in code per case or establish a default rule (keep/discard)?
Can you give me an example? I'm not sure what specifically you are asking.
Rather then comparing every index and value I though it might be easier/better to strip out the "Value" indexes from both, in new temp comparison copies, and then do a simple == comparison.
Keep in mind, I'm a hack and cut my python teeth on this program. So if there's a better way to accomplish something, I'm all for it. Sometimes when I program, I take steps in figuring out how to do things and the first step often influences what the second step is.. so after I get done, I might figure out a whole different way of doing it, but I tend to follow the 'if it ain't broke, don't fix it' mantra when there's other things to get done.
@gb0101010101 The other question is what happens if a Setting is removed or replaced by one with a different "Key" value. @madgrizzle Can you give me an example? I'm not sure what specifically you are asking.
So we current have Setting Key "truncate" for "Truncate floating point numbers at the specified number of decimal places"
Lets say we replace this with a new Setting Key "truncateMM" to make it clearer that it applies to MM units only, and then work out "truncateIN" for inches which requires many more significant digits to maintain the same precision.
Should the old "truncate" setting be removed by default? Or should it be kept just in case the user wants to roll back a version and retain their custom value?
Should we assign WebControl version numbers to Settings in case we want to compute a new Value using an old one?
@madgrizzle Keep in mind, I'm a hack and cut my python teeth on this program. So if there's a better way to accomplish something, I'm all for it.
You've done an amazing job on this project! MaslowCNC and Open Source communities in general need more people like you.
I've often been told that my strictly logical mindset makes me sounds harsh/blunt over the interwebs. I am working on it. So if something I write sounds negative please let me know and do not take it so. Really I just want to determine if a problem exists, and if so, fix it.
So I noticed the default settings are defined in defaultWebControl.json and in settings.py. defaultWebControl.json is the one currently being used. Which one is the newest or more desired method?
Opening a separate JSON file, and possibly writing a new one, using file pointers is slower than just having it all in a one Python file. Willing to keep the current separate JSON file if you see some benefit to it?
On Fri, 17 Jan 2020, gb0101010101 wrote:
> @gb0101010101 The other question is what happens if a _Setting_ is removed or replaced by one with a different "Key" value.
> @madgrizzle Can you give me an example? I'm not sure what specifically you are asking.
So we current have _Setting Key_ "truncate" for "Truncate floating point numbers at the specified number of decimal places"
Lets say we replace this with a new _Setting Key_ "truncateMM" to make it clearer that it applies to MM units only, and then work out "truncateIN" for inches which requires many more significant digits to maintain the same precision.
This is needed because the arduino code can't handle too many digits in it's
input, it doesn't matter if you are in inches or mm, too many digits break
things.
There is a separate problem of moving too small a distance being a waste of time
(and with circles, a tiny arch turns into a full circle if the start and end
point are too close together) but that's not what truncate is here for
It would be better to fix this in the arduino firmware, but the floating point
code there has serious problems. Moving to arbitrary precision numbers would
eliminate the need for this (and solve some other problems, single precision
floats work fairly well for small CNC machines, but our large workspace causes
grief)
David Lang
I think we are talking about the same end result using different terms.
The existing "truncate" Settings I referenced is only used by WebControl (which is not running on the Arduino) and appears to be there to address the limited capability of the Arduino board that you mention. I think it is used to reduce precision of gcode before it is sent to Arduino board.
As I understand it, the Arduino can only handle a certain number of decimal places, as you said, but it does not account for units of measure. The units certainly seem to influence precision e.g. 1 mm requires 1 digit but requires at least 5 significant digits in inches (0.0393701) to maintain the same precision. So sending G21 "1" (MM) to Arduino board yields greater precision than sending G20 "0.393701" (INCH) using fewer decimal places and less processing.
On Sat, 18 Jan 2020, gb0101010101 wrote:
Hi @davidelang,
I think we are talking about the same end result using different terms.
The existing "truncate" _Settings_ I referenced is only used by WebControl (which is not running on the Arduino) and appears to be there to address the limited capability of the Arduino board that you mention. I think it is used to reduce precision of gcode before it is sent to Arduino board.
As I understand it, the Arduino can only handle a certain number of decimal places, as you said, but it does not account for units of measure. The units certainly seem to influence precision e.g. 1 mm requires 1 digit but requires at least 5 significant digits in inches (0.0393701) to maintain the same precision. So sending G21 "1" (MM) to Arduino board yields greater precision than sending G20 "0.393701" (INCH) using fewer decimal places and less processing.
Do you agree?
are you proposing that WC convert all gcode from inches to mm and send only mm
dimensions to the firmware?
I think that's a bad idea in the long run, we want to be able to have the
firmware support other g-code senders, and if we never use inch support, bugs
will creep in and break things.
David Lang
Lets say we replace this with a new Setting Key "truncateMM" to make it clearer that it applies to MM units only, and then work out "truncateIN" for inches which requires many more significant digits to maintain the same precision.
If you can figure out a way to allow to make it carry old values, then that would be best.
I've often been told that my strictly logical mindset makes me sounds harsh/blunt over the interwebs. I am working on it. So if something I write sounds negative please let me know and do not take it so. Really I just want to determine if a problem exists, and if so, fix it.
I think we all worry about how we sound when we write things in forums and etc. I'm not offended by straight talk and realize that written communications lacks 'inflection'. Don't worry about sugar coating with me. :)
So I noticed the default settings are defined in defaultWebControl.json and in settings.py. defaultWebControl.json is the one currently being used. Which one is the newest or more desired method?
settings.py is not used and should be removed from the repo. It was a first attempt (imported from groundcontrol) and config.py was what I ultimately used.
The existing "truncate" Settings I referenced is only used by WebControl (which is not running on the Arduino) and appears to be there to address the limited capability of the Arduino board that you mention. I think it is used to reduce precision of gcode before it is sent to Arduino board.
To be honest, I've been adding some rounding into the hard code as it is because of issues with unit conversions and home offsets. I'm not sure just how much that setting really affects the results. I'm actually incline to just remove it entirely and round to four digits for everything. Maslow is nowhere near accurate enough to handle more than four digits for any units.
are you proposing that WC convert all gcode from inches to mm and send only mm dimensions to the firmware?
No. Just saying a distance in MM with 4 decimals is more precise than in INCHES with 4 decimals. So truncating them using the same number of decimals makes INCHES worse quality then MM.
The only thing I am proposing in this thread is how to deal with updating default settings in WebControl.
Activity
madgrizzle commentedon Jan 17, 2020
TLDR; go for it!
The updating (like most things) was an afterthought and I didn't get everything done that I would like to on it. Currently, it only adds new entries that don't exist but doesn't change anything if it does (as you've noticed). Ideally it would add/remove/modify. If that can be done, then adding in an order key (for how it is listed in settings) would be good as well. Right now, the settings page just shows them in the order they are in the json file.. but if you add something to the defaultwebcontrol.json file, regardless of where it is there, it will end up at the end of the webcontrol.json file (for a particular section). So having an order index would be good.
Correct.
Can you give me an example? I'm not sure what specifically you are asking.
Keep in mind, I'm a hack and cut my python teeth on this program. So if there's a better way to accomplish something, I'm all for it. Sometimes when I program, I take steps in figuring out how to do things and the first step often influences what the second step is.. so after I get done, I might figure out a whole different way of doing it, but I tend to follow the 'if it ain't broke, don't fix it' mantra when there's other things to get done.
gb0101010101 commentedon Jan 18, 2020
So we current have Setting Key "truncate" for "Truncate floating point numbers at the specified number of decimal places"
Lets say we replace this with a new Setting Key "truncateMM" to make it clearer that it applies to MM units only, and then work out "truncateIN" for inches which requires many more significant digits to maintain the same precision.
You've done an amazing job on this project! MaslowCNC and Open Source communities in general need more people like you.
I've often been told that my strictly logical mindset makes me sounds harsh/blunt over the interwebs. I am working on it. So if something I write sounds negative please let me know and do not take it so. Really I just want to determine if a problem exists, and if so, fix it.
So I noticed the default settings are defined in defaultWebControl.json and in settings.py. defaultWebControl.json is the one currently being used. Which one is the newest or more desired method?
Opening a separate JSON file, and possibly writing a new one, using file pointers is slower than just having it all in a one Python file. Willing to keep the current separate JSON file if you see some benefit to it?
davidelang commentedon Jan 18, 2020
gb0101010101 commentedon Jan 18, 2020
Hi @davidelang,
I think we are talking about the same end result using different terms.
The existing "truncate" Settings I referenced is only used by WebControl (which is not running on the Arduino) and appears to be there to address the limited capability of the Arduino board that you mention. I think it is used to reduce precision of gcode before it is sent to Arduino board.
As I understand it, the Arduino can only handle a certain number of decimal places, as you said, but it does not account for units of measure. The units certainly seem to influence precision e.g. 1 mm requires 1 digit but requires at least 5 significant digits in inches (0.0393701) to maintain the same precision. So sending G21 "1" (MM) to Arduino board yields greater precision than sending G20 "0.393701" (INCH) using fewer decimal places and less processing.
Do you agree?
davidelang commentedon Jan 18, 2020
madgrizzle commentedon Jan 18, 2020
If you can figure out a way to allow to make it carry old values, then that would be best.
I think we all worry about how we sound when we write things in forums and etc. I'm not offended by straight talk and realize that written communications lacks 'inflection'. Don't worry about sugar coating with me. :)
settings.py is not used and should be removed from the repo. It was a first attempt (imported from groundcontrol) and config.py was what I ultimately used.
To be honest, I've been adding some rounding into the hard code as it is because of issues with unit conversions and home offsets. I'm not sure just how much that setting really affects the results. I'm actually incline to just remove it entirely and round to four digits for everything. Maslow is nowhere near accurate enough to handle more than four digits for any units.
madgrizzle commentedon Jan 18, 2020
Well, maybe z-axis has the chance to use more than 4 digits.. assuming its not the stock sloppy z-axis.
gb0101010101 commentedon Jan 19, 2020
No. Just saying a distance in MM with 4 decimals is more precise than in INCHES with 4 decimals. So truncating them using the same number of decimals makes INCHES worse quality then MM.
The only thing I am proposing in this thread is how to deal with updating default settings in WebControl.
blurfl commentedon Jan 19, 2020
When making changes, do consider the impact on users that want to be able to use GroundControl as well. See issue #72 .