@Walt,
Thanks'
@idbruce,
The reason I went with the china drive system from amazon is because it has roller on the pressure side of filament (less friction), Everyone likes to use a friction tensioner and that just causes binding problems. I threw away the stepper that came with it and installed a high torque NEMA 17 from http://store.quintessentialuniversalbuildingdevice.com/category.php?id_category=16
The thing I learned early on was that as the heat creeps up the feed tube the filament starts to jam up ,so do every thing you can to keep the heat at the tip of the extruder , my cooling fan sucks air through the cooling fins instead of blowing it ,I didn't want extra air cooling the tip.
I don't know what the fastest feed rate I ever gotten with this setup up ,but I've ran really fast and had to slow it down because the printer kept almost falling off the table and it still feed reliable.
I have been leaning toward a geared down version, but thanks to your input, I believe I will now first try a direct drive, especially since it will be cheaper to build and less complicated.
I hate to be a pest, but I want to know what really works. There are three NEMA 17 motors on that page, which one did you choose? The one with the highest holding torque or the 4.5kg * cm?
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.
The velocity of the axes (correct plural term, BTW) does not come in to it. It's the vector velocity you need to be concerned with.
The velocity of the axes (correct plural term, BTW) does not come in to it. It's the vector velocity you need to be concerned with.
Thanks for setting me straight on the plurality of axis, I should have looked that up before using my own spelling
As far as vector velocity goes, I also stand corrected on that issue. Thanks for pointing that out. If I understand you and the theory correctly, I would have to compensate for acceleration/deceleration over time to extrude the plastic properly. Is that what you are trying to tell me?
idbruce ,
the 4.5 kg cm , this companys name was qu-bd and they had a ton of problems (financial) .I never had a problem receiving my parts ,but buyer beware.
In between the lingering pain from my injuries, dealing with pressing issues, and handling a couple setbacks, I managed to get quite close.
After getting the bandsaw and sander all setup, and getting my blanks ready, the sander started to develop a bearing squeal. Upon close inspection, I discovered that a bearing flange had been bent prior to my my receipt of the machine, so of course I had to fix that, and now it runs as good as new, or at least I hope.
Additionally I had to also create a router guide to machine some of my pieces, which is now complete. The only thing stopping me now is an overdue order of sandpaper from Fastenal. It was supposed to be in last week, but all I got was excuses. Anyhow, if it isn't in soon, I will just have to find another source.
Thanks for setting me straight on the plurality of axis, I should have looked that up before using my own spelling
As far as vector velocity goes, I also stand corrected on that issue. Thanks for pointing that out. If I understand you and the theory correctly, I would have to compensate for acceleration/deceleration over time to extrude the plastic properly. Is that what you are trying to tell me?
Glossing over or missing way too much, bud. Control of this type of equipment is a mammoth task. I want to suggest a coprocessor that makes way more sense than I'm reading here. Will PM you.
@Mickster
'
I just don't see the layered G-code that hard to deal with.
'
The Cad software that has to create the layers of G-code is a little different story. I don't see that to be the task of this post.
I have been poking around the Teacup firmware for several hours.... From what I seen, there are quite a few things to consider, but I definitely think a parsing and printing solution can be accomplished with portions of their code and a little custom code. I am still trying to piece it all together, but the biggest problem that I think I foresee is preprocessing the commands for speed, however I could be misinterpreting the overview I got so far.
I believe there is a lot to be learned from the Teacup firmware, but I don't necessarily believe that is the optimum solution for what I envision. I still think that an on-board or off-board computer is the best alternative, feeding g-code to the Propeller by serial terminal and let the Propeller control the machine and movements.
Another problem that I foresee is that I am taking a narrow minded approach to hardware and setup, and it probably wont run a wide array of printers. To keep the Propeller code to a minimum size, I will be primarily targeting the specifications of my machine. However as I go along, I will provide any code as open source, just in case someone else wants to take a gander.
I just wish I had my machine built and was able to play around with some code
@Mickster
'
I just don't see the layered G-code that hard to deal with.
'
The Cad software that has to create the layers of G-code is a little different story. I don't see that to be the task of this post.
Are you proposing to have gcodes for every motor step or will there be interpolation required?
Are you proposing to have gcodes for every motor step or will there be interpolation required?
At first glance, it appears that the various DDA files of the Teacup firmware figures out the interpolation, but it also appears that it will be difficult to decipher and port. I still need to examine it more to be sure that is where it is located.
I looked at the Teacup firmware a little more this morning, and once again, I came to the conclusion that I want to try and blaze my own trail. I can always go back to Teacup if I fail, but I think it would be much easier trying to write controlling software from scratch, as compared to porting what I think is necessary for my project. However, I will still probably port the parser, just to speed things up a little.
For the control software, I think I will revert back to the lessons I learned from PulseTheStepPin. By processing values ahead of time, and inserting them into the function, I think I can create smooth movement profiles or at least I intend to try. Going back to Post #181 where I stated that in my opinion, the whole key to successful 3D printing could 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.
I now realize after Mickster's comments, that timing is everything. I don't know if that was his intent, but that is what I walked away with. Once I get the machine built, I am going to attempt to preprocess some values, and insert those values into PulseTheStepPin for X, Y, Z, and E "axes", and attempt to create smooth moving profiles that deposit the correct amount of extruded plastic. If I can pull it off, it would be like hitting the Easy Button, as compared to deciphering a bunch of computer code. I think it is "doable".
EDIT - ADDED: From this point down.
Many of you are probably aware of the PulseTheStepPin function, and others will not be. Over a period of time, the original function had been changed numerous times to fit my particular needs. When I got to a certain point, and when the push for "Golden" OBEX objects was a goal in the forum, I attempted to create one of these golden objects, but once again the work went unfinished, however it is very close to being finished. For those that may be interested, here is a link to the unfinished object: http://forums.parallax.com/showthread.php/138282-StepperDriveErz?p=1095275&viewfull=1#post1095275
Concerning this particular post, I will be attempting to modify DriverF of that file for my control software.
EDIT - ADDED: From this point down.
With this driver or should I say an altered version of this driver, I believe I can create orchestrated movement for X, Y, Z, and E, and I believe the biggest problem will be preprocessing the values for ready acceptance by the driver. On the other hand, if a move has been completed and the next set of values have not yet been determined, printing will simply have to pause until the next set of values is ready for execution.
By all means feel free to explore alternatives. Meanwhile, I will plod along with my own vison of a Teacup-ette.
Smooth movement is critical and the Propeller may just offer some better solutions due to having all the parallel processors. Teacup just affords me a way to learn all the features that the 3D printer community is expecting to be provided.
I don't think a g-code for every motor step is supported by the Slice compiler software, but I may be wrong. G-code files could get huge. (I already have a 42mm sphere with hole that is 1.2Mb). It also would imply that print speed would be entirely controlled by the baud rate and fast response to baud rate.
+++++++++++
If I wanted to enhance Propeller performance, I suspect I would have a g-code pre-processor convert all the floating point decimal to 32bit binary values taylor fit to the printer. As it is, every G1 call (which is 95% of the file code, has an X, Y, and E floating point conversion with occasional calls to Z and F for such. All the linear interpolation could be done in binary, even curve interpolation if G2 and G3 were to be included.
And at least in Linux, it would be easy to write a program to convert these floating point values to binary. Of course, then the queistion become of how to actually transmit the binary over serial. Hexadecimal might be best. And a packet scheme to assure proper transmission and reception. Suddenly it gets to be a bigger project. But it still might perform faster and better.
The pre-processor could be written in Python for any platrom (Apple, Windows, or Linux).
Mmmmm, no! My company designed and built the original controls for THIS. Some models feature 8-axes which all get refreshed with new position commands at a rate of 1KHz. This was in the '90's, not fast by today's standards.
Ya, when you asked about accel/decel? There isn't any. The rate at which the position commands change dictate this but I asked about the rate at which you expect updates to happen because that will dictate whether you will need to interpolate or not. I.e. if you get a command to increment X and Y and they are not equal distances, you need to have them start and finish that segment simultaneously. The info I sent over PM? That uses a different technique; the position commands can be 30Hz, 60Hz,120Hz but the coprocessors interpolate between those positions at 2KHz.
I am still wondering what causes the jaggies that all the budget 3d printers seem to produce....low resolution position commands or low res drive systems (steppers)?
I am still wondering what causes the jaggies that all the budget 3d printers seem to produce....low resolution position commands or low res drive systems (steppers)?
I was wondering that myself. I am sure that could be some it, but I also think it is probably due to a lack of encasement or mold and the extruded diameter of the plastic, but again I am just guessing.
Limit and over-travel switches/sensors are definitely part of the 3d printing industry. However since it is also applicable to other types of CNC machinery, I started another thread to discuss this specific topic. To view this topic, please refer to the following thread:
EDIT: Since making this post, I have started another thread which discusses creating a CNC (3D printer) controller from two Propeller Proto Boards. If you are thinking of making your own 3D printer, you may also want to look at this thread:
Approximately two weeks later and I finally received my sandpaper order from Fastenal.... All I can say is WOW... Additonally, one of the sanding discs was damaged
Oh well, it is what it is.
Anyhow, I am much happier now that I have at least four sanding discs to start my fabrication. It is now time to recalibrate the sander to pin point accuracy and begin making my prototypes.
I am still wondering what causes the jaggies that all the budget 3d printers seem to produce....low resolution position commands or low res drive systems (steppers)?
Well a 1.8 deg stepper via a 15 tooth T2.5 sprocket has about 0.19mm resolution... With microstepping you should get
down to 0.05mm perhaps, but belt backlash is an issue. CNC machines tend to use leadscrews which give much more
resolution.
CNC machines tend to use leadscrews which give much more resolution.
I am certainly in no position to argue that point, however it is my understanding that the Gates GT2 is one of the most accurate belts out there for positioning.
As for one of the most important issues, speed must me considered, as well as torque and accuracy. I may end up regretting the choice to use belts for the X and Y axes, but for now, my goal is surely print speed, which the belts should provide. However without the mechanical advantage gained from a screw driven system, I may end up going slower than a screw drive Oh well, at this point I am locked into GT2 belt drives for X and Y. We will see what kind of output these belts can provide.
Print time should certainly be taken into consideration when selecting a drive.
For a printer a belt is ok. Different thing is a mill for metal. A printer in principle has no acting force beside acceleration of the table and positioning is in the range of 1/10th of a mm. In milling the problem is to have the chips of equal thickness as the cutting forces vary very much with feed rate per teeth. Variation in cutting forces leads to deviation of the path and excitation of high frequency vibrations what can be seen as marks on the workpiece.
Routing in wood or cutting pcb's normally has lower forces and so the requirements to the driving means are not so critical.
Floating point calculations can be off-loaded to a dedicated FPU processor.
Have you ever used one of the FPU processors? I am just wondering how beneficial it would be to invest in one or more for all the floating point calculations.
In working with numerical control I never really needed floating point. 32bit gives you 64k*64k of resolution. That for a table top machine should be enough. There is only one reason to have very high range: precision when doing the computation of step. To interpolate x=10, y=9 you somewhere have to miss one step. And as this example shows: there is free choice were to omit one step: at the beginning, in the middle, at the end. As the steps in the end are integer, floating point calculation doesn't solve this problem.
Comments
Thanks'
@idbruce,
The reason I went with the china drive system from amazon is because it has roller on the pressure side of filament (less friction), Everyone likes to use a friction tensioner and that just causes binding problems. I threw away the stepper that came with it and installed a high torque NEMA 17 from
http://store.quintessentialuniversalbuildingdevice.com/category.php?id_category=16
The thing I learned early on was that as the heat creeps up the feed tube the filament starts to jam up ,so do every thing you can to keep the heat at the tip of the extruder , my cooling fan sucks air through the cooling fins instead of blowing it ,I didn't want extra air cooling the tip.
I don't know what the fastest feed rate I ever gotten with this setup up ,but I've ran really fast and had to slow it down because the printer kept almost falling off the table and it still feed reliable.
Brian
Okay just so we are on the same page...
I use a 1Kg roll of 1.75mm PLA , my roll hangs slightly above the extruder and the x,y motion of the machine almost pulls it off to fast.
Brian
Thanks Brian....
I have been leaning toward a geared down version, but thanks to your input, I believe I will now first try a direct drive, especially since it will be cheaper to build and less complicated.
I hate to be a pest, but I want to know what really works. There are three NEMA 17 motors on that page, which one did you choose? The one with the highest holding torque or the 4.5kg * cm?
The velocity of the axes (correct plural term, BTW) does not come in to it. It's the vector velocity you need to be concerned with.
Thanks for setting me straight on the plurality of axis, I should have looked that up before using my own spelling
As far as vector velocity goes, I also stand corrected on that issue. Thanks for pointing that out. If I understand you and the theory correctly, I would have to compensate for acceleration/deceleration over time to extrude the plastic properly. Is that what you are trying to tell me?
the 4.5 kg cm , this companys name was qu-bd and they had a ton of problems (financial) .I never had a problem receiving my parts ,but buyer beware.
Brian
Thanks for the info
After getting the bandsaw and sander all setup, and getting my blanks ready, the sander started to develop a bearing squeal. Upon close inspection, I discovered that a bearing flange had been bent prior to my my receipt of the machine, so of course I had to fix that, and now it runs as good as new, or at least I hope.
Additionally I had to also create a router guide to machine some of my pieces, which is now complete. The only thing stopping me now is an overdue order of sandpaper from Fastenal. It was supposed to be in last week, but all I got was excuses. Anyhow, if it isn't in soon, I will just have to find another source.
I will begin the build very soon.
Glossing over or missing way too much, bud. Control of this type of equipment is a mammoth task. I want to suggest a coprocessor that makes way more sense than I'm reading here. Will PM you.
'
I just don't see the layered G-code that hard to deal with.
'
The Cad software that has to create the layers of G-code is a little different story. I don't see that to be the task of this post.
I believe there is a lot to be learned from the Teacup firmware, but I don't necessarily believe that is the optimum solution for what I envision. I still think that an on-board or off-board computer is the best alternative, feeding g-code to the Propeller by serial terminal and let the Propeller control the machine and movements.
Another problem that I foresee is that I am taking a narrow minded approach to hardware and setup, and it probably wont run a wide array of printers. To keep the Propeller code to a minimum size, I will be primarily targeting the specifications of my machine. However as I go along, I will provide any code as open source, just in case someone else wants to take a gander.
I just wish I had my machine built and was able to play around with some code
Are you proposing to have gcodes for every motor step or will there be interpolation required?
At first glance, it appears that the various DDA files of the Teacup firmware figures out the interpolation, but it also appears that it will be difficult to decipher and port. I still need to examine it more to be sure that is where it is located.
For the control software, I think I will revert back to the lessons I learned from PulseTheStepPin. By processing values ahead of time, and inserting them into the function, I think I can create smooth movement profiles or at least I intend to try. Going back to Post #181 where I stated that in my opinion, the whole key to successful 3D printing could be summarized as:
EDIT - ADDED: From this point down.
Many of you are probably aware of the PulseTheStepPin function, and others will not be. Over a period of time, the original function had been changed numerous times to fit my particular needs. When I got to a certain point, and when the push for "Golden" OBEX objects was a goal in the forum, I attempted to create one of these golden objects, but once again the work went unfinished, however it is very close to being finished. For those that may be interested, here is a link to the unfinished object: http://forums.parallax.com/showthread.php/138282-StepperDriveErz?p=1095275&viewfull=1#post1095275
Concerning this particular post, I will be attempting to modify DriverF of that file for my control software.
EDIT - ADDED: From this point down.
With this driver or should I say an altered version of this driver, I believe I can create orchestrated movement for X, Y, Z, and E, and I believe the biggest problem will be preprocessing the values for ready acceptance by the driver. On the other hand, if a move has been completed and the next set of values have not yet been determined, printing will simply have to pause until the next set of values is ready for execution.
Of course, this is all speculation at this point.
Smooth movement is critical and the Propeller may just offer some better solutions due to having all the parallel processors. Teacup just affords me a way to learn all the features that the 3D printer community is expecting to be provided.
I don't think a g-code for every motor step is supported by the Slice compiler software, but I may be wrong. G-code files could get huge. (I already have a 42mm sphere with hole that is 1.2Mb). It also would imply that print speed would be entirely controlled by the baud rate and fast response to baud rate.
+++++++++++
If I wanted to enhance Propeller performance, I suspect I would have a g-code pre-processor convert all the floating point decimal to 32bit binary values taylor fit to the printer. As it is, every G1 call (which is 95% of the file code, has an X, Y, and E floating point conversion with occasional calls to Z and F for such. All the linear interpolation could be done in binary, even curve interpolation if G2 and G3 were to be included.
And at least in Linux, it would be easy to write a program to convert these floating point values to binary. Of course, then the queistion become of how to actually transmit the binary over serial. Hexadecimal might be best. And a packet scheme to assure proper transmission and reception. Suddenly it gets to be a bigger project. But it still might perform faster and better.
The pre-processor could be written in Python for any platrom (Apple, Windows, or Linux).
When Mickster said:
I believe he was trying to be facetious.
Mmmmm, no! My company designed and built the original controls for THIS. Some models feature 8-axes which all get refreshed with new position commands at a rate of 1KHz. This was in the '90's, not fast by today's standards.
Ya, when you asked about accel/decel? There isn't any. The rate at which the position commands change dictate this but I asked about the rate at which you expect updates to happen because that will dictate whether you will need to interpolate or not. I.e. if you get a command to increment X and Y and they are not equal distances, you need to have them start and finish that segment simultaneously. The info I sent over PM? That uses a different technique; the position commands can be 30Hz, 60Hz,120Hz but the coprocessors interpolate between those positions at 2KHz.
I am still wondering what causes the jaggies that all the budget 3d printers seem to produce....low resolution position commands or low res drive systems (steppers)?
I was wondering that myself. I am sure that could be some it, but I also think it is probably due to a lack of encasement or mold and the extruded diameter of the plastic, but again I am just guessing.
Oh well, it is what it is.
Anyhow, I am much happier now that I have at least four sanding discs to start my fabrication. It is now time to recalibrate the sander to pin point accuracy and begin making my prototypes.
Well a 1.8 deg stepper via a 15 tooth T2.5 sprocket has about 0.19mm resolution... With microstepping you should get
down to 0.05mm perhaps, but belt backlash is an issue. CNC machines tend to use leadscrews which give much more
resolution.
I am certainly in no position to argue that point, however it is my understanding that the Gates GT2 is one of the most accurate belts out there for positioning.
As for one of the most important issues, speed must me considered, as well as torque and accuracy. I may end up regretting the choice to use belts for the X and Y axes, but for now, my goal is surely print speed, which the belts should provide. However without the mechanical advantage gained from a screw driven system, I may end up going slower than a screw drive
Print time should certainly be taken into consideration when selecting a drive.
Routing in wood or cutting pcb's normally has lower forces and so the requirements to the driving means are not so critical.
https://www.youtube.com/watch?v=JiCcakerS7s
'
Yes
'
I think all the math should be handled on the PC end and the Prop send the stepper moves and receive the position encoder's
Have you ever used one of the FPU processors? I am just wondering how beneficial it would be to invest in one or more for all the floating point calculations.