Skip to content

Mantis: Streamed Gcode, good accuracy

November 21, 2011

I spent most of my “make” time this weekend printing various upgrade parts for the Makerbots.  I printed one Wade’s extruder, finessed some temp and bridging settings, and then printed it again much better. Also started in on the 20 parts to print for a Lowrider XY assembly.

When I got a chance to try the Mantis again I added in the G20 code to specify inches and etched most of a Fabio 1.1 microcontroller board- a dry run using thin plywood as a stand-in for FR1 circuit board.

I took video but Youtube was throwing up on its shoes last night. I will try again to upload it this PM.

Notes:

Good- The accuracy is great! I can clearly see the “Fabio” name etched in tiny letters, and the separation on the Atmega leads- the finest part- is good.

Bad- the Y axis leadscrew came off of the stepper shaft partway through- I will reattach and use Loctite. I got enough done to see that overall the accuracy is very good.

To fix: I really need a 12v supply so that I can run the spindle off of the same supply as the shield. The 19v brick I am using is great for the steppers but too high for the little spindle motor. I can probably score an  appropriate laptop brick at the Splat, or at least an ATX. That would be more bulky and ugly, though.

Cad.py may be what I need to use for gcode when my start point is a png, but it does have problems. The main thing I saw is that it does not optimize the paths in any sensible way, so it mills one little bit, then travels all the way to the other side of the board and does one little bit there, then travels back, etc.

It would be nice if “travel” speed was much higher than “feed,” but I don’t know if cad.py can specify that. I don’t see it on the controls.

Advertisements
3 Comments leave one →
  1. Alden Hart permalink
    November 21, 2011 10:54 am

    Sounds like progress. The travels should be run as G0 commands (“seeks”), and the cuts as G1 (Or G2/G3 for arcs) (“feeds”). The grbl settings do not make the distinction between the two, but your CAD program should. What you can try is set the $5 default feed rate to as fast as the machine can go, then make sure to enter a feed rate F word (e.g. F300) to set the mm/min that the G1 cuts will run. I’m not sure this will work (depends on how grbl handles the seeks), but it’s worth a try.

  2. November 21, 2011 11:11 am

    Unfortunately I can’t find any way in cad.py to do insert those commands and doing it manually (the way I enter the G20) is going to take too long. It’s only an issue because cad.py doesn’t seem to optimize its work and moves around seemingly at random to do each little milling path, thus a lot of unnecessary travel time.

    Cad.py is really pretty clunky, and I’m glad I’ll only have to use it when I’m stuck with a png. It was just a quick way to get usable code to verify that the machine doesn’t have a lot of slop, and it will be useful for engraving graphics, which I was doing electrochemically with toner resist before.

    I am extremely pleased at the accuracy so far, and major kudos to David Carr for coming up with this mill and the match-drilling/epoxy method to get that kind of accuracy.

  3. Alden Hart permalink
    November 21, 2011 1:33 pm

    Have you looked at the Gcode? The CAD program should be differentiating between G0’s and G1’s for you. If it is (and it may not be) you should only need to put a single F word in the beginning part of the file – assuming that you don’t need to change the feed rate during execution.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: