forum.cncdrive.com

Can UCCNC run the code below in attachment when multiple commands on same line ? This is output from Mastercam which looks very different to the same cycles I would normally get output by fusion360 in that multiple commands on same line ?

Have a issue where the first part of code N5 is implimented for the spot drill then , a tool change and it then runs the drilling operation N5 but doesnot move away from tool change position to G54 X27 Y-9.5 to start the drilling operation .

it just starts drilling from where the tool change took place ???

Does anyone have a proven post processor for Mastercam and UCCNC ?

What is shown in white color is implemented and gets executed when cylced.
What is red is not implemented and not executed.
N5 is just a line number, it is not a command.

cncdrive wrote:What is shown in white color is implemented and gets executed when cylced.
What is red is not implemented and not executed.
N5 is just a line number, it is not a command.

Understand the line numbers but it did the first program N5 fine , then did toolchange of program N6 and then started drilling BUT it did not execute the line G0 G90 G17 G54 X27. Y-9.5 S800 M3 properly in that it did not move to X27 Y-9.5 9 , it did turn spindle on and then started the G99 G83 Z-23 R3 Q2 F65 but the position is supposed to be X27 Y-9.5 but it never moved there from the tool change position ?

cncdrive wrote:What is shown in white color is implemented and gets executed when cylced.
What is red is not implemented and not executed.
N5 is just a line number, it is not a command.

Understand the line numbers but it did the first program N5 fine , then did toolchange of program N6 and then started drilling BUT it did not execute the line G0 G90 G17 G54 X27. Y-9.5 S800 M3 properly in that it did not move to X27 Y-9.5 9 , it did turn spindle on and then started the G99 G83 Z-23 R3 Q2 F65 but the position is supposed to be X27 Y-9.5 but it never moved there from the tool change position ?


Fusion outputs a file like below -not the same operation but same type where everything is on its own line. The Mastercam PP does it different.

(Drill1)
T61 M6 (drill D=3.175 3.175 x17mm 1F DRILL)
S14500 M3
G61
G54
M8
G43 H61
G53 Z0

G0 X-31.467 Y14.889
Z15.
Z5.
G98 G73 X-31.467 Y14.889 Z-11. R4. Q0.794 F350
G80
Z15.
M9
M5
G53 Z-5.
M30

Looking for a mastercam post processor that will work with UCCNC

At the moment a fanuc post is being used and it outputs the attached code below , when it get to the drilling cycle it starts drilling at the tool change position rather than the correct spot and it does something wierd to the controller where even on a cycle stop and reload new gcode the X axis will no longer move .

Complete shutdown of the controller is required to recover. I then load the hand generated code that I have just seperated all the commands onto seperate lines and everything runs fine.

I believe there is something in the layout of the fanuc post ( which I have been led to believe UCCNC is based on or compatable with) that is corrupting the controller ?

Is there anyone out there using mastercam and can help out with a working post processor.

Did a heap more testing and its not the post processor .
Looks to be the M6 macro/M31 macro

IF the position of the last xy is the same as after the tool change the software doesnt move to the position commanded in Gcode as for some reason it thinks its already there ??.

So the solution is make sure the M6 macro records the coordinates before executing the tool change , then after the tool change it sends it back to position before the tool change .

I am doing it manually by adding a G0 X#Y# into my gcode after a tool change - I only worked it out due to having the same issue when using fusion post processor about a year ago and adding a random G0X#Y# into my PP after a tool change. Since it was mastercam not fusion the problem reappeared.

Now to work out how to do it in the M6 macro and the M31

Hi - Did you ever manage to find a a working PP for Mastercam?

It seems to me that Delco's issue probably was that several other G-codes were injected between the G0 and the movement coordinates.
These should be output in separate lines for the UCCNC.