CNC Communication Problem

Kirk Fraser

My MaxNC-15CL CNC died citing no communication between the computer and controller. I replaced the printer cable and same result. Duane Degn asked me to post a photo of the circuit board suggesting he or someone may be able to guide me in restoring it to function.

I think it may need to be replaced by a Propeller system. But even using free CNC software on a PC may require dealing with a lot of communication codes in the Propeller program. Nice things are a Propeller can communicate with USB instead of a printer port which are not provided on some new computers, the free CNC software has source code available - unavailable for the original proprietary system, and the Propeller's plenty of cogs and pins to replace the pictured board, depending on how many pins stepper motors use.

T Chap

I had that controller once, nothing but trouble. If I were you I would buy Gecko drives, make your own parallel port breakout cable or board to connect to the drives. This is a board I made that accepts parallel port and USB(ft232rl), so it can run off the on board Prop for USB proprietary applications or it can switch the inputs to parallel port. It is not in a state to send this to you since it would open up a can of worms, but the basic point is, route the parallel port to some other version of step/dir drivers, you will need to rig up the limit switches but that is simple, limit switches may still be in tact on the board you are using now for reference. Mach3 is what I use, easy to configure.

Duane Degn

@T Chap, Kirk's CNC has encoders on the steppers for feedback. Any new drive would need to be able to monitor the encoders (or does this information just get passed back to the PC?).

@Kirk, I don't know of a Propeller based controller to take the place of current controller. I'm planning on using the code discussed in this thread with my CNC machine. Though I'm also seriously considering using a PC with the program Mach3 (as T Chap and others have recommended).

Even if I do use a Propeller to control the CNC, the Propeller board still needs to interface with a parallel port on the stepper driver board.

I'm pretty sure the a parallel port interface is still the norm for PC to CNC communication. I suppose there are likely to be USB to parallel converters but I don't know if your control software would be able to interface with it or not. I believe there are cards which fit inside a PC's PCIx1 slot (I think that's what the slot is called) which allow one to add a parallel port to a modern PC. I don't know how one would go about adding a parallel port to a modern notebook computer.

One reason I asked you to post about your CNC problem here was in hopes someone would be able to offer some diagnostic suggestions.

For example, you should be able to get one of the stepper to move by triggering the appropriate pins on your controller. This would let you know if the controller hardware is in at least some form of working order. I don't know what to suggest to test the PC to controller communication but maybe someone does.

T Chap

The MaxNC controller is a quadrature input, not step/dir. The do have encoders but these are not needed with other drivers, I have replaced the steppers on these a number of times without adding the encoders (using the Gecko drives and Mach3, not the MaxNC controller). I can't remember but the original steppers may unipolar on that machine, so you will need to know what the motor is to add third party drivers. I suggest adding bi-polars, you will get more torque. Add third part drivers, and hack the parallel port cable to work as step/dir on Mach3. This is all easy stuff.

As for diagnostic solutions, I spent more time that I want to admit trying to gett it working. My solution, smash it with a hammer until it was unrecognizable, then learn how to build stepper drivers from scratch talking to guys on cnczone.com. That led to better and better boards, and ultimately the hybrid usb/parallel board that allows the PC to operate however I want it to. A specialized Propeller and GUI set up runs the CNC as a semi auto pick and place from commands via USB, then for milling use Mach3 and parrallel.

Kirk Fraser

A CNC mill consists of a computer hosting a GUI, communication to the motor controller, the controller board, communication to the motors, start of travel switches, the motors (and encoders), and the mill hardware. The MaxNC GUI was nice but being proprietary would take significant reverse engineering to obtain the control codes needed for the controller board and its signals to the GUI. If the full communication grammar were available, then programming a Propeller controller board should be straightforward.

I am not familiar with the Propeller's video functions which might be able to totally replace a PC for the CNC GUI component. I am more concerned with replacing the MaxNC controller board with a Propeller board. With total replacement of that component in view, it seems the communication component could be designed either around a PC USB interface or around the printer port or both. Since modern laptops do not have printer ports but even old Win98 laptops have USB ports, I will choose USB communications.

The signals needed to drive a stepper motor are also currently unknown. Several wires are involved and one should have documentation on what is required for each.

One approach offered by a MaxNC user is to replace the proprietary GUI with the EMC2 which is available for free at http://linuxcnc.org/ although I only recently got KBUNTU working on an old used computer which might be able to run the Linux software. Fortunately the source code is available so the communications component can be understood and interfaced to by a Propeller.

I don't yet grasp why the Closed Loop version of the MaxNC has an encoder as encoders typically have far less precision than the AS5055 and likely less than a stepper motor by itself. So does the encoder just verify the motions of the stepper? Sometimes when operating the MaxNC I found it would get into states where the motors had to be reset, perhaps the encoders helped detect when a stepper went off alignment?

LoopyByteloose

You might try LinuxCNC.org to get some additional help. Even if your PC is loaded with Windows, a LiveCD of Linux can be used just for CNC support and a lot of people have climbed on the bandwagon because it is both Open Source and doesn't require you to fully commit a computer to just being a CNC machine.

I don't think you should try to have the Propeller provide the video output or the keyboard input. But you might easily have a Propeller actually provide an alternative controller for your steppers, and it can handle USB serial as 3Mbaub if you must. And it doesn't seem that you really require encoders unless you are doing extremely critical tolerance micro-stepping. Having both encoders and steppers is somewhat schizophrenic... which do you want to take the lead in precision?

You computer can have a day job as a Window OS computer, and easily be redeployed for its moonlight job as a Linux CNC server whenever your muse comes calling.

Driving steppers and reading encoders are pretty easy with the Propeller. With X, Y, and Z axis you only need six channels of communication and they might all take an individual cog to enhance performance. That leaves one cog for serial i/o, and one left over to monitor and co-ordinate the whole parade.

Go Linux and Open Source for this. Sometimes proprietary products get just plain wierd and have no accountablity for doing things in an odd and overly ambitious fashion.


Try LinuxCNC.org for EMC2 software

and below are two links, one is a guy that claimed to be trying to put a Parallax Propeller in use with his CNC.

Searches for LinuxCNC and the Propeller keep turning up a project to make a six-blade boat propeller... argh.

Try alternative seaches with "EMC2 Parallax Propeller" to find active projects.

http://forums.parallax.com/showthread.php/129853-Propeller-gcode-interpreter-for-CNC-and-3D-Printer

http://forums.hackaday.com/viewtopic.php?f=5&t=3625

LoopyByteloose

Historically, it seems this was once done.. but the code was lost in a computer failure.

Here is another productive thread that was located looking for "gcode interpreter Parallax Propeller".

It might be that will a bit of enthusiasm, this might be revived as a collaborative project. Interest seems to have died off in 2010 in Parallax Forums. But DIY CNC is alive and well, and maybe more people comprehend how to apply gcode provided by LinuxCNC.org

http://www.cnczone.com/forums/group_projects/11459-hardware_gcode_interpreter-3.html

http://linuxcnc.org/docs/2.4/html/gcode_main.html

LoopyByteloose

I suspect the biggest obstacle to doing this project is creating a parser in the Propeller for EMC2 gcode (I suspect that not all gcode is the same).

One alternative is to port the Arduino GCode interpreter to the Propeller, or if available soon, the large RAM space of the Propeller 2. Arduino is really C code that has a hidden the C by hiding the 'main( )' away from the user.

Or one can start from scratch...
Fortunately, Linux has some good free tools, included YACC to create a parser and generate code in C.

C is perfectly acceptable for use with the Propeller, there are a couple of versions GCC and Catalina C.

The remaining code would be the motor control system.

https://www.linux.com/learn/docs/ldp/587-Lex-YACC-HOWTO

Kerry S

The original MaxNC controller used 2 parallel ports for control with 4 lines per stepper for quadrature control. Those were open loop systems. The current closed loop style (CL machines) use a single parallel port and standard Step/Direction signals for control. The encoders feed back to a Pic16F84A micro controller and are used to verify that the motor is moving correctly and will initiate a fault condition if it falls behind, loses steps. The encoder inputs are not available on the parallel port.

The pinouts for the various controllers can be found here: http://www.maxnc.net/category_s/1876.htm

One of my CNC guys is very interested in learning the hardware side of CNC control systems so we are currently working on a training program for him using one of my extra MaxNC CL controllers. First step is to simply use a propeller board, and the 3 axis CNC example in the object exchange, to get it running in place of the Dos PC control software. Next step will be to remove the Pic16F84A controllers and replace them with breakout boards (there is one Pic for each motor/axis) to allow us to take the encoders into the propeller for position monitoring. We may even eliminate the Pic completely and have the Prop run each axis in a cog using 6 I/O pins each ( 4 quadrature outputs + EncA, EncB). That leaves enough extra pins for the various other functions.

Note: MaxNC sort of cheated with the steppers. They are 8 wire motors wired in unipolar mode so you only get to use 1/2 of each motor winding at a time (one side for each direction).

If the controller is not communicating though that is a bad sign. Have you verified that you have power going through the on control circuit breaker? I had one of those go bad and even when 'reset' had no power to the board. If not that then you may have lost one of the two voltage regulators or the control side power transformer.

As others have stated it would be easy to simply replace the controller with some Gecko drives and either EMC2 (Linux CNC now) or Mach3 (windows) for control... but where would the Propeller fun be in that?

LoopyByteloose

I am a bit concerned that the Propeller 1 does not alone have enough RAM to adequately store all the choices of the EMC2 gcode. The Ardunios appear to be using larger capacity ATMega chips to work around this.

All is not lost though. You might be able to use PropForth or Tachyon Forth on the Propeller with an SDcard providing an extended Forth dictionary memory. I don't think pfth Forth deploys the SDcard in a way that the Forth Dictionary can search into it.

And all Forth solution on a Propeller 1 with SDcard wouldn't be very difficult. And if you discovered that you didn't require the whole gcode specification, it would be easy to optimize the important codes to the hubRAM for better performance. Cogs running the stepper motors might run independent of the Forth interpreter in PASM and just exchange motion instructions in an organized manner.

Kerry S

Loopy Byteloose wrote: »

I am a bit concerned that the Propeller 1 does not alone have enough RAM to adequately store all the choices of the EMC2 gcode.

If you look at the MaxNC system they have a very limited sub set of the standard G-Code that is supported. If you stick with the functions that would actually be used on a MaxNC desktop Mill/Lathe the Propeller should have no problem with handling the various codes needed.

In fact the project on the object exchange: http://obex.parallax.com/object/85 is very close to having all of the functions that the MaxNC software provides.

MaxNC - Mill

G00 Rapid move
G01 Feed controlled move
G02 Clockwise arc
G03 Clockwise arc
G04 Dwell
G20 Inch mode
G21 Metric mode
G43 Activate a tool height offset
G49 Deactivate tool offsets
G40 Radius offset cancel
G41 Radius offset left
G42 Radius offset right
G43 Tool length compensation active
G49 Tool length comp. cancel
G61 Switch detect command
G53 Machine Coordinate System
G90 Absolute mode
G91 Incremental mode

Command Variables:

Fxx feed rate (speed)
Hx Tool height offset #
Dx Tool radius offset #
I x.x Distance in X to center of arc
J x.x Distance in Y to center of arc
Sxxxxx Spindle Speed

M00 Program stop
M01 Optional stop
M2 End of Program (without reset)
M3 Spindle Start
M5 Spindle Stop
M6 Tool Change prompt (this can be done with an M00 hard stop and a comment line)
M8 Coolant on
M9 Coolant Off

M30 End of program and reset
M99 Repeat program

LoopyByteloose

I strongly suspect that this would be easier to code, debug, and operate in Forth on a Propeller. And the user might just learn a heck of a lot faster.

I really need to read the OBEX zip file, rather than speculate. But...

If the OBEX object defines the G codes in PASM, they might be directly portable to Forth. The operator could either have a stream of G codes fed via the USB serial or could have a second serial port do so with the USB serial monitoring what the Propeller is doing.

I do see that floating point maths is included.

Kirk Fraser

It's interesting how when downsized one must prioritize needs for self sufficiency just to get time for the important long term stuff. Since I have another project for "Propeller fun" which may make it to a product someday, I must conserve time spent on restoring my CNC which is only a building block needed for my project - if needed I could go to a machine shop. Kinda like a kid's game where everything must be mostly balanced for time and money. Then when something doesn't work it's all the more frustrating. So with the options discussed above, it looks like a Propeller could make a nice controller and people are working in that direction but it will take time compared to getting a Gecko drive and an existing software like Mach3 or Linuxcnc.

Another thing about prioritizing work is you can peck at something - plunge in for a while then fall back, do something else, then come back for more. So for now I have KBUNTU working and thus it's easy to pick exploring Linuxcnc next. If it looks good then the decision between a Gecko and a Propeller will be explored further. I'm guessing a Propeller solution has both less expense and more staying power compared to Gecko based on the demise of the original MaxNC company.

Thanks to everyone for the information.

T Chap

Gecko versus Prop? What are you trying to compare here? The gecko is a driver that accepts step and direction and moves the stepper. The software on the PC does all of the decision making on sending the step and direction. The Propeller is not a good option for receiving step and direction and turning on mosfets, that is the job of a mosfet driver IC, no point reinventing the wheel here. There are multiple mosfet drivers for steppers out there for cheap. The Gecko just allows you to not have to build anything, just buy the driver, connect the inputs to your parallel port. Now, trying to use the Propeller as a standalone Gcode processor which includes all the various interpolations involved, then either managing the mosfets or driving a third party (Gecko) stepper driver module, that is a heck of an undertaking. If you just want to get your Max CNC running, the cheapest simplest way is to

Get Mach3 free to run up to 1000 lines
Get any off the shelf stepper driver
Connect the parallel port to the drivers
Rig up your home switches to the parallel port(5V pullups on the switches)

This is an afternoon project. But you should replace the uni motors with bi polar.

LoopyByteloose

Well. It seems that if the CNC needs to be up and running to meet other more important goals, it is a matter of commiting to some system that is open-source and rebuilding accordingly or buying into another software package that takes generic hardware.

It would be great to see the Propeller develop a board to the point that you just plug it in and use it with what you have. That seems to not be a current reality.

The big advantage with open-source in the CNC is that you have a large user community that will help you with the learning curve. And you won't get pushing into a corner that you have to buy your way out of that proprietary systems tend to create.

It seems you have to choose between EMC2 and Mach3 according to how big a shopping list you have and you comfort with the support via generic parts.

Gadgetman

A bit late to the discussion, but...

As far as I see it, a CnC milling system needs 4 component to work:
1. CnC hardware(rails, mechanics, spindle, all the stuff that goes CLANG when you hit it with a spanner)
2. Motors and Switches.
3. Onboard controller of some sort.
4. Controlling computer running some sort of Software.

In your rig, the controller is dead and the Software doesn't work with anything else.
The only real solution is to dump the loss(controller and SW) and find something that can replace them that's a bit more open and documented.
There's plenty of Arduino-based CnC-controllers. Find one that can handle the number of motors in your rig.
It's helpful if it supports limit switches, but it's not essential.
(you can hook switches like that to a relay that cuts power to the CnC mill altogether if needed.)
Encoders aren't used on Arduino-based controllers. Maybe because the Arduino is better capable of keeping track of the tool's position than the PC with a rather limiting Printer port connection?

As long as the controller can take G-code, you can use just about any 3D modeling program in any OS of your choice. That's the neat thing about standardised protocols and file exchange formats.

My not-yet-finished ShapeOko uses an Arduino Uno and GrblShield v4 which only supports 3 axis, but other shields can support more.
This one supports 4:
http://www.buildlog.net/blog/2011/08/stepper-driver-arduino-shield/
And both works with the GRBL opensource code.