I finally got around to making my guide for the band saw and gave it a test run....
To my dismay, the guided cuts are not going to work for me. The bronze guides utilized for keeping the blade straight are heavily worn and the blade keeps deflecting at an angle. I could try to true them up or get some new bronze rod to replace, but for now, I am just going to eyeball my cuts and let the sander do it's job.
However I am not completely distraught...
I must say the band saw does a much better job of cutting than I first thought. I tried cutting through much wider aluminum this time around and the band saw breezed right through it. So it is going to be a HUGE time and labor saver, when used in combination with the sander.
I never rely on a saw to make square cuts...I add enough to square the edges after the cut. The sander is a really good way to do this. I have a Vert. Mill to do my dirty work.
'
I also make the parts in Assemblies, The front and rear of the Bridge base, the Right and Left sides of the gantry...etc.
'
I make these parts together, So there exactly the same.
The Assemblies approach is excellent.
Not everything needs to be cut and fit to .001 of an inch.
It is the parallel rails that need to be tightly parallel and the screws or belts that drive motion that require tight specs.
A lot of 3D Printers seem to be simply made with a particle board or plywood box as the main frame and the rest is supported by it.
Yea, me either. Regardless of the saw type, There is always some flexing of the blade. In addition to that, the ends are always to rough for my liking. In all honesty, that sander is just the ticket for a real accurate and clean finish. The accuracy of the sander did not really amaze me that much, because I knew I could make it accurate, but the finished ends sure amazed the heck out of me. If only I had known, I would have bought a sander years ago for this same purpose. The drill press/milling vise combination that I use, is no where near as accurate as that disc sander, and the finish is no where nearly as clean as with the sander.
As previously mentioned, it is good to see you taking part in this thread Walt. I really mean business this time around (providing my idea works ). This design will supersede all other actuator designs I have tried in the past and hopefully soon we can get into the heart of the matter, which is machine control, and of course, other items pertaining to 3D printing.
If were not for lifes other little problems, I would already be head over heels into this project, but I must say, now that I have the band saw and sander, I am really glad I set aside the time to get them setup.
Okay I must admit that I trued the bronze saw guides to at least make a better cut with the saw..... And even then the blade did not cut true, but it cuts quite a bit straighter and the blade hardly flexes.
And then, even though it was not my intention...... Since I was going to wait until I got some other stinky fudge out of the way..... I got ambitious and cut up enough aluminum to make an actuator prototype.
Now, I need to true up the sander, once again and drill some holes.
Check out this guy's ingenious homemade "CNC" machine, which cuts foam airplane wings with a hot nichrome wire. Steppers, allthread leadscrews, drawer slides, wooden frame, G code, the works. Very impressive! I think that a relatively simple project like this might be a good place to start for anyone wanting to build their own CNC machine or 3D printer.
I hear ya. I am going to get a little more done early this morning, but I think I am going to swap out my milling vise either today or tomorrow for drilling more accurate holes. The old milling vise is pretty tattered and I think I will just use that for general purpose drilling. Either way, I will have all the parts for one actuator all ready for drilling. Cutting the slots in the tubing is the hard part and I have tried various methods over the years, but I am trying to come up with a better and faster method.
Check out this guy's ingenious homemade "CNC" machine, which cuts foam airplane wings with a hot nichrome wire. Steppers, allthread leadscrews, drawer slides, wooden frame, G code, the works. Very impressive! I think that a relatively simple project like this might be a good place to start for anyone wanting to build their own CNC machine or 3D printer.
You hit a homerun with this one.... Foamy airplane wings are a huge expense... especially if you crash quite a bit. Plus you get to apply some real engineering -- aerodynamics, fluid mechanics, lift, drag, and air flow.
Now a nice wind tunnel for model airplanes would be the next logical step.
Great video Erco
'
I don't think the simple all-thread lead screws and sliders would work for a CNC router because of the weight of the spindle and the tool pressures. But as a depositor/3D printer, It might just be the ticket as a starter machine to learn and build from.
'
No tool pressure,
'
Adding some grease to the all-thread and sliders would help with the weight of the heater/extruder.
'
I just don't see much more drag on the machine when in 3Dprinter mode.
'
Thanks again
I have an old benchtop CNC that uses 1/4 20 acmE threaded rod and a 1/4" motor and spindle. Delrin nuts. I used to crank out lots of 1" thick aluminum with this machine, some stainless too. Lot's of torque at 20 TPI.
As it turns out, during the process of machining my blanks for the prototype, I came up with a new idea, and had to order a few additional parts. Since I must wait for these parts to arrive before proceeding, I decided to go on a little G-Code reconnaissance. I did not yet want to go as deeply as Loopy did, so I just performed a cursory search.
I reviewed the entire thread, to see if Loopy had posted this link and I could not find the same link. However, if I am just duplicating I apologize. Anyhow this is what I found:
It appears to be very informative with G-Code, pertaining to RepRap 3D printing, as well as other CNC machining. This will probably be one of my main references as I proceed through this project.
At first glance and without ever having printed a 3D object, I surmise that many of the codes are unnecessary for an accurate print, but I could also be highly wrong. This is my assumption because not all printers support all commands. So I therefore assume that all commands supported by all machines are therefore the actual necessary commands for 3D printing.
Hi all,
Just wanted to mention that some progress has been made in porting an actual Arduino 3D printer firmware code in GCC to a binary that the Propeller will load. WE have are first report of 'Build Succeeded', but with an ample list of errors and warnings that will have to be run down. And the binary is less that 20Kb at this point.
While the original target was Teacup firmware, this compile is of a predecessor called Tonokip firmware. It may not be adequate by today's 3D firmware standards, but it is a good place for those that are new to 3D printing to read some actual C code.
Tonokit is intended merely as a stepping stone to developing a Propeller firmware that is completely adequate with compiled Teacup g-code from Slic3r. But I already am aware that Tonokit's parser omited F-codes, G-2, and G-3 codes. So, added code with be necessary. So don't be too concerned with the omissions at this juncture.
I am finding that 3D printing has a rather larger reading and research load. If anyone gets lost, I might be able to reduce that list by what I have discovered.
++++++++++++
Regarding a printhead....
It is a critical component and people have moved into some very sophisticated constructions to enhance its precision. It just may be that trying to DIY one that prints with as good quality would drag down the whole El Cheapo concept. You need a lot of expensive equipment to get this component right.
I have previously vaguely mentioned that there are some expensive 'sub-assemblies'. This one might better be bought than built.
@IDBruce
Your link for RepRap G-codes is quite useful.. I have been using it for a reference for some time now. And it really is a 'must read' for anyone that is going to succeed in 3-D printing. There are times when you will do testing with hand-written g-code as you build and test your project.
...
I reviewed the entire thread, to see if Loopy had posted this link and I could not find the same link. However, if I am just duplicating I apologize. Anyhow this is what I found:
It appears to be very informative with G-Code, pertaining to RepRap 3D printing, as well as other CNC machining. This will probably be one of my main references as I proceed through this project.
...
Apologies accepted I mentioned that page on post #135 of this same thread. Loopy already saw it. And yes we don't need all the codes. If you look at gcode_process.c you can see what codes are used at least in TeaCup.
You need a lot of expensive equipment to get this component right.
Unless I missed something along the way....
There are two basic types, those that heat the filament with a resistor and those that heat the filament with resistance wire. If it is the resistor type, the resistor, temperature sensor, core, and nozzle all go to the same block. And if it is the resistance wire type, the wire wraps around the core, with the nozzle and sensor below the wire wrappings.
In it's simplest form, you have a core, a heating element, a temperature sensor, and a nozzle, not including the cooling fan(s).
The core must be of the proper diameter to feed the filament without problems. The core should also be free from defects, and I would imagine the best way to do this would be with a reamer.
Temperature sensor monitors the temperature to provide proper plastic viscosity, at key locations, such as the nozzle and the core.
For both types of heating elements, ensure that you are using the proper resistance.
The nozzle must be drilled to the appropriate diameter to disperse the liquid plastic correctly for particular your application. Much of this will depend upon the selection of filament and the capability of the extruder.
Sounds pretty simple to me.... In fact, if you follow the designs of successful hot ends, you are bound to also be successful. My design will closely follow the lead of MakerGear's ceramic heater core (http://www.makergear.com/pages/ceramic-heater-core-instructions) with the additon of my own special touches.
However, if you have some info regarding special designs of cores, that have been used successfully, please do share.
@IDbruce
I doubt that I could convince you to buy rather than DIY once you have a vision of doing so, continue on.
My impression of what is easy to build is quite different than yours. I suspect it is equally important to have a large thermal mass so that the melt temperature remains stable reguards of changes in feed rate. And it seems that precise extrusion tips might be made of ceramics rather than metal. Steppers that feed the material require spindels that grip the material. So there are are several aspects that daunted my desire to DIY. Not sure where and why cooling fans are required, unless the stepper motors overheat.
Here is a video of another Propeller CNC project that has actually worked. It is Jazzed's project and he is helping me with a 3D printer driver board at this time. In fact, it looks like he and Martin H. are doing all the heavy lifting and I am just a cheer leader.
I must admit that I have been following Loopy's Teacup thread pretty closely, but I believe I am going to attempt to blaze my own trail.
As mentioned elsewhere, I have had some downtime due to personal injury, and since most of the design work is complete (or at least well enough for prototyping), I have spent some time thinking about the software and control board. I have come to the conclusion, that I do not want to over-complicate stuff at this point, so instead of designing a control board at this point, I am simply going to prototype with a Propeller Proto Board and the Propeller Board of Education.
Additionally, instead of relying on or providing access to an SD card, I will rely on a PC to hold all the necessary files and provide instructions to a Propeller controller. So the only obligation of the Propeller chip will be to interpret and respond to G-codes, as well as control the machine, line by line. I intend to resurrect and alter one of my unfinished projects, which was called "PropCom", and here is a link to a thread which provides information about it: http://forums.parallax.com/showthread.php/133979-Project-In-Progress-New-Serial-Terminal-Taking-Suggestions. Of course this previous project just contains much of the necessary framework, and it will need to be altered and reconfigured for a 3D printing application, but this is the way I see it:
Sliced files are stored on a PC.
These sliced files are opened by a serial terminal which communicates with a Propeller controller board.
The serial terminal sends the Propeller controller the G-code line by line.
The Propeller controller interprets the G-code and controls the machine accordingly.
I believe this is the easiest and simplest route to take, plus it gives me the opportunity, to create a nice GUI for 3D printing. So essentially it boils down to two main problems:
Writing a G-code parser for the Propeller chip.
Make the machine respond appropriately to received G-codes.
I don't believe these items should be too hard to resolve, since there is plenty of free source code to choose from.
As mentioned earlier, I plan to go with one extruder, which puts me at four stepper drivers. Since I already have several spare G251s lying around, I will just stack them for prototyping purposes as described in the thread: http://forums.parallax.com/showthread.php/133309-Propeller-Proto-Board-Stepper-Motor-And-G251-Gecko-Drive-Tip. However, I may make a special plate for stacking these drivers with suitable heatsinks and making it more stable. This arrangement will give me 2.5A per winding per stepper @ 50VDC, which should give me plenty of play for torque or speed.
@IDBruce
I never expected anything less than you blazing your own trail.
@ everyone
The reasons I support a G-code solution are simple.
A. Historically, there are a lot of g-code solutions out there. G-code has a large popular following in 3-D and 2-D design.
B. RepRap is poplular is nearly entirely driven by a software tool chain that requires a compile in G-code to migrate from 3D CAD software to the actual printer.
C. I don't see how anybody with an ambitious 3D printer project will want to depend on a Manual Data Input solution for more than a few test pieces.
There are other 3D printer codes evolving. One that really seems attractive is called Elegant. But while that one day might be a better choice, it doesn't have the whole front-end tool chain yet working.
And then there is item D.
I just wanted to learn to code 3D printing and XYZ CNC from existing open-source code. I am not sure what I will eventually build, but the software knowlege that I have acquired is all useful. My point here is that one can learn a heck of a lot by supporting other people that want to build a project, even if they never actual build the device. So you might say, I am supporting a kind of builder/coder collaboration to help IDBruce get his 3D printer working sooner.
IDBruce is free to develop his own code, but it is difficult to develop code while working on the physical aspect of a build.
Having something in code developed for a Propeller will make it just that much easier to both get started and to add improvements to the code.
We do have a first attempt for 3D Printing on a Propeller. It is Tonokit_with_serial, and can be downloaded and explored by everyone. But it does appear to need further work. And I am trying to create a better solution based on Teacup code.
That will be called Teacup-ette as it will initially be down-sized to fit in the Propeller's hubram. It seems obvious that it is currently too larger in C code and may have to eventually be recoded in all PASM.
Sometimes you just baffle me with the things you say. I am not sure whether you are attacking my solution or just simply publicizing yours. For one, I applaud your efforts, and it is a very ambitious project, and I do not fault you in any way, especially for learning.
My appoach still relies upon g-code and I have no intention of manually inputting data. Here is the scenario of my plan:
STL file is either downloaded from the internet or created on a PC with CAD software.
STL file is then sliced into g-code with a slicing program, such as, Cura, Slic3r, or Kisslicer.
The serial terminal which will provide communication between the PC and the Propeller controller board, will read the g-code file generated by the slicer, line by line, and send the commands to the Propeller controller board, which will tell the printer just exactly what to do.
There is no manual data input and there is no SD card or size limitation, with the exception of the size of the g-code parser on the Propeller. The only downside to my plan is that I must rely on a PC, but that is also a benefit, because I can utilize the PC to run major executables with GUIs for 3D printing.
EDIT: With a 3D printer serial terminal, the only thing really needed is a nice g-code parser for the Propeller chip and a common Propeller 3D printer setup.
In reference to Posts #174 and #172, when I am not busy doing other things, I intend to start build a new serial terminal specifically for 3D printing. I will start off simple, by parsing g-code files and displaying the commands on an LCD attached to a Propeller. I think that is a very good starting point. And perhaps I will add an input button which will inform the serial terminal to send the next g-code command.
Sometimes you just baffle me with the things you say. I am not sure whether you are attacking my solution or just simply publicizing yours. For one, I applaud your efforts, and it is a very ambitious project, and I do not fault you in any way, especially for learning.
Sorry about that... having these projects in parallel, I can't quite keep up with all you are doing on the building side. Sometimes I do take comments wrongly, or my info is a bit behind where you are.
Slic3r is the only slicer I am working with. Kisslicer may be more sophisticated and require codes that I may not include in the g-code parser. (I had to start somewhere). Actually, it isn't g-codes that are a problem so much as the m-codes as there are lots and lots that may or may not be supported. The more that are used, the more they eat up hubram space.
A 3D Printer serial terminal might manage an SD card download if built on a Propeller.
+++++++++++
I'd love to include all and everything that everybody desires, but 'in the beginning' limitations just need to be asserted in order to get something working that indicates what else can be included.
Where they mount the fan is totally useless for what you need a fan for ,the fan keeps the heat from creeping up the the feed tube ,I'll post a picture of my setup later to see what I mean.
Okay, I am curious.... How well does the direct drive extruder push the filament? What size or type of NEMA 17 is on the back of it? What kind of feed rate can you get from it? Does it ever struggle rotating the spool?
I ask these questions, because I have been thinking of gearing down the extruder, instead of going with direct drive. However with a big NEMA 17, I think direct drive might be fairly dependable, but I wonder about the feedrate when pushing all the other axises to the extremes.
Okay, so I finally got around to visiting the github website and took a peek at the teacup software. I must say that a lot of effort went into that programming and perhaps I underestimated the depth of control necessary for 3D printing, or perhaps the code is overly complicated. I am not sure which is true at the moment.
Okay so we all know that the g-code must be parsed and the machine must follow the g-code to make a close representation of the model. From what I have found, there is not yet a perfect solution for any aspect of 3D printing, however it appears that the Teacup firmware has earned some respect.
I do not own a 3D printer, nor have I ever run one or even seen one run, besides on video, so needless to say that I am not expert, however I do my homework. In my opinion, the whole key to successful 3D printing can be summarized as:
Extrude the plastic at a rate of speed in direct proportion to the speed of X and Y axises, along a specified path of travel.
Of course, this statement is greatly over-simplying all the pertinent issues, but how hard can this be and is all that coding really necessary? I would have to say that I don't think so, or at least not for my machine. I also guess that much of it would depend on how many different types of machines that you want to support and just how many options that you want to provide. For example, it should be much easier to write the control software for one machine with a specific type of setup, as compared to writing software that will work on a variety of machines. And as we know, Teacup supports many options, and I sincerely believe that this is where the complexity and size of the code comes into play. I can only imagine how much code could be eliminated, if specified a given speed and travel for X, Y, Z, and E, but then that would also limit the usefulness of the firmware. Of course I am only guessing, because I have never run the software.
Comments
To my dismay, the guided cuts are not going to work for me. The bronze guides utilized for keeping the blade straight are heavily worn and the blade keeps deflecting at an angle. I could try to true them up or get some new bronze rod to replace, but for now, I am just going to eyeball my cuts and let the sander do it's job.
However I am not completely distraught...
I must say the band saw does a much better job of cutting than I first thought. I tried cutting through much wider aluminum this time around and the band saw breezed right through it. So it is going to be a HUGE time and labor saver, when used in combination with the sander.
End result, I am a very happy guy
'
I also make the parts in Assemblies, The front and rear of the Bridge base, the Right and Left sides of the gantry...etc.
'
I make these parts together, So there exactly the same.
Not everything needs to be cut and fit to .001 of an inch.
It is the parallel rails that need to be tightly parallel and the screws or belts that drive motion that require tight specs.
A lot of 3D Printers seem to be simply made with a particle board or plywood box as the main frame and the rest is supported by it.
Yea, me either. Regardless of the saw type, There is always some flexing of the blade. In addition to that, the ends are always to rough for my liking. In all honesty, that sander is just the ticket for a real accurate and clean finish. The accuracy of the sander did not really amaze me that much, because I knew I could make it accurate, but the finished ends sure amazed the heck out of me. If only I had known, I would have bought a sander years ago for this same purpose. The drill press/milling vise combination that I use, is no where near as accurate as that disc sander, and the finish is no where nearly as clean as with the sander.
As previously mentioned, it is good to see you taking part in this thread Walt. I really mean business this time around (providing my idea works ). This design will supersede all other actuator designs I have tried in the past and hopefully soon we can get into the heart of the matter, which is machine control, and of course, other items pertaining to 3D printing.
If were not for lifes other little problems, I would already be head over heels into this project, but I must say, now that I have the band saw and sander, I am really glad I set aside the time to get them setup.
Okay I must admit that I trued the bronze saw guides to at least make a better cut with the saw..... And even then the blade did not cut true, but it cuts quite a bit straighter and the blade hardly flexes.
And then, even though it was not my intention...... Since I was going to wait until I got some other stinky fudge out of the way..... I got ambitious and cut up enough aluminum to make an actuator prototype.
Now, I need to true up the sander, once again and drill some holes.
I was getting impatient
You hit a homerun with this one.... Foamy airplane wings are a huge expense... especially if you crash quite a bit. Plus you get to apply some real engineering -- aerodynamics, fluid mechanics, lift, drag, and air flow.
Now a nice wind tunnel for model airplanes would be the next logical step.
'
I don't think the simple all-thread lead screws and sliders would work for a CNC router because of the weight of the spindle and the tool pressures. But as a depositor/3D printer, It might just be the ticket as a starter machine to learn and build from.
'
No tool pressure,
'
Adding some grease to the all-thread and sliders would help with the weight of the heater/extruder.
'
I just don't see much more drag on the machine when in 3Dprinter mode.
'
Thanks again
I reviewed the entire thread, to see if Loopy had posted this link and I could not find the same link. However, if I am just duplicating I apologize. Anyhow this is what I found:
At first glance and without ever having printed a 3D object, I surmise that many of the codes are unnecessary for an accurate print, but I could also be highly wrong. This is my assumption because not all printers support all commands. So I therefore assume that all commands supported by all machines are therefore the actual necessary commands for 3D printing.
Just wanted to mention that some progress has been made in porting an actual Arduino 3D printer firmware code in GCC to a binary that the Propeller will load. WE have are first report of 'Build Succeeded', but with an ample list of errors and warnings that will have to be run down. And the binary is less that 20Kb at this point.
While the original target was Teacup firmware, this compile is of a predecessor called Tonokip firmware. It may not be adequate by today's 3D firmware standards, but it is a good place for those that are new to 3D printing to read some actual C code.
Tonokit is intended merely as a stepping stone to developing a Propeller firmware that is completely adequate with compiled Teacup g-code from Slic3r. But I already am aware that Tonokit's parser omited F-codes, G-2, and G-3 codes. So, added code with be necessary. So don't be too concerned with the omissions at this juncture.
I am finding that 3D printing has a rather larger reading and research load. If anyone gets lost, I might be able to reduce that list by what I have discovered.
++++++++++++
Regarding a printhead....
It is a critical component and people have moved into some very sophisticated constructions to enhance its precision. It just may be that trying to DIY one that prints with as good quality would drag down the whole El Cheapo concept. You need a lot of expensive equipment to get this component right.
I have previously vaguely mentioned that there are some expensive 'sub-assemblies'. This one might better be bought than built.
@IDBruce
Your link for RepRap G-codes is quite useful.. I have been using it for a reference for some time now. And it really is a 'must read' for anyone that is going to succeed in 3-D printing. There are times when you will do testing with hand-written g-code as you build and test your project.
Apologies accepted I mentioned that page on post #135 of this same thread. Loopy already saw it. And yes we don't need all the codes. If you look at gcode_process.c you can see what codes are used at least in TeaCup.
Alex
Unless I missed something along the way....
There are two basic types, those that heat the filament with a resistor and those that heat the filament with resistance wire. If it is the resistor type, the resistor, temperature sensor, core, and nozzle all go to the same block. And if it is the resistance wire type, the wire wraps around the core, with the nozzle and sensor below the wire wrappings.
In it's simplest form, you have a core, a heating element, a temperature sensor, and a nozzle, not including the cooling fan(s).
- The core must be of the proper diameter to feed the filament without problems. The core should also be free from defects, and I would imagine the best way to do this would be with a reamer.
- Temperature sensor monitors the temperature to provide proper plastic viscosity, at key locations, such as the nozzle and the core.
- For both types of heating elements, ensure that you are using the proper resistance.
- The nozzle must be drilled to the appropriate diameter to disperse the liquid plastic correctly for particular your application. Much of this will depend upon the selection of filament and the capability of the extruder.
Sounds pretty simple to me.... In fact, if you follow the designs of successful hot ends, you are bound to also be successful. My design will closely follow the lead of MakerGear's ceramic heater core (http://www.makergear.com/pages/ceramic-heater-core-instructions) with the additon of my own special touches.However, if you have some info regarding special designs of cores, that have been used successfully, please do share.
"Just for reference on gcode: http://reprap.org/wiki/G-code#Introduction"
I mentioned the same page in post #40
dgately
I doubt that I could convince you to buy rather than DIY once you have a vision of doing so, continue on.
My impression of what is easy to build is quite different than yours. I suspect it is equally important to have a large thermal mass so that the melt temperature remains stable reguards of changes in feed rate. And it seems that precise extrusion tips might be made of ceramics rather than metal. Steppers that feed the material require spindels that grip the material. So there are are several aspects that daunted my desire to DIY. Not sure where and why cooling fans are required, unless the stepper motors overheat.
Here is a video of another Propeller CNC project that has actually worked. It is Jazzed's project and he is helping me with a 3D printer driver board at this time. In fact, it looks like he and Martin H. are doing all the heavy lifting and I am just a cheer leader.
https://www.youtube.com/watch?v=p3lZaYeUGFg
LOL Sorry to you also. I can't believe I missed two posts..... Yea I can, I was zipping through it during my review
'
https://www.youtube.com/watch?v=p3lZaYeUGFg
'
I really like the G-Code GUI.
'
Has Jazzed posted any software/hardware on his set-up?
As mentioned elsewhere, I have had some downtime due to personal injury, and since most of the design work is complete (or at least well enough for prototyping), I have spent some time thinking about the software and control board. I have come to the conclusion, that I do not want to over-complicate stuff at this point, so instead of designing a control board at this point, I am simply going to prototype with a Propeller Proto Board and the Propeller Board of Education.
Additionally, instead of relying on or providing access to an SD card, I will rely on a PC to hold all the necessary files and provide instructions to a Propeller controller. So the only obligation of the Propeller chip will be to interpret and respond to G-codes, as well as control the machine, line by line. I intend to resurrect and alter one of my unfinished projects, which was called "PropCom", and here is a link to a thread which provides information about it: http://forums.parallax.com/showthread.php/133979-Project-In-Progress-New-Serial-Terminal-Taking-Suggestions. Of course this previous project just contains much of the necessary framework, and it will need to be altered and reconfigured for a 3D printing application, but this is the way I see it:
- Sliced files are stored on a PC.
- These sliced files are opened by a serial terminal which communicates with a Propeller controller board.
- The serial terminal sends the Propeller controller the G-code line by line.
- The Propeller controller interprets the G-code and controls the machine accordingly.
I believe this is the easiest and simplest route to take, plus it gives me the opportunity, to create a nice GUI for 3D printing. So essentially it boils down to two main problems:- Writing a G-code parser for the Propeller chip.
- Make the machine respond appropriately to received G-codes.
I don't believe these items should be too hard to resolve, since there is plenty of free source code to choose from.As mentioned earlier, I plan to go with one extruder, which puts me at four stepper drivers. Since I already have several spare G251s lying around, I will just stack them for prototyping purposes as described in the thread: http://forums.parallax.com/showthread.php/133309-Propeller-Proto-Board-Stepper-Motor-And-G251-Gecko-Drive-Tip. However, I may make a special plate for stacking these drivers with suitable heatsinks and making it more stable. This arrangement will give me 2.5A per winding per stepper @ 50VDC, which should give me plenty of play for torque or speed.
EDIT: I found a nice reference site for 3D printing (http://reprapmagazine.com), and on page 14 of issue 1 of their magazine, they compare three different slicers, Cura, Slic3r, and Kisslicer. I would consider this a must read for those choosing a slicer. Here is a link to a PDF of Issue 1: http://s3-eu-west-1.amazonaws.com/reprapmagazine/RepRapMagazine_Issue_1.pdf
I never expected anything less than you blazing your own trail.
@ everyone
The reasons I support a G-code solution are simple.
A. Historically, there are a lot of g-code solutions out there. G-code has a large popular following in 3-D and 2-D design.
B. RepRap is poplular is nearly entirely driven by a software tool chain that requires a compile in G-code to migrate from 3D CAD software to the actual printer.
C. I don't see how anybody with an ambitious 3D printer project will want to depend on a Manual Data Input solution for more than a few test pieces.
There are other 3D printer codes evolving. One that really seems attractive is called Elegant. But while that one day might be a better choice, it doesn't have the whole front-end tool chain yet working.
And then there is item D.
I just wanted to learn to code 3D printing and XYZ CNC from existing open-source code. I am not sure what I will eventually build, but the software knowlege that I have acquired is all useful. My point here is that one can learn a heck of a lot by supporting other people that want to build a project, even if they never actual build the device. So you might say, I am supporting a kind of builder/coder collaboration to help IDBruce get his 3D printer working sooner.
IDBruce is free to develop his own code, but it is difficult to develop code while working on the physical aspect of a build.
Having something in code developed for a Propeller will make it just that much easier to both get started and to add improvements to the code.
We do have a first attempt for 3D Printing on a Propeller. It is Tonokit_with_serial, and can be downloaded and explored by everyone. But it does appear to need further work. And I am trying to create a better solution based on Teacup code.
That will be called Teacup-ette as it will initially be down-sized to fit in the Propeller's hubram. It seems obvious that it is currently too larger in C code and may have to eventually be recoded in all PASM.
Best wishes.
Sometimes you just baffle me with the things you say. I am not sure whether you are attacking my solution or just simply publicizing yours. For one, I applaud your efforts, and it is a very ambitious project, and I do not fault you in any way, especially for learning.
My appoach still relies upon g-code and I have no intention of manually inputting data. Here is the scenario of my plan:
- STL file is either downloaded from the internet or created on a PC with CAD software.
- STL file is then sliced into g-code with a slicing program, such as, Cura, Slic3r, or Kisslicer.
- The serial terminal which will provide communication between the PC and the Propeller controller board, will read the g-code file generated by the slicer, line by line, and send the commands to the Propeller controller board, which will tell the printer just exactly what to do.
There is no manual data input and there is no SD card or size limitation, with the exception of the size of the g-code parser on the Propeller. The only downside to my plan is that I must rely on a PC, but that is also a benefit, because I can utilize the PC to run major executables with GUIs for 3D printing.EDIT: With a 3D printer serial terminal, the only thing really needed is a nice g-code parser for the Propeller chip and a common Propeller 3D printer setup.
Sorry about that... having these projects in parallel, I can't quite keep up with all you are doing on the building side. Sometimes I do take comments wrongly, or my info is a bit behind where you are.
Slic3r is the only slicer I am working with. Kisslicer may be more sophisticated and require codes that I may not include in the g-code parser. (I had to start somewhere). Actually, it isn't g-codes that are a problem so much as the m-codes as there are lots and lots that may or may not be supported. The more that are used, the more they eat up hubram space.
A 3D Printer serial terminal might manage an SD card download if built on a Propeller.
+++++++++++
I'd love to include all and everything that everybody desires, but 'in the beginning' limitations just need to be asserted in order to get something working that indicates what else can be included.
MakerSlide , open source and priced right:
https://www.inventables.com/technologies/makerslide
This is by far the best value drive system and extruder out there (for the money), even if you plan on using a j-head you need a good feed system:
http://www.amazon.com/0-3mm-Nozzle-Printer-Extruder-Print/dp/B00D2ITYDQ/ref=sr_1_6?ie=UTF8&qid=1397839653&sr=8-6&keywords=3d+extruder
Where they mount the fan is totally useless for what you need a fan for ,the fan keeps the heat from creeping up the the feed tube ,I'll post a picture of my setup later to see what I mean.
Brian
Here is my extruder ,thermal break kept low w/fan cooling it ,the inside of the feed tube is lined with PTFE
Brian
'
Thanks for the info about the cooling fan.
Yea thanks for sharing....
Okay, I am curious.... How well does the direct drive extruder push the filament? What size or type of NEMA 17 is on the back of it? What kind of feed rate can you get from it? Does it ever struggle rotating the spool?
I ask these questions, because I have been thinking of gearing down the extruder, instead of going with direct drive. However with a big NEMA 17, I think direct drive might be fairly dependable, but I wonder about the feedrate when pushing all the other axises to the extremes.
Okay so we all know that the g-code must be parsed and the machine must follow the g-code to make a close representation of the model. From what I have found, there is not yet a perfect solution for any aspect of 3D printing, however it appears that the Teacup firmware has earned some respect.
I do not own a 3D printer, nor have I ever run one or even seen one run, besides on video, so needless to say that I am not expert, however I do my homework. In my opinion, the whole key to successful 3D printing can be summarized as: