Fusion 360 - EMC Post ?

Muzzer wrote:

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. 

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.

Are you sure ?

I have checked cam.autodesk.com/hsmposts

It seem to continu to use UW ???

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
}
 

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.

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 ????