FAN needs support

[BackwardEcho]

@aegean-odyssey , Matthew Upp, whom I'm sure you know runs the Gigdigit store, has populated the empty FAN header on this recent batch of quiet boards. I just got my board in the mail and was pleasantly surprised by it. Did you see the post, did he contact you at all on it, or is this the first time you are hearing about this?

the post in question

[aegean-odyssey]

No, hadn't heard. I'm curious as to what I/O pin might control the FAN (if any). If it can be controlled by the CPU, then I think it's worthwhile to incorporate it into the firmware somehow.

[BackwardEcho]

I am willing to help out as much as I can in order to find out which I/O it is. If anything, components in spaces R41, R42, and Q3 were installed so maybe if you were to find what I/O uses R1, R2, and Q2, you might find the missing link nearby.

...though I have no real idea how it all works....

[aegean-odyssey]

Glancing at a photo of the circuit board, I think the circuit is a typical mosfet switch. One of the resistor traces should make its way back to the cpu where the dot on the CPU marks pin# 1. Pretty much all of the I/O pins are in use, though, I believe.

Digital I/O

CPU Pinout

[BackwardEcho]

"In use" as in every pin is attached to something or as in you know it activates something? Because we can try all 48 pins the hard way if you want just to find it.

…

On Tue, Jun 1, 2021, 6:19 PM Demitrios V. ***@***.***> wrote: Glancing at a photo of the circuit board, I *think* the circuit is a typical mosfet switch. One of the resistor traces should make its way back to the cpu where the dot on the CPU marks pin# 1. Pretty much all of the I/O pins are in use, though, I believe. Digital I/O [image: p-channel_mosfet] <https://user-images.githubusercontent.com/57586704/120407518-4db25c00-c31b-11eb-8add-c1d3085d1b1b.png> CPU Pinout [image: cpu] <https://user-images.githubusercontent.com/57586704/120408523-31afba00-c31d-11eb-86a0-1281035f1db3.png> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#76 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQYJ74WUTUGUI5SBKUFEGB3TQWBKPANCNFSM45NSOFEA> .

[mulcmu]

Looks to me like PA3 is setup to control Q3 as low-side switch. PA2 & PA3 are connected to the unused serial pads by the MCU, so PA3 should be "free" to repurpose without impacting anything else.

Here was another picture of the PCB area in question.

@BackwardEcho Could you post a close up picture of your installed Q3? Is it installed upside down?

[BackwardEcho]

@mulcmu here is a photo Matthew took when he was talking about it. It is leagues better than what my phone can take.

[BackwardEcho]

I guess here is the photo for Github to have for itself.

[aegean-odyssey]

I think this can work: PA3 allows for a PWM output (still checking on this) as an alternate function for the pin, so it shouldn't be too difficult or too much code to add another fan (as P1) to g-codes, M106 and M107. see M106

Does this sound like a reasonable way to use the output? Is there another approach that is prefered?

[BackwardEcho]

That seems fine to me. Is P1 the normal "part cooling" index for M106? or is there another designation it goes by on other builds of marlin in normal printers?

[BackwardEcho]

Installed a y splitter connected to that new port in anticipation.

[aegean-odyssey]

Yes, Marlin G/M-code docs for M106 and M107 specify that the default fan is always the part cooling fan, but the documentation is vague about any particular numbering scheme for the fans. So, for the mpmd_marlin_1.1.x firmware, here's the plan for M106, M107:

• option P0 will always select the orginal fan output;
• option P1 will always select the additional fan output;
• in the -ACfan variant of the firmware, P0 will be selected when no P option is supplied;
• in the -PCfan variant of the firmware, P1 will be selected when no P option is supplied;
• in both variants, the original fan output (P0) will use the -ACfan's "automatic" mode.

I think this works. The original behavior of the -ACfan firmware doesn't change, but P1 will be supported. And in the -PCfan firmware, the behavior will match a typical two-fan setup.

I'll get to work on it. Please point out any glaring omissions.

[BackwardEcho]

What about those that don't have the new fan output? I feel like the -ACfan variant should be the only version to get this new code as it wont affect anyone's current set up including mods. It was only the recent batch of boards that actually got this new header installed so I don't think many people will have it. If I understand your plan, changing how the outputs are selected in the -PCfan variant to use the new output, rather than the original output, would force the user to have the board with the new output installed. I guess assume those that use the -PCfan variant have only one output they want to control while those with the -ACfan variant don't care either way.

[aegean-odyssey]

I see your point. My approach does seem overly complicated. Rather than try to accommodate some hypothetical 2-fan configurations, perhaps it's better to just add the additional fan output as explicitly controlled P1 with M106, M107. The additional fan ouput would work the same way in both -ACfan and -PCfan variants of the firmware and original behavior is preserved for both. I'll get started on the groundwork code changes while we ponder this some more.

[BackwardEcho]

So the original fan output will be labeled explicitly as P0 and the new output will be explicitly P1. The only difference will be that the -ACfan will have P0 control itself while the -PCfan will have P0 be controlled by the user. So the choice would be "1 automatic fan and 1 controllable fan" or "2 controllable fans".

Correct?

[aegean-odyssey]

Yes, correct. Recall, though, that in the current -ACfan firmware, the single fan output (P0) can be controlled or automatic (setting the speed to zero enables the automatic mode). The added P1 fan output would only be controllable.

I'm hung up on what M106 and M107 use for the default fan output when no P option is supplied. The spec calls for selecting the part cooling fan when the -P option is omitted. The original fan output (P0) in both the -ACfan and -PCfan firmware would now be considered the part cooling fan.

For the -PCfan firmware, I'm thinking that it might be nice to have the added (P1) fan output function as a combination controlled and automatic fan control. With this flexibility, if a g-code file doesn't include an M106 P1 S... command, the P1 fan output would be automatically controlled; the typical approach to cooling a hotend. Using M106 P1 S..., the P1 fan output is PWM controlled; and perhaps suited for some extra type of part cooling application.

Anyway, first step is to get the new fan output working.

[BackwardEcho]

I feel like I'm letting you down by not being able to follow your train of though on this. Sorry >_>

In an attempt to: are you hung up on how to designate the original header for a "hotend" or "part cooling" function since the original fan is both? Why not have P1 copy what the P0 does until explicitly told to do otherwise? Are you able to differentiate between "automatic control" and "user control"? (Like have P0 do it's thing for the hotend alone, but when prompted with a M106 / M107 they both act the same without the P function) Would this do something funny to the boards that don't have this new header by activating an incomplete circuit?

...function as a combination controlled and automatic fan control.

I can't wrap my head around this, though I feel like I might have touched on it in my questioning above.

Anyway, first step is to get the new fan output working.

Let me know when you have a test build ready. I might be the only active one here with an applicable board.

[PurpleHullPeas]

I have not been following this thread intently, but I think it is important to look at the end goals. EDIT: I rethought some of my points in c/d. Here is my part cooling tutorial for anyone interested in relevant hardware mods.

a) Stock Setup (AC Firmware). The fan will automatically turn on after a temperature threshold, but you can definitely override this with gcode commands. So, it is still controllable, but it is not advised to turn it off due to heat creep.

b) Part Cooling Mod (PC Firmware): Hardwire the heatsink fan into the "always on" 12V to avoid heat creep, wire part cooling fans into the PWM connector for control.

c) New PWM Fan Header (PC Firmware). (edited) Same as b, except maybe you also want to control the dimness of some lights or something? Maybe you have different types of part cooling fans on the same printer?

d) New PWM Fan Header (AC Firmware). (edited) You have part cooling fans you wish to control, and you want the heat sink fan to turn on/off before-and-after the print.

So, to me, it makes sense to make the new fan controlled via gcode, like mainline Marlin M106 with the fan indices.

[BackwardEcho]

I agree with Purplehue in that it's a good idea to know what you want before you really go into the changes. I'm thinking it'll make things easier as the changes are made. Not to mention those listed options are more or less what I was hoping for, even if I wasn't able to properly convey it.

[mulcmu]

I'm hung up on what M106 and M107 use for the default fan output when no P option is supplied. The spec calls for selecting the part cooling fan when the -P option is omitted. The original fan output (P0) in both the -ACfan and -PCfan firmware would now be considered the part cooling fan.

I wouldn't get too hung up on this. I think P0 as the default works well. Anyone implementing these changes could swap the fan connections to match the firmware. I assume modern slicers would always output the fan index and not rely on defaults.

[aegean-odyssey]

Thank you all for the comments. I agree that my original draft is too involved for little gain -- the "default" fan should always be P0. I was also trying to accommodate @PurpleHullPeas' nicely laid out use cases, in particular case d (part cooling fan + automatic fan). And since this new fan I/O is currently configured as part of an auxillary serial port, I'd like to code this in a way that preserves the serial port and the myriad of fan options (likely in the form of compile-time switches).

I wasn't too concerned about this type of issue earlier because there was little program space remaining for firmware changes. Building the mpmd_marlin_1.1.x firmware with the latest compiler and libraries though freed up enough space to make it more feasible to customize the firmware for specific applications.

So I think it makes sense to "code in" a flexible configuration to help those who want to customize, but as far as what to include in the -ACfan and -PCfan variants, I'm leaning toward a simple controllable fan designated as P1 for the M106, M107 codes. I'm open to suggestion, though. My only concerns are not to adversely affect the firmware for the stock printer, and not to create something that becomes a support problem.

Thoughts and comments welcomed.

[PurpleHullPeas]

@aegean-odyssey I completely agree. I think the fan header mod is (and will be) so rare that those who do it can just setup their slicer to use P1.

[BackwardEcho]

Is there a way to set a given slicer to use a specific designation for a fan? I thought it would be set to some marlin default. Not like the "if omitted, use this" type of default, but like the "spec marlin has the hotend fan as P0 and part cooling fan as P1, so specify in gcode as such" default.

[PurpleHullPeas]

@BackwardEcho In Cura, you can set "Machine Settings"->"Extruder 1"->"Cooling Fan Number".
Alternatively, you can plug the part cooling fans into the stock P0 cooling fan port and then control the heatsink fan via the new P1 port in your Start/End Gcode.

[BackwardEcho]

@BackwardEcho In Cura, you can set "Machine Settings"->"Extruder 1"->"Cooling Fan Number".
Alternatively, you can plug the part cooling fans into the stock P0 cooling fan port and then control the heatsink fan via the new P1 port in your Start/End Gcode.

Oh sweet, I didn't know that. Thank you. Personally I'll stick with the automated approach.

[BackwardEcho]

For the sake of checking what cura generates with part cooling, I got M106 S255 when that "Cooling Fan Number" was set to the default 0. I got M106 S255 P1 when it was set to 1.

[aegean-odyssey]

I think I've got all of the changes in. It looks though that the Travis-CI (automatic build process) is somehow buggered. Waiting on support to try to sort it out. And I need to do a little testing here before asking for testers that have hardware for a working extra fan output. Thanks for your patience.

[BackwardEcho]

Are you gonna be making all 16 variants in this one run? If it cuts down on how many you need to make, I believe the one I use is the 0001 version.

[aegean-odyssey]

I'm still futzing with the travis-ci builds.

In the meantime: Completely untested, but compiles -- you can find two build runs under the Actions tab of this repository. Run ♯9 is -PCfan, ♯8 is -ACfan. If you are logged in to Github, then in each run you should be able to peruse the "build" log (only the "identify" section is useful) and download the "artifact" -- a zip file that contains the firmware.

If you give the firmware a try and nothing works, don't spend too much time with it -- I really did not test at all. M106 P0|P1 S<speed> and M106 S<speed> should now work, and is a good starting point. Also the PWM control for FAN1 (P1) is separate code (timer15 of the cpu), so even if M106 recognizes P1, I may have not have speed control working yet.

[BackwardEcho]

I was not able to get the fan connected to the new port (P1) working. Granted, I didn't open up the printer to plug it directly in (but I did switch the contacts on one of them just to be sure the current wasn't reversed for some reason), instead relying on my Y splitter that I made and installed. I tested the splitter before and it worked, so if it somehow broke during a print, I will find out later when you have a build you want absolutely tested.

edit: and that was the -ACfan -SM0001 -5Alimit version.

edit 2: same result with the -PCfan variant

[aegean-odyssey]

@BackwardEcho, thanks for giving the 1st round a try.

• Did M106 recognize P0, P1?
• Did the original fan still work (with P missing and P0)?

And to cover all bases, do we know that the hardware works (and that PA3 is the control)? In the photo of the main board, the round pad of J20 should be PA3, the io controlling the extra fan output. With firmware 119r15 (not the test versions of firmware), 5v 3.3v (through a resistor, ~150Ω) on the round pad of J20 should turn on the extra fan output. It's a test, but not all that important as we'll discover the answer as I produce better tested firmware.

Again thanks for testing, and don't spend too much time with it. It's unrealistic to think that I got all things correct on the first, completely untested attempt. I'll try to find the equipment to test the firmware to see if it is generating the expected PWM signal on PA3, and actually shake-out the firmware a bit.

[mulcmu]

I opened up my machine and double checked the schematic I posted above. PA3 goes to the round pin on J20 and to the screw side pad of R41.

I had previously hooked a scope up to PA3 with the 119r15 release firmware installed. There was a very brief pulse at startup. Might be long enough for @BackwardEcho to see a fan shift or LED light up when MPMD is first powered.

[BackwardEcho]

Here are 2 photos of my board with my new phone's macro camera.

Gimme me a minute to edit this on my computer after uploading those photos

Did M106 recognize P0, P1?

I don't know how to tell you if it did or didn't. Inputting M106 P0 S255 into pronterface worked on the stock fan / header while M106 P1 S255 did nothing. I did see that black line labeled Fan(one that line graph depicting target and current temps) show up, but it also showed up for P123 and P343451. I checked my splitter just now as well, it still works

Did the original fan still work (with P missing and P0)?

Yes.

do we know that the hardware works

Matthew Upp : "To test, I activated the hotend fan and then jumped R1 to R41. (Circled in purple)"

@mulcmu, I did not witness any shift in the fans when plugged into the header during startup. Does it need to be the -5Alimit version or will the -10Alimit theoretically work fine? Where would I need to attach the contacts of the LED? I'll see about getting one somehow that doesn't involve shipping from online.

[aegean-odyssey]

Thank you all for the testing assist! It real helps narrow things down, and I think I found the problem: I'd removed a line of (initialization) code that actually enables timer15-ch2's pwm output signal. For some reason yesterday's read of the tech specs led me to deliberately remove the line as not required for timer15 -- but it is and it is now back in the code.

@mulcmu, the firmware initializes all of the io at startup (after it gets control from the boot loader), so the state-change on the signal lines is probably related to the delay before the firmware gets to set the io to a known state. Also, both -5Alimit vs -10limit should work without a problem.

I've built two more test versions, runs ♯10 and ♯11, under the Action tab. Please feel free to test. Hopefully the FAN1 output will be working now.

[BackwardEcho]

Same result :(

[mulcmu]

I soldered wires to the R41 and R42 resistor pads to easily hook up to the scope. I tried builds ♯8 and ♯10 with a scope hooked up. Getting a constant 3.3V. No change in the waveform for M106 P1 S##

[aegean-odyssey]

Sigh. I'll dig into it. Thought I could get away without having to tear into the printer. Silly me.

[mulcmu]

I was able to verify PWM output with scope after some hacks in my fork. Not sure if these changes break other things but proves out the functionality.

https://github.com/mulcmu/mpmd_marlin_1.1.x/actions/runs/1167786560

[aegean-odyssey]

@mulcmu, great to see the output actually work.

Trying to think things through:

Looking at your changes, do you think that the change from |= to = is necessary? Or is it that initializing a CCR2 value for the PWM is what produced the result? (Timer15 should be reset in main.c

I'm inclined to think that setting the CCR2 is what worked, and that somehow it is not being written when a FAN1 speed is set.

But, if this is the case, then I'd expect the output PA3 to be low (not 3.3v) with the ♯10 and ♯11 test firmware (CCR2 = 0); though, maybe the polarity is somehow reversed (a CCR2 value of 25% (64) in your test could be used to deduce the polarity).

If |= to = is the fix, then I'd expect your test firmware to more or less be working -- that is, M106 P1 S<speed> should control the FAN1 speed.

As far as I can tell, the fan speed is actually set in planner.cpp. And if FAN0 is working, then there aren't too many places to look for problems.

Thanks for your help. Your scope is a big help.

[mulcmu]

M106 P1 S<speed> was controlling the FAN1 duty cycle as expected in my test. M106 P1 S63 yields square wave with 24.5% duty cycle. (3.3V 25% of time and 0V remainder.) So polarity seems correct as currently configured.

I had also commented out #if CONFIGURE_FAN1_AND_EXTRA_IO //&& (PWM_A3 > 0) the second check from these lines. (here was dif: mulcmu@d90944e). I didn't see where PWM_A3 was being defined.

EDIT: Looks like PWM_A3 is a typo and should be PWM_PA3 on line 155. This was keeping HAL_tim15_init() from initializing the timer. The |= should be okay as the reset values for all these registers are all zeroed and it avoids changing any of the reserved bits.

[mulcmu]

@BackwardEcho This build has the above fix if you want to give it a test on the modified board. Both fan outputs tested okay on my machine.

[BackwardEcho]

Sorry for the late / early morning reply. I was at work till 10pm my time, then till 4 am I was helping my sister setup a new printer. The last half-hour I took this video. (The file is 65 MB, otherwise I would have posted it here directly.)

I am STOKED. I believe everything worked as intended except for M107 in that it doesn't affect P1, only P0 if P left omitted. But everything else that I can think of at 4:30am worked (including M106 P1 S###)

[aegean-odyssey]

@mulcmu, oh my! You're right! It explains all. (I was bothered -- you're code changes were not materially different -- my latest test version should have worked. But my typo I looked at and didn't see for days... -- good catch.)

@BackwardEcho, I'll look into M107, too. We're getting close to a new release.

The help here has been great. I cannot speak highly enough of your assistance.

[BackwardEcho]

Glad I could help!

[aegean-odyssey]

Ok, I removed PWM_PA8 and PWM_PA3 from the conditional compilation for the PWM code. It was a cumbersome attempt to not lose track of the importance of these symbols; replaced with a good old-fashion comment in HAL_stm32.h that describes the situation.

Are we sure that M107 P0 and M107 P1 do not work? The code is very simple and looks ok to me.

[BackwardEcho]

There is a slight misunderstanding, M107 P0 and M107 P1 did work, but I was under the impression it was supposed to turn everything off the Part Cooling fan if P was omitted.

edit: omitting P turns off the hotend fan

[aegean-odyssey]

According the Marlin G-code docs, M107 (with no P) turns off the part cooling fan. It's implemented to the spec. I think all works. A few tiny changes, and a release is imminent.

Also, what are good part values for the extra fan mod (R41, R42, Q3, and FAN connector)? I'll work up some documentation for the wiki.

[BackwardEcho]

I don't remember off hand but I talked to @PurpleHullPeas about it on FB. I'll check for the comment when I get off work in a while.

Edit: it's nothing confirmed except for the 4A mosfet, but I looked at the images and the resistor's markings match here and there.

[mulcmu]

Here were my best guesses:

FAN: B2B-XH-A through-hole type shrouded header

Resistors look to me like 0603 package size
R42: 10kΩ
R41: 24Ω would match R1 but it is an odd ball value. 100Ω should work fine.

Q3: AO3402 (A29T) (SOT-23 package) mounted upside down!

[BackwardEcho]

I went ahead and @'d Matthew on FB, hopefully we'll get an answer later. I also sent an email via gigdigit and a PM telling him about the upcoming release and suggesting he make some new skus on the store page for an installation service (send your board in) because I think people are gonna want it. Before he told people to contact him via gigdigit to work it out, but adding a sku will make it obvious.

[BackwardEcho]

@aegean-odyssey were you able to get a confirmation regarding the components? I see you added them to the wiki already.

[MatthewUpp]

Apologies for not chiming in sooner. I didn't know this thread existed since I had only been searching the discussions tab to see if a thread for the fan addition was created. After reading the Facebook post and the email from @BackwardEcho, I did some searching and finally found this thread in the issues section.

Anyways, the components that are in the table on the wiki page are pretty much correct. The two resistor values I chose to use are based on the values that the printer manufacturer uses on the M300 and M200 mainboards.
For the MOSFET, if AO3402's are available then that will work. A few boards have AO3042 installed on the new header but others have either AO3434A's or a couple other equivalent MOSFET's. At the time there was very few available at Digi-Key and the few other larger component warehouses that I purchase through. They are all rated between 28-30V and 3.8-4.0A. A little lower or higher current values would likely also be fine to use but I wanted to keep the values the same or close to stock values.
Also, just confirming that the MOSFET does indeed need to be installed upside-down.

Since the PCB design for the additional fan is for whatever reason not correct, I created this image is help me visualize what needs to go where. Not really needed for anything here but figured I'd share anyway.

[BackwardEcho]

This actually might be very helpful to those who wish to add the components themselves instead of contacting you at Gigdigit. Obviously it might be very few who are comfortable doing it, but the documentation on it is extremely valuable nonetheless.

[aegean-odyssey]

Thanks @MatthewUpp for confirming the parts list and layout. Is GigDigit going to sell a parts kit, or offer a service to upgrade boards, or sell upgraded controller boards? If so, I'll mention it in the wiki page.

[BackwardEcho]

@aegean-odyssey He added the parts during his last batch which prompted this whole thing. Since it works I can see it being added going forward for new boards. The other options (parts kit or service) is what I'm thinking people would be interested in; to know it is available. But for the service some things will probably need to be shipped to the customer beforehand in order to get the board safely to him for modification (ie, an anti-static bag, because who is going to readily have one).

[BackwardEcho]

Is anyone able to add that Gigdigit schematic to the FAN1 wiki? I think it's a good representation on how to orient the components on the board and thus should be added. I'd do it but I am not familiar with anything related to GitHub outside of making simple posts and I don't want to break anything in an attempt to make it match the format.