- Posts: 55
- Thank you received: 11
Linear movement exceeding joint 2's positive limit in LinuxCNC
- verticalperformance
- Offline
- Senior Member
-
Less
More
9 years 3 months ago #95585
by verticalperformance
Replied by verticalperformance on topic Linear movement exceeding joint 2's positive limit in LinuxCNC
Can you attach the tool table for us to have a look at?
Per your ini file it will be named tool.tbl and should be in the same directory.
I also just noticed in your .ini file you have in the EMCIO section
TOOL_CHANGE_AT_G3 = 0
Per the docs this should be TOOL_CHANGE_AT_G30 = 0
Don't think this will fix, but never hurts to try. I don't have this line at all in mine so I suspect that is the same as =0
Try commenting it our with a # and see what happens?
I also see that you have remapped M6
REMAP=M6 modalgroup=6 ngc=tool-change
perhaps that is the issue - test by commenting out the remap lines in the .ini and even comment out any M6 lines in the g-code. If you are only using one tool you don't need a Tx M6 in your g-code unless you are using some form of tool compensation and the tool table.
I'm leaning towards whatever happens when you issue the M6 being the issue,
What is in the tool-change.ngc and tool-job-begin.ngc files (attache them too!) and do you need this stuff - seems pretty advanced config to me.
keith
Per your ini file it will be named tool.tbl and should be in the same directory.
I also just noticed in your .ini file you have in the EMCIO section
TOOL_CHANGE_AT_G3 = 0
Per the docs this should be TOOL_CHANGE_AT_G30 = 0
Don't think this will fix, but never hurts to try. I don't have this line at all in mine so I suspect that is the same as =0
Try commenting it our with a # and see what happens?
I also see that you have remapped M6
REMAP=M6 modalgroup=6 ngc=tool-change
perhaps that is the issue - test by commenting out the remap lines in the .ini and even comment out any M6 lines in the g-code. If you are only using one tool you don't need a Tx M6 in your g-code unless you are using some form of tool compensation and the tool table.
I'm leaning towards whatever happens when you issue the M6 being the issue,
Code:
[RS274NGC]
PARAMETER_FILE = linuxcnc.var
SUBROUTINE_PATH= /home/kieran/linuxcnc/configs/Mill/ManualToolChange
REMAP=M6 modalgroup=6 ngc=tool-change
REMAP=M600 modalgroup=6 ngc=tool-job-begin
What is in the tool-change.ngc and tool-job-begin.ngc files (attache them too!) and do you need this stuff - seems pretty advanced config to me.
keith
The following user(s) said Thank You: BeachBum
Please Log in or Create an account to join the conversation.
- BeachBum
- Offline
- New Member
-
Less
More
- Posts: 8
- Thank you received: 0
9 years 3 months ago - 9 years 3 months ago #96307
by BeachBum
Replied by BeachBum on topic Linear movement exceeding joint 2's positive limit in LinuxCNC
Thank you for all the suggestions. I have not had time to look at this for a while now but jumped onto it this afternoon.
So I started again from scratch without any of the added files or remaps. This has worked out fine the first half dozen trials I have undertaken. I must assume that there was something in there that was causing the very large move at the beginning. That was no longer seen with the new configuration.
One thing I did notice was that I had my lower limit set as -0.1. Using the new configuration a slightly different warning came up stating that the minimum limit was affected. I changed the z axis limits to be -70 and +80 and the problem no longer occurred. Ie if your part starts at 0 and extends to -50 on the zaxis and the axis 2 limit is -0.1 technically the part is outside the limits.
I never realised that the limits were applied to the workpiece coordinates. I assumed they were fixed at the world coordinates.
Im going to stick with this config for now.
I came back to this problem and found the actual reason for this: In the Remap code (Which I would like to keep as it greatly helps with locating the tool heights etc after a manual tool change), there is a line that specifies the coordinates of the tool change location. Of course I forgot to change these to coordinates within my limits! Hence why the large z axis move.
Thanks again for bearing with me and my stupid mistakes.
So I started again from scratch without any of the added files or remaps. This has worked out fine the first half dozen trials I have undertaken. I must assume that there was something in there that was causing the very large move at the beginning. That was no longer seen with the new configuration.
One thing I did notice was that I had my lower limit set as -0.1. Using the new configuration a slightly different warning came up stating that the minimum limit was affected. I changed the z axis limits to be -70 and +80 and the problem no longer occurred. Ie if your part starts at 0 and extends to -50 on the zaxis and the axis 2 limit is -0.1 technically the part is outside the limits.
I never realised that the limits were applied to the workpiece coordinates. I assumed they were fixed at the world coordinates.
Im going to stick with this config for now.
I came back to this problem and found the actual reason for this: In the Remap code (Which I would like to keep as it greatly helps with locating the tool heights etc after a manual tool change), there is a line that specifies the coordinates of the tool change location. Of course I forgot to change these to coordinates within my limits! Hence why the large z axis move.
Thanks again for bearing with me and my stupid mistakes.
Last edit: 9 years 3 months ago by BeachBum. Reason: New understanding of problem
Please Log in or Create an account to join the conversation.
Time to create page: 1.513 seconds