I’ve opened pull requests to bring those two branches up to speed with the master branches. When you have a chance, if those look OK, merge them into your fork to bring it up to date.
After that I can create pull requests to bring your changes back into Master. I’m thinking Friday in the late afternoon / evening to give us the best chance of getting everything tested over the weekend.
So, I looked at the pull requests. Something went wrong. There is one change which reverts the kinematics updates from @codepr1sm. That reversion creates conflicts and does the wrong thing. Unfortunately, that means we are not ready for testing, yet. It is going to take some work to resolve the conflicts.
In light of that, I’ll close the PR to keep the robot from merging it.
Before re-opening it or creating a new one, shouldn’t the matching firmware PR be opened at the same time? In my testing the PR code crashed on the “Push to machine” step after running the holey calibration sequence.
While you’re polishing things
• how about indicating how the measurements are to be made in the instructions? I assumed center-to-center, but there have been times in the past when folks talked about near-edge to near-edge.
• while precision is desirable, wouldn’t it make sense to round the error in the calibration result screen to the nearest .05mm instead fo showing error values smaller than that?
• The tool path for Point6 is vulnerable to friction - consider moving to a point ~10cm above and 2 or 3 cm beyond it then moving back to the final point to reduce this.
• how about indicating how the measurements are to be made in the
instructions? I assumed center-to-center, but there have been times in the
past when folks talked about near-edge to near-edge.
center to center and left-edge to left-edge should be the same. edge to edge is
easier to measure (unless you have something like the vernier tape measure
adapters)
• while precision is desirable, wouldn’t it make sense to round the error in the calibration result screen to the nearest .05mm instead fo showing error values smaller than that?
that sounds like a good idea
• The tool path for Point6 is vulnerable to friction - consider moving to a point ~10cm above and 2 or 3 cm beyond it then moving back to the final point to reduce this.
fair point, but that’s papering over the problem, if friction affects the
position like that, it will affect the cut like that. we need to test and find
if this is really a problem (and if it is, walk the user through fixing it and
then re-drill the holes)
David Lang
What is polish? A type of sausage?
This is good feedback. I will do my best. When it is merged, anyone can make these updates.
I like this observation. It is like the cutting process is creating some potential biases. In addition to this, I was just recently thinking the timing of the holes may cause some issue. We know the position controller isn’t perfect. Since the gcode drills immediately after arriving at the point, it doesn’t give the controller a chance to stabilize. I think there should be a pause before drilling the hole.
I agree with this. I recommend a 12 ft top beam because of this. I still think the calibration could be slightly less biased, if this friction wasn’t built in.
I tried to resolve the conflicts with the main Firmware fork. Based on everything I see, I think it is OK; however, I didn’t personally test it. So, it should be ready for another alpha test.
BTW, I think someone asked for a link to the instructions on how to use Holey Calibration. Here is the post:
Yes, the calibration pattern should automatically adjust to whatever values you have for the width and height of the cutting area.
If anyone with a functional machine could try download the Holey Calibration fork, and just click through the calibration to see if there is an error somewhere, that would be helpful.
I just downloaded the links from the other post you linked to. I’m going to get it set up and see if I can’t poke around a little. I don’t have time to do a cal routine tonight.
Edit: Alright, I hit a wall. Probably just my lack of understanding as to how Python works.
I am getting an error when trying to run “HoleyCalibration.py” that says that scipy isn’t installed. I followed the instructions to install Anaconda first, which I thought included scipy? Or am I misunderstanding how to get Holey Calibration running?
There is a GUI, so you don’t have to run the script. I am not sure why scipy wasn’t installed, or isn’t recognized.
If you’re just running from the source, I think you have to install all the requirements to make it work. But I don’t see a requirements.txt file in ground control’s repo… just ones specifically for linux and macos, and both of those don’t mention scipy.
So you can’t just run:
pip install -r requirements.txt
Instead, you will need to do:
pip install scipy
and if you get another error when you try to run it again, you will need to do the same for each missing module.
I think there is a list of requirements under the wiki page for the install process here:
Perhaps we should include that information in a better way?
Ahh, that’s been my problem. I’m not sure how to get to it, though
When I open the zip file from Github I see this:
So I ran build.bat and put a “pause” at the end so I could see what it was doing.
Looks like I’m having trouble with Python. I have 2.7 installed but it seems like i’m not accessing PyInstaller.
I know it’s probably a simple fix, I’m just not that savy 
Hey Bryan,
I am trying to review this issue. I, personally, haven’t ever installed it on a Windows machine, so I don’t have any experience with the issues you’ll encounter. I like to believe someone on this forum would have more experience at this than me, and would be able to help.
For now, the best information I can provide is this. Scipy can be installed easily from the command prompt.
It is like there are two users of Holey Calibration. Those who have used it, and haven’t had any problems, and those who cannot install it. It seems like the next step is to address the Windows installation issues.
Sorry for a massive delay on my end. Life has been getting in the way of a lot of things recently. Hopefully I’ll be fixing some of that soon and I won’t be so out of the loop here.
I really want to try to figure this out. I think I’m close.
I still can’t find anything resembling a GUI, so I went back to trying to run it through the script. If everything’s installed correctly, I should be able to just run main.py and get to the Ground Control GUI, right?
I followed @Bar and @Joshua’s directions and I think I have all the dependencies installed, but I can’t seem to get main.py to run.
As a summary, I ran the following commands successfully in cmd.exe:
As quick note, I did get a depreciation notice with the installation, as well as some path errors:
Not sure if that’s part of my problem on the next step:
I do see that it says it’s missing a module named “PIL”, but this is what happens when I try to install it:
Ive now converted 2 arduinos into bricks trying to get holey to work.
My kit runs with linear calibration. It cuts inaccurately and imprecisely. My frame is a solid wall and the easel a sort of bookshelf. All chains run really well. If I ask 360,10 or any other jog the machine moves freely. I’m cutting into insulation foam. I am doing all of this from web control, running on a pi4. I can cut a g code test file, square is not square and if cut to one end (not board centre) it’s a bit curvy. All as expected out of the box.
I have two controllers.
Metal maslow (with a different Arduino as the one supplied did not work). After a few attempts it stopped accepting uploads. Swapped to another mega. Holey uploaded.
Now I get “sled can’t keep up”. Also the z axis no-longer responds to up/down commands (it moves random direction and random amounts)
EastBay’s kit arrived today.
Their controller plugged in and gave exactly the same result with the default firmware (not holey).
Their controller also does not take the holey firmware. Stops during upload. After two iterations their Arduino now no-longer responds to Webcontrol.
Question
Peace, love and thanks for reading my long post.
I’m not sure what could be wrong with the upload of the firmware. There might be some errors occurring that would print to the terminal screen if you could view it. There should not be anything special among arduino versions. R3 should work. Unfortunately, I’m not in a spot to be able to do any troubleshooting for weeks (up some mountains).
You should still be able to re-flash the base firmware to the arduino to revive it. I haven’t tried it myself, so I’m not sure if that’s the correct solution. I recently upgraded to WebControl myself, but I haven’t tried the Holey Calibration update just yet.
Arduino rescue - wrote an old project onto the board, then plugged back into Webcontrol. Result = Resusitation.
Today I put the EastBaySource shield on my Arduino
