Profile

Cover photo
Eric Pavey
402,092 views
AboutPostsVideosReviews

Stream

Eric Pavey
moderator

Show & Tell  - 
 
Latest project with the C-Bot: Based on a design I came up with, I've printed over 90 of these modular brackets to build a new shelving unit in the garage. Picture plywood sliding into each side, then you tighten up the screw: Instant corner made.

Each one took about 70 min with my .6mm volcano nozzle running 90mm\sec at 300 micron, they weight just under 70g: I can print 14 at a time on my 12" build plate, which basically uses up the entire spool in one print. They're using MakerGeeks Raptor PLA, and based on my stress testing, they're pretty freeking strong.
4
Carl Feniak's profile photoEric Pavey's profile photo
2 comments
 
True: I often get asked "what uh... useful stuff have you 3d printed?". Boom: That.
Add a comment...

Eric Pavey
moderator

Show & Tell  - 
 
Thought I'd show off my totally custom injection molded RADDS/Due case for my C-bot. Who knew that Safeway sold printer stuff now? 
2
Carl Feniak's profile photoEric Pavey's profile photo
2 comments
 
Sometimes it's the path of least resistance ;)
Add a comment...
 
Recently went through the process of installing RepRap Firmware on my Due\RADDS setup, documented the whole process in great detail.

Sort of the 'dummies guide' version (considering myself the dummy). Mainly blogged it for my own sanity, but thought others may find use of it as well.

Even got support from the Octoprint devs so you can now print off the RADDS SD via the OP web front end, nice!
http://www.akeric.com/blog/?p=3909

Huge shout out to Dan Newman, GroupB, and David Croker from fourms.reprap.org for tirelessly answering all my questions.
Jump to C-Bot blog index to see all the posts. This post can also be prefixed “Building the C-Bot 3D printer part 34:” Overview This post covers the steps I went through getting RepRap…
2
Add a comment...

Eric Pavey

Discussion  - 
 
Doing a test by installing RepRap Firmware on my custom core-xy bot running RADDS\Due : I'd seen other people say they've got octoprint to work with this config, but I'm unable to connect. Note, I can connect via Simplify3D and communicate with it. I'm on Octoprint 1.2.11

When I do the connect I get:

Connecting to: /dev/ttyACM0
Changing monitoring state from 'Offline' to 'Opening serial port'
Connected to: Serial<id=0x1d4dcd0, open=True>(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Changing monitoring state from 'Opening serial port' to 'Connecting'
Send: N0 M110 N0*125
.... then it waits here for about 30 seconds...
Changing monitoring state from 'Connecting' to 'Closed'
Connection closed, closing down monitor

I get this behavior using either the 'Native' or 'Programming' usb ports. I also have the RepRapPro plugin installed.
Final note, I've been using Ocotoprint with the same hardware via Repetier successfully for some time now.
Any guidance appreciated!
1
Mark Walker's profile photoEric Pavey's profile photo
5 comments
 
To follow up: I think I found the issue: There's a bug in the version of the Due I have with it's USB chip : You have to press reset after you power it on to connect. If I press rest after I power on, it'll connect every time now. SIGH HARDWARE...
Add a comment...

Eric Pavey

Show-n-tell  - 
 
http://www.akeric.com/blog/?p=3800
Finished painting my Maui 3d print:  Blogged the whole start -> finish process for anyone interested.
6
2
Chris Mjh's profile photo
 
looks good.
Add a comment...

Eric Pavey

Discussion  - 
 
Question about Z touchplates, Chilipeppr, & GRBL (X-carve) :

I've done two-part cuts (rough, toolchange, finish) successfully in the past. Thought I'd do some testing in that area today, and it all quickly fell apart. I haven't upgraded the grbl firmware in way since I've done this in the past, and I'm exporting my gcode the same.

The issue is, after I do the toolchange and re-zero Z using a touchplate & macro in Chilipeppr, when I go to restart the print, the toolhead flies off to the right of the machine, and I have to hit the e-stop. This has never happened before.

After much testing, I think I finally narrowed it down: When I export my gcode from MeshCAM, I use the 'Shapeoko GRBL-mm' postprocessor. When I go to re-zero my Z-axis, this is the Macro I execute:
macro.sendSerial("G20\n G92 Z0\n G38.2 Z-.5 F1\n G92 Z.124\n G0 z.25");
The first thing it does it set it to inches.
But I've always exported my gcode in mm, and always zeroed Z in inches.
If I leave it in inches before I unpause, I get the "X-axis tries to escape from the machine' issue. But if I enter a G21 before I unpause, it works ok. Again, never had to do this before.

I seem to have a few solutions: Either change my macro to work in mm, change it back to mm after the macro (or the last cmd in the macro), or export from MeshCAM using an inch postprocessor and just work in inches the whole time.

Maybe this is an obvious question, but is there a preferred way I should be exporting \ zeroing Z?

Also, I still can't use the built-in 'Touch Plate' widget in Chilipeppr: While it goes through the motions of zeroing Z, it actually doesn't zero it at all (nor respect the entered touchplate height), it doesn't seem to change the Z value after touch.
1
Ray Kholodovsky's profile photoEric Pavey's profile photo
2 comments
 
Thanks Ray: FYI, I'm not doing the auto-level stuff. Just homing Z with a touchplate.
Add a comment...

Eric Pavey
moderator

General Discussion  - 
 
Oh snap: It's finally happening.
2
Add a comment...

Eric Pavey

Discussion  - 
 
This "bug" has happened to me before, but not in a while: Last night while cutting the piece in the attached image (2.5"x6"x12"), the cut would constantly pause. I'm using GRBL with an X-Carve. The rough cut was 1.5 hours, and had no problem/pause. But when the final pass started (same bit, no change/pause), it got maybe 1/8th the way through (just milling back and forth on X) when it would pause. I'd press the '~' button and it would resume. It would go on to do this maybe 15-20 more times over the next 3 hours. It's obviously super disconcerting to have your cut constantly stopping.
The gcode is 4.6 megs... doesn't seem too crazy? I was running it at 90ipm... would this have anything to do with it? It has having no trouble a that speed, I could probably go faster (technically).
Any thoughts appreciated!
4
2
Jérémie Tarot's profile photosimone marin's profile photoEric Pavey's profile photo
9 comments
 
+Phil Aldrich Interesting: Maybe I'll steal my sons laptop and see if it has any better results on the next cut ;)
Add a comment...

Eric Pavey

Discussion  - 
 
I'm having an issue where "all of a sudden", my Octopi is loosing connection with my printer (Due\RADDS\RepRap Firmware) over USB, when printing off the SD : It had been running good for the past few weeks since Mark updated the dev branch to let it play well with RRF. I've done no changes to Pi, Octoprint, or RRF since then. But starting yesterday, I noticed that the Terminal would stop updating. And I see lots of this:

...
Recv: SD printing byte 6664/5188517
Recv: ok
Send: N18 M27*47
Recv: SD printing byte 6664/5188517
Recv: ok
Recv: T:232.8 B:55.9
Recv: T:232.8 B:55.9
Recv:
Communication timeout, forcing a line
Send: N19 M105*31
Recv: ok T:230.7 B:60.9
...

It runs for a while, times out, then picks back up. Repeat. And when it times out, it's like the machine isn't connected anymore. If while it's frozen I reload the page, it'll sometimes start the terminal window again.
Also, every time it hangs, it seems to be proceeded by this:
Recv: T:232.8 B:55.9
Recv: T:232.8 B:55.9
It receives to lines of temp reading instead of one, then just locks up.

I've also noticed a few other things:
* After I power on the Pi and log into Octoprint, I have to reload the web page multiple times before it'll let me log in. Then after I connect to the printer I have to reload the page again to make the Terminal start updating. It doesn't detect when I plug in the USB, I have to reload the page for it to refresh and provide that in the dropdown (but it's always done that). I'm using Chrome on OSX, and have done no manual updates since the weirdness started.
* While the print is running, and the Terminal window is froze, if I instead plug the USB into my PC, Simpliy3D will connect right away, and has none of the issues Octoprint does. Plug it back into the Pi, and the above issues show up.
* I really took notice of this when three hours into a six hour print, the gcode hit a manually inserted M226 (pause) so I could reload the filament at that exact layer. When that happened via, right after the nozzle homed (part of the pause sequence), I heard all the machine fans kick off\on: Something had completely reset the RADDS board, and the print was lots. I repeated the same print\gcode, still via SD, but from the Simplify3D terminal instead, and everything worked fine.

I've been using Octoprint for a while now, and haven't seen it go off the rails so much as now, especially considering with no changes to anything, it was printing\responding fine a few days ago.

Any thoughts appreciated!
Version: 1.3.0.dev784+gf8c67fd (dev/rrpFileOpened branch)
1
Eric Pavey's profile photoMark Walker's profile photo
6 comments
 
It's strange that this just started happening after having some success. Perplexing.
Add a comment...

Eric Pavey

Discussion  - 
 
Another question with Octoprint & RepRap Firmware: I've got my bot all configured, but I've been unable to print off the RADDS SD card via Octoprint: I can only print off the Octopi's sd, streamed over USB to the RADDS. I can print off the RADDS SD card via a usb\serial connection in Simplify3D though.

Here is what I'm finding:
RRF expects your gcode to live in a /gcodes folder on the SD. So I save this file on the SD:
/gcodes/3DBenchy_rrf_gc.gcode
When I connect to the RADDS via Octoprint, it prints this:

Send: M20
Recv: Begin file list
Recv: 3DBenchy_rrf_gc.gcode
Recv: End file list
Recv: ok

And it shows up in the file list on the left. I go to 'open it' via the Octoprint front end 'open folder' icon, and it prints this:

Send: M23 /3dbenchy_rrf_gc.gcode
Recv: GCode file "/3dbenchy_rrf_gc.gcode" not found
Recv: File opened
See octoprint.log for details
Changing monitoring state from 'Operational' to 'Error: See octoprint.log for details'

Note, the log file has no info in it. And I completely loose connection to the RADDS board. Plus as you can tell, that path is wrong, it's /gcodes/3dbenchy_rrf_gc.gcode, not the root path listed above.

So I try to print via M codes:

M23 3DBenchy_rrf_gc.gcode
Recv: File opened
See octoprint.log for details
Changing monitoring state from 'Operational' to 'Error: See octoprint.log for details'

At which point I loose connection again.
Note, this fails too (thought I'd give it a shot):

M23 /gcodes/3DBenchy_rrf_gc.gcode

Doing this in Simplify3D works just fine though:

M23 3DBenchy_rrf_gc.gcode
M24

Any thoughts? Maybe Octoprint really doesn't support RRF that well? Note I DO have the OctoPrint-RepRapPro plugin installed.

Any thoughts appreciated! I'd much rather use Octoprint as my host than S3D.
1
Mark Walker's profile photoEric Pavey's profile photo
15 comments
 
That's what I figured, but just wanted to confirm. Basically no upgrade for me until I hear otherwise ;)
Thanks again for the help with this, I just kicked off a 12 hour print at 150mm/sec, and it's running great.
Add a comment...

Eric Pavey

Show-n-tell  - 
 
Sometimes it's the little things, and today it's low-profile bulldog clips:  I never liked how high up the C-shaped "spring" part of my bulldog clips stuck up above the bed:  I recently added a new filament cooling fan shroud to my printer (back left of the photo), and based on the design, it would hit the clips on the sides and back (if printing out to the edges).  I did a lot of looking and couldn't find any clip that met my needs... then realized I could probably modify my existing ones.  Thought I'd share if anyone else could benefit.

Presuming you have a hammer, two pair of needle-nose pliers, and a vice, it's pretty easy to pull the tabs out of the springs, smash them into a 45 deg angle, and re-insert.  Boom, low-profile bulldog clips.  Nothing on the hotend can hit them now, other than the nozzle itself.

#bulldogclip   #lowprofile   #clip  
15
Alan Whinery's profile photoBenjamin Santalucia's profile photoEric Pavey's profile photo
3 comments
 
+Benjamin Santalucia​: I know if you search Amazon for " bulldog clip" there's a wide variety to choose from. 
Add a comment...

Eric Pavey

Show-n-tell  - 
 
Just spent a week on Maui: When I came back I felt inspired to make a 3dprint of the island. Printed diagonal on my C-Bot's 12x12" platform, it's 14" across.
I had to download a bunch on individual chunks of the island mesh from the terrain2stl web app, then seam them together in Maya(quite a few hours of work...), + add the base and text . Sliced in Simplify3d, 200 micron, .4mm Volcano nozzle at 90mm\sec, 20% infill (probably should have done 10% to help with some of the roof issues), 2 shells, took about 13 hours in Makergeeks Gray'matter Gray PLA.
I'm pretty happy with it! Next up will be paint.
24
2
Robert (RJ_Make)'s profile photoSelva kumaran's profile photoEric Pavey's profile photo
3 comments
 
+Robert & +Selva kumaran : Thanks!
Add a comment...
People
Basic Information
Gender
Male
Story
Tagline
CG, art, projects, chocolate
Work
Skills
eating chocolate
Links
YouTube
Great beer, food, music, atmosphere, what's not to love?
Public - 2 months ago
reviewed 2 months ago
Public - 3 months ago
reviewed 3 months ago
Public - 3 months ago
reviewed 3 months ago
Very positive first experience: Professional wait-staff (which is a huge plus in my book), tasty food, nice beer & wine selection, good eating environment. Great addition to San Carlos.
Public - 7 months ago
reviewed 7 months ago
24 reviews
Map
Map
Map
Hearty tasty food, great pastry selection. Love coming here for breakfast.
Public - 5 months ago
reviewed 5 months ago
good beer selection, diverse menu, cool atmosphere, outdoor seating, music & dancing. solid
Public - 10 months ago
reviewed 10 months ago