![mach3 cambam endpoint of arc differs mach3 cambam endpoint of arc differs](https://docplayer.net/docs-images/57/40302671/images/4-0.png)
If it does, then the zero-offset needs to be adjusted. The motor should not turn when the command signal is at zero. On many of the older drives this is accomplished by adjusting a pot on the drive board, on the newer drives this is normally done via a parameter in the setup. The drive has some provision for adjusting the zero-offset. I am going to go out on a limb here and assume that your mill has DC Servo motors that are driven by a +/- 10 V command signal from the controller. If there is a backlash compensation parameter in the controller, try setting that to zero and look at the result. Apparently on end-of-travel limit, the drives are not disabled by the controller, but rather the command signal is set to zero by the controller. The clue is that the end-of-travel limit should shut off the motor, but the motor continues to drift. This is starting to sound like a zero-offset problem, at the drive level. If nothing else, this tells us the machine is reading the travel correctly and correcting but why does it allow the y axis to wonder?Īnyone run into something like this or know where to go from here? It appears as though the controller picks up on this position change and corrects it but by then the damage is done. Movement got to the position where it changed directions and sure enough the y jumped. I ran it at a feedrate of 1 so I could keep an eye on the y position while it was running. While I was at it I decided to run the program that we've been beating around here for the last few days and see what I could see. I was thinking about disconnecting the sensors to see if they are the source of the drift but was unsure of the result of running it with these disconnected.
![mach3 cambam endpoint of arc differs mach3 cambam endpoint of arc differs](http://www.cambam.info/doc/plus/images/basics/nema23-1.png)
Unit looks to operate via magnets so I put a small piece of metal in front of each sensor and they appear to work as the metal sets off the sensor and the axis walks slowly off the sensor. I took the housing off to see if there was any interference. There is a sensor on the x and y axis that detects the limit of the table travel. :nuts: OK, this is good to know, but what is causing it? After you let off the feed, the motor continues to walk for a partial revolution. In the video you will see that when I change directions on the Y axis, the motor makes a partial revolution in the reverse direction and then goes correctly. I figured while the belt cover was off I might as well see what I can see. Ended that problem.Īs I went out to the shop this morning something told me to check the belt to see if it was loose or worn. I just built a new controller for mine, and used mag scales for the input. What happened to my machine, was the encoders got flakey and it would not cut a correct circle and it would lose position on straight X and Y moves. This should cut the entire circle rather than arc segments. I don't know it it will work or not, but worth a try.
#MACH3 CAMBAM ENDPOINT OF ARC DIFFERS CODE#
You might try the following line of code in place of the 3 arc segments in the above code. That should be correct, but in looking at the Hurco code I could find, it may not use a G90 code. N100 G2 X0.5707 Y1.6711 I1.3118 J1.6711 X & Y are the endpoint of the third arc, and are exactly the same as the start point. N50 G0 X0.5707 Y1.6711 Start point of the circle Two different posts, two different machines and the same problem (different degrees of severity). I thought I might have a problem with my vector art so I went into CamBam and just made a circle and tried it. The problem was not as pronounced as it is on the Hurco, but there none the less. It never made sense to me as the square corners always lined up but the circles/arcs had the problem. Now that I think about it, I had the same issue on my small machine running Mach3 but I just assumed the problem was a sloppy thrust bearing on the Y axis.
![mach3 cambam endpoint of arc differs mach3 cambam endpoint of arc differs](https://docplayer.net/docs-images/59/43651874/images/70-1.png)
If I had a way to confirm the coordinates of the code I could verify weather my shifting occurs at the segment joints or not. It looks like the Y position shifts a few thousandths between the start and end points. Let's say one arc completes at the 12 o'clock position and another one starts at the same position. What it looks like to my untrained eye is that the arc is being broken into segments (that can be confirmed by looking at the code) and the segments do not start where the previous one ended. I checked everything but can't find any differences. I can't remember what I've changed, if anything. I think the thing that bothers me most is that it worked great once and not since then.