In looking at the various titles of CNC control software I'm not really impressed with any of them. Mach X has the largest following, probably driven by price, but I'm sure it's also a good product. Camsoft looks quite a bit better but is more than 10x the price.

I've installed the demo of mach to play around with it a bit and there's no way I can say this kindly, the whole layout of the program looks like mess. I have one programmer working for me who is no longer allowed to make any interfaces because everything he built looked...well...similar to the mach interfaces. Random sized buttons placed all over the place and objects that don't really operate the way you would expect within a standard Windows environment. I've been having to build software that car dealers can operate so I'm used to making things that have real simple layouts so I guess this is a bit of a pet peeve of mine.

Well in all of my scouring it seems that everyone, even the turn key CNC systems (shopmaster, Tormach) use mach.

Am I way off base here because it seems that a controller should simply allow G-code conversion, loading of G-code programs or an MDI interface and finally a tool selection interface. This doesn't seem that complicated. With the new G-rex from Gecko I'm thinking about writing a custom app to do just that. I really like the G-rex because it offers so many inputs and outputs that you could also have a hardware controller for things like feed rate etc. Really my biggest concern is that I don't know what I don't know. Anyone consider taking something like this on? What are the most challenging things to overcome?

I agree that the screens in Mach are a little too busy (for me anyway). But the thing we have to consider is that Mach allows you to create your own screens, and gives you as many function as you need, lay them out the way you see fit.... Look at cel phones today, its more like a gameboy / i-pod / pda / mp3 player / web bowser / oh yeah and use it as a telephone

It all depends on how much of a CNC controller you want and how much of the work the controller card does for you. Biggest headache #1 is MS windows. Even stripped to the core it sucks for real time work. If you want cutter comp this also gets trickey. How about block lookahead and backlash compensation? I build my own CNC software and run on Galil motion control cards (something like Camsoft). Written almost entirley in VB6 the current build version is just shy of 29,000 lines of code. This includes lots of bells and whistles like in-process gauging, auto-size adjust, high-speed rigid tapping and SPC stuff too. If your just going to process G00,G01,G02, and G03 codes it pretty simple. Start adding cutter comp, mixed incremental and absolute programming, multiple corrdinate systems etc. and the thing just grows and grows. One good thing, after building one of these you can write G-code programs in your sleep as you'll get an in depth lesson in the math involved.

The reason Mach has the largest following is because it's basically the ONLY program that can do what it does. Output a useable pulse train through the parallel port using Windows. Camsoft uses motion control hardware to do it.

If the only thing you don't like about Mach is the screens, as was mentioned, create your own. Far easier to create your own screens than to create your own software. Here's a screen used by an OEM running Mach on their machines.

One other thing to consider is that Art has spent 12-16 hours a day (every day) for at least 3 years to get Mach to where it's at today.

If you want something you can modify - take a look at emc2.

http://www.electronicsam.com/images/KandT/Dapper.png
http://www.linuxcnc.org/
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl

sam

I build my own CNC software and run on Galil motion control cards (something like Camsoft). Written almost entirley in VB6 the current build version is just shy of 29,000 lines of code. This includes lots of bells and whistles like in-process gauging, auto-size adjust, high-speed rigid tapping and SPC stuff too.

Out of interest, what or how much do you down-load to the Galil at one time?
I have played around with different interfaces to these cards, I wish I had the time to get more invloved, what Galil commands did you use to sync the spindle for the rigid tap, I am experimenting with the threading for a lathe, so it should be the same principle.
I understand if you want to keep this to your self.:)
Al.

I think that the Camsoft idea is probably the best approach, short of writing a specific interface for a particular machine, which then turns you into a 'black box' manufacturer, where you have total control over how every detail works.

The way I understand Camsoft, is that it would be using high level windows language piggyback on a lower level Galil command set. I suppose anyone knowledgeable in programming can learn to first use the Galil command set intelligently, and interface that with windows programming.

Camsoft may be a bit pricey up front, but it gives a wide margin of freedom. I suppose the interface could be spruced up and modified in thousands of ways, all of which would boil down to the same basic control.

Camsoft gives you a graphic proveout of your gcode program. This in itself is a bit of an accomplishment, and I do not think this has anything to do with Galil commands, so you would need to mimic that, or else your potential customers will be asking for it later on. I make use of this feature quite regularly on my Camsoft lathe retrofit, as it shows very plainly if I have 'fat-fingered' my edits, as I can visually trace out any errant segment of the toolpath.

I would like to see Camsoft advance the GUI a bit more, perhaps allowing the program to use dual monitors (if it doesn't already). I find my operator screen is extremely crowded as there is simply not enough room to lay out everything with ease, and have a graphic backplot viewport that is large enough to be remotely useful in size.

Chris64,
If you don't go with Mach software your making a big mistake. I understand the concern about the busy screens but there are many other screensets availible for Mach that are simple and more user friendly. I often wonder how Artsoft can aford to sell this software so cheap. I chalenge anyone to show me a better software for the same price with all the "bells and whistels" Mach has. Other things to think about is the detailed manuals Artsoft provides, demonstration videos, multiple message boards for support, wizard addons from Newfangled, ect. Also take some time to read about the new Mach Quantum artsoft is working on.

Well first off I will say that the screen shot Ger21 showed is very impressive. I didn't know that you could design new "skins" for mach. They should consider having someone build a professional looking default skin.

Part of the problem to me with most of this software is that it's designed to do everything for everyone on every machine. Maybe this goes right back to the "skin" argument but I don't feel like I need that many features.

Another thing was some of the features on different system I really like but I can't afford the systems that have them. Centroid has a lot of neat sensor features like finding the center of a hole or resetting the entire geometry system to the angle of the item mounted down. So if a block of aluminum is 1 degree off of square it could scan the edge and twist the entire architecture so that it is on that same angle. My thought was that if you had a jig with two holes for reference points you could swap jigs very easily and recalibrate locations.

As far as communicating with a parallel port, I have no interest in pursuing that route. Even if you can get Windows to maintain a good clock rate it's such a slow method of communicating. My only reason in considering something like this is specifically for the Gecko G-rex. It's specs look pretty impressive and it could allow for many features. Apparently there isn't any software support for it yet though. And of course it's price is very affordable.

Another feature that I don't even know if it's possible would be putting an encoder on the spindle so that you could potentially handle tasks like rigid tapping (if I'm using the correct word). This would require the Z axis to adjust to keep up with where it should be. I don't even know if this is possible. If nothing else this could give you an accurate true RPM feedback to your display.

You can download the Mach screen designer (Sceen4.exe) as well as some additional screens, and current Mach versions from http://www.machsupport.com/artsoft/downloads/downloads.htm
Mach is free for up to 1000 lines of code, so you can play around with customizing it without purchasing it.

There's a screen designing tutorial video at http://www.machsupport.com/videos.htm
The Mach G100 plugin is open source, so you can modify it to add features or suit your needs better. You can get the SDK from the first link I posted. Art is waiting for a firmware update for the G100 before he can finish the plugin, as the updated firmware is needed for some features.

If you have good enough skills to contemplate writing your own control software, you shouldn't have any trouble customizing Mach to do what you need.

In Mach you can customize macros. I'm sure there is a way build a macro or wizard to give you those functions you are looking for.

From what a read the G-rex is the way to go. I'm sure you'll get all the support you'll need from Gecko and Artsoft.

Have you posted over at the Mach forum on the Artsoft website? If not there is a load of info over there also.

If your interested in building your own screens, check out the Flash screens some of the guys are working on over there.

Something I've been looking into is "Microsoft Robotics Studio" ( http://msdn.microsoft.com/robotics/ ).

I know is says robotics, hey a servo is a servo.

You can watch an itroduction video here: http://channel9.msdn.com/ShowPost.aspx?PostID=206606 check out the bluetooth gamepad.

So far all I've seen are toys that they have worked on, I keep hearing about industrial robots, but havn't seen any examples yet.

This has only been out less than a year, & very hard to find any sites other than MSDN to see working examples, code, machines, etc...

I'm very, very interested in the industrial side of this, & hope things pick up a bit faster, we'll see. :)

Oh by the way everything you need to program is free...



.

In Mach3 you can write your own plugins "Mach3SDK" http://www.machsupport.com/Mach3SDK/Mach3SDK.html


.

Just to clear this up...I don't like the look of the default mach but that's not really my concern (although I'm impressed with the skin feature). I do think that I'm a little prejudice against a program where they don't take the time to make it well layed out by the third version...again, a pet peeve.

Really I'm interested in utilizing the Grex controller. I talked to the guys at Gecko and it doesn't sound like Mach supports the Grex yet. So my choices here are pretty limited...wait for mach or build it myself.

Out of interest, what or how much do you down-load to the Galil at one time?
I have played around with different interfaces to these cards, I wish I had the time to get more invloved, what Galil commands did you use to sync the spindle for the rigid tap, I am experimenting with the threading for a lathe, so it should be the same principle.
I understand if you want to keep this to your self.:)
Al.


Al
I have 1 task running in the galil card that is basically a watchdog program that is monitoring the motors for overloads, checking the safety switches, etc. This task shuts everything down when something goes wrong or of course when MS-windows decides to die while the motors are jogging at 900 ipm. :) The motion commands are sent to the card as the program executes line by line much as you would type them in from the terminal. Continuous contours are a little more complicated but basically you just sent a whole string of VP and CR commands and then tell it to go. I use the GR command for rigid tapping. I put an encoder on the spindle and gear the Z axis servo to it. Now when you turn the spindle the z axis moves up or down following your screw pitch. Note that this is a vertical machining center and I have a 1500 lb head pulling down on my leadscrew so there is no backlash to worry about. This would work for threading on a lathe in one direction but you couldn't do rigid tapping due to backlash/axis reversal errors when you try to pull the tap out. Glad to share this info, any questions don't hesitate to ask.

I think it’s practical if you can spend a few thousand hours working on the software before you get a usable program. It would seem to be more practical to purchase a ready-made program.

I think focusing on a specific machine or type of machine would be beneficial to shortening the development time.

I have also been eyeing the Grex. I think there are some possibilities with it, but there are some issues of great concern as well with it. It has been close to completion for about four years. In my estimation the core objectives of the original project manifesto have actually been met. I see a lot of script on the failure to sync a spindle motor for threading but that is actually mission creep.

The thing about motion control software is that the motion is really a big deal. It is not a trivial problem unless you are only going to concern your self with a program that just generates g-code files.

I did take on the task of building a motion control software program. It’s been over a decade of programming bliss. I resolved to forgo the g-code part and made a direct CAD interface to the machine.

It’s hard to say if it was practical to do it, but it certainly has been beneficial to me and the users of my program.

I think there is an expanding market for machine control software. I think the Machx programs are actually doing a pretty good job of plowing the field for more sophisticated approaches to machine control.

Art has said he currently has a registered client base of 7000. So that should give you a feel for the size of the market. If you are only going to build a program for one machine it is totally not practical.

Dennis
www.super-tech.com

Dennis, I'm not really sure what my plan is, but I like to try and look at things from a different angle. My thought was actually building something like you said where it is a straight CAD program to controller. It's market (if any) would be 3-4 axis CNC mills. Mostly conversions which is a huge market. Really I just wanted it for me (but if it's marketable...why not).

I was thinking of using a method of starting the drawing with the shape of the stock (maybe a DirectX ".X" object). Then draw or import tool paths so the program can design the cleanout and finishing paths. The idea is that it would create a 3d object with each stage so that the new "stock" object would be the finished object from the previous process. This may be common in some software but I haven't seen it. I think this method would really assist with 4th axis design too.

Ultimately I figure there's no getting around the simplicity of using 3d objects for the final shape. There's so many powerful 3d design programs. This is my major problem right now with my early 80's controller with 1k ram. Making a nice square pocket just doesn't blow anyones socks off...and you can forget about trying to put in a company logo. ;)

Plus I'd like to build a controller that isn't as big as the mill itself.

How about block lookahead and backlash compensation?

Can you explain this a little to me? The lookahead part.

Backlash compensation isn't as a huge concern to me right now for a couple reasons. One is that it seems to me like it's just tool path logic, each time you change directions on any axis, move a little extra. The second is that my machine right now doesn't appear to have any slop...I'm sure there's some there (is it possible to have no slop?) but it's very minimal (move right and left .001 without slop) and I have no compensation values currently entered in.

I am concerned about what I don't know about...if that makes sense. I made a 3 axis stepper control a long time ago through the 12 digital outputs from the parallel port. I didn't have to put any thought into accounting motor direction with that set up. I could go forward or backward on a whim without any problem. I did have a problem with my controller generating a ton of heat...but that's another story.

With my servos I do notice that when I'm using rapid movement that the servos seem to speed up and slow down stages. I don't notice that on normal motions.

Chris, I just thought I’d give you the benefit of my experience. When I started out I thought it would be a couple of thousand hours of programming, but I was way off. But that was before the fantastic visual programming tools were available.

I have seen a demo of VisualMill that does exactly what you describe with the 3D cut simulation.
http://www.mecsoft.com/Mec/Products/products.shtml

If you can build a program that will start with a raw block of stock material and simulate the tool cutting action with a rendered graphical 3D display, you got talent. By all means do it. It is a piece in the puzzle, and the puzzle is not complete with out all the pieces.

From my point of view if you open source your work, it has no value. If you maintain your intellectual property rights, I would be interested in implementing them. I have the framework of drawing to cutting in real time with on screen animation, 2D or 3D. As with most things it could be improved upon.

It would seem to be an awful lot of work to go through though, just because you are upset over a few sloppy screen displays in the Machx programs. As previously suggested it is much more practical to re-skin the Mach3 program. Few appreciate the miracle of the Machx motion control algorithms, the magic of that aspect gives Art a lot of latitude in display design.

If you can keep in mind that the screen and the keyboard are the sole user interface to the machine you can fit the machine motor controller into a shoebox.

I have a YouTube video at:
http://www.youtube.com/watch?v=L1-mF14GYhU
I am working on some tutorials at:
http://www.super-tech.com/root/itm.asp?p1=itm-supercamxp-tutorials
They should give you some idea what kind of interface I am talking about. My human to machine interface is completely unique, as far as I can tell. I was thinking CAD, not control panel, so my approach to the problem was from a completely different angle.

Whether something is practical is always going to be subject to debate. One thing to consider is your return on investment, which can be measured in many ways.

Backlash is usually the mechanical slop between the lead screw and the nut. To compensate the axis motor has to reverse directions with out counting the steps as moved distance.

Look ahead is where the trajectory planner looks beyond the current segment of movement and adjusts motor motions accordingly. It is a waste of time to slow down for a minor deflection in angle when moving from one segment of movement to the next. Without look ahead the motion motors must slow down and start up for each segment of motion.

Dennis
www.super-tech.com

Dennis, thanks for the info. I read through Grex docs most of the night...I'm going to try and order one today. It appears to have an option where you can specify true path or calculated path. As you said, in the event you're doing minor changes to the path you can use the calculated. If you're doing a right angle you would use true path. I'm very impressed with it. It appears to be (almost) as easy as telling it to go to XYZ coordinates. Some of the speed controls are explained a little weird but I think I get the basic idea of it. I'm curious about how I would interupt it's path mid stream but that's another story.

I'm looking into the 3d graphic part to see how practical it is. Re-writing dynamic vertices based on collision of two objects sounds like a headache.

And again...it's not the look of Mach that I don't like. I think I'd like to consider a different way of Cad->cam->Cut (you should appreciate that). Right now I'm graph paper to notepad to hyperterminal. I understand most the scope of what I'm considering...it's the unknowns that I'm worried about (hence this thread).