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] MKS Robin Nano E0_AUTO_FAN_PIN Sanity Check Error #14711

Closed
thisiskeithb opened this issue Jul 23, 2019 · 37 comments
Closed

[BUG] MKS Robin Nano E0_AUTO_FAN_PIN Sanity Check Error #14711

thisiskeithb opened this issue Jul 23, 2019 · 37 comments

Comments

@thisiskeithb
Copy link
Member

thisiskeithb commented Jul 23, 2019

Description

TL;DR: #if HAS_AUTO_FAN block in SanityCheck.h thinks two separate pins are the same.

Background

I am compiling a config for the Tevo Nereus (MKS Robin Nano-based w/ "dumb" MKS TFT) which has the hotend attached to HE0 (pin PC3), hotend auto fan connected to HE1 (pin PB0), and the parts cooling fan connected to the FAN connector (pin PB1):

For a general board reference:
image

Link to schematics on MKS' repo.

Steps to Reproduce

Setting E0_AUTO_FAN_PIN to FAN1_PIN in Configuration_adv.h causes the SanityCheck.h to return "You cannot set E0_AUTO_FAN_PIN equal to FAN_PIN." despite the pins being different for FAN1_PIN and FAN_PIN:

//
// Heaters / Fans
//
#define HEATER_0_PIN       PC3
#if HOTENDS == 1
  #define FAN1_PIN         PB0
#else
  #define HEATER_1_PIN     PB0
#endif
#define FAN_PIN            PB1
#define HEATER_BED_PIN     PA0

Commenting out the hotend conditional and defining the FAN1_PIN directly returns the same "You cannot set E0_AUTO_FAN_PIN equal to FAN_PIN." error:

//
// Heaters / Fans
//
#define HEATER_0_PIN       PC3
//#if HOTENDS == 1
//  #define FAN1_PIN         PB0
//#else
//  #define HEATER_1_PIN     PB0
//#endif
#define FAN1_PIN           PB0
#define FAN_PIN            PB1
#define HEATER_BED_PIN     PA0

Taking it a step further and defining E0_AUTO_FAN_PIN as PB0 in Configuration_adv.h and commenting out FAN1_PIN in the pins file still results in the same "You cannot set E0_AUTO_FAN_PIN equal to FAN_PIN." error:

//
// Heaters / Fans
//
#define HEATER_0_PIN       PC3
//#if HOTENDS == 1
//  #define FAN1_PIN         PB0
//#else
//  #define HEATER_1_PIN     PB0
//#endif
//#define FAN1_PIN         PB0
#define FAN_PIN            PB1
#define HEATER_BED_PIN     PA0

Troubleshooting further with @tpruvot, I modified the pins file again to undefine E0_AUTO_FAN_PIN and defined it directly as PB0, which still results in the same "You cannot set E0_AUTO_FAN_PIN equal to FAN_PIN." error:

//
// Heaters / Fans
//
#define HEATER_0_PIN       PC3
//#if HOTENDS == 1
//  #define FAN1_PIN         PB0
//#else
//  #define HEATER_1_PIN     PB0
//#endif
//#define FAN1_PIN           PB0
#undef E0_AUTO_FAN_PIN
#define E0_AUTO_FAN_PIN    PB0
#define FAN_PIN            PB1
#define HEATER_BED_PIN     PA0

If you comment out the #if HAS_AUTO_FAN block in SanityCheck.h, everything compiles without issue and both the auto fan & parts cooling fan works as expected (confirmed with the help of @zillarob since he owns the printer).

Why is sanity check throwing an error when these are clearly two different pins?

Config/pins file: Tevo Nereus - MKS Robin Nano.zip

@thisiskeithb
Copy link
Member Author

More troubleshooting from another issue.

@tpruvot: Is there a particular file I should look for? There are a ton of files to go through now that I've added the -save-temps flag (see screenshot below), but the ones I've checked don't offer any real answers:

Screen Shot 2019-07-26 at 12 46 18 PM

@tpruvot
Copy link
Contributor

tpruvot commented Jul 26, 2019

i would check on the file where you got the error in the past. I think its a ".i" file for the preprocessed C code

@thisiskeithb
Copy link
Member Author

Here are all the *.i files if you can point me in the right direction: tevo-nereus-temp-files.zip.

I'm not seeing an obvious error/reason why SanityCheck.h is throwing that that "You cannot set E0_AUTO_FAN_PIN equal to FAN_PIN." message.

@tpruvot
Copy link
Contributor

tpruvot commented Jul 26, 2019

from board.ii on the VET6 i get that

# 126 "~/.platformio/packages/framework-arduinoststm32-maple/STM32F1/variants/generic_stm32f103v/board/board.h"
enum {
PA0,PA1,PA2,PA3,PA4,PA5,PA6,PA7,PA8,PA9,PA10,PA11,PA12,PA13,PA14,PA15,
PB0,PB1,PB2,PB3,PB4,PB5,PB6,PB7,PB8,PB9,PB10,PB11,PB12,PB13,PB14,PB15,
PC0,PC1,PC2,PC3,PC4,PC5,PC6,PC7,PC8,PC9,PC10,PC11,PC12,PC13,PC14,PC15,
PD0,PD1,PD2,PD3,PD4,PD5,PD6,PD7,PD8,PD9,PD10,PD11,PD12,PD13,PD14,PD15,
PE0,PE1,PE2,PE3,PE4,PE5,PE6,PE7,PE8,PE9,PE10,PE11,PE12,PE13,PE14,PE15,
};
# 34 "~/.platformio/packages/framework-arduinoststm32-maple/STM32F1/variants/generic_stm32f103v/board.cpp" 2

but the RCT6 is different, with less gpios

@boelle
Copy link
Contributor

boelle commented Jul 26, 2019

just my 0.02DKK

do you set the autofan pin in the pins file? i set it in configuration_adv.h

@tpruvot
Copy link
Contributor

tpruvot commented Jul 26, 2019

maybe try fgrep -r PB0 * to find conflicting ones...

@tpruvot
Copy link
Contributor

tpruvot commented Jul 26, 2019

nope i dont, our nozzle fan pin is 24V permanent

@thisiskeithb
Copy link
Member Author

@boelle: See the first post 🙂 I’ve tried setting it multiple ways. The weird part is that if you bypass the sanity check, the board works as expected.

@boelle
Copy link
Contributor

boelle commented Jul 26, 2019

yeah, i just updated my fork and get the same error if i set auto fan to the same as part cooling fan

i know that some delta printers like the reprap pro fisher used one fan to cool both the cold end and at the same time work as a part cooling fan, https://www.thingiverse.com/thing:1503175

@tpruvot
Copy link
Contributor

tpruvot commented Jul 26, 2019

but he doesnt set to the same pin ^^

@thisiskeithb
Copy link
Member Author

@boelle: I know it can be wired differently/modded, but in order to get a printer config into Marlin, it needs to work on the stock/shipped printers. Telling users who upgrade Marlin to rewire their machine/install mods isn't going to fly.

@boelle
Copy link
Contributor

boelle commented Jul 26, 2019

nope, excatly my thought, i just took the fisher as an example where i know that auto fan and fan needs to be the same for it to work out the box

@thisiskeithb
Copy link
Member Author

@tpruvot: Here are the results when searching the temp files for PB0.

@tpruvot
Copy link
Contributor

tpruvot commented Jul 29, 2019

so i seen some boards have #define ORIG_E0_AUTO_FAN_PIN ...

see Marlin/src/pins/stm32/pins_REMRAM_V1.h may be related

@thisiskeithb
Copy link
Member Author

I've asked @zillarob to test the latest changes (Tevo Nereus branch) which now compiles with E0_AUTO_FAN_PIN FAN1_PIN set, so we'll see if PR #14785 fixed the issue and didn't break anything. 🤞

@zillarob
Copy link

I should have some time to give it a run this eve and will let you guys know.

@thisiskeithb
Copy link
Member Author

PR #14785 fixed the pin enums issue we were all seeing. Thanks @tpruvot! But now the LCD touch buttons no longer work.

Closing this since the originally reported issue is fixed. @zillarob and I will try to work out which commit broke the touch buttons on the stock Robin Nano TFT.

@tpruvot
Copy link
Contributor

tpruvot commented Aug 2, 2019

#14768 i guess, no issue here. Maybe the timeout

@zillarob
Copy link

zillarob commented Aug 2, 2019

Got a chance to do some looking and it might be the calibration. I did give some random taps on the new one that didnt work the other day just to check, but didnt go crazy so may have slipped by.

On the mks_touch one I tested for you I had commented out the calibration in config and pasted the mks calibration in the pins file.

On this new version the cal in config is defined, and no mks cal in the pins file.
The numbers look to be similar, but pretty much inverted +/- between the two cals.

I will be out this weekend so prob wont get to test until sun/mon. Hopefully false alarm =D

@zillarob
Copy link

zillarob commented Aug 3, 2019

@tpruvot @thisiskeithb

Good news, and bad news.

Bad news- The weekend didnt go as planned. There was a big boat and a big rock. The big rock won. Was starting to wonder if I was going to find out how good of a swimmer I am =)

Good news- I got back early and was able to play around. Pasting in the mks calibration got everything working again.

Not sure where the best place to put that in might be, Id guess in the pins file, but I will leave that to sharper minds =D

@zillarob
Copy link

zillarob commented Aug 8, 2019

@tpruvot
Looks like you do a bunch of work on the Longer board?
Seems similar to the Robin Nano so I pulled the servo stuff out and pasted into the Nano pins and will test BLTouch later this eve.
I was curious if you knew if BLTouch was working on the Longer board using the PE5 endstop pin?

@tpruvot
Copy link
Contributor

tpruvot commented Aug 8, 2019

if you mean the endstop as pwm pin, users need to remove a tiny capacitor to use it.

@zillarob
Copy link

zillarob commented Aug 8, 2019

Thanks!
Looks like the cap is on the end at least so should be easy to push off with the iron.

@zillarob
Copy link

zillarob commented Aug 8, 2019

@tpruvot
Getting closer =D
Seems to be working, but is very jittery. Pin I used was PA11 (TIM1) in the Z- endstop.
The one on there now is a TL clone, but it was working fine on the SKR v1.3 before.
Will have to swap in my genuine BLT and see if it fares better.
I tried with cap on and cap off, seemed to be the same, but I didnt try homing it with the cap on still.

@zillarob
Copy link

zillarob commented Aug 9, 2019

So I got the iron back out, knocked the 10k resistor R45 off the board, and bridged the pads with solder to see if more sig helped.
It is rock solid now without a single pin glitch since.

estop

@tpruvot
Copy link
Contributor

tpruvot commented Aug 9, 2019

yep, seems weird a so huge value there...

our cap value was too high for the PWM :
image

@zillarob
Copy link

zillarob commented Aug 9, 2019

Ya, I always thought 4.7k was the go-to for these things, but seeing the 10k more and more.

Im trying to see if can use E1 EN, STP, DIR for this also so dont have to mod the board.
I had the pins wrong above so need to fix that, they are actually
E1 STP PA6 TIM(3,8,1?), E1 DIR PA1 TIM(2,5), E1 EN PA3 TIM(2,5)

I see the open drain stuff in the Longer pins file, but I dont fully understand what that is (yet).
Would these qualify for the OD setup with no pullup like the endstop has, or do I need to keep reading the data sheet =D

@tpruvot
Copy link
Contributor

tpruvot commented Aug 9, 2019

the open drain (OD) is when you use a pullup res over the 5V (or more). the chip will only ground it to 0 (=5V) or be "unconnected" to the chip (= 0V on the device) so the logic is reversed

@zillarob
Copy link

zillarob commented Aug 9, 2019

Thanks for the tip. Looks like I have more homework to do =D
I may need to be really careful with those, they arent 5v tolerant.
Easy enough to pullup to 3.3 and just try it the normal way, but would be nice to not have to add the resistor.

When you set a servo pin, do you know if it enables the internal pullup so we might not have to add anything?

@tpruvot
Copy link
Contributor

tpruvot commented Aug 9, 2019

pullup or pulldown are for inputs, servo signal is an output. Dont mess that with the ZMin sensor of the bltouch... need both Zmin and ZMax (here as output)

@zillarob
Copy link

zillarob commented Aug 9, 2019

Here is what I have been playing with. Pruned from the Longer file and pins set for the Nano.
Zmin >> servo, Zmax >> Zmin

//
// PWM
//
#define NUM_SERVOS 1
#define SERVO0_TIMER_NUM 1 // General or Adv. timer to use for the servo PWM (2,5 might be reserved)
#define SERVO0_PIN PA11 // Pulled up PWM pin (3.3V or 0)

@tpruvot
Copy link
Contributor

tpruvot commented Aug 9, 2019

yep, i said that because you said you removed the Zmin resistor.. which is not the most logic :p (if you want to use a normal sensor later, well this R45 seems useless anyway)

@tpruvot
Copy link
Contributor

tpruvot commented Aug 9, 2019

Are you sure it was a 10K one ? those in serial are generally small values "fuses" ones as protection

@zillarob
Copy link

zillarob commented Aug 9, 2019

For sure, Im just fumbling my way through this stuff. Have an extra board just in case though =D
Im not certain what that resistor is for, but always guessed it was if somebody hooked up the endstop different or wrong it would keep the current down and protect the chip?

It was 10k on the button with the meter. BTT looks like they use them on the SKR also. Oddly enough the TL Touch worked fine on the SKR. SKR v1.3 had a dedicated servo pin so that prob had something to do with it.

Double checked with the meter
Nano is 10k on the pullup and the one back to the chip
SKR is 10k on the pullup, 1k on the one back to the chip

@zillarob
Copy link

zillarob commented Aug 9, 2019

Just tested The BLT on E1 STP PA6 TIM8 and looks good on the Robin Nano.
I did only run it through a couple autolevels and havent printed with it yet.

Originally set up with 10k pullup to 3.3v, but pulled that off just to see what would happen and appeared to work fine without.

Got a test print out (no pullup) and looks good. I think this might be a good option for the nano guys that arent using E1 and dont want to mess with the cap/resistor.

@ETE-Design
Copy link
Contributor

Anyone know if simular option is possible for the MKS Robin Lite? Do I just have to put in the PWM line in the pin definition? Or also remove the 10k on the Z+ for it to work?

@github-actions
Copy link

github-actions bot commented Jul 4, 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 Jul 4, 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

5 participants