CoreXY with FAST_COREXYZ defined is failing to home Z
Now and than I test "FAST_COREXYZ" for my CoreXY DIY printer.
First, without FAST_COREXYZ the printer works good so far. At least homing all axis is no problem at all.
But now to the issue: X and Y are homing perfectly. Also moving X/Y is working good/perfectly. But homing Z does not work.
It goes slowly up to z-min endstop, than it goes down slowly a few mm but immediately it goes down again about 2cm and stops. Now the printer tells me this position is "0 mm" -> z-min. To be honest, no way, thats wrong.
Short video for the effect
So whats going on there?
First, without FAST_COREXYZ the printer works good so far. At least homing all axis is no problem at all.
But now to the issue: X and Y are homing perfectly. Also moving X/Y is working good/perfectly. But homing Z does not work.
It goes slowly up to z-min endstop, than it goes down slowly a few mm but immediately it goes down again about 2cm and stops. Now the printer tells me this position is "0 mm" -> z-min. To be honest, no way, thats wrong.
Short video for the effect
So whats going on there?
Comments
Do you have any idea what could be wrong?
I also try to use FAST_COREXYZ and my Z-Axis never moves. It just resets the Printer.
Maybe insufficient ram?
looks like multiple z-endstops are not working with fast_corexyz.
With only one z-max-endstop my z-axis works.
dragon ball super | animeyt
My printer is DIY, RAMPS 1.4 (modified) with DUE. So Hardware should not be an issue.
You should check your eeprom values for additional heights like bed coating. Also the first reversal seems to be to early. But I'm not sure you have eeprom at all if you used a RAMPS on due since due has no build in eeprom.
First reversal works perfectly as I use a hall sensor for z-min. I changed it allready for testing to 5mm without success. I did also check for additional heights but did not found any.
But I will disable autoleveling for testing also.
Last not least, the printer works without issues for homing/moving with same firmware (1.0.-dev). All I did was adding "#define FAST_COREXYZ 1" to configuration.h and compile. Steps/mm for X/Y and ext2 offset I changed with RepetierHost.
I did the test and disabled autoleveling and Z-Probe and changed eeprom setting so I get factory default.
No change. The issue with z-home still exist.
here is my config. Hope you find (my) error:
No need to waste so much computation time for a linear system.
Maybe i was no clear enough. Homing to z-min with a rotated bed is a very bad idea causing a head crash somewhere or you have no contact while printing. Z-min needs to trigger at the lowest point of the bed or that position can not be reached. If be dis rotated that means on all other location it would push nozzle into bed. If you adjust to stop higher it can not lower enough to have good contact for printing. So with z-min sensor the bed must be 100% flat. If that is the case no autoleveling is required. So if you autolevel you need to use z-probe also as z-min endstop or use z-max homing instead. Both solutions work.
I see apart from this no reason not to home z. Did you test endstop with M119 to see if it works correctly. Also use only G28 Z0 for z homing tests in case a later stage causes the problem. Z homing has these steps
- go down until endstop is hit
- go up a bit
- go down again until hit
- go up depending on bed coating and distortion correction and also set z height after homing (Z_UP_AFTER_HOME which you did not define).
Can you say at which stage your error occurs.
I do have z-min and this works perfectly without FAST_COREXYZ defined.
I do not have a rotated bed, whatever that means, I have a CoreXY printer, no Delta or something like that.
The config posted is WITHOUT bed leveling or z-probe, just min endstops for all axis!
You to tell me with FAST_COREXYZ it is not possible to home just x-min/y-min/z-min?
WHY the hack all is working without FAST_COREXYZ defined!!!! Nothing else (except steps/mm) is changed!?
As you see in the video it is not crashing into bed, its just homing completely weird for Z axis. It goes to a direction it shouldn't go.
May I am wrong, but I just don't understand what's going wrong here. To me it's a bug.
Don't get me wrong. I really want to help to find the answer/issue/solution.
No, never said that. I said it uses nonlinear computations and you should adjust these settings like used for deltas to better match for core xy. When you say it works without then that is already a new information and you should look closer to the params appearing if you select delta printer the the one I showed you already. These show only if delta is selected, so switch to delta, edit and switch back to core xy.
G28 Z0 for z homing tests in case a later stage causes the problem. Z homing has these steps
- go down until endstop is hit -> check
- go up a bit -> check
- go down again until hit -> instead of going down again it goes up a few cm
After that z-min is 0, z-min endstop is off.
"For fastcore xy you should reduce
As far as I can see in the source this is already reduced to "30" if using FAST_COREXYZ. As of now I don"t care about wasting computing time, DUE should have the power to handle it. Z axis is moving correctly if using g0/g1. But I will double check if this helps.
Are there any other settings which are important to change in a nonlinear setup to fit CoreXY?
btw. I said in the very first post that all is working without FAST_CORXYZ defined.
Yes, we have a reduction compiled in to fix most obvious errors like reducing updates to 30.
Honestly I can not say what is going wrong here - just don't see it. To fire it out you need to modify in Printer.cpp the
void Printer::homeZAxis() { // Cartesian homing
function. You will see there several PrintLine::move commands for all the stages and corrections. Also in
void Printer::homeAxis(bool xaxis, bool yaxis, bool zaxis) { // home non-delta printer
there is a move to go to final position.
What you need to do is uncomment the later moves to see which of the moves is doing the wrong move. Then we can see how the distance is computed for the problem move and see which vars are set wrong.
According your sequence I (think I) identified the move which should go down but goes up. But if I compare homeZ with homeY/homeX I think the bold line is wrong at this position setting first home hit. It should be after the 1st down, am I right!?
...
Unfortunately I am not at my printer this weekend so I can't test/debug. Anyway, I'll let you know if I find something next week.
btw. No need to apologize from your side. I know you are busy and FAST_COREXYZ still is "experimental".
Interesting part are the moves after that I guess. These 3 moves are very well tested and have no secret. It seemed maybe a bit that the second down move did not talke place maybe because the z endstop was still triggered? But if the only difference is having fast corexy enabled then that should also happen there.
One problem with z might be steps per mm. Nonlinear system reduces to steps per subsegmend 32767 as the steps need to be stored in 16 bit integers. And Z move MUST fit in one segment. So 2 * Z-Length * steps per mm /
DELTASEGMENTS_PER_PRINTLINE < 32767. If not strange things can happen.
I did a short test in moving the source line I mentioned above (bold line) after the "1st move down". And that it was! Homing Z seems to be stable now.
...
// update current position should be here !
I did test with and without FAST_COREXYZ on my printer and it worked perfectly for both versions.