Update on my computerized ornamental lathe activity

#1
Update on my computerized ornamental lathe activity (or, here's some land mines to watch out for).

I've pulled the plug on my old system that I've used for over 2 years (with the Phidgets boards and real-time control) and re-built it to run from EMC2 with a g-code interface between my visualization software and EMC.

This change was driven by the quest for ever better quality of cuts -- particularly on spirals. I concluded that going forward I needed:
* Coordinated motion between the XZC stages. This was not possible with the Phidgets drivers.
* Finer resolution -- I needed to go to a driver with finer micro-stepping. The vast majority of these use a step-direction interface. My first choice was a Gecko G540 driver with 10X micro-stepping (but there are other problems with this board as mentioned below).
* Trajectory planning for smooth continuous motion and controlled acceleration/deceleration during the motion on all axes.

At present, these needs can be met with EMC2 (free, runs on Linux) or Mach3 ($175 on Windows). Free is good, so I'm using EMC2 for now (although I have a demo version of Mach3 up and running for comparison). This means adding an old PC in the shop with the old parallel port (required by both programs). Eventually, we may see some small Arduino-style boards that hopefully will replace the need for a PC with parallel port.

I've been running tests the last few days, and I'm very happy with the improved cut quality -- especially when running spirals.

However, there are a lot of land mines with the use of g-code. It's made for a regular CNC lathe/milling machine. Having a stepper motor driving the spindle on an ornamental lathe (C-axis) was never anticipated by the g-code crowd:
* If you keep rotating the C-axis the same direction, you eventually run into a limit.
* You can't actually set the C-axis back to zero with g-codes (or simple manual intervention) -- you only add an offset which keeps growing over time.
* Both programs have the option of specifying a "wrapped" rotary axis, but they behave differently. You can't run the same g-code on the two programs with "wrapped" rotary axis and get the same result.
* EMC2 limits the amount you can rotate (when using "wrapped" rotary axis) to something strictly less than 360 degrees. This makes it un-useable for some things we like to do (like cutting threads, following a profile, etc).

If you're interested in the details, email me via private email and I can elaborate with simple examples run on both programs. The bottom line is that you can write g-code for EMC2 or write it for Mach3 (or eventually for some other smart circuit board), but there is no such thing as "standard g-code" behavior with rotary axes that will work with multiple targets.

The other major land mine was a "feature" on most of the Gecko drivers -- auto standby current (70% current reduction). After 2 seconds of no motion, the holding current to the stepper is reduced. The problem is, that causes a "twitch" which can be seen in your work. Discussion with a Gecko representative yesterday said that reducing the current down to the 30% point probably causes the loss of the micro-step position (i.e. it snaps to the nearest full step). For example, say you're following a rosette pattern with regular rocking motion. The z-axis moves to the depth you want and you start cutting as you follow the rosette pattern. 2 seconds later your z-axis twitches. This "feature" cannot be disabled. I'll be looking for a different brand of driver soon.

My current thinking is that I'll stick with EMC2 a while longer and live with its limitations. Longer term, I may change over to Mach3 just to get a better implementation of a "wrapped" rotary axis (although there may be some new land mines there too). What I really would like to see is the introduction of some small Arduino-style board that supports rotary axes and good trajectory planning. This would permit the use of a USB interface and eliminate the need for an old PC with a parallel port. Hopefully, there would be "hooks" into it so that eventually I can go back to real-time control (rather than batch operation).
 
#2
Thanks for sharing, Bill. That's a huge amount of work thats both fascinating and mildly entertaining :)

One of my lathes is a full Fanuc CNC device that does C-axis cylindrical and polar interpolation. I've played with it a bit and discovered that the possibilities are endless. Just because of what it is I will not call it an ornamental lathe. Anyway, I can get up to my ears in the Gcode to make it do what I want and I've been successful in programming some general macros that are parameter driven to vary the patterns I get, say, on a cylinder. My plan is to use a live spindle as a cutting tool (non-belt-drive cutting frame :wink: ) to engrave patterns under C-axis control and then use a rose or straight line engine to fill in as I need.

Attached picture illustrates the intent - this was a trial with mistakes added for completeness. This was done on brass using a hand guided Deckel GK21 pantograph hence the tool marks in the bigger grooves. But this is almost under a microscope so one might not ever notice that. The result with a full up CNC process for the big grooves with a high speed live spindle is much better. The picture on the blue mat is after cutting all the ornamental grooves on the pantograph. The internal guilloch? applied later was done on a 1916 Lienhard rose engine.

Cheers,
Rich



:wink:
 
#3
Bill,

I run Mach 3 on both my lathe and mill. I tried EMC years ago and didn't like it (although I understand it has matured quite a bit since then). You might want to hold off on the Mach 3 purchase if you decide to go down that road. There is a complete re-write coming, and I suspect it will be a paid upgrade. Not sure on timeframe of the new version though.
 
#4
Thanks for the note about the up-coming Mach3 thing.

Rich -- Keep us informed as your work progresses. The c-axis control issue is really important for all of us. My biggest concern is that different programs/machines interpret g-code differently in spite of the existing standards. Since my original posting, I've been informed that EMC2 people made a conscious decision to depart from the standards for a variety of reasons. I'm not sure if others have done the same or not.
 
Top