Tool change .ngc brakes the ability to use "run from here"

More
18 Mar 2017 08:16 - 18 Mar 2017 10:19 #89847 by emcPT
Using the latest stable version, and after so much time in setting a tool change of a umbrella type changer in a vertical mill, all implemented with a sub routine with a lot of "if" "endif", linuxcnc now does not have the ability of using "run from here".
When I try to use it, strangely, all the tool changes before the line that I choose to "run from here" are executed (toolchange is simply executed without any actually machining).
I also notice that although I am executing the "main program", in normal machining, the name of the program that appears on the window name is the tool change file, in my case "change.ngc"

There is any "best practice" for implement a tool change with a sub routine? Or a sub routine should be avoided?
We choose to use a sub routine because we got the need to issue G0 G1 and it looked the best way to go.



Thank you
Last edit: 18 Mar 2017 10:19 by emcPT.

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

More
20 Mar 2017 13:05 #89940 by andypugh

emcPT wrote: When I try to use it, strangely, all the tool changes before the line that I choose to "run from here" are executed (toolchange is simply executed without any actually machining).


You might need to exit the tool-change routine if the system on the basis of:
#<_task> - 1.0 if the executing interpreter instance is part of milltask, 0.0 otherwise. Sometimes it is necessary to treat this case specially to retain proper preview, for instance when testing the success of a probe (G38.x) by inspecting #5070, which will always fail in the preview interpreter (e.g. Axis).

Can you (debug, #<_task> and see if that gives different values in the two cases?

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

More
20 Mar 2017 17:52 #89958 by jtc
Hi.

In both cases, running the program from start or using "run from here" the #<_task> variable is always 1.

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

More
20 Mar 2017 18:57 #89960 by andypugh

jtc wrote: In both cases, running the program from start or using "run from here" the #<_task> variable is always 1.


There goes that idea, then. Sorry.

Which LinuxCNC version? We can see if it is a new problem, or a solved problem, or neither.

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

More
22 Mar 2017 14:40 #90071 by jtc

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

More
22 Mar 2017 18:30 #90083 by andypugh
The following user(s) said Thank You: jtc

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

More
08 Jul 2019 22:34 #138903 by Marcking
Hello Guys, I'm having this same problem on a 2.7.14 version does someone find a solution?
Thanks!

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

More
09 Jul 2019 07:57 #138930 by emcPT
The problem persists here. In fact is the only problem that we actually currently face.
The following user(s) said Thank You: Henk

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

More
09 Jul 2019 08:44 #138933 by Henk
Hi
We have the same issue on 2.7.14 on the milling machines, they use the manual toolchange function so hasn't really bothered us.
We have two lathes also running 2.7.14, but I don't recall having that issue on them.

Henk

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

More
09 Jul 2019 13:51 #138952 by Marcking
Wow! can't believe it, I have made some tests and found that not only remapping M6 code does the problem also remapping the T code too so I just made a call to the tool change macro instead and the problem persists(replaced Txx M6 with o<change> call).
This machine needs to make tool changes and it is very needed to some times running from a second, third and so on tool. Hope someone can give us a workaround?.

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

Time to create page: 0.117 seconds
Powered by Kunena Forum