#error "USE_CONTROLLER_FAN requires a CONTROLLER_FAN_PIN. Define in Configuration_adv.h

[USAF-Retired]

I've beat my head for far too long on this printer but I am determined to get it right.  Lets just hope I get it before I turn 80 (70 at this moment, don't want to keep dealing with this for another 10 years.

My problem is this:  whenever I set / #define in Configuration_adv.h   #define USE_CONTROLLER_FAN, I get numerous errors the controller fan needs to have a pin assigned.

I am using the BTT SKR Mini E3 V3.0 main board.  I have verified the correct pin identifier/s for all three fans, or at least I thought I did.

I am attaching my Configuration.h, Configuration_adv.h, the listing of the error for the Terminal tab in Visual Studio Code, along with a schematic of the BTT SKR Mini and   finally an image of the board  and pin id's.

One final note, I am using Marlin Bugfix ver21Xas my VSC environment.  My Marlin configuration file has been compared with at least two other configuration.h files.  I did this because they were used to compile a firmware.bin file where the BLTOUCH and "Z" were functional.

Those other configuration files were from:   Ender3 Pro - SKR Mini e3 v3 - M2.1 - BLTouch-Z    and Ender3 skr mini e3 v3 bltouch

I hope someone is able to look at the files attached and give me a clue on what I am not seeing.

 

Configuration_adv.h Configuration.h Error Log - Terminal Tab BTT E3 SKR MINI V3.0_SCH.pdf

[USAF-Retired]

Good morning John,

 

Thank you sooo much for your reply.  As soon as I glimpsed the first few paragraphs, I knew exactly where I had gone wrong.  I was using the pin identifier off the board schematic, which shows PC7 as pin 39, in addition to others mis-configurations.

Since making the post, I have continued to my quest to this issue, and with the help of an obscure website, picked up on the pins file for: stm32g0\pins_BTT_SKR_MINI_E3_V3_0.h

I had just finished making some modifications to my 2 configurations files when I decided to check the community and saw your reply.  It served very well in verifying the changes I made this morning.  I gen'd a firmware file, flashed the board, and it worked perfectly.

In addition, using your info, I also made the proper pin assignments to my extruder fan, and the part cooling fan.  They too work when the temp is brought up.

Thanks again for your well explained response, can't begin to tell you how much appreciated I am.

And with that thought, onto my next issue, BLTOUCH and why when I enter M119 in terminal, the probe extends and the status shows Triggered.  I believe the probe is supposed to remain non-deployed on that command.  I also have to figure out why when performing a Z-homing step, the probe when touched continues to let the Z-axis to travel.  Forcing the probe to a fully stowed position does not work.  I understand there may be an invert function just like the motors have.  Heading off to check that out.

Unless, you have some insight into this as well?  

 

[USAF-Retired]

Sorry John for the late reply, been dealing with doctors the past couple of days, along with a power outage for several hours, and internet service.  But I am back and with good news.

The BLTOUCH WORKS...

I took your first paragraph and did as you suggested.  I took apart my wiring for the BLTOUCH and triple checked the correct path to the correct pin.  It was fine.  I did have one connection on the board side that looked frayed, so I crimped another to it.  Tested continuity - rewired for two pin connector for the Z-Stop and three at the Z-Probe (was running all five in the Z-Probe) - plugged all three plugs into their respective connectors and ran a test.

Here is where the touch worked, but I am still getting the TRIGGERED indication whenever the M119 is sent.  My thought:  That frayed wire was the culprit, but the trigger status still confounds me.

But I continued with your list to be safe.

PID Tune.  I had run this before and entered the results, but I am sure after trying many Marlin version, configuration release files, those settings were lost.  I re-ran and entered the updated numbers for the hotend and the bed.

Nope, those are the measurements I came up with, but after a second look, the first number is way off.  Took another stab at measuring and entered the updated numbers.

yada yada yada

Most of the other things you suggested had to be flipped on my end.  There was just a couple of them where they were set already.

I just ran another compile and bingo, no errors, .bin file created.

I'm going back to bed for a bit.  Will test the new .bin file, will let you know the outcome later this morning.

And if I had not said it enough, thanks again for all your help, your explanations and reasons behind some settings.

Tremendous Help.

 

 

 

 

[USAF-Retired]

Well, I knew it wasn't going to last.  The probe acting hinky again.  Don't know what changed from the other day, but here is what happens...

Turn printer ON, probe extends twice, then stows.  Orange Light ON.

I always double check the axis motors move in right direction (MENU > MOVEMENT > MOVE ), so I manually move X, Y and Z to verify.

Then to the Homing Section (MENU > MOVEMENT > HOME), where I run the Z home by itself.  When it passes, I do all 3 axis's .  The result for the Z by itself was :  X-axis right to x_stop...  Y-axis to rear to y_stop.  Probe extends, Z-axis lowers, probe touches and stows, z- axis rises a bit and at the top of that small rise, probe extends, z-axis lowers, probe touches then stows.  Cycle ends...

What is it doing now?  X-axis right to x_stop...  Y-axis to rear to y_stop.  Probe DOES NOT extend, z-axis lowers...  but since I am in no mood for a head to table crash, I stop it.

I have double checked all the settings you mentioned, have gone through other weblinks with their recommendations, Not Getting Anywhere...

As for your request above, here are the results.

Send: M280 P0 S10 (MY Comment “Probe Down”)   (Probe Down)
Recv: ok                                      (ok)
[…] 
Send: M119
Recv: Reporting endstop status
Recv: x_min: open                             (open)
Recv: y_min: open                             (open)
Recv: z_min: open                             (open)
                       Also have this entry.. z_probe: TRIGGERED
Recv: ok                                      (ok)
Send: M280 P0 S90 (MY Comment “Probe UP”)     (Probe Up)
Recv: ok                                      (ok)
[…] 
Send: M119 
Recv: Reporting endstop status
Recv: x_min: open                             (open)
Recv: y_min: open                             (open)
Recv: z_min: TRIGGERED                        (TRIGGERED)
                                Added entry.. z_probe: TRIGGERED
Recv: ok                                      (ok)
Send: M280 P0 S120                            Up and Down 10 times 
(MY Comment “Test BLTouch should go up and down”)

Any thoughts???

 

 

[USAF-Retired]

Also, saw the first items you wanted from me, here it is:

Send: G91
Recv: ok         OK
Send: G28 Z0     printhead moves left, z_stop, then center of x-axis
                 bed moves to rear, z_stop, then moves forward.
                 At this point, had to reset, probe fails to deploy, z-axis lowering.
[...]
Recv: ok         Never got to these
Send: G90
Recv: ok

[USAF-Retired]

BINGO, got it back.  Now to save both configuration file an .bin

I also worked out the printhead homing to the center of the bed too.

Now to the next problem which still remains the auto level probing, and not going off the edge.

 

[USAF-Retired]

FYI...   I just re-ran all the g-code commands you listed above and every response you received or response from the probe, is exactly the same I received in the last 5 minutes.  Just thought you'd like to know.

[USAF-Retired]

apparently I changed one of the z_homing functions to include a pin, which was wrong, although it never popped as an error.

anyway, one problem down, a dozen more to go..

Question?  Do you happen to know if personal contact with members is forbidden, against the rules. like email or phone?

[USAF-Retired]

I am going to work on this for another 30 mins or so, then I am hitting the hay.

Want to fix the speed at which the autolevel process sits at.  I did an G29, it probed all the spots fine, just very slow getting done.

[USAF-Retired]

I feel like I am imposing on you with all my questions and assistance, I do hope you are OK with it...

At any rate, I got the G29 probing to speed up a bit, both from point to point as well as the probe up and down.

But there is one thing wrong with the process.  When it starts the probing, which is on a 6x6 grid, all is good till it hits that last row.   The table moves towards the printer front, and when the last row is reached, there is a definite THUD.  It finishes the probing OK, but somewhere I have a table offset, probing offset, or my mind offset, that needs a tweek.

I am attaching updated configuration files for you.

I am going to continue with my Problem List, next up:   Load / Unload of filament.  The direction of the motor is fine, but the length is I believe wrong.  Need gto find the filament section and figure out what parameter is used to feed that amount.

I also have a menu item on my controller for PID Autotune.  I can use it instead of g-code from terminal.  But when I tested that function, after about 10 minutes is chimed out with "Process Aborted - Failed".  This was doing a PID on the hotend, the bed autotune worked from start to finish.

 

Configuration (as of 4feb at 0700hrs).h Configuration_adv (as of 4feb at 0700hrs).h

[USAF-Retired]

I am closing this thread - will start new ones for future issues