Hello Guest it is March 29, 2024, 05:53:29 AM

Author Topic: Unexplained estop triggers and other issues on new build  (Read 2686 times)

0 Members and 1 Guest are viewing this topic.

Unexplained estop triggers and other issues on new build
« on: September 24, 2017, 09:22:17 AM »
I have been using mach3 on my friends shop tormach for nearly 5 years now.  I recently purchased a CNC Masters CNC JR for my garage. The CNC Masters controller software is absolutely garbage. I was considering other CNC controller software, but I know mach3 and did not really want to learn another program.

So I decided to build an mach3 controller from the ground up.  Im using mach3 v 3.043.062. using windows xp sp3 os. UC100 usb converter, and a c11gs BOB from cnc4pc. Ill get to the machine specifics in the show and tell section at a later time.  Over all i am very happy with the conversion. Accurate enough for my needs.

One of the issues I am having sometimes when I'm in single step mode using the ALT J function, particularly when operating the z axis in .001 or .0001, the software sometimes just locks up. This usually is remedied hitting the stop button on the program run screen or by cycling the estop reset on the screen. The annoying part is that of course I have to reference all my axises. I have proximity switches from cnc4pc which seem pretty repeatable. Not a deal breaker, just annoying.

Another issue I have is that sometimes while loading or closing G code, this will also trigger a estop. Again, just annoying to reference the axises. I've noticed that I have better luck using the drop down menu instead of the button on the screen to load g code.   

Is there away to keep the axises referenced after an estop has occured. Or is this due to mach3 not knowing exactly where the steppers are after an estop? I realize that if there is a hard limit exceeded, the motors will certainly be out of step.

Again, referencing the machine is just a little annoying. I have checked my fixture offsets numerous times and found them to be spot on using a wiggler. Cant ask for much more than that.

Unrelated to estop issues, I have to enter a G90 command if I desire to give a MDI g0 or g1 command after running a program. again, just an annoyance.

Last but not least, im using a Hitachi wj200 VFD for my spindle. Im using the pwm from onboard C11gs board motor controller to generate the analog output. I have designed the option in to use the original power switch on the mill or mach3 to operate spindle direction. The same options exist for spindle speed too.

One of the things I have noticed is the spindle ramp down time in manual mode vs mach 3 when the spindle is powered off. When switched off in manual mode the spindle stops in accordance with the deceleration I have programmed into it. I have dynamic braking enabled, so it stops in less than a second or so.  While under mach3 control, it nearly takes 2-3 seconds for the spindle to stop at 300 rpm. My observation is that the command to keep the spindle running stays active until the pwm decays. I have played around with the settings in the spindle ramp up and ramp down delays with no luck. Checked the turn relay off after stop command, no change. I am using pins 14 and 16 with the pwm enabled on pin 14. Pin 14 also activates the m3 command and I believe pin 16 activates the m4 command. 

I can live with this issue for now, it just becomes a concern when power tapping.  I primarily use a floating tap holder since there is no encoder (not yet anyway) on the spindle. While tapping, the spindle will spin another couple of revs than expected with out Z feed due to the above issue. While this is taken up by the tapping tool its self, I would prefer to have the spindle stop when I tell it too. This will become very problematic should I ever want to do any ridged tapping. I am currently tapping at 300 rpm with the appropriate z feed. 

Who knows, It could be an issue with the computer or XP OS too. Time for Windows 7??

Hope this all makes sense. Any and all help is appreciated.

I am also willing to accept the phrase "Welcome to the bugs of Mach 3, we have jackets and coffee mugs".

Thanks
Ben

Offline Tweakie.CNC

*
  • *
  •  9,196 9,196
  • Super Kitty
    • View Profile
Re: Unexplained estop triggers and other issues on new build
« Reply #1 on: September 25, 2017, 03:45:34 AM »
Hi Ben,

Just looking at the problems one at a time for now;

Random Estop is often caused by electrical noise – try increasing the Debounce Interval (Config. / General Config.) to 2000. Additionally there may be a similar setting within the UC100 set-up which is the equivalent to Debounce.

If they are not already fitted add the clip-on ferrites at each end of your USB cable.

Try it for a while - did this improve the situation ?

Tweakie.
« Last Edit: September 25, 2017, 07:25:44 AM by Tweakie.CNC »
PEACE
Re: Unexplained estop triggers and other issues on new build
« Reply #2 on: September 29, 2017, 02:06:28 AM »
Hi,
did you try tweakies suggestion? Did it work?

USB cables are quite susceptible to electrical noise. Ethernet cables and termination circuits are very much more tolerant, if you have a choice
to make at some date in the future consider Ethernet for its 'robustness'.

As tweakie suggested putting a ferrite at each end will help. It is often a good idea to put one somewhere near the centre. A ferrite has the
effect of breaking the circuit at least as far as RF is concerned. A long antenna (aka your USB cable) receives more RF energy than a short one,
in fact more than several short ones end on end. Putting a ferrite or even more than one at lengths along the cable breaks your antenna into shorter ones
which is desirable.

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Re: Unexplained estop triggers and other issues on new build
« Reply #3 on: October 11, 2017, 10:29:56 AM »
I had the same problems with a USB-CNC controller and realized that I had used a cheap USB cable by mistake so I swapped it for one of my shielded USB cables and all is well. I will admit that I am so used to MACH 3 I have gone back to the parallel cable set up.
Remember it's always darkest just before pitch black.