Rotational homing on polar printer

[MassimoVisona]

Hi all, I'm Massimo and I'm writing in the name of WASP, an Italian 3d printer company. I'm part of the WASP construction research team. Our goal is to 3d print affordable and eco-sustainable houses trying to solve the housing problem in the world. We are trying your Klipper firmware in our custom 3d printer for architectural structures. The printers name is Crane WASP and here is how it works (https://www.3dwasp.com/en/3d-printer-house-crane-wasp/). Our printer has polar kinematics, and we were able to get it moving properly following your precedent discussion (https://github.com/KevinOConnor/klipper/issues/578). We are now getting some troubles trying to implement an homing for the rotating axis. We have an induction sensor that probes the rotational position only in the homing phase, and disabled after the probe. We couldn't find a homing procedure for the "steppers" kind axis. Is there a way to add this feature? Can you point us some directions or hints?

Thank you

[klipper-gitissuebot]

Hi @maxvi8,

It did not look like there was a Klipper log file attached to this ticket. The log file has been engineered to answer common questions the Klipper developers have about the software and its environment (software version, hardware type, configuration, event timing, and hundreds of other questions).

Unfortunately, too many people have opened tickets without providing the log. That consumes developer time; time that would be better spent enhancing the software. If this ticket references an event that has occurred while running the software then the Klipper log must be attached to this ticket. Otherwise, this ticket will be automatically closed in a few days.

For information on obtaining the Klipper log file see: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

The log can still be attached to this ticket - just add a comment and attach the log to that comment.

Best regards, ~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[KevinOConnor]

Ah, interesting. The polar kinematics were written with the idea that bed would be rotating and that it was not important where the bed would be at the start of a print.

To use an endstop on the "stepper_bed", one would need to change it to a "rail". (A "rail" in Klipper is just a combination of a stepper and an endstop.)

How does homing of that stepper work? Does it always home in one direction? Can that stepper make an arbitrary number of clockwise (or counter-clockwise) turns, or does the code need to know there are limits on the total movement?

@BKLronin - FYI

-Kevin

[MassimoVisona]

Hi @KevinOConnor , thanks for answering this fast. So would it be enough to change the "stepper" to "rail" in the polay.py kinematic file and to add the endstop pin in the config file?

The homing works always in the same direction, so one should manually check that the arm is on the right "side" before sending the G28. The axis con rotate between 180° and -180° right now, so we generate the gcodes accordingly. Infinite numbers of turns are not allowed because the cables and the material tube would wrap on the printer itself.

Thank you

[MassimoVisona]

Some updates: We tried to change the stepper_bed axis to rail, but we kept getting internal errors on G28 commands. So, after spending some hours trying to troubleshoot the problem, we changed strategy. We had successfully homed the rotating axis using the manual_stepper function. We added a fictitious axis in manual_stepper mode and we mapped some free pins on our board in it. Those pin are then phisically connected to the the inputs of the rotating axis driver. So right now we have two couples of pins (step+dir) on our driver: we use one step+dir to home the axis and then we use the normal stepper_bed step+dir pins for the actual printing movements. It's a dirty workaround but it works and it allows us to print. In the meanwhile we'll try to fix the first and more correct approach.

[BKLronin]

Interesting,

I haven't thought about the application in clay or specific house building robots.

I think for the main line of polar printers this isn't an issue as even if one uses a heated bet with cables attached it would be better to use a slip ring.

The addition of a limited move for the bed could be helpful for similar builds with rotating cranes. My first thought of a polar printer involved a crane mechanic too but I found it to difficult to route the cables safely so I went with rotating beds which is not an option for buildings of course.

Just some thoughts.

[KevinOConnor]

Any further updates on this? Did you need assistance with the endstop detection on the "bed angle" stepper?

-Kevin

[BKLronin]

This would also be great for a polar farmbot. The advantage would be that you don´t have to drag around the supply tubes for water and fertilizers etc.

So a contribution to an endstop version would be nice.

[MassimoVisona]

Hi all, we are actually stuck trying to implement the stepper_bed axis as rail. As I wrote previously, we have found a workaround that involves using an extra manual_stepper for the homing procedure. It would be great to have some assistance for implementing the "bed angle". Thank you.

[KevinOConnor]

FYI, I did take a look at this, but it's a bit more complicated than I originally thought. (A homing move of the bed is not easily represented as a move in cartesian space.) So, this is on my list of things to do, but I don't have a time frame to get to it. I'm glad you have a workaround for now.

-Kevin

[MassimoVisona]

Thanks Kevin! I really apprecciate your work and your help!

[BKLronin]

@KevinOConnor FYI: https://www.dppolar.de/en/3d-printer

They don´t print in the middle as well. I guess for serial printing this is perfecty fine as it is now. Totally different method of printing but polar def has a point.

[KevinOConnor]

FYI, I stumbled on this video recently: https://www.youtube.com/watch?v=Pi0Z8N-739Y

Looks like @robmink has done a bit with Klipper, but I don't think he's running Klipper on that printer.

-Kevin

[RobMink]

This is correct, the polar printers I made are super simple and require very little CPU power. Kippers advanced features would be wasted on them, so I have a fork of Marlin2.0. One of my next builds is to try and make a house printer, so I am very interested in this build! Let me know if I can help!

[KevinOConnor]

Okay, thanks. The atan2() call that is used to calculate the bed stepper angle is very expensive on micro-controllers, so Marlin uses approximations for the step timing. It would be interesting to see if using the more precise step timing in Klipper results in observable quality improvements, even on a simple printer.

Cheers, -Kevin

[BrueggemannFelix]

@MassimoVisona Do you mind sending me your printer.cfg file? I weren't able to get the homing process of my polar cinematics running.

Thanks Felix

[KevinOConnor]

Although this feature would be useful, it doesn't look like anyone is currently working on it. So, I'm marking this as inactive.

[chestwood96]

I am building a printer with a rotating arm (instead of rotating bed) and being able to home r would be very useful.

If I understand correctly, homing happens in cartesian space which makes the R home pretty hard. Is there no ability to home a rail in "stepper space"? It would also be pretty useful for scara.

I did try to turn the stepper into a rail before finding this issue and the behavior makes sense if it was homing in cartesian space.

[KevinOConnor]

It's possible to do, but it is a little tricky - it involves changing the stepper kinematics during the homing operation and then restoring the kinematics after homing completes. I think @bondus reported success with this method in one of his prototypes.

-Kevin

[BKLronin]

We might need a radius dependent speed modulation. Not sure if that was implemented yet. I can remember that it printed faster in the center.

Should be easier to implement? (Helps normal polar too)

[bondus]

For homing it does indeed work to use fake cartesian kinematics and swap them during the homing moves. I use it on a parallel scara printer (work in progress).

It's a bit hacky, but it works. Ideally this should be a part of the rail code, to be able to home stepper linear, regardless of kinematics. Most non-linear kinematics really should home by moving the steppers without kinematics math, the kinematic math can be very very wrong if the cartesian coordinate is unknown.

Some example code to show the general idea. In the kinematics initialization code:

# Create two dummy cartesian kinematics for homing
self.printer = config.get_printer()
ffi_main, ffi_lib = chelper.get_ffi()
self.cartesian_kinematics_L = ffi_main.gc(ffi_lib.cartesian_stepper_alloc('x'), ffi_lib.free)
self.cartesian_kinematics_R = ffi_main.gc(ffi_lib.cartesian_stepper_alloc('y'), ffi_lib.free)

Later in your homing code swap out the kinematics of the rails you want to home lineary:

# swap to dummy kinematics and save old kinematics
kinematics = [self.cartesian_kinematics_L, self.cartesian_kinematics_R]
prev_sks    = [stepper.set_stepper_kinematics(kinematic)
               for stepper, kinematic in zip(steppers, kinematics)]
...
# home
rails = [self.rails[0], self.rails[1]]
homing_state.home_rails(rails, forcepos, homepos)
...
# swap back to original kinematics
for stepper, prev_sk in zip(steppers, prev_sks):
   stepper.set_stepper_kinematics(prev_sk)
...  do kinematic math to figure out what x,y the home position actually is, and set it
toolhead.set_position( [x, y, 0, 0], (0, 1))

[chestwood96]

Interresting, I'll give it a shot tomorrow.

I don't really know python but I might figure it out.

[chestwood96]

It kind of works.

I managed to get it to home R but only in one direction and only once per restart. It makes some horrible noise when I try to home it a second time.

if home_xy:

            # swap to dummy kinematics and save old kinematics
            kinematics = [self.cartesian_kinematics_L, self.cartesian_kinematics_R]
            prev_sks = [stepper.set_stepper_kinematics(kinematic)
                        for stepper, kinematic in zip(self.steppers, kinematics)]            

            # home
            rails = [self.rails[0], self.rails[1]]

            hiArm = rails[0].get_homing_info()
            hiR = rails[1].get_homing_info()

            homing_state.home_rails(rails, [300, 3, None, None], [None, None, None, None]) # TODO less hardcode

            # swap back to original kinematics
            for stepper, prev_sk in zip(self.steppers, prev_sks):
                stepper.set_stepper_kinematics(prev_sk)

            self.toolhead.set_position( [ hiArm.position_endstop * math.cos(hiR.position_endstop), hiArm.position_endstop * math.sin(hiR.position_endstop), 0, 0], (0, 1))

I did try dynamically setting the values in forcepos but that didn't seem to do much good.

[chestwood96]

Took another shot at it and it works much better now. I can home in both directions and the settings from the config are actually used.

I do still have a bug where it sometimes just takes of in the wrong direction and smashes into the back of the end-stop for a couple seconds. No idea why this happens.

Also I found it diverged a bit too much from the polar kinematics so and I don't have the python skills to have both in one so I made a new "rotary_arm" kinematic. @KevinOConnor is that alright or should I try harder to keep both versions in one file?

[eirinnm]

@bondus I am also building a 5-bar parallel scara with Klipper. Do you have more kinematic code you would be willing to share? I realise this is off topic for this issue but I don't know another way to reach out.

[bondus]

@zouden offtopic indeed. I put some klipper code over at https://github.com/bondus/5barscara/tree/master/FiveBarElbowKlipper for a 5-bar driven by the "elbows", it's working but in development. The kinematic math is somewhat similar to the normal "shoulder" driven 5-bar. You can find me on klipper discord.