Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: maxy on January 27, 2008, 11:13:42 PM
-
We have our system finally setup with Mach3 and when doing test cuts as the machine finishes and moves back to it's part origin it is not going to the exact starting point.
The bit always ends up 1/8 past it's original x position...the Y looks correct...We know it's not hardware...we have calibrated the software and now we are lost on this strange problem.
The DRO's are reading 0,0,0 x y z, but the bit is ending up at approx -.120 past our original starting point. We are not on the limit switches as the test are in the centre of the table.
P.S. I went back and wrote G code for a 5x5 square, and ran it...when i ran that code it was also was not in the correct origin when it finishes, each time it runs it adds just a little more error it seems in the -X direction only.....
This is a servo system, we have checked for back lash and thats not the problem...
Thanks
-
Does your part come out the correct size?
Hood
-
Hi Hood,
As i was saying when i cut the square out it is the correct size, but the Zero position is 0.010 in the -x position on returning home and each time i re-run the program it looses another -0.010. So after 2 runs the entire square is 0.020 i the -x position.
Jeff
-
Jeff
Re-do your code so that it goes the opposite way round the square and see if it is now a +ve error.
Hood
-
Hi All it is a servo system what are you using for motor drivers. Geckos?
abheli
-
Hi, Jeff
Check in your Config, Ports & Pins, Motor Tuning, Are the Step & Dir Low Actives all set the same ? Thy should be if the servo control's are the same.
Some control's are sensitive to this setting and will preform poorly. Set them the same and use Config, Home and Limits, "Reversed" to change Direction as
needed.
May Be It, Chip
-
Jeff,
I would suggest you take an oscilloscope and check the Chan A and Chan B from the optical encoders on your X, Y and Zed axis' to make sure the signals are not noisey. Too much electrical noise could cause missed counts and therefore cause your axis to over-run.
SC.
-
WE Finally solved it on Sunday...and it was the encoder (noisy) causing the added 10thou in the -z direction......THANKS EVERYONE :) :o