Dual X carriage printer - cooling fan
Hi,
I am working on my construction of a dual X carriage 3D printer. I have some thoughts about cooling fan behavior.
I have configured the Repetier firmware to use two print cooling fans - "fan" (i will call it fan 1) and "fan 2". I want to have fan 1 on 1st printhead and fan 2 on the second one. Unfortunately, when i switch printhead with "T" command fan control always goes to fan 1. So when the 2nd printhead is working its print cooling fan is off and all commands goes to the 1st one which makes no practical sense.
My idea is to change behavior of "M106" and "M107" commands to the following:
- When 1st carriage is active and no "P" is specified, the command affects fan 1
- When 2nd carriage is active and no "P" is specified, the command affects fan 2
- When "P" is specified, then the command affects the specified fan
I also propose the tool change "T" command behavior to do the following:
- Set fan speed on the next printhead to the speed of the current active fan
- Turn off fan on the current printhead
- Set active fan on the next printhead as active
I don't know how other slicing software deals with print cooling fans but Slic3r cannot control two fans. It just generates "M106" and "M107" without the "P" parameter.
I have also noticed one more thing when looking through the firmware code: Fan control commands for fan 1 are queued along with moves but commands for fan 2 take effect immediately. Maybe commands for both fans should be queued ? This would make more sense...
I am going to modify the firmware and change fan control behavior anyway, but first i want to post these ideas here. If they get accepted by the community i can make a pull request later.
I am working on my construction of a dual X carriage 3D printer. I have some thoughts about cooling fan behavior.
I have configured the Repetier firmware to use two print cooling fans - "fan" (i will call it fan 1) and "fan 2". I want to have fan 1 on 1st printhead and fan 2 on the second one. Unfortunately, when i switch printhead with "T" command fan control always goes to fan 1. So when the 2nd printhead is working its print cooling fan is off and all commands goes to the 1st one which makes no practical sense.
My idea is to change behavior of "M106" and "M107" commands to the following:
- When 1st carriage is active and no "P" is specified, the command affects fan 1
- When 2nd carriage is active and no "P" is specified, the command affects fan 2
- When "P" is specified, then the command affects the specified fan
I also propose the tool change "T" command behavior to do the following:
- Set fan speed on the next printhead to the speed of the current active fan
- Turn off fan on the current printhead
- Set active fan on the next printhead as active
I don't know how other slicing software deals with print cooling fans but Slic3r cannot control two fans. It just generates "M106" and "M107" without the "P" parameter.
I have also noticed one more thing when looking through the firmware code: Fan control commands for fan 1 are queued along with moves but commands for fan 2 take effect immediately. Maybe commands for both fans should be queued ? This would make more sense...
I am going to modify the firmware and change fan control behavior anyway, but first i want to post these ideas here. If they get accepted by the community i can make a pull request later.
Comments
So a better solution would be to have a pin definition for each extruder for the filament cooling fan and P0/no P should always address the associated fan mapped for the extruder. With the current design this would require some ugly solutions. In the next big release V2 the configuration is much more modular and should give a better solution for this problem. It already supports unlimited pwm outputs and with a extra class it would be easy to solve this problem to multiplex signals to active extruder, so i have planned this in V2. For V1 we only plan bug fixes and small improvements.
So in contrast to V1 we now move the display pin assignments to the boards. I still have to move them from DisplayList.h in V1 to the boards and merge identical pins into groups. But you can easily do that for your board and it should work.
io_analog.h
'analogEnabled' was not declared in this scope (36,5)
tools.h
statement-expressions are not allowed outside functions nor in template-argument lists (49,121)
statement-expressions are not allowed outside functions nor in template-argument lists (49,140)
Are AVR boards supported at this time?