[theshed]

I have completed a retrofit on my cnc lathe junking about 20kg of transistors for a wonderful little dual drive - Everything has gone well even for an idiot like me.

Where I am having some difficulties is with cutting arcs repeatedly in a subroutine using Mach3. After about 30 cuts the tool point has drifted by about 1mm. I have checked and double checked the G code and do not believe that that is the problem. I have done a physical tune up of the lathe adjusting gibs backlash in the drive belts and lubricating everything I can think of. I do not think this is noise because it is repeatable every time (and anyway I followed the instructions on shielding).

I was wondering if the drives were loosing counts. My encoders are 2000 line encoders and I am using 4x multiply.

Could I need to retune the motors after all of my adjustments? Would a minor tuning issue cause position drift?

Can I spy on the encoders with a dual drive or does that only work for the single drive software?

I am very pleased indeed with my drive it was excellent value for money.

[Montabelli]

Are you using backlash compensation in Mach3? are you using a counting board like smoothstepper? and one last question, is the drift in one or two axies?

all of the problems I had with Mach 3 and my conversion were attributable to windows counting ability. or perhaps more accurately its interruptibility. since I put on a smoothstepper, I have been able to run at full resolution and have had no more great lurching kachunks from windows getting distracted. I am not however running the dual dc drive.

[theshed]

Hi,

it drifts on both axis by about 0.8mm in 50 moves. I do not have smoothstepper. I rather suspect it might be tuning - I will have a play this evening.

[theshed]

I am finding this tuning business tricky! I have 140v SEM servos. Having had a good long play I end up with


P 1650 I 5700 D 3000 on the x axis giving 11 encoder count error and 36ms settling time

P 1850 I 5700 D 3000 on the Z giving 14 count error and 41ms settling time

These figures are much higher than what I used before but with no huge changes.

One worry is using the graph function the current on one axis does not settle on zero - it flatlines just below.

Am I in the ball park?

[Xerxes]

Losing of the position with drive could be caused by:
-Interference in step/dir lines. Maybe direction signal is not set early enough before step pulse comes.
-Interference in encoder signal.

Also do you use step multiplier? Have you tried setting it to 1x? Or 4x for example? Does the amount of drifting change when you change multiplier?

It's not probably tuning issue if the Integral gain is high enough which will zero all error eventually. You can try rotating motor shaft by hand and see if it fights back to the original position. The tuning results sound ok to me.

[theshed]

Hi

What scope is there for adjusting the step/direction signals? I have set the step pulse to 5 microseconds in Mach3. My parallel port cable is quite long (3M or so) but shielded in the usual way.

The encoders are shielded but are close to the DC wiring. However the Z axis wires are only 0.75M and that is the worse axis.

I have also been adjusting the mechanical parts. The Z axis is heavy whereas the X is very light. There might be some friction in the ballnut - could that cause this problem?

This only happens in arcs a test program running 50 rapid square movement showed no position loss at all.

Many thanks

[Xerxes]

How long is the "dir pulse" setting in Mach3? Try increasing it anyway to see if it affects. Also please try changing step multiplier from DCtool to see if it has any effect (helps to locate problem).

Friction is no problem.

[theshed]

Hi

Sorry I have been on holiday - I have changed the DIR and step pulse without any noticeable change. I have changed the multiplier from 4x to 8x and 16x all no real change.

I am beginning to suspect my computer. The longer the program the greater the error so the problem is linked to time. The computer is elderly, slow and has not got much memory - it also has an onboard graphics card.

I will upgrade the memory and see what difference that makes.

thanks for all the help so far

John

[Xerxes]

Hi John,

If you changed the multiplier from drive and it drifts still same amount, then the problem may be caused by lost encoder counts (but could be also some PC problem, though).

You may try disconnecting motors cables of all but one axis of machine and then try if the drifting still occurs. If it stops drifting, it would mean that problem is electrical interference. Also the fact that running square moves doesn't drift supports the interference theory (only one motor active at a time).

Detailed photos of cabling & machine may be helpful for me to see if there's some apparent problem.

[theshed]

I think I have been stupid.....I had bought and fitted encoders with A+ A- B+ B- outputs but assumed for reasons I cannot now recall that these were single ended - following the instructions (for once) I used only the A+ and B+ connections. The cables are well shielded but do run close to unshielded motor cables at 100v. Am I right in thinking that if I have A- and B- outputs I must have a differential encoder? I take it that might help prevent encoder counts loss? Before you tell me I will also try and shield the DC motor cables...

[Xerxes]

Yes, leave A- and B- unconnected if you have single ended encoder. Unshielded motor cable and floating motor case are the major sources of interference, so shielded cable is a good idea.

[theshed]

I have still not solved this one. Many thanks for your help so far. The symptoms remain the same. A regular and repeatable error whenever I run a program where 2 axis move at once. No error when the program is one axis at a time.

My PC is elderly 950Mhz PIII 256MB Ram running windows 2000. Mach3 set to 25,000Hz - any higher and life slows up.

Servos are SEM 140v brushed DC.

PSU is 100v DC

Separate PSU for logic. All limits and e-stop are mechanical relays with 24v coils.

I think I have eliminated velocity and acceleration settings - the slower the speed and the longer the program the worse the error.

I have had a real go at reducing noise. Encoders are differential and high quality with shielded cable - shield connected to earth (frame ground) at drive end. Motor cables now replaced with good quality shielded cable connected to frame ground.

100v PSU is just 15cm from the drive the DC cables are twisted.

Whilst rewiring the motors I reversed two wires - I switched the encoder to suit - the error in turn swopped from positive to negative on that axis - this must be significant but I can't work it out.

I am very happy with the motor tuning - the motors run quietly with no dithering.

Servos are fitted with high quality industrial encoders with 2000 lines. Multiplier is set to 4 but I have tried 8 and 16 - no difference.

I have varied step and direction pulse from 1 - 5 - 15 and back again with no real difference.

I have switched of cv mode and gone for exact stop - no difference

I have on direction pin on active high and one on active low - could that be it?

I guess noise is the most likely culprit - the axis are talking to each other - where should I look next?

I will try and borrow a more modern computer so I can rule that out but that will take some time.

Many thanks

[Xerxes]

It sounds like motor cables are now properly shielded. Did you also connect motor exterior case to cable shield and drive's frame ground?

One reason could be that the step pulses interfere each other in signal cable. What kind of wiring you use there?

[theshed]

I still haven't managed to sort this out. The problem remains the same. Whenever I run a program where the 2 axis move together I get position drift. Running one axis at a time however fast and for however long is perfect including lots of reversals of motion.

The drift is always consistent i.e. if I run the program twice the error remains the same. The X axis moves in the negative direction the Z axis moves in the negative direction. The X moves a little further than the Z - this appears to be in proportion to the pitch of the lead screw. It seems possible that steps intended for the X have got misdirected to the Z axis - could that happen? Could I have made a mess of loading the dual axis firmware? I did struggle to load the Vsdepi firmware as I tried to load it before I flashed the dual axis firmware but I think I sorted it out.

I have tried every combination of step and dir pulse length with no significant difference. I have changed the multiplier again no difference - in particular the amount of error does not vary.

I have shielded and grounded everything I can see.

The connection between the PC and vsdepi is a standard parallel port cable and in now 2M long.

I am seriously running out of ideas!

Can the opto isolators cross talk? Could it be the ribbon cable between the vsdepi and drive? Any suggestions gratefully received.

John

[theshed]

Sorry got that wrong x axis drifts negatively Z axis positively - drift is proportionate to lead screw pitch.

[Xerxes]

It's not firmware loading problem or in DCtool settings, that I'm certain of. I'm 99% certain its some electrical issue and 1% possibility of firmware bug (however, nobody else has reported similar problem so it would be strange if it was in firmware).

Here is one thing you could try: invert axis direction of one axis/both axes from CNC software and try again. Then observe if the drifting direction has also changed.

It could be step/dir signal crosstalk in flat cables. How long cables do you use?

BTW, can you somehow verify that direction signals stay constant most of the time during arc moves? Too frequent direction reversals could confuse drive's step/dir counters (proper signal timing requirements are in DualDC manual).

[theshed]

The flat cables are only about 150mm long but folded back quite sharply. They are also quite close to the DC HV supply for the drive.

I will try reversing the axis direction and let you know what happened.

I do not have any way that I know of of checking whether the dir pulses are constant in arcs. I am not using a very fast pulse speed and the problem is the same or worse at lower axis speeds.

[theshed]

I tried reversing the x axis and running a test program with 50 lines of curvy code. A direction change every second or so. The error remains the same and in the same physical direction i.e it does not reverse. Does that help the diagnosis?

If I remember rightly the error is not only in arcs but also in any program where two axis move together. I will check that.

In mach3 I have step set at 3 and dir at 10 microseconds. Sorry to be stupid but I do not know if that is ok. I have tried loads of other values without the error disappearing.

I also looked at the flat cable - it is very short - looks harmless!

[H.O]

Hi,
I just read thru this thread and I think there's been a slight misunderstanding (or I've misunderstood).

Anyway, if you DO have differential encoders (ie they output A, A-, B, B-) then by all means connect all signals to VSD, don't leave the complimentary signals hanging. If the problem IS noise on the encoder signals using the differential signals should help.

However, the fact that the drift is always in the same direction is interesting....

/Henrik.

[theshed]

Hi Henrick,

Thanks for the quick responses. I had worked out the misunderstanding as to the encoder wires and all signal wires are now connected - however the error remained the same. The error did reverse direction when I set the dir signal to active low rather than active high.

any thoughts?

John