Loss of Y position on fast jogging.

[Robertspark]

The only thing to add here is that Geoff asked me to have a look at the indicator lights on the Gecko drives (G320X). I only know which one is the X ... the other 2 are unlabelled. One of them the In Position light remains lit constantly when I do a move. The In Pos LED on the X drive is lit when the machine is still, but during a move it flickers. The other one (presumably Y) does not have the In Pos LED lit at all.

https://www.geckodrive.com/amfile/file/ ... uct_id/21/

Bottom of page 7/9

The IN-POSITION indicator (green LED) is lit when the motor is within 2 increments of motion of the commanded position. If the
motor is out of position by more than two increments of motion the indicator will not be lit.

The Warn indicator (yellow LED) is lit whenever the motor is more than 128 counts off of the commanded position. Its purpose
is to give warning that a large following error is probably developing and will result in the drive going into FAULT (red LED) if
measures are not taken to arrest the increasing following error.

[Robertspark]

AvB

Have you read through all of these?

https://www.geckodrive.com/g320x-digita ... drive.html

It sounds like they may not have been setup correctly, UCCNC won't miss a step and it will just issue whatever steps it needs to at the speed it needs to.

Is your power supply large enough, is it stable under load, are your terminals all made off well (yes I'm just guessing but if it aint' working (and you've got 5 pages of thread here) then you need to start at the beginning and check everything from wiring, settings and supplies, as well as investigate noise and any potential cross talk (do the drive wires (output from the serveo drives to the servo motors) run alongside any other wiring.

Yup these are just guesses but only you have all the info from looking at it

I think the first post says that you had to do a bit of wiring converting from Mach3 to UCCNC .... have you rechecked all of the rewire, have you checked the routing of the wiring?

Where in the world are you? (there may be someone close who can have a look at it for you at the moment it seems quite a circular discussion).

[AvB]

Yes thanks Robert - I think we're at the stage as Balazs suggested that we need to do some proper diagnosis. But it's beyond my pay grade. Geoff is hopefully coming over on Thursday with oscilloscope and/ or logic analyser. But also Justin, who made the machine, is also coming over tomorrow so hopefully one way or another we'll sort it out. I'll hold off posting anything further until we have some clear findings.

[Robertspark]

AvB sorry I probably came across as a bit of an arse, but after 5 pages on the thread followers loose interest as they can't do much more.

It would be worth while while you have the osciloscope to check the ouput plot from the UC300ETH and also the output profile of your bob just to make sure that its still square and not changed shape, also for any signal bounce (I would not have thought so).

I'd suggest doing the outlet plots whilst everything is connected under load, get yourself a simple test pattern such as one of these attached which just runs the axis back and forth (note this is in inches {but you get the idea}).

[AvB]

OK thanks Robert. Geoff is keeping an eye on this so he'll take that info. By the way, I am in Australia ... Redcliffe, near Brisbane.

I've just done some more tests to clarify things and since I typed up an email for Geoff about them, I'll paste it in here too.

These tests were all done with the kernel frequency at 400khz. It was set at 200 previously, when the problem was discovered. As per the results I previously posted, the error is massively worse at lower frequencies ... about 5 times greater position loss at 200khz than at 400khz.

Relevant settings are:
Kernel freq 400khz
X and Y axis velocities at 3500
X and Y accelerations at 300 (they used to be 180 in Mach3 but the CV accuracy improved with higher accel, and also my previous tests have shown that this position loss problem gets much worse at a lower acceleration).
Backlash Comp is always off.
Jog speed at 100%

1) REPEATABILITY: Yes, very repeatable. Using 3 repeats of the following test: Start at homed. Jog out diagonally in one move to 500mm (visual, by tape measure). Stop and use PARK to return near home. Run the M925 verify macro. The results were almost identical for all 3 tests: around X -0.02 and Y -0.26

2) DISTANCE: Same procedure as above, varying distance:
At 200mm result is X -0.04 and Y -0.17
At 400mm result is X -0.12 and Y -0.21
At 200mm result is X -0.05 and Y -0.44
So some distance correlation for Y but not completely linear?

3) STRAIGHT VS DIAGONAL JOG
Doing a straight jog from home in Y direction then PARK: result is X 0.0000 and Y -0.0134
Doing a straight jog from home in X direction then PARK: result is X 0.0006 and Y -0.0128
(But note that Park will move it slightly away from the straight X or Y line on return because Park is about 50mm away from Home on both axes).

4) PARK VS MANUAL JOG RETURN
If I don't use Park, but jog back manually from the 500mm point as per test 1, result is X +0.03 and Y -0.01

5) VELOCITY
When the X and Y axis velocities are reduced from 3500 to 1000, the result for Test 1 is X -0.0061 Y -0.08 (so the error is close to proportional to velocity).

One thing I'm really interested in is why the error caused by the use of the Park function is so great. It seems like a very brisk move, no dwell and instant response. What is it in the Park function macro that could induce more of an error than simple manual jogging? I thought that 100% speed jogging and a G0 move would be similar in their response?

Cheers,
Andrew

[Robertspark]

Do you have any data on the servo motors? (model, datasheet, rated RPM?)

I dont know enough about servo drives, I only have one.

Is it possible that the drives may not be seeing the steps at the start and end of the acceleration profile?
The statement in the last post that the issue got worse with less acceleration??

[ger21]

One thing I'm really interested in is why the error caused by the use of the Park function is so great. It seems like a very brisk move, no dwell and instant response. What is it in the Park function macro that could induce more of an error than simple manual jogging? I thought that 100% speed jogging and a G0 move would be similar in their response?

The Park function you are using is a 2017 screenset macro.
All it does is do a G0 move to the position you specify.

It might be a good idea to take the Park macro out of the equation. Instead, try using MDI.

If your park position is in Machine Coordinates, then type this in the MDI:

G53 G0 X## Y##, replacing ## with the actual coordinates.

If not in machine coordinates, omit the G53.

G0 X## Y##

[AvB]

Hi Gerry, it's weird, using the MDI to do the move doesn't give the same result at all.

I turned the kernel freq back to 200 as it accentuates the error (it's a lot less at 400 khz).

Using Park, the test (same as above) gave a result of approximately X -1.0 Y -2.2 position loss.
The same move, but inputing G53 G0 X20 Y20 Z-10 into MDI instead of using Park gave a result of approximately X -0.002 Y -0.013.
That's a huge difference. I don't know what's going on but the Park move is the thing that causes by far the biggest error.

[Geoff_S]

Well, it will be very interesting to get a oscilloscope on this thing !

[Geoff_S]

Sorry for the newbie question - I'm not particularly familiar with the configuration of uccnc. Is there a way to adjust the step/dir pulse width, independently from the kernel frequency ? I'm trying to think of what might cause the behaviour seen by Andrew to get worse with SLOWER kernel frequency...