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.

Comments

  • I know what you mean. In fact only fan 1 is supposed to be a cooling fan and Fan 2 should be used for other uses. That is also why we have only one field for fan with exact timings.

    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.
  • Ok. Then I will make the ugly solution myself ;) and wait for stable release of the V2 firmware.
  • I have also built a printer with dual x carriages and have the same problem.  If you have a solution, would you mind sharing it?
  • V2 has solved it meanwhile. If you use M106/M107 without P it is mapped to the active extruder.
  • I would like to try v2 firmware, but I'm waiting for support for the 2004 reprapdiscount display. I had been unable to get a graphic display working with my ramps-fd. Maybe I should just swap in an 8 bit board...
  • Currently only RADDS/Graphic display is tested and configured in V2. See in boards/radds.j near end you have

    // Controller related default pins

    #ifndef CUSTOM_CONTROLLER_PINS
    #if FEATURE_CONTROLLER == CONTROLLER_SPARKLCD

    #define UI_DISPLAY_RS_PIN 25
    #define UI_DISPLAY_RW_PIN -1
    #define UI_DISPLAY_ENABLE_PIN 27
    #define UI_DISPLAY_D4_PIN 29
    #define UI_DISPLAY_D5_PIN -1
    #define UI_ENCODER_A 35
    #define UI_ENCODER_B 33
    #define UI_ENCODER_CLICK 37
    #define UI_RESET_PIN -1
    #define UI_BACK_PIN -1

    #elif FEATURE_CONTROLLER == CONTROLLER_SPARKLCD_ADAPTER || FEATURE_CONTROLLER == CONTROLLER_ORCABOTXXLPRO2

    #define UI_DISPLAY_RS_PIN 44
    #define UI_DISPLAY_RW_PIN -1
    #define UI_DISPLAY_ENABLE_PIN 45
    #define UI_DISPLAY_D4_PIN 46
    #define UI_DISPLAY_D5_PIN -1
    #define UI_ENCODER_A 50
    #define UI_ENCODER_B 52
    #define UI_ENCODER_CLICK 48
    #define UI_RESET_PIN -1
    #define UI_BACK_PIN -1


    // This is for offcial display port usage

    #define BEEPER_PIN 41
    #define UI_DISPLAY_RS_PIN 42
    #define UI_DISPLAY_RW_PIN -1
    #define UI_DISPLAY_ENABLE_PIN 43
    #define UI_DISPLAY_D0_PIN 44
    #define UI_DISPLAY_D1_PIN 45
    #define UI_DISPLAY_D2_PIN 46
    #define UI_DISPLAY_D3_PIN 47
    #define UI_DISPLAY_D4_PIN 44
    #define UI_DISPLAY_D5_PIN 45
    #define UI_DISPLAY_D6_PIN 46
    #define UI_DISPLAY_D7_PIN 47
    #define UI_ENCODER_A 50
    #define UI_ENCODER_B 52
    #define UI_ENCODER_CLICK 48
    #define UI_RESET_PIN -1
    #define UI_BACK_PIN 71


    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.
  • I appreciate your response, however I have been unable to get a graphic display working with any firmware.  All I get is garbage on the display.  I believe it to be a hardware problem, possibly with the level shifter on the display adapter board.  I've given up on trying to make the RAMPS-FD work with a graphic display, but 2004 displays work, which I think is kind of weird that one type works and not the other.  Last night I attempted to compile V2 for a Rumba board, using the Orcabot XXL example config and got the following errors

    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?
  • V2 does currently have no support for 8 bit hardware. Need to write the drivers for hat.
  • Thank you for your support and for all your hard work.  
Sign In or Register to comment.