TOS-KURIM CNC Upgrade

[JimJam]

Thanks for the heads up, I did have a bit of an idea that they could be different as I had to make a crossover cable to connect the motion controller to the PC.

I hadn't realised there were two different straight through styles though, something to look out for!

It turned out to be the extended encoder cables that were the issue... I have no idea what I done wrong or why it might have caused it!

The software seemed to be receiving what it thought to be a good signal from the encoder but I got that run away on every axis... removing the extended wire from each one has fixed it! well... I have had each one working on its own, time to connect all three and see what issues I get next!

I also now have three exposed line drivers that will potentially get covered in coolant, so I need to sort that out as well.

[JimJam]

I've finally been able to cut some metal last week!

Programmed up some test cuts, just a simple square with a holes in the center. purely just to check dimensions.

Getting a few strange issues and not sure where to start looking ....

The hole in the center is on size and position, but the flats across the square are 0.8mm undersize in the X and 1.8mm under size in the Y.

I've run various cuts with different size squares and its the same amount out every time.

I thought it was a coding issues as I'm using a MACH 3 post processor in OneCNC and running it on UCCNC, which from researching supposedly normally works.

Or is it more likely a motor/encoder issue?

[Muzzer]

You can presumably set the steps per rev in the motor driver to the wrong value. If you have 1:1 ratio in your machine it keeps the numbers simple (do you have a belt drive, I forget). You may also be able to set the pulses per rev or pulses per mm in your controller.

Good to cut metal but now investigate what is causing this issue. Is it (hopefully) a consistent % scaling error or a random (loss of pulses) error?

If it's a consistent scaling error, you should be able to fix it by correcting the settings in the drive via the software. I don't know Mach3 but there may also be some settings in there. If you swap over the X and Y signals, you will see where the scaling error lies - does it stay with the drive or within Mach3?

[JimJam]

Sorry I wasn't very clear, so I am using the UCCNC software as my controller (not MACH 3) but I used a MACH post processor when generating the code on my CAM software.

Within the UCCNC software there is a setup area where you zero the axis position, and you enter a value to move, then it moves what it thinks is that distance, then measure the actual table travel and enter it into the software and it calculates the distance per revolution. I had to repeat this a load of times on each axis to get it to down to where i wanted it. it worked out at something like 885 steps per revolution or something with a load of decimals after..

that is literally the only setup I have done though. So I may have missed some other important settings, but nothing jumped out at me.

all the axis use belts and are geared up/down ( i haven't actually calculated the ratios though)

On another note, the UCCNC software allows you to write some code directly into it and run it. When I enter a rapid or feed movement on any axis and run it, it travels the distance i have entered. So the issue only occurs when running a program, which is why I thought it may be to do with the CAM post processor... but if that was the case I guess I would see the same discrepancy on each axis and not random.

I will do a bit more investigating and try what you said about swapping the X and Y signals and see what happens

[Muzzer]

It's a good idea to try to calculate the exact PPR from the belt ratio, ballscrew pitch etc. Trying to do it by trial and error shouldn't be necessary and you could end up including backlash etc. That's my view on it but there's probably no right or wrong.

Bizarre that MDI moves work OK but programmed ones don't, given that they both generate g code. You've got me there but one step at a time perhaps...

[Neale]

Might be a missing steps issue, if you haven't done any other setup? The machine has been told to accelerate or move at speeds beyond its capabilities and the stepper motors can't keep up - could be why it moves correctly in air but not when cutting which puts more load on. Try halving the max speed for each axis and halving the acceleration, and see if that helps. If it does, then you can start winding things up a bit to find the limits.

[Muzzer]

It shouldn't be missing steps in a big way, as it's a closed loop servo drive. It should either recover them or go into an error state and stop.

Also, it appears to work correctly in both rapids and feeds from MDI, although the feeds will presumably be loaded when running a program. Having said that, missing steps wouldn't normally result in a good looking part that has a scaling error.

Let us know how you get on with this.

[Neale]

Sorry - forgotten that bit! Trouble with following multiple threads over a period of time....

Looking back over the current problem, though, it is a bit odd if there is the same absolute error on test pieces of different sizes. That isn't a simple scaling (PPR) error. Sounds more like backlash, but that doesn't fit with the observation that internal cutouts are correctly sized. I think that I would do a backlash check anyway, if only to eliminate it from enquiries. Easy enough to do.

[JAZZCNC]

Sounds more like it's following errors to me, I'd be looking at PID tuning the motor to drives again rather than Steps per, if the servo/Drive tuning isn't right none of that matters.

[Muzzer]

That would be mainly down to the integral "I" term in the PID controller. As Dean says, you could get a good looking response - but with an error if you don't tune it right.

I've got a feeling the cncdrive software actually shows you the response graphically but I may be confusing it with DMM? You want a good response without a noticeable overshoot and no bouncing about afterwards (you want it to be "critically damped").

Tuning a PID is a bit of an art. Here's how I do it:
Start by turning I and D down to zero, then increase P until it's unstable and back off a bit. Then dial in some D until it's unstable and back it off a bit. Then fiddle with both until it feels about as good as you can get. At this point you will have a pretty snappy response - but without the I term, you may end up with a steady state error. So now dial in some I until it's unstable again and back off a bit. You may now need to back off the P and D a little more. Finally, you should check to see what it actually looks like.

Naturally, cncdrive show a slightly different method http://www.cncdrive.com/downloads/help.pdf. It's not a perfect art but you get the general idea.