Option 'pin' is not valid in section 'heater_bed'

General Discussion
1

Basic Information:

Printer Model: Creality Ender 6
MCU / Printerboard:BTT Manta M8P with CB1
klippy.log
klippy(5).log (22.0 KB)

Fill out above information and in all cases attach your klippy.log file. Pasting your printer.cfg is not needed
Be sure to check our Knowledge Base and in particular this and this post

Describe your issue:

I have been chasing my tail here with the Printer.cfg file. I have had several issues which I have managed to solve but in solving th issue it seems to create another.
Initially I had issues with inverted axes (corexy) which with help was solved. The heatbed and hot end were working. Since solving the axis issue the Printer.cfg file no longer likes the pin assigned to the heat bed (PB7). This pin is not directly connected to the heat bed but to an SSR type controller (MOS controlled).
I thought as this doesn’t seem to work there is a spare connector for an additional extruder - I’ll try and use this instead - no luck. It doesnt seem to matter what pin is assigned I get the following really annoying message;

Option 'pin' is not valid in section 'heater_bed'

I have tried uncommenting and using the alternate SSR pin - BED_OUT: PB7 - the same issue.
image

I am new to Klipper and finding this quite a steep learning curve, so any help anyone can offer would be greatly appreciated.
Unfortunately, I somehow think I will be posting again soon :grimacing:

2 
[heater_bed]
heater_pin = PB7
sensor_type = EPCOS 100K B57560G104F
sensor_pin = PA0
max_power = 0.6
min_temp = 0
max_temp = 120
control = pid
pid_kp = 327.11
pid_ki = 19.20
pid_kd = 1393.45
pin = PF6                                # From here
x_offset = 0                             # 
y_offset = 25.0                          #
z_offset = 5                             #
speed = 10.0                             #
samples = 3                              # This seems to come from a Probe/BLtouch section
samples_result = median                  #
sample_retract_dist = 3.0                #
samples_tolerance = 0.006                #
samples_tolerance_retries = 3            # To here

Should maybe look like this:

[heater_bed]
heater_pin = PB7
sensor_type = EPCOS 100K B57560G104F
sensor_pin = PA0
max_power = 0.6
min_temp = 0
max_temp = 120
control = pid
pid_kp = 327.11
pid_ki = 19.20
pid_kd = 1393.45

[probe]
pin = PF6
x_offset = 0
y_offset = 25.0
z_offset = 5
speed = 10.0
samples = 3
samples_result = median
sample_retract_dist = 3.0
samples_tolerance = 0.006
samples_tolerance_retries = 3
1 Like
3

Hi EddyMI3D
Many thanks for the quick response - I was still editing and you had posted - thank you.
My printer.cfg file does look like you suggested, please see excerpt below;

# 	Bed Heater
#####################################################################

[heater_bed]
#SSR Pin - BED_OUT: PB7
heater_pin: PB7
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PA0
##	Adjust Max Power so your heater doesn't warp your bed
max_power: 0.6
min_temp: 0
max_temp: 120
control: pid
pid_Kp: 327.11
pid_Ki: 19.20
pid_Kd: 1393.45

#####################################################################
# 	Probe
#####################################################################

#[probe]
##	Inductive Probe
##	This probe is not used for Z height, only Quad Gantry Leveling
##  NPN and PNP proximity switch types can be set by jumper
pin: PF6
x_offset: 0
y_offset: 25.0
z_offset: 5
speed: 10.0
samples: 3
samples_result: median
sample_retract_dist: 3.0
samples_tolerance: 0.006
samples_tolerance_retries: 3
4

The hash (#) has to be removed here: It leads in a remark

#[probe]
5

Well, thats fixed that - thank you,
I now have a duplicate chip name ‘probe’ but I will look further into this.
I was hoping to try and get things set up in stages to try and make any fault finding easier. Thats why I had left the ‘probe’ commented.
In my limited understanding I never dreamt this would affect the heat bed?
EDIT
Lesson learnt - delete what I dont need - don’t just comment it out!!
Thanks again - very much appreciated, I am now connected to the dashborad again, so I can start setting things up :grinning:

1 Like
6

You can comment out but do it properly.
A statement in […] is a new configuration block. This means everything below this belongs to it until the next […] is encountered.
So if you have

[bla]
   I_belong_to_bla_1
   I_belong_to_bla_2
   I_belong_to_bla_3

[blubb]
   I_belong_to_blubb_1
   I_belong_to_blubb_2
   I_belong_to_blubb_3

Then you need to:

[bla]
   I_belong_to_bla_1
   I_belong_to_bla_2
   I_belong_to_bla_3

#[blubb]
#   I_belong_to_blubb_1
#   I_belong_to_blubb_2
#   I_belong_to_blubb_3

otherwise you effectively create:

[bla]
   I_belong_to_bla_1
   I_belong_to_bla_2
   I_belong_to_bla_3
   I_belong_to_blubb_1
   I_belong_to_blubb_2
   I_belong_to_blubb_3

which, of course, will error our.

2 Likes
7

Many thanks for your explanation- it makes more sense now

This email was sent using recycled pixels and sustainable bytes