mysterious height problems

[Tdeagan]

Gaargh!

I've now made my 8th attempt at printing a moderately complex model. The problem is that the height is too short. I made the switch some time back to M8x1.25 threaded rods and nuts. This let me have a simple M92 Z2650 statement that has worked like a champ, until this print.

Measured against the STL, the diff isn't consistent at each level, but in most places and overall it's at 77% of target. The part is supposed to be 80mm and it's coming in at 61.75

The print is a dual extruder print using the second extruder for support material. I've done numerous dual extrusion multi-material prints in the past with no Z distortion, but it was using the RAMPS 1.4 controller instead of the Printrboard/Extrudrboard I'm currently using. The print looks great except for the height problem. 8 attempts have consistent results.

I verified that the EEPROM (via the LCD controller,) has the correct M92 Z value. I checked the slicer and g-code output, the value is setting correctly.

Here's the frustrating part, I printed single material calibration cubes at 40mm an at 80mm and they came out perfect heights. This only seems to happen when I use the second extruder to print support material. I even printed the model using a single extruder, all one material and it printed fine. Very frustrating
.
I'll have to set up a multi-material dual extruder calibration that's high enough, the 30mm hilbert cube I printed is close to perfect, but not high enough to really tell if there's a problem.

All ideas appreciated.

[hal0eight]

You'll need a step value of 2560, not 2650. Give that a go, but that would explain it in theory.

http://calculator.josefprusa.cz/

[RetireeJay]

True, Tim should be using 2560 instead of 2650 (3200 steps/rotation divided by 1.25mm per rotation = 2560 steps/mm) but that only accounts for a 3.3% error.

Tim, try opening up your G-code file in a text editor like Notepad. Scroll to the very bottom of the file, click to put your cursor there, and then Edit > Find "Z", looking in the "reverse" direction. This should take you to the z command for your last height increment, which tells you how tall the object is according to your G-code.

If the object has the correct height in G-code, then I'd suspect that something is going on in software with the dual extruders getting swapped in and out. It might be a problem in the Printrboard firmware or it might be coming from Slic3r (or Repetier).

But I don't have dual extruders. How does the software take account of the slightly different heights of the two printheads? Is it possible that the "correction" in moving from one head to the other is somehow accumulating instead of self-correcting? Maybe you could design an extremely simple and extremely tiny object just for the purpose of examining how the G-code works. Does Slic3r "reset" the z axis position every time it swaps between printheads?

[Tdeagan]

Sorry all, the 2650 was a typo. Yes, I'm using 2560 everywhere.

The LCD is telling me that it's moving the proper layer height, .25mm which it derives from the G-Code. So yes, it's something weird with the tool change.

The two tool heads can be oriented in X and Y, but not Z. They have to be at the same height if only not to knock each other's stuff over. So there's no tool change height other than...
I do wonder about the Z lift that I use only on the second extruder (it' a Bowden setup.) Maybe it's screwing things up. Hmmm.

Thanks,
--tim

[RetireeJay]

The LCD is telling me that it's moving the proper layer height, .25mm which it derives from the G-Code.

I don't think you understood my previous post. I was suggesting that you look at the last z step of the G-code, which should tell you the TOTAL height that the code thinks it's printing. In other words, 0.25mm X however many layers you have. (Coordinate moves in Printrbot are usually in absolute coordinates, not relative, so you can read the absolute X, Y, Z from the G-code.) If the G-code THINKS it's sending your printhead to 12mm (and that's what you wanted) but you are only seeing 9, then you know it's not a problem with the G-code's intended height.

I think you know that these printers don't have position sensors. They keep track of where they are by counting steps on the stepper motors. So if somehow during tool changes you are taking steps that are not being accounted for, then you have a problem. You could scan your G-code for M91 commands, which put the 'bot into relative positioning. During tool changes, I can imagine that they might intend to introduce a small relative offset when going to tool B, and then (intend to) remove that offset when going back to tool A. So that's why I suggested creating a very small object where you can examine the G-code by hand to look for inconsistencies.

[Tdeagan]

I don't think you understood my previous post. I was suggesting that you look at the last z step of the G-code, which should tell you the TOTAL height that the code thinks it's printing.

No, I understood your previous post. The LCD display is generated directly from the g-code processed by the firmware. It displays the height that the printer thinks it's moving based on the series of Z-axis g-code statements sent. Yes, I also checked the g-code itself and it's sending .25mm Z moves, and the final g-code (and resultant LCD display) believe that the full 80mm height has been reached.

I think you know that these printers don't have position sensors. They keep track of where they are by counting steps on the stepper motors.

Yeah. I'm clear on that.

[RetireeJay]

Tim,

If you want to post (attach) the G-code for a fairly small but dual-material part, I'll be willing to look it over and see if I can find a smoking gun. (Be sure that the code you send does demonstrate the phenomenon in an actual print.)

You mentioned in a PM that backlash might be a problem. You could check that with a single-material print if you tell Slic3r to use z lift as often as possible. But usually backlash is a "local" irregularity in the desired motion, not a cumulative error.

Jay