Strange position/offset problem

More
30 Oct 2014 20:32 #52580 by staviq
Hi.

I would appreciate if anyone could help.

I have this strange problem with homemade xyz l297/l298 based cnc table.
In AXIS window / MDI tab i issue following g codes:
G0 X100 Y0
G0 X0 Y100
G0 X0 Y0
And the problem is table does not end in the same position it started ( stops with about 4mm offset in X and about 45mm offset in Y ).

BUT ( the strange part )

If i issue previous g codes backward:
G0 X0 Y100
G0 X100 Y0
G0 X0 Y0

Table does go back to exactly where it started ? It is impossible, i think, that table is losing steps, because when going backward it would have to do extra steps to cancel the offset ?

My head is currently in a wtf state, any ideas ?

Thanks in advance, and Best Regards.

Please Log in or Create an account to join the conversation.

More
30 Oct 2014 20:34 #52581 by andypugh

And the problem is table does not end in the same position it started ( stops with about 4mm offset in X and about 45mm offset in Y ).


What is the result with a 50mm move?

Is it possible that the scales are just incorrect?

Please Log in or Create an account to join the conversation.

More
30 Oct 2014 21:00 - 30 Oct 2014 21:02 #52584 by staviq
If it would be a scale problem, going from 0 to 100 and back to 0 should still go back to where it started anyway.

For 50mm move offset is about 2mm X and 15mm Y.

Lead screw pitch is 1.75mm, maybe its some kind of floating point error accumulation problem ?
Last edit: 30 Oct 2014 21:02 by staviq.

Please Log in or Create an account to join the conversation.

More
30 Oct 2014 21:19 #52587 by andypugh

If it would be a scale problem, going from 0 to 100 and back to 0 should still go back to where it started anyway.

Sorry, I misread the problem description.
It doesn't sound like a scale issue.

maybe its some kind of floating point error accumulation problem ?

No, if it was that then the problem would have been spotted by other users, surely?
Internally the step count accumulators are all integers.

Can you tell if the X100 Y100 point is the same for both right-hand and left-hand triangles? (ie, is the problem on the way there, or the way back)

The difference seems that it might lie in the direction of the move when both axes are moving.
Could you try a right-hand and left-hand square, ie the same sort of pattern but only moving one axis at a time.

I am wondering about cross-talk between step/dir channels on combined moves, or possibly very marginal power supply to input opto-isolators.

Please Log in or Create an account to join the conversation.

More
30 Oct 2014 23:03 - 30 Oct 2014 23:05 #52590 by staviq
Going from X0 Y0 straight to x100y100

"G0 X100 Y100"

works correctly ( and then G0 X0 Y0 works also correctly, going back to where it started ).

Going from X0 Y0 to X100 Y100 in two moves:

G0 X100 Y0
G0 X100 Y100

incorrectly ends up in about X62mm Y100mm real world position,

then, going back

G0 X0 Y0

incorrectly lands at about X-38mm Y0mm real world position.

Going in 2 steps but the other way around gives the exactly the same incorrect positions ( X and Y error is NOT inverted ).

Basically 1 gcode works fine, 2 gcodes works incorrectly, the error is reproduceable, and not exactly random.
Last edit: 30 Oct 2014 23:05 by staviq.

Please Log in or Create an account to join the conversation.

More
30 Oct 2014 23:10 #52591 by andypugh
If you move a "fast" axis and a "slow" axis both at the same time, then the "fast" axis will be slowed down to match.

Is it all possibly that one of your axes has a much higher (too high) acceleration value?

Please Log in or Create an account to join the conversation.

More
31 Oct 2014 00:14 #52594 by staviq
All axes have the same speed and acceleration and its set really slow at 2mm/s 3mm/ss

Please Log in or Create an account to join the conversation.

More
31 Oct 2014 01:19 #52596 by andypugh
What happens if you comment out the X step/dir lines in HAL, so that LinuxCNC only _thinks_ it is moving the axes?
(then try the same thing for Y)

Please Log in or Create an account to join the conversation.

More
31 Oct 2014 05:35 #52604 by staviq
I think i'm gonna borrow an oscilloscope from work tomorrow and count parallel port pulses to verify for sure whether it's software or hardware issue, since it seems to me like there is no easy answer and the problem is indeed strange at least.

Please Log in or Create an account to join the conversation.

More
01 Nov 2014 08:54 #52640 by staviq
Well,

Pulses are being emitted correctly from software and hardware, and the motor driver step and direction pins connected directly to parallel port pins gives me twice the possible speed and 100% real world position accuracy, ergo it has to be breakboard's fault.

This does not explain non random errors, however if without optocouplers everything works perfectly it has to be optocouplers, so it's time to make better breakout board.

Anyway thanks a lot for help and more or less consciously getting me on the right track, without it i would drown looking for source in configuration files :)

Please Log in or Create an account to join the conversation.

Time to create page: 0.086 seconds
Powered by Kunena Forum