Removal of rapid moves breaks Glowforge post-processor

[johnaboiles]

Similar to other reports of all sorts of other post-processors breaking after rapid moves were removed, it appears the Glowforge Colorific post has broken as well.

I've seen similar posts about the `F0` gcode bug but this is somewhat different: It appears that travel moves are now being reported to post-processors as cutting movements (`MOVEMENT_CUTTING`, `MOVEMENT_REDUCED` or `MOVEMENT_FINISH_CUTTING`) based on the Glowforge Colorific code. Since this post-processor generates an SVG with different paths for each cutting operation in Fusion360, this causes travel moves to get included in the cutting path. Here's a post-process I ran last week vs one I ran this week (the diagonal lines are travel moves):

Here are the links I've gathered so far. They're all related to post-processors outputting a move with `F0`:

https://forums.autodesk.com/t5/fusion-360-support/personal-use-version-takes-away-rapid-moves-and-ma...
https://forums.autodesk.com/t5/fusion-360-manufacture/bug-drill-operation/td-p/9779575

https://forums.autodesk.com/t5/fusion-360-support/cam-on-personal-edition-broken-due-to-feed-rate-ch...

I'm also tracking potential workarounds in this issue:

https://github.com/garethky/glowforge-colorific-fusion360-post/issues/2

[engineguy]

@johnaboiles 

I would have thought that Autodesk have been pretty clear on this !!

If you don`t pay then no rapids and a few other things liketool changes for example.

Bad as that is it is now a "pay up" or "shut up shop" for some folks who have been making good money out of the FREE Fusion for a long time.

Because of their selfish antics it has now affected many genuine Hobbyists, wish I could get my hands on some of those so called hobbyists 😞 😞 😞

But that is life, there will always be a sizeable "minority" that live by the principle of "I don`t like that rule therefore it doesn`t apply to me", horribe but that`s life 😞 😞 😞

For the Price they are currently charging anyone who is actually serious about their Hobby should be happy to pay it!!

It is cheap!!!!!!!!!!

Stay Safe

Regards

Rob

[atherisinnovations]

The no rapids issue is not a problem for him, it is just that that structural change has resulted in the inclusion of artifacts to an exported SVG where there were none before. He is saying that the toolpaths when the tool is not engaged are being exported as part of an SVG that is supposed to be showing engaged toolpaths only, not position movements/rapids. That is further explained in the github link he posted.

I think this is due to the lines previously being stripped out by the post processor, probably flagged by a value that is no longer being reported, thus no longer stripped out..

[atherisinnovations]

So everyone is appropriately tagged, the above reply was to @engineguy , concerning an issue @johnaboiles is experiencing with tool positioning movements becoming artifacts that are embedded in exported/post-processed SVGs..

[daniel_lyall]

What @engineguy  said @atherisinnovations is correct glowforge had enough notices to get there postfixed, as it is as of an hour ago.

https://github.com/garethky/glowforge-colorific-fusion360-post

[johnaboiles]

Yeah I'm not so concerned about losing rapids, but it seems potentially problematic that Fusion360 no longer tells post-processors which moves are cutting moves and which moves are travel moves. I think I understand why they did this -- if processors could tell the difference easily they could trivially re-add rapids.

But I _think_ that's the case anyways. You can probably infer travel moves based on the Z-height or tool status and just have the processor interpret those moves as rapids. It just adds complexity and potential for bugs to the post-processors (bugs which could potentially also affect paid users of Fusion360).

[seth.madore]

All,

We're tracking all these cases where loss of rapids had unintended consequences. I can assure you, the intention was NOT to break things and make CAM useless. Due to the shear number of post processors and possible operations and all combinations, it's clear that this wasn't tested in every possible scenario. We're examining all possible solutions to this issue.

The abuse was real, and I'm with @engineguy , I'd love to sit and "chat" with those shops running businesses off of free software....

[tw_mdl]

@seth.madore  Thanks for looking into this!

I just wanted to add that the AutoCAD DXF post-processor shows the same problem and now includes travel moves which it has not done previously.

[dan.j.schneid]

Is there a suggested fix for affected postprocessors?  I'm helping maintain a custom post for an old Yasnac MX-3 controller.  On a bunch of operations, e.g., drilling, Fusion tries to call onRapid() even from personal use license holders.  Our existing onRapid is here, probably just the default IIRC:

function onRapid(_x, _y, _z) {
  var x = xOutput.format(_x);
  var y = yOutput.format(_y);
  var z = zOutput.format(_z);
  if (x || y || z) {
    if (pendingRadiusCompensation >= 0) {
      error(localize("Radius compensation mode cannot be changed at rapid traversal."));
      return;
    }
    writeBlock(gMotionModal.format(0), x, y, z);
    feedOutput.reset();
  }
}

 I've tried a bunch of edits, e.g.,  subbing in writeBlock(gMotionModal.format(1), x, y, z); and commenting out the whole function, and many others,  but I still get a F0. output whenever I call a drill op from a personal use license (commercial use license not affected).  Do you have any suggestions or should I just write a python post-post processor to clean this up until there is a bug fix for this?

[seth.madore]

What ever workaround you implement will likely be shortlived, as this issue is extremely high on our list and will be addressed as quickly as is humanly possible.

[johnaboiles]

@seth.madore thanks for chiming in and I'm glad to hear it's on y'all's radar! The author of Glowforge Colorific worked around the issue by skipping all moves while the laser is turned off (via `onPower`). This is probably a more resilient implementation anyways.

This post-processor generates an SVG, so there isn't any concept of a rapid move in its output. But what I don't understand is, what's to stop other post-processors from just re-adding rapids in a janky way? It seems like removing rapids might not be enforceable without breaking post-processors. For laser (or waterjet/plasma) gcode processors, you could do it by interpreting all moves with the tool off as rapids. For milling you could keep track of the Z height. From a product perspective, I don't have an issue with removing rapids from the free version, but from a technical perspective, it seems like it won't be enforceable and may incentivize post-processor authors to do hacky things to work around it.

Anyways, I look forward to seeing the compromise y'all come up with!

FWIW I'm also a paid user for work. But I don't use my work account for personal projects (which is mostly what I use my Glowforge for).

[dan.j.schneid]

Thanks, I'm just going the post-postprocessor python script direction until a official fix comes out.  I'm operating a CNC mill with late-80s/early-90s controller.  Everything to get that to work with modern software ends up pretty hacky.

I also have the commercial version for my commercial use, but I maintain a full-sized CNC mill and teach novice machinists at Nova Labs, a non-profit makerspace.  We're collateral damage on this update since probably 90% of the CNC mill jobs in our shop are teaching projects and true hobby projects like engraved graduation gifts, custom motorcycle parts, and pre-prototypes for an idea at the stage of $50 of metal and a twinkle in the eye.

It makes sense for me to maintain a commercial license since I use it all the time, but most of my students use it for my class and then maybe twice-a-year after that.  There may have been abuse, but this update is messing with a lot of folks that were relying on it and not abusing it.