CoreXY translation for TrivKins
27 Jul 2019 22:42 - 27 Jul 2019 22:43 #140778
by scotta
CoreXY translation for TrivKins was created by scotta
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
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.
addf corexy.pos-fb servo-thread
addf motion-command-handler servo-thread
addf motion-controller servo-thread
addf corexy.pos-cmd servo-threadI have added the component source and instructions to my GitHub repository github.com/scottalford75/LinuxCNC-3D-Pri...g/tree/master/corexy
Last edit: 27 Jul 2019 22:43 by scotta.
The following user(s) said Thank You: tommylight
Please Log in or Create an account to join the conversation.
28 Jul 2019 00:55 #140782
by rodw
Replied by rodw on topic CoreXY translation for TrivKins
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
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
Please Log in or Create an account to join the conversation.
28 Jul 2019 07:17 #140791
by scotta
Replied by scotta on topic CoreXY translation for TrivKins
Rod,
Thanks for the positive feedback. Hopefully others find this useful.
BR
Scott
Thanks for the positive feedback. Hopefully others find this useful.
BR
Scott
The following user(s) said Thank You: rodw
Please Log in or Create an account to join the conversation.
28 Jul 2019 07:57 #140793
by pl7i92
Replied by pl7i92 on topic CoreXY translation for TrivKins
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
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
Please Log in or Create an account to join the conversation.
28 Jul 2019 08:25 - 28 Jul 2019 08:26 #140794
by rodw
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.
Replied by rodw on topic CoreXY translation for TrivKins
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.
Last edit: 28 Jul 2019 08:26 by rodw.
Please Log in or Create an account to join the conversation.
28 Jul 2019 12:54 #140798
by pl7i92
Replied by pl7i92 on topic CoreXY translation for TrivKins
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
sorry
and Thanks for the info to rod
Please Log in or Create an account to join the conversation.
22 Mar 2021 12:48 #203232
by +Jan+
Replied by +Jan+ on topic CoreXY translation for TrivKins
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
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
# An example joint 0 and 1 translation to corexy motor 0 and 1
setp spiPRU.joint.0.scale [JOINT_0]SCALE
setp spiPRU.joint.0.maxaccel [JOINT_0]STEPGEN_MAXACCEL
net xpos-cmd joint.0.motor-pos-cmd => corexy.xpos-cmd
net m0pos-cmd corexy.m0pos-cmd => spiPRU.joint.0.pos-cmd
net m0pos-fb spiPRU.joint.0.pos-fb => corexy.m0pos-fb
net xpos-fb corexy.xpos-fb => joint.0.motor-pos-fb
setp spiPRU.joint.1.scale [JOINT_1]SCALE
setp spiPRU.joint.1.maxaccel [JOINT_1]STEPGEN_MAXACCEL
net ypos-cmd joint.1.motor-pos-cmd => corexy.ypos-cmd
net m1pos-cmd corexy.m1pos-cmd => spiPRU.joint.1.pos-cmd
net m1pos-fb spiPRU.joint.1.pos-fb => corexy.m1pos-fb
net ypos-fb corexy.ypos-fb => joint.1.motor-pos-fbI changed to
# COREXY (Whole Block)
setp hm2_5i25.0.stepgen.00.position-scale [JOINT_0]STEP_SCALE
setp hm2_5i25.0.stepgen.00.maxaccel [JOINT_0]STEPGEN_MAXACCEL
net xpos-cmd joint.0.motor-pos-cmd => corexy.xpos-cmd
net m0pos-cmd corexy.m0pos-cmd => spiPRU.joint.0.pos-cmd
net m0pos-fb spiPRU.joint.0.pos-fb => corexy.m0pos-fb
net xpos-fb corexy.xpos-fb => joint.0.motor-pos-fb
setp hm2_5i25.0.stepgen.01.position-scale [JOINT_1]STEP_SCALE
setp hm2_5i25.0.stepgen.01.maxaccel [JOINT_1]STEPGEN_MAXACCEL
net ypos-cmd joint.1.motor-pos-cmd => corexy.ypos-cmd
net m1pos-cmd corexy.m1pos-cmd => spiPRU.joint.1.pos-cmd
net m1pos-fb spiPRU.joint.1.pos-fb => corexy.m1pos-fb
net ypos-fb corexy.ypos-fb => joint.1.motor-pos-fb
I would be grateful for a hint. Attached you can find the INI and the whole HAL.
Thanks in advance
Jan
Attachments:
Please Log in or Create an account to join the conversation.
22 Mar 2021 13:28 #203240
by Aciera
What is the error?
Replied by Aciera on topic CoreXY translation for TrivKins
Currently LinuxCNC does not start because I still have errors in the PIN assignment:
What is the error?
Please Log in or Create an account to join the conversation.
22 Mar 2021 14:25 - 22 Mar 2021 14:25 #203245
by +Jan+
Replied by +Jan+ on topic CoreXY translation for TrivKins
Hello,
here ist the debug Information:
Attached the whole report.
Best wishes
Jan
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
Attachments:
Last edit: 22 Mar 2021 14:25 by +Jan+.
Please Log in or Create an account to join the conversation.
22 Mar 2021 15:00 #203247
by PCW
Replied by PCW on topic CoreXY translation for TrivKins
Unless you are running a BeagleBone and have loaded the
spiPRU driver, no spiPRU pins will be present.
spiPRU driver, no spiPRU pins will be present.
Please Log in or Create an account to join the conversation.
Time to create page: 0.327 seconds