SOLVED Sequence definition fan pins
Alexwalex last edited by
Hi! I use board Duet2WiFi and REPRAP firmware 3.0 release. If i write in file config.g :
M950 F0 C"fan0" Q100 M950 F1 C"fan1" Q100 M950 F2 C"fan2" Q100 M106 P0 S0 H-1 M106 P1 S0 H-1 M106 P2 S0 H-1
all fans work correctly.
But when I change the sequence definition for fan pins to any other, then some fans not working.
M950 F0 C"fan1" Q100 M950 F1 C"fan0" Q100 M950 F2 C"fan2" Q100 M106 P0 S0 H-1 M106 P1 S0 H-1 M106 P2 S0 H-1
fan0 not working.
Command M106 P0 says: "Error: Fan number 0 not found"
That's because on Duet 2 we provide a default fan mapping, which maps the fan pins as they are in RRF2. So in your second sequence, fan1 is pre-assigned to F1 so it isn't available to use for F0. You could use M950 F1 C"nil" first to release it.
On Duet 3 we don't provide any default fan mapping. Maybe we should do the same for RRF3 on Duet 2?
Danal last edited by
Maybe we should do the same for RRF3 on Duet 2?
Just an opinion: One of the things I really like about RRF3 is that there are no 'magic' names or 'magically assigned' things or etc, etc. So, my vote is to not pre-assign anything, ever, for consistency.
Thanks for your opinion. Does anyone else have an opinion about this?
jay_s_uk last edited by
A Former User last edited by
I would differentiate between having something borderline implicitly defined and leaving the configuration tool and community to adapt a standard convention for the most common use cases while leaving the canvas blank for the (far) out there stuff, and the less far out there stuff like remaipping if something breaks.
infiniteloop last edited by
Does anyone else have an opinion about this?
Sure: don’t mess up a simple, elegant rule with unnecessary exceptions. It’s better to write some additional lines of code than always having to keep special cases in mind.
The configurator should take care of the initial setup. Given the diversity of todays printers, the board should not assume something like a "most common" assignment.