- Posts: 26
- Thank you received: 0
Need help Homing sequence in H-bot( CoreXY) system
Thanks a lot andypugh for your proposal. I really appreciate it a lot.
Concerning modifying homing.c, I understand your concerns about fully validating any modification in this part of the code. After looking at homing.c, the idea was to keep the state machine as is, and to process the joints commands through InverseKinetics or not, depending on a new option to be added to the INI file, in the homing section. This would require to modify home_start_move and home_do_moving_checks functions, and probably a little more...
Anyway, what you proposed is much easier to manage (no linuxcnc code to compile)... I like the 2nd option C.
I'll think about it and try to make a test as soon as possible in the next few days. I'll keep you posted.
Thanks for your help.
Best regards,
Bernard
Please Log in or Create an account to join the conversation.
2 Quick questions:
- Is there any drawback (issue), for a CoreYX machine, using the trivial kinematics in the INI file settings (instead of corexykins) and performing the forward and inverse required transformations (X, Y <--> joint.0, joint.1) directly in the custom.HAL file ? I this case, I'll not need the 'is-homing' signal as the required transformation will be enabled all the time.
- I have not found the "is-homing" pin or signal in the HAL documentation (linuxcnc v2.9). Does it exists or do I have to build it ? Using what existing HAL pins ?
Thanks in advance for your help.
Best regard, Bernard.
Please Log in or Create an account to join the conversation.
The main drawback is that following-error tracking is problematic, as the motor positions are not the same as the system is expecting.nbremond wrote: Is there any drawback (issue), for a CoreYX machine, using the trivial kinematics in the INI file settings (instead of corexykins) and performing the forward and inverse required transformations (X, Y <--> joint.0, joint.1) directly in the custom.HAL file
But then this is also the case with my suggested HAL component. In fact I think that there is a good argument that your suggestion is a simpler and better solution than my HAL-layer suggestion.
joint.N.homing - linuxcnc.org/docs/2.8/html/man/man9/motion.9.html (I misremembered the pin name)I have not found the "is-homing" pin or signal in the HAL documentation (linuxcnc v2.9). Does it exists or do I have to build it ? Using what existing HAL pins ?
Please Log in or Create an account to join the conversation.
I'll give it a try (maybee tonight) using the following HAL function (using comp) I wrote:
And connect it between the path calculations, and the PID that has been defined for each joint (steppers) driven by my mesa 7i96 board.
This HAL function perform the same calculation as in the corexykins (forward and inverse)
I hope this will be OK !
Please Log in or Create an account to join the conversation.
as 0,5(joint0 "" joint1) is a angeluar movement discription
most at 45 deg calculation
so the standard g-code woudt do a great performence on a setup with hexapod kinetik
Please Log in or Create an account to join the conversation.
@andypugh
I did some test tonight, and the HAL module I wrote with your help is working fine... at least at reasonable speed.
The homing is working also, along X and then along Y. This is a good news
I have attached to custom.hal and the corexy.comp files.
At higher speed (> 7000mm/mn), I get tracking errors on joint 0 and 1.
Do you any advise on how to investigate and fix tracking errors ? May this be due to the PID tuning ?
Thanks in advance.
Please Log in or Create an account to join the conversation.