Here’s my new setup to experiment with code right next to my computer where I don’t have to leave the AC to try new code.
The way I justified this to my wife was to use the whiteboard material (“its a whiteboard!”) and I’ll end up painting it at some point.
Hook it up to a machine you can remote into, stick a plotter attachment on it, and you can leave messages on the whiteboard when you’re not home.
I love the way that you have built it! The cross bracing like that is super slick.
I just half-lapped two 8’ boards (this is made of “leftovers” from some 2x2s I cut for an old project from 2x4s), then cut 45s on the ends, and dowel-joined the outer frame boards to it (and themselves). I still need to add some braces under the whiteboard because I noticed it flexing a little during calibration. Still got great fitness though on a 1m x 1m 9x9 calibration (~ .80). I was thinking it might be easy to make an overlay spoilboard if I want to take it elsewhere and cut on it.
Scrolling past this again gave me the thought to get your take on the thread I was pulling re: allowing for the arms to no longer need to rotate/have the belts trace a vector that passes through the center of the bit on the router, here: Thoughts on the next iteration of the Maslow 4 - #67 by Carson_Barry
When I noticed you mention that python is already being used in the project, I figured it would be worth getting another opinion. I’m too tied down to get acquainted with the repo and explore this much deeper than I already have, plus I’d have to spend some time “skilling up” to be able to do anything with the idea.
When I get done re-organizing my space, I plan on starting to actually cut/print what I would need to modify the sled/assembly so I can test the concept. First by taking the existing arms and putting them as-is on a ring-rail that wraps around the Z-carriage (examples also in the linked thread, just a short scroll up), so the only part I have to reprint to make the “router hole” bigger and enable hotswapping even the default Dewalt are the clamps.
Too much for me to digest quickly, but I’ll have another look at that thread. I am not skilled in the math involved here by any means, and I’ll need to spend a little time understanding what you are attempting.
I’m pretty sure we can be comfortable that the initial math/geometry, which would be used for running the machine, is sound, but what I’m less sure about is the viability of using something like the fsolve in that very last post to solve the problem of needing to reverse kinematics for calibration calculations.
I’ve we’re already using basically the same fsolve process, or something similar, adapting it to take advantage of this geometry may become, essentially, just a matter of swapping the math.
To be clear, that example doesn’t account for Z offset of anchors and expects belts to be parallel to workpiece surface. Accommodating that would just take re-inserting the variable for that value in the relevant places in the equations (I took it out to reduce clutter because it would have been 0 in the example).
Ah, I see. I think javascript is certainly capable and there are many libraries out there to help, but cramming any of them into the html.gz file is an issue. I have been thinking about alternative UI stacks running on a connected computer, where there is more power might be an alternative.
To be clear about the python in these projects, they do not use python in “runtime” only for things like building releases, or supplying a proxy server to test ui code. There is not any python running otherwise. At runtime, there is only fluidnc firmware with maslow mods serving up the index.html.gz (javascript and html) to a web browser. The UI environment has to be very very small (compared to what I’m used to) to fit on the ESP32 and be served appropriately from there.
Good to know. Like I said, wasn’t sure, didn’t know enough to explore and find out efficiently. I realized there would be possibilities outside of python, it’s just where I was pushed when I looked into a solve for the math and I’ve been meaning to get more familiar with it anyway, so it was a 2-birds situation.
As for what I am attempting: there are two ideas, one comes before the other.
The first, which is getting the spools away from the router, I think was already made possible by dlang making it so you can set the distance from center for where the belt passes the encoder something that can be adjusted. This would enable making the Z carriage a more-universal tool mount, opening it up to accepting basically anything that fits between uprights on the rails and screws. Unfortunately, this would require a ring for the arms to travel along, like the old maslow’s linkage.
At this point, the spools could also be redesigned so that the motor is in the middle and the gears are never in a position to interact with, or chew up, the belts. The nice thing, though, is that existing spools could still be used, so less needs rebuilt to apply the mod.
The second stacks on top of that, attempting to make the Maslow more like the Cubio, and allowing the arms to be fixed to the sled and not have to travel around it anymore, vastly reducing complexity of the assembly. This would also have the effect of keeping the sled oriented vertically, enabling more options for things like plotters and drag-knives.