I'm familiar with NC Drill and Route machines in PCB manufacturing. The models we used were about 15 years old and originally ran programs stored on paper tape. The interface between the paper tape reader and NC controller was 9600 baud with a VT100 display. These were large 3 and 4 head machines and each machine probably drilled over 100,000 holes per day. My point being that a 9600 baud interface was more than enough to keep up with these fast machines.
OK then, how about we analyze the speed requirements this way:
Let's assume that we can cause the steppers to operate at a maximum of 10,000 steps per second; perhaps a little aggressive for the bigger mototors, but it proves a point.
And let's assume the PC is doing the number crunching and outputting "next position" coordinates to a dumb motor drive.
And if the coordinates are those for a circle, or for that matter any non-linear path, but reaching for the targetted .001 inch positioning capability of the table, then we need one "goto" coordinate pair per point; that means one pair per .001 inch, being a single full step.
So if the protocol could provide one such pair per 4 byte transfer, we would need 10,000 (maximum) steps per second, meaning 10,000 coordinates per second, meaning 40,000 bytes per second, which is 400,000 bits per second.
Clearly then we cannot drive the steppers at their presumed maximum speed of 10,000 steps per second. (That would have been 10 inches per second).
At 38,400 we get 4 bytes per millisecond, being one coordinate pair per 1 millisecond, meaning 1000 steps/cordinate pairs per second. And at the table's proposed resolution, that means 1 inch per second.
Anything slower than that will pe painful for any "non cutting" move such as "go home". So I continue to suggest as fast a comm data rate as reasonably possible, and smartening the dumb controller up a little bit by adding the linear interpolation algorithm of Bresenham to its task. That will significantly improve at least all the straight line positioning speeds, and only the curves would be slow. This is probably a very acceptable compromize as that algorithm doesn't look too tough.
At 38,400 we get 4 bytes per millisecond, being one coordinate pair per 1 millisecond, meaning 1000 steps/cordinate pairs per second. And at the table's proposed resolution, that means 1 inch per second.
Am I reading that right? Your talking about sending one step at a time.
If we want to move in X 10,000 steps then just tell the SX to do so and
it will perform it at the desired speed and get back to us when it has finished.
As for curves, if the SX code can handle a small arc then I can send it, say 20 arc commands for a circle.
Or something to that effect.
pvj said...
and smartening the dumb controller up a little bit by adding the linear interpolation algorithm of Bresenham to its task
I agree. I'm just a little nervous about the project bogging down trying to solve the quick circle puzzle.
Even if we had that code in the SX we would still be using the same straight line code.
I'm not saying to dismiss the idea. Its definitely the correct technique for arcs.
I'm just saying if it stops the project in its tracks, then set it aside.
Does any of that make sense. I just finished posting the sound card thread and am all typed out.
pvj said...
Just my thoughts.....
Love hearing them.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - PLJack - - -
Perfection in design is not achieved when there is nothing left to add. It is achieved when there is nothing left to take away.
Completed the structure of a poor mans mill tonight that will give others an idea of what can be done with a drill press and a table saw. I did mill the threaded rod down to bearing size on the ends but·included a quote for this work by a machine shop for $25.00 in the total cost.
The total was just shy of $100·(without steppers or the Dremel Advantage)
All parts were available at Menards (or home·depot) except the plastic for bushings, anti-backlash nuts and steel rod that are available at most any machine shop.
The skate bearings were purchased off ebay
Since this is just the structure at this point there are·no accuracy measurements.
I thought the concept put forward by David was to use the PC to crunch what needed to be done, and have a relatively dumb controller just deal with one axis motion at a time.
My issue was to understand for the "dumb" case what the command update speed would need to be for continuous motion if one were to trace a path which was not a straight line. I believe that in the case of a "dumb" controller, one would then need to use one step per PC command, and that is what my calculation was intended to portray.
Again, I believe we need a slightly intelligent controller to be able to handle linear interpolation (straight angled lines) per command so that speed can be reasonable, and unfortunately step by step PC commands for any non straight lines. Realizing that step by step will be directly dependent on the comms speed, so circles etc. will be slow. This is probably acceptable, provided such step speed be uniform, and the motion never stop. This is where the smallish buffer comes in, and the concept of "dribble feed".
As I indicated, I believe a linear interpolater can easily be done by one SX running all 3 axes, as well as it running comms at 38,400
diagnostic error messages....PLEASE, don't use an "engine light" haha.
It'd be nice to have a system halt on certain critical faults but only give warning no less non-critical items!
Have the SX (or whomever) send out a hex string indictation status and let the PC decode it in to 'english' (or at least something that doesn't need to be looked up! [noparse];)[/noparse] )
As far as speed goes....1inch per second seems fine to me! Will there be an opportunity to change the speed setting? There'll be some materials that require smaller speeds and sometimes it's just nice to ensure a nice clean line as opposed to 'grip it and rip it'!
Could a ping sensor be used to help the Z axis detect it's height? Of course the ping would only be good to determine height above a setpoint (really just another way to determine Z other than using an encoder--say the ping 'proofs' the encoder I guess).
This COULD be used for some 3D scultures if it's build right (contouring and such)!
Will they have cup holders? [noparse]:D[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ ·
Steve http://ca.geocities.com/steve.brady@rogers.com/index.html "Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."
Have the SX (or whomever) send out a hex string indictation status and let the PC decode it in to 'english' (or at least something that doesn't need to be looked up! [noparse];)[/noparse] )
Now there is a good idea. I had not thought of SX error codes.
We should work that into the protocol.
steve_b said...
Could a ping sensor be used to help the Z axis detect it's height?
That I don't know. A mill could be a messy place for a ping sensor.
steve_b said...
Will they have cup holders?
Coffee or beer?
If the mill does not work as advertized then ther should be plenty of pen holders.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - PLJack - - -
Perfection in design is not achieved when there is nothing left to add. It is achieved when there is nothing left to take away.
Again, back to speed. I agree with you that for cutting 1 inch per second if probably fine. But for non-cutting positioning, and "homing", that is too slow. It'll drive you bananas. There we probably need 10 times that.
And yes, to be truly useful, selectable motion speeds are required.
I'm not normally a patient man....and unless Bonanza is on (or the Leafs--if hockey ever comes back) then I'll probably go nuts waiting for this thing to go! haha.
I guess finding an efficient way to do traces/holes (what ever the goal) is something to work on too!
No point drilling holes from left to right only to have the mill go all the way back to the left for the next pass....might as well have'er drill in both directions....if that makes sense!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ ·
Steve http://ca.geocities.com/steve.brady@rogers.com/index.html "Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."
Alot of the suggestions I see require alot of extra development time.
Some elements are bare essentials, like returning error codes from the SX. -> You need to know the status of the overall system.
Other requirements (like changeable speed) I don't think you need to incorporate into the first iteration.
Let the project responsibles define some milestones and work towards these milestones.
You don't want to do circular interpolation and changing speed + intelligent pathfinding in your first milestone.
Try to work towards a functional system in manageable, clearly defined, iterations.
The sooner you have something working, even with alot of missing functionality and bugs, the sooner other people will start building such systems themselves and contributing to the overall project.
!!! And make sure that every iteration results in a working system !!!
For the next iteration, take the feedback (bugs, errors, user experiences) from the previous iteration and resolve these issues + incorporate some extra functionality. -> one step at a time.
If you go for the big bang approach I can almost guarantee you that this project will not succeed.
If you have a basic working platform (even with alot of missing functionality) that other people can use, then I think you'll see alot more participation and real development happening.
One other thing:
Make sure the interfaces between the different submodules are clearly defined.
You need to put some effort in clearly defining these interfaces at first.
This will make it easier for everyone to work more indepently on their submodule. (and thus reducing development time in the end)
Final note:
sorry for my crappy english - not my native tongue
Before this project get's too far along in the development process, I think one of the leaders in the group should post a document stating the primary objectives and theory of operation on how this machine will operate - so the entire group can review it, comment and revise it before actually building/programming the machine. Attach this document to the first message of this topic - so everyone can find it. Thanks
Forrest said...
Before this project get's too far along in the development process, I think one of the leaders in the group should post a document stating the primary objectives and theory of operation on how this machine will operate - so the entire group can review it, comment and revise it before actually building/programming the machine. Attach this document to the first message of this topic - so everyone can find it. Thanks
Agreed, you need to have a concept!
This concept is to be reviewed and then project deliverables can be established.
Then work needs to be divided into different milestones.
noxus said...
Agreed, you need to have a concept!
This concept is to be reviewed and then project deliverables can be established.
Then work needs to be divided into different milestones.
I agree, thats a great way to produce.
Peter has already laid out his mechanical objectives.
Bean and myself are still working out the software side.
I will post some milestones in the next day or two.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - PLJack - - -
Perfection in design is not achieved when there is nothing left to add. It is achieved when there is nothing left to take away.
PLJack said...
Peter has already laid out his mechanical objectives.
Bean and myself are still working out the software side.
I will post some milestones in the next day or two.
pjv said...
Once the machine parameters are a bit further along, the applicable G codes to choose should be quite simple for us to determine as we also use them continuously.
But for those who are not in the know, please could you take the time to make a descriptive post to bring others up to speed as to their application?
pjv said...
My take on that would be for the basics. To those already familiar with G codes it would be less interesting; to others a bit of new understanding.
A short explanation of CAD vs CAM would probably also be appreciated.
A tutorial Introduction To G-Codes is released.· An annotated list of links generally relevant to this project is included at the end.
I would appreciate feedback on this tutorial: either for correction of error; or for inceased clarity in presentation; or about most any other aspect.
I am not sure where you guys are on the maximum size of the copper.
A couple of notes related to that if there will be routing of traces.
The machine I used in the past had two dowels protruding from the work surface. Matching holes are drilled into the copper.....the dowels keep the board from moving in the X or Y direction (along with masking tape at the edges of the board).
With larger pieces of copper, sometimes the copper board was a little warped.·When this occured and depending on how much warpage, the·routing bit would usually break because it suddendly·was routing at a deeper depth·due to the board on the Z axis being "taller".
The same problem occurs when lowering surface mount components onto a board. The vertical level of the board is not uniform. I have seen warpage that is well over 0.1 inch.
One nice product I saw to overcome that was a bunch of magnetic vacuum cups. The strong magnets located the cups on a flat steel base, and were placed so that the small suction cups could contact the underside of the board where there were no holes. Each one was individually connected via a tiny 1/16 inch rubber hose to a vacuum source. When that was turned on, the board was held firmly in place, and was then free of any warp. We'll need some of that concept for precision or professional quality work.
I've used machines with porus ceramic or metal bases. Basically, the base plate is made with kajillions of tiny holes in it, and then it's put into a 5-sided box with a vacuum line on the bottom. The exposed side allows a little air to move through the substrate, and when a flat workpiece is placed on it, voila, instant suction at a few PSI. I'm not sure about the cost of them, but I think we could do something simialr with a grooved baseplate and suction....
-dave
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
This is not a sig. This is a duck. Quack.
A tutorial Introduction To G-Codes is released. An annotated list of links generally relevant to this project is included at the end.
I would appreciate feedback on this tutorial: either for correction of error; or for inceased clarity in presentation; or about most any other aspect.
Best Regards,
Daniel
I just finished reading this.
Thank you very much Daniel.
Beautiful piece of work. Everything I need (or a link) to start working on the g-Code software.
You saved me many hours of research.
I have nothing to add though.
Thanks again.
Jack
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - PLJack - - -
Perfection in design is not achieved when there is nothing left to add. It is achieved when there is nothing left to take away.
Hi gang.
Just popped in to say that I have been very busy this week and have not had time to work on this project.
I will try to spend this weekend catching up on lost time.
Hopefully by Monday I will post a software update and a categorized list of objectives.
Jack
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - PLJack - - -
Perfection in design is not achieved when there is nothing left to add. It is achieved when there is nothing left to take away.
I'm busy designing the details of the recirculating slide bearings, and I expect to have the first protoypes in my hands soon. The detailed table designs are moving forward, and I have ordered a quantity of various aluminum extrusions to make prototype tables and slides of the 3 different sizes in various configurations. All continues to look very promising.
I realize I have not yet posted the 3D CAD drawings I promised. We have been very busy with a commercial project, so there has not been enough time.
I've been playing with implementing a simple G-Code parser/execution engine on a Basic Stamp 2, driving a pair of stepper motors using simple full-step instructions (not step/dir).· This prototype is limited to 8-bits per axis, as a memory saving contrivance.
I'll post more complete results in a day or so, but I have one program that does the G00 - Rapid Motion on two axes.· I have another program almost debugged that does the G01 - Interpolated Motion on two axes.
I'm going after a proof of concept, so I'll probably not do the G02/G03 interpolated arcs on the Stamp, but maybe on an SX with SX/B.
Comments
My thinking is that email would be faster. We are just going to bone out a basic protocol and present it here to
the community for discussion.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - PLJack - - -
Perfection in design is not achieved when there is nothing left to add.
It is achieved when there is nothing left to take away.
Let's assume that we can cause the steppers to operate at a maximum of 10,000 steps per second; perhaps a little aggressive for the bigger mototors, but it proves a point.
And let's assume the PC is doing the number crunching and outputting "next position" coordinates to a dumb motor drive.
And if the coordinates are those for a circle, or for that matter any non-linear path, but reaching for the targetted .001 inch positioning capability of the table, then we need one "goto" coordinate pair per point; that means one pair per .001 inch, being a single full step.
So if the protocol could provide one such pair per 4 byte transfer, we would need 10,000 (maximum) steps per second, meaning 10,000 coordinates per second, meaning 40,000 bytes per second, which is 400,000 bits per second.
Clearly then we cannot drive the steppers at their presumed maximum speed of 10,000 steps per second. (That would have been 10 inches per second).
At 38,400 we get 4 bytes per millisecond, being one coordinate pair per 1 millisecond, meaning 1000 steps/cordinate pairs per second. And at the table's proposed resolution, that means 1 inch per second.
Anything slower than that will pe painful for any "non cutting" move such as "go home". So I continue to suggest as fast a comm data rate as reasonably possible, and smartening the dumb controller up a little bit by adding the linear interpolation algorithm of Bresenham to its task. That will significantly improve at least all the straight line positioning speeds, and only the curves would be slow. This is probably a very acceptable compromize as that algorithm doesn't look too tough.
Just my thoughts.....
Peter (pjv)
Am I reading that right? Your talking about sending one step at a time.
If we want to move in X 10,000 steps then just tell the SX to do so and
it will perform it at the desired speed and get back to us when it has finished.
As for curves, if the SX code can handle a small arc then I can send it, say 20 arc commands for a circle.
Or something to that effect.
I agree. I'm just a little nervous about the project bogging down trying to solve the quick circle puzzle.
Even if we had that code in the SX we would still be using the same straight line code.
I'm not saying to dismiss the idea. Its definitely the correct technique for arcs.
I'm just saying if it stops the project in its tracks, then set it aside.
Does any of that make sense. I just finished posting the sound card thread and am all typed out.
Love hearing them.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - PLJack - - -
Perfection in design is not achieved when there is nothing left to add.
It is achieved when there is nothing left to take away.
The total was just shy of $100·(without steppers or the Dremel Advantage)
All parts were available at Menards (or home·depot) except the plastic for bushings, anti-backlash nuts and steel rod that are available at most any machine shop.
The skate bearings were purchased off ebay
Since this is just the structure at this point there are·no accuracy measurements.
What is the extent of the X,Y,Z travel?
Peter (pjv)
Well, not exactly.
I thought the concept put forward by David was to use the PC to crunch what needed to be done, and have a relatively dumb controller just deal with one axis motion at a time.
My issue was to understand for the "dumb" case what the command update speed would need to be for continuous motion if one were to trace a path which was not a straight line. I believe that in the case of a "dumb" controller, one would then need to use one step per PC command, and that is what my calculation was intended to portray.
Again, I believe we need a slightly intelligent controller to be able to handle linear interpolation (straight angled lines) per command so that speed can be reasonable, and unfortunately step by step PC commands for any non straight lines. Realizing that step by step will be directly dependent on the comms speed, so circles etc. will be slow. This is probably acceptable, provided such step speed be uniform, and the motion never stop. This is where the smallish buffer comes in, and the concept of "dribble feed".
As I indicated, I believe a linear interpolater can easily be done by one SX running all 3 axes, as well as it running comms at 38,400
Hope that clears up my musings Jack.
Cheers,
Peter (pjv)
12" x 10" x 3"
I know 3" is a little much on the Z axis but I wanted a little room for·thicker projects.
Post Edited (Eric R) : 7/11/2005 3:02:54 AM GMT
Great job eric. Very cool.
Looks like it has plenty of mass. I'll guess 35 pounds.
Does the base jolt a little starting a Y travel?
Keep us posted.
I would kill for that in this office right now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - PLJack - - -
Perfection in design is not achieved when there is nothing left to add.
It is achieved when there is nothing left to take away.
Musings Cleared.
I think we both on the same page here.
Lets go for broke and see how it goes.
Speaking of SX code,
Anyone seen Bean?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - PLJack - - -
Perfection in design is not achieved when there is nothing left to add.
It is achieved when there is nothing left to take away.
I you think you have nothing to add, then you are wrong.
What are you thoughts, plans for the mill, ideas?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - PLJack - - -
Perfection in design is not achieved when there is nothing left to add.
It is achieved when there is nothing left to take away.
diagnostic error messages....PLEASE, don't use an "engine light" haha.
It'd be nice to have a system halt on certain critical faults but only give warning no less non-critical items!
Have the SX (or whomever) send out a hex string indictation status and let the PC decode it in to 'english' (or at least something that doesn't need to be looked up! [noparse];)[/noparse] )
As far as speed goes....1inch per second seems fine to me! Will there be an opportunity to change the speed setting? There'll be some materials that require smaller speeds and sometimes it's just nice to ensure a nice clean line as opposed to 'grip it and rip it'!
Could a ping sensor be used to help the Z axis detect it's height? Of course the ping would only be good to determine height above a setpoint (really just another way to determine Z other than using an encoder--say the ping 'proofs' the encoder I guess).
This COULD be used for some 3D scultures if it's build right (contouring and such)!
Will they have cup holders? [noparse]:D[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·
Steve
http://ca.geocities.com/steve.brady@rogers.com/index.html
"Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."
Now there is a good idea. I had not thought of SX error codes.
We should work that into the protocol.
That I don't know. A mill could be a messy place for a ping sensor.
Coffee or beer?
If the mill does not work as advertized then ther should be plenty of pen holders.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - PLJack - - -
Perfection in design is not achieved when there is nothing left to add.
It is achieved when there is nothing left to take away.
Again, back to speed. I agree with you that for cutting 1 inch per second if probably fine. But for non-cutting positioning, and "homing", that is too slow. It'll drive you bananas. There we probably need 10 times that.
And yes, to be truly useful, selectable motion speeds are required.
Cheers,
Peter (pjv)
I'm not normally a patient man....and unless Bonanza is on (or the Leafs--if hockey ever comes back) then I'll probably go nuts waiting for this thing to go! haha.
I guess finding an efficient way to do traces/holes (what ever the goal) is something to work on too!
No point drilling holes from left to right only to have the mill go all the way back to the left for the next pass....might as well have'er drill in both directions....if that makes sense!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·
Steve
http://ca.geocities.com/steve.brady@rogers.com/index.html
"Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."
Some elements are bare essentials, like returning error codes from the SX. -> You need to know the status of the overall system.
Other requirements (like changeable speed) I don't think you need to incorporate into the first iteration.
Let the project responsibles define some milestones and work towards these milestones.
You don't want to do circular interpolation and changing speed + intelligent pathfinding in your first milestone.
Try to work towards a functional system in manageable, clearly defined, iterations.
The sooner you have something working, even with alot of missing functionality and bugs, the sooner other people will start building such systems themselves and contributing to the overall project.
!!! And make sure that every iteration results in a working system !!!
For the next iteration, take the feedback (bugs, errors, user experiences) from the previous iteration and resolve these issues + incorporate some extra functionality. -> one step at a time.
If you go for the big bang approach I can almost guarantee you that this project will not succeed.
If you have a basic working platform (even with alot of missing functionality) that other people can use, then I think you'll see alot more participation and real development happening.
One other thing:
Make sure the interfaces between the different submodules are clearly defined.
You need to put some effort in clearly defining these interfaces at first.
This will make it easier for everyone to work more indepently on their submodule. (and thus reducing development time in the end)
Final note:
sorry for my crappy english - not my native tongue
This concept is to be reviewed and then project deliverables can be established.
Then work needs to be divided into different milestones.
I agree, thats a great way to produce.
Peter has already laid out his mechanical objectives.
Bean and myself are still working out the software side.
I will post some milestones in the next day or two.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - PLJack - - -
Perfection in design is not achieved when there is nothing left to add.
It is achieved when there is nothing left to take away.
A tutorial Introduction To G-Codes is released.· An annotated list of links generally relevant to this project is included at the end.
I would appreciate feedback on this tutorial: either for correction of error; or for inceased clarity in presentation; or about most any other aspect.
Best Regards,
Daniel
http://www.misumiusa.com/
They seem to be about half price on linear bearings and offer many other parts that will be needed.
A couple of notes related to that if there will be routing of traces.
$0.02
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ken
The same problem occurs when lowering surface mount components onto a board. The vertical level of the board is not uniform. I have seen warpage that is well over 0.1 inch.
One nice product I saw to overcome that was a bunch of magnetic vacuum cups. The strong magnets located the cups on a flat steel base, and were placed so that the small suction cups could contact the underside of the board where there were no holes. Each one was individually connected via a tiny 1/16 inch rubber hose to a vacuum source. When that was turned on, the board was held firmly in place, and was then free of any warp. We'll need some of that concept for precision or professional quality work.
Cheers,
Peter (pjv)
-dave
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
This is not a sig. This is a duck. Quack.
I just finished reading this.
Thank you very much Daniel.
Beautiful piece of work. Everything I need (or a link) to start working on the g-Code software.
You saved me many hours of research.
I have nothing to add though.
Thanks again.
Jack
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - PLJack - - -
Perfection in design is not achieved when there is nothing left to add.
It is achieved when there is nothing left to take away.
Post Edited (PLJack) : 7/13/2005 10:43:14 PM GMT
Just popped in to say that I have been very busy this week and have not had time to work on this project.
I will try to spend this weekend catching up on lost time.
Hopefully by Monday I will post a software update and a categorized list of objectives.
Jack
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - PLJack - - -
Perfection in design is not achieved when there is nothing left to add.
It is achieved when there is nothing left to take away.
I'm busy designing the details of the recirculating slide bearings, and I expect to have the first protoypes in my hands soon. The detailed table designs are moving forward, and I have ordered a quantity of various aluminum extrusions to make prototype tables and slides of the 3 different sizes in various configurations. All continues to look very promising.
I realize I have not yet posted the 3D CAD drawings I promised. We have been very busy with a commercial project, so there has not been enough time.
Please be patient.
Cheers,
Peter (pjv)
Just a teaser, here.
I've been playing with implementing a simple G-Code parser/execution engine on a Basic Stamp 2, driving a pair of stepper motors using simple full-step instructions (not step/dir).· This prototype is limited to 8-bits per axis, as a memory saving contrivance.
I'll post more complete results in a day or so, but I have one program that does the G00 - Rapid Motion on two axes.· I have another program almost debugged that does the G01 - Interpolated Motion on two axes.
I'm going after a proof of concept, so I'll probably not do the G02/G03 interpolated arcs on the Stamp, but maybe on an SX with SX/B.
Daniel
Post Edited (daniel) : 7/18/2005 6:47:59 AM GMT