Does path know about G99 ?

Here's the place for discussion related to CAM/CNC and the development of the Path module.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Post Reply
User avatar
freman
Veteran
Posts: 2201
Joined: Tue Nov 27, 2018 10:30 pm

Does path know about G99 ?

Post by freman »

Hi,

as a test, I imported the following code. To my mind , it should traverse between the two drilling ops at z=3. 3D view shows it moving at z=35.

Am I mistaken or is Path WB not ready for G99 ?

TIA.

Code: Select all


(G99-Drilling)
(Begin Drilling)
G0  Z35.000000
G90
G99
G81 F360 R3.000000 X-17.500000 Y-15.000000 Z-17.000000
G81 F360 R3.000000 X-42.500000 Y-15.000000 Z-17.000000
G80
G0 Z33.000000
G0 Z35.000000
With GRBL expanding these bare paths, I have drilling paths retracting to either previous Z ( safety height ) or traversing at R value with wsk8's "keepTooldown" checkbox in the UI setup controlling whether G98 or G99 is added before the drilling command.

That fulfils my requirements. If there isany interest on this I'll do further testing and submit a PR.
Last edited by freman on Mon Mar 27, 2023 3:37 pm, edited 4 times in total.
GeneFC
Veteran
Posts: 5373
Joined: Sat Mar 19, 2016 3:36 pm
Location: Punta Gorda, FL

Re: Does path know about G99 ?

Post by GeneFC »

freman wrote: Mon Mar 27, 2023 1:53 pm Am I mistaken or is Path WB not ready for G99 ?
100% mistaken. :mrgreen:

FreeCAD does not control the machines in your shop.

The G99 is in the code. That is all that FreeCAD can control.

If you are not seeing the correct result it is because your controller is not following orders.

Gene
User avatar
freman
Veteran
Posts: 2201
Joined: Tue Nov 27, 2018 10:30 pm

Re: Does path know about G99 ?

Post by freman »

I have no problem with my machine. :D I have a problem with FreeCAD not respecting clearance height on drilling ops. :mrgreen:

My question was whether standards compliant Gcode would retract to R given that example code. And whether the 3D view rendition of that path is correct. Can you comment on that?

I have modified GRBL-post to expand this basic code to what I believe to be correct, NIST compliant behaviour. I now have retract to previous Z ( G98 ) and retract to R value ( G99 ) depending on a checkbox in the UI.

That seems like a considerable improvement on the current jumble which does neither one nor the other in a standard compliant way. It issues a G98 , then seems to attempt to backengineer behaviour similar to G99 behaviour by adding extra commands.

This mod should save me a few tools and unanticipated gouges in my work. 8-)
GeneFC
Veteran
Posts: 5373
Joined: Sat Mar 19, 2016 3:36 pm
Location: Punta Gorda, FL

Re: Does path know about G99 ?

Post by GeneFC »

freman wrote: Mon Mar 27, 2023 3:09 pm And whether the 3D view rendition of that path is correct.
I have no understanding of how the 3D view is created.

Your image above does not have any dimensions. I misunderstood your quest. :oops:

Gene
User avatar
freman
Veteran
Posts: 2201
Joined: Tue Nov 27, 2018 10:30 pm

Re: Does path know about G99 ?

Post by freman »

Thanks Gene.

I'm not asking for understanding how 3Dview works, rather what the results are.

The image I added. Is my GRBL output. I'll move that since it could be confusing.

This image below is the path I am questioning in the OP. To my mind it should be traversing at R value.
To create this path I removed all the extra stuff in drilling path python code which FC is currently adding to make a G98 stay down when it shouldn't. It now produces just the bare G81 commands. I inspected this with "Inspect Path Commands" and fixed the dummy feed rates that produces. The result was the code snip I posted. I then imported that and looked at how 3dview rendered it. It is essentially the same as described and same as the image below.

It seems that is wrong because G99 should not revert to previous Z it should retract to R value and stop there. The next G81 should then do a G0 to the new XY, before decending to drill. This seems to be the minimum movement results that had inspired previous hacks.

If 3D is confused about this as well, that may need tweaking. I doubt that is very hard.

The FCStd attached here will probably show errors because the paths were created with the new KeepToolDown property .
This is also displaying in a way I believe is wrong, though the gcode is now correct.

I have proper output for both cases with my new grbl-proc and this may finally be time to tidy up this unholy mess to something like NIST standards and provide both safe clamp avoidance and fast , stay down behaviour for those wanting that.
Attachments
G98-test.FCStd
(23.25 KiB) Downloaded 10 times
3d-view.png
3d-view.png (31.45 KiB) Viewed 641 times
GeneFC
Veteran
Posts: 5373
Joined: Sat Mar 19, 2016 3:36 pm
Location: Punta Gorda, FL

Re: Does path know about G99 ?

Post by GeneFC »

freman wrote: Mon Mar 27, 2023 3:33 pm
I am not sure what happened, but when I do a full recompute on your file before doing anything else the traverse jumps down and looks correct.

Gene
User avatar
freman
Veteran
Posts: 2201
Joined: Tue Nov 27, 2018 10:30 pm

Re: Does path know about G99 ?

Post by freman »

Thanks for checking it out, Gene.

So it seems that you confirm my expectation that G99 should traverse at the lower level. That's what I was looking for. :)

As I said, that path was created with modified drilling path code.

What your recompute did was rebuilt with the all the crazy stuff that came in a few years back to make G98 code behave like G99.

I'll bet if you examine your output you'll see the G98, G0XY move and the drop to start_depth + setupsheet.safetyOffset , then the g81. After that the G81 retracts to "current_z" which is now start_depth + setupsheet.safetyOffset, then another G0XY to next hole, so G98 ends up looking like G99.

My gcode , before recompute, does a G81 from z=35, so the final retract should be to z=35 for KeepToolDown=false ( and issues G98 ) and retracts to the R value and issues a G99 when KeepToolDown=True, as in this case. The code snip at the top should traverse just above the surface (at z=3).

I am asking why 3Dview seems to be showing the move at z=35 between holes. This seems to indicate that 3dview is NOT taking into account the G99. While some code is included for G99 in Path WB, it seems it currently unused and maybe 3D view is not coded for it, or is wrongly coded.

I've been trawling the code to find out where paths are rendered in the 3D view but haven't been able to find it :(
This needs to be tidied up since it will be confusing to users even if the gcode comes out right.
User avatar
freman
Veteran
Posts: 2201
Joined: Tue Nov 27, 2018 10:30 pm

Re: Does path know about G99 ?

Post by freman »

OK, this seems to be where it should be taken into account for 3D view. There is no mention of G99 for G81/83, so I'll have to work out how to pass it down to this code. I've added a TODO in the last line which is pushing the return point to the list of moves.

Code: Select all

 
 double q;
            if (cmd.has("Q")) {
                q = cmd.getValue("Q");
                if (q>0) {
                    Base::Vector3d temp(next);
                    for(temp.*pz=r;temp.*pz>next.*pz;temp.*pz-=q) {
                        Base::Vector3d pr = compensateRotation(temp, nrot, rotCenter);
                        qlist.push_back(pr);
                    }
                }
            }

            Base::Vector3d p3(next);
            p3.*pz = last.*pz;  
            Base::Vector3d p3r = compensateRotation(p3, nrot, rotCenter);

            plist.push_back(p1r);
            plist.push_back(p2r);
            plist.push_back(p3r); // TODO : G81,G83 need to account for G99 and retract to R only
Post Reply