UCCNC Post errors

[spumco]

(sorry in advance if this is a bit long)

Using the F360 generic UCCNC post (v41292) last updated 1/24/2017 from the online library

Runing UCCNC v1.2031

I noticed two errors in the post output that make it not play well with UCCNC:

1. Drilling cycles - posted a simple 4-hole pattern peck drill cycle.  Tool path in F360 looked great.  However, the post did two things wrong:

• Did not call a canned cycle (in this case a G73 peck cycle).  Instead it created a series of G1 Zx Fx moves to get the drill to depth with chip-breaking via G0 moves.
• Created a random G4 (arc) move while the drill was in the bottom of the hole.  Did a nice job snapping off my drill bit.  After looking at the code closely, each move to another hole was made at feed rate with the drill in the hole.  It appears that because a canned cycle was not used, the post didn't retract the drill to the retract plane  after the G1/G0 drilling "cycle" was complete.
• Further checking and fiddling with F360 revealed that ALL drill cycles (except for G81) have this bug.  All of them are posted using G1/G0 + location + feed rate instead of calling the canned cycle.  UCCNC supports G73, G81, G82 and G83.  Not sure why the post doesn't use them?

Drill-snapping snippet of code:

G1 Z-0.51 F29       (drilling down at feed rate instead of G73 cycle)
G0 Z-0.506           (Chip breaking via G0 move, not a G73)
G1 Z-0.5581 F29   (bottom of hole)
G4 X0.25              (Arc move with drill bit in hole!)
G0 Z0.2                (Now we rapid up to retract plane after breaking the bit)
X2.875                 (go to a new hole location)
Z0.04                    (Go to feed plane)
G1 Z-0.06 F29       (Start next hole)

2. RH Tapping cycle - tried tapping the same 4-hole pattern.  For whatever reason, the first hole tapped fine and the tap retracted to the retract plane.  However, the spindle didn't stop turning CCW, so when it moved to the next hole the UCCNC trajectory planner didn't permit starting the G33.1 cycle since the spindle wasn't turning CW (no M3 called).  Just sat there and waited.

It appears that the UCCNC G33.1 command is not like a drill cycle in that you can simply specify a new hole location and it will duplicate the last G33.1 command at the new location.  Instead, it appears to me that the post needs to treat each hole as an individual hole and not a series.

Only way I could get it to work was by hand-coding each hole:

Original Post Output (doesn't work)

G0 X2.875 Y-2.875
Z0.6
Z0.2
S500 M3
G33.1 Z-0.485 K0.0312
Z0.2
X0.625 (tool moves to new location but just sits there continuing to rotate CCW after the last hole)
(further hole locations...)

Hand-Coded (works)

G0 X2.875 Y-2.875
Z0.6
Z0.2
S500 M3
G33.1 Z-0.485 K0.0312
Z0.2
M5
X0.625
S500 M3
G33.1 Z-0.485 K0.0312

So...  hoping AutoDesk can fix the UCCNC post processor to manage these two bugs.  And while I'm at it, a peck tapping feature would be nice.  Since each hole has to be treated individually maybe we could have a G33.1 peck cycle with peck depth and number of pecks as an option.

Thanks for any assistance with this.

-Spumco

[spumco]

Sorry, I'm an idiot.

The line I earlier claimed was an arc move is actually an invalid dwell command.

G1 Z-0.5581 F29   (bottom of hole)
G4 X0.25              (Arc move with drill bit in hole!)
G0 Z0.2                (Now we rapid up to retract plane after breaking the bit)

It's a dwell, not an arc move.  The problem is that the post inserted that "X0.25" command after the dwell - presumably the dwell time - which I had set as .25 seconds in F360 CAM.

So the post still has an error since "X" is not the right parameter for a G4 dwell word.  "P" should be used for the dwell time, not "X."

Having identified my own idiocy, the rest of the issues with the post are still valid - missing canned drill cycles and the threading problem.  Still hoping for some work on the post.

Thanks,

Spumco

[AchimN]

Thanks for your feedback, I will have a look into the post and update it asap.

[AchimN]

FYI, the post is fixed and updated.

You can download it here:

https://cam.autodesk.com/posts/?p=uccnc

Please note that you will still get G0/G1 moves for drill cycles in cases where you entered a dwell time while that specific cycle does not support dwell.

Eg, chip-breaking and deep-drilling cycles do not support a dwell time, means, only if the dwell time is set to "0" in Fusion you will get your desired cycles.

Please test the tapping cycles and let me know if they work as expected.

[spumco]

Thanks for the prompt attention.

The drilling cycles all seem to be sorted out.  I assume that the G4 dwell period is in milliseconds, as a .25s value shows up as G4 P250 in the block. If this is correct, then we're all set with the canned drilling cycles - especially the dwell parameter.

The tapping still isn't working.  The new post output the following attempt to tap four holes:

G33.1 Z-0.485 K0.0312 (hole #1)
X0.625 (hole #2)
Y-0.625 (hole #3)
X2.875 (hole #4)
G80
Z0.6
G53 Z0.

As before, the post is treating the G33.1/.2 commands as modal when UCCNC doesn't recognize them as such.  Each hole needs an individual G33 Z[x]  K[x] command and then a spindle stop or reverse before the next hole can be tapped.  The four holes need to be output as follows:

S500 M3
G0 X2.875 Y-2.875
Z0.6 (retract plane)
Z0.2 (feed plane)
G33.1 Z-0.485 K0.0312

Z0.6

X0.625

Z0.2

M3 (or M5 then M3, and vice-versa for a G33.2 left tap cycle)

G33.1 Z-0.485 K0.0312

Z0.6

Y-0.625

Z0.2

M3

G33.1 Z-0.485 K0.0312

Z0.6

X2.875

Z0.2

M3

G33.1 Z-0.485 K0.0312

G80
Z0.6
G53 Z0.

Thanks again,

Ralph Christy

[AchimN · Accepted solution]

Unfortunately i missed to change left-tapping and right-tapping cycle, it is fixed already and the new version will show up soon.

Regarding your question, yes, dwell is in milliseconds.

Thanks for your feedback!

[spumco]

Thanks again for the help with the UCCNC post.

I have a new request - 4th axis.

It appears that the Stepcraft-specific UCCNC post has a 4th axis option, but the generic UCCNC post does not.  In addition, UCCNC authors have enabled a peck tapping (chip clearing) parameter in G33.1/33.2 - "Q" parameter for peck depth.

Would you be able to edit the generic post to include 4th axis support?  (A-axis rotational around "X") and the peck tapping parameter?

Peck tapping from the UCCNC user manual:

To execute a right hand (Leads in with M3) rigid tapping cycle program G33.1 Z... K... and to
program a left hand (Leads in with M4) rigid tapping cycle program G33.2 Z... K... Q..., where the
Z parameter is the bottom of the tap along the Z-axis and the K is the thread pitch per revolution.
The Q parameter is optional and defines the peck depth.
If the Q parameter is not programmed then the tapping cycle is executed from a single pass.
If the Q parameter is programmed then a peck tapping is made with each cycle increments Q depth
and a spindle synchronized tool pull off happens to the tapping command start position.
If the Q parameter value is not an integer divider of the full tap depth then the final tap depth will be
still correct, in this case the last peck cycle depth increment will be shorter than the Q parameter
value.

Thank you for your help

Regards,

Spumco

[AchimN]

@spumco , the generic uccnc post already has multi axis implemented, you just need to enable it as explained here:

https://forums.autodesk.com/t5/hsm-post-processor-forum/how-to-set-up-a-4-5-axis-machine-configurati...

Regarding the Q-Parameter for tapping, i didnt see that into the latest manual on the uccnc web page. Where did you find that information?

[spumco]

Achim,

The latest official version of UCCNC on their web site is 1.2029.  However, they're making updates  and fixes so fast they're up to 1.2037 for the 'beta' releases.  All beta versions are available for download on the CNCDrive forum.

A couple of revisions ago they implemented the peck tapping "Q" parameter at the users request.  I've attached the latest manual where I copied the "Q" test and pasted it above.

I understand if you're hesitant to change a publicly available post for a 'beta' version of the controller, but it's been through 4 revisions since implemented and is here to stay.

As for the 4th axis, I opened the Stepcraft version and found more than just the 'onOpen' true/false statement for aAxis.  Since I don't understand the post language or protocol much, I assumed that since there were other lines with warning messages I'd better ask the experts.

If all I need to do is follow the instructions in the linked tutorial let me know.  Or, if I just copy the differences in the Stepcraft post and overwrite the appropriate lines in the generic uccnc post will that work?  I just d/l'ed notepad ++ so I may be able to edit this on my own.

Thanks,

Spumco

[mitkus.tadas]

Hello All, 

I'm using UCCNC and can't figure out why the drilling toolpath is generating incorrectly. It might be my mistake, but I would like to hear from You gents.

I double checked, and seems I have downloaded the latest UCCNC postprocess:

And this is what I getting when posting a drilling toolpath:

(554)
(T2  D=6. CR=0. - ZMIN=-11.5 - flat end mill)
G90
G0 G53 Z0.

(Drill1)
T2 M6 (flat end mill D=6. 6 x 20 x 65mm)
S16000 M3
G61
G54
G43 H0
G0 X80. Y20.
Z16.
Z6.
G73 X80. Y20. Z-11.5 R6. Q3. F500
X20.
Y80.
X80.
G80
Z16.
M5
G53 Z0.
M30

Other toolpath (pocketing, adaptive, etc is working fine)

Thank You for your time and I hope someone could help me sort this out. 

[spumco]

[Really, I'm not an expert so take whatever I tell you with suspicion.]

It looks like it's outputting a peck drilling cycle to drill four holes in a square pattern.  Assuming you're working in metric, you have:

1. Exact stop mode set

2. G54 work offset set

3. Final hole depth 11.5mm below your work plane zero

4. Retract height 6mm above work plane zero

5. Peck increment  3mm

6. Feed rate of 500mm/min

All the variables in your code are recognized by UCCNC, at least according to my manual.  If it's retracting funny during the pecks, check the "R" height in your UCCNC settings tab and make sure it's set to the height you want.  That's a controller setting issue, not a post processor problem.

What is it doing wrong?  

-Spumco

[mitkus.tadas]

Thank You Spumco,

The issue is that my cnc machine stops at first pecking locatio - It moves to location, stops spindle and that's it, it shows as the last g-code line was executed. And because other machining toolpath types working just fantastically, I assumed that this issue must be with postprocess (and I'm highly experienced with G-Codes, so it is hard to tell if it is with G-Code or it might be with other settings in UCCNC or Inventor HSM)

[mitkus.tadas]

It seems I cant edit my own post anymore. I made typo mistake 😄

What I meant was :that  I'm NOT  highly experienced with G-Codes, so it is hard to tell if it is with G-Code or it might be with other settings in UCCNC or Inventor HSM

[mitkus.tadas]

Gents, 

It was a false alarm... I have updated UCCNC to latest version. And it solved the issue...  

Thank You for Your time and help

[spumco]

Good to hear you've got it sorted out.  I, too, am very new at this and can't read G-code like a master.

I suggest joining the UCCNC/CNCDrive forum if you haven't already done so.  It's incredibly active and the folks at CNCDrive are extremely helpful with issues and troubleshooting.  They also post their beta updates there for testing when they have new features or bug fixes.

In addition, I highly recommend taking a look at one of the forum member's screensets.  He's created a screenset that is significantly more attractive and much more functional than the stock one that comes with UCCNC.  I didn't want to spend days learning how to edit screens, and the UCCNC 2017 Screenset was just the ticket.  Very reasonable price, too, for all the work he put in it.

You may not like it, but it's worth a look.

Finally, if you search around the forum you can find an add-on to Notepad++ that is designed to work with the UCCNC & Stepcraft post processors.  Also recommend checking it out as it makes reading and perhaps editing the posts very graceful.

Good luck!

-S

[AchimN]

FYI, I´ve added a couple of features to the generic UCCNC and stepcraft UCCNC post like:

- parametric feed support

- property to enable 4th axis

- added Q-parameter for tapping with chip breaking

The update will show up into the tool library shortly.

[lof6ASVJ]

Hello

I use inventor and HSM express, when i tryed to post a g-code that included a taping cycle, I just got this:

"

Information: Configuration: Generic UCCNC
Information: Vendor: UCCNC
Information: Posting intermediate data to 'C:\Users\Lars Olav Bruk\Desktop\G-koder\1005 slettes.nc'
Information: Total number of warnings: 1
Error: Failed to post process. See below for details.
...
Code page changed to '1252 (ANSI - latinsk I)'
Start time: Wednesday, September 6, 2017 6:37:50 PM
Code page changed to '20127 (US-ASCII)'
Post processor engine: 4.2.1 41321
Configuration path: C:\Users\Public\Documents\Autodesk\Inventor HSM\Posts\uccnc (1).cps
Include paths: C:\Users\Public\Documents\Autodesk\Inventor HSM\Posts
Configuration modification date: Wednesday, September 6, 2017 6:17:37 PM
Output path: C:\Users\Lars Olav Bruk\Desktop\G-koder\1005 slettes.nc
Checksum of intermediate NC data: 76347cf43394dfa1e1bfb210ed127c42
Checksum of configuration: 4d258903be1da1feea75d5576b9a608e
Vendor url: http://www.cncdrive.com/
Legal: Copyright (C) 2012-2017 by Autodesk, Inc.
Generated by: Inventor HSM Express 5.1.2.33
...
Warning: Work offset has not been specified. Using G54 as WCS.
Error: Unsupported speed-feed synchronization activation command.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Error: Failed to execute configuration.
Stop time: Wednesday, September 6, 2017 6:37:50 PM
Post processing failed.

"

Is the Taping cycle fix, or still on going?

[AchimN]

Just tested it with the latest version of the post and it works fine for me, did you use the latest post?

If not, you can download it here:

http://cam.autodesk.com/posts/?p=uccnc

[spumco]

Achim,

Thanks again for your efforts with these posts.

I finally got around to trying the new peck-tap function (tapping with chip breaking) and the old problem came up I mentioned early this year.  Fusion is posting as if the G33.1/.2 tapping cycles were modal, and making moves to other hole locations before withdrawing from the first hole.

The normal (non-peck) tapping cycle works fine - each hole is treated as a separate operation (not modal) with individual G33.1 X/Y moves with a G80 and M5 command at the end of each hole before moving to the next location.

However, when 'tapping with chip breaking' is selected as the operation type, Fusion reverts back to the original error of simply adding X and Y commands for the next holes in the series.  This will result in moving in X/Y while the tap is still in the hole... not good.

What needs to happen is for the post to treat 'tapping' and 'tapping with chip breaking' the same, but with just the "Q" value enabled.

If I'm not being clear please simply model a couple tapped holes in some stock and try posting with the UCCNC or Stepcraft posts.  Then try it again using the chip break function and see the code difference.

Thanks again,

Spumco

[AchimN]

@spumco thanks for your feedback, the updated posts will show up into the library soon.