Is anyone using Mach 3 instead of UGS? If so, can you tell me how you connect the PC to the controller. From my reading on the Mach 3 site, the output is to a parallel port. I can’t see how to connect a parallel cable to the LongMill controller. Tks.
The controller supplied with the LongMill replaces Mach 3 and an external controller. There isn’t a parallel port for the LongMill unless you replace their controller with an external power supply and controller. The timing to a CNC router is critical, measured in microseconds. Interestingly enough, most modern multi-core, hyper-threaded systems cannot properly drive a CNC router because the jitter (the difference between when a pulse is supposed to be send and when it is actually send) isn’t good enough. Old Intel 396 systems, while they wouldn’t be very good for the CAD/CAM part of the job, typically do much better in producing a reliable stream of pulses. Another mistake many make is to attempt to use a USB-to-parallel converter; this fails miserably as the USB protocol is a streaming protocol, not real-time.
I’ve previously used an external CNC controller being driven by a parallel port, although with LinuxCNC, not Mach 3. I had all kinds of trouble with jitter, no matter what I did. The controllers can also be rather pricey; you can get cheap ones with the attendant problems or one of the more expensive (Gecko G540, for example, runs around $300) ones and still have to deal with jitter.
The GRBL-driven Arduino is real-time and off-loads the timing of the pulses from the PC.
Another solution I’ve seen is a USB dongle that uses a PIC to do the actual timing and is driven by a custom LinuxCNC implementation. The motion planning and pulse generation is done on the PC and fed to the dongle, which provides the actual pulse timing.
Sorry I went a little sideways on the answer, but the short answer is that there is no parallel port on the LongMill controller because it replaces the G-code interpretation, motion planning, and pulse generation where it would normally be done on the PC in either Mach 3 or LinuxCNC.
Tks for this, but I must admit that you lost me.
Suffice to say that I cannot run mach 3 with the existing longmill controller. I have no intention of replacing the longmill controller. My thought was to use mach 3 instead of ugs, which seems to hate me. I cannot get a job of any size to run completely. So, I thought that paying for a different g code sender may be necessary. Clearly, though, mach 3 is not the answer.
Tks again.
There are other gcode sending softwares that are not UGS that you can also use with the LongMill.
Info can be found here: https://sienci.com/dmx-longmill/machine-interface/
Tks, Andy. I had read your list and I if I can’t get UGS to settle down, will pick one of them.
Let me see if I can provide a little more clarity on my previous post about controllers, jitter, etc.
The main parts of doing milling or routing are: design (CAD), turning the design into GCODE (CAM), and driving the physical machine. I’m only going to cover the last of these.
GCODE is a language that describes how a machine is supposed to move; this is generated by the CAM so the machine will move the bit in the correct path to carve out what you want. CNC machines don’t use GCODE themselves, but use a combination of an interpreter, motion planner, pulse generation, and power drive electronics to drive the stepper motors. There are several different combinations of the above.
-
Separate interpreter, which does the motion planning and, in real-time systems also the pulse generation (MACH3, LINUXCNC, and a few others). These take the GCODE, do the appropriate motion planning in an attempt to optimize the paths, and talk, typically via a parallel port, to the drive electronics. The pulses are generated real-time in the host system and timing is extremely critical. Many modern PCs just cannot do the real-time part of this.
-
An in-between option is the dongle I referenced. The GCODE interpretation and motion planning are still done on the host system. The pulse generation is put into blocks and transferred to the dongle over USB which then does the actual timing of the pulses and drives a parallel port connected to the power drive electronics.
-
Many 3D printers use an approach whereby the GCODE is transferred to an on-board memory which used to interpret the GCODE, do the pulse generation, and drive electronics to drive the stopper motors, all on-board the 3D printer. They use something like the GRBL used in the LongMill.
-
LongMill (and a few others) use GRBL on an Arduino Uno to do the interpretation, motion planning, and pulse generation. They are fed the GCODE via a USB connection. UGS (or similar software) is used to transmit the GCODE to the Arduino and provide a visual feedback of where the bit is supposed to be. Typically, several GCODE commands are transmitted in a buffer so the Arduino can do some look-ahead for its motion planning. The Arduino transmits the pulses steps to a separate board with the appropriate drive electronics to drive the stepper motors.
In my previous post, I mentioned jitter. The stepper motors require very precise step timing to operate efficiently. They typically have 200 steps per revolution (1.8 degrees per step) and often use a concept of microstepping which is a multiple of the 200 steps per revolution to effectively give more steps per revolution. Common values are multiples of two. There is one controller (Gecko G540) which supports 10. The micro steps aren’t quite a precise as a full step, but are usually good enough, especially on hobby-level machines that don’t often have better then more than .001" of precision. Now, jitter is how far off one step is from the desired timing of the pulses. If a pulse arrive too early or too late, it might not take effect; the result is missed steps, which is always bad. One step is often unnoticeable, but, if your system has bad jitter, the pulses will much more often arrive at the wrong time and that can ruin a project.
Hopefully, this provides some background on how the CNC systems are driven.
2 Likes