Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: armitage on January 23, 2012, 01:48:04 PM
-
Hello,
I manage a student fabrication shop at Hampshire College and four or five years ago a student converted one of our manual Bridgeports to CNC run with Mach3. I have no prior experience with CNC and haven't been able to dedicate much time to working with this one, but I'm trying. The student did an impressive job considering he had no prior experience with this sort of thing and was completely self guided. Not everything worked out quite right including being able to have MPG control on only one axis at a time, and, of greater significance, he was never able to get the positional feedback system (whatever that's called) working. Fixing that is more than I can probably take on at this point but I can't ignore a new problem we're having.
For a while now if I rapid in both axes simultaneously one of them will unpredictably stall and won't more again until I stop moving the other axis (and of course it loses its position). I have not had this happen when I am feeding a lower rates. Recently, after zeroing on a part and starting to run code the machine would go to the wrong Y starting operation position, and (after stopping the code) when I hit "Go to Z" it would go to a position offset from the part origin. Sometimes it would do the same thing (to the same position) on repeated attempts and sometimes it would offset by even greater amounts. This primarily happened on the Y but then started happening on the X as well. Now, it makes sense that this might happen like it does on the manual rapiding since it is rapiding in two directions at once, but the odd thing is that it hasn't happened (except for possibly once) while in the middle of running code (even though it rapids multi-axis for tool changes and such). Also, when it happens during manual rapiding you can hear the motor complaining as long as you're holding the jog. I don't ever hear this while running code.
I may be leaving out some relevant details, but does anyone have any suggestions about where this problem is coming from?
Thanks,
Glenn
http://lemelson.hampshire.edu/
http://www.hampshire.edu/academics/index_lemelson.htm
-
Sounds like your velocity and/or acceleration is just on the edge, try lowering a bit and see.
Hood
-
Glenn,
Are you using servo's or steppers on the mill?
RICH
-
The machine has steppers. A student had the idea of reducing the velocity and it hasn't seized up while rapiding since then. We haven't run code yet though because we're having a new problem. When doing reference all home on start-up, when the Z switch trips, the reset button lights up and gives a Limit Switch Triggered message. My student wondered if it had to do with the velocity being reduced, but changing it to different rates has not effected the problem.
Any thoughts on that?
Thanks for the help.
Glenn
-
What is your Debounce Interval setting currently set at ? (upper right of the Config. screen)
Increase it buy 500. If that helps, then decrease it until the problem reoccurs, then increase it by 50.
Could be a bouncing contact inside the switch.
Russ
-
Russ,
It was at 14, I changed it to 500, but it made no change in the problem.
Glenn
-
Is the limit tripped constantly even if you are away from the switch? If it is then the most likely are the switch is broken or the wiring has come loose.
Hood
-
No, I can reset and manually move all axes.
-
Ok then it does sound like a bouncing switch, try 2000 or even 10000 and see if that helps but if it does, replace the switch as soon as you can as its better to have as little debounce interval as possible in my opinion.
Hood
-
So I just played around with the debounce. Setting it to a much higher number I could see that it was hitting the switch and then reversing direction for a while but even up to 10000 it would still trip the reset on the way down. The higher the number the great the distance it would go down.
What's it all mean?
Glenn
-
Switch is likely the issue, try replacing it or if you can get to the contacts (unlikely) try cleaning them.
Hood
-
How could it be the switch if the switch is clearly being activated (causing the software to tell the motor to change direction) and the reset isn't tripped until the Z has moved a distance away from it?
Glenn
-
By setting a high debounce interval you are making Mach ignore signals that are shorter than that length of time, the higher the debounce setting you have the lnger the signal duration Mach will ignore.
Simple way to see, if your switches are normally closed (should be for safest option) then disconnect the wiring from the switch and short it together, start homing and open the wres and leave them open for a while and see if the limit trips, if it doesnt then you have confirmed its a bouncing switch. Remember to put them together again to stop the axis backing off :)
Hood
-
Hood,
The switch is NC and I 've tested it as you suggested. I guess I don't understand what's going on because the switch works when tested for continuity. When I start homing with the wires shorted the Z moves toward home and when I pull the wires apart it reverses direction, and when I put them back together again it trips the reset. I also experimented with different debounce setting with no apparent change. What exactly does that tell us?
Ever been to Penicuik? I've got some friends there.
Glenn
-
Can you attach your xml, will look to see if there is a config issue.
Hood
-
Here it is. I'll be done for the day soon.
Thanks for all your time.
Glenn
-
Dont see anything wrong in the xml from first looks, do you have a spare input on your breakout board that you could connect the Z switch to and reconfigure Mach for it?
Hood
-
I will have to look into that. Again, I'm pretty ignorant about the electronics but I'm trying not to be. I'm using a Bob Campbell breakout board and I've attached a photo of it. Can you tell if there's a spare input?
-
Hood,
A student discovered the problem. Our Y axis homing switch was damaged and I guess was constantly in open position and causing the malfunction. The student assumes that when homing the machine just activates one switch at a time so the Y switch break wasn't detected until that switch was activated after the Z had finished its operation. In retrospect it makes complete sense. He simply tested by separating the wires from the broken switch and the homing operation continued fine after the Z homed.
Thanks for all the help though. It's all a learning experience.
Glenn
-
Glad to hear you found it :)
Hood