[megacanam]

Having a couple issues with the generic Fadal output from Fusion360. I have no experience of editing post processors, but willing to learn so I can stop hand editing this code each time.

Format 2:

At the end of the programs it is putting G53 for "go home" -- my machine fails to recognize this and stops mid program when the "scan ahead" reads the G53 and tells me "invalid G code on line nXXX". I have been deleting it and the machine returns to the current work offset at Z0. How do I change the post to do the actual "home" or another position that I choose like the popular Z0 X0 Y8 for part loading?

N2910 X4.7716 Y-0.3703 Z0.926 I-0.0125
N2915 X4.7695 Y-0.3669 Z0.9287 I-0.0116 J-0.0047
N2920 X4.7675 Y-0.365 Z0.9327 I-0.0095 J-0.0081
N2925 X4.7668 Y-0.3645 Z0.9375 I-0.0075 J-0.01
N2930 G0 Z2.6


N2940 M9
N2945 G28 G91 Z0.
N2950 G90 G53 X0. Y0. <---- In reading the manual Fadal says to have the G53 on its own line, how do I prevent the post from putting the G90 on the same line as the G53?
N2955 M30
%


In rigid tapping the Format 2 Output is this for 5/16-18 tap. I am manually having to enter the S540 for my machine to run. How can I change the post to accomplish this?

(TAPPING)
N2220 M9
N2225 M1
N2230 T5 M6
N2235 T6
N2240 S540 M3
N2245 E3
N2250 M8
N2260 G90 G0 X1.2 Y-0.375
N2265 G43 Z2.6 H5
N2275 Z2.2
N2280 G98 G84.1 X1.2 Y-0.375 Z0.075 R0+1.275 Q0.0556 F30. (S540)
N2285 X3.5
N2290 X5.8
N2295 G80
N2300 Z2.6
N2310 M5
N2315 G28 G91 Z0.


Thanks for the help

[schuter]

N2950 G90 G53 X0. Y0. <---- In reading the manual Fadal says to have the G53 on its own line, how do I prevent the post from putting the G90 on the same line as the G53?

Just now starting to look at Fusion 360 post for Fadal (Much better with solidcam) so I am far from an expert but it looks like this is in your post:

writeBlock(gAbsIncModal.format(90), gFormat.format(53), gMotionModal.format(0), homeX, homeY);

This "gAbsIncModal.format(90)" is putting G90 in your line. You could try to remove that and see if it works. (Back up original before you make changes)

Personally, I like "G91G28Z0 Then G0G90E0X0.Y9.9" at the end, This raised the Z axis, then brings the table to the door for parts loading.


Let us know how it turns out.

[ryanpierce]

I've run into the same problem. I met with the Autodesk HSM development team recently at a Fusion 360 meetup in Chicago during IMTS and reported the problem. I'd expect the code you posted:

writeBlock(gAbsIncModal.format(90), gFormat.format(53), gMotionModal.format(0), homeX, homeY);

Would produce:

N.... G90 G53 G0 X.... Y....

But the G0 didn't appear in the output you posted. Did some editing happen? Not only do you need to put the G90 on a separate line, I believe you need to remove the G0 too. The Fadal docs state that no other G codes can appear on the same line as a G53; I'm guessing G53 + an axis move without a G0 is still done as a rapid. So I'd suggest changing that code to:

writeBlock(gAbsIncModal.format(90));
writeBlock(gFormat.format(53), homeX, homeY);

Incidentally, I've found that Fusion 360 + format 1 isn't usable. Fusion sets a fixture offset with Ex while the tool is in the cold start / tool change Z position, but the tool then makes a move to 0 in the new coordinate system. If the fixture offset is > 4" then the spindle hits the upper Z limit. This seems to be Fadal's fault; I really don't like the idea that a fixture offset change should cause any movement. Format 2 corrects this but Fusion 360 out of the box produces code that the Fadal can't process do to the G53 issue above.

[megacanam]

Yeah fusion on format 1 sends my machine skyward... only using format 2.

I have been doing some work on the post and have this for the closing:

function onClose() {
writeln("");

optionalSection = false;

onCommand(COMMAND_COOLANT_OFF);

// 90/91 mode is don't care
if (properties.format == 1) {
writeBlock(gAbsIncModal.format(90), gMotionModal.format(0), hFormat.format(0), "Z" + xyzFormat.format(0)); // retract
} else {
writeBlock(gFormat.format(28), gAbsIncModal.format(91), "Z" + xyzFormat.format(0)); // retract
// writeBlock(gFormat.format(28)); // retract
}
zOutput.reset();

setWorkPlane(new Vector(0, 0, 0)); // reset working plane

if (!machineConfiguration.hasHomePositionX() && !machineConfiguration.hasHomePositionY()) {
// 90/91 mode is don't care
if (properties.format == 1) {
writeBlock(gAbsIncModal.format(90), eFormat.format(0), gMotionModal.format(0), "X" + xyzFormat.format(0), "Y" + xyzFormat.format(0)); // return to home
} else {
writeBlock(gFormat.format(53), "X" + xyzFormat.format(0), "Y" + xyzFormat.format(8.0)); // return to home DELETED gAbsIncModal.format(90), AND , gMotionModal.format(0)
}
} else {
var homeX;
if (machineConfiguration.hasHomePositionX()) {
homeX = "X" + xyzFormat.format(machineConfiguration.getHomePosit ionX());
}
var homeY;
if (machineConfiguration.hasHomePositionY()) {
homeY = "Y" + xyzFormat.format(machineConfiguration.getHomePosit ionY());
}
if (properties.format == 1) {
writeBlock(gAbsIncModal.format(90), eFormat.format(0), gMotionModal.format(0), homeX, homeY);
} else {
writeBlock(gFormat.format(53), gMotionModal.format(0), homeX, homeY); //DELETED gAbsIncModal.format(90),
}
}

onImpliedCommand(COMMAND_END);
onImpliedCommand(COMMAND_STOP_SPINDLE);
writeBlock(mFormat.format(30)); // stop program, spindle stop, coolant off
writeln("%");

[megacanam]

My tapping output was fixed by adding the RPM :

case "right-tapping":
if (properties.format == 1) {
writeBlock(
gRetractModal.format(98), gAbsIncModal.format(90), gCycleModal.format(84.1),
getCommonCycle(x, y, z, cycle.retract),
"Q" + xyzFormat.format(tool.threadPitch),
"F" + feedFormat.format(tool.spindleRPM)
);
feedOutput.reset();
} else {
if (!F) {
F = tool.getTappingFeedrate();
}
writeBlock(
gRetractModal.format(98), gAbsIncModal.format(90), gCycleModal.format(84.1),
getCommonCycle(x, y, z, cycle.retract),
"Q" + xyzFormat.format(tool.threadPitch),
feedOutput.format(F), "S"+feedFormat.format(tool.spindleRPM)
);
}