Discussion: Maintain Holey Calibration Firmware on WebControl CNC Organization

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.

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 <notifications@github.com> 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?
Proposal of Kinematic calibration model:
B20 = standard (default)
B21 = holey
B22 = optical
B23 = reserved for the next kinematic model

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

@madgrizzle

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.

Navigation Menu

Repository navigation

Discussion: Maintain Holey Calibration Firmware on WebControl CNC Organization #144

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Discussion: Maintain Holey Calibration Firmware on WebControl CNC Organization #144

Description

Activity

Orob-Maslow commented on May 21, 2020

madgrizzle commented on May 21, 2020

davidelang commented on May 21, 2020

Orob-Maslow commented on May 23, 2020

madgrizzle commented on May 23, 2020

emilecantin commented on May 23, 2020

davidelang commented on May 23, 2020

Orob-Maslow commented on May 23, 2020

madgrizzle commented on May 23, 2020

madgrizzle commented on May 23, 2020

Orob-Maslow commented on May 23, 2020

davidelang commented on May 23, 2020

davidelang commented on May 23, 2020

madgrizzle commented on May 24, 2020

davidelang commented on May 24, 2020

emilecantin commented on May 27, 2020

madgrizzle commented on May 27, 2020

emilecantin commented on May 27, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions