I have an existing complex application (22,000 lines of code written in Java) that controls a three axis milling machine of my own design from a Windows 7 or XP laptop. It currently uses a modified parallel port (including a hack to the Windows System Kernel to allow direct access) and some custom electronics to achieve simultaneous control of three stepper motors and receive diagnostic information from four sensors.
I need to upgrade this software/hardware to include the following:
USB communication to replace the parallel port
Two way serial communication (preferably via the USB port)
Add capability for another two stepper motors (bringing the total to five)
I have looked at the specifications of the various Arduino boards available and I think that the Mega2560 R3 or the Due look to be possible candidates.
My requirements therefore are:
20 output pins (of which only 10 will be active at any one time, each drawing about 10mA)
4 input pins
Bi-directional serial communications (or two one way serial communication streams) preferably via the USB port
I have searched the forums extensively and believe the above mentioned boards can cope with the first two requirements. What is not clear is that the USB port will support bi-directional serial communication (or two one way serial streams). I have tentatively defined both outgoing and incoming protocols for the five stepper motors and the four sensors.
I would very much appreciate technical advice as to the feasibility of this project and any suggestions on how to proceed. Please feel free to check my profile to check my competence for such a project and also feel free to request clarification if needed.
Sounds like you should look at GRBL (or a similar firmware). It would require that you communicate with your machine using GCODE, but GRBL does support commands for bidirectional communication. It would at least provide a basis for you to start from and you could extend it to meet your needs. You're looking for control of five motors so you might need to look at those alternate firmwares -- or I suppose you could always add a second controller.
Under normal circumstances I don't think Windows supports real time control with a USB port -- you can't send step/dir/etc. command pulses in a timely manner like you can with a parallel port. With GRBL all of the real time activity is handled by the microprocessor itself.
An Arduino Mega should comfortably meet your requirements. The only question is whether you want to write your own code for it, or whether you want to use code that someone else has developed.
You will almost certainly need to move some of the PC logic onto the Arduino simply because the USB system is not capable of giving immediate feedback in the way that the parallel port can. USB can transfer large amounts of data very quickly but it can be very slow for single byte data transfers.
Using GRBL as @Chagrin has mentioned would pretty much shift all of the control logic onto the Arduino.
If you like developing code yourself it should not be difficult to develop your own Arduino code - but you will need to have a clear picture in your mind of the relative roles of the PC and the Arduino and of the limits on communication between them due to the USB system.
Many thanks to you both for your advice and I apologise for the delay in replying; you gave me a lot to research and consider, plus I have had log in problems to the site (for some reason IE11 does not like your site).
With regards to Chagrin's post, I have looked carefully at GRBL and RepRap firmware (the only Arduino targeted software on the second list) to see if it would be useful. RepRap is too specialised and would need a lot of adaptation before it would be useful. GRBL is closer to what I need but puts too much of the functionality onto the Arduino. A lot of the functions in GRBL have already been implemented in my Java program but, not to put too fine a point on it, there are significant functions missing in GRBL that I have implemented in Java:
Automatic calibration of the physical system
Multiple smoothing routines
The ability to switch cutting heads and cutting bits mid job
The ability to automatically switch between stepping modes to achieve better smoothing - Half step/Full step, Single Phase/Two Phase
Support for Unipolar, Bi-polar Series, Bi-Polar Half Coil and Bi-Polar Parallel motors
This brings me neatly to Robin2's post. I need to keep the "meat" of the application in Java wherever possible as I intend to expand the capabilities quite significantly. I think that transferring some of the functions onto the Arduino would complicate the development process and quickly hit the storage limitations of the Arduino. My intention is that the final version will have 5 degrees of freedom to achieve fully smooth finishing in the final product.
So, I have a dilemma. I would prefer that the Arduino just acts as an "interpreter" for the USB port, passes on the pin activation and relies on the custom electronics to translate the signals into the control of the higher voltage and power needed to activate the motors.
My next step, therefore, must be to investigate the capabilities of the USB port, including any idiosynchrocies that might it have with regards to latency. I will purchase a 2560Mega, download the SoftwareSerial Library and the AltSoftSerial library and play with these for a while.
I will try to create hard statistics to the transfer capabilities of the USB port using both these libraries and will report back on the results ... it may take some time so don't hold your breath.
Many thanks for your suggestions and your support.
Ethernet is a better way to communicate with a cnc machine there can be to much noise for a usb cable.
get your self a bob and use the arduino to pass the commands to the bob from the computer and back again then your computer and arduino are doing bugger all.
so it can be faster.Ii run a ess on my cnc router and it makes the computer run faster as it only sending and receiving info from the ess and the ess just makes the machine do what you wont, its overall just faster than a PP
m2030978:
My next step, therefore, must be to investigate the capabilities of the USB port, including any idiosynchrocies that might it have with regards to latency. I will purchase a 2560Mega, download the SoftwareSerial Library and the AltSoftSerial library and play with these for a while.
You have a misconception. You don't need either SoftwareSerial or AltSoftSerial to communicate between an Arduino and PC over USB. That comms ability is built in with HardwareSerial. In addition the Mega (unlike the Uno) has a total of 4 HardwareSerial ports - but I'm not sure that is relevant for your project.
You just use Serial.begin(baudrate); to start comms aith the PC and Serial.read() and Serial.print() or Serial.write() to receive and send data.
I am a great believer in doing as much as possible of the hard work on the PC. I am experimenting with a system to interpret G Code on the PC and just send data for the number of steps (for 3 motors) for a move to the Arduino. However, be warned, compared to your CNC system mine will be a toy - using a very small lathe as a base.
At the moment I am experimenting with how quickly I can send the data for a single move to the Arduino. My PC (Ubuntu Linux - using the JVM) can communicate with the Arduino at 1,000,000 baud - which is about 100,000 chars per second. But because I only want to send a relatively small amount of data 11 bytes, maybe 44 or 88 the turnaround time gives a much lower average. Sending 44 bytes (in my case that is data for 4 moves and each move could be thousands of steps of the motors) the turnaround time is about 4 millisecs. I think it would be much the same with 88 bytes but HardwareSerial has a 64 byte buffer so the next step is to modify HardwareSerial.
Hope this makes some sense. Note that the max baudrate for the Arduino Serial Monitor is 115,200.
I haven't got around to the question of limit switches. I think they need to be resolved entirely on the Arduino because sending data for a pressed switch to the PC and sending new instructions back would be much too slow.
Thanks Robin2, You are quite right; I did not realise there was a hardware.serial (newbie mistake). I'll look at that first.
Chagrin:
Under normal circumstances I don't think Windows supports real time control with a USB port -- you can't send step/dir/etc. command pulses in a timely manner like you can with a parallel port.
Chagrin made a point about Windows not supporting real-time control of a USB port, but I already have real-time access to I/O buffers in Windows thanks to a system kernel hack. As long as I know the address range for the port, I can post/read data straight to and from it without Windows even noticing. I used this on my original version that used the parallel port. I'll try it out.
I need to buy the kit first (after I've been on Holiday ... )
m2030978:
but I already have real-time access to I/O buffers in Windows thanks to a system kernel hack. As long as I know the address range for the port, I can post/read data straight to and from it without Windows even noticing. I used this on my original version that used the parallel port. I'll try it out.
Are you saying that you can send (and receive ?) data over a USB cable attached to your PC without using the internal USB system? In other words you have an I/O system that is not actually USB but uses the USB cable?
If you can, then it seems unlikely that the Arduino would make sense of it without modifying the USB code at the Arduino end - or, perhaps, connecting directly to the Rx and Tx pins.
I must say I would be content with using the normal USB system and leaving the Arduino to manage the real-time stuff.
So it sounds like you're planning on sending bit strings ~32 bits in length from the computer to the Arduino, then on the Arduino just use a simple sketch to push those bits onto the Arduino pins.
You'll want to look at Port Manipulation; I guess it would be akin to directly accessing the I/O buffers in Windows; with very little overhead you can push a byte onto an AVR register to set the output state of 8 pins. See also http://forum.arduino.cc/index.php/topic,25799.0.html for a couple links to references for the port-to-pin groupings for the Arduino Mega.
Be sure to avoid PORTD as that port contains the TX/RX pins (pins 0 and 1) that the USB-to-serial translator on the Arduino uses. PORTA, C, and L appear to be the conveniently grouped pins on the Arduino Mega.
Sorry good people, I did not intend to stir things up. I believe in the KISS principle.
I try the normal routes first and if they don't work (which I am sure they will) I try alternatives until I find something that works.
I have not yet tried to use USB serial comms (need the arduino first!).
The only reason I mentioned the hack is that Windows can be notoriously coy about allowing access to I/O ports sometimes as I found out with the parallel port. Treating my device as a printer kept triggering interrupts with the returned data. The hack stopped all that.
Thanks for the links
Chagrin:
You'll want to look at Port Manipulation; I guess it would be akin to directly accessing the I/O buffers in Windows; with very little overhead you can push a byte onto an AVR register to set the output state of 8 pins. See also http://forum.arduino.cc/index.php/topic,25799.0.html for a couple links to references for the port-to-pin groupings for the Arduino Mega.
before you get too far down the path, have you been able to control the 5 axis with an arduino, with motors moving at both operational speeds and rapids ?
one of the problems with a 5 axis CNC is the movement of each axis. as you know, in order to follow a contour, one axis has to speed up at the exact same time as the next slows down. in order to run a stepper or servo (industrial servo) one typically uses a driver that offers over 1,000 pulses per inch, with possibilities of many times that.
what I am getting at is that the ardino has to be able to control 5 motors, probably running over 2,000 pulses per inch, in real time for the operation of the machine.
reading input should never effect output. in other words, you get a constant or variable stream of date from some device (host or memory) and turn that into steps, and run the motors. the controller needs to be able to fetch information so fast that it would not effect the output.
if your machine runs at 12 IPM, that is 0.2 inches per second. if you have 5,000 steps per inch, that would be about 1khz. times 5 motors. this may be glacial in comparison to the normal operation of the Ardino.