G-code file loading at G53 instead of G54
- CallumRD1
- Offline
- New Member
-
Less
More
- Posts: 15
- Thank you received: 2
08 May 2025 22:22 #328034
by CallumRD1
Replied by CallumRD1 on topic G-code file loading at G53 instead of G54
I'm sorry, I'm very confused by all of this. I have thousands of hours on a Tormach running Path Pilot, but this isn't behaving in a similar way.
The GUI G54 location set in the GUI at the bottom of the last screenshot isn't reflected in the offset tables. The display of the work envelope shows my G54 origin moving if I jog and hit the G54 zero GUI buttons, but the offsets table doesn't change. How is the offsets table supposed to be configured? In my screenshot, the Z column of the offsets table has values 1-12 in it, but I don't know where those came from or why they're there.
The GUI G54 location set in the GUI at the bottom of the last screenshot isn't reflected in the offset tables. The display of the work envelope shows my G54 origin moving if I jog and hit the G54 zero GUI buttons, but the offsets table doesn't change. How is the offsets table supposed to be configured? In my screenshot, the Z column of the offsets table has values 1-12 in it, but I don't know where those came from or why they're there.
Please Log in or Create an account to join the conversation.
- cmorley
- Offline
- Moderator
-
Less
More
- Posts: 7890
- Thank you received: 2135
09 May 2025 14:34 #328074
by cmorley
Replied by cmorley on topic G-code file loading at G53 instead of G54
could you run in debug mode (DISPLAY = qtvcp -d qtdragon), run linuxcnc from a terminal and post the output?
Please Log in or Create an account to join the conversation.
- CallumRD1
- Offline
- New Member
-
Less
More
- Posts: 15
- Thank you received: 2
09 May 2025 14:40 #328075
by CallumRD1
Replied by CallumRD1 on topic G-code file loading at G53 instead of G54
Sure. I'll try that this afternoon.
Please Log in or Create an account to join the conversation.
- CallumRD1
- Offline
- New Member
-
Less
More
- Posts: 15
- Thank you received: 2
09 May 2025 20:16 #328104
by CallumRD1
Replied by CallumRD1 on topic G-code file loading at G53 instead of G54
I used "DISPLAY = qtvcp -d qtdragon_hd" because I'm using the HD version and ran it from terminal. I've attached the terminal log.
Please Log in or Create an account to join the conversation.
- cmorley
- Offline
- Moderator
-
Less
More
- Posts: 7890
- Thank you received: 2135
10 May 2025 09:14 #328136
by cmorley
Replied by cmorley on topic G-code file loading at G53 instead of G54
Ok ill see nothing error ing in qtdragon.
I do see some weird errors about tool stat. But let's put test aside for the moment.
What I see based on your screen shots.
- g54 has zero offset for x and y so will be the same as machine zero position.
- you have a small offset in g54 z and while hard to see i think that it is honoring that.
- the offset table shows the same but also shows you have a rotational offset. Yes those z offset numbers seem weird.
I would cancel the rotational offset.
If you wish to move the g54 offset move the machine where you want g54 0 to be and press ZERO on each axis you wish to zero.
After that is done switching between ABS and G54 should make the DRO change the amount of offset and the offset will be shown on the offset table.
I do see some weird errors about tool stat. But let's put test aside for the moment.
What I see based on your screen shots.
- g54 has zero offset for x and y so will be the same as machine zero position.
- you have a small offset in g54 z and while hard to see i think that it is honoring that.
- the offset table shows the same but also shows you have a rotational offset. Yes those z offset numbers seem weird.
I would cancel the rotational offset.
If you wish to move the g54 offset move the machine where you want g54 0 to be and press ZERO on each axis you wish to zero.
After that is done switching between ABS and G54 should make the DRO change the amount of offset and the offset will be shown on the offset table.
Please Log in or Create an account to join the conversation.
- CallumRD1
- Offline
- New Member
-
Less
More
- Posts: 15
- Thank you received: 2
10 May 2025 13:42 #328145
by CallumRD1
Replied by CallumRD1 on topic G-code file loading at G53 instead of G54
Thank for your the response. Here is some more information in response to your suggestions.
This first image is the machine showing G53 coordinates. The tool is in the center of the work envelope, as you can tell by the non-zero coordinates (0, 0, 0 is the top front left corner).
This next image is after having switched to G54 using the gui button. As you can see, I set the G54 origin to be the current position, so it reads 0, 0, 0 while the tool is in the center of the work envelope. The work envelope image shows the work offset origin (3 vector arrows) as at the current position, as expect. This is all behaving as I expect.
But when I look at the offsets table, it hasn't reflected the changes to the G54 origin. No values have updated.
More so, when I clicked on the G54 Z value of 4 and tried to directly change it, I got this error, with the full text copied below.
Error message:
This first image is the machine showing G53 coordinates. The tool is in the center of the work envelope, as you can tell by the non-zero coordinates (0, 0, 0 is the top front left corner).
This next image is after having switched to G54 using the gui button. As you can see, I set the G54 origin to be the current position, so it reads 0, 0, 0 while the tool is in the center of the work envelope. The work envelope image shows the work offset origin (3 vector arrows) as at the current position, as expect. This is all behaving as I expect.
But when I look at the offsets table, it hasn't reflected the changes to the G54 origin. No values have updated.
More so, when I clicked on the G54 Z value of 4 and tried to directly change it, I got this error, with the full text copied below.
Error message:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/qtvcp/widgets/origin_offsetview.py", line 370, in dataChanged
self.reload_offsets()
File "/usr/lib/python3/dist-packages/qtvcp/widgets/origin_offsetview.py", line 232, in reload_offsets
temp[STATUS.stat.g5x_index-1] = STATUS.stat.g5x_offset
~~~~^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: 'tuple' object does not support item assignment
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/qtvcp/widgets/origin_offsetview.py", line 373, in dataChanged
self.reload_offsets()
File "/usr/lib/python3/dist-packages/qtvcp/widgets/origin_offsetview.py", line 232, in reload_offsets
temp[STATUS.stat.g5x_index-1] = STATUS.stat.g5x_offset
~~~~^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: 'tuple' object does not support item assignment
Please Log in or Create an account to join the conversation.
- cmorley
- Offline
- Moderator
-
Less
More
- Posts: 7890
- Thank you received: 2135
10 May 2025 14:27 #328151
by cmorley
Replied by cmorley on topic G-code file loading at G53 instead of G54
Ok great we are getting there.
I'm now betting that these debug lines are showing the problem:
Unfortunately I don't know what would cause this message.
Hopefully someone else will see and help us. I'll look at your INI some more tomorrow.
I'm now betting that these debug lines are showing the problem:
libnml/buffer/shmem.cc 320: Shared memory buffers toolCmd and toolCmd may conflict. (key=1004(0x3EC))
libnml/buffer/shmem.cc 320: Shared memory buffers toolSts and toolSts may conflict. (key=1005(0x3ED))
libnml/buffer/shmem.cc 320: Shared memory buffers emcError and emcError may conflict. (key=1003(0x3EB))
Unfortunately I don't know what would cause this message.
Hopefully someone else will see and help us. I'll look at your INI some more tomorrow.
The following user(s) said Thank You: CallumRD1
Please Log in or Create an account to join the conversation.
- rodw
-
- Offline
- Platinum Member
-
Less
More
- Posts: 11247
- Thank you received: 3757
11 May 2025 04:21 #328187
by rodw
Replied by rodw on topic G-code file loading at G53 instead of G54
Normally, you would touch off on your workpiece and set RefX, Y, and Z or use the probe screen (my preference),
Jog away from the home position and touch off all axes (using Ref buttons) then look at your offsets.
Press ABS and G54 to cycle between G54 and absolute coordinates.
The process is no different on a Tormach machine or any other machine including a manual mill with a DRO. Possibly your Tormach was dialed in on your vice long ago you forgot doing it.
Jog away from the home position and touch off all axes (using Ref buttons) then look at your offsets.
Press ABS and G54 to cycle between G54 and absolute coordinates.
The process is no different on a Tormach machine or any other machine including a manual mill with a DRO. Possibly your Tormach was dialed in on your vice long ago you forgot doing it.
Please Log in or Create an account to join the conversation.
- CallumRD1
- Offline
- New Member
-
Less
More
- Posts: 15
- Thank you received: 2
11 May 2025 12:51 - 11 May 2025 12:55 #328197
by CallumRD1
Replied by CallumRD1 on topic G-code file loading at G53 instead of G54
Hi rodw, thanks for the response. I think you are missing the problem so please allow me to clarify.
On my Tormach, this process makes perfect sense. I touch off with a probe or tool or edge finder or whatever, and then hit the zero buttons in the GUI. This sets the DRO readout to zero, puts the work offset origin symbol in the workspace viewer at the current position, and populates the offsets table with the position of the work offset in absolute coordinates. No problems here.
But on my new LinuxCNC mill, this process isn't working. When I hit the zero buttons in the gui, the DRO readout gets set to zero, the work offset symbol in the workspace viewer (3 colored axis arrows) gets put at my present position, but the offsets table doesn't update. It remains unchanged. You can see this in the images I attached to my previous post. More so, if I try to manually enter values in the offsets table, I get an error. I also included this info in my previous post.
Please let me know if there's anything else I can clarify. I understand that this is a bit of a subtle issue and I haven't done the best job of explaining it so far, so I hope this is a little better.
Edit: The mill is already homed in both situations described above. When run in what I call Bridgeport mode, moving the tool around manually and using the readout as a simple DRO, everything functions normally. The gui buttons zero the G54 work offset in the DRO correctly, it's just that the offsets table isn't updating along with this. When I load a G-code file, it appears to be respecting the offsets table G54 offset rather than the DRO-shown G54 offset, so the tool paths are not where I want them to be.
On my Tormach, this process makes perfect sense. I touch off with a probe or tool or edge finder or whatever, and then hit the zero buttons in the GUI. This sets the DRO readout to zero, puts the work offset origin symbol in the workspace viewer at the current position, and populates the offsets table with the position of the work offset in absolute coordinates. No problems here.
But on my new LinuxCNC mill, this process isn't working. When I hit the zero buttons in the gui, the DRO readout gets set to zero, the work offset symbol in the workspace viewer (3 colored axis arrows) gets put at my present position, but the offsets table doesn't update. It remains unchanged. You can see this in the images I attached to my previous post. More so, if I try to manually enter values in the offsets table, I get an error. I also included this info in my previous post.
Please let me know if there's anything else I can clarify. I understand that this is a bit of a subtle issue and I haven't done the best job of explaining it so far, so I hope this is a little better.
Edit: The mill is already homed in both situations described above. When run in what I call Bridgeport mode, moving the tool around manually and using the readout as a simple DRO, everything functions normally. The gui buttons zero the G54 work offset in the DRO correctly, it's just that the offsets table isn't updating along with this. When I load a G-code file, it appears to be respecting the offsets table G54 offset rather than the DRO-shown G54 offset, so the tool paths are not where I want them to be.
Last edit: 11 May 2025 12:55 by CallumRD1.
Please Log in or Create an account to join the conversation.
- rodw
-
- Offline
- Platinum Member
-
Less
More
- Posts: 11247
- Thank you received: 3757
11 May 2025 19:24 #328213
by rodw
Replied by rodw on topic G-code file loading at G53 instead of G54
Something sounds odd.
Docs on coordinates are here linuxcnc.org/docs/stable/html/gcode/coordinates.html
I wonder if the .var file is marked read only? This would prevent values from being saved.
Delete it as sometimes it gets stuffed up when setting up a new machine.
If you can't find it, check the file name in use in the ini file eg. for my QTdragon config
PARAMETER_FILE = linuxcnc.var
Docs on coordinates are here linuxcnc.org/docs/stable/html/gcode/coordinates.html
I wonder if the .var file is marked read only? This would prevent values from being saved.
Delete it as sometimes it gets stuffed up when setting up a new machine.
If you can't find it, check the file name in use in the ini file eg. for my QTdragon config
PARAMETER_FILE = linuxcnc.var
Please Log in or Create an account to join the conversation.
Moderators: cmorley
Time to create page: 0.147 seconds