I'm running Mach3 under vista, and I randomly have one of my axes give up and stop moving while running programs. I'm not sure exactly how MAXNC closes their loops with the encoders/steppers. If the PC is in the loop, then one theory is that somehow the software loses sync due to a lost interrupt and the wrong coils are energized, and the motor can't move anymore.  Sometimes I hear a hum from the offending motor, and usually after 30 or so seconds the fuse pops on the controller.

Anyone else see this issue? I can fix it by hitting reset and it comes back to life. When the axis is out, programs will run normally but the dead axis stays put. Jogging does the same. I can't jog the dead axis.  The DRO will increment / decrement as if it's moving.

Any help is greatly appreciated. I can't believe I'm the only one with this problem.  I'm hoping it's just a timing issue and some settings will fix me. I believe it's a design flaw or misconfiguration issue because resetting clears the problem. (ie, not a hardware failure)

Its definitely not closed loop back to Mach, not sure how the Max NC works though.
Sounds like either the motor is stalling if a stepper or the drive is tripping out and Mach doesnt know.
Try reducing the accel by half and see if that helps.
Hood

I'm going to play with the accelerations tonight. I did have the problem go away this morning by simply disabling my network and other drivers. I hope that was it. I'm increasingly amazed how flaky the MaxNC controller seems to be. Maybe it's my PC, but I am running with a clean install of Vista and nothing else! This is my second controller from them, and I'd think they'd have at least a FAQ or something at least describing this issue and a possible workaround or way to go about fixing it.

Apparently others have had this same issue. C'mon MaxNC! You guys have to be better than this! I drop 6k on the primo setup and I get something that feels like I'm the first user. This poor guy wound up making his own controller. I hope I don't have to do the same:

http://www.machsupport.com/forum/index.php/topic,1373.40.html

So I guess if ANYONE has ever seen a MAXNC CL machine behave in this way, definitely let me know!  I think one thing I'm going to do is probe around and see if it's the MAX controller giving up, or if it's MachIII. This machine has been out for 8+ years, so I don't understand why I seem to be alone in this. Waaaah.

Still the same issue. As a matter of fact, this sometimes happens when the motors are moving pretty slowly and not accelerating.

I'm trying all sorts of voodoo. Next idea tonight is to shorten the printer cable and use the 3 foot cable they gave me instead of the 6 foot one I'm using. I just find it hard to believe that I have to do this after dropping so much cash on a brand new machine.

Same issue with mine for 3 yrs.  I think MAXNC got padlocked by the warehouse leasing company a few weeks ago (another post on a different site) and there has been no response since.  No tax filing either since 2008.  I don't want anybody's company to fail but if true then the public should be aware.

Anyway, I've replaced the controller and tweaked the debounce (Chris seemed to think this might be the answer) plus put a filter on the power supply. 

Same problem, no better.  Also same problem when using the embedded computer as the connected computer so the error has to be in the controller/servo interface.  The ways are clear so the gantry isn't binding. It DOES seem to be missing instructions
and what I'm trying to find more information about something that came from another post that talked about the PIN setup for PIN #10, it said:



PIN#10 NOTE: MOVE ENABLE IS USED TO STOP THE COMPUTER STREAM OF CODES UNTIL THE SERVO
MOTORS CATCH UP. ON TIME-OUT IT WILL PRODUCE A SERVO ERROR.


If I could find out how to lengthen that Time out interval, I hope that might fix it.  I may try going back the the
debounce and setting it much longer or much shorter to see if that has any effect.

The second area that I'm looking into came from the spotty manual from MAXNC and suggested that memory managers like
HIGHMEM.sys or a ??386 memory manager might be the problem.  Will try to disable memory management to see if that's somehow
interrupting the commands over the MODBUS.

Will also look at the wiring guide for MACH3 to see if the setup has any functions to monitor the serial communication.

Will keep you posted if successful.

Probably not himem.sys memory management because same thing happens on the Embedded computer that's not connected to the Windows system.

I'll try it anyway.  When booting the computer hit F12 until you get the DOS screen and then you can disable memory management.  Or edit the config.sys in the root (as per googled instructions).

Do this at your own risk, I'm trying it so maybe you should wait and see if I mess up first.

@ sideris --

The solution to me seems to junk their controller. It's terrible.

What I've done is wire up 2 parallel ports to a G540 controller from Geckodrive. There are just enough input pins on both these ports to support all 4 encoders without adding any sort of 3rd party board.

The only issue with the G540 is that most MosChip based parallel port cards don't seem to go into "epp" mode, which leaves some of the output pins in the "open collector" state. This means that certain functions of the G540 will not work. Namely, the CHARGE PUMP. I'll spare you from my gripes about this, but I solved it by running a different pin from the 2nd parallel port that wasn't one of those open collector pins (D3 in my case) to the charge pump.

The encoders just need to be supplied with +5 volts and the controller with +40v (from an ebay switching power supply), the output of the encoders into the inputs on both parallel ports, and the limit switch connected to the G40.

The end result is that I now have everything running... WITH THE ENCODERS!

I am going to write a "brain" for Mach over the next few weeks that simply shuts down and flags an error if the encoders get out of sync. This is the whole reason to have the encoders IMHO, and not to "close the loop". This should prevent a crash and make the encoders worth their weight in gold to me

Trash that controller! The G540 runs the maxnc so smoothly you wouldn't ever want to go back. I think they had high school interns design their controller back in the 80s with radio shack parts... and they didn't bother to refine the design over the years like normal engineers would want to do either.

ALSO - On the motor controller... they have a solid state relay in there. I had to order another from digikey, but it's the cheapest solution I've ever seen. It works and is pretty good for the price so I'm still using the method. Here it is:

Solid state relay ---> Rectifier ---> motor.

The solid state relay has an LED that you can hook up to the parallel port directly through a resistor (330 ohms in my case).  One side of the AC mains goes into the rectifier directly. The other is switched by the solid state relay.  The output of the rectifier goes into the motor.

This does suck a bit because if the relay is on for even a fraction of the AC sine wave cycle, it's on the entire time. Consequently I can only get it to work with PWM frequencies of 30 hz or less, which doesn't really seem like much resolution.

Maybe one day I'll upgrade to a real motor controller, but it works for now.

config.sys / highmem.sys are from the old DOS days. I'd ignore any help from Chris or the manuals at this point.

I have mine running with MachIII-- the only thing I had to do was disable the CPU clock throtteling in the power management dialogs of VISTA. Some folks seem to do this via BIOS. Just make sure you get a consistant 10khz PWM signal on the charge pump pin. If you aren't, then you have a CPU clock throttling around trying to "help you" be green. In the end it just screws you.

Aside from that, it was pretty straightforward to get everything running in MachIII. At least, after I stopped trying to use their controller. It's just plain flawed.