[Uman]

I just received this reply from Daniel Rogge:
"You cannot change tool length offsets while a program is paused for tool change. We recommend measuring tools before starting the program, even for Mach 3 users. If this is a deal breaker for you then you should stay with Mach 3".

It seems that whatever alternative workaround is devised, PP still requires all programs to have offsets entered for every tool, no exceptions. Also from Daniel's email there is no intention by Tormach to modify PP. A disappointing attitude.

I guess this mean that PP requires every tool change line requires T and H parameters otherwise it doesn't run it.

Why do you suppose Tormach is so bent against this feature in PP? From what I observed as of lately, if even a small group of people unite and protest, jobs and policies soon change.

[mountaindew]

I just received this reply from Daniel Rogge:
"You cannot change tool length offsets while a program is paused for tool change. We recommend measuring tools before starting the program, even for Mach 3 users. If this is a deal breaker for you then you should stay with Mach 3".

It seems that whatever alternative workaround is devised, PP still requires all programs to have offsets entered for every tool, no exceptions. Also from Daniel's email there is no intention by Tormach to modify PP. A disappointing attitude.

I guess this mean that PP requires every tool change line requires T and H parameters otherwise it doesn't run it.

Sounds like a standard canned response. I also contacted tormach about work offsets and how PP did not allow access to these values. As I noted before in this thread and other threads there is a host of problems I run into because of this and was told I can get refund, go back to mach or figure out how to make it work for me. I found PP works so well that it would be best to figure out a process or procedure that solves the work flow problem. To be honest after using the program for months now I don't notice the added steps needed to perform and set offsets before and during program execution. The added typing of mdi commands can be error prone and not nearly as cool as just reading screen code and following prompts "oh well" I will adapt

[MikeRags]

Why do you suppose Tormach is so bent against this feature in PP? From what I observed as of lately, if even a small group of people unite and protest, jobs and policies soon change.

As you probably know, the underlying code for PathPilot is LinuxCNC. If Tormach modifies the underlying LinuxCNC code without getting LinuxCNC.org's agreement on the changes, this will result in a significant fork of the underlying code, making future updates much more difficult.

I would assume the Tormach engineers are under the direction to minimize (or eliminate) PathPilot specific changes to the LinuxCNC code. The more PathPilot specific changes there are, the more time consuming it is when they need to update the underlying LinuxCNC code. Tormach will have to review file by file for any changes they made specifically for PathPilot and merge/rewrite the code changes, versus just swapping the LinuxCNC files and adding their PathPilot overlay.

My guess is the best way to get these features would be to petition the LinixCNC team to incorporate them, which would ultimately flow into PathPilot. I could be wrong and Tormach may be maintaining their own LinuxCNC fork going forward, but this would be much more costly in the long run, so I assume they are not.

[cncbasher]

theirs no need to petition us Linuxcnc folks , a polite ask is all we need .
some are easy , some can't be , most can be ..


however some are pathpilot specific and outside of Linuxcnc , i hope to be able to satisy , as i'll keep this updated , however i have no requirement to step on Tormach toes .
Tormach are using a cutdown version of Linuxcnc to suit their purposes , my version wont be cut down and in fact i wish to actively expand it . but like everything else we all need to keep a roof over our heads and food in our stomachs .

i am purposely keeping politics out , so thats my answer.
i am also happy to work with Tormach , but i can see they would be inundated with tweaks... which is why they no doubt have gone with Linuxcnc , as we have an active dev team
but not everything can be incorporated .

i hope this at least clarifys a few points
i am also hoping to release a few added extras , for people wishing to use pathpilot for their own builds ,
and hardware to suit . as things progress .

[PCW_MESA]

Does linuxcnc's g43.1 (Dynamic tool length offset) work with Pathpilot?

[cncbasher]

i have just looked at the source code ,on digging i found
i dont think so G41.1 was added around may this year , pathpilot is based on 2.6.0 , so unless you have ran some of the updates , it may well not be
do you need it fixing ?

[PCW_MESA]

g43.1 has been in linuxcnc for a long time (since 2.4 at least, probably earlier)

[cncbasher]

then i miss understood the question ..

[RTP_Burnsville]

This is a huge disappointment for me as well if I can not zero for a new tool change on the fly..... I have installed PP but have not had time to use it other than a simple profile cut for which it appeared to work well. My work is mainly prototypes runs of a couple items at most. Guess I will need to return to MACH3 if this issue does not get sorted going forward.

Thanks,
Robert

[mountaindew]

RTP
You can perform offset tasks like tool height setting, just not on the fly! PP will require you to stop the program set a start point then in this case insert a drill bit or tool and set height with whatever method you like. Then you restart program and continue until the next tool is required and rinse and repeat. Same is required for work offsets g54-g59 and extended offsets. This behavior requires these additional steps but is from what I see is very reliable and the stop and start of code does not cause other problems.
pp version 1.9 even held position in the code window and the user did not have to scroll down and find a place to set start point the position was still visible in the code window and made that down right simple. Sad to say new releases now reset to start of code and the user now has to scroll down thru code "sometimes thousands of lines" to set a start position. If any changes are made I would like to see it retain position in code window like it did a few versions ago, this made much of the stop and restart operations by user a number of factors faster and less error prone. As I noted above I took a couple weeks off from mill controller and did mostly new part design. Then when I returned I had more or less forgot how I did it before, making this far less a problem to adapt too As I want to stay current with tormach and the way they support and use their tool system I decided this was necessary and only hope the behavior does not change too much going forward requiring me to adapt more or more often.

[bevinp]

Mountaindew,
OK, where you need a new tool, you program a slow G1 move to a suitable Z height, press Stop during the Z move, manually change tool, touch off tool and zero Z, return program to line below stopped line, press Start from Here (or whatever it is) and wait for end of next op. Correct?
Sounds OK. With no use of M6, you avoid the need to have T and H parameters accurately set. Yes?
Bevin

[mountaindew]

Mountaindew,
OK, where you need a new tool, you program a slow G1 move to a suitable Z height, press Stop during the Z move, manually change tool, touch off tool and zero Z, return program to line below stopped line, press Start from Here (or whatever it is) and wait for end of next op. Correct?
Sounds OK. With no use of M6, you avoid the need to have T and H parameters accurately set. Yes?
Bevin

Sounds and reads like its ok.
What I do is place m1 commands in places with text notes "prompts" that tell me what to do." not required but they help"

In this case the program would drill all the holes with the one tool. When finished it would move to the tool change position and ask for next tool. At that point the program has paused itself. I would then click the stop button on screen and then scroll back down to that position and set start point. Then put new drill bit in and bring Z down to touch on top of material. Then zero the z axis and run it back up out of the way. Then check what I just did mentally and hit run button. The code will start executing at the set point and use the new tool height you just set and complete all the operations and continue until next tool change and pause. Then repeat those steps over and over tell done . Using this method PP could do a host of operations and never know or even use the tool table data as long as user set the tool offset after each change.
Hope this helps


Edit. To set the start point you need to right mouse button click in the code window on the desired place.

[bevinp]

Thanks mountaindew, a very workable solution. Tormach should stamp a little Smiley on the back of your hand (as they do in junior school).
Bevin