EEVblog Electronics Community Forum

EEVblog => EEVblog Specific => Topic started by: EEVblog on January 22, 2016, 04:34:43 am

Title: EEVblog #843 - David's rPrint 3D Printer
Post by: EEVblog on January 22, 2016, 04:34:43 am
David tells us all about his rPrint 3D printer. A university project he has been working on for the last 9 months.
Everything is custom, including the world's lightest weight direct drive extruder head, Sarrus linkage build plate, linear rail guides, and his awesome bubble enclosure.
Not to mention his own custom controller, gcode interpreter, and highly optimised C++ string libraries.

https://www.youtube.com/watch?v=n_gfZsVb-SY (https://www.youtube.com/watch?v=n_gfZsVb-SY)
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: GAD on January 22, 2016, 05:39:08 am
 Cool stuff. Should of had that kickstarter ready! :)
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: poida_pie on January 22, 2016, 06:28:02 am
Well done David. Building a system such as this will develop lots of important skills (integration of systems for one)
Best of luck with the assesment.
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: V42bis on January 22, 2016, 06:43:03 am
Excellent job. if you get a chance please post some pictures without the PMMA bubble removed. 


Sent from my iPad using Tapatalk
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: Barny on January 22, 2016, 07:15:41 am
David, you have done a really good work.

Its funny to see the way a electronic guy is solving problems aut of the view of an mechanic guy.
(I'm an machine fitter / draftsman / CNC-machine programmer)

For example:
You said that aluminium parts are cheaper then steel parts.
Thats only the case if you mill the steel parts.
If the parts are laser cut, steel parts are much cheaper.
Because steel sheets are less expensive than aluminium sheets.
I know here a company, which lasercut the parts and make all the threads on the same machine.

If you have problems with harmonics, bend the part on the sides or screw ribs on it to lift the resonances over the hearable area.


About the zinc plated steel plates:
Your's are "blue" galvanic zinc plated steel plates.
There are yellow and black versions of galvanic zinc plated steel.

The funny pattered coating mentioned in the video is a hot dip zinc coat.
Its much thicker than galvanic coat.
Its used at low precision parts like fences, suport beams,...
I you buy zinc coated sheet metal, its hot dip zinc coated too.


Its funny to see that the electronic guy moan about countersunk screws. (I'm moaning about getting matching resistors, capacitors,... ;) )
Nearby my home, there are many shops for industrie suply which sells all sorts screws.
And that to a better price and quality than at ebay.
Dont go to a DIY superstore. They sell the screws with bad quality at ridiculous high prices.

By the way:
I dont use the countersunk screws with philips head.
They are a pain in the ass if you have to remove them after a couple of years.
I always use screws with hex-head or torx-head.
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: alexanderbrevig on January 22, 2016, 08:12:39 am
Absolutely amazing work David! I'd hire you in a heartbeat.  :-+
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: adam1213 on January 22, 2016, 09:10:30 am
Neat design.
David - you mentioned your aim was to design for speed. Out of interest have you benchmarked your printer against others / how do you think it would compare in terms of various workloads.
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: AndreasF on January 22, 2016, 09:50:40 am
Very nice!  :-+

One thing isn't clear to me (but I may have missed it): how does the filament get into the enclosure, where does it sit?
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: SL4P on January 22, 2016, 10:15:50 am
Absolutely love the work you put into this.
I have to ask though...  It doesn't look like you implemented any interlock opening the 'door' - which suggests a kid (or engineer) could open the lift & release panel while the unit is running.  I'm sure you have thought about this - but interested in your comment.
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: HAL-42b on January 22, 2016, 10:19:39 am
Ah the young whipper snappers moving too fast for the old camera man :-DD
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: hamdi.tn on January 22, 2016, 10:50:13 am
AWESOME  :clap: cool project and nicely done , totally admire this kind of enthousiasme for projects.
And yes it's the exception regarding university projects, where most of them are crap or too much theoretical, or the guy end up doing nothing . good job really good job  :clap:
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: German_EE on January 22, 2016, 11:20:02 am
Great work there David, technically the stuff that students have to do these days is miles ahead of what I had to tackle when I did my degree so well done.

However, I'd like to suggest a new drinking game. Play the video back and every time you say "like" you have to down a glass, by the time the video ends you'll be sozzled. Don't worry, it's either nerves or presentational style and I'm sure that it will be better in your next video. Ask that Jones guy, he seems to know what he's doing  :)
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: brutester on January 22, 2016, 12:14:06 pm
Speaking for "wireless limit switch" @47:10 , I can give a hint - TCRT5000 , which is an "Reflective Optical Sensor with Transistor Output". It has photodiode at 940nm and photransistor, which give 0.2 to 15 mm object detection. Good enough to position your head at top left (or where ever you want). From there on, "everything is relative" on your coordinate system. It may not be very precise, but you don't need that.
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: StuUK on January 22, 2016, 12:19:24 pm
Excellent work!!! enormous  undertaking for one guy in those timescales.
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: SixD on January 22, 2016, 01:04:55 pm
WOW, just awesome that one guy managed to design an entire 3d printer.
BTW: If you still do not have a website, I am willing to make one for you (for free ofc) since I am actually a web developer.
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: hlavac on January 22, 2016, 01:13:49 pm
Great work David ;) We want more photos!

But don't celebrate yet, theres plenty work to do still, until it actually prints.  >:D You are no doubt in for a few surprises there.
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: Brumby on January 22, 2016, 01:26:39 pm
I like what I see - and the approach as well.

I would be very interested to see this in production, but before I reach for the wallet, I'd like to see some specifications, performance comparisons and see some prints.  Early days yet, I know ... but I would be really interested!
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: rollatorwieltje on January 22, 2016, 01:35:50 pm
@15:10 The second extrusion head would allow the use of support material, making it easier to print complex shapes. Instead of having to break away support structures, you can just dissolve it or peel it off (depending on material used).
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: AF6LJ on January 22, 2016, 02:34:52 pm
Looks really good......
Sometimes it's better to redesign from the ground up, this proves it.
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: NivagSwerdna on January 22, 2016, 03:05:28 pm
So much to like about this project... the mechanical eng is just sweet, the controller board thoughtfully generic, the choice of processor great for its QE, brilliant.

Not so convinced about the string<>number conversion stuff.  Why use strings at all apart from presentation to the human when necessary?  Just ship binary to/from the controller?  I also think it would be good if you can explain why the standard floating point conversions are slow... is it because they cater for locales, do lots of allocations etc?

You look really employable!  Great project!
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: andreq on January 22, 2016, 03:45:46 pm
Just.. wow!

Very good job designing all this by yourself David. I have my little RepRap at home and you're spot on with the "issues" about the controller and what not. I can't wait to see your lightweight extruder design up close.
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: TheBlackOne on January 22, 2016, 04:20:45 pm
First post for me!

David, awesome project. If it's like a Bachelor thesis from the amount of work: WOW, yes, you did SO much more than just enough to pass it. Awesome.

Regarding the clamping mechanism of the belt pulleys: There is something called Taperlock, doing exactly that. Gates sells their timing pulleys prepared for Taperlock usage. But: I did not check if they come so small as for your usage. They do go down to a 9mm bore for the axle.
There are other systems, too, like the "P-System" or SKF taper systems.


As for the optimized C++ string conversion code: std::stod is quite mighty in what it does under the hood, for example it takes care of the current locale for parsing, so it would work with both "3,141" and "3.141", depending on the locale set. Also, it copes with things like "3.14E9", removes trailing whitespaces and so on.
Here is an comparison about different ways to parse a string to double: https://tinodidriksen.com/2011/05/28/cpp-convert-string-to-double-speed/ (https://tinodidriksen.com/2011/05/28/cpp-convert-string-to-double-speed/)

Same goes for string to int conversions, of course: http://tinodidriksen.com/2010/02/16/cpp-convert-string-to-int-speed/ (http://tinodidriksen.com/2010/02/16/cpp-convert-string-to-int-speed/)

In that context: If you can be sure that your input format is fixed, a hand-optimized library will always outperform existing solutions.
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: G7PSK on January 22, 2016, 04:33:19 pm
Very nice work I particularly like the enclosure. Just wondering if it would be possible to put the filament drive motor on the main chassis and feed it through a duct in order to reduce the weight of the head unit, much like MIG wire feeders.
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: TheBlackOne on January 22, 2016, 04:43:27 pm
Ah one more thing:
David, if main target for the extrusion head is low weight: You could use smaller screws there (seems to me like M6, that's quite alot) and/or screws of another material. Aluminium would work fine for the expected stress/load, or even titanium? I guess Dave would switch to his "engineer p0rn" voice with titanium screws :-)
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: Kalvin on January 22, 2016, 04:46:02 pm
About parsing the string data: Why not run the ASCII text through a preprocessor which would convert the numerical data into binary format - no real parsing necessary any more?
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: Muxr on January 22, 2016, 04:50:41 pm
Color me impressed. No doubt tons of work went into that project. In fact, I am amazed David did it all in the time he did it in. Major respect!

For your wireless board, give esp8266 a try, easy to program, and there is tons of community support for it. Although personally, I would just stick a Raspberry Pi on there with Octoprint. Octoprint is awesome.

Anyways, would like to see some closeups of the prints once it's all tuned and calibrated. What was the plastic proto place referred in the video?
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: TheBlackOne on January 22, 2016, 04:53:55 pm
About parsing the string data: Why not run the ASCII text through a preprocessor which would convert the numerical data into binary format - no real parsing necessary any more?

Valid argument, I guess.
It would add a preprocessing step with e.g. an own converting tool on the PC or something along those lines. Like this, you can load G-Code to the controller and get going directly, which makes it easier to use.
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: Max2k on January 22, 2016, 05:07:18 pm
The mechanical design surely has some novelty aspects, but it also looks expensive to manufacture and complicated to assemble/adjust as there are so many hinges :o
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: Kalvin on January 22, 2016, 05:13:32 pm
About parsing the string data: Why not run the ASCII text through a preprocessor which would convert the numerical data into binary format - no real parsing necessary any more?

Valid argument, I guess.
It would add a preprocessing step with e.g. an own converting tool on the PC or something along those lines. Like this, you can load G-Code to the controller and get going directly, which makes it easier to use.

That was my next question as I am not familiar how the things are done in 3D-printer. Is the G-Code file uploaded into the controller's SD-card before the printing has started, and the G-Code data is read and parsed at runtime (just-in-time) - or, are the G-Code files downloaded in smaller chunks during the actual printing?
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: lukier on January 22, 2016, 05:17:47 pm
Very nice project!

You've must be made of money though. Most things custom made, machined, CNC or laser, some injection form for the bubble? Hiwin linear rails, ballscrew for Z axis? No compromises were made it seems.

Once I was designing a controller for my CNC machine, based on STM32F4, trapezoidal profiles, also experimented with S-curves, I even wrote g-code parser based on AXE C++11 libraries, so I more-or-less wrote in C++ form the EBNF from G-code specification.

In the end I dropped the idea. It is too much hassle to do all these high level stuff on the MCU (parser, SD-card etc) and very little benefit so I moved to BeagleBone Black (AM3359) with LinuxCNC and PRU for step generation. Much easier to integrate and the controller can run standalone without PC.
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: TinkerFan on January 22, 2016, 05:19:05 pm
That 3D printer is absolutely amazing, great thing.

I'm interested in how you deal with the fumes under the lid, don't they concentrate even more in the closed enviroment?
The fans at the back would blow everything against the wall, if you put it in a shelf, as you suggested. And they sit at the bottom, whereas the hot fumes go to the top (before they cool down, or are they cold enough)?!
But I have no experience with 3D printers, so I could be completey wrong...
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: Fungus on January 22, 2016, 06:26:47 pm
About parsing the string data: Why not run the ASCII text through a preprocessor which would convert the numerical data into binary format - no real parsing necessary any more?

Why add an extra step to every single print job?
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: Kalvin on January 22, 2016, 06:33:23 pm
About parsing the string data: Why not run the ASCII text through a preprocessor which would convert the numerical data into binary format - no real parsing necessary any more?

Why add an extra step to every single print job?

If parsing the G-Code was a bottleneck, then preprocessing the data so that only very little or no parsing is needed would remove the problem.
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: Fungus on January 22, 2016, 06:50:08 pm
If parsing the G-Code was a bottleneck, then preprocessing the data so that only very little or no parsing is needed would remove the problem.

Technically true but in real life it would get very old, very fast...

...therefore it's not the best solution to the problem.
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: bertomg on January 22, 2016, 08:27:51 pm
If parsing the G-Code was a bottleneck, then preprocessing the data so that only very little or no parsing is needed would remove the problem.

Technically true but in real life it would get very old, very fast...

...therefore it's not the best solution to the problem.

You're imagining the preprocessing being a separate manual step, but that doesn't have to be the case at all.
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: dext0rb on January 22, 2016, 09:17:29 pm
Very cool. How do you tram/level the bed with this mechanism? The light extruder is cool too, with the feedback on the DC motor is awesome. You do have the added weight of the stepper on that portion of the motion, though, right? You could probably make an hour-long video on the gcode interpreter alone...hint hint...cheers!  :clap:
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: DeepSOIC on January 22, 2016, 10:13:12 pm
I like:
* the sensing of the actual filament being pushed, not the motor spinning.
* this printer looks WAY different to all the rest!   :-+ And very professional.
* rails (my printer - a bought one, PrintBox3D - is also built with rails, and I find them fantastic!)
* door is great
* the concept of having the printer somewhere on the shelf printing a long job is interesting
* [edited] wireless!

Needs improvement IMO:
* I see little sense in having super-lightweight extruder, which is seen by only one axis. The X axis involves movement of a rather huge arm with a stepper, rail, and the extruder. That extruder should be sweet for delta printers!
* Not enough room at the top for proper filament feed
* I see no local intense cooling fan (important for PLA)
* bubble case needs to be easily removable, like the door is, IMO. I'm not sure if it is already - probably not, since it was not shown on the video
* I'm not a fan of screw-driven Z. I'm a fan of belt-driven Z, like on my printer! The benefits are: very high speed (allows Z-hopping); crushing extruder into the bed won't cause a disaster.
* arm is going to wobble in Z coordinate, I think.
* I failed to spot bed leveling. Looks like it's lacking.

Fantastic project!!
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: hlavac on January 22, 2016, 10:31:16 pm
@15:10 The second extrusion head would allow the use of support material, making it easier to print complex shapes.

I have a much cooler use for second extruder: secondary, much larger nozzle for infill, in addition to the fine nozzle for outilines/details. Pure speed!
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: boonkerz on January 22, 2016, 10:42:23 pm
What type of display (board) is it in front of the printer?
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: EEVblog on January 22, 2016, 11:53:16 pm
The mechanical design surely has some novelty aspects, but it also looks expensive to manufacture and complicated to assemble/adjust as there are so many hinges :o

Come to think of it, I don't know why the platform needed hinges on all 4 sides. Surely a stiff build plate and two hinges would have been enough?
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: Fungus on January 23, 2016, 12:52:27 am
It would be a worthwhile innovation.

The advantage of text files is that everybody has a text editor. Looking at files and making test data is easy.

Sending Gcode as text human readable commands was probably a sound idea decades ago for big slow CNC robots with slow RS232 serial connections.

Text is still slow over slow RS232.  :-//
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: jnissen on January 23, 2016, 01:21:29 am
Fantastic work. 95% of the guys I have worked with don't have the combo of mechanical skills, programming, electrical skills, and most important a dose of common sense! You are a rare breed. Congratulations. 
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: Synthetase on January 23, 2016, 01:23:18 am
Respect!
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: adcurtin on January 23, 2016, 01:32:41 am
About those caches (it's been a few years, I'm a bit rusty):

Caches aren't handled by the OS, they're done in hardware (probably microcode in modern CPUs). What determines cache hits and cache misses is your access pattern. The cache has no address space, it's just a cache of the ram. If I read a value from RAM location 0x5365, the value and address will be loaded into a cache line. The cache also keeps track of accesses, maybe which order, or maybe just a last accessed time (probably don't use too many bits for this). It also keeps track of whether the cache was written to, or just read, so it can write changes to the ram when that cache line is freed.

If the program doesn't access address 0x5365 for a bit, that part of the cache will be marked as free and another value and address will be stored in that cache.

If the program does access 0x5365 frequently, it will stay in the cache and the program will run faster.

If you keep the amount of memory you access smaller than your cache, you will have cache hits for all of it and the code will run much faster. If your cache is 4 lines, then your program will will start to slow down if you access a 5th word, since it'll have to load it from RAM.

Again, all of this is done in hardware, and it all appears to the code as one address space. I'm not sure how multiple caches work exactly, but you can think of each cache level as doing similar things, and each getting an order of magnitude slower. When accessing memory, the processor would check L0, if the address is there, use it, if not, check L1, if it's there, use it, if not, check L2, etc. all the way back to the RAM.

In multicore processors, it gets even more complicated and more dependent on which CPU you have. Cores on the same die might share an L3 cache, but have their own L2 and lower caches, or some other architecture. It can get even more complicated when you have multiple CPUs in separate chips that don't share L3 cache across the chips.


What you can do to optimize in assembly is more directly control access patterns to RAM, and control how much stuff is kept in registers, which are even faster than cache, particularly if you're using the same location very frequently.
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: Someone on January 23, 2016, 09:30:31 am
You've must be made of money though. Most things custom made, machined, CNC or laser, some injection form for the bubble? Hiwin linear rails, ballscrew for Z axis? No compromises were made it seems.
The video mentioned $12,000 in sunk costs and a projected parts cost in volume of $1400 per unit which is indeed substantial amounts of money, it was considered excessive when I spent $1000 on parts for my Thesis project so this steps it up another order of magnitude.

Once I was designing a controller for my CNC machine, based on STM32F4, trapezoidal profiles, also experimented with S-curves, I even wrote g-code parser based on AXE C++11 libraries, so I more-or-less wrote in C++ form the EBNF from G-code specification.
Motion control is great fun, did you ever make real world measurements of your system? I worked for most of a year on precision positioning for some scientific applications and when we actually measured the results the trapezoidal profile was as far as we needed to go, anything more complicated added no further accuracy or speed.
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: Seppy on January 23, 2016, 09:39:12 am
You've must be made of money though. Most things custom made, machined, CNC or laser, some injection form for the bubble? Hiwin linear rails, ballscrew for Z axis? No compromises were made it seems.
The video mentioned $12,000 in sunk costs and a projected parts cost in volume of $1400 per unit which is indeed substantial amounts of money, it was considered excessive when I spent $1000 on parts for my Thesis project so this steps it up another order of magnitude.

Once I was designing a controller for my CNC machine, based on STM32F4, trapezoidal profiles, also experimented with S-curves, I even wrote g-code parser based on AXE C++11 libraries, so I more-or-less wrote in C++ form the EBNF from G-code specification.
Motion control is great fun, did you ever make real world measurements of your system? I worked for most of a year on precision positioning for some scientific applications and when we actually measured the results the trapezoidal profile was as far as we needed to go, anything more complicated added no further accuracy or speed.

Hey, that's really interesting, was there an audible difference though, there is some research that indicates that it is smoother to follow s-curves. It essentially smooths the high frequency components from the corner on the acceleration.

I worked 3 jobs to pay for the project (not all simultaneously, only 2 at a time), was also studying full time.
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: Seppy on January 23, 2016, 09:55:10 am
Looks really good......
Sometimes it's better to redesign from the ground up, this proves it.

YES, cannot agree more.

What type of display (board) is it in front of the printer?

That is the rHMI, another board I designed for the project.

About parsing the string data: Why not run the ASCII text through a preprocessor which would convert the numerical data into binary format - no real parsing necessary any more?

Why add an extra step to every single print job?

If parsing the G-Code was a bottleneck, then preprocessing the data so that only very little or no parsing is needed would remove the problem.

The ultimate goal for the project, a few versions ahead will be to perform absolutely all the processing from a step/stl/other file. There might be some advantages of a packet structure with organised data, and ultimately this will be what I will likely do.
But, as the user interacts with the printer with GCode, I believe that that layer should always be understandable by the operator.
When I can move it to a step or STL file, that will be the file, however for now I'm just doing GCode :)

The mechanical design surely has some novelty aspects, but it also looks expensive to manufacture and complicated to assemble/adjust as there are so many hinges :o

Come to think of it, I don't know why the platform needed hinges on all 4 sides. Surely a stiff build plate and two hinges would have been enough?

All hinge parts are a single design, this was for a few reasons, but I thought small parts in large quantities would be cheaper than large parts with complicated operations I did modular hinges for the prototype. Also, this way I could replace a small part if there was issues when press fitting the bearings (actually replaced 2). The final reason was that the modular design meant that the hinge could be used in separate products, instead of being a single purpose part.

Very cool. How do you tram/level the bed with this mechanism? The light extruder is cool too, with the feedback on the DC motor is awesome. You do have the added weight of the stepper on that portion of the motion, though, right? You could probably make an hour-long video on the gcode interpreter alone...hint hint...cheers!  :clap:
The next version will be adjusted through a mechanism under the heated bed, currently it is levelled  under the Sarrus linkage where the mechanism is attached to the base, a spacer is placed between the base hinge and base, seemed robust but very difficult to recalibrate after the machine is slid into the enclosure.
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: Kleinstein on January 23, 2016, 10:36:47 am
Something like a preprocessor for the G-Code is a good idea. Not only for speed, but also as a check for errors (leaving bounds or even syntax errors) - its much nicer to give an error massage while everything is still cold.  My guess would have been having a small SOC based computer (like a rasberry) to hande the wireless connection anyway).

Hinges on all 4 sides is a good idea, as symmetry helps to keep it leveled and parallel. In a Version buid to price, the hinges could likely be much simpler (e.g. just steel axis in plastics parts) - better 4 simple ones than only 2 but several times stronger.

The bubble case makes me think of those ships in a bottle.
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: HAL-42b on January 23, 2016, 11:57:31 am
The mechanical design surely has some novelty aspects, but it also looks expensive to manufacture and complicated to assemble/adjust as there are so many hinges :o

Come to think of it, I don't know why the platform needed hinges on all 4 sides. Surely a stiff build plate and two hinges would have been enough?

All hinge parts are a single design, this was for a few reasons, but I thought small parts in large quantities would be cheaper than large parts with complicated operations I did modular hinges for the prototype. Also, this way I could replace a small part if there was issues when press fitting the bearings (actually replaced 2). The final reason was that the modular design meant that the hinge could be used in separate products, instead of being a single purpose part.


In theory two hinges would have been sufficient if they had zero play and could handle bending moments without flex.

In practice 4 hinges are better because they handle bending moments much better. It is good for rigidity.

Novel design, hasn't been used in 3D printers before but I'm sure it will be widely copied.
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: Brumby on January 23, 2016, 11:58:48 am

In practice 4 hinges are better because they handle bending moments much better. It is good for rigidity.


This was my thought as well.
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: george graves on January 23, 2016, 12:04:35 pm
I'll have to watch the whole thing.  But I hope that bubble comes off easy!  Or that's a deal breaker for a 3d printer.

Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: electr_peter on January 23, 2016, 12:08:12 pm
Will we see this 3D printer in action or pictures of sample prints?
How does it compare in terms of speed and resolution to other 3D printers?
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: lukier on January 23, 2016, 07:47:45 pm
The video mentioned $12,000 in sunk costs and a projected parts cost in volume of $1400 per unit which is indeed substantial amounts of money, it was considered excessive when I spent $1000 on parts for my Thesis project so this steps it up another order of magnitude.

My thesis project (2D pong playing robot - linear bearing rail, paddle on a motorized timing belt, 87 fps uEye USB 2.0 camera above the table and computer vision algorithm running on the PC, sending commands to the NXP LPC23xx based PID motor controller) was also around $1000 and it was considered expensive, that's why I'm so shocked a student can afford to spend $12k. But I did my project in 2008 and it was in Poland, so quite different circumstances.

I worked 3 jobs to pay for the project (not all simultaneously, only 2 at a time), was also studying full time.

Chapeau bas!  :-+ This is serious commitment.

Motion control is great fun, did you ever make real world measurements of your system? I worked for most of a year on precision positioning for some scientific applications and when we actually measured the results the trapezoidal profile was as far as we needed to go, anything more complicated added no further accuracy or speed.

Not really, just messing around. Couple of years ago I bought CNC-3020T, wired STM32F4 to the original controller (LPT based) and wrote various bits of code, motion control, fancy C++ g-code parser. I've implemented this first: http://staff.bath.ac.uk/ensmns/Publications/pc074.pdf (http://staff.bath.ac.uk/ensmns/Publications/pc074.pdf) (it has a downside - profile has to be symmetrical), then something inspired by TinyG code, but in the end I wanted the machine working, not just occupying desk space, so I dropped STM32 and my C++ experiments and wired Beagle Bone Black with LinuxCNC (MachineKit) and got the machine running in no time.

From my brief experience trapezoidal profiles seem to be perfectly fine for heavier, damped machines, based on leadscrews etc - such as my Chinese CNC. Maybe for 3D printers with very lightweight extruders and timing belts S-curves make much more sense as they limit the jerk. You have to admit that this TinyG demo video is quite impressive: https://www.youtube.com/watch?v=Om0wTqFA-Dw (https://www.youtube.com/watch?v=Om0wTqFA-Dw)
 
Another thing that bothers me in 3D printers and cheap CNCs is the lack of feedback loops. A while ago I bought AS5311 linear magnetic encoder and 300 mm magnetic adhesive strip from Austria Microsystems when I find some spare time I want to experiment with that.
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: eneuro on January 23, 2016, 09:01:57 pm
... so I dropped STM32 and my C++ experiments and wired Beagle Bone Black with LinuxCNC (MachineKit) and got the machine running in no time. ...
I've decided to do not mess with custom g-code parsers, but use LinuxCNC too, in my CNC project-one can make diskless Linux machine and boot from network, so no worry about data storage, and control laptop with IP cameras can be far away from CNC machine, which will need better air conditioning, etc.
Writing own kinematics module for LinuxCNC is quite easy.

Anyway, what is working area/volume for this 3D printer-I mean -it can print anything else than a small toy for fun?

By adding aka 3D printer head to my CNC machine I'm talking about manufacturing eg. concrete monuments w few meters long  :popcorn:

Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: SnakeBite on January 23, 2016, 09:25:59 pm
well done David!! very nice job!

did you payed on the project from your own money or you had a sponser/university grant ?
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: android on January 23, 2016, 09:43:24 pm
About parsing the string data: Why not run the ASCII text through a preprocessor which would convert the numerical data into binary format - no real parsing necessary any more?
If I recall correctly that was the major reason for the creation of the RepetierHost and RepetierFirmware github forks a few years back. The binary protocol was called Repetier protocol.

https://github.com/repetier/Repetier-Firmware (https://github.com/repetier/Repetier-Firmware)

Hmmm...seems to be listed as a minor feature now as simply "Standard ASCII and improved binary (Repetier protocol) communication."
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: snoopy on January 24, 2016, 12:27:53 am
Hi David

Put this project on kickstarter or Indiegogo and don't feel guilty about taking peoples money upfront. A lot lesser project has taken a lot of money and some have bombed out too. People can see that you have put a lot of thought into this and matched it with real tangible results. This is not some hare brained grab for cash and then see if it works project like those sleep therapy devices  |O You already have the runs on the board.

If you go commercial do you have to pay royalties to the Uni ?

cheers
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: kony on January 24, 2016, 01:54:28 am
David - why not double extruder? You can have water soluble supporting material in secondary extruder, and no need for designing mixing nozzle. Also if you swap ABS ot different fillament material, moisture absorbtion won't be that bad to affect dimensional accuracy much, I think. It's certainly something I'd appreciate to have on prototyping machine.
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: sakujo7 on January 24, 2016, 07:54:01 am
If I recall correctly that was the major reason for the creation of the RepetierHost and RepetierFirmware github forks a few years back. The binary protocol was called Repetier protocol.

https://github.com/repetier/Repetier-Firmware (https://github.com/repetier/Repetier-Firmware)

Hmmm...seems to be listed as a minor feature now as simply "Standard ASCII and improved binary (Repetier protocol) communication."

Looks like a direct conversion of the ascii format to binary. Should be trivial to convert back and forth on a PC, and much faster to read on a micro. Any gcode-exporting software could offer this as well, no extra steps. No obvious disadvantages.

...Yet the older ascii format is still dominant, and the few people that care about performance focus on reading ascii faster.

The world doesn't make sense.  :-//
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: mxmarek on January 24, 2016, 07:18:18 pm
Hello,
 have you tried using windows' PerformanceTimer for measuring time it takes to do the business ?
Regards, Marek
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: coppice on January 25, 2016, 04:11:55 am
The video mentioned $12,000 in sunk costs and a projected parts cost in volume of $1400 per unit which is indeed substantial amounts of money, it was considered excessive when I spent $1000 on parts for my Thesis project so this steps it up another order of magnitude.
When I was at college projects like this were simply not allowed. There was a cap on expenditure, and it was pretty low. This caused considerable skew between projects of different types. A research oriented project might require no expenditure, but involve the heavy use of a lot of very expensive kit that was already around. A more development oriented project might be stifled by the lack of funds to put relatively simple hardware together. Overall, though, I think a severe limit on spending is a good thing.
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: Rickbar on January 25, 2016, 02:38:36 pm
Looking forward to your website opening and watching the progress from prototype to production.  You have a great idea/product.  Please consider a dual extruder for those who might be interested.  I would even challenge you to 3 extruders if there were enough room, maybe a larger frame and bed?  Something crazy to think about since 3 extruders would definitely be beyond the scope of many if not all 3D printers and it would make your printer the most unique on the market. (just a thought!) 

You can definitely count me in as one of the 1000 people who wants one of your beautiful printers.  By the way, it was amazing to see your ethics about crowdfunding.  I wish you many more successes in all your present and future endeavors.

Please keep us informed.
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: Dubbie on January 25, 2016, 08:31:11 pm
When I was at college projects like this were simply not allowed. There was a cap on expenditure, and it was pretty low. This caused considerable skew between projects of different types. A research oriented project might require no expenditure, but involve the heavy use of a lot of very expensive kit that was already around. A more development oriented project might be stifled by the lack of funds to put relatively simple hardware together. Overall, though, I think a severe limit on spending is a good thing.

The problem with this, is often the best solution to a mechanical problem often does cost a little bit more money.
For example, linear bearings and ballscrews have a lower bound to their cost. If the student is forced to use an inferior alternative, they will end up having to solve a ton of problems that are completely irrelevant to real life / industry. Everybody uses linear bearings and ballscrews because they have proven their worth over the years. This allows the student to focus on other more interesting problems rather than trying to solve/work around something that was already solved decades ago.
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: electronico on January 25, 2016, 10:59:36 pm
 :-+   this has been a lot of work. Congratulations!
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: eneuro on January 29, 2016, 05:36:09 pm
I'll have to watch the whole thing.  But I hope that bubble comes off easy! 
I was not able watch longer than  afew minutes,due to those nasty light reflections in this bubble-it is terrific challenge record any video with this thing on workdesk-in everyday waork job I wouldn't like have such bubble on my desk, too ;)
No mater how much cost such custom buuble, seams not practical at all and cheap IP camera inside this printer could be much more uefull-one could controll it operation many meters away.
I hate light reflections, this disturbs environment, so take it easy-it doesn't fit into my room ligting standards, o dismiss such things no mater how many hours someone spends on it-other people spend a lot of time practicing sport... it is good for health.. and require  a lot of work too... watching light reflections in this printer bubble is not acceptable for me...
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: jonw0224 on February 03, 2016, 09:16:23 pm
Great work, David!  :-+
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: AlienRelics on February 16, 2016, 01:03:51 am
I'm anxious to check out your filament feeder when it goes open source. I've started on a large Delta printer with 330mm diameter bed and 1.5m long legs. Printable height will be shorter than that, of course.

The plan is to put a 1mm nozzle on a Tornado on it so it doesn't take a month to print something large like a wing or fuselage. I was going to do Bowden feed because the usual stepper motor direct drive is too heavy, but I fear a meter of tubing is going to cause a LOT of problems with Bowden feed.
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: grimmjaw on February 16, 2016, 01:28:53 am
David,

Where do you get the bubble manufactured?I'm looking to get a similar bubble manufacture for a project of mine, not a 3D printer tho.
Title: Re: EEVblog #843 - David's rPrint 3D Printer
Post by: ajm8127 on February 21, 2016, 03:10:21 pm
Incredible work, David. The fact that you decided to tackle the mechanical aspects of the project will pay dividends in the future. So many EE/CS people are clueless when it comes to hand tools and mechanical assemblies. Having a good understanding of the mechanical aspects of the project just makes you a more well-rounded engineer.

Please do a follow up once you get the prototype complete. I would love to see some quantitative analysis of your printer against comparable products currently on the market. You seem more interested in making it work well than hitting a certain price point and the open source nature of the project is very appealing to me.