PC CNC control

B

bsharp

Registered
Registered
Joined
Dec 31, 2011
Messages
10
I have been beating around the idea of writing a windows based CNC control for a while. I currently have Mach 3 and it has worked well over the years but it does have its flaws, limits and quirks that will never be fixed.
I would like to write a Windows based controller that would have more ability's and be more refined for normal shop CNC machines.
At this point I don't think it would be of use to mess around with writing a parallel port driver as they are limited and will soon be extinct anyway. The controller would interface with USB or network controller cards and IO boards.

1: The software would be specifically written for a 2 to 3 axis lathe or a 3 to 4 axis mill
2: More robust and useful built in conversational ability's
3: Ability to support more I/O for tool changers and ability to support a proper machine error reporting system

I guess my question would be from a home shop perspective what are some things that you would like to see or not see in a cnc controller software?
Like I said this is just an idea that has been rattling around my brain for the last few years and figured I would try and get a little input from others.
 
Nice idea, and sense you asked. The #1 feature I would like to see is a program that is cross platform. :soapbox: ->About 25% of the world does NOT use window$ and that number is growing. Way too much windows only crap out there as it is. Don't really think the world needs any more.<- :soapbox:


That being said, as I'm sure your aware, using usb can not be relied upon to be real time. That means that your going to need to offload the machine commands to an external buffer. Regardless if your going proprietary or open source, make sure your com protocols are well documented and open so hardware can be adapted. The program should be able to talk to a $10 Arduino as easily as it can a$10,000 state of the art control box.

Touch screen friendly interface. Keyboard and mice don't always play well in the shop, but a sealed up touch screen can last years.

On the fly adjustable jogging speed.

Ability to accept user scripting with a straight froward and easy to understand interface.

I'm sure there's more, but that's just off the top of my head at the moment

Mark
 
Well I am very new to all of this, in way over my head but plodding along, so I cannot even say what I would like to see, except .......... better, more understandable, clearer documentation and manuals. Mach3 is on its way out but the documentation has never been brought up to snuff. I was reading one of the manuals recently and it said see further information on page ?????. For me a less than perfect program with good documentation would be better than a great program with poor documentation. I know writing documentation is not fun or sexy but you can see why some programs are expensive, because they have invested in what is needed to make the program useful.
 
MarkStephen said:
Nice idea, and sense you asked. The #1 feature I would like to see is a program that is cross platform. :soapbox: ->About 25% of the world does NOT use window$ and that number is growing. Way too much windows only crap out there as it is. Don't really think the world needs any more.<- :soapbox:

Mark
Click to expand...

I'll second that, as long a "cross-platform" includes more than just Microsoft and Apple.
 
The Windows program should only be a translator and communication conduit. Drip the motion commands to the controller buffer. Offload all of the motion control duties to the controller. That is one of the problems with Mach3, if Windows decides to go do something else for a bit, Mach 3 gets confused. I can surf the net, work on a drawing, or work on the CAM file for the next part while my machine is running.

Put in a teach function, on-the-fly speed changes, make the goto, and manual position entry simple to use, a 0.100 step over for easy edge zeroing, go to 0 buttons for each axis, variable park position (single button set). Keep most functions on the main screen.

I may think of more later.

I'm looking forward to seeing your work.
 
If folks don't like Windows why not just use LinuxCNC?

My first requirement for a Windows program would be for it to be written in a language that is native to Windows like C#. The same would be true if I was writing for a flavor of Unix including Apple OSX although Java would have no place in my program. If I had to have cross platform it would need to be written in C/C++ since other up and coming languages like JavaScript don't seem fast enough to handle a fast performing lathe or mill.

Error and memory handling would be front and center. Create a variable or object, add the appropriate destroy code before continuing on. I see to many people say "I'll clean it up later" and you have a junk program bleeding memory all over the place.

The config file would have a debug switch to turn on additional in depth error handling.

Wizards would be a big part. For instance thread milling would be built in. Geometric shapes that are easily defined. Rectangle, square, circle, oval, rhombus, etc. Specify the dimensions, cutter diameter, depth and sit back. Combine the output from multiple wizards to work faster.

Oh yeah and it would have to use scales to ensure that steppers have feed back to overcome missteps.

Dave
 
Getting away from Windows is not really a slam against Windows as an Operating System. It is not designed for that type of control. To be fair, Mac OSX and Linux are not either. The realtime linux kernel extensions help a bit but there is still a lot going on that is not part of controlling the machine.

What you would be best off doing is a two layer type program. An embedded controller to actually control the machine with a simplified g-code and a higher level program to feed that code and doing tasks that are not timing critical. There are many that are going that way. Off the top of my head: TinyG, Grbl, Planet-CNC's USB controller, Reprap software such as Marlin and the like and to a lesser extent, the Mesa cards and such. It doesn't take that much computer to handle the hardware. Little Arduinos and PIC based systems like PlanetCNC's work just fine. More elaborate controllers could run on things like a Raspberry Pi (although it's IO capabilities are pretty much crap in comparison to an Arduino Mega). Beaglebone is another option. The newer Arduinos with a system on a chip are looking pretty good. G-code is can be streamed to a controller well with the capacity of USB or Ethernet. It has been that way for years with printers. Most better ones use a page description language that is kinda comparable to g-code - postscript and HP's PCL.

There is a lot of room for improvement for the user interfaces of the programs. Putting it bluntly, Mach3 and LinuxCNC interfaces suck. They put so much on the screen at once, it is just sensory overload. You don't need to see the g-code stream past while the machine is running. It goes by to fast to be useful. You don't need to see the graphic path stuff all the time. The coordinate readouts are too small and hard to see unless you are right up on the screen. The HAL stuff in LinuxCNC is pretty nasty. I don't know anything about the MACH3 hardware stuff to have an opinion.

As far as the development tools, I am biased towards platform independance. Java and C++ with a good multi-platform library like QT would be first on my personal list for the main GUI and program logic and maybe something like a Python scripting interface. To be fair, you could do some pretty sweet stuff with C# and the .NET controllers like the Netduino family of boards.

In all, it is something that people have done. so no reason why you couldn't. The program that works with Planet-CNC's controller seems really capable of someone doing it themselves. The 3D printers do it just fine. There is a lot of room for a better product.
 
Linux can be stripped down to the bare necessity. The real problem is choosing a Motherboard that is not inundated with unnecessary hardware killing CPU cycles. A basic Atom based mini itx or smaller board will give you the best latency.
You can also build a custom GUI for Linuxcnc to suit your tastes which several people have done.
 
JimDawson said:
The Windows program should only be a translator and communication conduit. Drip the motion commands to the controller buffer. Offload all of the motion control duties to the controller... .
Click to expand...

I want to strongly 2nd this point. This is THE PROBLEM with other windows based controls.

The very few controls that handle this issue correctly are so expensive almost no hobbyists use them.

Karl
 
You must log in or register to reply here.
Back
Top