Your board with permanent attached heatsinks should get to you by next weekend. It’s on the machine testing now and waiting for more Mega 2560s to arrive Monday.
Thank you
3 Likes
First of all, in my opinion, a really good day would be just sitting in the room while @madgrizzle and @johnboiles problem solve and brainstorm together. I suppose reading a forum thread with said brainstorming will have to suffice as second best!
Second, is there any way you could prove (or at least help find) the source of the periodicity by running it in vertical columns up and down rather than left and right (then compare results)? Since most of this is simply magic to me I can’t pretend to know what I’m talking about. Perhaps this is not possible or perhaps it is a terrible idea. And, while I’m spouting terrible ideas, is there any chance that the center of the sled (i.e. camera) might be slightly below the calculated “tip of the triangle” (where the chains theoretically converge)? If that were the case wouldn’t the results be that the friction of the sled would hold the center point ever so slightly to the left as you moved right across the board and vice versa? I’m curious which triangulation solution you guys are using? (I probably read it somewhere but now I can’t remember)
Either way this is good work guys! I’m excited to watch this evolve!
-Logan
3 Likes
I’m currently using the ring kit but I do have your wooden linkage kit. I was hoping to do a comparison of the two (along with @dlang’s kit). My router is not perfectly centered with the ring. It’s not horrendous, but not perfect. I eagerly await the chance to buy a laser cut sled (maybe three… one for each kit type). The offset can definitely affect the performance. The system takes into account the camera being offset from the router bit (at least I think it does), but to try to account for the router bit offset from the center of rotation has proved challenging. @johnboiles came up with a way to do it theoretically, but when in practice it was difficult to manage (you had to rotate the sled by hand and that introduced error)
I can certainly change the scan direction from left to right/right to left to up to down/down to up. Good idea.
4 Likes
In my tiny bits of spare time here and there I am definitely working on a laser cut sled/sled template! I’ve done some shipping pricing, and material costs will change depending on what I use. I’ll try to keep everyone posted!
Thanks!
-Logan
4 Likes
+1 great idea.
1 Like
+1 to this too. Imagine if all of us were in the same space (or even same time zone). I bet we could move very fast! (and have a lot of fun)
I’m using the ring kit, so the slightly misaligned axes could certainly cause issues. But I don’t think the scanning direction is the issue in my case. For me, there’s 1mm amplitude periodicity in the y dimension and it doesn’t seem to correlate to the direction the sled is moving. This means that everything appears to be going up 1mm then down 1mm for every square horizontally on my pattern. Sometimes multiple rows have periodicity in the same direction – that is, no matter whether i’m scanning to the right or to the left, some of the adjacent rows still seem to be up or down in the same way. In the chart I posted last night, each line is a row, the y axis is the y offset and the x axis is calibration square index from left to right (-10 to +10 in my case). See rows 3 and 2 and rows 0 and -1, for example of adjacent rows with different scanning directions that have the same pattern.
Exciting! Attempting to get my sled perfect was definitely stressful for me. I tried really hard and I think I’m probably still 1mm off. A better solution for that would definitely be welcome!!
1 Like
I just finished the run using “your” method and the results are very similar to “my” method. So, there it is. I’ll push it up.
2 Likes
@madgrizzle happy to run another test tonight. Anything in particular it’d be helpful to look into?
I’m kinda wondering if I had lingering EEPROM values from earlier calibrations that could have been affecting my calibration run. Seems like possibly curve fitting could cause some oscillations if the curve calculation was off a bit. To be sure I might wipe EEPROM before running the calibration again tonight. I’ll also try setting the scale factors based on measurements of my test pattern.
missing steps would result in the position drifting over time. Uneven steps
should not matter at 8000 steps per revolution, so one step is ~0.0003 in, so
being uneven by a massive amount such as 30% would be an error of ~1/10,000 in.
This isn’t even close to the errors we are seeing.
David Lang
Do you have a design up somewhere? I could go get one laser cut somewhere near me potentially.
You should disable calibration in settings when you do the calibration, that way it won’t use anything in memory.
1 Like
can you run a test moving in the opposite direction? Even if you only did a row
or two, it would show you if this is the problem.
David Lang
Good call, should we make this happen programmatically?
Thanks for thinking it through! I’ll nix that theory then
no, it’s the firmware that does all the real work, ground control just stores
copies to passto the firmware whenit’s upgraded
Probably so… Also, the option to do vertical scanning is programmed in there, just requires code change in a couple of places. The routine is called on_AutoHomeVertical vs. horizontal scanning which is just on_AutoHome… so you can edit groundcontrol.kv to use it. Also, if you do, you need to change this line
in order to call it after the first square is found.
It might be a little more “stable” scanning up and down vs. left to right, but its really hard to say. I didn’t have periodicity going left to right (or at least havent recently).
X Axis Error (Scanning Horizontally)
X Axis Error (Scanning Vertically)
Y Axis Error (Scanning Horizontally)
Y Axis Error (Scanning Vertically)
The really bad error values are all at the extremes.
Is that Y axis in the graphs mm? It definitely looks like there is some periodicity of ~0.5-1mm in some of those lines. Seems just a little too regular to be random (especially in the ‘Y Axis Error (Scanning Vertically)’ chart).
Also it looks like you’re seeing 5-10mm error difference from one side of your board to the other? The x-axis could be explained by the not-exactly-perfect spacing of the 3in pattern. But I don’t understand why the Y values would be so different from one side to the other. Is one side of your board higher than the other? I’m trying to understand how these graphs relate to the physical world.
Yes. I’m doing this from phone so I’ll be terse.
Yes, my maslow is in a shed and I’ve struggled with keeping the things level. You’d be amazed at just how small an angle results in many mm difference over 3000 mm. My hope is that this methodology will mitigate to an extent.
Remember, the routine stops homing in when it’s within 0.125 mm x and y. And, when it moves to the next square, it uses the offset determined from the previous square as a guess… so it might (/shrug) be that it overshoots one way then undershoots the next and so on.
2 Likes