TOS-KURIM CNC Upgrade

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.

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?

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?

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

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...

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.

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.

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.

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.

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.

Quote:

---

Originally Posted by 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.

---

AAh Ok, this sounds much more likely to be the issue then. I am fairly happy with my knowledge on setting up with regards to CAM and posts/coding so was fairly happy that was right.

but with the tuning I literally had/have no idea about what I'm doing! I'm away at the moment but when I get back at the weekend I will grab some screen shots of the tuning software and my settings for you guys to have a look at if you wouldn't mind?

Quote:

---

Originally Posted by Muzzer

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.

---

Sounds good, I will give this a go a the weekend. I did have a bit of vibration develop on one of the axis when it was trying to hold it's position, so that's probably a pretty good indication something isn't right in the settings!!

Most likely too much P or D. Start off with I and D at zero and go from there. The steady state error is taken care of by the I term, so if PID tuning is indeed the issue, that's most likely where your solution will be found.

I finally got another chance to play with the mill, with no success at all so far!

The more I mess with tuning the more I realise I have no idea what I'm doing!

When you say unstable, I assume you are referring to the visual display on the servoconfig software displaying any line that is not a straight one?

I am a bit unsure of the actual shape of the plot I should be looking for as well, from what I've researched on the subject it should be a square up and back down kind of thing?

I have attached a screenshot of the settings I have currently, which I believe are not correct at all but this is the only combination I got to that doesn't result in the motor oscillating back and forward.

I always note the settings when i do stuff like this. Having said that, I also find no trace of said records when I need them. It might be helpful to be able to show you my final values but I can't find jack shit when I look.

The response doesn't look too daft. Ideally you wouldn't get any overshoot or oscillation on this kind of step change. You aren't far off, although the numbers do seem a bit odd. The P value seems very low and the D seems high. The I seems way OTT. You also seem to have a bit of an offset left when the system has settled down. The I would take care of this normally but perhaps your very low P is an issue.

Did you start with P, then dial in some D, then finally some I? It will start to wobble, oscillate, tremble etc if you overdo it and it can get a bit exciting on occasion. Back off about 20% or so to give yourself some margin before trying to dial in the next term. It's a bit of a black art!

I started with everything at zero ( Ap, Ad, Ai, Li) then started with the Ap but anything past 200 made it oscillate like mad. Whereas on the other two motors I think they were around 1000-1500 figure.

I ended up taking the motor off the machine in the end, I got a bit carried away with the settings at one stage and the machine got a bit of a jig on. Hopefully it didn't do any lasting mechanical damage! Having it off the machine shouldn't effect setting it up too much should it?


I guess I will just have to keep at it, try increasing P and backing off the D and I?

When you say it has a bit of an offset, I should be aiming to get the green line back down to zero (red line) and have as little oscillation before that as possible? I think I was getting confused by what I should be looking for. Researching PID tuning for the 100th time seems to be making it a little bit clearer now

Tuning really needs to be done with the motor attached to the machine, as the weight/inertia of the machine essentially acts as a big damper.

What Muzzer said about the basic PID tuning is the basic process.
Increase P until things go unstable, and back it off a bit.
Add some D which should then allow you to increase P.
Then once you find the limits of P and D, if needed you then add some I to reduce position error, but it will make everything unstable, so you then probably have to reduce P and D to get things stable again.

I'm not sure what other settings CNCdrive gives you, but once you've done the above on some controllers, you can then apply Feed Forward / filters to help further reduce any following errors.

Ok nice one, I might get it somewhere near off the machine so it doesn't shake itself to bits, then mount it up again and start adjusting the tuning again.

Thanks for the info on the tuning Muzzer and m_c, I watched a few videos on the process earlier as well and I now at least have a better understanding of what each value does to the tuning and how they relate to each other.

I think the screenshot I previously attached of the settings is the only values you can change for the drives. There may be some other settings in UCCNC control software but I haven't delved into that too far yet.

Odd that one motor goes unstable with Ap = 200 or so while the others manage 1000 or so. Perhaps you could swap a couple of them over to see if the problem stays with the motor.

Unless you are shifting a massive (large mass and / or large force) load on one of them, they shouldn't be significantly different. Have you got similar encoder PPRs in the drive and similar steps per pulse in the controller? It's possible that could change the system gain enough to cause this issue - not sure how that would work without actually thinking it through.

There are also a few parameters in there that I don't recall or understand immediately. At the very least you should ensure they are consistent for all the drives if you want to eliminate this strange behaviour. Perhaps a parameter reset would help.

I've been playing with this again today with the motor off the machine still and got what looks to be a pretty decent (not perfect) tune.

So I loaded up UCCNC just to jog the motor and see what it was like. When I jog the motor it will happily rotate in one direction but when I try the other way it is fighting itself and just judders a bit and doesn't really rotate at all....

Does this indicate it may be a hardware issue rather than the tune?

I will try the motor on another drive tomorrow and see what results I get to start ruling some stuff out.

But could this be down to an issue with the motor or encoder? or does it still seem likely to be my lack of skills with the tuning software?

Sounds more like some kind of hardware issue.

I'd try swapping motors, then drives, to see if the problem moves or stays.

Yes, I'd start swapping over the motor / encoder etc. Sounds like a buggered component or a wiring fault, crossed over wiring etc. Time to go for a process of elimination etc.

IIRC, you fitted your own encoders. Getting those wired up correctly would be helpful. That must be a fairly likely candidate.

I've attached a photo of the encoder just so you can verify it's even suitable for this application..

So the encoder wiring is labelled up as:

Brown: 5 - 24VDC
Blue: 0V Common
Shield: GND
Black: OUT A
White: OUT B
Orange: OUT Z

This is wired to the line driver module to convert to differential signals. I have attached a photo of the wiring info for this, but all it is is ground, A, 5 Volts, and B. so I have this wired up as:

Ground: Blue: 0V Common
A: Black: OUT A
5 Volt: Brown: 5 - 24VDC
B: White: OUT B

From there it is just a standard RJ45 cable that plugs into the drive unit. I have also tested the cables I'm using with the proper tool to verify the wiring is correct.

I have also attached the pin outs for the RJ45 side of the line driver and the servo drive encoder input.

Just noticed after I posted that, looks like I may have the + and - the wrong way around on the A and B inputs from the line driver to the servo drive!

EDIT: Would this actually cause any issues though? or just result in opposite rotation?

Quote:

---

Originally Posted by JimJam

Just noticed after I posted that, looks like I may have the + and - the wrong way around on the A and B inputs from the line driver to the servo drive!

EDIT: Would this actually cause any issues though? or just result in opposite rotation?

---

As long as you've still got the A/B paired correctly, direction is the only thing that could be affected.

And as noted before, you need to be sure the cables don't cross over any of the conductors.

Progress! You may remember a while ago I tried extending the encoder cables with some CAT5 cable I bought which turned out to be the cause of an earlier issue. I used the same cable to make up the RJ45 cables that link the encoders to the drives.

I have no idea why I didn't replace these earlier when I had the other issue, but swapping them out for some bought patch cables has stopped the motor juddering..

I stripped back the outer insulation of a piece of the cable from the reel and every now and then there is a break in the conductor but the insulation remains in tact! which I can only assume was enough to make a contact when I tested the cables but mounting it on the machine must have given it an intermittent connection.

Now back to the tuning!

Well I suppose a smart arse would point out that network cables aren't exactly industrial grade flexible cables, being single core etc. In my own defence, I only used it in my own system within the cabinet for the short distance between the line driver and the DG4S drive.

Good you found the issue in the end. It could have been even more intermittent which would have been even more frustrating. With intermittent faults you can never be 100% certain you've found and fixed the issue.

That cable sounds surprisingly crap if it has multiple breaks straight off the reel. You need to get the whole thing out of the building and into a skip where it belongs before you use any more of it now or in the future.

That video of swarf can only be hours away now - looking forward to seeing it in action!

Yeah, I’ve learnt my lesson there! Out of interest what would have been the best cable choice for this application?

Is there flexible cable available that would work with the RJ45 plugs?

Igus supply pretty much any kind of flexible cable you can think off, however you may want to be sat down when looking at some of the prices.

I suspect it's a bit of a contradiction in terms. As far as I know, the std RJ45 shells for ethernet expect to see single core wires which by definition are not good for flexing. You may be able to buy braided, very flexible cable but how good it is I have no idea.

I managed to get some surplus drag cable for my machine. It typically has multiple bundles of shielded wires of varying sizes, so you can run sensors, encoders, motors, PSUs etc up one cable without risk of interference, in an oil resistant cover. But as m_c says, the price might interfere with your underwear.

Rapid Electronics "stock" Lapp drag chain cable (https://www.rapidonline.com/drag-chain-cable), although that's "stock" as in they will order it for you from Germany. Possibly worth getting the real deal if you want to make a really pukka job, otherwise use multicore shielded PVC cable inside a conduit etc and use the ethernet / RJ45 for the last few inches in the cabinet where there is no flex required.

You weren't kidding, pricey stuff this flexible cable! If I ask nicely the electrical guys at my work might have an offcut of something suitable kicking around.. worth a try!

The motor didn't seem to be the issue in the end, I don't think anyway.

I was still getting the dimensional inaccuracy's when running a program so I went through the setup process again within UCCNC to define the steps/rev. This time I done it over a larger distance where as previously I just used the max travel of my DTI (only about 15mm), this time I just used the closest accurate thing I had at home (50mm slip gauge).

Running the program again, the dimensions were pretty good, 0.15mm of what was programmed, which is most likely backlash to be honest.

A few more test cuts and see what happens over larger/smaller lengths!

Ethernet patch cables which are intended to be flexible SHOULD be made from stranded conductors rather than the single core of fixed cabling. Sounds like you got some that were not. A search on eBay for 'Cat 5 stranded' will find you plenty. Not recommended for repeated movement but it might last until Santa can bring you the real stuff!

Kit

I run Mach3 on most of my machines (Chiron FZ12, Beaver NC5 and Plasma) but recently fitted an SZGH CNC1000 control to the lathe.
I love it for a lathe but not so sure for a mill. Having said that around the same time as I put the SZGH on the lathe a friend bought one for his Mill and he loves it, so might be worth looking at.

EDIT
Ignore my post, for some reason I only saw the first page of this thread but now see it has progressed a long way since then :D

Hi Jim,

I also have a TOS Mill the same as yours apart from mine does have the CNC parts installed.

I’m looking at the feasibility of installing ball screws and servos and wondered if you have any more photos of the conversion?

TIA

Quote:

---

Originally Posted by Muzzer

I suspect it's a bit of a contradiction in terms. As far as I know, the std RJ45 shells for ethernet expect to see single core wires which by definition are not good for flexing. You may be able to buy braided, very flexible cable but how good it is I have no idea.

I managed to get some surplus drag cable for my machine. It typically has multiple bundles of shielded wires of varying sizes, so you can run sensors, encoders, motors, PSUs etc up one cable without risk of interference, in an oil resistant cover. But as m_c says, the price might interfere with your underwear.

Rapid Electronics "stock" Lapp drag chain cable (https://www.rapidonline.com/drag-chain-cable), although that's "stock" as in they will order it for you from Germany. Possibly worth getting the real deal if you want to make a really pukka job, otherwise use multicore shielded PVC cable inside a conduit etc and use the ethernet / RJ45 for the last few inches in the cabinet where there is no flex required.

---

I'm going Cat7 solid core from the control box all the way to the base of the machine. Terminated with custom RJ45 modules either end with 2.54 pins out or jst.
Then short stranded cables for sensors into jst connectors plugged into the modules.
Or something like that.