Printer Model: Rolly Your Own
MCU / Printerboard: MKS Robin V3 & Mellow klippy.log: klippy.log (72.2 KB)
Describe your issue:
I want to test the part cooling fan on two testers that I’ve designed on my own (working fine, but I want to see the different parts working).
I try manually setting the fan using M106 S255 from the (Mainsail) Console as well as using the fan slider in Mainsail (which sends the same command) with the nozzle cool and at 200C but it doesn’t turn on.
When I’m using the MKS Robin V3 board, I set the fan using the statement: [fan] pin: PB1
When I’m using the Mellow FLY-SHT42 toolhead board, I set the fan using the statement: [fan] pin: canFly:PB11
Now, the fan seems to work correctly when a print is in operation but I’m curious as to why I can’t control it manually.
That’s very odd. Perhaps a subtle wiring issue - like the fan actually getting its power from a stepper or heater. I guess you could try enabling steppers and heaters to see what part of a “print” causes the fan to start turning.
Found the problem (which may point to a bug or two) and I have another question.
When I set up the printer with the FLY-SHT42 board, I used an MKS Robin Nano V3 for the movement steppers. The “printer.cfg” file was taken from another printer which also used the MKS Robin Nano V3 as it was a good base for the heated bed and movement steppers.
I thought I had deleted/commented out all the statements for the functions which are used by the FLY-SHT42 but, I had left in the [fan] statement and I put in another [fan] statement in by “confly.cfg” file which was included in the “printer.cfg”. So I had two [fan] statements, one in each of the .cfg files.
First potential bug - shouldn’t two [fan] statements be flagged as an error during Klipper restart, even if they are in separate .cfg files?
Next, I found the two [fan] statements and removed the one in the printer.cfg file (as the one in confly.cfg should have taken precedence) but there was no difference in operation. Out of desperation, I rebooted the rPi and everything started to work correctly (ie fans working correctly and I can set speeds with the M106 command in the console as well as using the Mainsail slider).
Should I need to reset the rPi for this kind of issue? It seems like the original printer.cfg was buffered in the rPi and was never updated.
Now, in my latest testing, I’m getting an ‘Unknown command: “SET_FAN_SPEED”’ in Mainsail as you can see here:
Everything has been updated to the latest level.
The defining statement for the fan is: [heater_fan heatsink_fan] pin: canFly:PB11 max_power: 1.0 fan_speed: 1 kick_start_time: 0 heater: extruder heater_temp: 30.0
Any ideas on this one? I have no idea why the “SET_FAN_SPEED” command is not recognized.
Includes are difficult to handle and some “manufactures”, e.g. RatRig make heavy use of it (for good or worse). Klipper goes through the statements sequentially and the last one to be processed takes precedence.
Note that this is true for exactly the same config sections, e.g. [fan]. If you use a pin twice in different config sections, Klipper will raise an error.
When I look at Klippy.log I only see the latest of the two [fan] statements - this lead me to looking through the two files as the pin wasn’t what I was expecting. What was strange is that the second [fan] statement overwrote the first [fan] statement and doesn’t show up in it’s actual location in the high level .cfg file.
Personally, I consider this to be a bug and not a feature; I’m not sure how often superseding statements are used in .cfg files, but I would think that their appearance creates ambiguity in how the file will be processed that, at very least, should generate a notification to the user. Actually, I consider this worthy of generating an error that requires the user to resolve before they can go further.
Can you answer why I had to restart the rPi to clear this issue?
Thank you for pointing out the mistake in the SET_FAN_SPEED and its need for `[fan_generic]’ my excuse for missing that was that it was late and I was trying one last thing to see if I had resolved all my questions.
Seems unusual. I’m quite sure that a sudo service klipper restart potentially followed by a FIRMWARE_RESTART would have had the same effect.
WRT to the include issue: I’m not a big fan of them as they exactly create such issues if not done carefully. In my opinion not every bug a user creates can or should be caught in the software. This will just cause a maintenance burden for the developer and potentially also limits deliberate choices.
Just take a look at the include hell RatRig has created: Personally I think that leads to a Klipper system a regular user can no longer maintain.
It was RatRig which lead me to ask about standards for the printer.cfg and include files a few weeks ago.
I added a separate .cfg for the FLY-SHT because I felt it would be cleaner to have a separate .cfg for each separate intelligent board with a primary (the Robin Nano) that forms the printer.cfg and the secondary (the FLY-SHT). Next, I listed the features the FLY-SHT would provide and removed/commented them out from the Robin Nano based printer.cfg - with one error. Looking back, I’d still argue that this was the right way to do it.
What is your criteria for deciding which user bugs should be caught in software? The problem here is a classic “It’s impossible to create a fool proof system as fools are too ingenious” (with me being the fool). I’ve been in the situation of supporting users and having to prioritize which user problems are to be caught in software and it’s a hard decision to make.
I’ve found that the problem with saying that you have an opinion that not all user bugs should be caught in software is that you will immediately get asked what is your criteria for deciding which bugs should be caught in software?
