search

MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.03k stars 19.13k forks source link

[BUG] BIGTREE_SKR_PRO_1v1 Pins mixed: calling (pin PF7) turns on (PF8) #16158

Closed carl1961 closed 4 years ago

carl1961 commented 4 years ago

Bug Description

Found while using RGB LED after Updating Marlin 2.0.x

Last working correctly (RGB LED) Marlin-bugfix-2.0.x "2019-11-10" Configuration.h

define RGB_LED

//#define RGBW_LED

if EITHER(RGB_LED, RGBW_LED)

define RGB_LED_R_PIN PF9

define RGB_LED_G_PIN PF8

define RGB_LED_B_PIN PF7

//#define RGB_LED_W_PIN -1

endif

define STRING_DISTRIBUTION_DATE "2019-11-10"

C:\BIGTREETECH\Working Mega CoreXY\newer\Marlin-bugfix-2.0.x\buildroot\share\PlatformIO\variants\BIGTREE_GENERIC_STM32F407_5X

First BROKEN Version traced back to Marlin-bugfix-2.0.x "2019-11-14"

define STRING_DISTRIBUTION_DATE "2019-11-14"

Pins mixed:

turning Blue LED On (pin PF7) turns on Green LED (PF8) Blue LED never comes on so pin PF7 is not active.

I think issue started when

variants BIGTREE_GENERIC_STM32F407_5X was updated (changed), with (to) BIGTREE_SKR_PRO_1v1

C:\BIGTREETECH\Marlin-bugfix-2.0.x\buildroot\share\PlatformIO\variants BIGTREE_SKR_PRO_1v1\PeripheralPins.c

I have not found any other issues, printer runs fine except for these pins used for RGB LED.

My Configurations

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

working PeripheralPins.c PeripheralPins.zip

Steps to Reproduce

  1. Compile Firmware Marlin-2.0.x for BIGTREE_SKR_PRO
  2. Issue M150 B255 from Pronterface or from Display LED Menu

Expected behavior: Blue LED Light coming on (Pin PF7) Actual behavior: [What actually happens] Green LED comes on (Pin PF8)

EDIT: 12-9-2019 Temporary Fix

Replacing PeripheralPins.c from C:\BIGTREETECH\Marlin-2.0.x\buildroot\share\PlatformIO\variants\BIGTREE_SKR_PRO_1v1 with PeripheralPins.c from Marlin-bugfix-2.0.x "2019-11-10"

C:\BIGTREETECH\Working Mega CoreXY\newer\Marlin-bugfix-2.0.x\buildroot\share\PlatformIO\variants\BIGTREE_GENERIC_STM32F407_5X

Everything works that I tested. Board BigTreeTech SKR Pro 1.1 Firmware: Latest Marlin-2.0.x with only file above changed (PeripheralPins.c) BigtreeTech TMC 5160 1.2 on X, Y, Z LV8729 on E0 BLtouch 3.0 ( on BLTouch 4 pin header) VCC, PA1, GND , PA2 RGB LED on the pins :

define RGB_LED_R_PIN PF9

define RGB_LED_G_PIN PF8

define RGB_LED_B_PIN PF7

Z-auto align (using 3 steppers) Auto bed level I2C eeprom Module on 4 pin I2C header PB7 (SCA) PB6 (SCL) GND VCC Hotend fans come on at and above 50C and go off below 50C Printing test Cube worked fine Auto Power on/off PE10 X, Endstop PB10 Y Endstop PE12 Filament Runout Sensor PE15

Something in latest file PeripheralPins.c , causing pins mixed and others not working . swapping PeripheralPins.c from older version, most likely not a correct procedure, but got me going.

NOTE: for Click to resume... Issue

also another old known not fixed issue, thing you will most likely need to do if your using the RGB is comment out some lines in "queue.cpp" C:\BIGTREETECH\Marlin-2.0.x\Marlin\src\gcode\queue.cpp around line 537 else { SERIAL_ECHOLNPGM(MSG_FILE_PRINTED);

if ENABLED(PRINTER_EVENT_LEDS)

printerEventLEDs.onPrintCompleted(); // #if HAS_RESUME_CONTINUE // inject_P(PSTR("M0 S" // #if HAS_LCD_MENU // "1800" // #else // "60" // #endif // )); // #endif

endif // PRINTER_EVENT_LEDS

} } else if (n == -1) SERIAL_ERROR_MSG(MSG_SD_ERR_READ); so your printing does not pause at last few lines when the RGB goes to green signalling your finished . https://github.com/MarlinFirmware/Marlin/issues/15054... https://youtu.be/ipmvCMhUBXc

arminth commented 4 years ago

Thanks a lot! I will try this now because I was struggeling with the exact same behaviour!

Will report!

arminth commented 4 years ago

And I can confirm: YOU ARE RIGHT!! Iwas already thinking I am stoo stupid and have to give back my enigineering degree! Finally I can use my cheapo LIDL LED strip on my printer! Thx a lot - I hope somone fixes this ASAP in the bugfix version!

Chears Armin

boelle commented 4 years ago

@carl1961 is the issue still the same with all the updates in the last 15 days?

boelle commented 4 years ago

btw, who can confirm there is an issue? use the same configs as OP and the same hardware if possible

carl1961 commented 4 years ago

soon as I get home, I will check for you.

carl1961 commented 4 years ago

@boelle New Marlin 2.0.1 Update did not fix this issue, because the (PeripheralPins.c) file or the same. (Identical) but un-commenting Lines: 188-191 in (Marlin 2.0.1 Update) Marlin-2.0.x\buildroot\share\PlatformIO\variants\BIGTREE_SKR_PRO_1v1\PeripheralPins.c fixed this issue. Uncomment these

boelle commented 4 years ago

@thinkyhead can you cook up a fix from the above post?

viper93458 commented 4 years ago

Confirmed to fix the generic RGB string LEDs for me as well on the SKR pro. If I used the PC9 PWM pin, then the LED channel/color connected to that PIN would work, but none of the others would. I tried various pins and pin definitions in the lines below:

define RGB_LED_R_PIN xxx

define RGB_LED_G_PIN xxx

define RGB_LED_B_PIN xxx

and ultimately settled on PF9, PF8 and PF7 like the OP did since it was mentioned that those pins did indeed work a while back. I tried other pins just for experimentation.

I hope that uncommenting those lines doesn't break anything else that @LinoBarreca has been working on for the SKR Pro board!

-William

carl1961 commented 4 years ago

Confirmed to fix the generic RGB string LEDs for me as well on the SKR pro. If I used the PC9 PWM pin, then the LED channel/color connected to that PIN would work, but none of the others would. I tried various pins and pin definitions in the lines below:

define RGB_LED_R_PIN xxx

define RGB_LED_G_PIN xxx

define RGB_LED_B_PIN xxx

and ultimately settled on PF9, PF8 and PF7 like the OP did since it was mentioned that those pins did indeed work a while back. I tried other pins just for experimentation.

I hope that uncommenting those lines doesn't break anything else that @LinoBarreca has been working on for the SKR Pro board!

-William

looks to be just timers for those 4 pins that is effected.

LinoBarreca commented 4 years ago

@boelle this is duplicate with the last one we were talking on.

LinoBarreca commented 4 years ago

@carl1961 those lines MUST be commented.

boelle commented 4 years ago

dublicate of #16300, so closing, we only need one open with the same issue

LinoBarreca commented 4 years ago

If you are wondering why it worked before my modifications the answer is simple: you were using the board outside its specifications and BTT (stupidly) allowed you to do it (this was causing other issues with timers) I didn't "break it", I just fixed a bug from BTT making the board work as intended.

SORRY ABOUT THAT

but any software developer can't (and shouldn't) care about out-of-specs usage by the end-user. And the end user must not believe that an out-of-specs usage of something will be for-ever-working.

Anyway....I realize that it could be useful to attach a RGBW strip to digital pins, though, that's why we opened a feature request for it (using SOFT-PWM). Not many boards have so many analog pwm..so it's a logical feature request....to workaround, at the moment, swap RGB and FANS and #define FAN_SOFT_PWM

github-actions[bot] commented 4 years ago

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.