PC CNC control

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.

Hardware for which no driver is loaded uses no 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.

Better to devote a mini itx or somesuch to LinuxCNC (or to your homegrown software) and use a different one for the GUI.
 
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.

Linux even with realtime extensions may not be true hard realtime but I think that with modern hardware it should be fast enough for machine control. You can easily strip out all unnecessary processes and you have control over the type of scheduler and the process priorities and can lock processes into RAM. There is, of course, no reason that the cpu controlling the machine should have a GUI. That belongs on a seperate laptop or somesuch.
 
If bsharp isn't looking to produce a closed, for profit control package, and their is nothing wrong with that, but just wants to produce something that works with simplicity and ease of use, maybe contributing to already existing software or forking existing software might be an option. There is GRBL Controller that is looking real promising. Just lacking a few features, like auto probing, (3 axis edge and center), scripting, and maybe offsets. It's cross platform, runs really well on anything from desktop to tablets to Raspberry Pi/BeagleBone. interfacing hardware is very inexpensive, (dirt cheap) and lets one use about any stepper/servo driver one would want, from little postage stamp size on up. Something to think about anyway.

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.

When I started out I was the same way and figured I was in way over my head and at the time I was!
Looking back on it all now is one reason why I had the idea. It would have been a lot less frustrating if things were a little more refined and strait forward.
I actually like writing documentation and procedures. I did a lot of that when I worked as an engineering specialist, machine programmer and also product designer.
 
The problem with Windows and most other OS, it that they are not a real time operating system and are not capable of being locked into a program thread as a priority. The exception to this is Windows CE, at least the older versions, I haven't worked with the newer versions. You could set up deterministic control and write the program just like a PLC would scan the program. Then you would put a break in the program scan and allow a milli-second or so for the OS to take care of it's housekeeping. That way it keeps it's mind on what you want it to do, and takes care of the other stuff when you allow it.
 
The problem with Windows and most other OS, it that they are not a real time operating system and are not capable of being locked into a program thread as a priority. The exception to this is Windows CE, at least the older versions, I haven't worked with the newer versions. You could set up deterministic control and write the program just like a PLC would scan the program. Then you would put a break in the program scan and allow a milli-second or so for the OS to take care of it's housekeeping. That way it keeps it's mind on what you want it to do, and takes care of the other stuff when you allow it.

There doesn't have to be any housekeeping with Linux. Even if there is you can choose a scheduler and priority that assure that it will run on time and not be interrupted. There are billions of embedded systems out there running Linux. A typical embedded system has the kernel, uClibc (small version of the C library), busybox, and the application on it.

BTW I'm sure Jim knows this but Windows CE is not a version of the Windows you use on your desktop. It is a totally different OS designed for embedded systems.
 
Wow thanks for all of your great replies on this!
I guess I should have clarified "using USB or Ethernet" a bit further. The program itself would just be a translator and GUI. It would set up and do all the motion setup like work offset's, tool compensation and ect. The software would then download the instructions to the motion controller connected to the USB or Ethernet. At this point I am really undecided on what motion board to start out with but it needs to be inexpensive and simple to hook up and use "virtually plug and play".
A industrial standard Ethernet bus interface that could be easily connected to a cheap $50 - $100 dollar PLC would work great as simple and robust IO capability.

I will be initially writing the software in C++ on windows. The reason is that it is simple to use easy to support and familiar to lots of people. Lets face it not that many people know what a bash prompt is or how to edit text in Vi. Although there is nothing saying that it could not be ported to something else later on. What I think would be nice down the road is to have an imbedded version on a usb stick. Sort of like a Roku for CNC!

Most of the pc controller software core logic like mach that are out there were written on nix and ported to windows. If you have ever looked at the source for EMC I think you would agree that it is a complete mess. The original core logic was created by NIST to support as many different configurations as possible including scara robots and hexapods! This is all just unnecessary for what the majority of home shops that just want to retro fit a 2 axis lathe or a 3 axis mill would use it for. I think a clean slate needs to be made. A clean program designed specifically for the type of machine it will be used on and for the guy in his garage more interested in machining out his latest idea and not so much learning the inner workings of coordinated motion control. I know there are lots of these guys because I was one of them.

The first thing that I need to work on is creating the core logic from scratch. This will include all the algorithms that modify the trajectory code like tool and work offsets and cutter comp. This will be the toughest for me as I will need to dust off the rusty calculus gears that haven't been used in a long time. :) After the core is finished then we can do the fun stuff like create the GUI and conversational generators like threading, facing, pocketing, ect.

I really appreciate all of your input and please keep it coming. :)
 
You might find these books helpful.

"Step by Step Design of Motion Control Systems"


"Motion Control Applications"


"Motion Control by Microprocessors"


All of the above by Dr. Jacob Tal
 
The problem with Windows and most other OS, it that they are not a real time operating system and are not capable of being locked into a program thread as a priority. The exception to this is Windows CE, at least the older versions, I haven't worked with the newer versions. You could set up deterministic control and write the program just like a PLC would scan the program. Then you would put a break in the program scan and allow a milli-second or so for the OS to take care of it's housekeeping. That way it keeps it's mind on what you want it to do, and takes care of the other stuff when you allow it.

I worked with a small touch screen plc at a previous employer that ran windows CE and it was really nice. They used it to test the response time of proportional and conventional pneumatic valves. It was nice as it booted up almost instantly and was easy to train an assembler to use. Programming it was really easy using basic. Although I think it was a bit expensive if I am not mistaken.
 
At this point I am really undecided on what motion board to start out with but it needs to be inexpensive and simple to hook up and use "virtually plug and play".
A industrial standard Ethernet bus interface that could be easily connected to a cheap $50 - $100 dollar PLC would work great as simple and robust IO capability.

I would think that the Arduino family hit's the mark rather well here. Already working with great success, very very inexpensive, and they are usb out of the box. Add an ethernet shield, (or BlueTooth/WiFi), also dirt cheap, and your good to go. The platform has a lot going for it. Available the world over, huge user community, tons of peripherals, easy to use and hook up.

Not to say you could not use other PIC's / PLC's, but targeting the Arduino platform up front is a good hedge towards wide spread adoption. Their already being used in countless 3D printers. (that's 4 and 5 axis control), and seeing more and more use with 4 axis hotwire foam cutters, laser engravers, as well as lathe and mill operations. This translates to - hardware is already in place, waiting for a good controller program to come talk to it. :)

Mark
 
Back
Top