I’ve been using my Makerbot Replicator (1) to print all the parts for my new C-Bot build. However as of a few days ago, it suddenly quit extruding correctly.
I print almost entirely in PLA, usually from 200-210 degrees. Suddenly, I couldn’t get anything to print unless I raised the temp to 230-245: Pretty crazy for PLA. And the surface quality was terrible. Any lower in temp and I could hear the extruder stuttering, and it wouldn’t really extrude much at all.
Leading up to this I had been printing at 120mm\sec, at .3mm layer height: Squeezing a lot of plastic out of the nozzle at that rate. I noticed a bunch of melted filament around the top-rear of the heater block (you only noticed it when specifically looking for it, couldn’t see it from the front\sides): The only way it could have got there would have been backpressure from the nozzle squeezing it out of an improper location up-stream. My guess is that this somehow started the domino effect to cause whatever was screwing up my current extrusion. It had completely encased the back of the heater cartridge and wrapped around the thermocouple wires. I had to heat the whole block up and carefully pick it away without damaging any of the wires.
Thanks to tips from this forum I got it resolved: One suggestion was that the kapton tape that insulates the thermocouple had worn through, and by grounding to the heater-block it was giving inaccurate temperature readings. This seemed like a prime culprit since I had to crank my temp settings so much higher.
I’m not sure specifically which steps fixed it, but this is what I did:
Did a complete teardown on the hotend, to the last bolt. Removed old kapton, cleaned up head, wrapped in new kapton.
Removed heater cartridge and thermocouple : Didn’t noticed any wear-through on the thermocouple kapton, but added more just in case.
Did however noticed where the wire leaves the thermocouple and bends up around the heater block : one of the bends looked a bit frayed, and was mighty close to the heater block itself: Added extra insulatory kapton at that junction.
Added a new nozzle, just to weed that out.
Re-bed level, etc.
Extrusion was immediately was back to normal after that, thankfully. I was beginning to think the Replicator was getting jealous of the C-Bot build…. 😉
Some words of wisdom from Ryan Carlyle on the above thread:
General rule of thumb is that PLA does not print reliably over 10 mm^3/sec with a typical Replicator type hardware setup. At 0.3mm layer height, 0.4mm extrusion width, and 120mm/s, you’re doing 14.4 mm^3/sec. That’s reasonable for ABS (which melts faster) but not for PLA. Raising the temp may cover the symptoms for a while but it can also lead to charred filament and worse clogging issues later on.
Update: Since authoring this post I have switched my electronics to RADDS, and my firmware to Repetier. See the “Part 31 post” for the latest on it.
Now that my z-stage is moving down and up, and I can ‘auto home’ my printer through the LCD, it was time to get the movement settings and max travel extents calibrated.
Total time: About two.5 hours.
Tuning Movement Settings:
You need to make sure that when the g-code tells your printer to go 100 mm’s, it really goes 100mm. Not 90mm. Not 100.1mm: 100 mm. On bots like my Makerbot Replicator (1) this is already done for you. But when building your own machine from scratch, you need to figure all this out. Otherwise you get ovals where you should get circles, and rectangles where you should get squares.
Pitch : Listed at 2 (distance in mm between each peak), but this value was incorrect for the below calculator. Info below. The value needed in this instance was 8 (the distance in mm traveled with one revolution).
Armed with those numbers, I accessed the “RepRap Calculator” to get me the base values for my bot. I wanted to see if they’d match values Mason had already pre-plugged into Marlin (that mine should very closely match), but I wanted to understand how this system worked: In Marlin’s Configuration.h, I found the line with ‘DEFAULT_AXIS_STEPS_PER_UNIT’ with an array of four values plugged into it {x, y, z, extruder}. Based on the calculator, my ‘belt steps per mm’ came out to 100, which was around what Mason had given me. However, the ‘leadscrew steps per mm’ were 4x (1600) what was listed in the firmware (400). After a bit of research, I realized the calculator wanted to know the distance the lead screw travels in one revolution, not the tooth-to-tooth pitch (2mm). Armed with my calipers, I figured out one revolution traveled 8mm, and plugging that into the calculator gave me a value of 400. Success!
Now for the tuning: I found this great guide (on the Marlin Configuration page) by Neil Underwood that goes through the manual process of telling your bot (in my case, via the LCD) to go 100mm, and then measure with calipers to see how far it really went. Do maths, enter new values into firmware, re-measure, over and over. Not hard, just a bit time consuming:
I just hit one major problems: Very often the Rumba would reject the upload from the Arduino IDE. At a certain point, it took me half an hour to get three uploads. It turned this already slow process into an incredibly slow and frustratingprocess.
I’ve been programming Arduino’s for years and never encountered anything like this (but never on a 2560 like the Rumba uses): Sketch would compile, but when it would go to upload it would timeout, saying this:
avrdude: stk500v2_ReceiveMessage(): timeout
Searching the internets, I found many other people with complaints (not Rumba specific, Arduino Mega specific), but no solutions. Finally, I read one post (which I’ve lost the link to) that had this issue. The fix? Simply swapping USB ports on your PC between uploads. Suddenly I was back in business.
Setting the max travel extents
For each axis, there is an endstop telling the printer to ‘stop moving’ when it hits it. Most printers (like mine) only have one endstop per axis, although you could setup two per axis (min & max) and probably skip this step. If the endstop stops the toolhead\build platform going in one direction, what stops it going in the other? The firmware.
In Marlin’s Configuration.h, there’s a section called “Travel limits after homing”, where you can setup these constraints for X, Y, and Z_MAX_POS. To start, I edited these values to be something much larger than my current volume, since I was going to dial this in manually on my own and didn’t want a small value to stop me before the true extent was reached.
After re-uploading the firmware with the ‘big’ values, via the LCD I manually drove each X, Y & Z axis to what I considered was the ‘safest max position’: Just before a X/Y gantry would hit something on the opposite side with maybe 10mm to spare, or about 50mm above the lead screw flexible couplings so as to not cause any binding. I copied those numbers down from the LCD and plugged it back into the firmware. My final values are:
// Travel limits after homing (units are in mm)
#define X_MIN_POS 0
#define Y_MIN_POS 0
#define Z_MIN_POS 0
#define X_MAX_POS 320
#define Y_MAX_POS 315
#define Z_MAX_POS 530
So my X & Y are clearly over a foot (304.8 mm), so I have no problem filling my whole 12×12″ bed. But the Z is just under 21″, 3+” short of the 24″ build height I was after. This is due to a few reasons: I have maybe an inch before the z-gantry hits the flexible couplings on the leadscrews, and my E3D volcano easily sticks down over 2″ from the X/Y-gantry : If I did a bit of redesign on the extruder mount I could probably move it ‘up’ more and get 2+” back, and I’d be closer to my 24″ height goal. But 21″ isn’t too shabby to start… 😛
Other Notes:
In my previous post I showed how my Y-endstop was at the rear of the bot: This actually blocked the gantry from moving all the way back, and since the extruder is mounted on the front of it, I couldn’t get all the way to the rear of the build platform: I moved it to the front corner instead, and got that clearance back. Now my endstops are all Xneg,Yneg,Zneg, when before they were Xneg,Ypos,Zneg. In the firmware, the settings are thus:
// ENDSTOP SETTINGS:
// Sets direction of endstops when homing; 1=MAX, -1=MIN
// :[-1,1]
#define X_HOME_DIR -1
#define Y_HOME_DIR -1
#define Z_HOME_DIR -1
Update: Since authoring this post I have switched my electronics to RADDS, and my firmware to Repetier. See the “Part 31 post” for the latest on it.
After posting my z-stage problems to the C-bot forum, they suggested I try a couple things: Loosen up the bolts on the ACME lead-screw blocks, and switch to using dual motor drivers, rather than one, like I’m currently doing.
I loosened things up, and it helped a negligible amount, but I was still unable to predictably raise the build platform. So, I decided to dig into Marlin and enable dual-z-steppers.
Which I did, and then added an additional A4988 driver to the Rumba board to make use of it:
A4988 Drivers, with dual-z support.
I added the additional A4988 to the “Extruder 2” plug (on the far right), plugged the right z-stepper into it, and gave it a go: The steppers would only lower, not raise. NOW what?
Looking at the Marlin code, I noticed that the block I enabled (starting with ‘#define Z_DUAL_STEPPER_DRIVERS’) to support this looked different from the same block in the “Marlin Configurator“: It appeared that it was also enabling “dual z endstops”, which I didn’t want to happen. Rearranging the code resolved this, and now I have a bed that both lowers, AND raises. Finally. I was going to post this code-fix, but I diff’d the Configuration_adv.h file Mason had given me with the one I pulled down from GitHub, and that code section was radically different. I’m not sure which is newer\older. At least mine works now…
Now that I have the z-stage working, I decided to focus on the endstops: I had mocked them up earlier, but didn’t have them wired properly… at ALL. I spaced out and thought I only needed two wires (+-), but in reality you should also hook up signal, so the LEDs light up. More splicing and crimping ensued, and I got the Geeetech v1.2 endstops wired up correctly, based on this great pic Mason pointed me to…
… living in this thread, that explains it pretty plainly. Thus the end results:
From there, it’s getting them plugged into the Rumba correctly:
Note: Since I took this pic, I’ve changed my Y endstop so it is now Y-
Here’s the logic behind it:
Looking down on the build platform, zero XYZ is in the bottom left corner. +X is to the right, +Y is towards the back, and +Z is up.
The X-endstop is on the left side of the Y-gantry, that the extruder blocks hits when traveling left: It is in the “negative” position, thus X-.
The Y-endstop is mounted on the top-left-rear corner of the printer, and the Y-gantry hits it when it moves back in a ‘positive’ direction. So it’s Y+.
Note: Since I authored this page I’ve moved my Y endstop to the top-left-front corner, so it’s really Y- now.
The Z-endstop is mounted towards the top of the left rear leg of the printer, that the Z-stage hits when it lifts up. Since when the build platform drops it’s going in a ‘positive’ direction (or, instead, imagine the build platform on the bottom of the printer, and the nozzle lifting up instead, which is effectively the same thing), it means it starts at the negative position, thus -Z.
Note: Since I took this pic, I’ve changed my Y endstop so it is now Y-, or on the front-left of the bot, rather than rear-left as in this pic.
Once the endstops were wired up, I was able to ‘auto home’ the whole system from the LCD, and… it worked.
Finally, no more blockers… next up will be calibrating the XYZ travel distances.
While I struggle with getting my Z-steppers to work, I did some frame upgrades:
I hadn’t ordered enough of the OpenBuilds ‘Black Angle Corner Connectors‘ : I needed 18, I bought 8 (not sure how I missed that)… Mason needed extras as well, so he placed a big order, and I got my ten in today. So, I swapped out my printed corners on both the bottom of the frame, and the parallel arms under the HPB with the new corners. Metal FTW!
The 8x 55mm M5 bolts that held the wheels onto the Z-gantry weren’t long enough: I couldn’t actually got a nut on the back-side. Mason experienced the same issue, and picked up two 10-packs of 60mm M5 bolts and gave me one: I went through the process, one at a time, of removing those bolts from the wheel assembly on the HPB, and swapping it for the new 60mm version, with a locknut on the end. I held all the existing spacers, wheels, and shims in place (so they wouldn’t fall all over the floor when I removed the bolt) with tape on the bottom: Worked great!
Thoughts on my Z-stepper issue:
The A4988 drivers (that came with my Rumba ) ‘continuous current per phase’ is 1A (see link). The DRV8825‘s (like what Mason uses) are 1.5A. I’m wondering if that 50% boost would be enough to lift the z-stage? I found a 5-pack on Ebay for $13, so those are on order. But it can take up to a month: Mason may have a spare, and if so, I can test this out and see if the extra power is worth it.
I spent a good amount of time making sure my rear Z-extrusions were the exact width apart, and futzing with the HPB Z-stage brackets: I can now lift the gantry with one hand with little resistance. I also made sure the Z-steppers were exactly below the ACME lead-screw holders: I can now get the HPB to lower, just not raise (without help from my hand). So again, I hope the DRV8825’s will resolve this lifting issue.
Update: Since authoring this post I have switched my electronics to RADDS, and my firmware to Repetier. See the “Part 31 post” for the latest on it.
Instaling Marlin
Once all the wiring was mocked up, was time to get Marlin installed: The Rumba already had a cut of Marlin on it, but I need an updated version turning on the coreXY mechanics.
So I went to the RepRapDiscount Smart Controller page to glean what it had to say: I wants you to set your board type to ’30’, which ain’t a Rumba, and other things that didn’t seem to apply to my board.
Mason sent me his cut of Marlin, and after I got it installed my LCD came back. I need to diff files and see what I did wrong and he did right. He did remember that he ‘had to go modify the LCD code to get it to work’. Scary!
Tuning the stepper drivers
(Note, I have since replaced these with DRV8825’s, check out this post to see a better way to tune them up).
Once the LCD was working, I could start manually tuning the A4988 motor stepper drivers. My previous post talks about the math to calculate the values, but that sort of goes out the window when you turn things on. From the “Motor Calibration” section of the RepRap Wiki, they say:
“Each Pololu has a trimpot located next to the heatsink. The trimpot controls the current that is sent to each motor. Turning the trimpot counter-clockwise reduces the current to the motor, turning it clockwise increases the current to the motor.
Start by adjusting the trimpot down until your motor vibrates on the spot rather than turning cleanly. Now turn the trimpot in a clockwise direction in small increments (1 eighth of a turn) until the motors just start running. Then give the trim port a final turn of about 1 eighth of a turn and your should be good to go.”
So I did a bunch of that and got the X/Y steppers working, + the extruder. But I couldn’t get my dual-Z steppers to work. I had both stepper wires running into the same green terminal blocks. Mason suggested maybe I connect one to the terminal blocks, and the other to the pins behind it: That made things seemingly work better, but the z-stage still wouldn’t move. I loosened the couplings that hold the leadscrews to the steppers, and then they’d start to turn. But if I tighten them back up, no movement. Currently stuck here. Grrr…
