Printer 001

Discussion in 'Show and Tell' started by jasonmiles, Oct 18, 2014.

  1. jasonmiles

    jasonmiles Member

    Just wanted to show off the first delivered printer! With a little help from Terence and Mike, I'm almost done with assembly. All that is left to do is some wiring and a flash of the latest firmware version (the latest firmware should ship with other printers).

    I can't wait to get this baby up and running. The build quality of all the parts are simply stunning, the OpenBeam team has done an excellent job.

    Assembly has been pretty straightforward, the trickiest part is definitely the end effector, and I admit to turning on the football game while threading in the 69 screws that hold on the linear rails. But with the kitting and instructions the OpenBeam guys are working on I don't think anyone will have any trouble.

    Can wait for all the other backers to receive their printers. Shouldn't be long now...

    DSC01596.JPG DSC01601.JPG DSC01605.JPG DSC01608.JPG DSC01617.JPG
  2. thoughtfix

    thoughtfix Member

    She's beautiful. Any newer photos? Maybe something with a blank background?
  3. degreaser

    degreaser Member

    Yeah, more pictures :)

    Have you moved the axis' yet? Is it alive?
  4. Terence Tam

    Terence Tam Mr. OpenBeam Staff Member Vendor

    We got it printing early this morning, at around 12:30am. A HUGE step for us, and a big congrats to @Mike Ziomkowski, whose electronics with preloaded firmware worked out of the box.

    We may have an issue with the "Brainwave Bundle" - this is a bundle of code that is inserted into the Arduino IDE to enable the Arduino IDE to compile code against the boards. This was a new bundle of code that we grabbed; for some reason, when we compiled the code on Jason's laptop, the board refused to talk, and when we recompiled the code, it seemed to have bricked the board. Fortunately, my car is a travelling Kossel repair center these days with all the parts being transported back and forth, so we gave Jason a board that was meant to go out in another kit.

    The really good news is, when we swapped that board in (with preloaded firmware), it just worked.

    So we have a way to build boards that work out of the box. We just need to duplicate the code base used to build these cards as part of the final release so that people who want to can compile and change the firmware themselves, ideally without bricking the control boards. :p.

    (It's not a permanent brick, the board is electrically fine, worse case we can reload the boot loader on the board via the debug headers and the card will be just fine. But we certainly want to get to the root of the issue, which is why we grabbed that board and the suspected code and quarantined it for inspection. It is frustrating to us, because we had to rely on outside help to write the code and get the drivers to work. But we will get through this).

    -=- Terence
    thoughtfix likes this.
  5. protoserge

    protoserge Member

    That's good news that the preloaded firmware board worked right out of the box. "It just works" is what I expect this printer to do.

    Will this impede the shipment or are you planning to do an engineering investigation on that board and the firmware upload process to determine if a corrective action needs to be taken on all Brainwaves for the Kickstarter and preorder kits prior to shipment?
  6. jasonmiles

    jasonmiles Member

    Here are a few pics of my printer's first prints. I am still dialing in the slicer settings, but the Kisslicer settings Terrence shared with me have been working pretty well. I am by no means a printing expert so I suspect that many people can achieve this quality and better on their first few prints.

    All of these prints were printed at 35mm/s. I did print one part (sorry not pictured, print is currently missplaced) at 60mm/s. The printer was really flying! and it came out really well considering.

    Second print was a tree frog
    Sorry about the focus
    I'm working on fixing an issue with overhangs curling up, and so far an external fan is helping
    Used an external fan on this ring after a couple tries and it came out great

    The ring was printed at .1mm layer thickness, which makes the layering barely visible.
    4th part was this large spider
    I am amazed how well the auto leveling and heated print bed are working. I would have never been able to attempt a print this large with my previous printer (BFB Rapman). This print would have failed for the following reasons on my Rapman; bed not level, bed not flat, first layer not sticking, unable to remove print without damage, warping, and raft required and non removable. This printer solves all these issues for me and more! About the only flaw I can point out is, one of the fangs did not lay down perfect and came dislodged during the print.
    Here are a couple shots of the printer. I'm not a pro so if you are looking for good photos to share look at the ones on the pre-order page

    Let me know if there are any other requests. Next I will work on trying to take a short video.
  7. Terence Tam

    Terence Tam Mr. OpenBeam Staff Member Vendor

    Answering @protoserge 's question earlier: It does not impede shipment; we already have additional printers leaving the dock, although still in small numbers, and we are on track to start transferring kitting of the top level kit to our kitter this coming week (which will then greatly increase kitting speeds, and frees me back up to do documentation. I kit all the printers currently leaving the dock and that needs to change.).

    In a situation like this, you cannot be 100% sure of what caused the failure. My laptop had not been working, so without any way to verify the board, we swapped out boards immediately since we had spares available (well, it wasn't a spare, technically. The fine folks at Solarbotics won't be getting their engineering validation machine #2 this week as a result...). However, we can now tell conclusively that there is something wrong with Jason's Windows installation on the MacBook Pro that he was using *or* something wrong with that USB cable. The board that failed USB recognition (ie, computer just didn't see it) worked just fine when @Mike Ziomkowski plugged it in for evaluation, and initial forensics determined that the boot loader did *NOT* get corrupted, which is what we were fearing, given that the board refused to be recognized in Device Manager. (The bootloader resides in the top part of the chip's memory, if the program got too big, it is possible for the boot loader to get clobbered during flashing. We went in through the debug port on the board, dumped back out the binary image and then looked at the hex code in a hex editor to determine that the boot loader had not been affected). So, if the computer had a properly functional USB port, we would have been able to recompile the firmware.

    We are going to take a much closer look at the Brainwave Bundle and our code base to see if there's any compatibility issues. It comes down to zero version controlling in Open Source software - Matthew Wilson did test his bundle, but he probably grabbed a fresh version of Marlin. We've been using a version that's been locked down since Dec of this past year, and our own libraries. BOTH paths gives a functional piece of software (as evidenced in Wilson's testing and our testing), but it looks like combining them introduced some weird communications error. Still, the end result is to be able to publish a set of code for people to modify their own firmware - and we aren't quite there yet. We would want to base our driver library off the latest Marlin source.

    And it is for exactly reasons like this that we want to own and control a version of our supply chain, soup to nuts. I can't tell you how many times in the past 2 years I've worked on one problem, only to find that the features I've been dependent on changed, or moved, etc.

    -=- Terence
    protoserge likes this.
  8. protoserge

    protoserge Member

    Thanks for the update @Terence Tam. I hope you don't regret this project even with the setbacks. The machine is truly beautiful.

    I've definitely encountered the "bad USB" cable before and it is one of the most overlooked and unsuspecting failures to have!

    @jasonmiles thanks for the photos. No one said we needed professional quality, we just want to keep salivating while we wait for ours :)

    60 mm/s is "pretty slow" for a deltabot to be over 200mm/s (at least in the software settings). Was that the print speed or just the first layer print speed (which makes sense). In fact, I was just printing last night with a Lulzbot TAZ (an outstanding printer, btw) at 200mm/s, but the part was small, so I doubt it actually achieved that speed.

    It looks like you're having fun! 3D printing is really an awesome thing :D
    Last edited: Oct 28, 2014
  9. Terence Tam

    Terence Tam Mr. OpenBeam Staff Member Vendor

    Friendly "challenge": I don't believe 200mm/s print speed. That is the equivalent of tranversing the entire side of a Prusa Mendel build platform in one second.

    The head can certainly move that fast on a Delta (and it's ability to "hop" during a retract move is truly impressive - we move ours in non-printing moves at 300mm/s ), but actual laying down plastics and getting it to stick where it was left is still limited by physics. Our J-Heads have a 0.35mm nozzle on them; it's a design trade off for precision and details vs the ability to go fast. (As it is, the machine can build potting fixtures 2-3x faster than my Stratasys both at work and at home). Does anyone have actual videos of printer printing at a measurable 200mm/s, and actually laying down plastic in a reasonable manner at that speed?

    Edited to add: Here's Johann's machine, at 40mm/s exterior, and 105mm/s infill, and even then I don't trust that it is actually *hitting* 105mm/sec infill, due to the short acceleration paths available to do the actual infill.

    -=- Terence
  10. protoserge

    protoserge Member

    Of course not :p

    I probably should have clarified what I was asking was the software settings for print speed. Since this is the theoretical maximum it still offers a comparison point. 200mm/s on a deltabot and 200mm/s on a cartesian printer, given all extruder and physical constraints, should print at the same actual speed.

    The comparison point I wanted was something like this: the cartesian printer physically can't exceed 30mm/s, but the deltabot can print at 60mm/s with the (hypothetical) software setting set to 200mm/s and 300mm/s, respectively. Or is the software setting in the slicer program set to 60mm/s?

    I'm sure that a deltabot (with same class of motors) will be able to experience much higher accelerations than the cartesian bot purely due to the lower inertia of the end effector.

    Hopefully, that makes more sense.
    Last edited: Oct 28, 2014

Share This Page