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.

[Knipex95]

I try this already. I set $133=0 but I get an error message when homing.
Picture of the error message follows. Currently I am working on the machine.
And I can't turn it on.

[fra589]

I try this already. I set $133=0 but I get an error message when homing.

Oh darn!
I didn't foresee in the code that an axis with no limit could need homing since homing position is normally a limit.

Looking quickly in the code, it seems to me that you should get an alarm #10 in this case.
This error comes from the function void limits_go_home(uint8_t cycle_mask) within the file limits.c line #252.
Since the max travel value is zero, it is not possible to assign it to the max search distance of the limit switch for homing.

You need to deal with this special case in the code by adding a test that defines the max displacement if the value is zero for rotary axis.
Can be a think like this in limits.c (not verified):

I probably add this to the code soon :-)

@++;
Gauthier.

[Knipex95]

Can be a think like this in limits.c (not verified):
With a small change it runs without problems and exactly as I wanted

and is no Arduino code the correct one is && and I change to 380° but this is my personal safety :)

Thank you I hope you get some time to update the code on GitHub so that other people can benefit from it.

[fra589]

Hi @Knipex95,

I change to 380° but this is my personal safety :)

I think than the correct way to add safety will be to use HOMING_AXIS_SEARCH_SCALAR * 360.0 to be consistent with linears limits.

and is no Arduino code the correct one is &&

Grbl and by inherit, grbl-Mega-5X, is not "Arduino" code, but pure highly optimized C code, utilizing every clever feature of the AVR-chips to achieve precise timing and asynchronous operation. Not either C++!

In fact, personally, I don't use Arduino to compile it. I use make under Linux which directly calls the avr-gcc compiler.
Ardiono can't produce this kind of really optimized code, the use of Arduino IDE to compile it is only here for helping users who would not have enough skills to do otherwise.
This why Grbl is installed as a library in the Arduino IDE and not as a standard Arduino code and the Arduino sketch which permit compiling it contain only one line which call the whole library.
Since I'm an (very) old developer (I wrote my first C code line during the prehistory of computing, early in 80's) the old habit of writing "and" instead of "&&" comes back regularly :-).
Inside the C compiler, "and" and "&&" are exact synonyms and produce the same output code. But you are right, the common usage today is to use "&&" and not "and" for all C or C++ code.

For more information about this, read:
https://en.cppreference.com/w/cpp/language/operator_alternative
https://stackoverflow.com/questions/2376448/the-written-versions-of-the-logical-operators

I hope you get some time to update the code on GitHub so that other people can benefit from it.

Done ! 😃

@++;
Gauthier.