Fusion 360 - EMC Post ?
15 Dec 2021 20:48 #229160
by Muzzer
Replied by Muzzer on topic Fusion 360 - EMC Post ?
Incidentally, Autodesk recently updated the LinuxCNC lathe post processor with the G28 U/W issue corrected. It seems to be dated September 2021, although I'm pretty certain it hadn't been released when we were posting about this back in October. So now a G28 will set coordinates in X and Z rather than U and W. They don't seem to have published any release notes, so I've no idea what else they changed and I can't be bothered to diff it to find out right now. But it's worth installing the latest version if you want to use G28 instead of G53 coords at the end of your file. I've checked it and it works, so I am now back to using my preferred G28.Perhaps worth asking them to look into it but TBH, their response to Alkabal's query on the matter was pretty dismissive, despite him and Andy Pugh pointing out that they'd misunderstood how LinuxCNC interprets the U/W output. I might give it a go and see what if anything transpires.
I suspect they consider the lathe CAM to be largely complete now, so don't have any / much effort planned to support it and to be fair, the milling CAM is an order of magnitude more complex and wider ranging, with a much bigger user (paying subscriber) base. The lathe CAM still seems a bit buggy, so I'm being fairly cautious in how I use it.
Please Log in or Create an account to join the conversation.
15 Dec 2021 21:18 - 15 Dec 2021 21:18 #229166
by alkabal
Replied by alkabal on topic Fusion 360 - EMC Post ?
Last edit: 15 Dec 2021 21:18 by alkabal.
Please Log in or Create an account to join the conversation.
15 Dec 2021 22:04 - 15 Dec 2021 22:21 #229168
by Muzzer
Replied by Muzzer on topic Fusion 360 - EMC Post ?
Hmm, yes, that's forced me to look again. I seem to have the last 3 versions reversed in my mind. It seems that r43470 and r43462 output U and W, while the previous version r43417 correctly outputs X and Z. Seems somebody may have screwed up a perfectly functional G28 feature when changing something else.
Bottom line is that previous version (r43417) outputs X & Z, so one simple fix is to revert back. All the previous versions are available in the Fusion post library
cam.autodesk.com/hsmposts
43462 12/10/2021 Added the ability to specify the coolant codes as a text string.
43418 08/09/2021 Fixed undesired expansion of tapping cycle in generic turning posts.
Doing a file compare in VSC shows the 2 authors had different styles when it came to spaces and tabs, which accounts for most of the differences. I don't see any obvious major structural / content differences, so I wonder if the loss of G28 function was due to a subtle but unintentional formatting / syntax change due to insertion or deletion of a space in a critical statement. I may be forced to gradually swap out the differing content and repost my trial CAM file to see what is causing it....
Both posts contain the same section for outputting G28 in either XZ or UW, so I'm guessing something has been broken, preventing it from functioning as it originally did:
// format home positions
for (var i = 0; i < retractAxes.length; ++i) {
switch (retractAxes) {
case X:
words.push((method == "G28" ? "U" : "X") + xFormat.format(_xHome));
retracted[X] = true;
xOutput.reset();
break;
case Y:
if (yOutput.isEnabled()) {
words.push((method == "G28" ? "V" : "Y") + yFormat.format(_yHome));
yOutput.reset();
}
break;
case Z:
words.push((method == "G28" ? "W" : "Z") + zFormat.format(_zHome));
retracted[Z] = true;
zOutput.reset();
break;
case XZ:
words.push((method == "G28" ? "U" : "X") + xFormat.format(_xHome));
words.push((method == "G28" ? "W" : "Z") + zFormat.format(_zHome));
retracted[X] = true;
retracted[Z] = true;
xOutput.reset();
zOutput.reset();
break;
default:
error(localize("Unsupported axis specified for writeRetract()."));
return;
}
}
for (var i = 0; i < words.length; ++i) {
switch (method) {
case "G28":
writeBlock(gFormat.format(28), singleLineRetract ? words : words);
break;
case "G53":
gMotionModal.reset();
writeBlock(gFormat.format(53), gMotionModal.format(0), singleLineRetract ? words : words);
break;
default:
error(localize("Unsupported safe position method."));
return;
}
if (singleLineRetract) {
break;
}
}
singleLineRetract = false; // singleLineRetract reset
}
Bottom line is that previous version (r43417) outputs X & Z, so one simple fix is to revert back. All the previous versions are available in the Fusion post library
cam.autodesk.com/hsmposts
43462 12/10/2021 Added the ability to specify the coolant codes as a text string.
43418 08/09/2021 Fixed undesired expansion of tapping cycle in generic turning posts.
Doing a file compare in VSC shows the 2 authors had different styles when it came to spaces and tabs, which accounts for most of the differences. I don't see any obvious major structural / content differences, so I wonder if the loss of G28 function was due to a subtle but unintentional formatting / syntax change due to insertion or deletion of a space in a critical statement. I may be forced to gradually swap out the differing content and repost my trial CAM file to see what is causing it....
Both posts contain the same section for outputting G28 in either XZ or UW, so I'm guessing something has been broken, preventing it from functioning as it originally did:
// format home positions
for (var i = 0; i < retractAxes.length; ++i) {
switch (retractAxes) {
case X:
words.push((method == "G28" ? "U" : "X") + xFormat.format(_xHome));
retracted[X] = true;
xOutput.reset();
break;
case Y:
if (yOutput.isEnabled()) {
words.push((method == "G28" ? "V" : "Y") + yFormat.format(_yHome));
yOutput.reset();
}
break;
case Z:
words.push((method == "G28" ? "W" : "Z") + zFormat.format(_zHome));
retracted[Z] = true;
zOutput.reset();
break;
case XZ:
words.push((method == "G28" ? "U" : "X") + xFormat.format(_xHome));
words.push((method == "G28" ? "W" : "Z") + zFormat.format(_zHome));
retracted[X] = true;
retracted[Z] = true;
xOutput.reset();
zOutput.reset();
break;
default:
error(localize("Unsupported axis specified for writeRetract()."));
return;
}
}
for (var i = 0; i < words.length; ++i) {
switch (method) {
case "G28":
writeBlock(gFormat.format(28), singleLineRetract ? words : words);
break;
case "G53":
gMotionModal.reset();
writeBlock(gFormat.format(53), gMotionModal.format(0), singleLineRetract ? words : words);
break;
default:
error(localize("Unsupported safe position method."));
return;
}
if (singleLineRetract) {
break;
}
}
singleLineRetract = false; // singleLineRetract reset
}
Last edit: 15 Dec 2021 22:21 by Muzzer.
Please Log in or Create an account to join the conversation.
16 Dec 2021 17:53 #229200
by Muzzer
Replied by Muzzer on topic Fusion 360 - EMC Post ?
I seem to have figured it out now. Between r43417 and r43470, somebody determined that a G28 must use U & W coordinates while G53 must use X & Z. Nobody knows why. Either way, they changed the section that outputs either G28 or G53 according to what you choose in the post processor dialog box. The original line said:
words.push((method == "G28","X") + xFormat.format(_xHome));
which was then replaced by
words.push((method == "G28" ? "U" : "X") + xFormat.format(_xHome));
The value of method is set by the dialog box to either "G28" or G53" and as you can see, a value of G28 will result in outputting a "U" prefix to the coordinate value set by _xHome. If you haven't selected G28 then you must have selected G53, in which case the ternary operator (the "?" term) results in an "X" prefix. Go figure.
So G28 forces a U coordinate and G53 by default results in an X coordinate. The answer is either to revert to r43417 or modify the post like this:
The commented out originals are shown in green, with the replacements directly below them.
words.push((method == "G28","X") + xFormat.format(_xHome));
which was then replaced by
words.push((method == "G28" ? "U" : "X") + xFormat.format(_xHome));
The value of method is set by the dialog box to either "G28" or G53" and as you can see, a value of G28 will result in outputting a "U" prefix to the coordinate value set by _xHome. If you haven't selected G28 then you must have selected G53, in which case the ternary operator (the "?" term) results in an "X" prefix. Go figure.
So G28 forces a U coordinate and G53 by default results in an X coordinate. The answer is either to revert to r43417 or modify the post like this:
The commented out originals are shown in green, with the replacements directly below them.
Attachments:
The following user(s) said Thank You: tommylight
Please Log in or Create an account to join the conversation.
05 Aug 2022 03:54 #249093
by nala
Replied by nala on topic Fusion 360 - EMC Post ?
Thanks for the answer, it's well explained and helped me a lot.
I am trying to create gcode using the EMC post in fusion 360 to use with linuxcnc.
I have a XP-Pen Deco 01 V2 drawing pad , it works as a mouse in Fusion 360 but does not activate it, does anybody know why ????
I am trying to create gcode using the EMC post in fusion 360 to use with linuxcnc.
I have a XP-Pen Deco 01 V2 drawing pad , it works as a mouse in Fusion 360 but does not activate it, does anybody know why ????
Please Log in or Create an account to join the conversation.
05 Aug 2022 21:06 #249159
by andypugh
It doesn't activate what?
Replied by andypugh on topic Fusion 360 - EMC Post ?
I am trying to create gcode using the EMC post in fusion 360 to use with linuxcnc.
I have a XP-Pen Deco 01 V2 drawing pad, it works as a mouse in Fusion 360 but does not activate it,
It doesn't activate what?
Please Log in or Create an account to join the conversation.
Moderators: Skullworks
Time to create page: 0.096 seconds