CoreXY / CoreXZ Kinematics

[Charles Steinkuehler]

I've got my CoreXZ machine built for MRRF, and am working on getting it
printing which means I need kinematics. While the kinematics equations
are trivially simple, the interaction between axis makes this style
machine an excellent example of why the Joints-Axis branch is a minimum
requirement for sanity (and there need to be a *LOT* of other
improvements, like support for coordinated homing).

Anyway, someone suggested implementing the kinematics directly in HAL
and letting the motion planner pretend it's running in Cartesian mode
with trivialkins. This seems like the overall least painful way for me
to get printing in short order, so:

Has anyone implemented a HAL comp for CoreXY or CoreXZ style printers
and want to share the code? I'm hoping someone can save me an hour or
so of writing and debugging. :)

--
Charles Steinkuehler
cha...@steinkuehler.net

[Viesturs Lācis]

On Thursday, March 12, 2015 at 5:36:23 PM UTC+2, Charles Steinkuehler wrote: 

Has anyone implemented a HAL comp for CoreXY or CoreXZ style printers
and want to share the code?  I'm hoping someone can save me an hour or
so of writing and debugging.  :) 

I also remember such a post somewhere, but cannot find it at the moment. Meanwhile, you can try corexy kinematics, here is my theory on how to set up homing:

I _think_ that I have come up with a workaround:

1) arrange home switches so that one is tripped, when carriage reaches the desired end and the other is tripped, when gantry reaches its desired end;

2) in INI file set home_search and home_latch velocities to be the same value, but one positive, the other negative for both motors, depends on config.

3) after starting homing:

a) both motors turn the same direction (both are doing home_search) - carriage reaches its desired position and trips home switch; 

b) one motor starts home_latch, the other continues home_search, motors turn in opposite directions, the gantry is now moving towards its home switch;

c) when gantry trips the second homeswitch, both motors will do home_latch, so carriage starts moving off its switch,

d) first motor stops and is homed as soon as first homeswitch is untripped

e) only second motor is still moving, causing the gantry to back off its switch

f) second motor is homed as soon as second switch turns off.

There is one little drawback: in point E, where second motor is moving the gantry off the switch, it moves the carriage by the same amount.

The trick to repeatable home position is not to change home_search and home_latch velocities (it changes the distance, required to stop the movement) and have good, precise switches with good repeatability (the lower the velocity, the lower is the distance variation due to error of switch) 

Home_search velocity can have opposite signs for each motor (and home_latch as well), which would cause gantry to hit its switch at first and only then the carriage, but it does not change the principle as whole.  

[Charles Steinkuehler]

On 3/12/2015 11:36 AM, Viesturs Lācis wrote:
>
> On Thursday, March 12, 2015 at 5:36:23 PM UTC+2, Charles Steinkuehler
> wrote:
>>
>> Has anyone implemented a HAL comp for CoreXY or CoreXZ style printers
>> and want to share the code? I'm hoping someone can save me an hour or
>> so of writing and debugging. :)
>
> I also remember such a post somewhere, but cannot find it at the moment.
> Meanwhile, you can try corexy kinematics, here is my theory on how to set
> up homing:

This is all complicated by the fact that for this machine there's a 3:1
reduction on one of the axis (Z) compared to the other (X). And I'm not
actually installing home switches (yet), but it would be nice to be able
to manually home via coordinated jogging.

I'm going to go ahead and write the kins as a HAL module, and just cast
a vote for the ability to do coordinated moves in joint and/or world
space as part of the new motion planner. I'm looking forward to being
able to craft some Python code that can do homing, probing, and
calibration by directly talking to the motion controller.

The existing homing logic makes *WAY* too many assumptions about how the
machine works to be generally useful for non-trivialkins.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Viesturs Lācis]

On Thursday, March 12, 2015 at 7:25:29 PM UTC+2, Charles Steinkuehler wrote:

This is all complicated by the fact that for this machine there's a 3:1
reduction on one of the axis (Z) compared to the other (X).  And I'm not
actually installing home switches (yet), but it would be nice to be able
to manually home via coordinated jogging.

Well, set home_search_vel and home_latch_vel to 0 and it will home just where it is. Then simply jog the machine to its home position and do G92 X0 Y0 (either via directly doing MDI or vcp button, that executes particular MDI command; G10 L20 P... X... Y... also might be an option instead of G92).

Today in cnc-club.ru I found a thread about LinuxCNC and corexy machine and one guy is homing both corexy joints, where they are and then he is running a g-code file, that is doing probing and then setting coordinate G92 coordinate offset. He also posted the contents of his file:

G38.4 Y1000 F5000

G38.2 Y-1000 F150

G92 Y5

G0 Y0

G92 y60

G38.4 X-1000 F5000

G38.2 X1000 F150

G92 X-64.5

G0 X0Y0

M30

 

Unfortunately this approach requires some probe switches, which does not seem like an option for you.

[Ryan Carlyle]

The non-square shape of step space "pixels" for CoreXZ (and my CoreXYZ build) makes homing hacks hard. You really want a control scheme that separates actuator position from joint position. Then you home using motion commands in joint space, because joint position is usually what triggers the limit switch, and let the joint/actuator sub-kinematics do the necessary coordination work. 

Merely separating joint position from axis position isn't really sufficient (if I properly understand the way you MK guys use those terms). Kinematics really ought to have two discrete coordinate transform steps between three coordinate spaces:

1. Part space cartesian coordinates attached to the build table origin, in absolute linear distance units
2. Joint / machine axis coordinates attached to the joint endstops, in some meaningful absolute joint travel units (eg mm or degrees)
3. Actuator position coordinates, in terms of relative steps or other actuator-specific unit

Most simple kinematics schemes combine the 1-2 conversion and the 2-3 conversion into one transform. That's fine for relatively simple machine architectures, but it breaks down when you get into more complex machines (like using redundantly-actuated joints) or if you want to apply separate dynamics limits at different levels in the machine architecture (like separate limits for feedrate, joint velocity, and actuator force).

[Ryan Press]

I did not need to write a custom HAL component.

https://groups.google.com/d/msg/machinekit/8Pia4JgK73c/xLy69dRlkGgJ

Ryan

--
Charles Steinkuehler
cha...@steinkuehler.net

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups "Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com.
Visit this group at http://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Charles Steinkuehler]

Thanks Ryan! I knew I'd seen that somewhere!

I went ahead and wrote a component since I have to scale one of the axis
for the CoreXZ machine (Z has 3x the resolution of the X axis), but I
could also have just thrown some multipliers into the HAL chain.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Ryan Press]

The sum2 component has the gain0 and gain1 parameters which could scale the output/feedback without adding an additional component.

I *am* seeing transient large position errors while doing rapids (which doesn't matter much with an open loop system) but I'm not so sure it's the CoreXY calculations in HAL that's causing it.

Ryan