search

classicrocker883 / MRiscoCProUI

This is optimized firmware for Voxelab Aquila & Ender3 V2/S1 3D printers.
https://classicrocker883.github.io/
Other
82 stars 17 forks source link

Add advanced misc fans menu (DWIN) + G-Codes #125

Open wlkmanist opened 5 months ago

wlkmanist commented 5 months ago

Description

I added features that I can test someway, we can add more variables. Tested (except RU locale), works fine. Voxelab Aquila GD32F103.

Requirements

DWIN LCD Display. Controllable fans hw configuration (2-pin fans connected someway to the microcontroller, optional).

Benefits

More controls. Totally silent 3d printer with controllable parameters via display and g-code. We can change any misc cooling parts and really fine tune them without recompilation.

Configuration

See the code. What added, in short (all of that optional):

Also affects:

G-Code

Issues

Controller fan works for me strange way. Works only 0-127 range (remap to 0-255 is existing in code). >127 it is full speed (with soft pwm value 2) or decreasing to zero (128-255) actual speed (with soft pwm 7 + dither). Added another config parameter to fix that (max pwm). Idk is that a base marlin code or just my specific hardware issue. It is 0-255 range for user in the interface anyway (mapping value to the real pwm value).

We need to test this with another pins (I used BLTouch pins) and with soft pwm = 0, disabled dither. But again, issue can be fixed by user using config or just via display settings or G-code.

Photos

image image image

I made it that way on my stock Voxelab Aquila board: (Custom adapter with just 2x ao3400 smd N-channel mosfets connected to BLTouch pins with some resistors (200ohm gate->pins, 100k gate->gnd) and 24v hook (to stock fan connectors on board). Gave me 2 controllable fans. Code should work with any other solutions.)

IMG_20240330_074751 IMG_20240330_074802 MVIMG_20240330_081103

classicrocker883 commented 5 months ago

this is a very thought out PR, have you also made one over @ MarlinFirmware?

so a few things if you can help me understand...
is the hw required to replace BL-Touch bed probe? so auto bed leveling cannot be used? or are there other options to make this work?

and how does this work? im not familiar with it. so the fan speed changes based on temperature? and what fans exactly? part cooling fan and hotend fan, both? seperately or at same time?

I'd like to make a few suggestions, like instead of adding seperate files under src/feature, merge them into controllerfan.cpp/.h. same for under src/gcode/feature/controllerfan, to group M711/M712.cpp with M710.cpp.
or you can put them all in one file and call it M710-M712.cpp

this way, settings.cpp doesnt have to be changed and it will fall under controllerFan_settings you can incorporate it within class ControllerFan and struct, or make Kickstart and Autofans a subclass of it.

what do you think?

wlkmanist commented 5 months ago

this is a very thought out PR, have you also made one over @ MarlinFirmware?

No. I need to check if it uses any ProUI functions.

so a few things if you can help me understand... is the hw required to replace BL-Touch bed probe? so auto bed leveling cannot be used? or are there other options to make this work?

Any available pins can be used if the board have not controllable fan ports without modification (boards like a creality 4.2.2 just have extruder fan connected to 24v and controller fan in parallel with nozzle fan. BTT SKR boards, as I know, have controllable fan ports). BL-Touch can be used (I just made a modular solution for that connector). You can set pins in config or xxx_pins.h. I was not changed any Marlin pins code, it is work as before.

and how does this work? im not familiar with it. so the fan speed changes based on temperature? and what fans exactly? part cooling fan and hotend fan, both? seperately or at same time?

I am added ~3 independed features: Auto fans (extruder fan (that on coldend), heated chamber fan, laser cooling) just have now user controlled variable to set a temp threshold. Above that threshold specified fan turns on (that behavor existed before and setup was only via config). For example, nozzle > 50°, radiator fan enables, below that threshold it disables. Controller fan logic already in Marlin, I am just added a menu to the dwin lcd. For now it functions very simple: steppers enabled - then fan(s) turned on, steppers disabled - fan(s) turns off after specified timeout. Thats auto mode. With manual mode you can set a static fan speed. Kickstart options was implemented in Marlin, but only with 2 macroses and setup only via config. I added variables, menu, enable/disable boolean and so on. Kickstart works for all fans (and laser) that Marlin defines like a fan. It helps starting any fan at lower speeds.

I'd like to make a few suggestions, like instead of adding seperate files under src/feature, merge them into controllerfan.cpp/.h. same for under src/gcode/feature/controllerfan, to group M711/M712.cpp with M710.cpp. or you can put them all in one file and call it M710-M712.cpp

this way, settings.cpp doesnt have to be changed and it will fall under controllerFan_settings you can incorporate it within class ControllerFan and struct, or make Kickstart and Autofans a subclass of it.

Maybe, but that features are really independend, doing different things and can work without each other and with different hw build. G-code cpp files may be combined, I think, but not the others as it will be more difficult to understand the code. But may be I am wrong. I will look at the code later.

what do you think?

Overall, that code works for me around three weeks and made my printer really comfortable without any disadvantages. Also code may be near to complete disabled via config. I will continue adding more functionals as this, but now it is usable and stable as I can test.

wlkmanist commented 5 months ago

this is a very thought out PR, have you also made one over @ MarlinFirmware?

No, I can't. There is some different code (at least in dwin.cpp), and I can't test it after merging this. But it can be ported someway.

and how does this work? You can try Kickstart feature even with stock board without any hw modification, how it feels and how it works.

This PR is ready to merge if we don't need even more controllable Auto Fans now, that will require more memory if that features is enabled (I will do that later with more free time).

I am thinking about nozzle fan cooldown speed + temp threshold feature (will be useful when used 3d printed cooling shroud near nozzle, prevents melting it) that will override minimum (if min = 0) speed while hotend above temp threshold but heater is disabled.

I can also add Auto Fans speed variables that will work instead of EXTRUDER_AUTO_FAN_SPEED, CHAMBER_AUTO_FAN_SPEED and COOLER_AUTO_FAN_SPEED if AUTO_FAN_EDITABLE is enabled.

What do you think about this?

this way, settings.cpp doesnt have to be changed and it will fall under controllerFan_settings

Is it necessary to leave settings.cpp as is? Or you mean that it is better to store settings just in one struct someway?

classicrocker883 commented 5 months ago

I am thinking about nozzle fan cooldown speed + temp threshold feature (will be useful when used 3d printed cooling shroud near nozzle, prevents melting it) that will override minimum (if min = 0) speed while hotend above temp threshold but heater is disabled.

this would be good, while temp is still hot fans still on.
take a look at this code in proui/dwin.cpp

void update_variable() {
    const celsius_t bc = thermalManager.wholeDegBed(),
                    bt = thermalManager.degTargetBed();
    // if bed is near target, heating, or if degrees > 44, ICON indicates hot
    if (thermalManager.degBedNear(bt) || thermalManager.isHeatingBed() || (bc > 44)) {
      DWIN_Draw_Box(1, HMI_data.Background_Color, 9, 416, 20, 20);
      DWINUI::Draw_Icon(ICON_BedTemp, 9, 416);
    }

you can use this as an example, basically, if hotend/bed is heating, or above a certain temp, the ICON changes. you may have noticed this when printing. the ICON's change when hot/cool. you can use similar code for controlling fan speeds if that helps you out.

I can also add Auto Fans speed variables that will work instead of EXTRUDER_AUTO_FAN_SPEED, CHAMBER_AUTO_FAN_SPEED and COOLER_AUTO_FAN_SPEED if AUTO_FAN_EDITABLE is enabled.

so instead of making it one fan speed, it can vary depending on the temperature?

here is what I do not understand, the hotend fan is on all the time, so the board would use PWM to adjust the speed? or how would it work using a PIN? so this works the same way for the nozzle/part cooling fan when printing?

wlkmanist commented 5 months ago

so instead of making it one fan speed, it can vary depending on the temperature?

No, it is 2 states for that fans: on and off. That variables sets speeds for "on" state. Fans enabed after reaching its temperature threshold. This is Marlin behavour, I am not going to change that because variable Auto Fans speeds having only downsides. We always need maximum possible cooling for the extruder radiator fan and probably for laser too. But in some rare hardware build scenarios changing maximum speed may be useful, or maybe for chamber fan (espesially with g-code).

But it would be possible to change semi-dynamically that speeds using any slicer software that would support this gcodes (that feaure is not implemented yet).

here is what I do not understand, the hotend fan is on all the time, so the board would use PWM to adjust the speed?

Hotend fan is on only after hotend thermistor temp is above specified fan threshold, speeds are on and off, non adjustable automatically. PWM works, under the hood for speeds that non 0 and non 255.

or how would it work using a PIN? so this works the same way for the nozzle/part cooling fan when printing?

It can be connected with the same hardware schematic like a nozzle/part cooling fan. PIN allows that fan to be controllable, it controls the mosfet of connected fan circuit, like a nozzle fan. You specify the pins corresponding your connection/board in config like it was before this PR and magic works.

classicrocker883 commented 5 months ago

I have yet to fully look through this PR. I would like to make a couple changes. the thing is this is not for the average user because of the hardware modifications needed, right?

I see you have a jumper wire connected to the driver for E stepper motor and DIO pin. is that so you can enable UART? or is that also needed for the fans

wlkmanist commented 5 months ago

the thing is this is not for the average user because of the hardware modifications needed, right?

For some boards modifications don't needed. For stock Aquila and Creality boards - yes. But I don't modified my board for fans, I just made an adapter that connects to my board. It is not as hard as connecting BLTouch to the board.

I see you have a jumper wire connected to the driver for E stepper motor and DIO pin. is that so you can enable UART? or is that also needed for the fans

It is UART for E driver. Now I made UART for all drivers: MVIMG_20240420_033211

For fans I also made custom pcb, that not tested yet. It is much more complex than DIY solution, but should work pretty much the same. Connects to debug pins: IMG_20240506_212004_568

wlkmanist commented 5 months ago

I would like to make a couple changes.

What kind of changes?

classicrocker883 commented 4 months ago

the changes I'd make is to combine the features, like autofans.cpp, M711.cpp with controllerfan. so instead of having its own file and folder. I would leave the Gcode files, but put them in the same folder as M710.cpp