Here’s the issue. In the Holey Calibration Model, the coordinates of each hole is calculated and Hole 0, which is drilled at where Maslow thinks the center is (0,0) is assumed to really be at 0,0. But let’s say the left chain has more wear than the right chain but chain tolerance is set to 0 for each chain. Even though Maslow thinks the sled is directly between the two motors, it’s really not. The left chain will be slightly longer than the right chain and therefore, the sled will be slightly to the right of the actual middle point (and I guess down a little as well). This is what I’m trying to account for. It’s an exercise to see if this makes a difference. Eventually, through multiple iterations of calibrations (assuming linear chain wear) you will get a calibration where the 0,0 is really equidistant to the two motors (assuming top beam level). After one run, it calculates my 0,0 is about 0.0034 mm to the right of middle… something really small… but the right motor is ~3mm higher than the left which is about 0.1 degrees tilt of the top beam.
The difference between allowing this adjustment:
With adjustments:
Error Magnitude: 0.809
RMS Error Hole 1: 1.2549
RMS Error Hole 2: 1.3436
RMS Error Hole 3: 0.9535
RMS Error Hole 4: 0.9713
Without adjustments (no tilt or shift left to right):
First, there is no current ground control or firmware that can actually use the values that this routine generates. I’m working on it, but right now it’s not done.
Second, go ahead and calibrate your machine using the current method, but at this point, I recommend setting chain tolerance to 0 when calibrating. After the machine is calibrated, then do the following:
Once again, ensure your chain tolerances to 0.
Load the gcode for the hole pattern
Run it
Measure the distances shown on the diagram on the first post
Edit the python code of the new calibration (will update it today):
change the motor spacing, motorYoffset, rotation radius, chainSagCorrection, chainOverSprocket to what they are when you did the cut.
change the desired motor spacing as well… when I ran the test pattern, I had a wrong number so I incorporated this feature. Chances your desired motor spacing is equal to 3602.6 is very slim
if using a ring kit, try leaving desiredRotationalRadius at 139.1 and see how it goes.
change the default values for the measurements
In command prompt, run “python newcal-holes.py”
It will first calculate the x,y coordinates of the holes and display them… press Enter
It will then make calculations of chain lengths to each hole based upon the machine’s parameters and display them… press Enter
It will run through a bazillion iterations of trying different solutions and will print the ones that make improvements. Eventually it will look like its frozen, but it will continue to try to find better solutions.
Eventually it will present a message. Type ‘x’ and then press Enter to exit. The last printed solution is the best solution
As for the mark, you’ve got to figure out how to make the mark. Mark 5 needs to be the point where a line straight down from Hole 0 crosses a line drawn straight between Holes 2 and 3. This is the more challenging one to define. I can’t just drill a Hole 5… It needs to be determined. What I did was draw a line straight down and then marked where my tape measure stretched between Holes 2 and 3 crossed it.
As for new version, eventually if this works will will be done through a PR. But I’ll have a fork for people to test well before we get to a PR.
From what I understand is that I should override the values that GC calibration found that seem wrong.
I my case motor distance, height of the sheet in Y and the rotation radius are not near the hand measured values, so I think I should enter my more trusted numbers.
@madgrizzle Running the script in the office with the default values I get:
-------------Machine parameters could no solve to your desired tolerance, but did you really expect to be able to?---------------------
Although I like the humour, it’s still a bit discouraging
Heading over to workshop to feed the snake with some real life numbers and are hoping for
I tried this morning to use the new firmware (had to fix some errors in what was posted to get it to compile) but now I can’t even get it to move. I need to figure out how to debug firmware on the arduino… it could be hitting a math error and crashing or something.
So, like I said before, there’s no firmware that can use these numbers. You may be able to try to take the chain tolerance values and use them in the existing software by doing this:
so if you get a 0.99934, the value for current software should be (1 - 0.9966) *100 = 0.33
That might work.
And you cant use the top beam tilt numbers… but it might help you determine how level your top beam is. Again, it might. Whether or not the tilt adjustment is real, I don’t know.
To explain the new firmware, I’ve added a setting for top beam tilt and I’ve changed how the chain tolerance is used. Currently, chain tolerance is used to adjust how many millimeters of chain is fed out per rotation of the sprocket. I don’t think this is the best way to handle it, and in this firmware, it just changes the calculations (inverse triangular) on how much chain to feed out. As I said above, the software isn’t working so don’t try to use it.
I’ve updated the GC/firmware on my github. I had some really dumb mistakes in the firmware so I hope the revisions work. I’ll know later today/tomorrow when I get a chance to compile and upload them.
I’ve also updated the newcal-holes.py to be less discouraging and give the values needed for entering into the revised GC.
So a little about the top beam tilt and x-axis shift of center. The reason I incorporated these values into the calibration routine was to try to eliminate any assumptions. That way, if the assumptions are bad, we aren’t adjusting values that shouldn’t be adjusted to overcome the bad assumptions.
The top beam tilt has made it as a setting in GC and is used by the firmware because if there is a tilt, there is a tilt. If you don’t like having a tilt value, then make the frame more level. Honestly I don’t know if it works because I’m surprised that my frame is within 0.04 degrees of level and maybe some of it is being compensated by chain tolerances. Nevertheless, I’m going to try using that value and see what happens.
However, I’m not making the x-axis shift of center a setting in GC or firmware because I don’t think it should be. My rationale is that if you are going to do multiple (at least two) iterations, then eventually the chain tolerance values will produce a 0,0 that is truly in the middle horizontally between the two motors… at least theoretically that is the case.
Sorry… not following… top beam tilt changes the X & Y coordinates of the motors. It makes the right motor a little higher or lower than the left motor depending on tilt and brings the x coordinates in a wee closer so that the distance between motors is maintained at what you set it for.
Something i’ve been wondering though - if the whole machine is tilted wouldn’t it work the exact same way as if it was level? What we don’t want is tilting of the motors in relation to the workpiece, not necessarily in relation to the groundplane. So if we compensate for the tilt of the motors, we should first make sure that the workpiece is not also tilted in the same way as the motors are.
Thats part of my point. It must be the responsibility of the end user to make sure things are level. It would be tough to raise a motor a mm accurately unless a slotted mounting bracket was implemented. Although I have to admit I don’t fully understand @madgrizzle 's process and I assume most of it is getting the math dialed in and not physically moving things around.
It’s strictly to try to find a solution. If the top beam is actually tilted, then the calibration process will try to compensate for it somewhere. The process calculates the x,y coordinates of the holes and the x,y coordinates of the motors. The motors coordinates are based upon the top beam being level. If its not, then the coordinates of the motors will be off. And therefore the chain length calculations needed to get to each of the holes is off.
The coordinates for the holes is independent of whether the frame is tilted… none of coordinate calculations for the holes reference an edge of the plywood… Mark 5, which is “gravitationally” below Hole 0, sets the reference. The whole frame could be tilted but the coordinates for the holes won’t change. But if the whole frame is tilted, the coordinates for the motors will be off. Therefore, something will be changed to minimize error… seems that chain tolerance is the most likely.
So by having a top beam tilt factor, I can try to mitigate changes to chain compensation to account for a tilted top beam. This was the goal of incorporating it. Like I said early, the routine calculated and incredibly low tilt for my top beam. I can’t imagine I’m that accurate so I still think chain tolerance is taking up some of the tilt.
I got the calibration, firmware and ground control updated to work together. After two runs of calibration, I get really low error calculations. I did some test holes (18 inch up and down from center, then 36 inches left and 18 inches up and down from center). I was off by 1/16 the inch in the holes at the edge of plywood and dead on in the middle… which seems really good. But then I ran a 16-inch radius circle in the middle and was surprised at how much the radius varied around the circle (+ 1/8 inch to - 1/16 inch). I’m afraid I calibrated so we’ll to the corners that the middle has suffered. I more and more suspect uneven wear of my chains because that’s about all that seems to explain it. I know my router isn’t perfectly centered in the ring but it’s not that far off. I’ll try switching out the chains now for my new ones. If that doesn’t help, I might add a set of holes near the middle to give more calibration points.
Oh, the GitHub repository changed… I had to scrap the firmware and ground control I had modified and didn’t want to delete it, so I just made a new repo
Would it help to find a open source Delta 3D printer? I know that it has three Oxys instead of two and it doesn’t have to compensate for chain stretch, gravity… But when it’s making a move perfectly perpendicular to two of the rods the math must be similar and therefore possibly useful in what you’re trying to do with the Maslow?
run, edit in the newcal-holes.py the following lines with your values:
