qt_dragon_hd - manual tool change and remap
14 Jun 2023 00:24 #273525
by grey_goat
Replied by grey_goat on topic qt_dragon_hd - manual tool change and remap
Thank you for all your help and time.
Please Log in or Create an account to join the conversation.
22 Aug 2023 09:31 - 22 Aug 2023 09:32 #278680
by Vector
Replied by Vector on topic qt_dragon_hd - manual tool change and remap
I took a long swig of the documentation tonight, but I'm stuck with a question:
(and btw, I'm on qt_dragon, not qt_dragon_hd, on LinuxCNC 2.9, updated two days ago, and Debian 12)
I've got this line in my .ini file:
I understand this to indicate I should have the following files somewhere in the paths defined in the [RS274NGC] section under SUBROUTINE_PATH:
change_prolog.ngc
qt_auto_probe_tool.ngc
change_epilog.ngc
I found qt_auto_probe_tool.ngc, but I cannot file the other two even when I search the entire disk.
I both qt_auto_probe_tool.ngc under ~/linuxcnc/nc_files-examples-remap-subroutines ... and in there is a "change.ngc" but neither change_prolog nor change_epilog.
But I don't get errors when I start.
What am I missing?
(and btw, I'm on qt_dragon, not qt_dragon_hd, on LinuxCNC 2.9, updated two days ago, and Debian 12)
I've got this line in my .ini file:
REMAP=M6 modalgroup=6 prolog=change_prolog ngc=qt_auto_probe_tool epilog=change_epilog
I understand this to indicate I should have the following files somewhere in the paths defined in the [RS274NGC] section under SUBROUTINE_PATH:
change_prolog.ngc
qt_auto_probe_tool.ngc
change_epilog.ngc
I found qt_auto_probe_tool.ngc, but I cannot file the other two even when I search the entire disk.
I both qt_auto_probe_tool.ngc under ~/linuxcnc/nc_files-examples-remap-subroutines ... and in there is a "change.ngc" but neither change_prolog nor change_epilog.
But I don't get errors when I start.
What am I missing?
Last edit: 22 Aug 2023 09:32 by Vector. Reason: Removed color codes
Please Log in or Create an account to join the conversation.
22 Aug 2023 15:59 #278719
by cmorley
Replied by cmorley on topic qt_dragon_hd - manual tool change and remap
change_prolog and change_epilog are not ngc files, they are python functions.
They are found in the file: stdglue.py
probably at path something like this :
~/linuxcnc/nc_files/examples/remap_lib/python-stdglue
They are found in the file: stdglue.py
probably at path something like this :
~/linuxcnc/nc_files/examples/remap_lib/python-stdglue
The following user(s) said Thank You: Vector
Please Log in or Create an account to join the conversation.
22 Aug 2023 22:06 #278735
by Vector
Replied by Vector on topic qt_dragon_hd - manual tool change and remap
Ack! Awesome (I must've read it too late into the evening, that's exactly what it says).
Can you weigh in on the best practice for these subroutine paths?
1. On the one hand, there's setting a ton of paths, like all the kitchen-sink contents, as they suggest here in section 2.10 of the QTDragon documentation which involve a lot of different paths through shortcuts in the /home/user/linuxcnc/nc_files directory.
2. Or should we point directly to the actual path on disk, which is more like /usr/share/linuxcnc/nc_files...
1. has the advantage of probably finding something you need regardless of where the next update might possibly move/add it, it might also solve security issues.
2. has the potential advantage of clarity? But it might break on an update if the philosophy at linuxcnc is to manage directory changes by updating the install underneath that list of shortcuts that are installed in ~/linuxcnc/nc_files, or are the directory structures pretty fixed?
Or is there another better reason for using the shortcut paths instead of the actual paths?
Can you weigh in on the best practice for these subroutine paths?
1. On the one hand, there's setting a ton of paths, like all the kitchen-sink contents, as they suggest here in section 2.10 of the QTDragon documentation which involve a lot of different paths through shortcuts in the /home/user/linuxcnc/nc_files directory.
2. Or should we point directly to the actual path on disk, which is more like /usr/share/linuxcnc/nc_files...
1. has the advantage of probably finding something you need regardless of where the next update might possibly move/add it, it might also solve security issues.
2. has the potential advantage of clarity? But it might break on an update if the philosophy at linuxcnc is to manage directory changes by updating the install underneath that list of shortcuts that are installed in ~/linuxcnc/nc_files, or are the directory structures pretty fixed?
Or is there another better reason for using the shortcut paths instead of the actual paths?
Please Log in or Create an account to join the conversation.
22 Aug 2023 22:50 #278736
by cmorley
Replied by cmorley on topic qt_dragon_hd - manual tool change and remap
We use relative paths a lot in linuxcnc because the paths of development version vrs a installed version are based from different places in the system and we want them to work either way. And frankly, linuxcnc really isn't that helpful about letting you know what is wrong with paths.
But on your system you are probably not going to switch from development (known as RIP) to installed or vice versa, so you can use absolute paths if that is easier for you.
The other choice is to make copies of the file you need and add them in your configuration folder (best in another folder or two , to keep things tidy) and set the paths to them.
The advantage is an update won't change those files.
The disadvantage is an update won't change those files.
![:) :)](/media/kunena/emoticons/smile.png)
This becomes most important if you modify the files.
And once you get your linuxcnc machine running the way you want, think hard before updating linuxcnc - it's annoying to break your running system just because there was an update (that you might have not needed). At the very least have a separate hard drive of the original so you can get back to work quickly if you need to. Once we officially release a version we try pretty hard not to break the system but it happens from time to time.
Chris
But on your system you are probably not going to switch from development (known as RIP) to installed or vice versa, so you can use absolute paths if that is easier for you.
The other choice is to make copies of the file you need and add them in your configuration folder (best in another folder or two , to keep things tidy) and set the paths to them.
The advantage is an update won't change those files.
The disadvantage is an update won't change those files.
![:) :)](/media/kunena/emoticons/smile.png)
This becomes most important if you modify the files.
And once you get your linuxcnc machine running the way you want, think hard before updating linuxcnc - it's annoying to break your running system just because there was an update (that you might have not needed). At the very least have a separate hard drive of the original so you can get back to work quickly if you need to. Once we officially release a version we try pretty hard not to break the system but it happens from time to time.
Chris
Please Log in or Create an account to join the conversation.
23 Aug 2023 00:14 #278738
by Vector
Replied by Vector on topic qt_dragon_hd - manual tool change and remap
Thank you: I had forgotten about the RIP vs. Installed... I figured there was more to consider than just the advantage/disadvantage of not updating files ![:-) :-)](/media/kunena/emoticons/smile.png)
And also thanks for the reminder to do a backup drive. Yes indeedy.
![:-) :-)](/media/kunena/emoticons/smile.png)
And also thanks for the reminder to do a backup drive. Yes indeedy.
Please Log in or Create an account to join the conversation.
10 Sep 2023 07:59 - 10 Sep 2023 10:13 #280380
by Vector
Replied by Vector on topic qt_dragon_hd - manual tool change and remap
Doh! I Found the problem described in this post!
For future travelers: check and recheck the .ini file for Z coordinates related to probe and tool change. In my case, I had made sure Toolsetter Z, Z_Max_Clear, and MaxProbe were set... but I missed the Z under Change_Position.
Now it's working.
After stepping back to work on CAD/CAM for a bit, I'm back to this step in my project and having a new problem.
I'm attaching the configuration files including the tool table, because it's probably relevant.
I'm also attaching two versions of test g-code. This isn't for anything real, just testing.
One version has the M6 T2 line, and ope version has it remarked out.
The version with the M6 line remarked out works.
The one that has it returns this error after pressing the Cycle Start button:
For future travelers: check and recheck the .ini file for Z coordinates related to probe and tool change. In my case, I had made sure Toolsetter Z, Z_Max_Clear, and MaxProbe were set... but I missed the Z under Change_Position.
Now it's working.
After stepping back to work on CAD/CAM for a bit, I'm back to this step in my project and having a new problem.
I'm attaching the configuration files including the tool table, because it's probably relevant.
I'm also attaching two versions of test g-code. This isn't for anything real, just testing.
One version has the M6 T2 line, and ope version has it remarked out.
The version with the M6 line remarked out works.
The one that has it returns this error after pressing the Cycle Start button:
Linear move on line 30 would exceed Z's positive limit
Linear move on line 30 would exceed joint 2's positive limit
invalid params in linear command
Operator Display:
Abort Parameter is [3]
Note1: this message comes up before the program executes anything: so it's during a pre-pass safety check.
Note2: yes, this machine has body image issues, so please be gentle. Yes, it's absurdly tall, yes, it has ridiculously long tool holders. Yes. We pretend not to notice. ;-)
On the plus side, having it be so strange may help to force some errors we might not otherwise get.
I ran the machine down to a soft target (a cereal box) for probing and reference... this code when it runs just waves the tool above it two passes.
The ABS coordinate for G54 0,0,0 is: 129,137.2,-461.6
Tool change is where I'm scratching, but I'm not making any progress.
I changed my tool lengths to zero based on a thread, but it didn't help. That thread is here: https://forum.linuxcnc.org/20-g-code/32950-linear-movement-exceeding-joint-2-s-positive-limit-in-linuxcnc
Any ideas?
Oh: versions:
Linuxcnc: 1:2.9.0~pre1.1119.gf9a02b365
QtDragon (not HD)
Linux 12
Linux 6.1.0-11-rt-amd64
And I have not modified the qt_auto_probe.ngc
Thanks!
Last edit: 10 Sep 2023 10:13 by Vector. Reason: Added version info. Also added a detail.
Please Log in or Create an account to join the conversation.
10 Sep 2023 19:23 #280425
by cmorley
Replied by cmorley on topic qt_dragon_hd - manual tool change and remap
How about just changing the tool in MDI?
t1m6
What does that do?
Should go to the toolchange position, ask you to change the tool, then go to the probe position and probe.
t1m6
What does that do?
Should go to the toolchange position, ask you to change the tool, then go to the probe position and probe.
Please Log in or Create an account to join the conversation.
11 Sep 2023 00:08 #280442
by Vector
Replied by Vector on topic qt_dragon_hd - manual tool change and remap
You are quite right! Thank you for an elegant test.
And it would have helped point directly to the problem: I had my Change_Position set wrong in my ini file.
Thank you!
And it would have helped point directly to the problem: I had my Change_Position set wrong in my ini file.
Thank you!
Please Log in or Create an account to join the conversation.
11 Sep 2023 02:27 #280444
by Vector
Replied by Vector on topic qt_dragon_hd - manual tool change and remap
Follow up question....
I tried a tool change -- T1M6 -- but my tool didn't have time to get to the tool sensor, so it "timed out"
I'm increasing the speed, and trying it again, but when I issue the T1M6, it tells me:
So, the work-around is just restart the program.
But, this might indicate that on a time-out, the cleanup doesn't set the machine back to the correct state?
I tried a tool change -- T1M6 -- but my tool didn't have time to get to the tool sensor, so it "timed out"
I'm increasing the speed, and trying it again, but when I issue the T1M6, it tells me:
Cannot use g53 incremental
Operator Display:
Abort Parameter [1]
So, the work-around is just restart the program.
But, this might indicate that on a time-out, the cleanup doesn't set the machine back to the correct state?
Please Log in or Create an account to join the conversation.
Moderators: cmorley
Time to create page: 0.125 seconds