Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Compilation fails for BTT SKR1.4 Turbo when using dual Z endstops #19595

Closed
Le0Michine opened this issue Oct 3, 2020 · 5 comments
Closed

Comments

@Le0Michine
Copy link

Le0Michine commented Oct 3, 2020

Bug Description

Currently if user tries to enable dual Z axis with independent endstops for BTT SKR1.4T the compilation would fail with the following error:

#error "Z2_USE_ENDSTOP has been assigned to a nonexistent endstop!"

A simple way to fix it is to update pins for SKR1.4 to allow using E0DET, E1DET and PWRDET as endstops. That would be the same solution which is already applied and working for SKR1.3 boards where you can see that exactly the same pins are being assigned to two different functions.

https://github.com/MarlinFirmware/Marlin/blob/2.0.x/Marlin/src/pins/lpc1768/pins_BTT_SKR_V1_3.h#L47
https://github.com/MarlinFirmware/Marlin/blob/2.0.x/Marlin/src/pins/lpc1768/pins_BTT_SKR_V1_3.h#L94

In addition pins E0DET, E1DET and PWRDET are being used as max endstops in current version of pins_BTT_SKR_V1_3.h so it seems it should be fine to extend that behavior to cover more configurations

https://github.com/MarlinFirmware/Marlin/blob/2.0.x/Marlin/src/pins/lpc1768/pins_BTT_SKR_V1_4.h#L59
https://github.com/MarlinFirmware/Marlin/blob/2.0.x/Marlin/src/pins/lpc1768/pins_BTT_SKR_V1_4.h#L70
https://github.com/MarlinFirmware/Marlin/blob/2.0.x/Marlin/src/pins/lpc1768/pins_BTT_SKR_V1_4.h#L81

I tried to submit a pull request #19532 fixing the issue but without much communication it was closed almost right away. So I'm trying to follow up on it with this bug report and see what can I change to get it merged.

My Configurations

Required: Please include a ZIP file containing your Configuration.h and Configuration_adv.h files.

Steps to Reproduce

  1. Using attached configuration files config.zip try to build Marlin for LPC1769

Expected behavior: [What you expect to happen]

Build successful

Actual behavior: [What actually happens]

Build fails with

#error "Z2_USE_ENDSTOP has been assigned to a nonexistent endstop!"

Can make it work if the following line is added to pins_BTT_SKR_V1_3.h file

#define Z_MAX_PIN                      P1_00

Additional Information

Attachments:

@ellensp
Copy link
Contributor

ellensp commented Oct 3, 2020

BTT SKR 1.3 has min and max endstops
BTT SKR 1.4 only has endstops (one set of 3) and E0DET, E1DET and PWRDET
This is how they are written on the controller and the schematics.
So this is how they are implemented in marlin.
So on a skr 1.4 you should not use "#define Z2_USE_ENDSTOP _XMAX_"
you should use _E0DIAG_ or _E1DIAG_
No easy way to use PWRDET pin

@ellensp ellensp closed this as completed Oct 3, 2020
@Le0Michine
Copy link
Author

Le0Michine commented Oct 3, 2020

@ellensp thanks for a quick response, I would appreciate it if you could help me a bit more.

The problem I was facing when trying to use _E0DIAG_ is that it cannot be easily inverted using one of _MAX_ENDSTOP_INVERTING flag, at least I couldn't find a way to do that so if you could point me to it or to the docs where it is described I would be happy to check that out.

I would appreciate it if you could clarify for what reason pins labeled for filament sensors can't be used as regular endstops if from hardware point of view there is no difference between mechanical endstop and a mechanical filament runout sensor, could that be that you are most concerned about PWRDET pin and not about the other two?
It seems SKR1.3 does not have pins labeled for filament runout sensors, what makes it okay to assign those sensors to endstop pins?

I'm wondering what makes this change different from what I'm trying to propose 2822c08?

it introduced the following code:

#ifdef X_STALL_SENSITIVITY
  #define X_STOP_PIN                  X_DIAG_PIN
  #if X_HOME_DIR < 0
    #define X_MAX_PIN                      P1_26  // E0DET
  #else
    #define X_MIN_PIN                      P1_26  // E0DET
  #endif
...
  #define Y_MAX_PIN      P1_25   // E1DET
...
  #define Z_MAX_PIN      P1_24   // PWRDET
...

why enabled stall sensitivity makes it acceptable assigning those pins as endstops?
From the discussion on this PR #16727 it seems that it should be okay to do that and essentially the only difference in regards those pins between SKR1.4 and SKR1.3 is the labels.

@ellensp
Copy link
Contributor

ellensp commented Oct 3, 2020

wrong again. PWRDET does not have a pull up resistor.
If you want to use them as max endstops feel free to do so. Modify the pins files any way you want.
But this is non standard. Don't try and force your non standard config on the rest of us.

@Le0Michine
Copy link
Author

@ellensp I see, so PWRDET doesn't have the required resistor attached, but the rest two do, does that mean that they can be standardly assigned to the max endstops?

Also what makes my approach non standard if that is no different from what the code does today when stall guard enabled? If one is migrating from SKR1.3 with a setup similar t mine that is pretty much exactly what they would want to do isn't that right? Besides the assigning wouldn't happen if one does not have USE_MAX_PLUG flag enabled so for everybody who does not enable that flag or uses it with stall guard nothing would change, for those who enable that flag without stall guard the firmware wouldn't compile.

@github-actions
Copy link

github-actions bot commented Dec 2, 2020

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.

@github-actions github-actions bot locked and limited conversation to collaborators Dec 2, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants