Even without the torque issues, I’d expect that it adds more points of failure. When I was talking about moving the motors, I was talking about moving them and the teeth of the gears that turn the spools to the inner edge instead of having them on the outside where they can interact with the belt directly and cause issues.
The current design has the router in the way, of course, so it seemed prudent to bring the spools/arms away from the center. I considered having them be the same size as the sled, or at least having an inner radius that sat them outside the linear rod supports (potentially changing the support to make this inner radius able to be smaller), but that just seemed like making more large parts and needing larger molds, more plastic, etc, while also limiting the machine a bit because more belt would have to stay on the spool to protect the glued end from getting pulled out. I also can’t print that large on my 3D printer that is en-route and figured that would be the case for most people, so trying to only have the sled itself be something too big for me to print.
Why not move the motors to the anchor positions and the anchors to the sled (as thin concentric circles around the router) ? I would not mind having a set of cables around my frame. The controller pcb could also be attached to the frame somewhere (far away from the electrical noisy router). You would only need a simple cable to the sled for the stepper motors.
I remember seeing that when it was first posted. Didn’t even cross my mind when I was sketching, but it’s basically spot on.
This definitely at least proves that what I was suggesting with radially-arranged statically-placed spools would work, it would just be a different calculation. Luckily, math is math and makes that possible.
If there wasn’t all of this in the center of the sled, designing and attaching custom tool setups would become trivial (in comparison to how it is now) and I honestly think that this would be well worth a redesign - especially if that redesign was able to re-use most of the parts of the original and just needed new spools and ‘router’ clamps, plus either holes put in the sled or something mounted on it to facilitate the new placement of the spools.
I think the anchors would need to be spaced very precise and really rectangular for the Cubiio setup. But yeah, that could work. Even the math could stay the same I think, just subtract the spool spacing from the anchor spacing. No Calibration though.
Have you seen @md8n 's double sleeve? the outer sleeve stays in the M4, the inner sleeve and spindle can easily be taken out. If you use a 69mm x 2mm wall thickness, you can use every 65mm core you want to swap.
The compact all in one design of the M4 I really like, also my frame is semi outside, the designated Pi of my first Maslow didn’t like that and died.
On the other hand you have got a point, especially since we need a sturdy and stiff frame, it is not very portable, then the electronics could go into the frame.
With the parts you have you could already do that, all you’d need is 69mm anchors, belt ends with a 69mm hole and a lot of cable. I like your idea.
I have. That concept in mind, the change I would most like to make would be to make the router clamp opening wide enough to fit a sleeve twice that thick between the router and the clamp and spools. That way the router is no longer a mounting surface and the originally recommended router can be easily swapped back in just like any other core designed for it.
I just also see the issues with the motors having access to the belts, the arms having limited angles, the different heights of the arms requiring compensating math, people’s confusion around assembly order, issues with the arms being stacked and loose bolts creating linkages, and that I’d have to modify the spools/arms to widen that clamp and have it matter, so I figured it was worth it to go for as much of a solve as possible.
If I’m still way off, please let me know, but if I’m not mistaken, something like this, with the wider core cylinder, the spools free to move and rotate in those curved channels, and the motors mounted above the center of the spool…
still allows the belts to always draw a straight line aligned with the bit
would actually likely increase the angles available before collisions and inaccuracy
allow for both making the default router “hot-swappable” and for using larger routers/cores
(bear in mind these are very generalized, I’m not an engineer and have been using this CAD suite for less than a week)
Because this should essentially just look to the machine (as it currently is) as if it just has 6ish inches of extra belt, wouldn’t this be a reasonable direction to think towards re: iterating and increasing possibilities?
Again, the on-router mounting and the small size of the core, which is currently tied to the inner radius of the spools, really limits the potential of the system. I could even see taking what I did here further and extending that clamp’s inner radius out to just shy of the linear rails and stepper motor screws to enable even larger tools in the core and more airflow if needed.
I also realize that this design would block dust collection as visualized, but again, it’s more about the concept than the measurements in this rough-out.
something like that could work. The angles would depend on the size of the
spools. (thus my thinking above about snail oriented spools)
unfortunantly small diameter spools don’t get you much belt length.
the belts are ~1.6mm thick, so a spool that’s 20mm diameter on the inside and
97mm on the outside is 24 layers and the same 14.5 ft of belt that we get on the
maslow4 with 13 layers (inner diameter ~90mm outer diameter ~130mm
with a ~16" sled (400mm diameter), and a 100m spool, the closest we get is a
triangle 50mm x 200mm which is ~14 degrees (28 degrees on adjacent belts).
opposite belts can get to ~118 degrees if the tracks stop when the adjacent
belts would hit (if you do the slots as two half circle slots instead of 4
quarter circle slots, you could get MUCH closer, ~50 degrees, close enough to eliminate that as a concern)
I understand the issue about smaller spools and less belt, but I would at least expect that the extra volume given from decreasing the inner radius should let us step down the outer radius slightly. In this example, the circles that I drew to make my spool representations are 100mm in diameter, and that hole in the middle is 10mm in diameter, which is just barely smaller than the housing would need to be to accommodate that 97mm figure you put forward.
I have also been thinking of how best to use the existing spools in a system like this, because I want to try this mod without having to repurpose my motors and encoder/produce spools. I’ll throw together a render of that as well. Would require extensions for the motor cables, likely, but the same idea I had for placing two bearings each on the top and bottom face of the spools so that they keep it in proper alignment should “just work” (though it would require a different offset value for belt length, would also potentially have different green/white/red zones depending on collision. and would likely not be able to get as close to the anchor points because it may stick out even further.
play around with that spiral length calculator I posted above, a 20-100mm spool
is ~15.5 ft and a 10-100 spool is only 16 ft, but a 20-110 spool is almost 19 ft
but spools like this could have the motor directly attached to the center of the
spool
it would definitely need motor extension wires and longer ethernet cables.
with 125/130mm spools, you are at ~20 degrees from flat, which is about the
same as the stock system for the top red area. However, if you leave the rod
support towers in place, the closest you can do is ~25 degrees from flat, whichmakes the top and bottom red zones deeper (you would the frame to be taller than 8’)
This is my CAD model that I use for checking mechanical fitness
you could have something that sits in the center of the existing arm and holds a couple bearings (the orange circles reflect this) and have a slot (shown by the large dotted lines) that the bearings ride in
It could work, and for a PoC it sounds like a good idea, but I think you would
be better off planning to use the motors/encoders, but with new spools instead
of re-using the entire arms (move the motors to the center of the spool and eliminate the gears and all that headache) (100mm spools would give you better-than-stock red zones even with the towers)
if you count on the arms sliding in the track, you don’t need them to swivel, which makes it much easier to adapt/design them
The only real problem would be the vaccum, and depending on how high the ring is, you may be able to get in under it for that
two part ring segments with holes that match the sled (did not include standoffs, don’t know what height above the sled would be correct)
two part adapter that goes in the middle of the arm and has pegs on it for bearings. should just need a bolt or two in the middle of the arm to hold it together.
I just received my 3D printer, so I should be able to fabricate the parts I couldn’t have made out of wood to test all of this, I just might not be up to modeling them until I spend more time in CAD. I should be able to have that and the Maslow tag-team making me a test-sled that I can transfer the main unit over to. Was thinking of laminating/ screwing an old cutting board to some plywood and having a pattern cut into it to cut down weight.
I’m sure I wouldn’t be able to implement this without making the machine aware of the new offset for how far from center the belt measurement point is at. That’s, I think, the only obstacle I’d have to giving this mod a go (not knowing where in the code that is handled). I should be able to at least do the hardware side of things in the next week.
I need to dig into the code, I am not sure if there is already a configurable
parameter, or if it’s a hard-coded variable (when I dig into this, I intend to
make it so that there is a configurable per-belt extension as well)
@bar@ronlawrence3 I am not setup to be able to compile/test this PR, but it seems like a pretty straightforward change to allow for setting belt offsets (including now different offsets for each belt) via the .yaml file instead of requiring code changes.
What I don’t get in all this discussion is the assumption that the spools need to rotate to align with the anchors. In the original Maslow there were only two motors and hence two measurements to get us two unknowns, x and y. There, it was critical that the chains point at the center of the sled because otherwise you needed a third variable which you couldn’t measure.
On the Maslow 4 you have 8 measurements at your disposal (4 encoders, 4 motor currents) if you had fixed arms, you basically would have three unknowns, x, y, and rotation angle. The math to calculate those is a little hairier, but not a lot hairier.
I am only not considering that path because it would require more software changes than just telling the unit the belts “start” further from center and because it kept getting shot down. It would make sense to me, based on how other things I’ve seen with cables mounted to corners, for both 2d and 3d, manage to keep things oriented properly. Just seems like different math, but still just math, and likely already solved math that could be found and adapted.
This page has a great visualization and breakdown of the current math, though it’s assuming a design where all the belts are at the same z offset on the sled, so it’s a bit cleaner.
I’m not able to quickly find an example of the other, but will look more today.