So whats the deal with holey calibration

No Judgement
1

First, I’ve taken a hands-off approach when it comes to ground control as I’m focused on webcontrol.

Second, I’m unable to do any testing/verification/etc (repurposed motors and RPI for testing a four motor design)

With that said, @bar and others… what’s needed to get holey calibration getting incorporated into ground control? It’s pretty clear there’s frustration on behalf of those that spent a lot of time and energy making it happen and I think it’s basically sitting there as a fork. It’d be nice if there was a plan in place to get it incorporated. I personally think the methodology makes more sense than the current calibration model.

.

6 Likes
2

I can create another pull request, if that is the missing step.

2 Likes
3

Holey is ready for testers in Webcontrol right?

1 Like
4

I think that all that needs to happen is for us to be sure we’ve tested enough that we’re not going to be breaking anything. I’m in the same boat that I’m pursuing the four motor setup so I can’t test. If we have a pull request where two people say that they have:

  1. Gone through the holy calibration smoothly
  2. Gone through the original calibration process to show that it still works

I think we’re ready to merge.

Any volunteers willing to take on testing the pull request?

1 Like
5

I have gone through Holey Calibration successfully. That probably doesn’t count. A few others have; evidence is on the forum topic. I did set it up to operate as a second option to the original triangular calibration, and that process was not modified. However, I haven’t tested the triangular calibration, and I don’t think anybody has.

1 Like
6

Holey calibration is supported by webcontrol. It’s enabled once you update to the holey firmware that’s included within.

2 Likes
7

we need to make sure that when holey calibration is added as an option, it
doesn’t break the existing calibration.

David Lang

1 Like
8

I’m getting awfully close to getting my Maslow back up and running again, and I would be willing to give Holey Calibration a trial run. Problem is, I’ve been very out of the loop on the development so I’m not sure where to begin with it. Is there documentation on how to get from 0-60 on this?

My understanding from reading this thread is that I would need to run Holey Calibration (once I have that all sorted out) and then the normal calibration to check if they both work. Is this right?

I should have my machine running again within the month. Admittedly, I bet others will probably beat me to this.

1 Like
9

Same issue here. Happy to assist in the next week or two, but not sure where to begin and what the necessary outputs are.

For example, I am currently using the original calibration process. However, it mis-measures my motor spacing and (usually) results in cut dimensions being smaller than what is in the gcode. Would “working” be defined as not making this worse?

2 Likes
10

“working” with the new code and triangular calibration would be defined as
making no difference

“working” for triangular calibration would mean better results.

David Lang

2 Likes
11

I think the steps are:

  1. Let’s create a pull request for exactly what we want to see added. That way we are all testing the same thing. The pull request should have instructions for how to test it attached.

  2. We all give the pull request a test following the instructions and give it the :+1: or :-1: accordingly.

  3. The robot will take care of the rest :grin:

Given that we have just 48 hours to test once we create the pull request it might be a good idea for us to coordinate ahead of time so we know when it’s coming.

2 Likes
12

Is that 48 hours configurable?

2 Likes
13

Okay, so it isn’t too complicated for those of us who have already done some testing with the Maslow. :smiley:

I’m more than happy to coordinate with anyone else testing this out. I need to sort out the counterweights for the slack side of my chain, and then I should be ready to dig into calibration. I’m hoping to get this done this weekend, but that could get slowed down if I hit any snags.

2 Likes
14

In theory, but last time we configured it things broke…I think we fixed the bug which caused that, but I haven’t tested it since the fix.

Does anyone feel comfortable taking charge of opening pull requests? I am not hip to the latest to know what we want to be merging

1 Like
15

Sorry I missed the deadline for this weekend’s activities. We should probably shoot for next weekend. Something around Friday or early Saturday would likely be best. Thoughts?

2 Likes
16

No worries @Joshua, I just got the counter-weights figured out on my machine this weekend. Still have to do the basic calibration to find the dimensions for the new top beam and I should be good to go. I am planning to get that done over the week, so Friday into Saturday would be good for me. If we start the test around 3pm-4pm on Friday, that could keep the window open into Sunday, as well, if that helps some people.

I’m pretty excited to see the results, as I’m basically starting from the beginning with this setup. Enough has changed on my machine that next to none of my previous settings will be useful.

@Bar I’m also not very learn’d in the ways of Github, so I’m not sure I’m the right person to orchestrate that. :frowning:

17

to prepare a PR, someone needs to fork the code and implement the new
functionality, can someone copy the config that compiles/packages GC to a
separate repository or branch where we can leave it up for a week or two?

David Lang

18

I’ll build the macOS testing version when the fork is ready.

1 Like
19

Where is the code that we want merged in located? I can take on making the pull request.

20

I haven’t merged any changes in since the latest tag, so we will have to check that first.

Here are the links.


2 Likes