Author Topic: EEVblog #843 - David's rPrint 3D Printer  (Read 23684 times)

0 Members and 1 Guest are viewing this topic.

Offline Muxr

  • Super Contributor
  • ***
  • Posts: 1342
  • Country: us
Re: EEVblog #843 - David's rPrint 3D Printer
« Reply #25 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?
 

Offline TheBlackOne

  • Newbie
  • Posts: 3
  • Country: se
Re: EEVblog #843 - David's rPrint 3D Printer
« Reply #26 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.
 

Offline Max2k

  • Newbie
  • Posts: 1
  • Country: de
Re: EEVblog #843 - David's rPrint 3D Printer
« Reply #27 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
 

Online Kalvin

  • Super Contributor
  • ***
  • Posts: 1787
  • Country: fi
  • Embedded SW/HW.
Re: EEVblog #843 - David's rPrint 3D Printer
« Reply #28 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?
 

Offline lukier

  • Supporter
  • ****
  • Posts: 614
  • Country: gb
    • Homepage
Re: EEVblog #843 - David's rPrint 3D Printer
« Reply #29 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.
 

Offline TinkerFan

  • Regular Contributor
  • *
  • Posts: 93
  • Country: de
Re: EEVblog #843 - David's rPrint 3D Printer
« Reply #30 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...
"A good scientist is a person with original ideas. A good engineer is a person who makes a design that works with as few original ideas as possible. There are no prima donnas in engineering." - Freeman Dyson
 

Online Fungus

  • Super Contributor
  • ***
  • Posts: 9980
  • Country: 00
Re: EEVblog #843 - David's rPrint 3D Printer
« Reply #31 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?
 

Online Kalvin

  • Super Contributor
  • ***
  • Posts: 1787
  • Country: fi
  • Embedded SW/HW.
Re: EEVblog #843 - David's rPrint 3D Printer
« Reply #32 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.
 

Online Fungus

  • Super Contributor
  • ***
  • Posts: 9980
  • Country: 00
Re: EEVblog #843 - David's rPrint 3D Printer
« Reply #33 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.
 

Offline bertomg

  • Newbie
  • Posts: 3
Re: EEVblog #843 - David's rPrint 3D Printer
« Reply #34 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.
 

Offline dext0rb

  • Contributor
  • Posts: 48
  • Country: us
  • grind it out
    • INVENT3D - 3D Printing Service
Re: EEVblog #843 - David's rPrint 3D Printer
« Reply #35 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:
EE and Tinkerer. 3D Printing Service Startup: invent3d.xyz
 

Offline DeepSOIC

  • Contributor
  • Posts: 5
  • Country: ru
Re: EEVblog #843 - David's rPrint 3D Printer
« Reply #36 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!!
« Last Edit: January 22, 2016, 10:26:00 pm by DeepSOIC »
 

Offline hlavac

  • Frequent Contributor
  • **
  • Posts: 533
  • Country: cz
Re: EEVblog #843 - David's rPrint 3D Printer
« Reply #37 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!
Good enough is the enemy of the best.
 

Offline boonkerz

  • Newbie
  • Posts: 4
  • Country: de
Re: EEVblog #843 - David's rPrint 3D Printer
« Reply #38 on: January 22, 2016, 10:42:23 pm »
What type of display (board) is it in front of the printer?
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 29692
  • Country: au
    • EEVblog
Re: EEVblog #843 - David's rPrint 3D Printer
« Reply #39 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?
 

Online Fungus

  • Super Contributor
  • ***
  • Posts: 9980
  • Country: 00
Re: EEVblog #843 - David's rPrint 3D Printer
« Reply #40 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.  :-//
 

Offline jnissen

  • Regular Contributor
  • *
  • Posts: 61
Re: EEVblog #843 - David's rPrint 3D Printer
« Reply #41 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. 
 

Offline Synthetase

  • Regular Contributor
  • *
  • Posts: 99
  • Country: au
    • Synthetase's World of Nerd
Re: EEVblog #843 - David's rPrint 3D Printer
« Reply #42 on: January 23, 2016, 01:23:18 am »
Respect!

Offline adcurtin

  • Contributor
  • Posts: 26
Re: EEVblog #843 - David's rPrint 3D Printer
« Reply #43 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.
 

Offline Someone

  • Super Contributor
  • ***
  • Posts: 2105
  • Country: au
Re: EEVblog #843 - David's rPrint 3D Printer
« Reply #44 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.
 

Offline Seppy

  • Administrator
  • *****
  • Posts: 189
  • Country: au
  • Curious
Re: EEVblog #843 - David's rPrint 3D Printer
« Reply #45 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.
 

Offline Seppy

  • Administrator
  • *****
  • Posts: 189
  • Country: au
  • Curious
Re: EEVblog #843 - David's rPrint 3D Printer
« Reply #46 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.
 

Online Kleinstein

  • Super Contributor
  • ***
  • Posts: 6226
  • Country: de
Re: EEVblog #843 - David's rPrint 3D Printer
« Reply #47 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.
 

Offline HAL-42b

  • Frequent Contributor
  • **
  • Posts: 423
Re: EEVblog #843 - David's rPrint 3D Printer
« Reply #48 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.
 

Offline Brumby

  • Supporter
  • ****
  • Posts: 9233
  • Country: au
Re: EEVblog #843 - David's rPrint 3D Printer
« Reply #49 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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf