is there an open source gcode interpreter that can drive mach3-type devices?

[gtoal]

I have a Sainsmart Genmitsu 3018 MX3 - which people refer to as a 'mach3' device but it isn't really - it can be driven by Mach3 and also another program called Drufel - both of which, as I understand it, implement their own internal gcode interpreters, and convert from gcode to pulses that directly drive the stepper motors.

Also although I believe the underlying interface is individual wires over a parallel port, my understanding is that the controller board on the MX3 is front-ended by a USB to parallel chip and that the parallel driving is internal to the controller board which is otherwise pretty dumb.

My question is whether anyone has created an open source gcode interpreter which drives this setup - I know there are a few that drive stepper motors directly over GPIO pins or equivalent parallel interfaces, but is there any that multiplex these commands over a USB interface? If not is the USB to parallel interface that the MX3 controller implements documented anywhere so I could take an existing gcode -> GPIO interpreter and modify the calls to drive the USB interface instead? I don't care what host such a program would run on although a linux/raspberry pi program would certainly be easier to work with than a windows-hosted one.

Failing that, does the "MPG" jog controller interface on the MX3 controller implement sufficient features that it could be used as a device interface instead, by hacking up a wire from say raspberry pi GPIO pins to the D-type connector? (I think it's the same connector as the old style VGA, no?)

Currently my workflow is to generate gcode by whatever means, and copy that gcode into Drufel via load file, or cut&paste, and then run Drufel to interpret the gcode and drive the MX3. I'ld like to be able to generate gcode and send it to the MX3 directly, eg by sending it to a Pi and having the Pi interpret the gcode and control the MX3.

Is this a pipe dream or do the components already exist? I got the impression from some older postings by 'cncdudez' that some of the software either exists or was started on.. I'm comfortable hacking gcode interpreters - I ported this code to a different arduino library a couple of years ago: https://github.com/mlpassos/easilogo...code/gcode.ino so I don't mind if there's a bit of coding involved...

(and yes, I am aware that I could just swap the MX3 controller for a compatible one that uses GRBL to interpret the gcode, and if necessary I will eventually do that, but for now I'ld like to try the way I've outlined above first.)

thanks,

Graham

Similar Threads:

• InTheBay's Open Source G0704 Belt Drive Conversion
• Open source Mach3 pendant, hot keys help!
• open source uni-polar chopper stepper drive 80V 5A -Schematic available
• open source uni-polar chopper stepper drive 80V 5A -Schematic available

[rcheli]

Why not just use LinuxCNC? It's free, open source, very flexible and powerful. There is plenty of help available on the LinuxCNC forum.

www.linuxcnc.org

John

[philba]

One approach is to toss the controller and stepper drivers. Use GRBL and off the shelf stepper drivers - probably less than $60 total. Then you can use a PC, MAC or RPi to send gcode to the GRBL board.

I suppose you could trace out the stepper drivers on the existing controller and wire into them to save a little money (35ish). Then use a GRBL board to drive it. You'll need to understand if the controller is running at 5V or 3.3 and match that in your interfaces.

[gtoal]

> Why not just use LinuxCNC? It's free, open source, very flexible and powerful. There is plenty of help available on the LinuxCNC forum.

My understanding was that LinuxCNC could only drive parallel port devices, eg from https://forum.linuxcnc.org/38-genera...in-every-group :
"If your CNC is connecting to your Mach3 computer via a USB port. That will not be an option in Linuxcnc. If the machine does not have a parallel port connection option."

[gtoal]

One approach is to toss the controller and stepper drivers. Use GRBL and off the shelf stepper drivers - probably less than $60 total. Then you can use a PC, MAC or RPi to send gcode to the GRBL board.

I suppose you could trace out the stepper drivers on the existing controller and wire into them to save a little money (35ish). Then use a GRBL board to drive it. You'll need to understand if the controller is running at 5V or 3.3 and match that in your interfaces.

Yes, if I replace some of the mx3 hardware, there are quite a few ways of making it into a gcode-based machine. But I'ld like to be able to do that without changing the machine and just plugging something in to it that takes gcode in its input and drives the MX3 on its output. That's why I specifically said up front "(and yes, I am aware that I could just swap the MX3 controller for a compatible one that uses GRBL to interpret the gcode, and if necessary I will eventually do that, but for now I'ld like to try the way I've outlined above first.)" because I wanted to head off alternative suggestions like this and find out if there exists, or can be created, an external gcode interpreter that just plugs in to either the USB or jog controller interfaces.

[philba]

OK, I understand your desire. Just remember that each thing you add on creates another failure point.

One thing I don't think you understand is that Mach3 is the motion controller so you will have to provide that somehow. Not an easy task.

Seems like drufel (which is also a motion controller) should have a way to connect to a PC to send the gcode files.

[gtoal]

OK, I understand your desire. Just remember that each thing you add on creates another failure point.

One thing I don't think you understand is that Mach3 is the motion controller so you will have to provide that somehow. Not an easy task.

Seems like drufel (which is also a motion controller) should have a way to connect to a PC to send the gcode files.

I think what you're calling a motion controller, I'm calling a gcode interpreter, i.e. a program which accepts gcode and moves the x,y,z steppers and spins up and down the spindle motor. Like this code: https://github.com/mlpassos/easilogo...code/gcode.ino except perhaps a little more complex. (That was quite a simple implementation.)

Anyway, Drufel definitely doesn't have a way to accept gcode other than, as I said, "load file" in its GUI or pasting it in to the edit buffer. I don't think you can even pass it in on the command line.

I'm not worried about the rather abstract concept of points of failure - in fact this will be more reliable because the Drufel closed source solution is notorious for stalling out with no indication why and no way to resume where it halted, whereas with an open source gcode interpreter/motion controller we'll have some chance of debugging this problem (if it even persists) and fixing it.

[joeavaerage]

Hi,

I think what you're calling a motion controller, I'm calling a gcode interpreter, i.e. a program which accepts gcode and moves the x,y,z steppers and spins up and down the spindle motor

I would not describe Mach3 as a motion controller, nor either as a Gcode interpreter, or at least solely as a Gcode interpreter. It is a GUI/Gcode interpreter/trajectory planner.

The trajectory planner generates numeric P(osition) V(elocity) over T(ime) data in 1ms time slices which is consumed by a motion controller.
The motion controller turns that numeric data into the required pulse streams.

Traditionally Machs parallel port is a motion controller, note the the parallel port driver is a separate component than Mach3 the GUI/Gcode interpreter/trajectory planner.
The Sainsmart is a motion controller, the trajectory data is fed to it over USB and the microcontroller on the Saismart board generates the pulse streams.

LincuxCNC is also a GUI/Gcode interpreter/trajectory planner which is in turn consumed by a parallel port motion controller, not unlike Mach3's parallel port.

I agree with a previous poster that the very intensive and extensive effort to write your own GUI/Gcode interperter/trajectory planner is unwarranted, aside from the difficulty
in reverse engineering the Sainsmart to the extent you can supply the PVT data in the correct format.

I have a VERY poor opinion of Chinese made motion controllers, they never work as avdertised and the Chinese don't give a damn....your on your own.
I would recommend another controller like an ESS......but that rather commits you to Mach3 or better yet Mach4. Otherwise I believe the previous posters
recommendation about LinuxCNC is very good, free, open source, readily available hardware....whats not to like?

Craig

[samco]

Not quite.. Linuxcnc motion controller is a few levels above the printer port. The printer port in linuxcnc is just a simple i/o module.

LincuxCNC is also a GUI/Gcode interpreter/trajectory planner which is in turn consumed by a parallel port motion controller, not unlike Mach3's parallel port.

[joeavaerage]

Hi,
my apologies, LinuxCNC's parallel output is indeed very sophisticated and because its realtime can be induced to do many more
things than a buffered control system can do. My intention was to indicate to OP that as a matter of practice it might be considered
'equivalent' to Mach3's parallel port, although that term 'equivalent' is being stretched somewhat.

The main thrust of my post is that OP is trying 'to re-invent the wheel' here, there are a number of perfectly excellent CNC solutions including
Mach3, or better Mach4, UCCNC, PlanetCNC, Acorn and LinuxCNC. The true limiting factor in his setup is a very lackluster controller.

A good controller like an ESS (with Mach of course) OR a Mesa IO board (with LinuxCNC of course) would put him far FAR ahead of where he is now.
I was not trying to suggest that Mach/Windows was better or worse than LinuxCNC, just that either alternative would obviate the need for him to write
what amounts to a new CNC solution.

Craig

[machinehop5]

ass gas grass

[samco]

I agree

Hi,
my apologies, LinuxCNC's parallel output is indeed very sophisticated and because its realtime can be induced to do many more
things than a buffered control system can do. My intention was to indicate to OP that as a matter of practice it might be considered
'equivalent' to Mach3's parallel port, although that term 'equivalent' is being stretched somewhat.

The main thrust of my post is that OP is trying 'to re-invent the wheel' here, there are a number of perfectly excellent CNC solutions including
Mach3, or better Mach4, UCCNC, PlanetCNC, Acorn and LinuxCNC. The true limiting factor in his setup is a very lackluster controller.

A good controller like an ESS (with Mach of course) OR a Mesa IO board (with LinuxCNC of course) would put him far FAR ahead of where he is now.
I was not trying to suggest that Mach/Windows was better or worse than LinuxCNC, just that either alternative would obviate the need for him to write
what amounts to a new CNC solution.

Craig