Z axis will not change layers during a print
-
I had the same problem due to a config mix up , don
t know if its the same !!!!
My problem was setting the min height wrong .Thanks for the tip. That is one part of the configuration (in my very simple first config file) I haven't managed to fully figure out. I will double-check
-
it was M208 X0 Y-15 Z0 S1 which I got wrong and set Z to 3 by mistake or not knowing what I was doing.
-
nopp
I didn't do that at least.while the g-code obviously have G1 Z commands, it's still not moving in the Z direction at all during print. baby stepping and all other forms of manual G1 Z commands though the console, and machine control interface works perfectly…. Layer statistics of course doesn't change, taking forever at layer 1...
-
Hmmm. That's very odd looking gcode with very strange layers heights and some really weird feed rates. Also some very odd behaviour. It seems that it starts with Z at 0.28 mm, raises it to 0.78 mm, moves the carriage without extruding filament then drops Z back down to 0.28mm and does that few times. Do you have "Avoid crossing perimeters" enabled? Anyway, regardless of that, the Z axis ought to move.
The other thing that struck me was the M115 command with a U parameter. M115 isn't needed so try taking it out, just in case that's causing some havoc somewhere.
-
I forgot exactly if I have the crossing perimeters option activated, I shall check when I get home. I do have z-hop enabled, which is probably what that is (although I don't see why it should be there in the beginning since there is little to z-hop over….).
Note that this is generated from my default profile for that printer which I know works well (before I ripped out the old controller for the duet because I fried a driver in all my stupidity). I have also tried generating g-code using the same .stl file in Cura (also with a profile I know worked before, though that doesn't say much here) and the same thing "no z-axis movement" happens during printing.
The last tests I did yesterday was I manually injected huge z-axis movements such as "G1 Z10" at random locations in the first couple of layers of original code, and since I decreased z-axis top speeds to ludicrously low, I can see them in action. They run fine (with the correct distance too), but the "real" layer changes don't seem to be executing.
Almost at wits ends here. Last night I ordered another board (I shop to alleviate stress) to see if that helps, though Duet Wifis are currently out of stock and I have to wait a while ...
Would this be a bad time (i.e. way too late) to say that I (might) have damaged the board during assembly because I shorted a fan output and had to replace the 1A blade fuse? I withheld the information partly due to the fact that none of the other parts of the board seemed to be affected by that after testing, and partly due to me being ashamed of my incompetence.
-
I don't think it's a hardware problem, because your G1 Z10 commands worked.
You are not alone in having shorted a fan output. Lots of people seem to do that, which puzzles me. But as that's the many way that users have been damaging Duets, we decided to provide some protection for the fan circuits in the 1.03 PCB revision. Unfortunately, in testing I found that when I shorted a controlled fan output using 24V power, the mosfet blew before the fuse. I don't know what happens using 12V power.
-
My mosfet seems to have survived the short at 14.5V, so the blade fuse did its job. I am not sure how it will be now when I replaced it with a 2A one (somehow, in my country 1A mini blade fuses is not a thing that exists)
Not sure about others, in my case shorting the fan output is due to: 1) I do this last, when exhaustion and impatience to fire up the printer sets in. 2) I have the bad habit of swapping my "favorite" fan across systems with different mounts, so my fan wiring has 4-5 half-baked soldering job scars across it, of which any can fail at any time but of course I always check the fresh half-baked crimp job first, happens to be closest to the board in this case. 3) I am not good at crimping. My mechanical handicap shows when using large tools on small parts.
I will try more configuring. While I am not a fan of z-probes in general, perhaps its worth it to try an actual z-probe instead of "faking one" according to the configs. I have found no issues in that respect though since the axis homes correctly with the min z-stop working as intended.
-
Hmmm. That's very odd looking gcode with very strange layers heights and some really weird feed rates. Also some very odd behaviour. It seems that it starts with Z at 0.28 mm, raises it to 0.78 mm, moves the carriage without extruding filament then drops Z back down to 0.28mm and does that few times. Do you have "Avoid crossing perimeters" enabled? Anyway, regardless of that, the Z axis ought to move.
The other thing that struck me was the M115 command with a U parameter. M115 isn't needed so try taking it out, just in case that's causing some havoc somewhere.
Well, I'll be darned. Just in time for a spare MKS to arrive and I thought about replacing the Duet board with something that actually works (my only multi-extrusion system so I kind of need it), it works!
Going through the generated g-code, I can say that the "strange" behaviour is the priming with z-hop, though that sequence is a bit strange… after I commented out the home all axis, and G80 (not supported, so it comes out an error), and M115 U commands, I began hearing the z-axis movement (should have learned this earlier since it is the only axis on screws). I do not know which of the two G80 or M115 U that was causing my problem, but easy to figure out now. What still puzzles me is why these unsupported commands will cause only z axis movements not to be executed...
-
That's a puzzle! M115 Uxxx will behave just as M115 with no parameters, i.e. return the current firmware version. G80 will return a "not supported" message but is otherwise harmless. I have just tested both.
-
I have the same problem any one
Can help me here!!??? Realy the same and my fusr its blow to! Fan fuse, it have someting to do eith that?
