…code, cg, electronics, 3d printing…

Jump to C-Bot blog index to see all the posts.

This update is a combo post on several subjects at once:

Adding Lighting

Up until now, the C-Bot has been a dark printer:  No internal lighting whatsoever.  My Replicator1 is like a little supernova next to it when the room is dark.  But no longer:  Over the weekend I added both an 12v LED strip to the top-front X-beam (pointing directly at the print-bed) and a superbright LED directly on the print-head itself:

While my buddy Mason did a slick job of wiring his LED strip directly into the Rumba board on his C-Bot, so he can adjust the lighting based on the print settings, I did not:  I ran a extra 12v lead out of my power-supply, and connected both the LED Strip, and the superbright LED (with inline resistor) directly to it:  Turn C-Bot on, lights turn on.  Nuff’said / good enough.

Breaking

After I installed the lighting and turned the bot back on, the Bowden extruder suddenly started jittering:  It would no longer extrude filament.

I started by swapping a DRV8825 stepper driver from the z-steppers to the extruder stepper slot:  Try extruding, and it works.  Ok, it must be a bad DRV8825, and I have no spares.  But I do have a bunch of extra A4988‘s:  I’ll just put one in there, and updated my firmware to use it instead.  It doesn’t work:  Jittering starts again.  So I revert the firmware change, and put a ‘good’ DRV8825 back in:  Jittering.  What is going on?

Soon, any DRV8825 I put in that slot causes jittering, but they all work when plugged back into their original slot.  Drivers are good,… is my board bad?  At this point I disconnect the 4-prong JST connector running from the board to the stepper, and notice that one side is slightly melted: I remove the wires from the connector, and connect them on-by-one to the pins on the board:  Everything starts working again.

Canibalizing a connector from some other wires, I reinsert the leads, plug it into the board, and back in action.

Seriously?!?

Improving Ringing / Ghosting

I had recently printed out a “Sledgehammer Games Recognition Coin Holder” for someone at work (I modeled it in Maya / Tinkercad):  We can give out cool coins to fellow employees for doing good work, and I designed this coin holder so people can show them off (there’s four slots in the top to hold the coins).

I’d printed many on my Replicator 1 in the past, and printed this one on the C-Bot for the first time.  And what I noticed was, there was a terrible amount of ghosting / ringing happening:

Click to see the full-size that really shows the problem off.

This was printed with the .6mm E3D-Volcano nozzle, 300 micron layer heights at 60mm/sec, in MakerGeeks Royal Purple PLA.

The issue was, the prints done on my Replicator 1 had less ringing than the C-Bot, and this didn’t make sense to me:  The C-Bot has a Bowden extruder, thus removing a bunch of moving mass from the toolhead, not to mention it uses Core-XY mechanics, that is supposed to help out as well.  Why are things worse?

Posting this question to the 3D Printing Google Group, I got a bunch of good answers.  Specifically, my firmware acceleration may be too high, and the size of the printer itself could be causing too much shake, do to the lack of additional cross-members for stability.  Right now I have no surplus extrusions to stiffen it up, and my ultimate goal is to bolt the printer directly to the wall, thus really locking down any shaking.  But in the meantime, I can adjust the acceleration in the firmware.

I made a ringing/ghosting test model in Maya that would show off the issue on X, Y, and XY all at the same time.  I printed it with my default settings (3000 mm/sec), then dropped it waaay down to 800 mm/sec.  The results were pretty obvious:

Click for bigger pic

On the left of each image, is the ‘800 mm/sec acceleration’ print, and on the right is the ‘3000 mm/sec acceleration’ print.  These changes were made in Marlin’s Configuration.h:

#define DEFAULT_ACCELERATION 800
#define DEFAULT_RETRACT_ACCELERATION 800
#define DEFAULT_TRAVEL_ACCELERATION 800

I just set everything that looked applicable to 800.

So, an noticeable improvement.  But once I get the printer “bolted down”, I hope to be able to print even faster, with better results.

Jump to C-Bot blog index to see all the posts.

Jump to C-Bot blog index to see all the posts.

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.

First I had to get some info for my hardware:

• Stepper :
  • OpenBuilds Nema 17 
  • Step angle : 1.8
• Stepper Driver:
  • Pololu A4988
  • Microsteps : 1/16
• XY Pulleys:
  • GT2
  • Teeth : 16
• Belts:
  • GT2
  • Pitch : 2mm (distance between each tooth)
• Lead Screw :
  • 8mm ACME
  • 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:

My final values:

#define DEFAULT_AXIS_STEPS_PER_UNIT {100.2166,  100.20469,  401.770921, 145.5687675196672}

Gotchas:

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 frustrating process.

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

Jump to C-Bot blog index to see all the posts.

Jump to C-Bot blog index to see all the posts.

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.

Time tonight:  About 2 hours.

Jump to C-Bot blog index to see all the posts.