CoreXY bug

[oilytin]

Hi,
Homing only moves one motor at a time all other corexy movements (jogging etc) are ok.
gnea#49 (comment)
A workaround was posted in the issue above but i am unsure how to apply it here.
Thanks
Anthony

[fra589]

Hi @oilytin,

I don't have a CoreXY machine so it's difficult for me to do the necessary tests.
You can try to use the linked workaround, the line number 347 mentioned in the workaround comment corespond to the line number 461 in the actual grbl-Mega-5X version.
You also need to add bits for your CoreUV need...
This solution is surely a bad solution, but if it work... Try it.
If you need more help to make a real patch, I will need to made a coreXY prototype, this will probably take a long time as I don't have a lot of it.

@++;
Gauthier.

[oilytin]

By trial and error I found the value 89 works for coreXY +Z+A and the limits work as expected. It also sort of works on my coreXY/UV fork, the motors move as expected but the limits for X and Y dont work (U and V work as expected???) really at the limits of my knowledge trying to sort this 😖.

[oilytin]

With regards to building a Core xy prototype, you could probably get away with 2/4 motors and just observe the rotation. Moving along one axis will rotate the motors in the same direction, and moving along the other axis will rotate the motors in opposite directions.

Have done some more digging and found that the same steps as above needs to be aplied to the Initialize step pin masks part of the code in limits.c to get my corexy/uv code working.

Im guessing that this is the value that the respective bits of code should return but dont. its as if they only return half at the moment.

[AngusLawlessDunn]

Hi @oilytin and @fra589,

I believe I'm in the same situation as you. I have a CoreXY machine running four-axis on a standard Arduino Mega 2560 and homing is only moving one motor at a time. I don't need to home axis A but do need to home XYZ. I'm unsure how to apply the fix you suggested on May 26th, I can find the line in limits.c but I'm not sure what the value of 89 represents. In the linked workaround they said it was the "combined mask for step pins". Are you able to explain that or how to calculate it for my scenario?

My other alternative is to manually home by sending incremental gcode commands and poll the arduino to check when the limit switch has been triggered which I haven't tested yet.

Thanks,
Angus

[oilytin]

Hi @AngusLawlessDunn ,
89 was specific to my machine as i have both coreXY and coreUV, I came to that value through trial and error. 89 is just the decimal representation for 01011001 - the mask my machine needs.

[Knipex95]

Is there anything new on the topic?
I currently build a machine with CoreXY + Z + A and I can't finde the right value for the hot fix.
In the moment I'm not ready to build the Z axis so I have disable the homing for Z in the config.

I have try some value for sys.homing_axis_lock[idx] = XX; on line 334 in limits.c but without success.

I have manage to get the CoreXY to home but the A axis don't move or it's move to the sensor, triggert the sensor, drive 5 mm back and I get a error.

I try to find the problem in the code without success. (2 hours wasn't enough)

[fra589]

Hi @Knipex95,

I didn't find the time to work on this bug as there was a workaround to home the CoreXY...
The workaround is indeed on line #334 of limits.c. :-)

You say that you managed to have a correct home on the CoreXY, but that there is still a problem on the A axis...

Can you post your config.h, cpu_map.h, nuts_bolts.h and limits.c files, and the output of the $I and $$ Grbl's commands so that I can search a solution for your problem?

@++;
Gauthier.

[Knipex95]

@fra589 Hey
Sorry I can't post the Error anymore. :-)
The error are solved. Now CoreXY and A axis are homing correctly.

I invested about 6 hours of work and made many changes to many files.

But I create a new error. :-)
The code $21 Hard limits enable has no function any more. No matter whether 1 or 0.
If I trigger a limit switch it has no effect. Only shown in UGS.
For me it is not important I only use software limit and the hardware switch only for homing.

[fra589]

Hi @Knipex95,

@fra589 Hey Sorry I can't post the Error anymore. :-) The error are solved. Now CoreXY and A axis are homing correctly.

👌

I invested about 6 hours of work and made many changes to many files.

I'm interested with your changes. Please, can you post a zip file with all your Grbl code files?

But I create a new error. :-) The code $21 Hard limits enable has no function any more. No matter whether 1 or 0. If I trigger a limit switch it has no effect. Only shown in UGS. For me it is not important I only use software limit and the hardware switch only for homing.

Did you enable the #define ENABLE_RAMPS_HW_LIMITS in line 206 of cpu_map.h?

The hardware limits code is disabled by default to maximize performances. And I also think than software limits are enough and hardware limits are not useful.

@++;
Gauthier.

[Knipex95]

Did you enable the #define ENABLE_RAMPS_HW_LIMITS in line 206 of cpu_map.h?

No I don't :) I don't test it but i tink ist will work if I enable it.

I'm interested with your changes. Please, can you post a zip file with all your Grbl code files?

grbl.zip

I have done the main changes in:
limits.c
cpu_map.h
stepper.c
config.h
nuts_bolts.h
motion_control.c

But you have to compare it to find all changes. I don't document it.

And for a future project I need the dual motor support for self-squaring gantry homing.
I think it is possible on the Arduino Mega. Did you plan to add this function or did you need help?

And a side question is it possible by default to disable the Software limits only from the A axes.
I need complete freedom of the Rotary A. If not I will add it to my code for me.

[fra589]

And a side question is it possible by default to disable the Software limits only from the A axes. I need complete freedom of the Rotary A. If not I will add it to my code for me.

Just set the MAX_TRAVEL of the A axis to 0 (zero) and the soft limit of the A axis will be ignored.