Thoughts on 3D printer design, and firmware.
davidsaunders
Posts: 1,559
I am getting close to testing my new PropBASIC firmware (in part, as I am waiting on a new stepper motor to arrive). Though I am thinking about some things as far as implementation is concerned for the firmware.
1:Would it be better to use an external memory for G-Code, thus allowing large G-Code with support for M98 and M99 (both using line number and using file methods)? Having the entire G-Code in an external SPI memory would make it easier to do such things.
2:Should I change my extruder to use a stepper instead of a continuous rotation servo? As the melted plastic tends to string anyway I do not see any reason that a Stepper would be better, other than possibly that small steppers cost less, and it would be more consistent with standard 3D printer designs. See NOTE 1 below.
3:I have decided to make one small modification to my 3D printer HW, that is to use two screws on two steppers to drive the vertical axis. This should make for a little more stable print bed (sometimes I do get 0.05mm imperfections with the current layout.
NOTE 1: My primary extruder gave up the ghost on me, the NiChrome element burned out, so I am temporarily using a 3D printing pen as an extruder until I get a new better extruder made.
The HW design as it stands:
I will continue to make small modifications as I figure out better ways to do it with out increasing the price (and especially as I figure out ways to reduce the cost while keeping it just as good or making it better).
Though currently the frame consists of 4 vertical half inch dowels of 12 inches, mounted in a 3/4th inch board at the bottom, with 1/8th inch dowels crossed between the upright dowels to add stability. The Y rails are mounted across the two sides on top of the half inch dowels, and the single X rail is mounted across the linear bearings on the Y axis, there is a single X axis linear bearing with an attached peice of wood for the screw drive mount, and the print head mount. The Z axis rail is oposed to the Z axis drive screw, that is attached to the servo mounted on the base board, the z axis rail is mounted into the base board.
This set up works well, though in the interest of saving people money and making the design more stable I am considering a few changes.
Intended HW Changes:
I am going to add a second Z axis drive screw to lift and lower the print bed, attached to a second stepper that is kept in perfect sync with the first Z axis drive screw. This will make the bed more stable. The second Z axis screw will be on the opposite side of the bed from the current one.
I am going to try an idea to simplify the construction of the 3D printer, it is a strange idea though I think it will work. I am going to see if a frame made from wooden Tinker Toys will do the job as well as the current frame. That will simplify getting it correct for others building the 3D printer design in the future. I am also designing a number of parts that can be printed, modeled after tinker toys, so it makes sense to use them for those that do not have an existing 3D printer.
There are a few other ideas I have, though they are not complete yet.
Unfortunately even after these changes it will still cost almost $140 to build if you have to purchase everything.
Input?
Please give any input on this.
1:Would it be better to use an external memory for G-Code, thus allowing large G-Code with support for M98 and M99 (both using line number and using file methods)? Having the entire G-Code in an external SPI memory would make it easier to do such things.
2:Should I change my extruder to use a stepper instead of a continuous rotation servo? As the melted plastic tends to string anyway I do not see any reason that a Stepper would be better, other than possibly that small steppers cost less, and it would be more consistent with standard 3D printer designs. See NOTE 1 below.
3:I have decided to make one small modification to my 3D printer HW, that is to use two screws on two steppers to drive the vertical axis. This should make for a little more stable print bed (sometimes I do get 0.05mm imperfections with the current layout.
NOTE 1: My primary extruder gave up the ghost on me, the NiChrome element burned out, so I am temporarily using a 3D printing pen as an extruder until I get a new better extruder made.
The HW design as it stands:
I will continue to make small modifications as I figure out better ways to do it with out increasing the price (and especially as I figure out ways to reduce the cost while keeping it just as good or making it better).
Though currently the frame consists of 4 vertical half inch dowels of 12 inches, mounted in a 3/4th inch board at the bottom, with 1/8th inch dowels crossed between the upright dowels to add stability. The Y rails are mounted across the two sides on top of the half inch dowels, and the single X rail is mounted across the linear bearings on the Y axis, there is a single X axis linear bearing with an attached peice of wood for the screw drive mount, and the print head mount. The Z axis rail is oposed to the Z axis drive screw, that is attached to the servo mounted on the base board, the z axis rail is mounted into the base board.
This set up works well, though in the interest of saving people money and making the design more stable I am considering a few changes.
Intended HW Changes:
I am going to add a second Z axis drive screw to lift and lower the print bed, attached to a second stepper that is kept in perfect sync with the first Z axis drive screw. This will make the bed more stable. The second Z axis screw will be on the opposite side of the bed from the current one.
I am going to try an idea to simplify the construction of the 3D printer, it is a strange idea though I think it will work. I am going to see if a frame made from wooden Tinker Toys will do the job as well as the current frame. That will simplify getting it correct for others building the 3D printer design in the future. I am also designing a number of parts that can be printed, modeled after tinker toys, so it makes sense to use them for those that do not have an existing 3D printer.
There are a few other ideas I have, though they are not complete yet.
Unfortunately even after these changes it will still cost almost $140 to build if you have to purchase everything.
Input?
Please give any input on this.
Comments
If its easier, its easier. This is your design decision.
Change means addition development, which means more variables, which increases likelihood of delay. Its your design decision, but I would NOT create a new extruder from scratch (big unknown) when the old one works fine, until the entire project is finished and working.
Is this X or Y or both; is this going to be the same as the Z axis? (can we have a drawing? I'm not familliar with your target). Same is always better, less things to master, and behavior is already known. Is the is the axis floating on a gantry? Are the screws going to affect speed?
Advice: save modifications until "working", as each new change increases development time, number of unknowns, and likehood of problems and delays.
This set up works well, though in the interest of saving people money and making the design more stable I am considering a few changes.
This is a proven method, this is how my Prusa does the Z
Ignore cost until you have it working (as this is development) and reduce cost after you have a something in a working state if at all possible. Making "this design" cheaper is easier than when many aspects are in a state of flux.
Maybe I'm not understanding correctly... but wouldn't it be easier if it was on an SD card instead of a flash chip? Load a gcode file to SD card, pop it in the propeller, run.
I see them in use for smaller sized G-code operations. A turret punch, for example, produces parts with very few G-codes compared to a laser cutter, or mill, both of which frequently employ much larger programs. The exception, of course, is hand coded programs. Both a laser and mill, when programmed by hand, using the more advanced bolt circle, arc, etc... type operations, can employ macros and the G90, 91, 92, coordinate reference operations to great effect!
So then, I wonder how many people will actually author G-code directly for 3D printing? For some basic shapes, hand coded programs would make sense and be possible, viable options. But for most of those shapes, other means and methods work too. 3D printers excel at not so simple things (when the printer is capable), and that's going to boil down to a ton of basic G-code, not so much advanced G-code.
Whether or not macro support makes sense is associated with that, as well as modeling software. I could see people employing more advanced G-code with software written to produce it.
The majority case is software generates a lot of very simple G-code, move, line, etc... and in that case, the most important support attribute is being able to spool a larger program, "drip feed" DNC style, or from storage, such as SD card.
Again, using mill as an example, DNC systems are extremely common. Program sizes are large, always larger than the machine memory. That machine memory is most often used for simple programs, which may well employ those advanced G-codes, and are considered "utility" type programs. Facing off a block of material, machining a piece for a fixture, tool testing, etc...
In the 3D printer sense, having the more advanced G-code support might help with similar kinds of operations. Extruder test, calibration, and so forth, but that's about it.
If it were me, I would insure the system can spool from storage, or buffer serial comms to get at the majority "sweet spot" use case, and both of those will not employ macros, though they may employ the coordinate related G-codes, g90, 91, 92.... The vast majority of cases will require only minimal G-code support, and for the few that might actually support advance G-code output, the option to keep the output basic will still be there.
Early on, G-code sizes were not large. And the machines themselves not all that capable either. A paper tape could hold production / commercial grade programs.
Advances in mill and laser, among others I'm not so familiar with, blew program sizes out of the water! They are huge, and nearly always DNC, or "run from local storage" use cases now.
The move away from direct G-code input continues. Some controllers are now offering splines and other exotic surface types, and software to directly support that is slow in coming and very expensive. Some very specific use cases require it, but where it's not required, the vast majority use case is to just output very long G-code programs and not worry about controller memory and overall capability.
So far, in commercial 3D printers, that trend continues to be true. Again, FWIW.
Edit: One other thing...
My milling experiences all involve large programs. Anything with any kind of surface detail is going to be huge. And if one is micro-machining? Seriously huge. I use Sublime to make minor edits to these programs due to their size. Some of the 3D printer output I've seen is on par with milling, and I think milling is the closest analogous process when considering G-code support levels and returns.
One very common use case is to patch programs together. Take a common operation that required significant software processing time to actualize into G-code, and use it repeatedly by inserting it into some other program, or combine a few together, etc...
Even those won't use macros or any advanced G-code. Having comment support is good though! An operator can search by comment, and comments can be left by programmers / people using software, for these purposes.
Once the big program is done, it's spooled to a machine. 3D prints can take long periods of time, as can milling machines. In my case, days sometimes. Being able to spool from local storage is awesome. No annoying glitches and no dependencies on computers / serial / ethernet links. Nice feature to have, IMHO!
TL;DR version: The vast majority of potential users will not employ macros.
I did not understand any of that. Except perhaps the last part: "The vast majority of potential users will not employ macros."
If I understand correctly:
1) A 3D printer is squirting blobs of stuff on a 2D plane (X, Y). According to some design I have.
2) Then to get into 3D it is squirting blobs of stuff on top of what it laid down before. Just raised up a bit (z)
3) Given that I can create incredibly complex designs in software, think fractal complexity, then the only thing we need from g-code or whatever command system is:
a) Move there, in (X, Y) coordinates on a 2D plane.
b) Squirt stuff.
c) Move up in Z.
Of course said software has to ensure that when moving to (X, Y) and squirting stuff, there is actually something underneath it to support whatever is being squirted.
Am I in any way right in this assessment of the situation?
I have always found these things difficult to write about.
Put another way, where the gcode operations are able to create an entire feature of the part, programs tend to be shorter.
Where that is true, advanced gcode, such as patterns, arcs, sub programs, macros, make or can make good sense. This also means humans are more likely to write them directly too.
Where gcode operations only contribute to a feature, programs get much larger and because things are partially complete, macros and sub programs make much less sense, but some things like arc movement might still make sense.
At the extreme, only the basic and minimum operations are typically used, and programs are very large.
A punch makes a hole, for example. A mill cuts away in layers, just as a 3d printer may build in layers.
The former is simple and typically shorter programs, unless a punch is programmed to nibble at the material... and the latter is much longer prpgrams.
Support for macros and sub programs is nice when humans are writing gcode and it will fit into controller memory.
They ate not useful when computers are writing gcode programs, and those programs won't fit into controller memory, or there is little benefit to having a controller with so much memory.
Spooling us used in the latter case, via setial, network, or local storage.
Please ignore mobile typos...
At one time, controller processing speed as well as spooling speeds both favored more concise gcode. This is still true for some older controllers today.
Advanced gcode constructs assume some benefit from smaller programs and or operator manual data and or program entry.
Both of those do happen, but the norm is utility or prep type activities not so much direct input intended to make parts.
Early in my manufacturing career, I would frequently create gcode on pencil and paper, manually type it in, use macros to get the number of parts I wanted and or arrange them on the material at hand.
Once computer assisted gcode made sense, that practice ended for all but some basics.
Sounds much the same as the the CISC instructions of CPUs that compilers never use.
Time and effort on visualization might be a better feature, along with vwrification, or bounds checking... think print preview.
Even that is best done on the source system, but could be a benefit on the printer.
It's funny. We have nice capable mills here that support all kinds of fantastic things in gcode. Nobody cares!
Oh my God. Now you remind me that I actually did that manual gcode writing thing back in 1983 at a Technical College. Paper tape times! We milled out some spiffy prototypes in plastic, complete with gears and such.
Quite why that company wanted me to do that as an electronic's engineer I never understood. It was a lot of fun to play with such machines anyway.
I was pleased when I could actually use paper tape. I got to the point where I could read the tape, cut, splice, patch, etc.... they would call me when one got damaged. I would read it, look at the print, put the missing ops back in and tape the whole thing back together. I had a little line punch I used to put the byte on blank tape... fun times.
The best was the old machine lacking any real program memory. One made a program loop by taping the ends of the paper tape together. The thing spooled right off the tape a block at a time...
In the modern world if you want to see the differences between one file and another you might use "diff" or "kdiff3" or whatever.
I remember holding two paper tapes, overlaid on each other, up against the light. The light came through both. Then one could see which tape had extra holes, or "not holes" here and there!
We had it all. Backups, version control, branches, diffs, merges. All done with paper tape. Git, eat your heat out!
A fresh roll is good for 180kbytes or so...
An actual loop. Interesting.
That said, if you used an encoder on the servo in a closed loop, it would be possible to get much more exact control, and it'd almost certainly use less power than a stepper, but that would complicate the design too.
The other thing about a continuous rotation servo, I would not trust it to last a very long time in continuous use - they just aren't designed for that.
FIRST
I was not clear in that the 3D printer is working and has done a number of small prints. The original firmware source in PASM got lost (do to my error), and I am doing a ground up rewrite with some better ideas of implementation.
The first version ignored almost everything other than G0, G1, G20, G21, M104, M105, and M114. That is enough to run the 3D printer, though I can do better.
I have been looking at the changes that can be made sence I know that it works.
What I am hearing is that M98, M99 are not often used, and would only benefit hand coded G-Code (as half mine is). So I may not worry about that so much.
Buffering G-Code does still seem like a good option, as it can be stored in a 1MB EEPROM (8M-bit), and printed with out continued connection to the computer.
A stepper for the new extruder seems to be recommended (for precision). I do understand the issue of keeping good control with verrying pull on the filament with a continuous rotation servo.
Thank you all for the input.
I am doing some work on the 3D printer today, as it is down anyway while I wait for the replacement z axis stepper motor. I am also hoping that I can get most of the replacement extruder complete before the replacement Stepper arrives (as stated above, I burned out the NiChrome element in the original, and temporarily have a cheap 3D printing pen in place of it).
Thank you all again. And I am always open to suggestions.
Default Teacup works on an 8 move buffer. While calculating a move, all the necessary data is added to a DDA structure. Once the structure if filled, the structure is then added to a DDA queue. The DDA queue is simply an array of 8 (default) DDA structures. The current move is always the tail (maybe the head), when the move is finished, it is removed from the queue buffer, so that another move may be added to the head.
By default, Teacup receives it's data from a serial connection, but like you, I do not want to be attached to a computer. Instead, I will be using a microSD card to store my GCODE files. During parsing, I will be creating DDA structures and a DDA queue, similar to Teacup.
Just an idea for you.
I will be adding a 1MB SPi EEPROM to the board, finishing up my replacement exruder head assembly, changing 3 lines of code to use a stepper for the extruder (actually add in a conditional compile to allow for either method of filament feeding as well as adding support for the use of a DC motor).
I did have this partially done in PropBasic, full PID, trapezoidal motion profiling, antiphase PWM, encoder frequency > 1MHz, etc. It would require a separate Prop, mind.
Thought it was on my DropBox but can't find it.
At least then we will be able to find it even if you can't
Yeah, I was using tortoisesvn before. I always work from my DropBox folder and I have a subscription that gives me unlimited undeletes so I know that it was never there in the first place.
It all works out though, I have ordered some Wooden Tinker Toys to see about making a new frame that is easier to deal with (also ordered some K'Nex to see if they may help for reducing the cost and simplifying construction). This is important to me as I want this to be something that most people will be able to build with out issue for as low of a cost as possible, while having the print quality, and build volume of the better low cost 3D printers (those that cost around $700 to $1000). The only required skill should be soldering to follow the plans that I intend to give (along with the firmware source [and one version of the binary] once it is good enough).
This has been a lot of fun, even if I have not printed much of any use yet