Hi Ethan, I drew your frame, and it seems to me you have an issue-free area of 800 wide and 1800 high
good luck with callibration,
Arjen
2 Likes
WFD wrote:
Yes, you are right. I did not look at opposite arms.
It is turning out that the opposite arms are more of a restriction than teh
adjacent arms.
David Lang
see the discussion at
Maslow 4 frame size checker - #9 by dlang I’m seeing
some errors on this and have some questions.
David Lang
I feel like this would only be the case at the very widest possible aspect ratio. Otherwise, the sled will just rotate until those arms are no longer interfering with the uprights, since there’s nothing necessarily keeping the sled square to the frame
Case in point: at the center of any frame, the opposite arms are always 180 degrees from one another
Hi P,
I used the sizes in your spreadsheet in my parametric sketch in CAD, and I’m afraid the spreadsheet is not correct. The specified frame size of 3600x2700 would only lead to a collision free area of 1800x 1220.
In the calculation a should be 2044 and not 1885
and b should be 3109 and not 2954
the now resulting angle is 120.3 degrees, which is of course lower than the minimum of 130.
David Langs spreadsheet does now give the right sizes
which would would be 4492x 2855 for the shortest frame, to 3933x4100 for the most narrow frame
Arjen
1 Like
when the limit of 130 degrees minimum angle for opposit arms is reached, both arms are touching an upright, the sled then can’t rotate anymore
1 Like
a square frame, 8’ on each side, trying to cut a 5’ workpiece satisfies the angles at the sides, but not the 130 degree angles in the corners
calculating frame size as a ratio is not any more accurate than saying “give it 2’ off the edge” it may seem reasonable on some sizes, but it fails as you move further away from the size that made the ratio look good.
This is what I am coming to note - also that unless someone has a very deep (ie portrait) frame, the top limiting angle of 40° is broadly irrelevant as the angle between the arms only becomes an issue at the extreme sides of the frame.
Plugging in some random ratios started to provide an interesting view but what is also interesting is when the offset is not the corner - which is what I started working through with the Frame Add - as I am assuming that the accuracy at the corners becomes less anyway so having a 2700/1350 work area that has a 2440/1220 board in the centre becomes much less of an accuracy issue at the extremes.
Getting back to the original question, over the weekend I found a bug in the calibration system which might be causing this. Basically sometimes the math was not converging on the correct (optimal) value leading to low finesses levels. I’m working on a fix right now so the next firmware update could fix your issue.
1 Like
I updated to interstitial firmware 0.67.1 to see if the updated algorithm might help (used the same 800x800mm calibration area with 2x2 grid). It didn’t seem to help my setup, new max fitness was about 0.28. Log here: 2024-04-09.txt
I’m also seeing the behavior that others have described where it gets a pretty good fitness and then it degrades in subsequent runs. In my log you can see it gets to 0.283 after around 300 cycles, then degrades to 0.226 after 1800 cycles.
1 Like
Thanks for the log, that is helpful. I’m going to dig into those numbers tomorrow and see if there is something funky going on but it might be normal.
During the process the value will sometimes go down and back up so it will keep exploring after finding a peak to see if the numbers start going back up. (Edit: But it remembers and uses the values from the high point)
The issue that I think you might be having is with the 2x2 grid. The more data points the system has the better it is able to find the correct value (with a good score) that’s why we use 90 points by default. 4 points probably just don’t contain enough information for it to converge on the correct answer well.
A 2x2 grid is great for quickly testing if the basics are working (ie can you even get through the whole process) which is why I was encouraging folks to use such a small grid to test when we were fixing bugs which were preventing folks from getting ANY answer, but if you want a good answer I think that more points are needed.
1 Like
Great point! I tried switching back to a 9x10 grid and calibrating again (retract, extend, calibrate). What I got was still fairly poor (0.2139). Log here: 2024-04-10.txt. Config file too, in case that helps:
maslow.yaml
In an effort to remove bad points, I created a spreadsheet to remove a few I thought might be contributing badly. I first removed points that were adjacent to a “Motor current on XXX axis exceeded threshold” error message and came up with a new “CLBM” statement. Using the calibration tab feature from @ronlawrence3, I ran the calibration again with the new point set and got a similar fitness of 0.219.
I then removed even more ‘bad’ points by looking at the cal details preview in that tab and throwing out any that looked bad (points that didn’t seem to match the grid). That helped a little, got the fitness to 0.315. Am I onto something, or am I just getting a false ‘better’ result by throwing out bad-looking points?
1 Like
note that my calibration thing does not have Bar’s new algorithm yet! I will try to merge that in tonight if I have time.
2 Likes
Sorry, needs a bit more than a simple merge, so it may be another day. I may have time later tonight after I get back from our errands to try to fix my merge and push it up.
3 Likes
@bar which ESP3D branch is your newest calibration logic? I merged Maslow-Main and did not see the results I expected…
1 Like
@bar, I have a 2438x1066 frame. Able to get through calibration after dealing with a belt jam on the new firmware. My frame is a piece of plywood. I only need a small work area in the center. I used the fully 3d printed anchors that were uploaded in the forums by Dan Bunby (they work amazingly by the way). I used the 0.67 and 0.68 firmware and have very low fitness on both calibration runs:
Fitness: 0.03773664319222134 in 1500 cycles
Fitness: 0.03799678058125825 in 1600 cycles
Fitness: 0.03820953516957285 in 1700 cycles
Fitness: 0.03836836842437151 in 1800 cycles
Fitness: 0.038436186861047064 in 1900 cycles
Fitness: 0.03847548371880548 in 2000 cycles
Fitness: 0.0384808176286419 in 2100 cycles
Fitness: 0.03846896653563891 in 2200 cycles
Fitness: 0.038425916849816055 in 2300 cycles
Fitness: 0.0383975581743906 in 2400 cycles
Fitness: 0.0383734153357456 in 2500 cycles
Fitness: 0.03836100743636753 in 2600 cycles
Fitness: 0.03833298788794225 in 2700 cycles
Fitness: 0.038307802541049554 in 2800 cycles
Fitness: 0.03828661847572996 in 2900 cycles
Fitness: 0.03826680225055586 in 3000 cycles
Fitness: 0.03824691083417708 in 3100 cycles
Fitness: 0.03823390748961487 in 3200 cycles
Fitness: 0.038219067236553 in 3300 cycles
Fitness: 0.038202385183761886 in 3400 cycles
Fitness: 0.03819945443277461 in 3500 cycles
WARNING FITNESS TOO LOW. DO NOT USE THESE CALIBRATION VALUES!
Calibration complete
Calibration values:
Maslow_tlX: -91.8
Maslow_tlY: 913.7
Maslow_trX: 2294.6
Maslow_trY: 1013.9
Maslow_blX: 0.0
Maslow_blY: 0.0
Maslow_brX: 2331.5
The sled travels almost right up to the edge of the anchor. Was hoping to get away with not having to build a large frame due to space constraints. Just in a garage and want to pick up the board and set on my Bora workstand, connect and get to cutting. Would even be happy with a 4’x3’ cutting area. Not sure why the values are so low. Does it have to do with the size? My area is no where near as small at the 2x2 you mentioned above. As an aside, as mentioned on another thread in the forum, that bottom right motor puts out a lot of slack, way more than the others.
1 Like
It should be on Maslow-Main. This is the pull request:
What are you seeing? Are you still getting a low value?
Do you have the measurements? I can take a look at those.
This might have something to do with it. I haven’t tested that configuration, but it might be worth making the calibration grid smaller and further from the anchor points. I would expect that to help.
Yes, low values I did not expect with the new code. I think those are the changes I merged I’ll compare to my old numbers and the calibration simulation code and see if I went wrong or just have a new problem, then I’ll share 
1 Like