Discussion: Maintain Holey Calibration Firmware on WebControl CNC Organization #144
Comments
|
Do you think the system has sufficient memory and ram to do both? |
|
Yes, it's really just different kinematics functions and a setting. But then modifying webcontrol to work along with it.. it's just not trivial. Certainly doable and probably not hard. I like this idea because what changes are made to one get made to the other. The support for R in G2/G3, for example. |
|
we really should find a way to merge them, but have a config option to switch
the type in use.
ideally merge in the optical calibration style correction table as an option as
well
David Lang
…On Thu, 21 May 2020, madgrizzle wrote:
Date: Thu, 21 May 2020 09:59:53 -0700
From: madgrizzle ***@***.***>
Reply-To: WebControlCNC/WebControl
***@***.***>
To: WebControlCNC/WebControl ***@***.***>
Cc: Subscribed ***@***.***>
Subject: [WebControlCNC/WebControl] Discussion: Maintain Holey Calibration
Firmware on WebControl CNC Organization (#144)
Currently, the holey calibration firmware that gets built to be included in webcontrol releases resides on a firmware branch on my repo. Ideally there would be one firmware, but it doesn't look like holey calibration will make it into the official firmware. People are making PRs for the official branch, but the holey firmware on my repo isn't getting updated.
So, how do we manage this? Do we want to put both firmwares here and 'disconnect' from maslowcnc? Do we want to move my firmware fork over here? There's probably a number of commits to the official master branch that aren't in my holey branch that needs to get sorted out. I'm not a github pro and probably would break something trying to cherry-pick the commits.
One thought, that's not necessarily trivial, is to have just one firmware and allow users to switch from triangular to holey via setting.
|
|
Specifically which branches / versions should be merged? The webcontrolcnc/firmware release Holey branch and the release maslowcnc from the same repo or the one from the maslowcnc repo? |
|
I think we should use what's in the master branch on maslowcnc/firmware and then merge in what is in madgrizzle/firmware/holey-firmware. |
|
I already merged the upstream repo yesterday, master on our repo is at the
same point as master on the maslowcnc/firmware repo.
The three firmwares we build are under the release/xxx branches. I guess
the work that needs to be done is to open a pull request from release/holey
to master, and work in there.
Please create another branch from release/holey if you're going to work in
it, as I'm working on build automation on these branches right now.
Le sam. 23 mai 2020 12 h 15, madgrizzle <[email protected]> a écrit :
… I think we should use what's in the master branch on maslowcnc/firmware
and then merge in what is in madgrizzle/firmware/holey-firmware.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#144 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGYF3XDMASGIKHOJC6XGY3RS7ZDRANCNFSM4NG7WMZA>
.
|
|
note that it's not just a simple issue of merging the holey branch, if you do
that the result will only support the holey calibration parameters (that's what
went wrong initially)
it's a matter of merging the functionality, but adding a mode to switch between
the calibration types.
David Lang
|
|
A switch or setting needs to be added to select which kinematics model is being calibrated or used... thoughts on a command that would toggle the switch? the B17-B20 are for zaxis endpoints. Should we go with a B command or something more exotic? |
|
I think we should add a new setting for triangular kinematics type.. either "standard" or "catenary/holey". |
|
Or maybe just add setting to enable holey calibration.. might be better option? |
|
It can be called whatever you want. Does it need to be toggled with a gcode command? |
|
I think the model to use is probably better as a $ setting (since the
calibration parameters arealso $ settings)
that way there's one place to set the calibration type and you can read it by
dumping the one value (and no worries about what to do in the future as more
types are invented)
David Lang
…On Sat, 23 May 2020, Orob-Maslow wrote:
A switch or setting needs to be added to select which kinematics model is being calibrated or used... thoughts on a command that would toggle the switch? the B17-B20 are for zaxis endpoints. Should we go with a B command or something more exotic?
Proposal of Kinematic model:
B20 = standard (default)
B21 = holey
B22 = optical
B23 = reserved for the next kinematic model
|
|
On Sat, 23 May 2020, madgrizzle wrote:
Or maybe just add setting to enable holey calibration.. might be better option?
we already have two modes in the firmware (quad/triangular)
we now want to add holey triangular (or some other name based on the additional
parameters that are set rather than the way those parameters are calculated
Your Optical calibration gives us a couple other types
grid interpelation
wave correction
and there will probably be more, if only a more flexible interpelation option.
David Lang
|
|
I think if the error matrix/curve is to be an option, I should be an additional layer on top of any calibration.. that is, you calibrate with triangular, you can then add an error matrix on top of it. Same if you calibrate with holey. It shouldn't be its own calibration. |
|
On Sat, 23 May 2020, madgrizzle wrote:
I think if the error matrix/curve is to be an option, I should be an
additional layer on top of any calibration.. that is, you calibrate with
triangular, you can then add an error matrix on top of it. Same if you
calibrate with holey. It shouldn't be its own calibration.
get close with something else and then fine tune with the error matrix/curve?
plausable, but I'm not sure it's needed.
the triangular calibration (while it was progress when it was created), was
created before we understood the sources of error and it's activly mangling
machine dimensions to try to make things good in the test cut area (even if it
makes things worse elsewhere)
I think that going with the uncorrected machine dimensions would be equally good
for the error matrix approach, and I suspect the error curve approach wouldn't
be much worse.
but with a $ setting for enumerating possible modes, we can just list the
combined modes if we find they are useful.
I think we need to do testing to see if the combinations make sense before we
reserve the slots for them
David Lang
|
|
In the spirit of keeping things clean, I think we should have firmware discussions over on the WebControlCNC/Firmware repo. @madgrizzle can you enable issues on that repo? There should be a checkbox for that here. Let's close this issue once it's done. |
|
Checked |
|
Moving this to WebControlCNC/Firmware#6. |
Currently, the holey calibration firmware that gets built to be included in webcontrol releases resides on a firmware branch on my repo. Ideally there would be one firmware, but it doesn't look like holey calibration will make it into the official firmware. People are making PRs for the official branch, but the holey firmware on my repo isn't getting updated.
So, how do we manage this? Do we want to put both firmwares here and 'disconnect' from maslowcnc? Do we want to move my firmware fork over here? There's probably a number of commits to the official master branch that aren't in my holey branch that needs to get sorted out. I'm not a github pro and probably would break something trying to cherry-pick the commits.
One thought, that's not necessarily trivial, is to have just one firmware and allow users to switch from triangular to holey via setting.
The text was updated successfully, but these errors were encountered: