drilling order, what the peck .

[freman]

Hi,

I have a simple test piece of five holes. In this case I wish to define the drilling order , and hence the path, to avoid a clamp on the stock.

I first made a path of 4 holes before realising the need, so I just added a central hole at the centre.

Problem 1: I don't seem to be able to add the fifth hole to Drilling4, I go to Base Geometry; select the 5th hole and click Add. Nothing happens , nothing in report window. Looks like a bug.

Problem 2: I made a new drilling path with the 5 holes selected in the order which I wanted them processed. The path does not seem to take account of the order the elements appear in the list. This probably not a bug but possible would be a good feature.

Should the order be significant there does not seem to be a means of reordering the elements in Base Geometry. If this has not importance and is ignored that makes sense. If would be good to order them and for it to matter.

Problem 3: probably my lack of familiarity but I selected "peck" and entred 2mm. I only see a straight dive to the bottom in the Gcode. Where is the peck?

Am I missing stuff or is this all not possible at the moment?

TIA.

PS I just found another issue here. It is using G81 and it seems that GRBL does not support this. I checked that I was using grbl post processor.
https://github.com/gnea/grbl/wiki/Grbl-v1.1-Commands
Also see:
https://github.com/gnea/grbl/issues/290

Code: Select all

(Begin Drilling)
G0 F0.000000 Z6.000000
G90
G98
G81 F2.000000 R10.000000 X-10.000000 Y-10.000000 Z0.000000
G81 F2.000000 R10.000000 X-110.000000 Y-110.000000 Z0.000000
G81 F2.000000 R10.000000 X-210.000000 Y-210.000000 Z0.000000
G81 F2.000000 R10.000000 X-210.000000 Y-10.000000 Z0.000000

Code: Select all

OS: Linux (LXDE/LXDE)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.16854 (Git)
Build type: Release
Branch: master
Hash: fe0fd5512ba9a8a9c729cdc47af35bbe965050ac
Python version: 2.7.15
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/UnitedKingdom (en_GB)

[RatonLaveur]

Hey hey,

Same procedures as you,

1. Yep i think it's a bug. Not just with drilling too. I find with pocket as well.
2. Could be very cool. Technically if you open a drill op for each hole you can already rework the order. So i suspect it's a matter of rethinking the hierarchy of sub programs generating g code.
3. Peck drilling, check your post processor my friend, peck drilling will be G83 or a variation thereof, which constitutes a standard canned cycle. I encourage you to look up canned cycles. Most Numerical Commands have them precoded and PathWB leverages this.

Cheers mate, great reporting, you're a fury!

[freman]

check the PS, grbl does not support canned cycles. And even if I do not check "peck" and to not give a peck distance FreeCAD is still producing code using G81 which makes GRBL barf.

I did work around this using one single hole and then a grouped path for the other four, did the job. I also had to use a pocket instead of a drilling path.

So workaround OK, but I think the OP is still valid.

I'm not sure how FreeCAD is stuctured but maybe the post processor should be breaking them down into separate moves.

[RatonLaveur]

I see...the lack of distance variable prevents your GRBL post processor to even take the G81 and adapt it. Understood. Valid complaint.

In my opinion only half the problem is due to PathWB. The rest should be handled by an adapted GRBL post to take the pseudo g-code offered by PWB and make it digestible (i.e. Prevent it from barfing)

[freman]

Like I say, I don't know what the post processor is supposed to do in FreeCAD but I would have thought it is for taking care of specific limitations or variations in the various GCODE interpreters ( like GRBL ).

If no peck is given when defining the drill path, there is no need to use G81. In any case, either the FreeCAD post processing for grbl target breaks these moves down and avoids G81 ( which should be pretty trivial ) or it needs to flag the user to remove them. IMO.

[herbk]

Hi freman,
the postprozessor is not involved if you create a path.
FreeCAD creates a "basic gcode" which gets translated to the postprozessors dialect if you export it.
But of course it schould not export not suported codes.

[freman]

Can we clarify terminology a bit here?

The post processor is what I'm calling the FreeCAD action when I select Path | Post Process. The external machine firmware which reads the Gcode sent to the machine and controls the motor hardware etc. is called GOCDE interpreter. I'm not sure earlier replies are clear about what I meant by post processor.

We are agreed that FreeCAD ignores the target at the time it is creating Gcode for a path. This may include things like G81 which is not supported by all Gcode interpreters.

I think it is the grbl post processor in FreeCAD which should be breaking down these "canned cycles" into separate moves. If someone who understands the guts of FreeCAD design can confirm that is where it should be dealt with , then a bug report should be opened.

[sliptonic]

There have been post processors written already that break G81 style canned cycles down into regular G1/G0 moves. Search this forum for G81.

I thought it was already included in grbl but I might be mistaken.

[freman]

You are correct in principal:
https://github.com/FreeCAD/FreeCAD/pull/1837

so why did this get through to my Gcode and get spat out by GRBL on the machine?

[sliptonic]

It's a different post processor. Make sure you're using the right one.