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.
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.
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.
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.
This kinematics has the same problem like hbot (in contrast to core-xy). The x gantry gets unwanted shearing forces, because it’s only realy powerd on the left side. A move of the right motor toghether with the inertia of the x -axis will twist the x-gantry. Same for a move of the right motor. It depends on the angle stiffness of the rails and carriages if this matters.
I’m actually using a torsion rod so that Y movement is driven from both ends, though by a single motor, so the racking forces are countered. The schematic was just to reduce it to the simplest form to find the answer, and in fact is nearly identical to the schematic I saw posted elsewhere once I got the word “MarkForged” to describe it.
Also, I’m using linear rail and will be designing my own mount because the one that came with my laser head doesn’t match the rail. Therefore, I have the opportunity to design the mount to further reduce racking forces from head inertia by making the connection be closer to the center of mass.
When it comes to inertia, one of the goals would be to take the X motor inertia off the X gantry so that the Y motor has minimum inertia.
In any case, I realized something last night as I was drifting off to sleep: I want the X motor on the left side, so that it shares “wasted space” with the mirror assembly. This means two things:
I think that the form added to Marlin is actually what I want after all, with the X motor on the left side.
I want to reduce the width of the bed to not put it under the mirrors or the motor, so the added depth of the servo motor vs a stepper won’t cause problems after all.
Therefore:
I don’t have to start with MarkForged kinematics
If I later want to change, I’ll have room to change; I can move the X motor back out of the laser box later without doing damage to the design.
I then realized that when I came up with gantry plates for my Z lift I was over-thinking it. I can just mount wheels with spacers directly into M5-tapped ends of extrusion, letting me move the transverse bed supports wherever I want between those ends. This simplifies the design meaningfully, I think.
