During testing of the provided Anycubic Kossel Pulley config in 1.1.x-bugfix, following the README, when i do Set delta height with Z-Probe V2 connected, my printer crashes in the XYZ MAX endstops, forcing me to shutdown the printer.
Expected behavior: [What you expect to happen]
Correct delta height around 333.50
Actual behavior: [What actually happens]
Moves around 30mm down then goes backwards and crash on endstops
SENDING:M119
>>>> Tested all endstops, works correctly <<<<
Reporting endstop status
x_max: TRIGGERED
y_max: TRIGGERED
z_min: open
z_max: TRIGGERED
echo:enqueueing "G33 P1"
G33 Auto Calibrate
Checking... AC
.Height:320.00 Offset:-16.80
echo:busy: processing
echo:busy: processing
echo:busy: processing
Calibration OK std dev:0.000
.Height:29.19 Offset:-16.80 <<<< Wired height...
>>>> Crash to endstops happened here <<<<
I can help you to test these configs, also there is my hand-made working config that i'm currently using
handmade_configs.zip
Thank you in advance, F0x.
Try the bugfix-2.0.x version, I fixed a lot of issues there.
Thank you for the quick reply, I will test that tomorrow and come back with the results :)
Hi @brandstaetter, same issue on bugfix-2.0.x.
./Marlin/src/config/examples/delta/Anycubic/Kossel to ./MarlinANYCUBIC_PROBE_VERSION to 2Does homing work?
It kind of sounds like you inverted your stepper directions, has it worked with another firmware before? Can you try homing and then moving the Z direction?
Yes homing works. And yes worked on my own previous config (attached handmade_configs) I'll try to move Z from LCD menu
Ok, fixed by switching Z_MIN_ENDSTOP_INVERTING and Z_MIN_PROBE_ENDSTOP_INVERTING to false. Why these values are set to true by default ?
Either you or I connected the probe wrong then to the board. Can you check? I鈥檓 not at my printer at the moment.
@brackendawson Connected with the black wire to the exterior side, like other endstops, these are working perfectly. Tell me your wiring when you can check on your printer :)
@brackendawson I successfully calibrated my printer, all is working properly now, great configs :) !
@F0x06 I checked my wiring, the probe is connected the same as all the other endstops. I also checked the instruction manual again. So either yours or mine is connected wrong in the cable :) (and since it is the same in many other custom Kossel configurations, I'm betting it's yours)
@brandstaetter Probably me, can i have a picture of your end-stops pins ? Maybe my probe has been wrongly assembled... In your build, the black wires are on which side ? Exterior (Close to the third unused pin) or Interior ? In my case Exterior like this
B: Black
R: Red
Z+ Z- Y+ Y- X+ X-
R R R * R *
B B B * B *
* * * * * *
^
|
- The Z-Probe
I just looked in the build manual, it does say to connect it the same as the others?
v1 probe is NO
v2 probe is NC
see https://github.com/emilio1625/Anycubic-Kossel-Marlin/blob/1.1.x/Marlin/example_configurations/delta/ANYCUBIC/Configuration.h
Oooh, that explains a lot. I'll modify my example configuration to take that into consideration.
also the v2 z offset is 15.9. thats from the official anycubic firmware.
@b0ssman On my printer with my V2 probe my offset is at -16.80, I have good results
I'll leave it at 16.8 then. Now you can safely measure your own.
Mine is now at -15.69 thanks to the crash that nearly broke it
@brandstaetter Whoops, yes Z-Offsets are different on each build, maybe better to put a lower value, and specify in the doc how to adjust them to avoid any crashes like -15.4 specified in https://github.com/ANYCUBIC-3D/ANYCUBIC_Kossel_Source_Code/blob/master/ANYCUBIC_Kossel_Beta2/Configuration.h#L624, thanks for the fix! :)
With #11899 the risk to the probe should be resolved and it can be measured safely from the LCD UI
Nice I'll try it tonight :)
It's been merged into bugfix-2.0.x now.
If you first measure the delta height with the probe, and then do the z-offset measurement, you should get reliable values without risking the probe now.
@F0x06 if you still have problems with the Z probe being connected wrong, just change the version to 1, that should help
@brandstaetter Thank you! I'll try it :)
@brandstaetter Probes are always miss configured in latest version, as said by @b0ssman
v1 probe is NO
v2 probe is NC
Or its me ?
// Mechanical endstop with COM to ground and NC to Signal uses "false" here (most common setup).
#define X_MIN_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.
#define Y_MIN_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.
#define Z_MIN_ENDSTOP_INVERTING true // set to true to invert the logic of the endstop.
#define X_MAX_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.
#define Y_MAX_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.
#define Z_MAX_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.
#if ANYCUBIC_PROBE_VERSION == 1
#define Z_MIN_PROBE_ENDSTOP_INVERTING false // V1 Probe is NC
#elif ANYCUBIC_PROBE_VERSION == 2
#define Z_MIN_PROBE_ENDSTOP_INVERTING true // V2 Probe is NO
#endif
It must be
// Mechanical endstop with COM to ground and NC to Signal uses "false" here (most common setup).
#define X_MIN_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.
#define Y_MIN_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.
#define X_MAX_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.
#define Y_MAX_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.
#define Z_MAX_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.
#if ANYCUBIC_PROBE_VERSION == 1
#define Z_MIN_PROBE_ENDSTOP_INVERTING true // V1 Probe is NC
#define Z_MIN_ENDSTOP_INVERTING true // set to true to invert the logic of the endstop.
#elif ANYCUBIC_PROBE_VERSION == 2
#define Z_MIN_PROBE_ENDSTOP_INVERTING false // V2 Probe is NO
#define Z_MIN_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.
#endif
Thanks, otherwise it works really great, and the multi-probing is a lot faster now :)
@F0x06 please make the pull request yourself. I thought I have V2 Probes and it works for me as-is. I will recheck my wiring and also check with the other probes that I have.
Plus, I finally need to build up the Linear Plus that I got to verify that setup too.
@brandstaetter OK, I'll check with the anycubic stock firmware before. if it's reversed too then its my probe, maybe wires are reverses by a manufacture error. I'll also ask on the FB group to have other users inputs.
@F0x06 I now built a Kossel Linear Plus I had sitting in a box for some weeks now - it seems to have a V1 probe, and the logic is really inverted to the V2 one...
Small fix is necessary, see #11929
@brandstaetter Nice!, I checked also on my side with Spike's Lee version, it's inverted. No need to make a pull request tonight so. Thank you for the fix. Feel free to close the issue when done :) The fix is almost the same as mine (posted few posts before)
Just bought a V2 probe, and it is definitely NC.
So Z_MIN_ENDSTOP_INVERTING needs to be false for a V2 probe.
By the way, reversing wires on a simple switch doesn't make the switch behave differently. So it doesn't matter where the red and black wire go, as long as one is on the GND pin (middle row) and the other one is on the GPIO pin (top one).
I can make new PR if desired.
You are correct @JelmerT still reversed, it must be like this for a V2 probe:
#define Z_MIN_PROBE_ENDSTOP_INVERTING false
#define Z_MIN_ENDSTOP_INVERTING false
I'll make the PR :)
@thinkyhead @brandstaetter I guess the bug is still present on 1.1.x and on 1.1.x-bugfix do you want me to make a PR also ? :) Or i let you do the modifications because configs maybe need some other changes ?
is there a config for the kossel on 1.1.x?
is there a config for the kossel on 1.1.x?
I ran into the bug when running 1.1.x would be great if it got fixed there too
I'll do the PR for 1.1.x maybe tomorrow @JelmerT
@F0x06 looks like #12101 already fixed this in the bugfix branch
@JelmerT you're right, so I can close this issue :)
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.