CoreXY translation for TrivKins

When I developed the Hypercube Evolution 3D printer I chose the CoreXY motion system for its simplicity and for its low moving mass.

Originally the printer was controlled by a standard Marlin software that supports CoreXY and has no issues to Home this type of motion system.

Prior to LinuxCNC 2.8 homing in LinuxCNC was an *AXIS* based process. This also meant that when using CoreXY kinematics, homing also worked as expected. However, since homing has now moved to a *JOINT* based process, homing of a CoreXY system is not as easy to implement or reliable in my experience.

I can understand the move to *JOINT* based homing. Typically, most motion systems have MOTOR == JOINT with a homing switch / index directly related to the motor position.

However, CoreXY systems typically use homing / limit switches located on the Axes of the machine. This makes homing more difficult; we move one Joint (Motor) and get motion in both X and Y when we are trying to make a switch on X or Y.

Solution

My solution is to treat the machine as a TrivKins kinematics machine but to wrap the kinematics motion component with a CoreXY translation for X and Y (Joint 0 and 1) to Motors 0 and 1. It works nicely and keeps the homing logic as we would normally expect.


I have added the component source and instructions to my GitHub repository github.com/scottalford75/LinuxCNC-3D-Pri...g/tree/master/corexy

Very good work. There was a recent discussion about corexy here
forum.linuxcnc.org/49-basic-configuratio...orexy-system?start=0

I hope support for corexy is taken up by the dev team from this work

Rod,

Thanks for the positive feedback. Hopefully others find this useful.

BR

Scott

why are the axis joint commands downgraded to servo tread at the comp

this gives lots of space till it triggers

is the only reason the limit switch cordination

for most there is no need to sync the homing as every joint can home on its time
3D printer home x first then y and then z as it is downwards

pl7i92 wrote: why are the axis joint commands downgraded to servo tread at the comp

this gives lots of space till it triggers

This is not correct. Linuxcnc only looks at whats going one on the servo thread which usually fires every millisecond. So if the state of a switch changes state say every microsecond (eg 1000 times per servo thread cycle, it is immaterial as its only going to be seen by Linuxcnc when the servo thread fires.

Whilst parallel port systems run a faster base thread, it is only used to generate steps and is typically not used for anything else.

The real issue is that coreXY was not considered when the joint axis homing was introduced in 2.8. Apparently the joint axis homing was a result of several years of incremental improvements. Its not perfect but its what we have and it did not support corexy so now there are components that do.

my english seams not to be that good to folow the corexy discusion to understand the meaning of the comp
sorry
and Thanks for the info to rod

Hello, we have here a technical type wall printer. A Core XY kinematic is usede to move the print head in X and Y.

Here is the setup:

- Mesa 7i76 to 6i25
- Linux Mint 19.3 with LinuxCNC 2.8.1
- Motor 1 CoreXY at Stepgen 0
- Motor 2 CoreXY to Stepgen 1
- Motor Z to Stepgen 2

I would like to use the component presented here, but fail at the integration. I installed the component with Hal-compile and included it in the HAL created with PNCCONF. Lines, which I changed in the Hal are marked with "# COREXY".
Currently LinuxCNC does not start because I still have errors in the PIN assignment:

The original one

I changed to

I would be grateful for a hint. Attached you can find the INI and the whole HAL.

Thanks in advance

Jan

Currently LinuxCNC does not start because I still have errors in the PIN assignment:

What is the error?

Hello,
here ist the debug Information:

Note: Using POSIX realtime
./crawler_rev00.hal:81: Pin 'spiPRU.joint.0.pos-cmd' does not exist
5508
Stopping realtime threads
Unloading hal components
RTAPI_PCI: Unmapped 65536 bytes at 0x7ff1e6f5f000
Note: Using POSIX realtime

Attached the whole report.

Best wishes

Jan

Unless you are running a BeagleBone and have loaded the
spiPRU driver, no spiPRU pins will be present.