Posts Tagged ‘ steps per mm

X-Carve : Configuration & troubleshooting

This page will be an evolving repository for myself, to collect bits and pieces of X-Carve configuration, troubleshooting, etc.


Configuration

Steps per mm

After I built the X-Carve and got a few test cuts in, I found it odd there was no tuning step.  With 3d printers, it’s important to make sure you get their “steps per mm” set so when you say “make this 10cm”, it really is 10cm.  I found the “Calibration Test Pattern” project and started cutting.  Immediately I noticed something was wrong:  The circle (labeled #13) it started with was an oval, not a circle.  After searching the forums, I found this great vid showing how to calculate the steps per mm (just about the exact same process as on a 3d printer), and how to update the settings via Easel:

As it turns out, my Y & Z seemed pretty spot on, but my X was way off.  Fixed!

Motor current

Just like on 3D printers, you need to tune the steppers current so it’s not too little (so that you miss steps) or too great (so you miss steps).    All three of my stepper pots were off from the factory (which is normal, really), and to get started I manually twisted the pots until they started behaving correctly.  But I figured there was a more accurate way, like tuning the stepper drivers on my C-Bot.  And there is: Again, another great vid:

I have the Nema 23’s from inventables, which are 2.8A per phase.  Using the method from the above vid I set them all to 2V.   Seems to work just fine so far.

Troubleshooting

Forum post with a variety of troubleshooting videos:

https://discuss.inventables.com/t/x-carve-maintenance-troubleshooting-videos-add-your-own/13405/5

Understanding GRBL

I somehow got my limit switches broken.  Follow the thread here for the nitty gritty.  As of this authoring they still don’t work:  Worked fine for a day, and then… dead:  Those pins on the Arduino constantly read 0v.  But in the process of debugging this I learned a lot about grbl.

This forum post got me started on talking to grbl.

The easiest way for me to talk with grbl is through the Arduino IDE.  It was a little twichy at first, here’s what I had to go through:

  • Make sure your board is set to Arduino Uno (since right now grbl requires an Uno).
  • Make sure you have the right port selected (obviously).
  • When the serial monitor is up, make sure your baud rate is 115200.
  • If it connects properly, you should see it say something like > Grbl 0.9j [‘$’ for help]
  • You issue commands to grbl by prefixing them with the dollar sign: $.  If you issue the $ command and nothing happens, change the baude rate to 115200 again.  I had to connect a few times before it would let me issue commands to it.

grbl links:

Building the C-Bot 3D printer: Part 18 : Software Day 3 : Tuning movement settings

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 :
  • Stepper Driver:
  • 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.