Regarding drive motors, at this point we are planning to accommodate several "standard" sized motor mounts. Sizes 17, 23, 34 were recommended. We are looking at supplying two drive options, one being lead screw for precise positioning, albeit a little slow, and the other belt positioning, faster but not as precise. In both cases steppers are presently contemplated, but a DC approach with pulse encoder will also be possible later. Although we will have standard kit reccommendations, the user can choose the items he wants to make up his own "kit".
Furthermore, the drive method (screw or belt) for each axis can be chosen independently, although the short Z stroke will generally be lead screw.
Terry; in regard to SX executing simple instructions, remember that circular interpolation cannot be done by the PC as it's timing is not precise enough. Constant real-time position knowledge (feedback) of the driving system is required to keep the two (or three) axes in sync with each other for making prescribed arcs and circles.
It it for the same reason that slop and backlash cannot be tolerated. A unit that has backlash can move in straight lines, but the compensation method cannot accurately do curves.
At present (subject to change) kits to make up the following nominal sizes are contemplated to provide an accessible work area of 24" by 18"; 18" by 12"; and 12" by 9". This permits paper sizes of 8.5x11, 11x17 and 17x22 to be handled.
Two basic table/motion styles will be available:
A: Fixed table; X moving gantry; Y slide on the gantry; Z stroke on the slide.
B: X moving table; fixed gantry with Y slide; Z stroke on the slide.
Presently we are not considering an XY moving table because it requires a footprint 4 times the work area.
We expect the pieces to be interchangable so one could design their own shapes and sizes using our standard components.
Oh, I can see this is going to be FUN...No really FUN...May have to use the SX48/52 because they have twice the code space. Hmmm maybe one of those $10 protoboards....
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
I'm starting to get excited...it sounds like specifications are coming along nicely.
I'm going to toss in my vote for Excellon drill files (the .drd and .drl I mentioned before) as well as DXF for baord outlines. Just about every decent package can output the former, and export to the ltter, tho I think those of us using Eagle would appreciate a basic gerber converter for outlines.
I also agree that the SX-PC comm link should be as lightweight as possible. I also had thought on some object primatives:
From the PCB perspective, the following would work well:
Rectangle (4 x-y coordinates)
Circle (x-y center and scalar radius)
Arc (x-y center, scalar radius, starting angle, ending angle)
Line (2 x-y points)
Drill location (x-y point, drill depth)
This may require an SX28 to do something akin to the worlds largest switch() statement as a pre-processor, especially for the arc and circle commands.
However, if the machine is going to be milling anything in 3-dimensions, the issue of 3D shapes will quickly rear it's ugly head, and I'm not sure how to deal with that. Adding a Z-axis coordinate to all of the above, and restricting primative orientation to cardinal planes would make a simple 3D description set like so:
Rectangle (4 x-y-x coordinates)
Circle (x-y-x center and scalar radius)
Arc (x-y-x center, scalar radius, starting angle, ending angle)
Line (2 x-y-x points)
Curves or arcs on anything but the cardinal planes would be verboten. Complex curves would need to be built up from the primitives.
I know this is pretty far from g-codes, but I'm not entirely convinced that a super-lightweight protocol is reasonable either.
I have some samples coming from Ramtron of some small (1-256Kb) serial static RAM modules that could easily be used as scratchspace for serial decoding. That may be able to be used to enable a more structured protocol.
I have a blinding headache and am running on next to zero sleep, so it may be less logical than I think it is, but I wanted to put it out for discussion anyway.
-dave
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
This is not a sig. This is a duck. Quack.
For those that are reading this thread regularly and feel that they can't really contribute, we need some web research done.
It would be useful to me and others on this project if we had some links to the following file specifications:
Excellon drill format
G-Code format
2d DXF format
I have started to bone out the software. I will be posting software updates in this thread from time to time.
I will be coding from the ground up so expect the first dozen updates to be not so exciting.
Bean,
Dave brought up a good point about primitives. How should we handle that code wise.
For a Line or Square I could just send the SX point A to point B positions. Same for drill positions. Not a real big deal.
But what about Circles and Arcs? They have infinite points. I wonder if there is enough code space in the SX for interpolation.
In any case I recommend we focus on straight lines and drilling for version one. With an eye towards complex curves in the near future.
Also using the SX proto board is a great idea. It would be good for Prallax as well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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 have one request about the serial link between PC & SX:· please make the protocol a printable ASCII one (I don't recall that this has been discussed, and serial does not necessarily imply printable characters).
I almost did not respond to the following, but based on· subsequent dialog, I thought it worthwhile.
PLJack said...
Bean and Daniel, I think you are talking about two different things.
I really dont think the SX will have enough RAM to decode G-Codes.
G-Code translation is the job of the PC software.
Daniel is talking about the PC side. Bean is talking about the SX side.
I understand your position, but I was really talking about the SX interpreting a subset of the G-Code universe.·
It is the following several items that specifically leads me to clarify a bit what I was meaning.
Bean (Hitt Consulting) said...
The SX should be given only the most rudimentary commands.
pjv said...
in regard to SX executing simple instructions, remember that circular interpolation cannot be done by the PC as it's timing is not precise enough. Constant real-time position knowledge (feedback) of the driving system is required to keep the two (or three) axes in sync with each other for making prescribed arcs and circles.
Dave Paton said...
I also agree that the SX-PC comm link should be as lightweight as possible. I also had thought on some object primatives:
From the PCB perspective, the following would work well:
Rectangle (4 x-y coordinates)
Circle (x-y center and scalar radius)
Arc (x-y center, scalar radius, starting angle, ending angle)
Line (2 x-y points)
Drill location (x-y point, drill depth)
...
However, if the machine is going to be milling anything in 3-dimensions, the issue of 3D shapes will quickly rear it's ugly head, and I'm not sure how to deal with that. Adding a Z-axis coordinate to all of the above, and restricting primative orientation to cardinal planes would make a simple 3D description set like so:
Rectangle (4 x-y-x coordinates)
Circle (x-y-x center and scalar radius)
Arc (x-y-x center, scalar radius, starting angle, ending angle)
Line (2 x-y-x points)
Curves or arcs on anything but the cardinal planes would be verboten. Complex curves would need to be built up from the primitives.
In their essence, G-Codes are motion primitives.· For example, by examining the first 4 defined G-Codes
G00·-- Move [noparse][[/noparse]all axes] in a straight line as rapidly as possible
G01 -- Move [noparse][[/noparse]all axes in a coordinated fashion so that the tooltip moves] in a straight line with some form of ramped acceleration/decelleration
G02 -- move in an arc in the clockwise direction
G03 -- move in an arc in the counter-clockwise direction
These G-Codes all have essentially the same arguments that Dave Paton suggests.· They differ from Paton's suggestion in that a 'rectangle' would be composed of four lines (G00/G01), and 'circles' may be required to be composed of up to 4 arcs (G02/G03) depending on implementation.
I fully agree with Paton that motions should be restricted (for now, at least) in the cardinal planes.
So what about the rest of the G-Codes?· Mostly they have to do with setting the conditions under which the motion interpreter will do its work, have to do with some things outside the project's scope (like lathe operation), etc.· The four codes referenced above could be the only motion G-Codes necessarty to implement for this project's goals.·
BTW, Gerber, Excellon, and similar formats are, in my opinion, essentially·variations on the basic G-Code world view that have been derived to meet specific vertical needs.
However, it is your project, I'll let the issue rest.·
Bean (Hitt Consulting) said...
I can see this is going to be FUN...
Yup, that is what this ia all about.
I hope to have an informal introduction to CAD/CAM/CNC, as·Peter (pjv) suggested,·ready by the end of the week.
Please don't hit me, but....Can't arcs and circles be translated into small line segments by the PC ?
Yes, I'm trying to wimp out of create code to draw arcs. [noparse];)[/noparse]
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
I think this is not quite adequate, and I believe we need AT LEAST to add:
G25 subroutine call
G67 modal off (stops action when position is reached -eg. stop Z stroke)
G68 modal on (enables action each time position is reached -eg Z drill stroke)
G69 go machine (hard) home
G90 absolute positioning
G91 incremental positioning
G92 set part absolute zero reference
M00 cycle stop
M30 rewind program list
M75 load position
How do the Cad-like programs handle arcs and curves...they also need to know more information other than start/stop points otherwise, again, there's be infinite paths.
Do the Cad-like programs list a bunch of small points for an arc?
or do they simply say it's a positive arc or negative arc (Up and Right being postive and down and left being negative----in relation to a plot).
Depending on the size of your arc, you can get away with fewer points....but as the arc enlarges, you'll want more points to make it look more smooth.
Dunno....just sitting on the fencepost watchin and commenting!
I like what I'm reading so far though!
Remember the babysteps and just worry about moving to X,Y position and drilling....Mark2 will be trace making!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ ·
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."
The PC's interaction speed with the motion system is insufficient for CONTINUOUS control. Windoze frequently goes away for a bit to do its own thing and this would cause a hiccup in the motion; absolutely intolerable. That will produce a lot of scrap and break cutters.
I firmly believe that each motion needs to be atomic, and itself not rely on the PC for execution.
I'm sure you have a lot of time available (Ha!), so might I suggest assessing the software needs in sections as follows:
1) Rapid motion to an x,y,z coordinate where the axes are independent (G00) appears to be trivial software. Simple acceleration, then constant speed, then deceleration of each axis independent of the other axes. This generally does not generate a straight line, but it is normally used for "non cutting" positioning.
2) Linear interpolation to an x,y,z coordinate where the axes are "linked" (G01); acceleration, constant speed, deceleration, with each of the axes linked to each other so that a straight line is produced by the motion. This will be quite a bit tougher, but I'm sure still OK for an SX.
When you get done looking at that, then the toughie;
3) Circular interpolation ... how in an SX? I expect we need precision sine/cos values; probably more than can be stored in even an external table. So how about calculating them as needed (that is prior to the move) using the CORDIC method. Will this be fast enough? Need some help here guys!
Clearly we need some insightful discussion on this, especially number 3)
At the risk of people freaking out on me (another thread), I recommend a Google search using the terms "bresenham" and "circle". A little history goes a long way here. All of the problems that need to be solved in this have already been solved and were typically solved decades ago.
Jack Bresenham, an IBM researcher in the 1960's, realized that there was a need to plot straight lines on things likes plotters and raster display devices and invented what has come to be known as the Bresenham algorithm. He presented this in a paper in August of 1963. Of course, Jack was a really clever boy. He also figured out a way to do circles. He presented that paper in January of 1964.
In both cases, the really applicable part to the current problem is that both algortihms are integer only. Yep, he was a really clever boy that old Jack. Bean, go for it. Do the research, study a little computer history, and re-implement Jack's work. If he did it in the 1960's, you can do it in 2005.
Having designed, built, and worked with more than my fair share of stepper based motion control systems (without using any off the shelf motion control components), I have been down this path before.
If there's a concern over running on a "shakey" windows platform...is there a thought that this could be run in a Linux environment!?
We operate our radar and subsystems on linux platforms because there are fewer (*knocks on wood*) issues and it's just plain more stable!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ ·
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."
PLJack said...
For those that are reading this thread regularly and feel that they can't really contribute, we need some web research done.
It would be useful to me and others on this project if we had some links to the following file specifications:
Excellon drill format
G-Code format
2d DXF format
There is a lot of info here if you download the PDF manuals for MACH2.
BTW, is there any reason we couldn't use this software to control the mill? The demo is free for up to 1000 lines of G-code with dxf import capabilities and a whole host of other features. It looks like the full blown version is about $150. We could design a parallel breakout board with opto isolation and use the SX to drive the steppers with a forward, reverse and enable command.
Bean (Hitt Consulting) said...
Please don't hit me, but....Can't arcs and circles be translated into small line segments by the PC ? Yes, I'm trying to wimp out of create code to draw arcs. [noparse];)[/noparse]
Bean.
Sure, but I think the results would be poor.
We have plenty to do before the Arc issue, So don't sweat it just yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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.
steve_b said...
If there's a concern over running on a "shakey" windows platform...is there a thought that this could be run in a Linux environment!?
We operate our radar and subsystems on linux platforms because there are fewer (*knocks on wood*) issues and it's just plain more stable!
Two thoughts:
I don't have a Linux development environment to write the software.
I doubt the average user would be able to install it. Nor have an extra computer laying around to install it on.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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...
Two thoughts:
I don't have a Linux development environment to write the software.
I doubt the average user would be able to install it. Nor have an extra computer laying around to install it on.
· Definately not trying to nitpick....but most kernels are free to download and can be easily enough set up for a dual boot system. · · I've got a few friends in a few different areas of 'computer controlled...stuff' haha....one being a sound engineer.· He's got a big Mackey recording board and it runs on it's own version of Mackey software.· I do believe it's windows based, but it's built with a different angle--to be robust and sturdy enough that it doesn't glitch when it's needed.
So, if there was a need to have a sturdy OS to run things....linux is free.
I don't even have linux....use it somewhat at work....but I'd totally jump in to it if the 'machine' was to run on it.
Just thinking out loud! [noparse];)[/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."
BTW, is there any reason we couldn't use this software to control the mill?
I'm not sure to be honest.
If this is the route we want to take then tell me now before I drop a hundred hours into software development.
I'm not trying to take away from your contribution but rather save you some time and future support questions.
I have been tossing together a low dollar mill in the garage since this post started and will likely use this software at least for testing. Upon completion of the structure I will post some images or·a link and make CAD files available for anyone else interested. Could possibly have it done by the end of the weekend.
The fact remains that most users use Microsoft.
Not that I like it myself but since this is a community project and most people on this community use Microsoft I think we should stick with MS instead of linux.
( -> maybe in the long term someone wants to do a port to linux but this shouldn't be our primairy goal for now)
Again, there are a thousand reasons why Linux is better then Microsoft but if the overall design is good (clear separation of responsibilities, ...) I don't see any reason why this project wouldn't run on crappy Windows.
Let's first try making something that actually works before going any further. One step at a time.
One other remark:
I myself am from Europe - Belgium to be exact.
I would love it if the parts of the final design would also be available to users outside the States or Canada.
On a previous post someone mentioned the "brute" PCB milling machine - a perfect example of something that cannot be made by users outside the US and Canada since the essential parts simply aren't available for us to purchase.
But, if parallax is going to help with the distribution of kits I think this isn't going to be a problem.
Again, the same remark here.
If I'm in the minority, and making the design feasable for people outside the US would take a tremendous amount of effort, by all means, just go with a US-based design instead of an international design.
The main problem I see with this community project is that there are too many different/conflicting requirements from people having different agenda's.
(ie the previous posts about the accuracy of the mechanical design)
It's good that there are some people that take leadership in the different areas (mechanical, software, electrical, ...) and can make decisions in the best interest of the community.
Even Linux is subject to interrupts of uncertain length. If you want the PC to determine the timing between stepper steps at anything faster than a moderate step rate then you'll need some form of real-time operating system, whether Linux or something else.
Bean, I know that the Sx coding is your area, so I hope you'll excuse me if I brainstorm a bit, because this sounds like a really cool project.
Why not give an Sx lots of external RAM memory, build queue management functions, let the Sx store many step commands, then let the PC send a command to have the Sx execute all queued step commands? Then the PC can do the calculations to find the best motions to generate circles, arcs, etc and let the Sx do what its good at - real time.
Let each command be extremely simple, something like: "X+375" = "step motor X one step clockwise at 375 microseconds." And "A"=stop. "B"=go. "C" = return number of commands in queue, "D" return time remaining until last motor command is executed, and so on. Let the time be relative to the execution of the last executed command.
Let the PC build groups of 1 to tens of thousands or more of individual commands like these. Send them as an RS232 ASCII stream of characters to the Sx. As soon as the Sx receives the "go" command, the Sx would begin executing step commands sequentually from the head of the queue.
With serial ASCII, and simple commands, any old computer should be able to generate and send commands, whether Linux, Windows, my dad's old 386, my wife's Mac...
With VP technology, an Sx should be able to pop the next motor command off the queue, execute it at the proper time, respond to user info requests, and receive and push new queue entries.
An interesting concept. It kind of takes all the real time issues away from the PC, yet uses its crunching power. and leaves the SX with only the most basic, albeit real time tasks. I like it if there are no "gotcha's".... need to think about that some more.
Bean (Hitt Consulting) said...
I would be open to that method. Would put alot of the work on the PC software developer though...
Bean.
Bean (Hitt Consulting) said...
I would be open to that method. Would put alot of the work on the PC software developer though...
Bean.
That has been my plan from the beginning.
I thought I made that clear. One of the draw backs of this type of communication I guess.
Timing is not an issue with a serial command / response system.
It is a very simple process. The SX run the motors in a very precise manner and only looks to serial when it need something to do or has just finished a task.
I'm fine with a low byte command buffer. No need for external RAM. (at this point)
As long as the SX reports that one command has been finished I can send it another one.
That is why I talk about an SX/PC protocol.
That is why I talk about translating G-Codes.
That is why I talk about importing files.
That is why I am writing software.
All the CNC apps I have seen directly drive a motor control board.
From some private messages I gather that most real time CNC software apps have a manual command mode.
From what I have read they direct drive a motor control board one command at a time.
I see no command/response ability so I unsure about how long you know to wait before sending a new command.
But I do not know a whole lot about the industrial interfaces.
My take is that this is a light weight mill and none of the apps I have seen are light weight by any means.
They are designed to run a broad range of controller boards.
This next comment is from a programmers point of view but , the Mach software mentioned earlier breaks every user interface rule I have ever learned. Its a monster app.
I am happy to write the software. Actually now that I have started I'm looking forward to the challenge.
BUT, I do not HAVE to write it. There is always another software app on my todo list.
So, here are the options and I will wrap up with my opinion.
1) Build a motor control board with SX or two. Or buy a controller. Use an off the shelf application to control it.
2) Build a light / custom / Low part / inexpensive motor control with an SX. Write some software to control it and do what ever we can dream up.
Ok, so the second option is my opinion.
This is a small mill. I'm not sure if it even warrants any industrial components.
If we can settle on option two, then I think its time for me and Bean to do a little emailing to hammer out a protocol.
We really need to make a decision and move forward.
So, speak up.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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 like the concept of continuous motion, and if we go the route of "PC as cruncher", then there should be "some" small buffer in the SX ready to execute the next several commands. Remember, that in this mode many of the low level commands will be executed very rapidly by the SX, and it is NOT good to have tools engaged and rotatiing while the motion is momentarily stalled. For example, it can be hard on bits when drilling boards where the fiberglass heats up, and the bit gets hot and burns. Or while milling, and the lateral motion stops, the deflection of the cutter returns to "normal", leaving a big mark in the cut edge. The "drip feeding" method mentioned earlier will help eliminate or at least minimize this situation.
If the SX software is written such that there IS a buffer, then when the project nears completion, all "left over" ram can be allocated to that buffer. Also it would be useful to pick a reasonably fast serial link; 38,400 gives 4 bytes per millisecond, so a simple command might be transferred in 2 or so mSec. At that rate the SX can do the software UARTing and have time to drive 3 axes. I suggest a single SX running all three axes; it makes the PC com simpler, and gives better opportunity for the SX synchronizing the axes' motion, should that become neccessary.
Jack, please keep the rest of us in the loop as to protocol.....there could be issues here.
Just a small heads up from someone who works with cnc machines. Before you get too worried about the speed of the system, you have to determine how fast it actually needs to be. There are a lot of variables to consider with the type of material that is to be machined. Some need high cutter speeds and low feed rates, some materials the opposite. Fiberglass in pcb boards is not easy to cut, mill or drill, you would probably need a diamond tip cutter, and they are prone to heat up at high feed rates, which is not good. Also high feed rates can cause overrun on the motors, delay from when the stop signal is sent, to when the motor actually stops. So a ramping control will have to be used on the motors to get good accuracy. So, to make this short, do some research into the application itself, you may not need a super fast controller for a machine that has a slower feedrate. Take it or leave it, but it is something that should be looked into.
Comments
Regarding drive motors, at this point we are planning to accommodate several "standard" sized motor mounts. Sizes 17, 23, 34 were recommended. We are looking at supplying two drive options, one being lead screw for precise positioning, albeit a little slow, and the other belt positioning, faster but not as precise. In both cases steppers are presently contemplated, but a DC approach with pulse encoder will also be possible later. Although we will have standard kit reccommendations, the user can choose the items he wants to make up his own "kit".
Furthermore, the drive method (screw or belt) for each axis can be chosen independently, although the short Z stroke will generally be lead screw.
Terry; in regard to SX executing simple instructions, remember that circular interpolation cannot be done by the PC as it's timing is not precise enough. Constant real-time position knowledge (feedback) of the driving system is required to keep the two (or three) axes in sync with each other for making prescribed arcs and circles.
It it for the same reason that slop and backlash cannot be tolerated. A unit that has backlash can move in straight lines, but the compensation method cannot accurately do curves.
At present (subject to change) kits to make up the following nominal sizes are contemplated to provide an accessible work area of 24" by 18"; 18" by 12"; and 12" by 9". This permits paper sizes of 8.5x11, 11x17 and 17x22 to be handled.
Two basic table/motion styles will be available:
A: Fixed table; X moving gantry; Y slide on the gantry; Z stroke on the slide.
B: X moving table; fixed gantry with Y slide; Z stroke on the slide.
Presently we are not considering an XY moving table because it requires a footprint 4 times the work area.
We expect the pieces to be interchangable so one could design their own shapes and sizes using our standard components.
More later.
Peter (pjv)
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
"What's the difference between ignorance and apathy ?"
"I don't know, and I don't care."
·
I'm going to toss in my vote for Excellon drill files (the .drd and .drl I mentioned before) as well as DXF for baord outlines. Just about every decent package can output the former, and export to the ltter, tho I think those of us using Eagle would appreciate a basic gerber converter for outlines.
I also agree that the SX-PC comm link should be as lightweight as possible. I also had thought on some object primatives:
From the PCB perspective, the following would work well:
Rectangle (4 x-y coordinates)
Circle (x-y center and scalar radius)
Arc (x-y center, scalar radius, starting angle, ending angle)
Line (2 x-y points)
Drill location (x-y point, drill depth)
This may require an SX28 to do something akin to the worlds largest switch() statement as a pre-processor, especially for the arc and circle commands.
However, if the machine is going to be milling anything in 3-dimensions, the issue of 3D shapes will quickly rear it's ugly head, and I'm not sure how to deal with that. Adding a Z-axis coordinate to all of the above, and restricting primative orientation to cardinal planes would make a simple 3D description set like so:
Rectangle (4 x-y-x coordinates)
Circle (x-y-x center and scalar radius)
Arc (x-y-x center, scalar radius, starting angle, ending angle)
Line (2 x-y-x points)
Curves or arcs on anything but the cardinal planes would be verboten. Complex curves would need to be built up from the primitives.
I know this is pretty far from g-codes, but I'm not entirely convinced that a super-lightweight protocol is reasonable either.
I have some samples coming from Ramtron of some small (1-256Kb) serial static RAM modules that could easily be used as scratchspace for serial decoding. That may be able to be used to enable a more structured protocol.
I have a blinding headache and am running on next to zero sleep, so it may be less logical than I think it is, but I wanted to put it out for discussion anyway.
-dave
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
This is not a sig. This is a duck. Quack.
It would be useful to me and others on this project if we had some links to the following file specifications:
Excellon drill format
G-Code format
2d DXF format
I have started to bone out the software. I will be posting software updates in this thread from time to time.
I will be coding from the ground up so expect the first dozen updates to be not so exciting.
Bean,
Dave brought up a good point about primitives. How should we handle that code wise.
For a Line or Square I could just send the SX point A to point B positions. Same for drill positions. Not a real big deal.
But what about Circles and Arcs? They have infinite points. I wonder if there is enough code space in the SX for interpolation.
In any case I recommend we focus on straight lines and drilling for version one. With an eye towards complex curves in the near future.
Also using the SX proto board is a great idea. It would be good for Prallax as well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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/7/2005 3:36:29 PM GMT
I almost did not respond to the following, but based on· subsequent dialog, I thought it worthwhile.
I understand your position, but I was really talking about the SX interpreting a subset of the G-Code universe.·
It is the following several items that specifically leads me to clarify a bit what I was meaning.
In their essence, G-Codes are motion primitives.· For example, by examining the first 4 defined G-Codes
G01 -- Move [noparse][[/noparse]all axes in a coordinated fashion so that the tooltip moves] in a straight line with some form of ramped acceleration/decelleration
G02 -- move in an arc in the clockwise direction
G03 -- move in an arc in the counter-clockwise direction
These G-Codes all have essentially the same arguments that Dave Paton suggests.· They differ from Paton's suggestion in that a 'rectangle' would be composed of four lines (G00/G01), and 'circles' may be required to be composed of up to 4 arcs (G02/G03) depending on implementation.
I fully agree with Paton that motions should be restricted (for now, at least) in the cardinal planes.
So what about the rest of the G-Codes?· Mostly they have to do with setting the conditions under which the motion interpreter will do its work, have to do with some things outside the project's scope (like lathe operation), etc.· The four codes referenced above could be the only motion G-Codes necessarty to implement for this project's goals.·
BTW, Gerber, Excellon, and similar formats are, in my opinion, essentially·variations on the basic G-Code world view that have been derived to meet specific vertical needs.
However, it is your project, I'll let the issue rest.·
Yup, that is what this ia all about.
I hope to have an informal introduction to CAD/CAM/CNC, as·Peter (pjv) suggested,·ready by the end of the week.
Best Regards,
Daniel
Post Edited (daniel) : 7/19/2005 12:28:28 AM GMT
Daniel
I understand your position.
My point was for Bean to design the best he can given the hardware limitations and I would translate everything on my end.
Your the Man. Thanks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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.
Yes, I'm trying to wimp out of create code to draw arcs. [noparse];)[/noparse]
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"
·
Thanks for the input and commitment for the tutorial.
Regarding the four being the only initial codes:
G00 rapid (x,y,z unsynchronized) positioning
G01 linear interpolation (x,y,z sychronized) positioning
G02 clockwise circular interpolation
G03 counterclockwise circular inetrpolation
I think this is not quite adequate, and I believe we need AT LEAST to add:
G25 subroutine call
G67 modal off (stops action when position is reached -eg. stop Z stroke)
G68 modal on (enables action each time position is reached -eg Z drill stroke)
G69 go machine (hard) home
G90 absolute positioning
G91 incremental positioning
G92 set part absolute zero reference
M00 cycle stop
M30 rewind program list
M75 load position
Cheers,
Peter (pjv)
Do the Cad-like programs list a bunch of small points for an arc?
or do they simply say it's a positive arc or negative arc (Up and Right being postive and down and left being negative----in relation to a plot).
Depending on the size of your arc, you can get away with fewer points....but as the arc enlarges, you'll want more points to make it look more smooth.
Dunno....just sitting on the fencepost watchin and commenting!
I like what I'm reading so far though!
Remember the babysteps and just worry about moving to X,Y position and drilling....Mark2 will be trace making!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·
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."
The PC's interaction speed with the motion system is insufficient for CONTINUOUS control. Windoze frequently goes away for a bit to do its own thing and this would cause a hiccup in the motion; absolutely intolerable. That will produce a lot of scrap and break cutters.
I firmly believe that each motion needs to be atomic, and itself not rely on the PC for execution.
Cheers,
Peter (pjv)
daniel
I'm sure you have a lot of time available (Ha!), so might I suggest assessing the software needs in sections as follows:
1) Rapid motion to an x,y,z coordinate where the axes are independent (G00) appears to be trivial software. Simple acceleration, then constant speed, then deceleration of each axis independent of the other axes. This generally does not generate a straight line, but it is normally used for "non cutting" positioning.
2) Linear interpolation to an x,y,z coordinate where the axes are "linked" (G01); acceleration, constant speed, deceleration, with each of the axes linked to each other so that a straight line is produced by the motion. This will be quite a bit tougher, but I'm sure still OK for an SX.
When you get done looking at that, then the toughie;
3) Circular interpolation ... how in an SX? I expect we need precision sine/cos values; probably more than can be stored in even an external table. So how about calculating them as needed (that is prior to the move) using the CORDIC method. Will this be fast enough? Need some help here guys!
Clearly we need some insightful discussion on this, especially number 3)
Cheers,
Peter (pjv)
Jack Bresenham, an IBM researcher in the 1960's, realized that there was a need to plot straight lines on things likes plotters and raster display devices and invented what has come to be known as the Bresenham algorithm. He presented this in a paper in August of 1963. Of course, Jack was a really clever boy. He also figured out a way to do circles. He presented that paper in January of 1964.
In both cases, the really applicable part to the current problem is that both algortihms are integer only. Yep, he was a really clever boy that old Jack. Bean, go for it. Do the research, study a little computer history, and re-implement Jack's work. If he did it in the 1960's, you can do it in 2005.
Having designed, built, and worked with more than my fair share of stepper based motion control systems (without using any off the shelf motion control components), I have been down this path before.
Thanks, PeterM
We operate our radar and subsystems on linux platforms because there are fewer (*knocks on wood*) issues and it's just plain more stable!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·
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."
Bresenham.... a good link, thanks.
Peter (pjv)
There is a lot of info here if you download the PDF manuals for MACH2.
http://www.artofcnc.ca/
BTW, is there any reason we couldn't use this software to control the mill? The demo is free for up to 1000 lines of G-code with dxf import capabilities and a whole host of other features. It looks like the full blown version is about $150. We could design a parallel breakout board with opto isolation and use the SX to drive the steppers with a forward, reverse and enable command.
Sure, but I think the results would be poor.
We have plenty to do before the Arc issue, So don't sweat it just yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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.
Two thoughts:
I don't have a Linux development environment to write the software.
I doubt the average user would be able to install it. Nor have an extra computer laying around to install it on.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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 not sure to be honest.
If this is the route we want to take then tell me now before I drop a hundred hours into software development.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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.
===========
7/6/2005 4:05PM
Started SXYZ project.
7/6/2005 4:53PM
Fleshed out configuration file code, using XML format.
7/6/2005 5:21PM
Added serial Communications code.
7/6/2005 11:55PM
Fleshed out options window.
Added Com port options and save / load code.
7/7/2005 1:32PM
Created XML store class so that all windows can load /save/share the same configuration information.
7/7/2005 3:32PM
Added action tool bar. Should allow for plenty of expansion as the software grows.
7/7/2005 4:39PM
Settled on a three panel design for the application.
Added Activity panel.
Added tabbed page list for job related items.
7/7/2005 6:18PM
Fleshed out activity logger.
7/7/2005 8:59PM
Added read/save source file and viewer jobtab.
7/7/2005 10:32PM
Boned activity syntax highlighting.
===========
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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've got a few friends in a few different areas of 'computer controlled...stuff' haha....one being a sound engineer.· He's got a big Mackey recording board and it runs on it's own version of Mackey software.· I do believe it's windows based, but it's built with a different angle--to be robust and sturdy enough that it doesn't glitch when it's needed.
So, if there was a need to have a sturdy OS to run things....linux is free.
I don't even have linux....use it somewhat at work....but I'd totally jump in to it if the 'machine' was to run on it.
Just thinking out loud! [noparse];)[/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."
I have been tossing together a low dollar mill in the garage since this post started and will likely use this software at least for testing. Upon completion of the structure I will post some images or·a link and make CAD files available for anyone else interested. Could possibly have it done by the end of the weekend.
Not that I like it myself but since this is a community project and most people on this community use Microsoft I think we should stick with MS instead of linux.
( -> maybe in the long term someone wants to do a port to linux but this shouldn't be our primairy goal for now)
Again, there are a thousand reasons why Linux is better then Microsoft but if the overall design is good (clear separation of responsibilities, ...) I don't see any reason why this project wouldn't run on crappy Windows.
Let's first try making something that actually works before going any further. One step at a time.
One other remark:
I myself am from Europe - Belgium to be exact.
I would love it if the parts of the final design would also be available to users outside the States or Canada.
On a previous post someone mentioned the "brute" PCB milling machine - a perfect example of something that cannot be made by users outside the US and Canada since the essential parts simply aren't available for us to purchase.
But, if parallax is going to help with the distribution of kits I think this isn't going to be a problem.
Again, the same remark here.
If I'm in the minority, and making the design feasable for people outside the US would take a tremendous amount of effort, by all means, just go with a US-based design instead of an international design.
The main problem I see with this community project is that there are too many different/conflicting requirements from people having different agenda's.
(ie the previous posts about the accuracy of the mechanical design)
It's good that there are some people that take leadership in the different areas (mechanical, software, electrical, ...) and can make decisions in the best interest of the community.
Keep up the good work.
Bean, I know that the Sx coding is your area, so I hope you'll excuse me if I brainstorm a bit, because this sounds like a really cool project.
Why not give an Sx lots of external RAM memory, build queue management functions, let the Sx store many step commands, then let the PC send a command to have the Sx execute all queued step commands? Then the PC can do the calculations to find the best motions to generate circles, arcs, etc and let the Sx do what its good at - real time.
Let each command be extremely simple, something like: "X+375" = "step motor X one step clockwise at 375 microseconds." And "A"=stop. "B"=go. "C" = return number of commands in queue, "D" return time remaining until last motor command is executed, and so on. Let the time be relative to the execution of the last executed command.
Let the PC build groups of 1 to tens of thousands or more of individual commands like these. Send them as an RS232 ASCII stream of characters to the Sx. As soon as the Sx receives the "go" command, the Sx would begin executing step commands sequentually from the head of the queue.
With serial ASCII, and simple commands, any old computer should be able to generate and send commands, whether Linux, Windows, my dad's old 386, my wife's Mac...
With VP technology, an Sx should be able to pop the next motor command off the queue, execute it at the proper time, respond to user info requests, and receive and push new queue entries.
David
An interesting concept. It kind of takes all the real time issues away from the PC, yet uses its crunching power. and leaves the SX with only the most basic, albeit real time tasks. I like it if there are no "gotcha's".... need to think about that some more.
Hmm.....
Peter (pjv)
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"
·
That has been my plan from the beginning.
I thought I made that clear. One of the draw backs of this type of communication I guess.
Timing is not an issue with a serial command / response system.
It is a very simple process. The SX run the motors in a very precise manner and only looks to serial when it need something to do or has just finished a task.
I'm fine with a low byte command buffer. No need for external RAM. (at this point)
As long as the SX reports that one command has been finished I can send it another one.
That is why I talk about an SX/PC protocol.
That is why I talk about translating G-Codes.
That is why I talk about importing files.
That is why I am writing software.
All the CNC apps I have seen directly drive a motor control board.
From some private messages I gather that most real time CNC software apps have a manual command mode.
From what I have read they direct drive a motor control board one command at a time.
I see no command/response ability so I unsure about how long you know to wait before sending a new command.
But I do not know a whole lot about the industrial interfaces.
My take is that this is a light weight mill and none of the apps I have seen are light weight by any means.
They are designed to run a broad range of controller boards.
This next comment is from a programmers point of view but , the Mach software mentioned earlier breaks every user interface rule I have ever learned. Its a monster app.
I am happy to write the software. Actually now that I have started I'm looking forward to the challenge.
BUT, I do not HAVE to write it. There is always another software app on my todo list.
So, here are the options and I will wrap up with my opinion.
1) Build a motor control board with SX or two. Or buy a controller. Use an off the shelf application to control it.
2) Build a light / custom / Low part / inexpensive motor control with an SX. Write some software to control it and do what ever we can dream up.
Ok, so the second option is my opinion.
This is a small mill. I'm not sure if it even warrants any industrial components.
If we can settle on option two, then I think its time for me and Bean to do a little emailing to hammer out a protocol.
We really need to make a decision and move forward.
So, speak up.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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 like the concept of continuous motion, and if we go the route of "PC as cruncher", then there should be "some" small buffer in the SX ready to execute the next several commands. Remember, that in this mode many of the low level commands will be executed very rapidly by the SX, and it is NOT good to have tools engaged and rotatiing while the motion is momentarily stalled. For example, it can be hard on bits when drilling boards where the fiberglass heats up, and the bit gets hot and burns. Or while milling, and the lateral motion stops, the deflection of the cutter returns to "normal", leaving a big mark in the cut edge. The "drip feeding" method mentioned earlier will help eliminate or at least minimize this situation.
If the SX software is written such that there IS a buffer, then when the project nears completion, all "left over" ram can be allocated to that buffer. Also it would be useful to pick a reasonably fast serial link; 38,400 gives 4 bytes per millisecond, so a simple command might be transferred in 2 or so mSec. At that rate the SX can do the software UARTing and have time to drive 3 axes. I suggest a single SX running all three axes; it makes the PC com simpler, and gives better opportunity for the SX synchronizing the axes' motion, should that become neccessary.
Jack, please keep the rest of us in the loop as to protocol.....there could be issues here.
Cheers,
Peter (pjv)
kelvin