Freezing during G code run

[JW]

PMDX,

I have been using the 422 with mach4 for a few months now. It has been running well except for a problem with the spindle speed control (407) a few months back (earlier post). I am now having a problem when I run G code. The G code will begin to run and then freeze in seemingly random places. At this point, I am unable to stop the run or to disable (mach4 not responding with a corresponding unable to disable-communication error in the history).

I have tried with two different mach4 builds with two different pmdx vers (2236,2238 and 0.17.86,0.25.111) with same results. I have tried two different G code loads (both which I've run error free multiple times with this same setup before). I have tried with two different computers (both running the same version of mach).

Jogging of the three axis is still working fine. Of note, when I run the G code with the stepper drivers depowered the g code seems to run through ok.

Thanks,
-Jim

[Bob at PMDX]

Well, the history file that you sent shows our plug-in reporting a communication problem between the PC and the PMDX-422.  Since this happens at seemingly random times the most likely cause is noise corrupting the USB transfers.  That is presuming you are running our plug-in build 0.25.111 and Mach4 build 2336 (and letting our plug-in update the firmware when it asks to).

A quick aside, as I don't think this is your problem. You mention Mach4 builds 2236 and 2238 and our plug-in versions 0.17.86 and 0.25.111.  I presume you meant Mach4 build 2336 instead of 2236.  Our plug-in version 0.25 111 will run with Mach4 build 2336, but there was never (to my knowledge) a Mach4 build 2236.

A few questions:

(1) Since you say the system has been working for 2 months and now is having this issue, has something changed with the machine and/or control electronics?  Wiring routed a different way?  Control box mounted in a different location?  Actually cutting parts instead of cutting air?  Machine moved to a different place in your shop?  Other machines added to your shop, or other machines now running that were not running before?

(2) You said you tried running with the stepper motors powered off and did not see the freezing issue.  What about the VFD?  Was the VFD running during this test when the stepper motors were un-powered?

(3) If the VFD was also powered down during the test mentioned in (2) above, then please try the test again with the stepper motors powered up and the VFD powered down.

VFDs can generate a lot of electrical noise and that *may* be an issue here.  In general you want to keep the VFD as far away from the other electronics (PMDX-422, etc.) as possible.  And route the VFD power and motor wiring as far from the other wiring as possible.

Bob

[JW]

Bob,

Thanks for the reply. I had a chance to test some more tonight. Good news is the stepper motors are running fine with the 422. With the VFD unconnected, the stepper motors worked as advertised during the same g code run.

The setup is indeed 2336 with 0.25.111. Like you say, the issue seems to be related to the VFD and possibly the 407. I currently have the VFD on/off/rev signal supplied by the 422 via an off board relay. The 407 only controls the speed signal to the VFD (the 407 run light is continuously on - prior post).

More info...The last couple of times the g code has frozen is the line just following a spindle start/speed command. When this occurs, using the stop or disable commands through mach will not stop or slow the spindle. When I use the e-stop (connected to both VFD and 422) the motor will stop and the 422 receives the e-stop condition but when I reset the e-stop the motor will start right back up to the speed selected prior to initiating the e-stop. I was under the impression that an e-stop condition to the 422/mach would direct a spindle off/baseline speed command? At this point If I try to direct a spindle stop through MDI, mach will stop responding.

The VFD, control electronics, and wiring have not been moved since first run and no new equipment in the garage. I will take a good luck at my VFD wiring and settings to make sure they are not causing the problem.

Thanks again for all the help!
-Jim

[JW]

Bob,

Update:  I put on a new motor pulley (different diameter), re-calibrated the VFD analog voltage input, calibrated the 407 max rpm pot, and now everything seems to be working normal. My previous settings for the previous size pulley (VFD, 407, mach max spindle speed) may have caused the problems.

Thanks for the help!

-Jim

[JW]

Bob,

Spoke too soon...The problem is back again at a random point in the G code (albeit a bit further into the G code when it happened last). I'll try to reroute wiring to try and rule out any noise issues. Is there anyway to diagnose communication issues with the 422? I have tried two different computers so I don't believe the issue is in the usb hardware on the primary computer.

Thanks,
-Jim

[Bob at PMDX]

Sorry for not replying sooner. It seems I'm not getting all of the forum update notifications that I should.  I'll have to go back and re-read the thread and try some experiments on my system here to try and see what might be going on with EStop and the spindle starting up as soon as EStop is removed.  Meanwhile...

I am still troubled that the "RUN" LED on the PMDX-407 is always on.  That may or may not be related to your current issues, but it still ain't right.

Unfortunately, electrical noise induced USB communication errors do not necessarily indicate faulty USB hardware.  It *appears* that the electrical noise puts the USB bus (or one or both endpoints) into an unrecoverable state (short of unplugging the USB device and plugging it back in to the USB port).  Testing workarounds for this is difficult because we cannot reliably recreate this problem here in our lab.  I guess we need a bigger VFD :-)

Bob

[JW]

Bob,

Second update: I think I can safely say the problem is gone. I have run a few thousand lines of G code trouble free. The electrical noise seems to have been the culprit. I rerouted the power lines and ensured plenty of clearance on all signal wiring (VFD and stepper motors).

I think the E-stop problem was due to the fact that the communication was interrupted. The E-stop signal to the 422 is working as advertised now (spindle signal off, RPM to 0 once reset).

As always, thanks for the helpful and timely advice!

-Jim

[Bob at PMDX]

Glad to hear it.  Careful routing of power wiring, specially the VFD, can make a world of difference.

Bob

[it_guy]

After Months of having no issues, I too started to have this problem (not to mention uninstalling mach because of crashes and losing my mach configuration and having to reconfigure my machine - my fault BTW -  I was unaware that a firmware update was release and I jumped the gun).

Anyway,
2 Days ago, my machine started to display this same problem out of nowhere. I was pulling my hair out at this point.

I came across this post and re-routed the USB cable from the machine to the computer, much easier than moving the router cable. I went from having the machine run 100 lines of code to running about 400. Re-routed again and ended up using ferrules on either end of my USB.

Fast forward to Today,
Ran 16,000 lines without missing a beat. I hope this helps anyone else with a custom built machine that does not really have the option to reroute their VFD/Router cables.

I will be buying more ferrules today...
V/R
Mike

[Steve Stallings]

Trying to control noise in CNC systems is an art form and there are many different paths to take, but I have not heard of using ferrules. Perhaps you are referring to ferrite cores.

Ferrite cores on the USB cable may help, but putting a large ferrite core on the output of your VFD will likely help much more.

You can see a variety of available cores here:

http://www.digikey.com/product-search/en/filters/ferrite-cores-cables-and-wiring

Here is one example that is probably suitable for use with VFDs up to 5 horsepower.

http://www.digikey.com/product-detail/en/LFB360230-300/240-2287-ND/703473

All three of the power wires to the motor should go through and around the outside and back again in order to make a one turn loop.

In difficult cases you may need to do the same thing on the input power to the VFD.

Where possible the power wiring from the VFD to the spindle motor should be shielded and the shield of the cable connected to the safety ground terminal on the VFD.