Gantry gemometry not supported?

FrodeBNilsen

Seems like I am running into a brick wall with this one.

Someone pointed out to me, that the core-xy mechanism ensured geometric stability during movement, and that was specifically why he used core-xy for his giant printer.

I figured out that if I stuck with that, I could use core-YZ for two sides and core-XZ for two sides. Ultimaker has proven that rods can be used to position the printhead. So if the wagon of the Y-Z is connected on both sides by a rod, it can move the printhead just like Ultimaker has done. This can then be done for both X and Y axis. And since we use "core-XZ" and "core-YZ" we also have the movement in the Z direction.

This means that I need to dial in four motors. Each of the "core-XZ" and "core-YZ" has two motors. That not only gives me motor A and B, but also motor C and D.

As in a "second Z".

This geometry has 4 motors, not just 3. How do I dial that in the firmware.

If we got this to run, particularly by carbon fiber rods and plastic bushings, the reduction in moving mass is insane. Also, the reduction in moving electronics is crazy. Only the E stepper will be placed above the printbed. The printbed will be fixed.

The inherent stability of the core-XY gantry will greatly reduce the need for funky mechanisms for keeping things leveled. Also, every side can be made exactly the same. There is a repetitive use of a few modular components. If this actually worked, it would be a printer designers dream. The number of parts would be reduced like nuts.

If it works, it will improve speed dramatically. In the current core-XY, the Z axis is heavy. Also, the Y axis tend to be heavy. In my design, there is 8 steppers doing the Z-lifting. There is 4 steppers doing the X axis. There is 4 steppers doing the Y axis. The moving mass for the X-axis and the Y axis can be exactly the same.

If this can be done in current firmware, please let me know. I actually think I can get this to work.

Just for reference, I am not talking about a second printhead. That is what core-xyuv is for. I am not moving in any U or V direction for a second toolhead. As in not. I just need to define what movement in x,y, or z means, for 4 motors.

Not Sure what to call it, but a core XZ-YZ? Pretty catchy.

gloomyandy

@FrodeBNilsen I'm struggling to understand what this setup looks like. Did you post a diagram of it?

oliof

@FrodeBNilsen this sounds somewhat similar to the MIR kinematics for which I did RRF kinematics a while back.

The short answer is that you can use the M669 kinematics definition like this

M669 Xa:b:c:d Ya:b:c:d Za:b:c:d

where you basically denote for each motor how it does contribute to the motion in X, Y, and Z.

For MIR kinematics above, my solution was

M669 K0 X-1:0:1:0 Y0:-1:0:1 Z1:1:1:1

lets dissect this. I have four motors driving for sides of the kinrmatics (diagram shows printer from above):

           c
         ,---.
      d  |   |  b
         `---'
           a

Since its the easiest case, lets start with Z. In the MIR kinematics, each motor contributes to Z equally, so each motor gets a factor of 1.

For X, a and c contribute equally, but c runs reverse to a. b and d do nothing for X motion. So we get a negative factor for a, a positive factor for c, and nothing for b or d.

For Y, b and d contribute equally, but d runs reverse to b. So we get the same solution as for X, only shifted to b and d motors.

I hope this somewhat extensive write-up helps you sort out what you need to do for your machine.

You may or may not need to use K1 for your M669; the Hybrid Markforged example in the M669 docs may be closer to your needs.

oliof

Follow-up question for @dc42 -- with a fully defined matrix like above, is the K parameter still needed? If yes, what's its significance?

FrodeBNilsen

@gloomyandy Sorry, have no sketch yet. But I am working on designing the printer i Fusion360, so hopefully I will post about it with a video in January.

As for what it is, imagine running the X and Z axis as you would run the X and Y axis for a core-XY.

The printbed is stationary. You move the Z by lifting a plane with crossing gantry. So the X and Y both lift the the Z and moves X. This is mirrored on both side of the bed. This gives you motion in the X and Y motion. These two planes are connected by one of the crossing gantries.

If you have seen the Voron 2.4, the bed is fixed, and the core-xy, or the XY plane is lifted linearly. It is the same consept for lifting Z, as in that the XY plane is lifted, and the bed is stationary.

In a core-xy, either the bed or the xy-plane is "lifted". The Z is altered linearly.

But if you for every side of the printer, as in for both X-Z and Y-Z plane, have a core-XY like gantry for them planes, and uses crossing gantries instead of belts to actually move the gantry in the x-y plane, all the motors ends up at the bottom of the printer. Except for the e-stepper.

This also means that I struggle with the math. There is some answers given, which I need to comprehend, but the math is already known, as it exists for the core-XZ and the core-YZ gantries. It is a four vector parameter mesh, in its simple form.

Also, if there is two axis for X and Y in this "xz-yz", this can easily be adopted for a 4 color machine, with a minimum of moving mass. Once the gantry for one side is done, the entire thing is done. The physical gantry on each side of the printer is identical for all sides. But for such a setup, a minimum of 12 stepper channels is needed, 8 for axis and 4 for e-stepping. For a total of 16+4 stepper motors. And all those 16 of them, must adjust for almost any diagonal movement in the xy plane.

Why there seemingly is no setup for combining the core-XZ and the core-YZ, by using crossing gantry seems strange to me. As a design, it is just so much easier to work with. Also, moving mass is seriously low, particularly for Z-axis. I start out using dual axis but using single rods will reap seriously low moving mass, and only the e-stepper will be physically moving, as in not totally stationary, and only move physically if using direct drive extruder.

Now I need to look into the other replies, and as of now, they seem to be beyond my comprehension, so I cannot tell if they actually work for my use case. I will make this, there are some challenges, and finding tight tolerance carbon fiber tubes and this gantry setup, are actually the only two that worries me. I just find it strange that I cannot find anyone who have done this before.

FrodeBNilsen

@oliof First of all: Thanks.

The MIR design uses the H design just split. But it seriously highlights what I am going for. The only info I find about this MIR design is on this forum, Google has nothing on it.

It does have the same issues with the firmware, but from what I can find, people think the code should work? But do anyone know this is the appropriate code. Will this work?

Since the MIR is a half H, it only uses one stepper for each side plane. This actually may give me a way out as it leaves me with a one stepper motor matrix for the x-z plane, and if I use a half H for Y, and the y-z plane, that is only one more motor to define. That leaves me with only 3 steppers, and hopefully something that can be dialed in.

The issue will be imbalance for the Y motor with a half H. Another twist could be to actually use an H style belt routing for the y-z axis, just with one motor. (just faking a stepper with an idler) Banking on the other axis to keep any imbalance in check, if I do not figure out this firmware thing. So I got a plan B and C now.

Also, I will be modeling this for 1m tubes. That should at least give me a print volume of 800x800x800mm. Which can be easily swapped for 2m tubes, resulting in something like 1800x1800x1800mm.

Finding a suitable printbed with a reasonable prized textured PEI is also a nightmare.

The sanely prized ones seem to cap at about 500*500mm, and even those are hard to get by. Please let me know if you know of anything reasonable. Preferably something stable, that is available over time. Makes it easier for others to duplicate the printer.

The whole idea of the xz-yz is that each side is inherently balanced by the gantry. That in it self allows for less rigid gantry, and is the very core of the design, allowing for less moving mass. The design by nature is keeping things straight, allowing for less rigid designs to achieve tight tolerances. This is supposedly the key weakness of the H-design.

Again, thanks for the answer. I will make this, hopefully your code actually works. That would be really great.

oliof

@FrodeBNilsen MIR is documented in the github link I posted in my reply: https://github.com/Apsu/Mir

See this video for a run on my prototype (would need proper re-engineering to work, time I dont seem to find): https://streamable.com/vczvhu

My config from back then is at https://github.com/oliof/printerconfigs/tree/main/minimir

Regarding larger PEI sheets: I got nothing on this, I am more into small printers.