[closed] FreeCAD path, strange movement in Z axis

More
5 years 6 months ago #204630 by andypugh

ikkuh wrote: If you look at the DRO in the video you can see that right after the first G1 command the DRO goes to -0.1 But the spindle itself didn't move at all in the Z direction, it is physicaly still at 5 (in this case, I changed the gcode file a little).


Right, this sounds like hardware / config.

It seem that the Z axis might be stalling. Try reducing the MAXACCEL value for Z. Initially by a lot, ie divide by 10. Just to see if that makes a difference.

Please Log in to join the conversation.

More
5 years 6 months ago #204642 by ikkuh

andypugh wrote: Right, this sounds like hardware / config.

It seem that the Z axis might be stalling. Try reducing the MAXACCEL value for Z. Initially by a lot, ie divide by 10. Just to see if that makes a difference.



These are the values now. Not sure how low acceleration should go
Code:
[AXIS_Z] MIN_LIMIT = -200 #0 MAX_LIMIT = 0.01 #541 MAX_VELOCITY = 15 MAX_ACCELERATION = 20 [JOINT_3] MIN_LIMIT = -200 #0 MAX_LIMIT = 0.01 #541 HOME = 0 #POSITIE NA HOMING HOME_OFFSET = 0 HOME_SEARCH_VEL = -17 HOME_LATCH_VEL = 2.5 HOME_SEQUENCE = 1 HOME_USE_INDEX = false HOME_IGNORE_LIMITS = false MAX_VELOCITY = 18 MAX_ACCELERATION = 25 TYPE = LINEAR SCALE = -400 STEPGEN_MAX_VEL = 18.0 STEPGEN_MAX_ACC = 28.0 #FERROR = 0.0051 MIN_FERROR = 0.0025 DIRSETUP = 100000 DIRHOLD = 100000 STEPLEN = 22000 STEPSPACE = 22000 DEADBAND = 0 P = 1000 I = 0 D = 0 FF0 = 0 FF1 = 1 FF2 = 0.00013 BIAS = 0 MAX_OUTPUT = 0 MAX_ERROR = 0.0127

Full .ini file at: git.cnckloon.nl/CNCZone/mesa_2019/raw/br...wZaxis/mesa_2019.ini

Please Log in to join the conversation.

More
5 years 6 months ago #204653 by andypugh
It's odd that your limits are different for joint and axis, if this is a cartesian machine. But it isn't likely to be the problem.

Your acceleration is already rather low. Acceleration of 10/s * velocity is more common.

So, try reducing the max velocity instead.

Also, listen very carefully. Can you hear the Z axis stall?

Can you definitely jog down to -0.1?

Please Log in to join the conversation.

More
5 years 6 months ago #204763 by ikkuh
It was the G43 command.

Somehow there is something wrong there. Maybe it is one of the gmoccapy settings.

Thanks for all your help, it was quitte an experience.

Attachment not found




forum.linuxcnc.org/41-guis/29398-semi-ma...es-in-gmoccapy#60521

Please note, that gmoccapy takes care of its own to update the offsets,
sending an G43 after any tool change, but not in auto mode!

wiki.linuxcnc.org/cgi-bin/wiki.pl?Gmoccapy

Please Log in to join the conversation.

More
5 years 6 months ago #204764 by andypugh
That doesn't make sense.

If you have a G43 between the two Z moves, and the tool length in the table is exactly the right value, then you might see no Z movement.

But if there is a G43 and _then_ two Z moves, the Z should move.

Please Log in to join the conversation.

More
5 years 6 months ago #204766 by ikkuh

andypugh wrote: That doesn't make sense.

If you have a G43 between the two Z moves, and the tool length in the table is exactly the right value, then you might see no Z movement.

But if there is a G43 and _then_ two Z moves, the Z should move.


The G43 was early on in the program, before the G1 moves.

I removed the G43 from the program and everything works as expected.
Will try to find out what is going wrong. But it does like G43 is the guilty command here. The z-axis would move in LinuxCNC's idea but it was just the offset that was stored in G43 (and that kinda works out with the numbers, G43 offset was 21.43 mm and that was about the amount of space that the bit was positioned above the spoilboard). The tool gets measured with a toolheight sensor every time I run the program and gmoccapy stores the offset in the LinuxCNC tooltable.

Please Log in to join the conversation.

More
5 years 6 months ago #204805 by jbraun
Break the problem into pieces without red herrings?
Code:
G17 G54 G40 G49 G80 G90 G21 G54 M5 M6 T1 G43 H1 M3 S8123 G0 Z6.000 (G01 Z-0.1 F900) M02
So running the above code stops the tool 6mm above G54 Z0 ?
But rerunning with the brackets on the 2nd last line doesn't stop the tool at -0.1mm ?
ooops meant to say without the brackets

Please Log in to join the conversation.

More
5 years 6 months ago #204806 by ikkuh

jbraun wrote: Break the problem into pieces without red herrings?

Code:
G17 G54 G40 G49 G80 G90 G21 G54 M5 M6 T1 G43 H1 M3 S8123 G0 Z6.000 (G01 Z-0.1 F900) M02
So running the above code stops the tool 6mm above G54 Z0 ?
But rerunning with the brackets on the 2nd last line doesn't stop the tool at -0.1mm ?


Exactly, that is what is happening.
Code:
G17 G54 G40 G49 G80 G90 G21 G54 M5 M6 T1 G43 H1 M3 S8123 M7 G0 Z6.000 G0 X-0.100 Y536.751 G0 Z4.000
=====> Z physicaly goes to 4 as it should
Code:
G1 X-0.100 Y536.751 Z-0.100 F900.000
Z should now be physically -0.1 and under the surface of the spoilboard, but it is still physically 4 as was set by the G0 command. The DRO changed though, it displays now -0.1
Code:
G1 X5.249 Y542.100 Z-0.100 F900.000

As I said before, when I remove the G43 command all works as expected.

Please Log in to join the conversation.

More
5 years 6 months ago #204882 by Aciera
Can we see what you've got in your tooltable?

Please Log in to join the conversation.

More
5 years 6 months ago #204887 by ikkuh

Aciera wrote: Can we see what you've got in your tooltable?

Code:
cat tool.tbl T0 P0 ; T1 P0 Z+41.690621 ;flat003

That was after removing the *.var files and setting G54 to new corner and starting LinuixCNC. After running the first program gmoccapy added the toollength offset as seen above.

Please Log in to join the conversation.

Time to create page: 0.070 seconds
Powered by Kunena Forum