Does this form of kinematics have a name?

I’ve been pondering a hybrid of cartesian and corexy/hbot kinematics design. It would be terrible for a 3D printer because it is asymmetric, but could possibly make sense for a laser, which is already asymmetric in that moves are dominated by X when engraving. Schematically, with Y in red and X in blue:


This would let you move the X motor off the X gantry, lightening the gantry and reducing inertial load for Y moves, and would allow keeping all of the motors outside the firing zone. It would be controlled like cartesian kinematics, except that every movement in Y would be composed inverted on top of any other X movement.

Does anyone know a name for this? I don’t see anything like this in Marlin, Smoothieware, RepRapFirmware, or Klipper.

It probably isn’t worth implementing, because gantry inertia should only matter for fast moves, and a laser doesn’t normally do fast moves in Y, but since I started thinking about it I became curious whether there was a name for it.

This kind of design would limit your rastering in only one axis. If you had an item that she needed to be rotated but couldn’t due to your size limitations then you would be in trouble. There are the rare occasions that you would want to also raster on a 45 degree angle.

No, it wouldn’t have that limit, any more than corexy would. The motors can turn simultaneously. It’s just that if you were rastering in Y, the X motor would have to move synchronously, in equal steps and opposite direction with the Y motor. To raster on the 45⁰ / diagonal, the X motor would not move (except to change between raster lines); to raster on the 45⁰ \ diagonal, the X motor would move twice as fast and in the opposite direction as the Y motor (except to change between raster lines).

It’s half like HBot/coreXY in which to move in X or Y both the A and B motors have to move, and to move on a 45⁰ diagonal only A or B moves. So the Y axis is cartesian, and the X axis is HBot-like.

In fact, this would be better for Y rastering or diagonal rastering than cartesian, because it would remove the motor mass from the X gantry. I don’t think that the motor mass is meaningful when it comes to cutting, but it might be for rastering; that’s actually the only good argument I can think of in favor of adding this.

Like I say, I can’t imagine that I’m the first person to come up with this mechanism, I just don’t know what it’s called. :slight_smile:


dc42 on the forum had the answer: MarkForged kinematics, and it is supported by RepRapFirmware.,876689,876704,504042

It is not currently supported in Marlin:

I don’t see that it’s supported in Smoothieware or Klipper either.


Nice detective work! Does not look like there is a lot of info out there but that makes it much more interesting! :grinning:

1 Like

dc42 did the hard work, I just had to ask. :slight_smile:

It is generally not the best choice for a 3D printer because you would have to tune the two axes differently. I like the way they supported it in RepRapFirmware — you can just fill in a matrix that maps axis movements to motor changes, as long as it is linear.

Hi, I’m not sure if this helps but the Grbl controller firmware can support Core XY Hbots. The conversion in code is very simple in fact and can be selected via just compiling via a define statement.

Also this H-bot design was used in plotters and time lapse recorders (e.g. earthquake graphs). Mostly they used like nylon rope instead of toothed belts.

Cheers, Paul

Thanks @Paul_de_Groot! This isn’t HBot though. I haven’t checked, but does grbl support MarkForged kinematics? I know about corexy; I built my own corexy printer from my own design. But MarkForged was new to me.

… I don’t see MarkForged in grbl, grbl-lpc, or grblHAL. I could be missing something of course!

Thanks, I have mistaken it for a corexy. However it seems to be very similar almost half a corexy (X axis only) so I would expect it fairly simple to rework the existing corexy code to make it work (hybrid of X corexy code and normal Y axis code). Cheers!

I already pointed out the algorithm when I said it was kind of half an hbot/corexy. I like the RepRapFirmware implementation particularly because it’s general; you don’t have to keep writing new code for new linear combinations, you just apply a matrix, and their linear kinematics are just presets for the matrix. :slight_smile:

My current design is cartesian; if I decide to move to MarkForged I’ll have to either use a firmware that supports it or implement it. Probabliy I’ll just leave it cartesian. :slight_smile: