UCCNC Fusion 360 Post Processor

[spumco]

Not specifically a UCCNC issue, but maybe someone here has an idea about how to solve this. I've received no response from the Autodesk Post folks.

I've found a couple of errors in the Generic UCCNC post outputs:

1. The post is not calling any of the canned drill cycles recognized by UCCNC except for G81. The G73, G82, and G83 cycles are output as individual G1 feed rate moves with G0 retracts and G4 dwells.

1a. The G4 dwell parameter recognized by UCCNC is "P" for dwell time. The F360 post is outputting the dwell parameter with "X" - as in "G4 X0.25" for a .25 second dwell. This causes an X-axis movement while the drill is still in the hole. The moves look fine in the F360 CAM tool path, but the gcode output will show up in the UCCNC backplot with the little sideways drill-snapping move. Ask me how I found this gem.

2. The F360 post isn't handling the tapping cycles properly for multiple holes. The post output assumes that the correct method of coding multiple holes to tap is to call the G33.1 Z... K... and then issue a command for the next hole location. This results in the first hole being tapped properly, but the spindle doesn't stop (CCW) when it reaches the retract plane and moves to the next hole location. Since the spindle is still turning CCW, UCCNC won't permit starting the next tapping cycle and the machine just sits there spinning CCW at the feed plane.

2a. The solution I came up with was to edit the posted code and insert an M5 between the G33.1 line and the next location, and then insert another M3 line after the tool reached the next hole, then an identical G33.1 Z... K... command. Repeat for each hole.

So... question for CNCDrive: Is there a better method of coding multiple tapping locations than treating each hole as an individual feature? Something like a canned drill cycle where you can just have:

G81 Z-0.5 X1 Y1
X2
X3
G80

And get three holes in a line?

By the way, while figuring out the tapping issues I realized that I had re-tapped the same hole about five times. The threads were still perfect. And I'm just using a cobble-up inductive limit switch as a spindle index signal.

UCCNC's motion control and spindle gearing is awesome!

Thanks,
Spumco

[cncdrive]

Hi Spumco,

I'm not sure if Fusion knows the canned cycle codes and if it knows it then it is still a question if it knows that UCCNC knows them.
I think only Autodesk could answer these questions or maybe digging into their post processors could also give an answer, I mean if there is any post processor which outputs canned cycle codes then the first question is answered.

The G4 X0.25 is really not good, because that will mean a G4 dwell which will be basicly ignored as there is no P parameter defined and then there will be a X0.25 movement and if this is made at the bottom of a Z drill then it will likely break the tool.

The issue why the G33.1 can work like that is because it is not modal. The G73, 82, 83 etc. are all modal codes and are in mode one which is the motion mode, so when you execute them then the UCCNC will switch the motion modal to that code, so the next time a coordinate is programmed then that will be exacuted using that motion mode.
When a G33.1 is executed then that does not set the motion mode, the 1st modal, because the G33.1 is not modal at all.

By the way, while figuring out the tapping issues I realized that I had re-tapped the same hole about five times. The threads were still perfect. And I'm just using a cobble-up inductive limit switch as a spindle index signal.

Most of the proximity switches are pretty good at repeat accuracy.
Once we were making an ATC spindle machine and the tool lenght sensor we ordered for the machine did not arrive in time, but we wanted to test the ATC macro with the tool length measurement,
so we placed a square shaped inductive sensor on the table to test the codes and I remember I was surprised that it gave a repeat accurace lower than what we could technically measure.

UCCNC's motion control and spindle gearing is awesome!

Thank you, I'm happy to hear that you are satisfied with it.
In the next release we've also add the feature that the motion controller will take the ratio parameter into account for tapping when using spindle pulleys and will adjust the encoder resolution parameter in the API taking the ratio into account, so the function will be hopefully even better in the next release.
And we also just finished adding the optional Q peck depth parameter for the G33.1/2, so peck tapping with a single G-code will be also possible in the next release.

[spumco]

Thanks for the clarification. I figured G33.1/2 weren't modal from the machine behavior, but I wasn't sure.

It's odd that the Autodesk post author knew enough about the UCCNC recognized gcodes to call G33.1 for tapping (instead of G84, typical of other languages), but didn't call the other drilling cycles.

I guess I'll just keep pestering them.

In the next release we've also add the feature that the motion controller will take the ratio parameter into account for tapping when using spindle pulleys and will adjust the encoder resolution parameter in the API taking the ratio into account, so the function will be hopefully even better in the next release.

If you can update the manual, or at least a change log, when you implement the next release to explain this change more fully I'd appreciate it. I want to make sure I adjust my encoder settings (if needed) before tapping again. As you might recall, it's working now because I 'tricked' the motor shaft encoder PPR/CPR to match the pulley ratio.

Regards,
Spumco

[cncdrive]

If you can update the manual, or at least a change log, when you implement the next release to explain this change more fully I'd appreciate it. I want to make sure I adjust my encoder settings (if needed) before tapping again. As you might recall, it's working now because I 'tricked' the motor shaft encoder PPR/CPR to match the pulley ratio.

OK, will try to explain it well in the manual.
What changes is only if pulleys are used (by 'used' I mean the spindle pulleys enabled and selected) and when the ratio of the selected pulley is not 1.
The encoder resolution setting will define the 1:1 pulley ratio resolution and if you change to a pulley which has different ratio then the motion controller will use that ratio to adjust the encoder resolution internally with that ratio.
The only difference from how it works now is that the ratio is not used to adjust the encoder resolution for rigid tapping, but in the current release always the same encoder resolution which is setup is used,
which you pointed out that it is not too good and is why we've added this ratio compensation to the encoder resolution for the tapping.

[spumco]

Good explanation, thanks. This means I'll have adjust the encoder PPR and enable the pulleys again, but I won't have to have the workaround setting in there now.

-S

[cncdrive]

Thanks.
Yes, I also think it is much better to compensate the encoder resolution with the pulley ratio.
We should have make it that way in the beginning, but there are so many things going on that honestly I did not even think about the rigid tapping when we added the spindle pulleys functionality and only realised that the compensation was not done for the rigid tapping when you've mentioned it.
And yes, you will have to adjust the encoder resolution setting to the ratio 1 and then the motion controller will adjust the resolution when you will change pulleys.

[spumco]

UPDATE -

The Autodesk folks have partially fixed the Fusion 360 UCCNC post processor:
1. Drilling cycles are now posted using the canned cycle G-codes UCCNC recognizes.
2. G4 dwell parameter is now "P" and posts in milliseconds (i.e. .25 seconds in the CAM screen posts as "G4 P250" in the g-code.
3. Drilling cycles that do not support dwell (deep-hole G83) are postsed with G0/G1 moves and a G4 dwell. Works fine, just takes up more lines.

4. Tapping cycle not fixed. The new post still treats G33.1/.2 as modal, and I've submitted a request for them to take another shot at it.

It also throws up when you try to call a peck tap (file fails to post).

Balazs - you mentioned elsewhere that you are planning to incorporate a peck tap parameter in the next (or soonish) release. Would it be possible for you to contact Autodesk CAM folks and let them know what the parameters are and how to implement this feature? I figure if they're going to work out the errors on the tapping cycle, they might as well incorporate the peck tap features.

Here's a link to my forum post:

http://forums.autodesk.com/t5/hsm-post- ... -p/6842152

Also, I'm not a member of the Stepcraft forum, but I know from reading the forum posts there are quite a few folks discussing the Fusion posts. They might like to know about the updated post file available. Fusion doesn't seem to have an automatic way of notifying users of post updates. If there's anyone here who is a member of the Stepcraft forum please feel free to mention the updates. There have been 2 or 3 (including this one) in the past week, and I hope yet another one shortly that fixes the tapping cycle.

-Spumco

[spumco]

UPDATE 2-

Latest post file update posted 2017-02-08 has fixed the multi-hole tapping problem. I've mentioned the (new) peck tapping "Q" parameter to them, we'll see if it works.

So far, F360 is good to go with UCCNC.

-Spumco

[cncdrive]

Hi Spumco,

Yes, the G33.1/2 was updated in the latest test release with the Q peck depth parameters.
Unfortunately it was reported that the new Q parameter does not work correctly yet, we fixed it meanwhile and I've posted a replacement UCCNC.exe file for those who wants to run tests,
the replacement exe work well at us, we've tested it meanwhile, but waiting for others also to feedback their test results.

The Q parameter is now described in the manual, but you will have to open the manual which is in the UCCNC/Documentation folder,
and ofcourse the document which has this description is only the 1.3032 latest test UCCNC release.

We are not yet in contact with Autodesk, but will try to contact them, however I think they should not put the Q parameter in their post processor before this new feature goes into official release.
However executing a code like that with the Q parameter with an older UCCNC version will not cause any serious problems, just the pecking will not happen, the tapping will go in a single pass.