Looks like a teaser kind of morning.
I made allot of progress on the PC software over the weekend.
I will post a software update when I get back tonight.
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.
Daniel,
I was on vacation last week, so I didn't post anything. I would love to see your Stamp code, could you post it ?
I'm not familar with "g-codes" so it would be a big help to me.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
I'll be a little slow with replies and such for the next month or so. My new house has me over a small barrel, and I have to get things at home straightened out before hobbies can take precedence.
-dave
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
This is not a sig. This is a duck. Quack.
Daniel, that was a real helpful G-code presentation.
I have questions about circuit drawing packages. (I have zero experience in using circuit drawing programs, G codes, etc.)
It seems to me that for all practical purposes, this mill will depend on using Gerber or some other format files produced by an existing circuit drawing package.
So either this project has to implement all (or all commonly used) Gerber or whatever codes, or else implement the subset of codes used by some particular drawing package, right?
Since each G or D or whatever code has to be individually implemented, if I were to use some random circuit drawing package to design a circuit, then were to discover that this milling project didn't implement some code that my drawing package produced, then I would be stuck! I couldn't mill or drill my circuit! I'd have to either switch drawing programs to one that used only implemented codes, or else I'd need to be able to extend the milling machine drivers to implement the missing codes, right?
So should there be a recommended circuit drawing program for this project that the interface will implement the codes for? Is there one that seems like generally the best for this project? Preferably inexpensive or freeware?
Or is there a small subset of G codes that are commonly used? I noticed that in Daniel's tutorial, the Basic Stamp 1 Gerber files only use a very small number of codes - G01, G54, D01, etc. Is this common? What drawing program produced these codes? Is it common for most drawing programs to use only a few codes?
Maybe choosing a program that's a good overall package....but of course $$$$.
A package that will let you import from other packages in order to mill your bits.
Everyone has something different in mind....since this is a simple setup (no 3D stuff--yet!) then picking a simple program would be best.
Ever seen the drawing programs on a CNC machine....not all that "pretty" but they certainly do the job!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ ·
Steve "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."
David B said...
I were to use some random circuit drawing package to design a circuit, then were to discover that this milling project didn't implement some code that my drawing package produced, then I would be stuck!
And stuck you would be.· One aspect of the more complete CAM packages (or the POST processors) is to add information about the specifics of the G-Code implementation and mechanical capabilities of the target milling machine (or lathes, etc.).· This is then taken into account to some degree when rendering the G-Code to instantiate the design on that particular machine.
David B said...
I'd need to be able to extend the milling machine drivers to implement the missing codes, right?
This is the mixed blessing of the volunteer open nature of this project.· You get what was programmed, but can, if sufficiently motivated, program it to do what you want.
That said, however, do keep in mind that so far the projects formal direction is to provide a motor controller that has some intelligence that communicates to the PC software.· The PC software functions as the POST processor, reading CAD files (e.g. DXF) or G-Code programs (e.g., Gerber or Excellon) directly and emitting the machine control instructions for the SX controller to wiggle the axes of the machine.
My bias would be to make the SX a simple minded motion execution engine, whose interface is a formally reduced set of the G-Codes.· There are other opinions as to whether this would work in the large.· Hence my experimentation with a simple motion processor on the Basic Stamp.· My bias is not too far different from the current formal intent of the project to, as I undestand it, have the SX be a simple minded motion exection engine, whose interface is a formal, but·of an as yet unpublished, protocol.· In either case (my bias, or the project's bias) there is a requirement for a PC POST-processor to take the CAD design or CAM output·and massage it for the SX motion engine.
David B said...
is there a small subset of G codes that are commonly used?
You observe correctly.·
Gerber files typically used for PCB photoplotting utilize a quite limited subset of the G-Code standard.· Excellon drill files, likewise, take another subset, and add a few unique twists.
Ultimately, all motions could be constructed of straight line segments.· Arcs are a rich dessert that that not all need partake of.· Of course, gourmand tastes can be developed, and leave our palette unsatisfied with these fundamental motion entities.· This rising expectation is often accompanied with increased demands for part sophistication, finish, and other important things to either speed of production, physical requirements of the part's application,·or customer perception of value.
David B said...
What drawing program produced these codes?
As a part of the research for the tutorial, I was informed that Parallax uses Protel software internally; the Basic Stamp OEM Gerber files was generated by Protel.·
More on the Basic Stamp G-Code Interpreter experments in a day or too.
Too many changes to list.
May last personal entry was,
7/8/2005 9:56PM
Added 32Bit graphic and class code.
Since then I have created the graphics plotting code.
And the G-code parser code.
The Parser:
All G-codes contained in Oembs1.gtl file are at least recognized and parsed less M-codes.
Of those 80% are fully parsed.
Attached to this thread are the oembs1.gtl and gtlparse.txt files.
oembs1.txtl is the original GTL file.
gtlparse.txt is the translated file produced by the G-Code parser class.
The Plotter:
The plotter feeds off the parser vectors created during the parse.
The tough (not quite solved) part is dealing with the incremental coordinates of the G-Code files.
All the files are of different "widths".
Once I nailed that the plotter came to life. It only really only knows how to draw from point to point but throw the parser data at it and voila, circuits!
Each plot contains the head path (light color) and trace width (dark color), i.e. the aperture.
Still need to get the aperture in proportion with the PCB. Its close, but I am winging it. Its not mathematically correct.
Keep in mind that all anomalies are ONLY related to graphic plotting.
The numbers we would be sending to the SX are true.
Aside from the missing SX pad. Still looking into that.
I have attached a few screen shots.
[noparse][[/noparse] oembs1.gto + oembs1.gpt + oembs1.gg1 ]
As you can see the drill holes (green plus) line up nicely.
[noparse][[/noparse] oembs1.gbl + oembs1.gtl ]
Again a nice fit
[noparse][[/noparse] oembs1.gto + oembs1.gbl + oembs1.gtl ]
Looks like a Basic OEM to me.
I'm tired now. Good night.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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.
Unfortunately, I don't have time to read through all the hundreds of posts in this thread, but I heard of something you might want to know.· A quick search of the forum didn't reveal any posts from this thread mentioning "servo", so I don't think anyone else has posted it.
A couple months ago, Servo Magazine did a two-part series on how to build your own three-axis PCB milling machine for under $500!· You should look up the article.· I intend to build one as soon as I go back to school (there are seven people in my apartment; 5 of us want a PCB miller).
Bean (Hitt Consulting) said...
your Stamp code, could you post it ?
Here is the writeup for my Basic Stamp G-Code Interpreter.· In the end, I also removed the acceleration/deceleration ramping from the interpreter, but that probably is not reflected in the G01 source code comments.
PLJack said...
Too many changes to list.
Nice work.· I'm curious, what software environment are you using?
Close enough...the "plotter", for example, is it a part of a particular library/plugin, self-written, etc.
Another way of putting it would be "what software tools/components would I need in the event I wished to "extend" the completed PC side of the project?"
daniel said...
PLJack
Close enough...the "plotter", for example, is it a part of a particular library/plugin, self-written, etc.
Daniel
I wrote it this weekend from scratch.
daniel said...
Another way of putting it would be "what software tools/components would I need in the event I wished to "extend" the completed PC side of the Project?"
Daniel
I will be releasing the binaries, not the source code.
I don't release code as a policy.
Mostly because I reuse code I have written over the years.
I would have to distribute my entire development drive!
Open source software is at it's best if it is designed that way from the ground up.
Releasing in house code is a nightmare.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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'd spotted this on American Choppers some time ago (funny thing was the guy couldn't get it to work).... http://www.faro.com/
From the looks of the one on the show....it has a multi-limbed arm with encoders at each joint.....you run a rolling ball (another encoder) along an object and it gets drawn on the computer.· So you can take machined parts and get 3D images of them by running the tip across it....seems cool!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ ·
Steve "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."
Bean (Hitt Consulting) said...
Will this work for the stepper controller ?
Have you knoticed the lines generated to be blemished?· If not, then it passes the empirical test of working, so why wouldn't it be adaptable to stepper control?
Bean (Hitt Consulting) said...
how [noparse][[/noparse] is it ]·any different than Bresenham's ?
Dunno. Bresenham is essentially step X until the accumulated error in Y exceeds one-half Y step, then step y and·reduce accumulated error by Y step.·
Yours seems to do the same.·
I didn't look too close, but·increasing the error accumulator by·"+DeltaY" and the reducing it by "-DeltaX" seems at first glance a bit curious.· What happens if DeltaY differs greatly from DeltaX?
[noparse][[/noparse]Following standard Bresenham,] implementations of the algorithm I've seen use one-half the Y step size as the test point.· This would have the effect of making the resultant plot ride the average of the vector; does your plot run half a Y step·above the actual vector?· Probably not a big difference, and maybe a flawed analysis.
Strickly speaking, Bresenham's orignally stated algorithm was limited to one octant, specifically where the line goes down and right, with a slope of less than 1.· It can be applied to a vector in any direction by fiddling with the octant symmetries.· Is your method limited to a specific quadrant?
Daniel
P.S.
A few references (in case some reader has not yet become familier with Bresenham's algorithm):
But I expanded my little Basic Stamp G-Code Interpreter into a 3-axis machine, with basic spindle control, axis limit-switch and feed-hold monitoring, and able to do·either G00 Rapid Move or G01 Interpolated Move.· With all that on board, the·longest part part program I can·execute from EEPROM is about·10 bytes long.
Now, I really want one of these X-Y-Z machines we've been talking about.
Am I right in assuming that I will have to break up the desired steps into "256 step" chunks?
In other words Delta X and Delta Y are integers.
Say I need to move from:
X1.0567 Y1.2045
to
X1.5934 Y2.7548
That comes out to 0.5367 in X and 1.5503 in Y.
At .001" steps that's 536 X steps and 1,550 Y steps.
So my question to bean is, if the head is at X1.0567 Y1.2045 and we need to move to X1.5934 Y2.7548, what would you like me to send to the SX?
Or are we not there yet?
On my end, I'm still working on the plotting code.
Now correctly renders pad size and shapes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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.
Oops,
The first line of my line code should have been "Temp=DeltaX / 2"
PLJack,
I hope to be able to handle integers for the movements (-32767 to +32767).
Also I would hope the PC would remember where the head is, so all I would expect is offsets. Of course the table will have to have some kind of "HOME set" cabibility. We will have to decide how to set the HOME position.
We will need some kind of serial handshaking also.
I realize we need three stepper motors to be controlled (for X, Y, and Z), but does the Z axis need to be interpolated along with the X and Y axis ?
I assumed we would move to an X,Y position, then move the Z axis.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
You experts are so far over my head it's pathetic.· Notwithstanding, and back to my little MF70 mill, I have the routines for the X and Y drive in separate banks.· Regarding "home" and "where am I" I wrote the following in the X bank:
pos = 0············ 'total degrees of rotation
y = 0··············· 'y is direction, 1 left, 2 right
disx = 0··········· 'distance from origin
write 0. word pos, y········ 'disable after first run
read 0, word pos, y
write 10, word disx··········disable after first run
read 10, word disx
'go to program
I move the X table any direction.· It writes new values of pos, y and disx to EEPROM.· I power down, disable the above write lines and reload.· Now the program always knows how far it is from the X origin and the total number of degrees travelled.· I can shut the program down, come back hours later and the LCD always tells me exactly where the spindle is in relation to the X origin.
Same thing for the Y bank.
If posts concerning my little MF70 are of no value, please let me know and I will cease and desist.
Sid, please keep posting. Variety is the spice of life, and I think it will only help the exchange of ideas and solving of problems here.
I like the idea of using EEPROM to store relevant data, but I think it should be used in combination with a home routine. I know for myself, if I'm working ont he machine it won't be in precisely the same position as before when I power it up again, tho it will probably be close (or maybe not!). Having the machine know generally where it should be in space is valuable however, and I think it should be discussed.
PLJack/Daniel:
The development of the G-code interpreter is exciting, but I have one question: If the toolpaths are running down the center of the tracks, won't that leave copper everywhere but where we want it? Drilling holes seems pretty easy (just a set of XY coordinates to plunge into), but don't we need to interpret trackwidths and compute an outline to cut?
Or am I jumping the gun?
-dave
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
This is not a sig. This is a duck. Quack.
Dave, if I am working on something, and my LCD says:
Distance from X - .600
Distance from Y - 1.400
I·can turn everything off, come back the next morning, and the LCD will tell me the exact same thing.· Nothing has moved.· That's why I added the routine - I can be working on something and have to stop several times.· Before this routine was added I had to measure with a micrometer to find out where I was.· The origin - X = 0,
Y = 0 - is always marked with a shallow hole drilled just through the copper.
Dave Paton said...
If the toolpaths are running down the center of the tracks, won't that leave copper everywhere but where we want it? Drilling holes seems pretty easy (just a set of XY coordinates to plunge into), but don't we need to interpret trackwidths and compute an outline to cut?
Keep in mind the difference between the circuit-trace vector (where the copper is to remain) and the·several trace-outlining vectors that surround the circuit-trace (where the copper is to be removed).·
The first is plotting the wire's trace; the second is plotting the outline of that same trace.
One way of doing this on a standard mill·might be to have the tool tip, with a G41 Left Offset, machine the circuit trace.· Then machine the same circuit trace with a G42 Right Offset.· In this case have the each of the tool offsets be one-half of the desired circuit-trace width plus one-half of the tool's cutting radius.· See http://www.timgoldstein.com/cad_cam/diacomp.htm·for a nice diagram.
Bean (Hitt Consulting) said...
...
does the Z axis need to be interpolated along with the X and Y axis ?
I assumed we would move to an X,Y position, then move the Z axis.
For a PCB drill, your assumption is correct.
My personal goal is to have an X-Y-Z machine with each axis roughy equal in size.· Hence my thoughts include this hope of a future realization.
A question though,· what your design goal of the controller?· Is it a vector to stepper-steps converter?· Is it a fullblown (microstepping, current limiting, etc.)·stepper controller?· Something else?· What is it's output to the stepper motors:· Step/Direction, or Coil Phase?
Dave, I forgot to mention one thing.· I have a little safety routine, that when the spindle is at origin, the program rejects any entry that would take X further left or Y further out.· This keeps me from breaking drills on the X hold-down clamps or trying to drive the Y table further out than its mechanical stop will permit.
As long as the stepper controller is energized, it will keep a holding current applied to maintain a particular phase of the step sequence when the motor is stopped.
But when you power the controller down, then restart it, is there any guarantee that it will power up to that same phase? I know that earlier controllers would power up to a random phase. This could make the motor jog a step, and throw maybe 0.001 inch of inconsistency, or whatever a step is geared at, into the location.
Sometimes a single step makes a difference (and sometimes it doesn't).
PLJack,
I hope to be able to handle integers for the movements (-32767 to +32767).
Bean.
There you go!
That's is great news.
Bean (Hitt Consulting) said...
Also I would hope the PC would remember where the head is, so all I would expect is offsets. Of course the table will have to have some kind of "HOME set" capability. We will have to decide how to set the HOME position.
Bean.
That is the strength of writing the software from scratch. The PC can do anything you wish.
And yes, the PC will keep track of the head. This functionality requires that the SX report on successful maneuvers.
Bean (Hitt Consulting) said...
We will need some kind of serial handshaking also.
Bean.
I have some thoughts on that.
Given the communication level between the PC and SX I really recommend we use a MAX232 or similar to enable a full fledged serial communication.
On the software side I have already implemented full serial ability including the serial configuration window.
I have done this many times so it went pretty quick.
I also would suggest that the SX default to 9600 baud on power up. the speed can be "ramped" up by the software.
That is why I'm always talking about protocols. Not serial protocols but our own "PC->SX" communication protocol.
Bean (Hitt Consulting) said...
I realize we need three stepper motors to be controlled (for X, Y, and Z), but does the Z axis need to be interpolated along with the X and Y axis ?
I assumed we would move to an X,Y position, then move the Z axis.
Bean.
Correct.
As I see it Z axis interpolation would come about in phase three of the project when we start working on a 3D mill.
By then we will have learned allot.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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.
David B said...
About saving location to EEPROM -
But when you power the controller down, then restart it, is there any guarantee that it will power up to that same phase? I know that earlier controllers would power up to a random phase. This could make the motor jog a step, and throw maybe 0.001 inch of inconsistency, or whatever a step is geared at, into the location.
David
What does everyone think about a very tiny hole in the platform with a photoresistor underneath it?
Then place an LED device in the chuck.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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.
Comments
I made allot of progress on the PC software over the weekend.
I will post a software update when I get back tonight.
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 was on vacation last week, so I didn't post anything. I would love to see your Stamp code, could you post it ?
I'm not familar with "g-codes" so it would be a big help to me.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
Product web site: www.sxvm.com
"One experiment is worth a thousand theories"
·
I'll be a little slow with replies and such for the next month or so. My new house has me over a small barrel, and I have to get things at home straightened out before hobbies can take precedence.
-dave
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
This is not a sig. This is a duck. Quack.
I have questions about circuit drawing packages. (I have zero experience in using circuit drawing programs, G codes, etc.)
It seems to me that for all practical purposes, this mill will depend on using Gerber or some other format files produced by an existing circuit drawing package.
So either this project has to implement all (or all commonly used) Gerber or whatever codes, or else implement the subset of codes used by some particular drawing package, right?
Since each G or D or whatever code has to be individually implemented, if I were to use some random circuit drawing package to design a circuit, then were to discover that this milling project didn't implement some code that my drawing package produced, then I would be stuck! I couldn't mill or drill my circuit! I'd have to either switch drawing programs to one that used only implemented codes, or else I'd need to be able to extend the milling machine drivers to implement the missing codes, right?
So should there be a recommended circuit drawing program for this project that the interface will implement the codes for? Is there one that seems like generally the best for this project? Preferably inexpensive or freeware?
Or is there a small subset of G codes that are commonly used? I noticed that in Daniel's tutorial, the Basic Stamp 1 Gerber files only use a very small number of codes - G01, G54, D01, etc. Is this common? What drawing program produced these codes? Is it common for most drawing programs to use only a few codes?
David
A package that will let you import from other packages in order to mill your bits.
Everyone has something different in mind....since this is a simple setup (no 3D stuff--yet!) then picking a simple program would be best.
Ever seen the drawing programs on a CNC machine....not all that "pretty" but they certainly do the job!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·
Steve
"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."
This is the mixed blessing of the volunteer open nature of this project.· You get what was programmed, but can, if sufficiently motivated, program it to do what you want.
That said, however, do keep in mind that so far the projects formal direction is to provide a motor controller that has some intelligence that communicates to the PC software.· The PC software functions as the POST processor, reading CAD files (e.g. DXF) or G-Code programs (e.g., Gerber or Excellon) directly and emitting the machine control instructions for the SX controller to wiggle the axes of the machine.
My bias would be to make the SX a simple minded motion execution engine, whose interface is a formally reduced set of the G-Codes.· There are other opinions as to whether this would work in the large.· Hence my experimentation with a simple motion processor on the Basic Stamp.· My bias is not too far different from the current formal intent of the project to, as I undestand it, have the SX be a simple minded motion exection engine, whose interface is a formal, but·of an as yet unpublished, protocol.· In either case (my bias, or the project's bias) there is a requirement for a PC POST-processor to take the CAD design or CAM output·and massage it for the SX motion engine.
You observe correctly.·
Gerber files typically used for PCB photoplotting utilize a quite limited subset of the G-Code standard.· Excellon drill files, likewise, take another subset, and add a few unique twists.
Ultimately, all motions could be constructed of straight line segments.· Arcs are a rich dessert that that not all need partake of.· Of course, gourmand tastes can be developed, and leave our palette unsatisfied with these fundamental motion entities.· This rising expectation is often accompanied with increased demands for part sophistication, finish, and other important things to either speed of production, physical requirements of the part's application,·or customer perception of value.
As a part of the research for the tutorial, I was informed that Parallax uses Protel software internally; the Basic Stamp OEM Gerber files was generated by Protel.·
More on the Basic Stamp G-Code Interpreter experments in a day or too.
Daniel
Post Edited (daniel) : 7/18/2005 8:34:28 PM GMT
Too many changes to list.
May last personal entry was,
7/8/2005 9:56PM
Added 32Bit graphic and class code.
Since then I have created the graphics plotting code.
And the G-code parser code.
The Parser:
All G-codes contained in Oembs1.gtl file are at least recognized and parsed less M-codes.
Of those 80% are fully parsed.
Attached to this thread are the oembs1.gtl and gtlparse.txt files.
oembs1.txtl is the original GTL file.
gtlparse.txt is the translated file produced by the G-Code parser class.
The Plotter:
The plotter feeds off the parser vectors created during the parse.
The tough (not quite solved) part is dealing with the incremental coordinates of the G-Code files.
All the files are of different "widths".
Once I nailed that the plotter came to life. It only really only knows how to draw from point to point but throw the parser data at it and voila, circuits!
Each plot contains the head path (light color) and trace width (dark color), i.e. the aperture.
Still need to get the aperture in proportion with the PCB. Its close, but I am winging it. Its not mathematically correct.
Keep in mind that all anomalies are ONLY related to graphic plotting.
The numbers we would be sending to the SX are true.
Aside from the missing SX pad. Still looking into that.
I have attached a few screen shots.
[noparse][[/noparse] oembs1.gto + oembs1.gpt + oembs1.gg1 ]
As you can see the drill holes (green plus) line up nicely.
[noparse][[/noparse] oembs1.gbl + oembs1.gtl ]
Again a nice fit
[noparse][[/noparse] oembs1.gto + oembs1.gbl + oembs1.gtl ]
Looks like a Basic OEM to me.
I'm tired now. Good night.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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/19/2005 3:42:26 AM GMT
www.mmsonline.com/articles/cnc9801.html
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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 couple months ago, Servo Magazine did a two-part series on how to build your own three-axis PCB milling machine for under $500!· You should look up the article.· I intend to build one as soon as I go back to school (there are seven people in my apartment; 5 of us want a PCB miller).
Good luck.
Nice work.· I'm curious, what software environment are you using?
Daniel
Not sure waht you mean by "software environment".
The code is C++.
The compiler is Borland.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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.
Close enough...the "plotter", for example, is it a part of a particular library/plugin, self-written, etc.
Another way of putting it would be "what software tools/components would I need in the event I wished to "extend" the completed PC side of the project?"
Just curious.
Daniel
I wrote it this weekend from scratch.
I will be releasing the binaries, not the source code.
I don't release code as a policy.
Mostly because I reuse code I have written over the years.
I would have to distribute my entire development drive!
Open source software is at it's best if it is designed that way from the ground up.
Releasing in house code is a nightmare.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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'd spotted this on American Choppers some time ago (funny thing was the guy couldn't get it to work)....
http://www.faro.com/
From the looks of the one on the show....it has a multi-limbed arm with encoders at each joint.....you run a rolling ball (another encoder) along an object and it gets drawn on the computer.· So you can take machined parts and get 3D images of them by running the tip across it....seems cool!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·
Steve
"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."
Temp=DeltaX / 2
DO LOOP
· StepX
· Temp=Temp + DeltaY
· IF Temp >= DeltaX THEN
··· StepY
··· Temp=Temp - DeltaX
· ENDIF
UNTIL Done
Will this work for the stepper controller ?
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
Product web site: www.sxvm.com
"One experiment is worth a thousand theories"
Post Edited (Bean (Hitt Consulting)) : 7/21/2005 10:46:15 AM GMT
Dunno. Bresenham is essentially step X until the accumulated error in Y exceeds one-half Y step, then step y and·reduce accumulated error by Y step.·
Yours seems to do the same.·
I didn't look too close, but·increasing the error accumulator by·"+DeltaY" and the reducing it by "-DeltaX" seems at first glance a bit curious.· What happens if DeltaY differs greatly from DeltaX?
[noparse][[/noparse]Following standard Bresenham,] implementations of the algorithm I've seen use one-half the Y step size as the test point.· This would have the effect of making the resultant plot ride the average of the vector; does your plot run half a Y step·above the actual vector?· Probably not a big difference, and maybe a flawed analysis.
Strickly speaking, Bresenham's orignally stated algorithm was limited to one octant, specifically where the line goes down and right, with a slope of less than 1.· It can be applied to a vector in any direction by fiddling with the octant symmetries.· Is your method limited to a specific quadrant?
Daniel
P.S.
A few references (in case some reader has not yet become familier with Bresenham's algorithm):
Bresenham's line algorithm
(http://en.wikipedia.org/wiki/Bresenham's_line_algorithm)·
The Bresenham Line-Drawing Algorithm
(http://www.cs.helsinki.fi/group/goa/mallinnus/lines/bresenh.html)
Bresenham's line and circle algorithms
(http://www.mandelbrot-dazibao.com/Bresen/Bresen.htm)
...and for something a little different...
The good, the bad, and the run-sliced
(http://www.gamedev.net/reference/articles/article386.asp)·
Post Edited (daniel) : 7/21/2005 2:27:11 AM GMT
But I expanded my little Basic Stamp G-Code Interpreter into a 3-axis machine, with basic spindle control, axis limit-switch and feed-hold monitoring, and able to do·either G00 Rapid Move or G01 Interpolated Move.· With all that on board, the·longest part part program I can·execute from EEPROM is about·10 bytes long.
Now, I really want one of these X-Y-Z machines we've been talking about.
Daniel
Post Edited (daniel) : 7/21/2005 7:23:29 AM GMT
Am I right in assuming that I will have to break up the desired steps into "256 step" chunks?
In other words Delta X and Delta Y are integers.
Say I need to move from:
X1.0567 Y1.2045
to
X1.5934 Y2.7548
That comes out to 0.5367 in X and 1.5503 in Y.
At .001" steps that's 536 X steps and 1,550 Y steps.
So my question to bean is, if the head is at X1.0567 Y1.2045 and we need to move to X1.5934 Y2.7548, what would you like me to send to the SX?
Or are we not there yet?
On my end, I'm still working on the plotting code.
Now correctly renders pad size and shapes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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 first line of my line code should have been "Temp=DeltaX / 2"
PLJack,
I hope to be able to handle integers for the movements (-32767 to +32767).
Also I would hope the PC would remember where the head is, so all I would expect is offsets. Of course the table will have to have some kind of "HOME set" cabibility. We will have to decide how to set the HOME position.
We will need some kind of serial handshaking also.
I realize we need three stepper motors to be controlled (for X, Y, and Z), but does the Z axis need to be interpolated along with the X and Y axis ?
I assumed we would move to an X,Y position, then move the Z axis.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
Product web site: www.sxvm.com
"One experiment is worth a thousand theories"
·
pos = 0············ 'total degrees of rotation
y = 0··············· 'y is direction, 1 left, 2 right
disx = 0··········· 'distance from origin
write 0. word pos, y········ 'disable after first run
read 0, word pos, y
write 10, word disx··········disable after first run
read 10, word disx
'go to program
I move the X table any direction.· It writes new values of pos, y and disx to EEPROM.· I power down, disable the above write lines and reload.· Now the program always knows how far it is from the X origin and the total number of degrees travelled.· I can shut the program down, come back hours later and the LCD always tells me exactly where the spindle is in relation to the X origin.
Same thing for the Y bank.
If posts concerning my little MF70 are of no value, please let me know and I will cease and desist.
Sid
I like the idea of using EEPROM to store relevant data, but I think it should be used in combination with a home routine. I know for myself, if I'm working ont he machine it won't be in precisely the same position as before when I power it up again, tho it will probably be close (or maybe not!). Having the machine know generally where it should be in space is valuable however, and I think it should be discussed.
PLJack/Daniel:
The development of the G-code interpreter is exciting, but I have one question: If the toolpaths are running down the center of the tracks, won't that leave copper everywhere but where we want it? Drilling holes seems pretty easy (just a set of XY coordinates to plunge into), but don't we need to interpret trackwidths and compute an outline to cut?
Or am I jumping the gun?
-dave
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
This is not a sig. This is a duck. Quack.
Distance from X - .600
Distance from Y - 1.400
I·can turn everything off, come back the next morning, and the LCD will tell me the exact same thing.· Nothing has moved.· That's why I added the routine - I can be working on something and have to stop several times.· Before this routine was added I had to measure with a micrometer to find out where I was.· The origin - X = 0,
Y = 0 - is always marked with a shallow hole drilled just through the copper.
Sid
Keep posting.· At least you have real hardware--I could become jealous <grin>.
And thanks for the tip for setting a machine's home position.
Daniel
The first is plotting the wire's trace; the second is plotting the outline of that same trace.
One way of doing this on a standard mill·might be to have the tool tip, with a G41 Left Offset, machine the circuit trace.· Then machine the same circuit trace with a G42 Right Offset.· In this case have the each of the tool offsets be one-half of the desired circuit-trace width plus one-half of the tool's cutting radius.· See http://www.timgoldstein.com/cad_cam/diacomp.htm·for a nice diagram.
Daniel
Post Edited (daniel) : 7/21/2005 3:15:43 PM GMT
My personal goal is to have an X-Y-Z machine with each axis roughy equal in size.· Hence my thoughts include this hope of a future realization.
A question though,· what your design goal of the controller?· Is it a vector to stepper-steps converter?· Is it a fullblown (microstepping, current limiting, etc.)·stepper controller?· Something else?· What is it's output to the stepper motors:· Step/Direction, or Coil Phase?
Daniel.
Sid
As long as the stepper controller is energized, it will keep a holding current applied to maintain a particular phase of the step sequence when the motor is stopped.
But when you power the controller down, then restart it, is there any guarantee that it will power up to that same phase? I know that earlier controllers would power up to a random phase. This could make the motor jog a step, and throw maybe 0.001 inch of inconsistency, or whatever a step is geared at, into the location.
Sometimes a single step makes a difference (and sometimes it doesn't).
David
There you go!
That's is great news.
That is the strength of writing the software from scratch. The PC can do anything you wish.
And yes, the PC will keep track of the head. This functionality requires that the SX report on successful maneuvers.
I have some thoughts on that.
Given the communication level between the PC and SX I really recommend we use a MAX232 or similar to enable a full fledged serial communication.
On the software side I have already implemented full serial ability including the serial configuration window.
I have done this many times so it went pretty quick.
I also would suggest that the SX default to 9600 baud on power up. the speed can be "ramped" up by the software.
That is why I'm always talking about protocols. Not serial protocols but our own "PC->SX" communication protocol.
Correct.
As I see it Z axis interpolation would come about in phase three of the project when we start working on a 3D mill.
By then we will have learned allot.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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.
What does everyone think about a very tiny hole in the platform with a photoresistor underneath it?
Then place an LED device in the chuck.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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.
Please don't stop posting.
I have said this before but it is worth mentioning.
If you think you have nothing to offer, then you are wrong.
As for you Sid. You ACUALLY have a mill. "No value"!! are you kidding?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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.