search

jetty840 / Sailfish-MightyBoardFirmware

Sailfish, faster than a Marlin
117 stars 76 forks source link

Fan Speed #193

Open Rockevzel opened 6 years ago

Rockevzel commented 6 years ago 
Hi there,

I hope, I am right here - I've never been on Github before. Please have mercy mith me :-D

I can't find out: Does this Firmware already include the Fan-Speed Control for the 'Extra'-Fan? Or is it only: On/Off ?

If not: Is there a way to programming the speedcontrol? Many ppl - including me, are waiting for the solution :-D

Thank you :)

dnewman-polar3d commented 6 years ago

X3G does not permit a fan speed. It's just ON or OFF. Some people have modified their gcode to X3G translator AND Sailfish to allow for a variable fan speed. But there's no plans to incorporate that into Sailfish. Well, at least not by me as I no longer have to to test and make new releases.

The current Sailfish 7.8 code base has code to allow you to set via the LCD screen a fan speed (0 - 100%). That speed will then be used when the fan is turned ON via a print. So, it's a "static" fan speed as opposed to a fan speed which can change during the course of a print.

Rockevzel commented 6 years ago

Ahh I see.. do you know who did this translator and the modified sailfish ?

I bring you my printer for testing :-D the whole community hopes for an update :-D

Am 12.02.2018 9:43 nachm. schrieb "dnewman-polar3d" < notifications@github.com>:

X3G does not permit a fan speed. It's just ON or OFF. Some people have modified their gcode to X3G translator AND Sailfish to allow for a variable fan speed. But there's no plans to incorporate that into Sailfish. Well, at least not by me as I no longer have to to test and make new releases.

The current Sailfish 7.8 code base has code to allow you to set via the LCD screen a fan speed (0 - 100%). That speed will then be used when the fan is turned ON via a print. So, it's a "static" fan speed as opposed to a fan speed which can change during the course of a print.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jetty840/Sailfish-MightyBoardFirmware/issues/193#issuecomment-365055485, or mute the thread https://github.com/notifications/unsubscribe-auth/Ait3BKPm2Q6kCoYiL9a1yLxRWq2Jw8YEks5tUKJhgaJpZM4SB60N .

dnewman-polar3d commented 6 years ago

Look at outstanding pull requests on this repository.

DrLex0 commented 6 years ago

I have wanted true variable fan speed ever since bumping into the disappointment of noticing that the EXTRA control is only a binary toggle. I recently cooked up my own solution. It is somewhat crazy and requires (reversible) hardware modifications to the printer, but it should work with any unmodified Sailfish build.

I'm using the buzzer on the MightyBoard as a kind of modem connection to send commands to a Raspberry Pi which acts as the PWM controller. This works surprisingly well, and allows advanced features like giving the fan an extra kick to improve responsiveness or starting at extremely low speeds. (1% duty cycle? No problem.) Of course manual override is also possible, because the daemon that handles PWM is actually a web server. Because slicers don't output fan speeds for Sailfish, a post-processing script takes RepRap-style G-code with M106/M107 fan speed commands as input, and outputs Sailfish-compatible code with the speed commands converted to beep sequences. This script also optimizes the timings for the fan. From experiments, I have found that M300 commands are played exactly where they appear in the code, unlike the M126/M127 commands which toggle the EXTRA output at unpredictable moments. The timings of the beeps also prove accurate while a print is in steady-state. If you're afraid this makes the printer annoyingly noisy, the ‘modem’ sequences consist of three short blips at the highest frequencies the buzzer can play, which makes them rather unobtrusive compared to typical printer noises.

There is only annoying thing, being the tune Sailfish plays when the heaters reach their target temperature. If this happens right in the middle of a beep sequence, it will not be detected. This risk is low, but it could ruin a print in extreme cases. I'll probably make a feature request to have this tune toggle-able, if only because it already annoyed me before I thought of this hack. From what I've seen, there are plenty of unused bytes in the EEPROM reserved for buzzer settings.

I think offloading fan control to an external controller is way better a solution than trying to implement it all in the firmware. Hence if any effort would be spent on this, I would rather see a better way to send commands to an external device than my hack of sending signals across an air gap.