drilling operation not using canned cycles

[Stuart-H]

as above

history

I used to use a personal use licence for fusion360 but due to the changes I now have a paid for licence

and I am sure it worked before 

problem drilling basic drilling uses the correct canned cycle but chip breaking cycle does not it output  code instead

info

I use a mach 4 milling post but I have tried a Fanuc post with the same results 

please find attached files its a simple test 

[seth.madore]

Can confirm this behavior. I've tried the Fanuc, Haas from the generic library.

However, my own post in the Cloud (for my Kitamura) posts out a G73. So i did a bit of post reading, and we have this option now:

[seth.madore]

Photo embedding appears to be broken for me....

See attached

[Stuart-H]

@seth.madore 

thanks Seth

not sure what you mean "So i did a bit of post reading, and we have this option now:"

do you know what has changed?

Stuart

[Stuart-H]

@seth.madore 

sorry crossed post 

problem I use a Mac that pic you posted is the pc version of the properties not available on a Mac unless I have missed it 

[seth.madore]

Hmmm....retracting my last comment. There's something different, as the Mach4 post seems to have the proper logic. Need a few minutes to look at it closer

[seth.madore · Accepted solution]

It's possible that they changed something internally on the drill cycle. I can't get a definite answer until Monday, but let's try this:

Open up your Mach4 post, search down to approximately line 1036 where we have this line:

case "chip-breaking":
      if ((cycle.accumulatedDepth < cycle.depth) || (P > 0)) {
        expandCyclePoint(x, y, z);
      } else {
        writeBlock(
          gRetractModal.format(98), gCycleModal.format(73),
          getCommonCycle(x, y, z, cycle.retract, cycle.clearance),
          "Q" + xyzFormat.format(cycle.incrementalDepth),
          feedOutput.format(F)
        );

And we're going to change it to this;

case "chip-breaking":
      // cycle.accumulatedDepth is ignored
      if (P > 0) {
        expandCyclePoint(x, y, z);
      } else {
        writeBlock(
          gRetractModal.format(98), gAbsIncModal.format(90), gCycleModal.format(73),
          getCommonCycle(x, y, z, cycle.retract),
          "Q" + xyzFormat.format(cycle.incrementalDepth),
          feedOutput.format(F)
        );

Which ends up giving us this code:
G98 G73 X-4.75 Y-3.455 Z-25.625 R4.375 Q1.5 F50.

[Stuart-H]

@seth.madore 

looks like you have fixed it 

I have rung all others types to code and post's look ok but I have not run on machine yet 

I will let you know either way next couple of days ( just had our over 65 flu jabs as per normal I get a painful arm for the next few days should be used to them by now as we are both 73 

Stuart 

keep safe and be safe 

[Stuart-H]

@seth.madore 

Seth

now its got bizarre 

as I said I have a paid acc and I have another in the wife's name as a personal one

ok loaded up the wires one on the current version on Mac OS with a unmodified mach4 post and it worked fine then it stopped working with bad gcode

went back to the iMac on big sur again with a new copy of the post still ok 

the reason for the tests was because the more I used it on the iMac the more it failed with your mods somtimes it would work then it would fail if I had two different drill ops  eg normal and chip brake 

so I am completely stumped as to why it works sometimes on two different macOS on two different Macs one a laptop air and the other a fully spaced out iMac i9 40gb ram 8 gb graphics  

I will try to get some more information tomorrow ( not a happy bunny now I am paying for for this the team have altered somthing that is upsetting the apple cart not sure if it a bg but it sure is not correct

[engineguy · Accepted solution]

@Stuart-H 

@seth.madore 

Gentlemen, if I may comment on this please ?? IMHO I can`t find anything wrong with the G73 drilling cycle, it looks to me to be working as expected 🙂

Here is the section from the 4 axis Mach PP that I use all the time, it is unmodified and works correctly.:-

case "chip-breaking":
if ((cycle.accumulatedDepth < cycle.depth) || (P > 0)) {
expandCyclePoint(x, y, z);
} else {
writeBlock(
gRetractModal.format(98), gCycleModal.format(73),
getCommonCycle(x, y, z, cycle.retract, cycle.clearance),
"Q" + xyzFormat.format(cycle.incrementalDepth),
feedOutput.format(F)
);

What is actually happening here is that if the "Accumulated Pecking Depth" is used then to have the G73 Canned Cycle then the "APD" must be set to the full depth of the hole then it doesn`t come into play so it is just a normal G73 Cycle, OK so far 🙂

However if the "APD" is set to say half depth of the hole then at  that point the full retract has to  come into effect, as there is no way that I can see to get that variable retract to appear in the standard G73 Cycle it would appear that the Developers have made it so the actual G code for each vertical move is output 🙂

G Code with no "APD" applied, in other words set to full depth of the hole I don`t see this as a workaround but expected behaviour :=

G98 G73 X-0.69 Y-0.181 Z-15. R5. Q1.25 F180.

G Code using "APD" set to half depth, in this case 7.5mm and all vertical moves are output, again this is what I would expect without some way of creating a variable retract within the Cycle. This may be something that the developers are working on but as I see it it works fine for now and IMHO the way the Devs intended it to work ?? 🙂 🙂

Z5.
Z2.
G1 Z-1.25 F180.
G0 Z-0.25
G1 Z-2.5 F180.
G0 Z-1.5
G1 Z-3.75 F180.
G0 Z-2.75
G1 Z-5. F180.
G0 Z-4.
G1 Z-6.25 F180.
G0 Z-5.25
G1 Z-7.5 F180.
G0 Z-6.5
G1 Z-8.75 F180.
G0 Z5. Here is the point where it does the full retract after the 7.5mm "APD"
Z-6.75
G1 Z-10. F180.
G0 Z-9.
G1 Z-11.25 F180.
G0 Z-10.25
G1 Z-12.5 F180.
G0 Z-11.5
G1 Z-13.75 F180.
G0 Z-12.75
G1 Z-15. F180.
G0 Z5.
Z15.

Summary:-

If you want just a straight G73 Cycle then set the "APD" to the full depth of the hole and all will be well 🙂 🙂 🙂

If you want a full retract at some point in a deeper hole then just set that value to the "APD" depth required and again all will be well 🙂 🙂 🙂

Be nice if the Devs could work a full retract value into the Canned Cycle though 🙂 🙂 🙂

Stay Safe

Regards

Rob

[Stuart-H]

@engineguy 

@seth.madore 

further testing last night left me perplexed 

after a while the post mods failed to work as expected on both fusion360 installs then it worked🤔

I do not completely understand @engineguy    Post but it does seem to gel with a same light in the back of the brain cell could it be the model I ask my self your post made me think it could be and this is compounded with me not setting the drill cycle correctly ( maybe it’s new behaviour) . I will look into how I setup the drill cycle to try and understand it 

thanks again guys for your time 

I should have twigged it when other post processors had the same errata 

Stuart

[Stuart-H]

@engineguy 

@seth.madore 

Rob

ok I have done some work in fusion

Conclusions

you have to be very precise in selecting the heights with the APD set accordingly to get the single line code that I expected.

as you correctly stay the retract at a depth forces the long code 

but as both have there merits all seems well

Thanks again to both as I have learnt a bit more in the process the problem was I could not see the wood for the trees

boy my dyslexia writing is playing up today sorry for the jumble its all getting mixed up 

[engineguy]

@Stuart-H 

Yep, "wood for the trees" about covers it, I looked at it for hours on and off before what I ended up with eventually clicked 🙂

As for great precision required what I found is that as long as the APD setting is equal to or greater than the hole depth then the G73 cycle is produced so it is easy to just put a depth in the APD that is say the bottom of the model, so you don`t need to know the exact depth of any of  a number of holes, it is also (once the idea had sunk into my porous old brain) to quite easily have a lot of different depth/diameter holes all doing either the G73 or long code within the same program 🙂 🙂 🙂

Your original block modified and attached for your examination 🙂

As for whether it is intended behaviour by the Developers or I just found a "workaround" we will have to wait till Seth @seth.madore  gets to have a chat with the Developers on Monday, either way as you rightly point out it works both ways and if a CNC Control can read and execute one it will also do the other, certainly the "long" code should always work 🙂 🙂

Stay Safe (You youngsters 🙂 )

Regards

Rob

[Stuart-H]

Rob

thank you

yes we know about keeping safe at 73 we have to be careful 

Stuart