How practical is it to build control software

[Chris64]

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?

[RLC]

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

[CarbideBob]

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.

[ger21]

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.

[ger21]

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.

[samco]

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

[Al_The_Man]

Originally Posted by CarbideBob 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.

[HuFlungDung]

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.

[rcrabb]

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.

[Chris64]

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.

[ger21]

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/d.../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.

[rcrabb]

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.