[BUG] TRONXY Chitu V8 Z Endstop

[TylerHooper]

Z-Endstop on Chitu V8 boards seems to remain in triggered state after pressed once and released. As such this makes it impossible to home Z properly or print. A workaround has been found by utilizing the unused z-max pin. This can be done by swapping the Z endstop switch from z-min to z-max on the board, then modifying Marlin/src/pins/stm32f1/pins_CHITU3D_V5.h and changing #define Z_STOP_PIN from PA14 to PA13.

[thinkyhead]

Do you have the pull-up turned on for the problematic endstop? Try that and see if it helps.

[TylerHooper]

I had tried enabling that, but it did not seem to have any effect. I see there was a bugfix for this issue, as originally the signal started in a triggered state (this was explained at the end of HOWTO-INSTALL.md for the TRONXY X5SA), however the fix only seems to resolve this up until the switch is pressed the first time.

This is what I found from Marlin/buildroot/share/PlatformIO/variants/CHITU_F103/wirish/boards_setup.cpp

__weak void board_setup_gpio(void) {
            /**
             * PA14 is a pull up pin. But, some V5 boards it start with LOW state! And just behave properly when the Z- PROBE is actived at least once.
             * So, if the sensor isnt actived, the PA14 pin will be forever in LOW state, telling Marlin the probe IS ALWAYS ACTIVE, that isnt the case!
             * Chitu original firmware seems to start with every pullup PIN with HIGH to workaround this.
             * So we are doing the same here.
             * This hack only works if applied *before* the GPIO Init, it's the reason I did it here.
             */
            #ifdef CHITU_V5_Z_MIN_BUGFIX
              GPIOA->regs->BSRR = (1U << PA14);
            #endif
            gpio_init_all();
        }

[rhapsodyv]

Did you try to use the env chitu_v5_gpio_init instead of chitu_f103?

[TylerHooper]

Yes, that is the env I have been using

[rhapsodyv]

Did you try to use V6 board? Some v8 are equal to V5 and some are equal to V6

[TylerHooper]

Hmm I actually did not try that! I have everything working on the other pin so I'm taking a break from tinkering for the moment, but I can certainly give that a try if that would be helpful.

[krukhlis]

Did you try to use V6 board? Some v8 are equal to V5 and some are equal to V6

@rhapsodyv
I second you!!! I've wasted whole day today fighting with strange issue with my new shiny Tronxy X5SA 2020 that comes with V8 STM32 board and TMC 2225 drivers. I've managed to configure everything and even resolved quarter-sized Marlin screen and "Tronxy touchpad-not-working with Marlin" issues by myself. But one issue costed me smashed printer's head and X-Axis Rail that now looks like some flat Bell. And the issue is Marlin is completely ignoring data from the Tronxy stock inductive probe. I see the sensor reacts with red light to any metal approaching it, I see signal comming to Tronxy V8 motherboard( measured with multimeter and osciloscope). But Marlin keeps eyes closed and smashed everything he can reach with massive table.
So, after almost whole day lost and trying different build targets in platformio.ini ( default_envs = chitu_f103 or chitu_v5_gpio_init , based on readme.md) I've finally found silver bullet that works for me.

1. Keep chitu_v5_gpio_init as default env for your project
2. Change default config for your Tronxy from this repo, I mean Configuration.h
   , replace BOARD_CHITU3D_V5 to
   #define MOTHERBOARD BOARD_CHITU3D_V6
   Build it and flash it. 99.99% it will resolve your issue.

I sugged to update README.MD for Tronxy configs to include this essential and critical information for any victim( with V8) of the creative minds of the Tronxy engineers.

[rhapsodyv]

Yes, I’m gathering information about tronxy board numbers to match with marlin configs, to avoid it.
I’m trying to get official info pro tronxy too.

[ElliottFox]

@rhapsodyv, @krukhlis
Thanks, the V6 comment helped me a lot. The only trouble is now I can't stop my bed from crashing into my nozzle at random! Sometimes it stops, sometimes it doesn't!

I have tried endstop_inverting on both true and false. On true the bed doesn't move up at all, on false it does but the sensor trigger doesn't stop it. I am using chitu_v5_gpio_init and V6. I am also using the black tronxy TR sensor.

Does anyone have any ideas? Here is my config file (changed it to .txt for upload):
Configuration.h.txt

Thank you!

[SergedeParis]

I broke my firmware by mistake so I flashed Marlin on my X5SA Pro. Everything looked fine except for the Z-stop. So I followed advices.
For me, nothing has improved. "Z-Endstop on Chitu V8 boards seems to remain in triggered state after pressed once and released. As such this makes it impossible to home Z properly or print."
I have tried the Z-Max connector with PA13, the Chitu V6 board im my Configuration.h, I mean every idea given here without success. I guess I have to go back to stock firmware if I can find it. I you have solved it please let me know.

[nighonimpossible]

@SergedeParis I have a similar issue with Marlin and a non-working z-stop (although I'm starting to suspect the z-stop connector on the board is just damaged). At the risk of teaching granny to suck eggs (and apologies if I am), one of the problems I found with the "oh just use the z-max connector and change to PA13 from PA14" is they generally leave out the essential advice of providing a voltage divider. I also did not have any luck changing definitions in Configuration.h (I'm no Marlin guru). I had to alter the Z_STOP_PIN definition to PA13 in the "pins_CHITU3D_V5.h" file which lives in "Marlin/src/pins/stm32f1" in addition to the hardware bodge. NB: I have an old V5 board, no doubt yours will have some different model but I'm guessing there are V6 and V8 versions of the file.

As I mentioned, I then had to build a little circuit (voltage divider) to turn the 24v signal output provided by the probe down to (around) 5V to feed into the signal pin on the z-max connector. Using a multimeter it appears all the end-stop connectors run at 5v with the exception of the bed-levelling (z-min) connector which runs at 24v. Simply running the signal line from the probe direct to the signal pin on one of the other end-stop connectors will probably fry something :-(

I guess the voltage divider and all the mucking about would be not necessary with a genuine 5V probe, however, all the probes I have are either 10-40v or the 6v-36v types (which really don't work at only 5v in my experience).

In any case I now have a working set up again, hopefully the information is of use (no egg sucking) . If you have any questions I'll try my best to answer them.

[Amilleriiw]

so is there a easy fix for this im am working on one now and having the same issues

[thinkyhead]

The PINS_DEBUGGING option with M43 is designed to solve such issues and to locate the correct pins. For example, you can use M43 to watch a range of pin numbers and get feedback in the host console when one of the pins changes state.