PathPilot Software Update – v2.2.0

[David C. Allen]

PathPilot Software Update – v2.2.0

Please see SB0046 for install instructions and software revision information.
NOTE: IF YOUR CONTROLLER IS RUNNING PATHPILOT V1.X, YOU MUST FIRST PURCHASE A PATHPILOT V2.0 USB DRIVE PN 38249 TO UPGRADE TO PATHPILOT V2.0 OR GREATER.

David





Similar Threads:

• What would you like to be added to the pathpilot software
• PathPilot Software Update - v1.9 (2080 kb)
• PathPilot software sharing requests
• PathPilot Software Update - v1.8.2
• PathPilot Software Update - v1.7.2 (3952 kb)

[metalmayhem]

what is the point of this ?

" In addition to Z offsets, G43 now applies X and Y offsets. (PP-2402) "

[Advil]

what is the point of this ?

" In addition to Z offsets, G43 now applies X and Y offsets. (PP-2402) "

Probably so it will retrieve gang tooling Y locations when using RapidTurn without having to modify your post code. There is a thread going in the regular Tormach forum about it.

[kstrauss]

I requested this change so a few words of explanation: I have an auxiliary water cooled 24K RPM spindle mounted beside the main Tormach spindle. With this update the tool table magically accounts for the x/y offset between the main and auxiliary spindles. There is no need to edit the gcode to use both spindles in the same job!

[mountaindew]

I like the tool table filters and feed override slider that goes to 200% will be handy at times

[metalmayhem]

I requested this change so a few words of explanation: I have an auxiliary water cooled 24K RPM spindle mounted beside the main Tormach spindle. With this update the tool table magically accounts for the x/y offset between the main and auxiliary spindles. There is no need to edit the gcode to use both spindles in the same job!

I'm confused because all I've ever known g43 for tool height calls . how does this work with the x and y and where would their values be placed

[kstrauss]

All offsets (x,y,z) have always been maintained in the tool table but only the z-offset was applied with g43. There is no UI to set x and y offset so you will have to use g10 to do so. For my application x and y are unchanged between the various tools used in my auxiliary spindle.

[kstrauss]

There is now version 2.2.1 released. The only mention in the release notes of changes from 2.2.0 is: "We fixed an issue introduced in PathPilot v2.2.0 where, during some ATC tool changes, the feed rate and spindle speed override
sliders were disabled (so that the sliders no longer had any effect). (PP-2471)"

[kstrauss]

All offsets (x,y,z) have always been maintained in the tool table but only the z-offset was applied with g43. There is no UI to set x and y offset so you will have to use g10 to do so. For my application x and y are unchanged between the various tools used in my auxiliary spindle.

Based on some private emails I should have explained at bit further!
Assume that your auxiliary spindle is offset from the main spindle by 4 inches in X and 1 inch in Y and you want to use tool 69 in the auxiliary spindle. Enter this in the MDI "G10 L1 P69 X4 Y1" Set the Z-offset normally using your ETS. Changing to tool 69 (T69M6G43 or G43H69) will then magically apply the right offset to position your auxiliary spindle at the current x/y position of the main spindle. Changing to a tool without an X/Y offset restores things to normal positioning.

[metalmayhem]

I'd feel safer throwing in a g52 for something like that

[kstrauss]

I'm unsure of your concerns. Could you please explain?

Applying the X&Y offsets is no different from the Z-offset that we use with every tool change. Also, the additional offsets are almost always used in lathe work. In my experience using X&Y offsets is only a potential issue because they are not displayed on the offsets tab and that possible problem is not obviated by using G52. In fact, since G52/G92 are potentially persistent across reboots I think that they are extremely dangerous and avoid them unless essential. I've also been bitten even in a single session when I aborted a run and left the G92 active. Obviously each program's safety preamble should disable G92 but I sometimes forget when hand coding a quick task.

[metalmayhem]

To each his own I'm not knocking it but I'd never use such a thing
I never use g92 , but I've been using g52 shifts and sub routines for 30yrs and never had a problem with them . My concern is the "magical" but hidden thing , and the modification of a standard G code for more than it is intended for . I can add a g52 to a program and I can physically see it is there and active , for me thats the safety net

[kstrauss]

I've only been doing CNC for a few years so I certainly don't have your depth of experience. I don't see anything hidden (an oxymoron?). Most every vendor -- LinuxCNC, Haas, Fadal or... -- seem to have their own dialects and extensions of "standard" Gcode and even RS274 is pretty loose in many areas.

[metalmayhem]

I've worked with most controls and every mill has treated a g43 the same as one another . For something as unique as your application, I'd think a custom g code or m code would make more sense since it would be a unique code for a unique situation . I suppose if it causes no ill effect then there's no problem .

I'm glad to see that tormach is willing to look outside the box , but at the same time there are simple common things that they don't seem to feel the need to impose . I'm waiting for an update that will allow access to the offset pages and allow modifications mid program , without having to do a reset to change an offset . I love pathpilot but so many things are missing

[kstrauss]

I haven't looked at the internals but my understanding is that the standard version of LinuxCNC treats offsets the same as Tormach now does; they had a bug that prevented it working as intended. In lathe mode multi-axis offsets are applied at tool change to accommodate gang tooling. Anyway, things are as they are and I'm happy with the new release. Everyone is free to use or not use features at their discretion. PP is really mostly LinuxCNC with a pretty face added by Tormach so don't look for fundamental changes.

[metalmayhem]

[QUOTE=kstrauss;2288420. PP is really mostly LinuxCNC with a pretty face added by Tormach so don't look for fundamental changes.[/QUOTE]

I wouldn't expect anything above what lnuxcnc offers but it would be nice if it had more of what linuxcnc does have to offer . A simple block/skip(delete) button would be nice and it would beat me having to constantly edit a / in and out of my programs . I'd just like to see the common simple things added . Otherwise I'm good with it

[dannirr]

Unfortunately they didn't add the very simple thing I asked for - split the coolant button into two - M7 and M8. Currently you cannot get M7 while the machine is running Conversational code (without editing the code) or during a manual op.

[TurboStep]

I wouldn't expect anything above what lnuxcnc offers but it would be nice if it had more of what linuxcnc does have to offer . A simple block/skip(delete) button would be nice and it would beat me having to constantly edit a / in and out of my programs . I'd just like to see the common simple things added . Otherwise I'm good with it

First of all I believe PathPilot offers a LOT more than just "raw" linuxcnc with a pretty face, but if this still isn't enough Tormach provide all their Python source code in readable format, so the sky's the limit!
Just out of interest I implemented a Block Delete button (BG button to the right of Cycle Start) and tested the functionality. Block Delete works as advertised but it only affects the flow of a program if enabled/disabled BEFORE the program is executed. If the Block Delete state is changed while execution is stopped at a M01 break or while stepping through the program with Single Block it doensn't appear to affect the remaining program flow - I've only done very limited testing so far. I therefore have my button disabled unless PathPilot is idle. Possibly Tormach don't like this behavior, or maybe they know of other issues. Tormach are certainly more than capable of reproducing what I've done here so I can only assume they have good reasons for not doing so.
Step

[kstrauss]

Just out of interest I implemented a Block Delete button (BG button to the right of Cycle Start) and tested the functionality. Block Delete works as advertised but it only affects the flow of a program if enabled/disabled BEFORE the program is executed. If the Block Delete state is changed while execution is stopped at a M01 break or while stepping through the program with Single Block it doensn't appear to affect the remaining program flow -

The behaviour that you noted appears to be as documented in http://linuxcnc.org/docs/2.5/pdf/Lin...ser_Manual.pdf :
"10.3.2 Block Delete Switch
If the block delete switch is on, lines of G code which start with a slash (the block delete character) are not interpreted. If the switch is off, such lines are interpreted. Normally the block delete switch should be set before starting the NGC program."

See https://forum.linuxcnc.org/38-genera...during-program for another user's complaint about the behaviour together with a workaround for the desired action in certain specific circumstances. Also see https://sourceforge.net/p/emc/bugs/53/ for a very brief explanation of why changing Block Delete while running may give unexpected results.

I have achieved a flavour of Block Delete using my USBIO clone board to skip specific pieces of code.

[metalmayhem]

I'd be fine with implementing block delete before starting the program because this when I turn it on or off anyhow . As it stands I have to edit and bracket or un bracket the slash before running the programs