Maslow 5 next generation ideas

No Judgement
1

So taking it all apart again because I have been watching one of the motors dance around. I suspect that the bearing on the opposite side is either missing or bumped out. I really like the general design of the maslow and how few parts it really has. I have been enjoying seeing what IanB is playing with with moving the motors and spools out from the center Modified version of Maslow 4.0 using redundant parts ? and with randomdave moving the motors to the other ends of the belts. Spider Maslow, Spider Maslow, does whatever a Spider Maslow does - #21 by RandomDave

But I wonder what small tweaks we could make to the basic design just to clean it up a bit. My THree frustrations are

  1. the limit to the size of the center hole where everything slides on the router. It means we can’t take the router in and out easily and that we can’t swap tools or spindles without a lot of work.

  2. that the vertical pillars are just a little too close together to pull the arms straight out.

  3. that the arms move up and down with the z axis.

The maslow4 is wonderfully compact and has only a few parts.
What if we just opened up the whole center section where the router currently fills. designed a central cylinder core much wider that would lock easily to the sled at the bottom (like a large pipe screwed to the sled. It could act as both the vertical tower and the cylinder for the arms to rotate around. Keep the arm design but make them larger to fit around that core (yay longer belts) . and then the central pipe could be open for z motors to attach to the top to lift swapable tools up and down. It would separate the z movement from the arms. It would give a large payload area in the middle. it would move the z motors to the top. arms and router could be all be swapped or lifted easily off the top. Basically keep the maslow design mostly the same but open everything up around a larger central pipe.

Drawbacks: The arms would still be at different heights. The router bit would still be hidden deep in the center.

PXL_20260819_231418484
PXL_20260819_2314184841920×1442 492 KB

1 Like
2

I love that idea! I couldn’t agree more that the router/z axis combo is a big weak point in the current design, and rethinking that is the place to start.

3

Maslow 4.1’s base hardware design imposes some necessary constraints, and the challenge isn’t just a firmware issue. We were initially treating the mechanics, kinematics, and control system almost as if they were interchangeable, but they’re really three different layers that have to agree with each other.

What our testing has shown is that the motor controller can track commanded belt lengths very accurately. That shifts the bigger question toward whether the kinematic model matches the actual mechanical belt routing and geometry. If those two agree, then the mechanical design can become much more flexible.

That’s really where this project has evolved: not simply trying to make the mechanism “simpler,” but understanding which parts of the Maslow 4.1 architecture are necessary, which parts can be changed, and making sure the firmware math, belt geometry, and physical machine all describe the same system.

M4.1 hardware does set some necessary boundaries, but the real lesson we’ve learned is that mechanics, kinematics, and control aren’t really interchangeable. So far, the belt servos and encoders track belt lengths very precisely. The bigger challenge is making sure the kinematic model matches the true belt routing and effective exit points. That’s where the project is evolving. Not in forcing simplification, but in making each layer agree with the others. It’s not that simplification is wrong, it’s that without that alignment, simpler doesn’t necessarily mean more accurate.

Base | MR2QUIK

3 Likes
4

So in my understanding the math in the software is cool because the assumptions that it makes are ones that give us a lot of flexibility in the mechanical design.

I haven’t played directly with the software and i am not a practically good programmer so this is me checking that my understanding of the math is correct. I am enjoying playing with the mechanical design and trying to stay within the constraints and assumptions of the software.

Are these assumptions correct? I am not including anything about finding anchors but just for basic running.

  1. it assumes all belts point directly at the cutting blade. Useful because we don’t have to worry about the maslow rotating. This simplifies the position calculations in the xy direction to drawing four triangles from the center of the cutting blade to the four corners of the frame.

  2. There is a standard adjustment built in making the measured belt length the hypotenuse of a triangle with the correct blade center to anchor length being one leg and the difference in height between the anchor and the arm on the maslow as the other leg. I don’t know if this uses the arm length to offset the triangle as well?

  3. it measures the belt lengths by counting the rotation of the idle gears (quarter or half rotations? )
    This is why it has to start from fully retracted when it gets confused. It has to pull them all in to where the anchor ends are pressed directly to the motor arms and then start counting from there.

  4. It pulls each belt tight by measuring the resistance on the motor. I guess we are adding a factor for belt length and resistance to calculate belt stretch? EDIT electric current through the motor*

  5. we adjust for the physical design by adding in a set length for the anchor ends and the motor arms and belt extensions (if used) to the measured belt lengths. If we adjust the heights of the arms relative to the anchor bolts that changes the hypotenuse calculation above.

  6. zaxis is entirely relative to what you tell it each time. You run the z axis all the way down and then you tell the machine that this is zstop. It is good to run find anchors there. Then when ready to cut you raise the z axis until the blade is touching the cutting surface and call that z home. The machine then moves the z axis blindly based on the gcode from there with no feedback.

****Quesiton, does the machine use the z height to refine belt lengths as it moves? I had assumed not, just that they all got a little tighter?

  1. currently the limit to the calculation space for the maximum frame is 5000 by 5000 mm? I would like to expand that a little. EDIT now it is 5500 by 5500

So as long as my physical design takes these assumptions into account it will generally work? I can play with where the motor, spool and belt is as long as it ends up pointing at the center of the blade and is free to rotate around that both on the maslow end and on the anchor end? I can play with the heights of the arms as long as I end up telling the machine the difference in height between the place it touches the machine and the anchor bolt? I could make bigger spools with more belt? I could separate the spools from the router? I could make a tiny one? It feels like those mathematical constraints give a lot of design freedom?

I would need to make deeper updates to the software if I:

  • swapped out the z motors and screws for something with a different pitch.
  • changed the size of the idle gear. or the tooth count of the belt (would also need a new idle gear)
  • changed the drive motors
  • didn’t let the motor arms rotate freely around the center

Do these seem like the right constraints?

Am I missing something important?

5

@wouldchuck

Our perspective, I’d correct it point by point like this:

  1. “All belts point directly at the cutting blade.”
    Not quite. The useful abstraction is the router/tool center, but the real machine has belt exit points offset from that center. The firmware has to account for that geometry somehow. Treating all four belts as if they literally terminate at the cutter center is too simple, especially once you change the sled mechanics.
  2. “There’s a standard triangle adjustment for height difference and arm length.”
    Partly right, but this is where terminology gets muddy. armLength is not simply “the other leg of a triangle.” It’s part of the effective belt-path geometry. Our own tests showed that changing armLength over a large range did not proportionally change the XY scale, so it clearly isn’t acting like a simple global correction factor. I would avoid describing it as a basic hypotenuse correction unless someone confirms the exact implementation from code.
  3. “Belt length is measured by counting idle-gear rotation, and it must fully retract to establish zero.”
    The first half is essentially right: belt travel is derived from encoder rotation and the configured tooth geometry. But full retraction is a reference-establishing routine, not an absolute measurement of the belt’s physical free-end position. The distinction matters. Once the anchor end reaches the encoder/exit area, the encoder may stop seeing belt travel while the motor can still continue winding until the retract-current threshold is reached. That’s exactly the behavior we’re now trying to change.

Also, newer firmware can preserve belt-position state through some transitions, so “it always has to fully retract whenever it gets confused” is too broad. v1.17 specifically added saving belt positions in the Extended Out state.

  1. “It tensions belts by measuring motor resistance, and maybe belt stretch is calculated from that.”
    The first part is broadly correct for certain belt-state operations: motor current is used as a proxy for tension/contact during retraction and tensioning. But that should not be confused with normal XY servo positioning. Our diagnostic logs show that during jogging the motors are following explicit belt-position targets using encoder feedback extremely closely.

Belt stretch compensation is a separate issue. Recent firmware has added belt-stiffness/load-related configuration hooks, but on the diagnostic source build we used those particular YAML keys were ignored because that source revision didn’t support them. So I wouldn’t state that current draw is directly being converted into stretch during ordinary motion unless @bar confirms that exact implementation.

  1. “Physical design is handled by adding fixed lengths for anchors, arms, and belt extensions.”
    Only partially. Fixed offsets can account for some constant path length, but they do not automatically describe arbitrary belt-exit geometry.

That’s probably the most important lesson from our modified sled work. If you move the belt exit/encoder point, make it fixed instead of pivoting, change its radius from router center, or create a different wrap path, you may have changed the geometry itself—not merely added 40 mm of belt.

That’s why mechanics and kinematics have to describe the same machine.

  1. Z axis.
    Calling Z “entirely blind” is too strong.

The Z system is a normal motorized axis with its own machine/work-coordinate handling. The newer firmware has explicit Z-home handling, safety limits, parking behavior, and persisted offsets. For example, v1.18 changed Z-stop handling to establish a work-coordinate offset, and v1.21 added further Z-position safety behavior.

But the question about whether live Z position modifies XY belt lengths is a good one. I would not claim that it does without checking the exact kinematics code. The fact that Find Anchors asks for Z to be fully lowered strongly suggests Z geometry matters to establishing the anchor model, but that is different from continuously recomputing belt lengths from Z during every XY move. v1.21 explicitly warns that Find Anchors should be run with Z fully lowered.

So I’d mark that one: needs code confirmation.

  1. “Maximum frame is 5000 × 5000 mm.”
    That’s outdated. Firmware v1.20 increased the maximum supported frame dimension from 5000 mm to 5500 mm, including kinematics validation, calibration solver, and WebUI support.

The Maslow math does give mechanical flexibility, but not unlimited mechanical freedom. The firmware assumes a particular relationship between anchor locations, belt measurement, belt exit geometry, and router center. You can redesign the hardware extensively as long as the physical machine still satisfies the geometry the firmware thinks it is controlling—or you update the kinematic model to match the new mechanics.

Our recent testing has shown that the belt servos themselves can hit their commanded belt positions very accurately. The harder problem is making sure the commanded belt positions correspond to the physical XY location you actually want.

Base | MR2QUIK

6

I don’t understand what is meant by belt exit geometry in this case. When I am looking at the motor arms the belt when tightened seems to line up with the central axis of the machine. Is there code or assumptions there that make that more complicated? what are they?

Thank you for your answer. I would like to hear from other people who have been working on the software as well. I do not understand all of the technical words and would like to have a better simple understanding of what the mathematical constraints are?

7

What I mean by belt exit geometry is just this: the firmware needs to know where each belt effectively leaves the sled relative to the router center.
On the stock Maslow arms, the belt does appear to line up toward the center, and that is part of why the math can be simplified. But the belt does not literally start at the router bit. It leaves from an arm or roller some distance away from center, and the firmware has to account for that distance and the way that exit point moves or pivots.

So the simple version is:

  • the firmware knows the frame anchor locations,
  • it knows where the router center is supposed to be,
  • and it calculates how long each belt should be to place that center at a given X/Y position.

That works as long as the real mechanical belt path matches the geometry the firmware assumes.
Where it gets more complicated is if you move the belt exit farther from center, make it fixed instead of pivoting, change the wrap path, or otherwise make the effective exit point behave differently. Then the physical belt length can be different from what the math expects even though the encoder itself is measuring very accurately.
In our testing, that distinction became important because the belt motors were hitting their commanded lengths very closely, but the router-center movement was still scaled incorrectly. So the question became less about whether the motors were doing what they were told and more about whether the geometry they were being told to follow matched the actual sled.
For a simple mental model, I would think of the Maslow math as four triangles from the frame anchors toward the sled, but with an important correction: the belts terminate at known belt-exit points around the sled, not magically at the cutter center.
That’s the “belt exit geometry” I’m referring to.
And yes, I’d also encourage others who know the current firmware math better than I do to correct or simplify that description further.

Charlie | MR2QUIK

8

Ok, thank you. That matches my understanding. I have only considered designs that point the belts at the center of the machine consistently. If I were to do something else like make them fixed then I would need to do a lot of extra math and change the program. I am not in a place where that is reasonable for me. I was impressed that you got the square fixed angle maslow to work so well. that was pretty cool. As a hobbyist I am wanting to mod the machine in ways that are consistent with my abilities and understanding of it.

why would moving the exit farther from the center change things as long as you changed the arm length in the config file? once the belt is past the encoder does it matter how it is wrapped? I had considered having a drive gear and then just a pile of belt in a flat box like the old endless cassette tapes. As long as the drive gear is similar in mechanical advantage to the current spool set up and that the encoder gears still line up with the center of the machine as the belt exits would that change much?

9

Just as a quick comment on this - although I quickly jumped to the messing around with the spider Maslow stuff, prior to that I was using the 2040 gantry stiffening arch + turtle clamps + relocated control board - so keeping the same basic design with some stiffening.

Those together meant I just had to loosen the turtle clamps, and as long as the 2040 was 350mm for the legs, the router slides in and out with minimal fuss - it took me like 60 seconds to swap the router itself (plus whatever time for bit change if that’s what I was doing).

Edit: though it does mean having to slack the belts which it would be better not to have to.

1 Like
10

@wouldchuck I would say that your understanding is pretty much spot on

1 Like
11

I might have a few more comments on the wider stuff, but I think a couple of easy wins (potentially, depending on board stuff) are:

  • Z limit switches (1-4, possibly just all ORd together to one input).
  • Simple touch-plate / touch-probe in the box.

Would simplify setup and likely remove a good chunk of user-error support requests.

2 Likes
12

This post will answer your question

2 Likes
13

Yep, yep, the comment about the board supporting it was more about the limit switch(es), but I think it’s worthwhile including a simple touch probe setup with the next generation too.

1 Like
14

Big spools might have too much friction.