New ornamental lathe simulator software on google code.

Hi Ornamental Turners,

My name is Bruce Frederiksen. I am a (semi-)retired computer programmer and bumped into Mike Brooks (a friend of my brother-in-law). Mike was talking about writing a computer program to simulate the ornamental lathe and be able to generate G-Code to drive a CNC machine to cut the same part. He was struggling with how to do this and we figured out the basic math tools need on order to accomplish the simulation.

I have written a program in the python programming language (which can be downloaded for free for Macs, Linux and Windows machines). This program simulates the operation of an ornamental lathe and translates the various movements into the CNC coordinate system and generates the G-Code for the CNC machine.

The program has virtually no graphics capabilities, and is not really intended to provide graphics (but might be capable of this with more work). At this point, the program is still in its infancy and so setting up and using the program requires some programming skill. I have written the project as an open source project, free for all, and for all to contribute, on google code called ornamental-lathe-simulator (sorry, I'm not permitted to post URLs on my first post...).

I have limited OT knowledge (only what Mike's taught me). So I don't think that I will be able to pursue this much further without getting some more help on it.

I have the following attachments written, which can be stacked together in any combination just like on an OT machine:
  • elliptical chuck
  • geometric chuck (can be stacked to any number of stages)
  • simple_headstock (as opposed to a rose engine headstock)
  • slide rest
  • chuck_to_cutting_frame converter (converts any combination of chucks to a cutting frame with the addition of a slide rest value, for example I use this to create a 2-stage geometric cutting frame in the vase example explained below).
Other attachments can easily be added, most requiring only 5-10 lines of code. I just haven't done them yet as I don't know what interest there is in this so don't know if I should bother. All of the following would be trivial to add:
  • rose_engine_headstock
  • dome_chuck
  • eccentric_chuck
  • reciprocator
  • spiral_attachment
For my first test project I've been working on a Tormach 4 axis CNC milling machine. This project is a small vase, 4.5 inches high, cut from a 2x4. The vase has an elliptical cross section that is smaller at the bottom and larger at the top, then narrowing down rapidly at the top to a small circular neck. Other than the neck, the rest of the vase has an elliptical cross section (when viewed from the top), but continuously varies the eccentricity setting on the elliptical chuck so that the small ellipse at the bottom doesn't get too narrow.

Then I take the 2-stage geometric chuck figure from Bazley (fig. 3023), rotate it 30 deg to make it more of a T shape and cut it on the face of the vase, wrapping the geometric chuck figure around the bulge in the face of the vase by converting the Y (vertical) motion of the cutting frame into a headstock index offset.

This vase project is in the repository on google code in the examples/vase directory (start with the file), if anybody is interested. I cut the G-Code from this on the Tormach and it looks like it will work, but I screwed up some the machine settings, so it didn't come out quite right (new to CNC and wood working, let alone OT, so still screw up a lot). I can try to cut another piece without screwing up on the operation of the CNC machine if anybody is interested (please let me know).

Anyways, Mike says he's been pushing CNC on the OT crowd for several years and that there is little interest in this sort of thing. I can't proceed much further without working with somebody that knows OT, and even just general wood working, better than I do. I thought I'd just test this lack of interest theory by sending this post out to test the waters. If Mike is right, I guess I'll move on to something else.

But if anybody is interested in pursuing this, I would be happy to work with you! I don't mind doing most of the programming. It would be really nice if somebody with a CNC machine could run the examples, as it's an hour drive for me (each way) to get to the place with the Tormach machine.

Thank you for your consideration,

-Bruce Frederiksen
photos of vase, attempt #1

OK, David asked for pictures. These are pics from my first attempt. You'll see several screw ups on these pics, and I'd be happy to discuss these. (That's one of the reasons I'm here). So I hope that people aren't upset with pics of screw ups on their lovely web site... :)

Well it looks like I'm still not allowed to post URLs, so you'll have to go to the photo gallery and look for the "Bruce Frederiksen image storage" album... :(

This is the front of the vase, shown with the routing tools that I'm using. If you want to get more into this, the tool on top will be central to almost any discussion. The tool on the bottom was only used to do the geometric chuck pattern. There is a combination of operator error on the CNC machine and setup problems with the virtual OT machine. (This my first CNC project, first turning project, first OT project, so lots of learning and lots of mistakes still!)

I'm not sure how much analysis of my mistakes I should include, so I'll go on the light side...

First, let me get the other pictures out of the way so that you'll have a better idea of the shape of this thing.

This is a side view, showing the shape from the side. Notice that the ellipse doesn't narrow very much at the bottom of the vase. This is due to the dynamic eccentricity setting on the virtual OT elliptical chuck.

Top view. The screw ups on the left edge are some test cuts that I had made in this piece of wood prior to cutting the vase. Notice that the right edge of the ellipse is pointed, not round. This explains why the scrolling from the geometric chuck doesn't seem to wrap around on the bottom of the first image. The reason it doesn't wrap on the top is CNC operator error.

I did a little investigative work and discovered that the pointed ellipse is caused by the edge of the work not being vertical all the way around the ellipse the way that the elliptical chuck works. This also explains the two downward sloping groves at the top of the first picture. These are remnants of the roughing cut.

So I looked on wikipedia (this project would not have been possible without it) and figured out the tangent to the ellipse on the elliptical chuck. The following illustration shows this:

I've modified my virtual elliptical chuck to produce these tangent angles and plan to rock the cutter back and forth at this angle so that it is always tangent to the work. If I can also manage to do a better job at operating the CNC machine, I expect attempt #2 to be much better (but don't expect it to be perfect yet).

I hope to do attempt #2 this Friday (June 10) down at the Fab Lab. Don't know if I'll complete it then or not. Will post more pics of attempt #2.

I also have a video (.mp4 file) showing the CNC machine doing the finishing cutting. But I don't know how to make that available to people. It's 14MB in size.

Now that you've got an idea of what I'm up to, I've got a question for y'all that I'll post in a separate post.
Tool offset question

OK, here's my first question.

What I did in attempt #1:

To cut the varying size of ellipses, I have a template on my virtual slide rest. Since the slide rest is set to the semi-minor axis of the ellipse, I used this curve to calculate my tool offsets off of. (This corresponds to the shape seen from the "side_view" image). This offset is based on the 3/4" cutter that I am using.

The tool offset was done based on the slope of the curve at each point and calculating a 3/8" offset perpendicular to that slope at each point in the curve. This offset is then factored into my slide rest template.

The problem:

The problem is that the slope of curve on the side of this vase varies as you go around the ellipse. So, therefore, the tool offset must also vary, rather than being constant for any given SR position. This means that the tool offset can not be factored into the SR template (unless the template were made two dimensional to be indexed by the SR and the headstock angle).

One solution:

Thinking about this, I figured that I could cut on the end of the tool rather than on the side of it. Thus, the tool would appear to be a square corner as it cuts on the slope of the vase and the tool offset would no longer depend on the slope, but would be a simple constant (though with different signs for the top and bottom of the vase).

Good news: this would eliminate the varying tool offsets altogether!

Bad news: I'm told that cutting this way will tear up the wood and not leave a smooth finish.

Nonetheless, this is what I plan for attempt #2 this Friday (June 10) as no other solution comes to mind that I think I can implement by then.

Advice, other ideas, or general comments welcome. How would you solve this problem?
Elliptical vase, take 2! (more pics)

OK, so I fixed the first set of problems brought up in attempt #1 and cut attempt #2. The two big changes here are:

1. Dynamically rocking the angle of the tool shank to match the tangent of the ellipse. This helped a lot! Now the ellipses have rounded ends and don't have groves cut into them in the roughing passes.

2. Changed to orientation of the tool to cut on the end of the tool, rather than the side of the tool. This solves tight clearances between the tool holder and the work and eliminates the need to base the tool offset on the tangent of the work.

OK, now the pics!

This shows the front (though tilted on its side). You can see that this is much closer! The squared neck, where it meets the body, is how the original drawing was done, but I couldn't cut this on the side of the tool in attempt #1. This was another benefit of cutting on the end of the tool!

The side view. You can just see the curvature of the GC pattern on the face of the vase to match the curve of the vase here.

But I'm still having problems with the rotary table losing position. The ellipse should line up with the bottom (uncut) part of the wood. The rotary table is adding about 15 degrees to the six revolutions (5 roughing cuts, and one finishing cut on the body). Not sure what's causing this. The G-Code looks good. I have the machine set in absolute mode, but it's acting like there are some kind of accumulated round off errors. Anybody got any ideas on this?

And the final pic showing the back where the indexing problem caused the lower part of the back (as seen in this photo) to not even get cut in a small area. You can also see the roughing cuts on the lower edge (again as seen in the photo) that the finishing pass didn't even touch. This shows that there was an extra few degrees of twist between the last roughing cut and the finishing cut. This error is accumulating a few degrees per revolution.

Well that's it! This project was suggested by Mike Brooks, and has proven to be a challenge! But I think that I've got it licked, minus a problem with the rotary table.

What next? I'd like to work with somebody else on a joint project for the next one. Anybody got a CNC machine? I can adopt this program to any CNC machine layout. If not, I can hoof it to Sarasota and continue to use the Fab Lab there, but could still use ideas on what to do.

You can see the machine I've been using (minus the rotary table) here:

And, FWIW, this is my wooden bicycle that I displayed at the Fab Lab grand opening...

Thank you for you interest! Please post ideas for where to go from here. This project needs your active involvement to continue to make progress!


P.S. Is anybody going to the AAW conference this month (June, 2011)? I have some mahogany that I could try cutting and might be able to mail it to Mike up there if anybody would like to see this in person...
I am watching this with interest. While I do have traditional machines (straight and rose), I also have a 3 axis CNC table. I do use it with a lathe set on the table (kale spinshop spinning lathe) to do some cnc router/lathe work.

I'm very interested in being able to produce ovate parts much like these shapes as I am a sword manufacturer. Right now we cut them in the round on the lathe and do the rest of the forming free hand. While it works fine something more like what you are doing would allow me to ornament the turned part directly

I know that my CNC machine supports a 4th axis, I just dont have it setup like this right now.

Thanks for sharing!
During the special interest night at the AAW Symposium next week Bill Ooms will be addressing his CNC machine. He will cover why he went CNC, and I hope he'll address these questions as well.

We're actually putting together a pretty good program for the night which should include John Lea, Jon Magill, and John Calver as well as Bill.

I hope to see you there.

catching up on replies...

Sorry guys, I've been falling behind a little...

Here are my responses to get me caught up. I'd like to know if anybody has taken a look at or tried to use the software yet.

kerrystagmer: If you are cutting the ellipse in two halves, this software should allow you to cut each half of the ellipse without a rotation axis. But adding ornamentation gets a bit trickier. The software can trace out the ornamentation, but if you're using a vee-shaped tool the cuts nearer the edges will be cut at an angle. So one side of the V will get more horizontal, and the other side will get more vertical. It doesn't take much of an angle for this to be quite noticeable. The rotation axis solves this problem by angling the tool (actually angling the work, but same thing) to be perpendicular to the slope of the work. My software should also be able to cut a long curved piece with an elliptical cross section, though this may take some thought on how to set it up.

jschnell1203: I'm using a 4-axis CNC mill at the Sarasota Fab Lab. It's using Mach3 for its control software. My software generates the G-Code. You might also want to look at (emc2). Haven't used it myself though.

David: Yes, I'll be at the AAW Symposium! I definitely plan to attend the OT session Friday night. I'd like to be able to show off my software and see if I can drum up a little interest. Never been to one of these before, so don't know the ground rules. Do I need to sign up somewhere to get a time slot, or is it an open format?

jschnell1203: You have my permission to record anything you like with me in it at the Symposium and make it available to whoever you like.

That's all for now. I expect that the AAW Symposium is going to boggle my mind and get the little gray cells churning. We'll see what comes up. I do need a few brave souls to poke at this software though. Looks like I may have a rose engine project lined up for it.

A couple of ideas that I've had, that I haven't been able to pursue yet:

1. It would be easy to put a template on the nosewheel_phase of the elliptical_chuck. This would let you cut a length of wood with an elliptical cross section, but with the orientation of the ellipse rotating as you go down the length of the work. So you'd end up with a spiral pattern with an elliptical cross section.

2. I did a little poking around and I'm quite sure that the elliptical chuck will also cut ellipses with a negative eccentricity. This would correspond to moving the adjustment ring on the headstock toward the front of the lathe, rather than to the rear of the lathe as is normally done. The difference is that the orientation of the ellipse changes 90 degrees, and the SR offset now defines the semi-major axis, rather than semi-minor axis. So using the vase example, which reduces the eccentricity setting towards the bottom of the vase, this could be extended to bring the eccentricity from a positive setting at the top of the vase, smoothly changing to a negative eccentricity at the bottom of the vase. This would mean that as you go down the vase, the ellipse would gradually turn into a circle, and then switch direction (90 rotation) from there down becoming more elliptical again. I've changed my tangent calculation to also work for negative eccentricities. None of this has been tested, hence the need for volunteers to play with this stuff and try things out!

I'd like to hear your ideas for what you'd like to be able to do with this software. One big question I have is whether it's better to do the traditional G-Code route, where you stand there with your hands in your pockets while the machine does its work; or whether it makes more sense to have the simulator driving the CNC machine in real-time so that you can operate virtual OT controls (e.g, SR offset, tool offset, headstock rotation) and have these controls immediately translated into CNC speak.

More after the Symposium!

We do all of our programing in Acad and use the WinCNC software/hardware with gecko drives for control. Not the cheapest option.

I have friends using Mach3 who have a very high opinion of it and the ablity to setup and control systems.

I suspect the retrofit for my Gorton I plan to build will use Mach3
Second SIN after SIN?

Bruce -- First I have to say I'm excited to see work on a g-code based, 4-axis, real-world approach, with open source! I haven't met you yet, but you may be my new hero. That said, I guess I need to go learn Python now. Hmm.

Mike has been pushing CNC for many years, but unfortunately IMO, he jumped into the deep end of the pool and no one was willing to follow his particular path. The geometric chuck, while mathematically interesting, is w-a-y beyond the grasp of most (contemporary) ornamental turners. Few over here have seen a real chuck, and fewer still have any idea how to use one, much less engage in a discussion with Mike on the idiosyncrasies of the n-th stage of one.

Most people dabbling with motion-control stuff want to do something more than 2D, and the geometric chuck, once it moves beyond the first stage, really only (seems) to have applications in 2D. Many people would say, "scratch work" meaning engraving shallow patterns, or drawing on paper. In fact the really hairy chucks, like the exotic 7-part one Tweddle had, could only be used vertically and for drawing on paper.

That said, your initial attempts at wrapping may be the thing that makes geometric chuck work interesting to more people. But it would be good to solve the much simpler, traditional problems first, again IMHO.

Aside from Mike, a few people are interested in CNC-like systems and I think would like to collaborate in some way. Unfortunately, there is a lot of fragmentation out there right now, and I think it would be great if there was a way to get together at the symposium and talk through some of the basics and goals.

By fragmentation I mean...

1) Platforms: PC, Mac, Linix users
2) Ports supported: Parallel vs. USB ports
3) Languages: C, Python, Java, TCL, Perl, and Mike's use of NI's LabView
4) Controllers: Lots of Mach3/Gecko out there, some Flashcut, newer Open Hardware boards coming--all USB
5) Coordinate system: Lathe, mill, live tooling?, orientation
6) Source input: CAM-like UI, G-Code editor, Solids files, SVG artwork?
7) Output: G-Code, visualization/graphing files, direct machine control?
8) Tools: Support for and definition of "tools" which are unlike existing industry tools (HCF, VCF, UCF, drill frame, Ecc. cutting frame, Ell. cutting frame, Epicycloidal cutting frame, etc., etc.)
9) Chuck/Workpiece orientation: Ecc. chuck, Spiral chuck, Oblique chuck, Dome chuck, Epicycloidal chuck, Geo chuck, etc., etc.
10) "Stacks": The combinatorials of tools and chucks above which you defined as "stacks"

I'm sure there are many more things I'm not thinking off the top of my head that are variables that need to be defined and nailed down. You took a great stab at defining some of those things in your notes Thanks!

And above all, I'm not quite sure what an ornamental lathe really is or should be in terms of the motion-control/CNC/G-Code world, but I have spent way too much time thinking about it. In my thinking about the problem I have been inclined to define an OT lathe more as a CNC vertical mill, with a horizontally mounted 4th axis. I say this because for the most part the tooling on the OT lathes is spinning on (or near) a vertical axis, like a VMC's spindle, but typically being presented on the side or end of the workpiece (rather than the top as a mill/VMC typically does), with the workpiece acting like it is held in a 4th-axis rotating about (lathe) Z, aka the C-axis. Obviously a jumble of the things you already set out to define in your notes.

Except for the presentation of a router bit from the top, I often think about the coordinate system like I imagine the Legacy Ornamental Mills use, with their 4th (and manual 5th) axis ( It seems like the extension of the cutter (HCF) being able to cut on the side of the cylinder, as well as the top, sorts out a lot of the geometry issues/questions. But that's just my thinking about it. I imagine "clones" of the Legacy Mills being built out of 80/20 as DIY platforms for OT "machines." Alternatively, I often wonder if people would retrofit a Grizzly-type "combo" lathe/mill if the coordinate system and software allowed for it? E.g. this form factor:

Others, like Dewey Garrett have taken a completely different approach to the coordinate/tool systems. In case you're not familiar with Dewey's fantastic (EMC) setup, look here:

Anyway, without trying to solve all the problems here, can I suggest that those of us interested in this topic meet after the end of the Friday evening SIG in St. Paul? We can adjourn to another location (hotel lobby?) if we need to, as they'll likely kick us out of the room to lock up at the end of the SIN.

Does that sound interesting/workable to others here?

Re: Second SIN after SIN?

Hi Jon,

Both Mike and I would be willing to meet at any time and any place to talk about this stuff.

The first SIN ends at 9, so sounds like the second one would probably go late. I'm coming from eastern time, so it will feel an hour later to me than local time. So I may be dragging a bit, but I'll do whatever it takes!

Thanks Jon for bringing this up! Since I'm still very new to this AAW stuff (been a member for about 4 days now), I'm going to have to rely on you to get the word out on this. I hope that you have some time to do that. But whatever you set, whenever you set it up, count Mike and I in!

Jon -- I like your idea of getting all the computer-oriented folks together. I'm open to the Friday after-SIN time (or any other convenient time).

Does anyone know if Dewey is coming? I'll send him an email and ask.
Re: CNC Fragmentation

I just wanted to do a quick post to try to show how my simulator fits with the 10 points that Jon mentions in his post. I think that this will provide a much better idea of what this software can do.

1) Platforms: PC, Mac, Linix users

Python (and, therefore, this software) runs on all of these platforms. There is no GUI yet, but I will definitely be looking at one that runs on all platforms. So it my full intention to support all platforms. (The only question would be if I ever get to displaying 3D graphics, don't know how that works from a multi-platform perspective).

2) Ports supported: Parallel vs. USB ports

Currently, this software generates G-Code, which is above this level. One nice thing about G-Code is that it's fairly standard. The software could also be adapted to driving a CNC machine in real-time to give the operator manual control over the process, but that hasn't been the direction I've taken so far. I would very much like to talk about these two different approaches (automatic operation, vs manual operation of CNC machines), as I am right at that decision point where I need to go with either Plan A or Plan B.

3) Languages: C, Python, Java, TCL, Perl, and Mike's use of NI's LabView

This distinction may or may not be important, depending on how much we need to be able to integrate different software projects. If each software project can be made to run as a stand-alone program, and the interfaces between the projects is done by communicating between programs, then this becomes a moot point.

4) Controllers: Lots of Mach3/Gecko out there, some Flashcut, newer Open Hardware boards coming--all USB

This is currently at a lower level than this software is operating at. This would be at the level of a G-Code interpretor. I'm not sure which of these support the "direct drive" approach.

5) Coordinate system: Lathe, mill, live tooling?, orientation

At the heart of this system is a 3D coordinate system transformation engine. So this software can handle any coordinate system orientation on the CNC machine. It can translate to 3, 4, 5 (or even 6, but can't imagine what this would buy you) axis machines with any coordinate system orientation (though the fewer the axes, the more you'll run into limitations just based on what the CNC machine is capable of). I believe it will also handle left-handed coordinate systems (though this hasn't been tested). It's very easy to set up a new machine.

The coordinate system of the virtual OT lathe can be completely different than the CNC coordinate system. The software will automatically translate. You get this for free!

The vase was cut with a different coordinate system orientation between the virtual OT machine and the actual CNC machine. I didn't have to worry about this, except when specifying the rapid movements (G0 commands). The way that is currently done is a hack that needs more thought.

6) Source input: CAM-like UI, G-Code editor, Solids files, SVG artwork?

I envision eventually having a simple GUI that will let you configure the virtual OT lathe by specifying a set of virtual OT components and their associated parameter settings (e.g., eccentricity settings, nosewheel index settings, etc).

I also have an svg2csv program so that you can use your favorite draw program to draw templates, e.g., for the curvilinear apparatus or rosettes for the rose engine, and then import them into this program.

7) Output: G-Code, visualization/graphing files, direct machine control?

This is where I'd like to see a lot of discussion. I'm exactly at the right point in time in the development process to be influenced on these type of decisions. I am very interested in avoided having to program 3D graphics and am eager to find out how other people have done this and whether I can use their code, or other 3D rendering programs out there rather than having to write my own. I have very little personal interest in this sort of thing, so don't keep up with whats available out there. If somebody else could pick up the ball on 3D graphics for this project, that would be awesome!

8 ) Tools: Support for and definition of "tools" which are unlike existing industry tools (HCF, VCF, UCF, drill frame, Ecc. cutting frame, Ell. cutting frame, Epicycloidal cutting frame, etc., etc.).

One of the interesting fall-outs of this coordinate transformation technique is that I can take any ornamental lathe setup and convert it into a cutting frame. This is done with one standard "chuck_to_cutting_frame" component that is fully general. This gives me some of the standard CFs for free. For example, it can convert an elliptical chuck into an elliptical CF, an N-stage geo chuck into a epicycloidal CF. But it can also convert, say, a rose engine into a CF, or a dome chuck into a CF, etc, etc.

But, other than these "mirrored" CFs, I think that the OT tools are the most difficult things to simulate. So I'd say that the "ideal" CNC machine would accept standard OT tools. In fact, from where I sit right now, the OT tools are much more flexible than standard CNC or router tools. With this software, you don't need any of the physical OT chucks, any of the apparatuses (spiral, curvilinear, reciprocator, etc), even the slide rest and the whole lathe itself (including the rose engines). None of that stuff scares me in the least. But those OT tools are going to be what bites me in the butt. Hang on to those OT tools!

9) Chuck/Workpiece orientation: Ecc. chuck, Spiral chuck, Oblique chuck, Dome chuck, Epicycloidal chuck, Geo chuck, etc., etc.

This is all handled auto-magically. I can define any of these chucks in about 5-15 lines of code (ignoring boilerplate that is just copied from somewhere else) and they will fully function in any combination with any of the other chucks or components. It really is magical! I wish I could say that I invented the underlying technique, but it's just standard 3D coordinate system transformation math that I got off of wikipedia. So we have the mathematicians to thank for this!

10) "Stacks": The combinatorials of tools and chucks above which you defined as "stacks"

This is the thing that most fascinates me about OT. This is just like what we software types call "object oriented programming". It's a very powerful technique that the software crowd "invented" about 30-40 years ago and has been the single most influential leap in software technology since the first programming languages were developed in the 50's and 60's.

... except that the OT guys were doing this same thing mechanically 100+ years before we were! Amazing!

I hope that this provides some better insight into what my software can and can't do.

I'm very much looking forward to talking about this, both at the symposium and on this forum.

I've been thinking about setting up a google group for discussions about this software, but haven't gotten to it yet. This might make it a little easier for people to participate?

Yes Dewey is coming, and hopefully will be available for the time we pick. He said he thought he had a conflict during the regular SIN time, but should be free by the time it ends.

SIN meeting

Bruce and Others -- I'm glad you replied and walked through my not-necessarily-thought-through points. My sense was you were right at the crux for a lot of those discussions and decisions.

I read through all your code last night and now have a much better idea of what you were trying to accomplish, and what is/isn't in there so far. I do have to compliment your commenting which makes a lot of it readable, especially where you've taken the time to write out the math you're using, including sources.

I think the fortuitous part of this could be that various people have taken stabs at various parts of the problem, and, if we can collectively start defining some things, maybe the disparate parts can "play well together."

-- Bill Ooms has done a lot of work on the 3D graphics front, mainly using Java3D, but currently controls a non-g-code hw architecture (although I think Bill said he was playing with a new controller and learning g-code as we speak, right Bill?)

-- Dewey has adapted a very complete system using EMC2, TCL and a lot of Open Source components/apps to accomplish what is mainly an artwork-to-surface mapping solution (that's grossly understated, but for purposes of the discussions he typically probes a pre-turned surface and applies decorations mapped onto that surface).

-- Randy Rhine (who won't be there) has written a very complete g-code geometric chuck simulation using .NET that feeds Mach3 and his DIY 3-axis CNC router.

-- Mike Brooks has written (as you know) an infinite-stage geometric chuck simulator using National Instrument's LabView, but as far as I know is just a graphical simulation with no target output.

-- Others, myself included, have been thinking about and discussing the problem with various individuals, mainly one-on-one, but with no formal group to date. I am sure there are lots of others doing things I'm not aware of too.

I'm trying to draw up some sort of "block diagram" in preparation to make a discussion easier. There are so many layers to this problem that we'll need something to help us navigate the pieces of the overall architecture, and if we want to define anything as a project.

1) Yep. That's why your open-source approach was appealing.

2) That's why I think we need some overall architectural diagram to work with. If we can say that anyone who has a Mach3 or EMC2 system can use this, that opens the doors for a lot of people.

3) Ditto #1, but we would want/need to define the projects/interfaces/APIs.

4) Ditto #2. Some defined target hw or systems will allow this to be used on more systems, and evolve. As you already did for your specific use (Tormach 1100), we'll need to review supported g-codes, if that's the way this goes.

5) I saw all your transformation code/projects and that is the way it should work underneath the UI, whatever that ends up being. I started trying to read about "Mill/Turn" or "Mill-Turn" coordinate systems last night. Since that class of machine generally does what we're trying to do (but usually in 6-axes), it may make sense to study/adopt their system for coordinates to hopefully avoid the confusions (and crashes) associated with rotations about one or the other axis.

6) I think this is a big part of the discussion, but it does seem a simple UI could be devised to allow connecting various pieces of a "stack" and then opening the devices in a stack to set parameters would make sense. I did see your svg2csv project (is that the right Python term? Program? Module?). I think the over-arching question is the whole user model? is this a semi-traditional CAD/CAM approach; draw, process, then feed? Or is it more of a surface decoration approach where artwork or multiple cuts are mapped onto a surface that has been pre-defined some other way (or in a previous step)? And as I thought more about it last night, the question kinda comes down to, are there multiple passes for roughing and finishing, including a notion of tool changes, roughing tools and finishing tools?

7) As I mentioned above, Bill has done a lot of work in developing the 3D side in his sw (, but I cannot speak for his willingness to share or participate in this kind of open source effort. Bill?

8) Don't forget the Victorians did create the ever-popular Rose Cutting Frame. :) Seriously though, the simulation of the tools onto the surface is what Bill's sw really illustrates for the user doing design work. But your work taps into more transformations and combinatorials. Dewey's system also works by cascading multiple modules and transformations, in what I would describe as more of a DSP-model. All this suggests a huge benefit if we can marry the projects somehow. And you've hit the nail on the head for *why* I want to see this all happen--the OT cutting frames. The surfaces, textures, profiled cutters and everything else are why I have been slowly moving towards building a CNC router adapted for traditional OT cutting frames.

9) Isn't sharing wonderful? There is nothing better than things that just work magically.

10) I've been an OOP enthusiast since the early days, and for this type of approach it really demonstrates its value, and powerful attributes (assuming you can abstract everything). And my admiration for the Victorians who did it mechanically goes without saying.

I'd suggest we try to get together as a group in person, rough out some of the ideas, goals and architectural blocks/divisions, before we post it to the world on a Google, Yahoo, or Open Source-type forum. I think reading through EMC's architecture (with its HAL and PLC's) might help lay some foundation for the discussion. And reading more about Mill/Turn machines and their coordinates may be useful as well.

So, at a bare minimum, let's all plan to gather at the end of the OT SIN meeting, and decide how long we can talk, and/or if we can find other workable times while we're all at the symposium.

I think this is very exciting!

All --

Yes, I have my 2nd stage pretty much up and running. It has a stage that moves 8" x 8", uses a Gecko 540 driver, and runs from g-code using EMC and Linux.

I've also modified my software to output g-code to a file, then load the file into EMC and run it pretty much in batch mode. There are a lot of little subtleties with g-code that I didn't expect. The two major challenges so far are how to handle the wrap-around of the spindle (i.e. when you get to 360 degrees you are really at zero again), and the peculiar behavior when you give EMC a new coordinate that only changes the c-axis (that it, the change in the x or z dimension is smaller than the resolution of your steppers and results in no movement in x or z). When an instruction only moves the c-axis, EMC interprets the feed rate as degrees/minute rather than inches/minute (very slow).

This has been a good learning exercise for me to speak more intelligently about g-code vs. direct control.

Looking forward to the discussion.

Bill -- Congratulations!! Now the questions... How are you talking to the 540? Did you switch to a PC for Ubuntu/Linux and a parallel port, or have you found some magic USB solution that works from the trusty Mac Mini with EMC???

Enquiring minds...