NC Controller difference

[BobWarfield]

Originally Posted by fkaCarel So the easy solution is: buy the fastest PC you can get. The number in the delay loop grows, the overhead is executed faster. This is noise reduction by numbers. The costly solution is: buy a Fanuc and have a specialised controller. The crazy solution is: do it yourself and invent new G-codes and new approaches.

The explanation about timing loops was directionally correct, but pretty far from reality. I don't know that I would add that to the cheat sheet as is. Likewise NC, it isn't exactly true that the moment your drive lags it stops while the Gecko system is somehow inferior because it doesn't communicate until enough error occurs. Both systems have feedback loops by their nature. There is always some amount of following error there in a closed loop system as it struggles to keep sync'd with the encoders. Both systems have a threshold beyond which they fault, and that threshold has to be greater than 0 or the feedback process can't happen.

Gecko has chosen a value of 128 steps at which to fault on the controller. Is this a bad value? Too large? Kind of depends on what a "step" is? In this case, it is encoder counts, which by virtue of quadrature means 1000 per revolution for a typical "low res" 256 step encoder. So 1/1000th of a servo resolution, translated through whatever drive reduction (2:1 or 3:1 = 2000 to 3000 per revolution), translated through whatever your leadscrew offers.

Put all of this together as 1000 resolution per rev * 3:1 reduction * 5 TPI and you are looking at 128 * 1/15000 of an inch = 8.5 thousandths. Now that is for a fault, and in a lot of systems you are done once you faulted, meaning you can't just restart from that point. At the least you probably need to rehome the system because it may have lost track of where it is. You therefore don't want to fault at the drop of a hat by setting that tolerance too low. It is pretty routine for things to get back on track as the servos catch up again. Some systems even let you set a time parameter for how long the following error can exceed the maximum before you get a fault.

I would be curious to know what that threshold is for the Fanucs and such. We might find it is not so different. EMC uses a default of 0.010", which is actually a greater error than is built onto the Gecko boards in this example. I Googled for a bit and found a Grundig CNC paper on MMSOnline that used the same value, so maybe that is conventional wisdom.

The Heidenhain guys have a fascinating account of how "closed loop" isn't really closed loop unless you measure how far the axis really moved using linear scales as opposed to whether the servo "lost steps":

http://www.heidenhain.com/wcmsmimefi...3_20_15180.pdf

The figures they give about how much error temperature related effects cause along these lines are pretty interesting, so they have a point too in this endless religious debate. They are just simply a little more rarified sect.

But we digress!

It is the conclusion that counts:

- Buy a faster PC. Yup. I see guys over on the Mach board wondering why a 333 MHz machine is struggling. Get a real PC, 1 GHz or so. They're cheap. Much cheaper than dedicated controls. Watching the video offered by Ger21 it would be hard to conclude that the description of the difference between a Windows based system and an embedded controller was as simple as what was presented (it isn't!).

- Use Servos with Gecko drivers, they will fault just like the big guys if steps are lost. While the faulting parameter is not tunable, it is also not bad as a default. Running Mach with Geckos is pretty darned easy, there is tons of free support on these boards, and it has been done successfully by many folks. There are also commercial OEMs that use this technology as well as OEMs like Tormach that are happy enough with steppers.

- Failing that, look at running encoders with steppers if you need to catch the lost steps. That also works just fine. Rogers Machine will sell you a card and the Mach 3 bits needed to make that work for you.

- Look at the GRex. It is immature at present, but offers a host of advantages. In particular, it runs the nasty timing loop portion that we seem to feel is a problem for Windows on an embedded microprocessor. The performance being seen with it is apparently astounding. It comes with encoder inputs for all axes. Slightly longer term Mach will be enabled to work full closed loop with it.

- If you don't want a project, buy someone's turnkey conversion kit. I read about just about as many headaches with those and much greater costs as I do with Mach, however. So beware, you may have a project there as well.

- If you really don't want a project, buy a brand new turnkey CNC machine from Haas or someone similar.

BTW, in all of this minutiae, we have overlooked some of the most important differentiators of the industrial grade CNC stuff:

- It is typically set up by an experienced OEM for a particular machine combination more often than a one off or conversion. They have gotten the bugs out (hopefully) before you get your hands on the machine.

- It is carefully tuned for that combination of machine, motors, drivers, and control.

- The software may be highly optimized for the machine.

- The front panel and conversational modes may be a lot more advanced than one finds with Mach 3. It's quite a bit of effort to build a nice control panel for Mach 3. It's been done and is very doable, but you start to move out to a more rarified atmosphere.

- There are some pretty nifty very high end features available in controls like Fanuc that are not yet there for Mach 3. For example, there is an option to directly interpret NURBs instead of approximating them with line and arc segments. Other much talked about options are look ahead and interpolation. These are mechanisms to smooth the roughness of those line and arc segments, and to look ahead at what is coming so that if the axis has to change direction too suddenly, it is planned for and the following error isn't too great. The machine may have to accelerate/decelerate before it finishes the current block of G-Code in order to meet the needs of the next block in these scenarios. The Grundig article I mentioned earlier talks about some of this (http://www.mmsonline.com/articles/059604.html). If you are buildling $2000 titanium + carbon fiber toilet seats for the Pentagon's stealth bomber (can't have a radar signature on your toilet seats!), this stuff is important!

With all that said, Art is making huge strides with Mach. His new plug-in architecture is going to open it up to a lot more contributors, and progress should accelerate from there. He says he has 5400 users. His stuff runs on the world's most popular computer and OS architecture. History in the computer industry has shown that this stuff will generally win out over the proprietary approaches, and it won't take all that long to do so.

Heard anything from DEC or Cray Research lately?

Cheers,

BW

[NC Cams]

The problem is that many folks, including myself, don't REALLY understand what is going on between any number of key strokes we make and the piece of paper that is printed because of what we typed.

If one takes the attitude (which I did) that the computer only counts 1's and 0's, it should EASILY be able to repeatably cut a circle cuz it does so real fast and accurately.

Assuming that this assumption was correct, I spent weeks eliminating the mechanical gremlins that I thought were causing mine NOT to do it. Even then, the darn thing would put flats at the turn around points an the 0,0 point would wander off by 0.005" or so at the end.

The guy who knew the electronics and servo tuning tricks came and showed me that there is "magic" in obtaining the proper "tune" for the servos. There is also a real challenge in learning what the idiosyncracies are in your PC which have to be addressed in order to get it to process data as WE want, HOW we want.

Recall that PC's were adapted TO use in CNC retrofits, they were made to DO other stuff (flight simulation, word processing, play DVD's, you know the REAL stuff PC's are used for). Big difference

I'd contend that the guys at Mach would have a far easier time if their system were ported to a dedicated machine with known interrupt tendencies and/or whatever other gremlins they surely have to deal with that the folks in Redmond hid in XP and it's derivatives. These were only made tougher by the hundreds of ways PC m/b chipsets process the data and in what order.

Imagine literally plugging and playing with a dedicated PC that doesn't do flakey stuff - or differenly in this box versus that. The cost of the PC might double or tripple but think of the performance you could get by not have to worry about the microprocessor deciding it was time to refile the e-mail (which it was holding open for god knows what reason), or go into battery conserve mode because the battery just dropped 1 milivolt below the conserve battery threshhold mode.

Aaaah, the what could be's. In the mean time, compromises are made and the REALITIES of CNC become public knowledge via life's experiences.

The neighbor's Haas cuts my cam profile masters is less than 15 m minutes. My BPT Eztrak consumes nearly 3 hours running EXACTLY the same number of lines of code. The dedicated CNC does a better and more efficient job of crunching the numbers it is supposed to crunch.

The PC based control in our Eztrak has to be run slowly so it doesn't hurk/jerk around. It's comparatively older and compromised PC based controller simply needs more time to crunch the exact same G code numbers.

Via trial and error we found that slowing down the process and some other tune parameters, resulted in dazzling accuracy out of a machine that shouldn't perform that good - even my BPT trained tech said so... But to do it, you have to time it with a calendar as opposed to an egg timer.

When we oversimplify the actions of the PC into only counting 1's and 0's real fast, it is easy to lose sight of what it really takes for the myriad of different electro/mechanical components to synergistially come together to mill a simple circle.

Them little electrons are flowing around pretty fast and, I contend, some of them fall off of the board traces and get lost. People claim it is "lost steps" but I know better.

Found a bunch of them had collected themselves and migrated to the coolness of the refridgerator. Seems they had found a way to keep the light on when we closed the door and they were partying until the wee hours over the weekend. Does anyone know what the gestation period of electrons is? I suspect some of mine surely got "lucky".

I don't feel it is the software vendor is to blame that the software does funky stuff on some of the infinite blend of PC's and ancillary hardware that's out there. I'd challenge the user's group to poll the user base and find out which group/brands of components gave the least amount of trouble all things considered.

Those should then be the "baseline" system to recommend. Sadly, the way the industry is, it will be obolete in 3 months and you'll have to start all over.

ANyway if this were done, I"d be a lot of wheel spinning and/or reinventing would not be needed in trouble shooting a bad synergy of PC's "finest offerings" (ergo right tool, wrong job).

Maybe its time to develop DIY controls on/for a PC104 based standard system. At least they still offer simple stuff as old as industrial 486's, Pentiums and other "obolete but adequate" processors.

A bit more pricey but at least the stuff was designed for industrial use and they don't have some of the ginger bread you probably don't need in a machine controller - like a Tomb Raider graphics card or DVD player for your Jennifer Tilly (talk about HOT) sampled movie clips. Important things, granted but not out on the shop floor.

[BobWarfield]

NC, there's a TON of differences between your neighbor's Haas and your EZTrak. I have a hard time believing it all boils down to just swapping the Haas dedicated controller in place of your EZTrak's PC! I don't know that you were even suggesting that.

The PC does a fine job, and is much more maligned than it really should be. It is too often the excuse and crutch when as you have pointed out there are a tremendous number of other factors that have nothing to do with the PC. PC's have also gotten many orders of magnitude faster since the days of EZTrack, and that makes a huge difference. I've used Unix, Linux, and Macs, and despite all the protestations that Windows crashes more, it's bunk. I make my living building large scale Unix software today, and made it in the past writing Windows desktop software like the spreadsheet Quattro Pro.

Perhaps their greatest Achilles heel of the PC has been the use of parallel ports as a suitable real time control interface. Truly that has been a kludge, and particularly difficult to make work well under Windows. Yet, as the machines have grown faster and Mach has evolved, it has reached a stage of working pretty well.

The next iteration in that evolution is at hand, and it totally changes the equation in a way that favors the PC tremendously. I'm talking about the GRex and similar devices that offload the innermost (and most finicky) processes to exactly the dedicated controller that you are lusting after. Yet they leave a PC firmly in control, so you keep all of the advantages of low cost, graphical user interface, and plethora of programs available there. This is really a cool innovation NC, and one I think you would find fascinating if you ever had a desire to play with it. The parallel port issue is eliminated--GRex and similar boxes communicate using either USB or LAN at much higher speeds and without the limitations. The timing issues are eliminated as well because GRex receives very high level instructions similar to G-Codes and it has a bunch of them. If the PC hiccups for a brief while the G-Rex can carry on without it during that time. The PC gets to do what it does well and the G-Rex handles the rest. This all happens at a very low incremental cost--a GRex is about $300. Some of the other USB boxes will be even cheaper. Both Art and Mariss have expressed great surprise at the improved performance on stepper based systems this provides. I mention steppers not because its a stepper centric system, but because they showed cases where steppers were performing at speeds that used to require servos in the pre-GRex days.

I paid for my college degree consulting for Cad/Cam companies of the day. At that time Intergraph and Computervision were the Kings. They ran on proprietary hardware, and they were proud of it, and felt nobody would ever produce a product as good without that proprietary recipe. I did most of my consulting for a whole host of little firms that were writing CAD/CAM programs to run on desktop workstations. Today it would be hard to argue that the desktop machines hadn't pretty much wiped out all the proprietary players. The same is unfolding at the CNC machine level, and it is fascinating to watch and be a part of. It happened in the same way I've talked about with GRex. They took the finicky parts off of the PC's plate and moved them out to a dedicated controller--what you have referred to as a Tomb Raider graphics card. BTW, they do have a place on the shop floor if you fancy toolpath simulation at all. Today, graphic controllers actually have more transistors and are in many ways more powerful than the PC's cpu itself, yet they are cheap enough to be used for games. They have powerful vector instruction sets just like the Cray computers of my college days that were being used to design atomic weapons. They're scary powerful!

This trend has happened many times in the computer industry, and is inescapable for CNC too. Resistance is futile--when your EZTrak finally cannot be repaired further, you'll have to decide whether to embrace the newness, or join the gang on HSM talking about how great those old Southbend lathes are and why nobody really needs CNC anyway! LOL, just teasing! But I'll bet you would enjoy learning more about this GRex phenomenon and Mach if you'd give it a chance.

Cheers,

BW

[NC Cams]

BobWarfield: the point about the Haas vs Eztrak wasn't made clear enough by me.

Point is this: the code that both machines use is IDENTICAL (point to point G code milling).

We found that the Trak can hog the metal away but at high speeds, the feedback isn't quite as good as that which is in the Haas. The error was stacking up to be greater.

Dunno why, but the Trak (running on a ISA PLC card in a DOS 133 Pentium box) can only process data so fast and tends to deviate more (error) if you try to push it. So it's several masters in 1 hour on the Haas or 1 in 2.5 to 3 with the Trak with EXACT SAME G Code. The thru put on the dedicated CNC is far superior than that of the 10 year old PC based technology.

If a PLC based "professional" machine (Trak) with true servo direct F/B has issues running fast and keeping up, how can you expect a device that is running (brilliantly and amazingly well) thru a parallel port to provide comparable performance???

I understand what you're saying although it may not quite show. I'm also glad you're explaining it to all of us. It really puts this PC based CNC thing into a better perspective. This post will be put into my "cheat sheet" for future reference when the well intended but ill concieved "we can hook any old computer up to it" comment gets made in the future.

Simple case of right tool for right job and every tool has its limitations and wishing won't make it so.

[NC Cams]

BW: I"m in the odd position of NEEDING CNC based tools but unable to afford the Haas version that I should be using. As such, I have to rely on "legacy" hard/software to keep my retirement project/business affloat until the 'end' or until the lotto deal rewards me - maybe I ought to start buying tickets.

I"d jump to a Mach in a heartbeat BUT when I contacted them direclty about being able to interface with servos, they said it couldn't be done. They said, "you'll have to write code" which immediately rules it out - I'm not in a postition where I have the where with all to learn how to write code. Amazingly, I learned on this site that Mach could run with servo's but the decision process has moved on since.

I have no doubts that the 'Trak's lame yesteryear technology has already been eclipsed with newer technology. Yet, this 10 year old system does stuff in such an easy to use, well founded, brainless fashion, it simply amazes me. Even the neighbor with the Haas and the BPT guy who came in to tune it sat there in astonished awe watching it do what (as one guy admitted) he'd only seen a Haas tool room mill do. And we were told it couldn't be done....

Sorry to digress...

Some of us are looking for MANAGEABLE "heathkit" (actually component stereo) like projects to do CNC retrofitting on/for/with.

We're not code writers nor are we all ME's or EE's or even college educated at all although some of us purport to be. Some of us simply long for the day when Grex will be ready to assemble into a psuedo plug together control system. Just don't get super side tracked - don't let mission creep set in. Hard point the features list, leave room for growth/development and get something that works.

IT would be neat to fire up a system where a nice screen is IN THERE already and not something you have to write VB or whatever with to make it go. No time to do, license one that's already written by a Mach user. If it is SO easy to do, provide it with the system as a default boot screen for lathe or mill and you immediately have a more user friendly device - don't like what you see, go (enter manual page here for DIY modification instructions).

As much as I hate Windows, it did something good for society. It gave almost anyone the ability who could turn on a PC simply boot it up and start doing productive stuff. When you quit having to self program a computer and bought functioning software, the sales exploded. I dare say, that a lot of small shops out there are in exactly the same position as I, more or less. Need it, wan't it, don't have the time or skill to do it ALL ourselves....

If you can turn on the stereo and listen to and enjoy fine music WITHOUT having to LEARN music, why should you have to learn to do all sorts of fancy programming to make a so-called mill or lather retrofit "kit" work???? Kit, hardly. DUH.

A DIY kit doesn't have to be an entirely DIY KIT - I don't think some of us are looking to resurrect Heathkit but something more like the "component days" of stereo creation might do wonders. Gee, do you think Centroid maybe got started doing things just that way???

As bad as Gates and Co are, they knew how to make a product good enought to get the world, even folks who only know how to turn a PC on, hooked into relying upon it to be productive.

I hope this makes sense. Oh so much more can be done by those of us who NEED what the Mach can do but WANT NOT to have to do some of the stuff needed to do to make it go in their application.

Maybe Grex is the salvation. Maybe something else is. Time will tell. Got to go get some of my lame a$$ yesteryear technology interfaced and operational so I can pay more taxes next year and cover luxuries like gas, food and rent.

[fkaCarel]

The explanation about timing loops was directionally correct, but pretty far from reality

Perhaps their greatest Achilles heel of the PC has been the use of parallel ports as a suitable real time control interface. Truly that has been a kludge, and particularly difficult to make work well under Windows. Yet, as the machines have grown faster and Mach has evolved, it has reached a stage of working pretty well.

I stated not to be able to look in the software, so it was my estimated analysis. So what is the reality?

- Look at the GRex. It is immature at present, but offers a host of advantages. In particular, it runs the nasty timing loop portion that we seem to feel is a problem for Windows on an embedded microprocessor.

I think the "embedded" has crept in, but it confirms my opinion. The function of the GRex is just to time and buffer, lets call it a buttonless, invisible and limited embedded controller. It redifines commands. It's sales pitch is to make interrupted data streams continuous. Reading the comment of NC an effort to make a high resolution continuous circular interpolation data stream would be welcomed. These kinds of internal resolutions need also to be a part of a discussion, if they obvious need to be refined.

Watching the video offered by Ger21

A video is 30-50 frames per second. How you can use a video to disprove time domain differences which are at least under 1/25000 sec is a mystery to me. This is just slow oscilloscope domain.

And then in general: servo's call for a dedicated servo-controller. The higher the encoder count, the better the PID function works. So if the maximum output of a PC is 50000 pulse/second then the max rev/min of a servo with an 1000 encoder count in quad mode is: 50000 / 4000 * 60 = 750 rev / min. This speed limit already exists. I would'nt trade speed vs hold or vs resolution.

A tighter integration with a dedicated processor eliminates all these data-pipelines. And, do not mistake me, I am not against the PC as data-generator and visiualiser. It's just the eternal question: what is the best solution for a given problem? From my point of view there is a little too much band-aid in the PC approach.

[NC Cams]

Here' the problem.

Joe DIY"er buys a Mach whatever. He's gona CNC his whatchamaycall it. He can't/won't do the math. Suddenly, something doesn't work and the 3000rpm motor spins the encoder at a date stream rate that is beyond the count ability of the stuff he's trying to interface. Someone will do the math and point it out but the customer will feel ripped off none the less.

My fear is that our Australian friend who's buying stuff of Ebay to retrofit his lathe inaother thread is setting himself up for just that sort of rude awakeningl. Plug and play assumptions that lead to keen eyes for what should be "obviously it won't work".

But if it were obvious, how come the customer didn't see it? DUH. So much for overestimating the intelligence and/or education level of the end useer. Yes, it is a cerebral hobby but stuf gets easily overlooked or OOPS'd..

Yes CNC is NOT plug and play - but the guy who makes it so will become inodinately wealthy. TRW did that in the automotive aftermarket and helped make the market viable by making their products fairly idiot proof -even though bigger idiots ultimately evolved to be dealt with but they were and the overall level of the product rose in the process.

DIY CNC vendors take heed. PLug and pray can become plug and play with a bit more development effort abd a higher performing product.

EDIT

At one point 133mhz was fast, now 1.5 gig PC's are passe.

1500 rpm lathe spindles were common, now 4K spindles are "So what?"

386 gave way to 486 to Pentium to Celeron to ?????

7000 rpm auto engines yesterday are 9k in Nascar versus 10k in NHRA Pro Stock today and 19k in F1. Tomorrow ?????

END EDIT
.

[fkaCarel]

At one point 133mhz was fast, now 1.5 gig PC's are passe. 1500 rpm lathe spindles were common, now 4K spindles are "So what?" 386 gave way to 486 to Pentium to Celeron to ????? 7000 rpm auto engines yesterday are 9k in Nascar versus 10k in NHRA Pro Stock today and 19k in F1. Tomorrow ?????

No. I worked on an 1978 Gildemeister lathe with a Fanuc control. It was a highly functional, speedy and powerfull lathe. It produced parts that passed Quality Control. There was no way to visiualise programs, you had to do it in your head.

It had a processor, designed in those days. Looking at this machine and comparing it with the PC related problems arising now, in 2006, and centering my attention on the seemingly biggest problem: threading, I only wonder where things went wrong. I have drawn my own conclusions.

Everybody who designs and builds its own machine is an integrator. You should know the problems you face or have the ability to master them. (the learning curve)
So I have no fear for the results nor pity for the people who starts these projects. This week I spoke with somebody who also induced the factor "luck" in his professional projects. I told him to wake up and not to include me in this.

And on a side note: I call "Plug and Pray" "Advanced Reset Technology"

[BobWarfield]

We are actually at the "Heathkit" level today, you just need to know where the beaten path is with Mach versus the "bleeding edge." I would say the Heathkit level of complexity boils down to the following recipe:

- You run the default screens that come with Mach. These are pretty nice, BTW. You can also add the Newfangled wizards, which are a fancy conversational mode. Again, pretty nice.

- You want to run it on a mill, or perhaps a router table. That's where it is most proven. Next after that would be a plasma table. Running distantly further out, because Art never quite keeps it as up to date would be the lathe functionality. I have heard it said it is very hard to retrofit a CNC lathe with Mach--not Heathkit! Simple lathe functionality can be done, however, and is probably Heathkit.

- Pick a pretty simple mill. NC's EazyTrak, a Tree 325, or some such. Not something with toolchangers, 29 axes, palette changers, pneumatic vises, and 5 different kinds of coolant.

- You want to run steppers. Yes, I know, servos are sexier and perform better. You can make servos work with Mach, many have, but steppers are closer to that "out of the box" Heathkit level. The trouble with the servos is there is more complexity to debug, plus you have to tune the servos yourself. Save that experience for your second CNC project. By then, it will be a Heathkit level experience to run servos. Incidentally, Mach doesn't care all that much. It sends steps to the servos too and let's the Geckos worry about the delta. If you are confident you can tune the servos, then go for it.

- Run Geckos with the steppers. Choose the 202, it is more idiot, excuse me, er Heathkit-builder proof in terms of not frying if connected wrong. The Vampire drive will be even more bulletproof shortly.

- Build a simple linear power supply, or you can buy one off the shelf. They're dead simple. You can get a toroid, a capacitor, and a little $29 rectifier board from Ajax that bolts atop the cap. Follow Al the Man's advice to properly phase the xformer, directions on this here CNCZone.

- If you need closed loop to avoid crashes and trashed work, buy the Rogers Machine encoder board and run encoders with your steppers. It's proven and he gives you the code to plug into Mach.

- Run ballscrews that someone else engineered. Either get an engineered conversion kit like the one for IH Mills (just an example), or buy a CNC machine with dead/obsolete controller and refit for Mach. Run 2 or 3:1 reduction on the screws. Yes I know, you can optimize it more, but this is what most people do, it is the proven track. Buying an engineered setup avoids all those nasty non-Heathkit discussions about angular contact bearings that get NC all fired up--LOL!

- Go for a dead simple control panel. Yes, it's great fun to have MPG's, rheostats, and as many buttons as that Haas panel, but it adds complexity. Use the PC screen. The buttons are on there. Get a touch screen if you want to get fancy. All you need is the power on and E-Stop. BTW, a real panel is only slightly beyond Heathkit. The main issue is the number of inputs you can run in a parallel port system. It is very limiting, and you wind up having to add ModIO or run 2 parallel boards. My judgement is that takes you out of Heathkit, because there aren't enough people who do it for it to be the beaten path. However, it can be done, and it doesn't require you to write code if you insist on a panel. This lack of inputs is part of why its hard to retrofit CNC lathes as well. Toolchangers and such need a lot of fancy footwork for Mach. Not Heathkit. BTW, a panel is a great follow on when you are fully satisfied with the Heathkit functionality and ready to venture to the next level.

- Get a 1GHz or better PC that is either a reputable brand like Dell, or is a reputable mobo you assemble like an ASUS. If in doubt, post on the Mach Yahoo Group to see if anyone else has that 'puter. If not, try again.

- Use a Campbell Designs parallel breakout board.

- Don't try to run rapids faster than 60 ipm. Probably 30 ipm is better and less likely to lose steps.

- Buy steppers that are a little too big. No harm done. May lose fewer steps.

- Run limit switches at each end of each axis. Use one end as Home as well.

- Variable spindle speed is probably near-Heathkit, you need an isolated board that will control your VFD. Set the speed manually until you get the rest working. Likewise, operate the coolant manually until you get the rest working.

That's it. That will work with a minimum of trouble. There are a ton of articles and posts with that configuration and plenty of people to help you make it work. If you want it all packaged like a Heathkit, consider something like the Industrial Hobbies CNC kit.

Now, if that sounds like it'll be too wimpy to be interesting, you owe it to yourself to just start reading the Yahoo groups for Mach and Gecko. There are not that many posts that it is hard to keep up, and you will learn a whole lot from it. The bar is rising for the Heathkit level. Art has done some major architectural surgery to the core of Mach to make it more extensible. The GRex is coming on line. Much higher performance. People are talking about 300 ipm instead of 60-100. Running out of parallel port pulse resolution is no longer a factor. Mach's new plug-in architecture is letting third parties package stuff. You'll be able to just buy an MPG pendant and plug it in and Mach will suddenly work with it. By end of year Art is talking about setup wizards to greatly simplify the initial startup.

It's all good.

Cheers!

BW

[NC Cams]

1978 lathe with Fanuc control - shades of Fanuc 5T.

If the observation is true, I have 3 (2 near new) of the beasts on my shop floor. Next time you're in the area, please stop in. We're working on a BTR so you could program externally and download the G code directly via the latest in legacy tecnology, DOS 6.22. If you walked into my shop, it would probably seem like a time warp.

In the field of auto racing where we're trying to carve a niche, "luck" is where opportunity and preparation coincide - you can only wait for the opportunity, you prepare for it weeks in advance.

Threading: this is the one function of "lathing" that i essentially fear. Lacking the sophisticated computer technology that the government uses in "fly by wire" aircraft, the CNC developers are really pushing the envelop trying to "cut by wire".

Here's my take on what's going on. Computers are not smart, the do simple things, very fast. In the auto industry, they count and time pulses so as to figure out when and for how long to inject fuel or induce spark.

In computer speed, these are fairly slow occurring event. 8 events in 2 revolutions (total), 1 event per cyl every other revolution. Dead slow simple stuff done repeatively yet accurately to minute fractions of a degree.

Even with stuff this simple, they have a hard time counting to 4. There are checks, resests, countercheks galore, just to count to 4 on a V-8. Speed??? say 6000 rpm max. Just count to 4, event after event after event.

Now lets cut a thread. I consider this a "rubbing you stomach and patting you head to the beat of music" sort of function. Why?

You have to start at exactly the same point, move along the z axis at a 100% (or reasonably close proximity) constant speed all while NOT moving in X axis. All while counting to 1024 and then doing it again next revolution.

IF a car has trouble counting to 4, think of the issues a lathe faces - literally a 2 bit task compared to a 10 bit task with consequences just as dire if done incorrectly if not more so.

In automobile speak, this CNC cut by wire thing would be akin to running the camshaft and ignition system (which is timed off the cam) without a mechanicla 2:1 timing belt, chain or gear drive. You couldn't get that project funded if you're life and career depended on it. Yet, it is an expected given for an NC/CNC lathe.

My guess is that some folks in CNC lost focus on the REAL goal when they let their imaginations run amock as compared to addressing the real object: automate the repetitive, tedius needs of the machinist.

Give me more, give it to me faster, let me do more things with the same machine. I think more "cool stuff" got added to the various systems because it helped market the machine, it didn't do much for actual machine function. Complexity in search of a need

Take tool pathing. IF the machine is all you got, tool pathing is a valuable addition. If you have a cad program, you could/should/would run the tool path off machine - it doesn't need to be a built in feature for each and every machine. Macro/subroutine/option yes, built in??? I don't feel so.

When a feature is added to the machine to "update" it with some glitzy "cool feature", does it REALLY do anything good for the machine's TRUE purpose in life, make good parts???

If the "feature" compromises the TRUE purpose, it's "puffery" as an old manager used to say - "we don't have the time or budget to waste on puffery".

The challenge I see it is to take what the 1978 Gildemeister did WELL with the Fanuc control (ala make good parts) and simply get a PC based controller to do that - nothing more - for STARTERS.

If you can do more, fine. But if it is at the expense of ANY of the prime feature capabilities that you need a lathe (turn, space, groove, threat, taper), you don't need it in the base product.

Yes, you don't want to visualize everything in your head (but think how good you had to be as a machininst/designer if you had to, though) to program the machine. That was a deficiency (was it??). But, if again, you have to compromise the prime functions to do drip feed or lan work to merely transfer programs (which can be a pita to do over long lines), you're misplacing your priorities.

Yes it is theoreticlaly faster to d/l a program via wire transfter. BUT considering all the overhead, error checking, etc that has to be developed to make it so, is it really so hard to use a CW-RWR disc or even a floppy to carry the program out to the machine?

I contend that in a small shop, simple is better. You simply don't need "cool stuff" mission creep to spoil the prime objective of what the machine is supposed to do.

A computer crash is a problem remedied by a reboot. A machine crash costs real money, breaks stuf and can hurt people. BIG DIFFERENCE. If your "cool feature" that got included in the features list of a CNC ever causes it to crash the main function objectives, delete the feature until you can make it totally benign to the prime program function.

Perhaps it is time to KISS some of the "puffery" and provide simple, productive machine controls, you know like they somehow did in 1978 but should be able to do it cheaper and faster with much better computers today.

When somebody figures that out, I have 3 Fanuc 5T's they can experiment on, 1 by one of course, the program has to work afterall.

[NC Cams]

BW: Not to belabor the Eztrak/Ezpath thingie but I've been doing a lot of research into the DX32 that ran these of late.

Why?

It was a fully functionaly BASIC control card that did pretty much what I want/need it to do and did so with a ISA plug in board in DOS 6.22 - in 1996.

Same BMDC interface card (with unique ROMS) running a lathe (all the functions I'll ever need), 4 axis VMC (plus spindle speed), 2.5 or 3 axis mill and/or 3 axis motion control on a surface grinder. Pretty nifty, huh??? In 1996. 10 years later, the system hasn't been duplicated at that level of simplicity for a PC.

Folks I've talked with who have Ezpaths wouldn't give them up for the world. I wouldn't give up my Trak either. It does what it does simply and reliably. It's an axis shy of a Haas tool room mill but a VMC 800/VMC1000 BMD control card and some software will EASILY remedy that - if only I could get access to the source code to port the Eztrak functions over to the VMC - life would be perfect. Oh what could have been....

Sorry to digress.

Sounds like, 10 years later, the Mach Grex is approaching the capabilities of what the DX32 system did in 1996. I wonder if it is a "brilliant minds work in parallel paths" sort of thing or "if one doesn't study history, one is doomed to repeat it" or it simply took that long to get Windows boxes capable of doing what ISA cards in DOS did easily. Someone will surely set me straight.

Sadly as you age, you "see" stuff that was ahead of it's time and appear jaded when today's stuff just now starts to do what was available over the counter 10 years ago - at a HUGE price, however. Was it that costly? NO but that's the price of advanced tecnology. Sadly, this simple system never got to be aftermarket viable. Too bad - it was almost perfect for DIY aftermarket use.

I dare say the stuff used in that old system is probably 1/10th the cost if it were sold today. Yet, for a lot of us, it would EASILY address our day to day needs in darn near plug and play fashion - asside from tuning but you could always hire a BPT service guy to do it. Try that with the DIY creation - buddy, you're on your own.

Maybe an update from analog drives but then again, they work so why bother??? Compared to what some guys go thru, doing a bolt together drive and spending a day to tune servos is far less time consuming than the gyrations we go thru today. Try gettin a 3.7v LPT port to work with a BOB/parallel interface that's looking for a 5v signal. Talk about frustrating!?!?!

Why don't I upgrade from DOS 6.22/Win3.11 on my cam design computer?? Simple the XP version does absolutely NOTHING better design wise. And "better graphics" simply isn't needed for the static graphing of a bunch of derivative curves. Ditto that for my other PC's with Win9x. They do what they do just fine and don't need XP for simple word processing or spreadsheeting.

Perhaps the Grex is what I"m longing for - a Y2.06 reincarnation of DX32 and BMDC. I'd be nice if it DID do servos, then it would be the bolt in i'm looking for to update my Fanuc 5T's. Think of Art's profit potential if he had a system that would service various Fanuc's. Instead of a few hundred in sales for each O/S he sold, he could be talking multiples of that in the Industrial market. Just a thought.

This has turned into an inordinatley GOOD thead that should be required reading for the noobie CNC'er. It explains a LOT of stuff that needs to be 'splained.

BW's post #21 is especially good at homing in on what the DIY CNC'er needs/should do. Thanks Bob, for the focused easy to read primer.

Until Grex is developed, maybe I'll be lucky enough to find some BMDC's in salvage someplace. I've gotten kinda good at resurrecting lame a$$ yesteryear technology (kind words from my ex-fiance). Perhaps the BMDC's are the "pound puppies" of machine controllers. They're neat and they do what they do with no glitz or glamor and I'd like to think that they appreciate not being relegated to land fill fodder....

[Al_The_Man]

Originally Posted by NC Cams Threading: this is the one function of "lathing" that i essentially fear. Lacking the sophisticated computer technology that the government uses in "fly by wire" aircraft, the CNC developers are really pushing the envelop trying to "cut by wire". Now lets cut a thread. I consider this a "rubbing you stomach and patting you head to the beat of music" sort of function. Why? You have to start at exactly the same point, move along the z axis at a 100% (or reasonably close proximity) constant speed all while NOT moving in X axis. All while counting to 1024 and then doing it again next revolution. .

The way the typical threading routine is done is the CNC will position the X axis, wait for the marker pulse on the spindle or C axis, the Z axis will then be electronically geared to the C axis encoder, so if there is a slight variation in spindle speed the Z will vary accordingly to co-ordinate the two.
On the PC based cards I use (like Galil) have 32bit RISC based Processors that will read encoder inputs up to speeds of 12Mhz. and servo update as low as 30 µs. they also have the electronic gearing feature.
AFAIK the Software PC based systems that operate through the parallel port do not close the control in the PC.
Al.