I've just had a really frustrating and puzzling experience. The part I have just printed is one half of a puzzle cube and should be 100 x 100 x 100 mm (minus a 0.1 mm offset on each side). X and Y are spot on at 99.8 mm on each axis. The height however, is 114.7 mm - way off! Printed in PLA and Polymaker Polysupport on my E3D Big Box Dual Titan Hybrid I've checked the STL file and it's perfect. I've also checked the Simplify3D generated code file and the final layer has a Z value of 99.8, which should be right. My Z axis steps/mm (printed straight from the EPROM using M503) are 1600 - unchanged from default. Here's my only clue - the puzzle is meant to be 7 blocks high with each block being 14.08 mm tall. The bottom block layer is a bit short at 13.8 mm. The middle 5 blocks are all much too tall at 17.8 mm. And the top layer, the only one without support material, is pretty much dead on 14 mm tall. Any ideas what on earth is going on here?
Nobody?! OK, well I've had a nice hot bath and laid there thinking for a while (which often helps, but not quite as much as the morning shower ...) and I remembered that when I was 30, I had an IQ of 157 (based on a postal Mensa application form - I didn't join). Now I'm almost double that age, and my little grey cells are undoubtedly dying off at an ever-increasing rate, but I don't think I have lost all my skills as a diagnostician yet (albeit, they are probably better at silicon-based hardware than carbon-based wetware these days) so it shouldn't be beyond me to solve this little mystery by applying some logic. I was leaning towards thinking that the only plausible answer was skipping motor steps due to a too low driver current (I haven't actually tested any of this yet), but I couldn't work out how that would make the object taller. Surely, skipping steps on the Z axis would mean less movement and therefore a shorter model?? Then I realised that there is one possible explanation for the increased height of the print. The 'Oozeless Tool Change' script that I used for this dual-extrusion print includes the following line every time the print-head is changed, just before moving to the dock position: Code: G91 ; relative positioning G1 Z2 F360 ; move Z axis by 2 mm G90 ; absolute positioning This drops the bed by 2 mm at 6 mm/s (360 mm/min) (gravity assisted - no problem!) (Incidentally, Alex's original script included a 5 mm Z move, but I had already decreased this to 2 mm, simply to save time). Then, at the end of the purge/prime/wipe cycle, the print head moves to the correct position to recommence printing and then bed must then be raised by 2 mm to restore the correct Z height, e.g.: Code: G1 X170.140 Y51.320 F12000 G1 Z85.600 F360 The printer is trying to raise the bed by 2 mm at the same speed, but against gravity! If the current was fractionally too low, the motors would be most likely to skip at this point, and failing to restore the bed back up to the correct position would definitely result in the layer height being fractionally taller, and the whole print significantly taller as a result. This would also explain why the top set of blocks printed at the correct height - no support means no tool changes, so no 2 mm drop on every layer. I think the next step is to measure my voltage on the Z axis driver and increase it a bit before running some test prints. Any suggestions for a good setting?
Stock steppers and Rumba with GeeTech stepper drivers? The stock Wantai 42BYGHW609 steppers are rated at 1.7 amps/phase. You could try running them at 1.5 amps as a test of your theory.
Following this thread. Defiantly something to watch when doing dual printing. My initial thought that this could have something to do with microstepping. Every now and then you pause and adjust Z when the motor is in not fortunate positions it would be easier for the motor to jump back to the whole step. But then not sure how they can add up over time. What's your layer height?
@Ephemeris - I increased my Z stepper voltage from 0.56 to 0.8 volts. I don't think it has made any difference. @Stian Indal Haugseth - I've been using various layer heights between 0.1 and 0.2 mm. All cause problems when I am dual extruding. I tried printing an alternating tower of cylinders 50 mm tall. This printed accurately but there were only four filament swaps, so not really a good test. Then I tried printing a dual-colour tree frog. He looks great but the eyes are oval instead of round. The feet are also much taller than they should be. I printed a single extruder copy of the same model for comparison and put them side by side. Both were printed at 0.1 mm resolution at 30 mm/s. You can clearly see that when a layer uses both extruders, the layer height is higher than it is supposed to be. This is most noticeable in the last picture. There are a number of variables I can try eliminating, one by one: Z hop Filament change script Mesh Bed Levelling Micro-stepping Any other suggestions?
To quantify the problem, I printed two cubes 20 x 20 x 20 mm, using a different extruder for each cube. I will attach the STL and the Gcode file here in case anyone cares to try and inspect them. Please bear in mind that this was sliced for my printer configuration (BigBox Hybrid Dual Mirrored) and probably won't work on anything else. Here are the results: X = 19.93 mm Y = 19.93 mm Z = 23.44 mm So when I dual extrude the Z axis dimension is coming out 17% taller than it should. All the layers seems to be a very consistent height - just consistently wrong!
Done a bit more thinking. Current best guess is that it may be a bug in the MBL code that is interacting with the 5 mm Z lift in Relative mode during the tool change script. Here is a macro-photo of the layers on the support cube after drawing a line across the surface. You can see that the normal layers and fat layers alternate absolutely regularly. I think this means we can rule out skipping steps which would be be much more irregular.
Not that simple, I'm afraid, @Paul Winter. Both nozzles are 0.4 mm. Well, I did another trial of dual extrusion after removing the Z-lift from the Tool Change Script in Simplify 3D, and got exactly the same result - my 20 mm cube has a height of 23.44 mm - the one on the right in the picture below. Then I decided to print the same models with the same 'Both Extruders Oozeless/Ram purge' extruder setting, but opted to print both cubes using extruder 0. This time I got two perfect cubes, accurate to within 0.02 mm. What is going on here?!
I thought I had 2 x 0.4mm nozzles on my hotends........ Nope, one of them (one of my newest nozzles) is considerably narrower than the older 0.4mm nozzle. Unfortunately the only way I have to check the nozzle size is using a piece of steel guitar string and poking it up through the nozzle, as if I was unblocking it. Eyeballing the nozzles shows me they have different size apertures, but they are identically coded on the hex flats. Those are some awesome sharp cubes
I thought I had 2 x 0.4mm nozzles on my dual hotends..... Nope, turned out that one of my newest nozzles (Tool 1), specified as a 0.4mm is significantly narrower than it should be. Not sure why, as it is coded as 0.44 using the dots on the hex flats, the same as the coding on my older nozzle (Tool 0). The only way I can measure the aperture is by trying to push a length of steel guitar string up the nozzle, as if I was trying to unblock it. Caused me no end of grief so far.
I could be wrong, but I think the clues are in the tree frog's orange feet. The top surfaces are badly finished, possibly indicating a layer height to extruded filament height mismatch. Check that the extruder feed rates and step sizes are identical. If layer height, nozzle diameter, extrusion multiplier, and extrusion width are all identical, then all that's left to cause differences between the green and orange parts of the model would be the material characteristics. I would take the extrusion width off auto (set a manual value for both hotends), load up both extruders with the same material (choose the green, as it showed the best results on the frog), and reprint the frog as a dual extrusion, with the same temperature on both hotends (after checking that they are both measuring the same ambient temp before starting). Did you also do this for extruder 1? I'm so dying to find out what the answer is!
Good idea, @Paul Winter. I have just repeated the previous test using extruder 1 (instead of 0) and the results are quite conclusive. Another perfect pair of cubes - the light blue ones in the photo. The next test is going to be another pair of cubes printed using Both Extruders, instead of Both Extruders Oozeless/Ram purge, to see if that makes a difference.
hmm.... I do not think it's an extruder issue as @Paul Winter suggested. Under extrude would make holes, over extrude... more plastic than height so the nozzles would scretch in the part. it might be this extruderRetractionZLift,0.25,0.25 with the tool change script. This is a z hop on retract. But I have no ex with Dual, since I never was able to align the nozzles One day I may go IDEX but with other hotend mounts I do not like the default mount design.
From left to right: Original pair of cubes printed with [Both Extruders Oozeless/Ram purge]; height = 23.44 mm Cubes printed with [Both Extruders] profile; height = 22.82 mm After manually adjust the bed and then repeating the Mesh bed Levelling, (all other settings the same) two more cubes printed with [Both Extruders] profile; height = 22.38 mm Two cubes printed from Extruder 0; height = 20.00 mm Two cubes printed from Extruder 1; height = 20.00 mm So here are my conclusions. It's not the filament - almost identical results with different filaments. It's not the nozzles - cleaned and checked the nozzles and got the same results. It's probably not the Z-hop, because this works fine with a single extruder and removing it doesn't help. It only happens when printing with Both Extruders Adjusting the MBL setting does affect the results I think the regularity of the increase in layer height on every other layer makes missed steps very unlikely I've been reviewing the Marlin issues list since the recent release of 1.1.0 firmware and a great many MBL issues appear to have been fixed. I'm still on 1.1.0 RC6 (@Alex9779 's Marlin-BigBox-Dual-RC build) In summary, I still think it's a bug in the firmware and I'm very tempted to try the new release and see if the problem goes away. I've now got a stack of orders waiting, that I would have used soluble support material for, but I can no longer trust the accuracy of the parts until I get this fixed.
I've spent the weekend reviewing the Marlin issues and looking for possible reports of this type of problem. I haven't found the exact issue reported by anyone else, but even if I did, I suspect it would not be worth fixing because the firmware has moved on so much since RC6, the version I am still using. I did find several reports of Mesh Bed Levelling interacting with Tool switching. For reference, these are the kinds of problems that sound somewhat similar to mine and make me think that a newer version of the firmware might already contain the solution to my 'Stretched Z height' issue: Tool offset not working (RCBugFix) #4182 Fix position shift with MBL #4310 Issues when switching tools (RCBugFix) #4266 I'm now in the process of trying to adapt the new 1.1.0 release to my printer's configuration and once I've got everything working again I hope to be able to repeat my cube test using both extruders to see if the Z height is correct. I'm dealing with the Head Crashing when Docked problem using @Alex9779 's reverse tool head move logic on tool change code change, rather than @Greg Holloway 's 'S1 disables the auto-move' slicing method.
Hi @Alex9779 . I copied all the changes in your 'reverse tool head move logic on tool change' code change but when I tried to print some gcode which started with Code: G90 M83 M106 S0 ;BigBox Hybrid-Dual Mirrored Start Script Begin ;relies on M83 (use relative extrusion distances) ;home T0 ; select extruder 0 G28 M420 S1 M117 Preparing I got an unhandled communication error The only clue I could find was one additional reference to 'no_move' in the 1.1.0 release version of Marlin_main.cpp: Code: // Only when auto-parking are carriages safe to move if (dual_x_carriage_mode != DXC_AUTO_PARK_MODE) no_move = true; Could that be important? If not, do you know what else might be causing this? Thanks.
This is an interesting thread @richgain . I have had similar issues with the machines here and I was putting it down to bad stepper drivers and missed steps. I have found that the issue has stopped when I shifted to the dual idex system running on RC6. I have since tried to swap to 1.1 but ran into a problem where MBL fails to finish. I've not had the time to investigate more just yet.
