Saturday, December 19, 2015

Tribed: a fully automatic bed leveling and tool height adjustment, with FSR and 3 Z screws

This post is the continuation of my preliminary analysis regarding bed tramming and automatic tool height adjustment. So far I never made the step to redo my bed, even though it was on my wish list for years. Now it is a reality :)

Early testing of the complete setup : starting with a properly calibrated bed,
corrupting it manually, and letting the system auto-calibrate it again.
A faster / realistic movement is here, since speed was not a concern above.

So why now? A few months ago, someone came and talked to me about his wish to design a new, open source, user-friendly printer for the prosumer market. Please check this as your opinion counts!

All in all, it was an excellent reason to realize my idea of a fully automatic bed leveling. And since the new printer will also be opensource, here is the work, design and my analysis. How nice: not only I was given the possibility, but I was asked to do so!

As said, this improvement is part of a longer effort towards a user-friendly printer, for more reliability and less manual tweaking. My Ultimaker itself may eventually be ditched one day. Huh. No, I am joking. Well.. unless the new one is really is obviously better... Damn, that's exactly what it is all about :/

Friday, December 18, 2015

Sensors and issues for automatic bed leveling and height adjustment

My printer eventually has a fully automatic and hardware bed leveling (aka tramming), and bed height (aka Z-offset). Yes, it now handles any tool height without any user action, in addition to a long-wished automatic leveling of the bed.
This is part of preliminary studies for a prosumer open-source printer, for which you are more than welcome to give your opinion! The entire bed structure was entirely revamped, as one important point in my former wish list.
Revised heated bed with automatic tramming and tool height compensation.
Since I wanted to document both the new bed but also why I wanted it this way, this first post addresses usual sensors and strategies used to deal with the bed calibration. The deal is to make a bed level and to start printing at a proper height, and there are many ways to do so, but not as conveniently as I wanted (which will be documented in a subsequent post). The second post will show more precisely what and how I did it.


Friday, October 30, 2015

Preliminary expectations and design options for a prosumer, fully opensource 3D printer. Your opinion matters!

Call for feedback: designing an opensource, prosumer-grade 3D printer

(update 2017: this project is no more alive, sorry!)

We are currently designing a 3D printer for advanced, serious, or professional usage.

The main target is reliability. The price tag is secondary, but we expect it to be $3 to 5K. Would you help us with this short survey? Being open source, the preferences of the community is very valuable to us, and we think it may be a win-win strategy.

Update: as an example of a forthcoming growing list of publication, here is an automatic bed leveling and head height adjustment.

Please feel free to share the link, every opinion counts: https://jeremiefrancois.typeform.com/to/xbuY9S


Friday, October 2, 2015

"It is better for your safety that we are opaque" (Volkswagate)







"It is better for your safety that we are opaque"

I just read an article on the BBC related to Volkswagen and the "(...) argument for stopping people fiddling with those systems, because if you don't know what you are doing - or even worse do know and have malicious intent - you could create genuine safety issues."
Volkswagen in 1969 by John Muir
But are we still complete idiots?
This post not only relate to Volkswagen, but to any big company using proprietary stuff and saying it is good for you. You can replace "car" with any non-open piece of software or hardware alike. Transparency is just so hard to depreciate, especially when you are talking to your own customers.

Saturday, May 16, 2015

Messy code, branches with a lack of guidelines and comments are killing Marlin!

Marlin no more exists as a single, readable, common branch!

Where shall I go now?

In a previous post, I described a tiny contribution I made to the 3D printer firmware Marlin. The deal was to help with the calibration of a Delta printer thanks to a manual Z-probe (calibration really is the drawback of Delta printers, due to their weird geometry as compared to easier cartesian X-Y bots like the usual printers). It was already painful for such a small, one-time improvement to the code source, and given the invested time, I tried to make it broader by implementing multi-line comments (and to learn about git by the way).
http://www.dailymotion.com/video/x2gp98t_hal-fixing-a-light-bulb_fun


This is how I feel when I want to code something in Marlin!
(Malcom in the Middle, fixing a light bulb)

So I worked in mainstream Marlin. My idea was that it could benefit to existing variants of Marlin as well, when they decide to get changes from the "official" parent. But it does not work so well in reality.

This experience unveiled another, deeper, issue related to the many Marlin variants, and I think it is due to the fundamental way github works, in addition to git own complexity. In my opinion, Marlin is just dying because of this, together with the limits of the Arduino platform.


Tuesday, April 21, 2015

Headlines again... 3D printing guns, a passion?

Headlines again: 3D printing yet another part of a gun. So what?

Please Cody, yes, you the guy with big stainless-steel thermoplastic bollocks, please, now I want new stuff, like 3D printing bazookas, ammo or landmines!

I already tackled the subject it in this older post but telling that a 3D printer is probably not the best tool to use is not even my point here. Using a 3D printer to print more guns is no surprise, but I wish headlines focus more on noble usage like e-NABLE prosthetics. It is an excellent project, where volunteers 3D print free upper-limb prosthetics, like artificial hands for others. If your printer is idle, you should go and read about them!
E-NABLE: is this not a better use for 3D printing, according to you?
This way we have people printing tools that may harm people, while other people do repair them. Nice absurd world.

Here is my point for once: why do the words gun and freedom have to be put in the same sentence almost each time pro-gunners start to argue? What the heck?

Sunday, April 5, 2015

3D printer survival kit: a comprehensive set of 3D printer tools and tips.


Survival kit: tools for the 3D printers


This post started as early as September 2013, and it eventually ends here, may 2015! At least, you can be sure I heavily made my opinion and I have feedback on the tools I list here.

All included, a nicely packed Ultimaker 100% ready for travel.
I keep nearly all my tools in a dedicated box, that matches well the bottom of my printer. You will read in this post about each of the tools, slightly sorted in different categories and even though some tools are used for multiple tasks.

I attached a note after each of the items, where 5/5 is a must in my opinion, and 0/5 a luxury or a useless tools. Of course there are no 0/5 in my box as I want only a (comfortable) survival kit in the end. Read more...


Monday, March 30, 2015

CNC fail? 3D printed design blows my ears instead of the dust

I bought a well-built Chinese CNC machine last year, namely a 4 axis CNC3040Z-DQ router/engraver, for about €1000 (as far as I remember).

Milling a PCB with a low cost CNC router/engraver controlled by LinuxCNC.
My initial need was to "etch" electronics PCB boards at home, to get rid of so called proto- and perf boards. This machine is overkill for the job, but I do not regret my purchase since it can do much more than PCB milling...

But only recently did I spend enough time to use it. Even though the reliability and consistency of a CNC milling machine is way better than that of a 3D printer, the whole process is cumbersome. It takes a lot of time to get used to the software, which is a decade behind the ergonomics of more intuitive 3D printing software. Worst, the controlling software like linuxCNC or Mach3 still require a parallel port and a special real-time distribution of linux. Both are a real pain because you need a dedicated and obsolete machine just to drive the CNC. Recent projects like GRBL are knocking at the door though, as an alternative to parallel port hardware: they rely on Arduinos, but are limited by the power of this platform. ARM-based boards are more promising, especially for fast machines, or when you have more than 3 axis of freedom (e.g. see 6DoF)

Note: I may write more about CNC machining at home, its software and process in other posts. But I start here with a quick, funny, and miserable failure of mine, that was meant to be an improvement in the first place. And, well, it mixes printing and milling so it is a good transition.


Tuesday, January 27, 2015

Contributing to projects hosted on github: a step by step howto, and an illustration with Marlin (3D printer firmware).

Git is powerful... and very painful the first time! / Github contribution howto / Tweaking Marlin for better 3D printer menus.

Git mess, only partially resumed by Oliver Steele.
Indeed, the upstream higher repository is not shown here,
as seen on this other bigger, clean and useful cheat sheet.
I eventually wrote a feature to fix something that annoyed me for years: allow multi-line commands in the LCD menus of Marlin, a very well known firmware for 3D printer.

I needed it for my Delta printer: these printer do require precise calibration, often with a sequence of gcode commands (check the end of this post for more and why I wanted these to be in my menus and not as initialization files on all my SD cards nor on a PC over a USB cable).

Now, Marlin is hosted on github, a community front end to many other open source projects. Actually, the linux kernel itself is developed with git so it works, for sure.

I often tried to use github, but I never went past a simple git clone of a repository. It was still better than to download a zip archive, because you can easily get the new stuff with a git pull. But here and partially out of curiosity, I wanted to try and contribute to a project at the source.

Now... what a huge and painful procedure just to give a hand! Seriously, it is mind boggling how much crap and megabytes need to be handled just to help and submit a few dozen f*king lines of code to an opensource project hosted on github. This is too bad since I am sure many programmers would be glad to give a hand to project they stumble upon (like me, often), but without this need to become administrators of complex and shared projects themselves!

This article is all about posting and contributing to a project hosted on github. You'll get the calibration g-code line I used at the end of the post if you really ask yourself.