Part cooling fan command cancelled on Z move

My Huxley and I were starting to get along fine and play together nicely, then the honeymoon period ended and I started to ask it to print ever more ambitious things and to get ever more picky about the results. That's when I started to notice some strange fan behaviour. I'd occasionally notice the fan kick in for just a fraction of a second and then spin down. And on parts with very small layers I noticed that the fan wouldn't start at all.
Further investigation showed that the g code contained all the correct M106 S255 fan "on" commands and there were no fan off commands at all. A little experimentation later and it seems that fan operation is cancelled by a Z axis move. Is this a bug or a "feature" of the firmware? Either way it's not at all helpful as slic3r produces g code which looks like this at the end of one layer and the start of the next (comments are mine):

G1 X64.294 Y57.456 F600.000 E2.40742 ; last line of one layer
M106 S255 ; fan full on
G1 F1800.000 E0.40742 ; some extruder stuff
G92 E0 ; some more extruder stuff
G1 Z1.400 F7800.000 ; move up to the next layer... which also has the side effect of cancelling the fan
G1 X63.827 Y81.827 ; start of next layer... but fan is now not rotating

Does anyone know of a fix for this?

I'm using Duet 1.04 firmware by the way.

The behaviour you describe is an unfortunate side effect of a change that RepRapPro made in firmware version 1.04. Any non-extruding move will turn the fan off. It's because they implemented gcode M571 and used the fan output to indicate whether extrusion is taking place or not.

It's fixed in my firmware fork, which only uses the fan pin to indicate extrusion if you first send an M571 with an S parameter greater than zero (so don't do that!). You can find my firmware at [github.com]. The recommended web interface to use with it is DuetWebControl, available at [github.com]. You can find a list of differences between my fork and RRP's master at [github.com], and migration notes at [github.com].

Edited 1 time(s). Last edit at 04/14/2015 03:14AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Wow, dc42 you're a hero. Not only have you fixed this problem for me but other issues as well.

I had been sticking with the RRP main line of firmware out of some mixture of loyalty, nervousness and laziness and I was happy with my Huxley and it worked OK but was a bit rough around the edges. This issue with the part cooling fan forced me to move to your firmware fork as the main line simply didn't work anymore and it's transformed my printer.

The fan problem is sorted, as you knew it would be.
The movement is incredibly smooth, especially on the first layer.
Related to the above the movement now sounds so much nicer - I can hear the motors "signing"
I'm now able to use the DuetWebControl (which didn't work before) and I'm loving it. It's better in so many ways.
The time estimates now work (almost, I'll come to that below).

I only had time last night to print one thing and you'll be please to know it was your fan backwash eliminator. I've got to the stage where the biggest of my problems is a slight lack of adhesion with PLA or a slight curling of parts with ABS but only in the front right corner of the bed. I can feel the air being stirred there (wet finger test) so I'm hoping your eliminator will, er, eliminate it. The fact that that's my biggest worry says that things are now going incredibly well, thanks in most part to your help, so thanks very much.

I have one small piece of feedback, and I'm not sure if it's for you or for zombiepantslol. On the print status page of the web interface the percentage progress bar in the middle and the filament usage data in the top right both appear to be based on data from the last layer rather than the overall print. I don't know whether those numbers are calculated in the firmware or the web interface, hence not knowing who to mention them to. Please understand, for me this is cosmetic fluff which in no way detracts from the tremendous job both you and zpl have done with these pieces of software.

Thanks again,
Calvin

So I spent a happy lunchtime snooping through the codebase and I suspect my comments above about the filament numbers being based on the previous layer only might not be for dc42 or zpl at all but rather for whoever maintains slic3r. It seems that slic3r scatters G92 Z0 commands through the gcode and specifically between each layer which of course resets the filament "home" and therefore the amount used so far becomes zero.

I can't see why those G92 Z0 commands are needed so I'll experiment tonight by stripping them out of a file and seeing if it fixes it. My reading of the code in GCodes.cpp and PrintMonitor.cpp says it should.

Quote
csambrook
So I spent a happy lunchtime snooping through the codebase and I suspect my comments above about the filament numbers being based on the previous layer only might not be for dc42 or zpl at all but rather for whoever maintains slic3r. It seems that slic3r scatters G92 Z0 commands through the gcode and specifically between each layer which of course resets the filament "home" and therefore the amount used so far becomes zero.

I can't see why those G92 Z0 commands are needed so I'll experiment tonight by stripping them out of a file and seeing if it fixes it. My reading of the code in GCodes.cpp and PrintMonitor.cpp says it should.

I think you mean G92 E0, not G92 Z0. You are evidently using absolute extrusion distances, and RepRapFirmware prefers relative extrusion. So check the "Use relative E distances" in the slic3r printer settings, and add a M83 command to the slic3r start gcode.

I don't know whether fan backwash is a problem on the Huxley - if it is, then you will be able to feel it. On the Ormerod, there is so much backwash from the fan that it feels like the fan is blowing backwards. However, I thought the Huxley had a small er fan (10mm thick instead of 20mm).

Edited 1 time(s). Last edit at 04/15/2015 10:43AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42

Quote
csambrook
So I spent a happy lunchtime snooping through the codebase and I suspect my comments above about the filament numbers being based on the previous layer only might not be for dc42 or zpl at all but rather for whoever maintains slic3r. It seems that slic3r scatters G92 Z0 commands through the gcode and specifically between each layer which of course resets the filament "home" and therefore the amount used so far becomes zero.

I can't see why those G92 Z0 commands are needed so I'll experiment tonight by stripping them out of a file and seeing if it fixes it. My reading of the code in GCodes.cpp and PrintMonitor.cpp says it should.

I think you mean G92 E0, not G92 Z0. You are evidently using absolute extrusion distances, and RepRapFirmware prefers relative extrusion. So check the "Use relative E distances" in the slic3r printer settings, and add a M83 command to the slic3r start gcode.

I don't know whether fan backwash is a problem on the Huxley - if it is, then you will be able to feel it. On the Ormerod, there is so much backwash from the fan that it feels like the fan is blowing backwards. However, I thought the Huxley had a small er fan (10mm thick instead of 20mm).

Indeed, I did mean G92 E0 rather than G92 Z0. And yes, relative extrusion fixes it.
So it seems that "Absolute" is absolutely not absolute at all but rather relative to the start of the layer rather than relative to the start of the print. Anyway, sorted now, I have full feedback on the web interface and I'm officially a Happy Bunny.

What I'm experiencing from the fan may not be technically backwash. The fan manages to stir a lot of air to the front right of the printer, I can feel as cold it if I wet my finger and hold it there. The front right is also where I see any adhesion problems and any curling, so much so that my simple work around is to rotate parts when slicing them so that either the front right is not used or any elements in that space don't matter if they curl. Looking at it again in the light of your comment I notice that the heatsink outputs to the side so I wonder if I might be seeing that. If so I think I'll print a deflector to guide the air upwards and away from the bed. Just occasionally I wish I smoked, it would make this sort of investigation so much easier!

Yes, I've wondered whether RRP's new simpler hot end design would cause warping because of the air expelled at the sides. Another approach would be to turn the heatsink through 90 degrees (you need to drill another hole in it) and then block off the bottom. My Ormerod has one of their older hot end designs with printed ducting instead, and with those a fan inlet duct definitely helps.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].