Feature Request: Add setting to ignore M5 for 'program splitting'

Hi Tim,

I found your batch processor after searching on how to overcome the tool change limitation in Fusion360. In my old (subscribed) version of Fusion360 I used to be able to generate a single file and I really miss this as manually editing files is becoming a bit of a bore.

I've installed your processor and got it working, but unfortunately it is throwing up an issue with my post processor...

0 files were written. 2 Setups were skipped due to error:
Failed on setup PROFILE_CUT: Tool change G-code (Txx) not found; this post processor is not compatible with Post Process All.
Failed on setup SPOT_MARK: Tool change G-code (Txx) not found; this post processor is not compatible with Post Process All.

Obviously it is complaining that there are no Tool Change commands in the output (which is true). My setup is a plasma table and does not physically change tools, however it does use a drilling operation in Fusion360 to perform 'Spot Marking' to centre mark where holes need to be drilled. So essentially I use two 'virtual' tools - one to generate the spot marks and the other to cut the profile. I chose to omit the physical tool change from my post processor as it is essentially redundant, however it is now preventing me from using your code and I need to add it back in.

As I wrote the post processor I can easily edit it to generate what your post processor expects to see, however exactly what it wants is unclear. So I would like to ask for some advice in fixing it.

Do I just add a T01 / T02 command at the top of each generated NC file? and is there a preference for where this line is located within the generated output? (After the G64 command perhaps?)

I've included an example output below

(--- Created by DeeEmm DDCSV Plasma Post Processor ---)
(--- https://github.com/DeeEmm/DDCSV11-Plasma ---)
(--- Program: BASE_GUSSET ---)
(--- 6MM-HOT-ROLLED ---)
(--- Workpiece:   0.000 <= X <= 60.000 | 0.000 <= Y <= 56.000 | -6.000 <= Z <= 0.000 ---)
(--- Tool travel: 3.000 <= X <= 63.905 | 3.000 <= Y <= 53.000 | 0.000 <= Z <= 15.000 ---)
(--- Safe Z: 15.000 ---)
G90
M5
(--- Units: millimeters ---)
G21
G64 P0.0254
(--- Setup #1 ---)
G00 X26.483 Y19.905
G00 X26.483 Y19.905
(--- [START] Probe Z Axis: 40mm @ 300mm/s and add -2.35mm floating head offset ---)
G4 P0
M101
G91
G91 Z-40 F300
M102
G4 P0
M103
G91 Z40 F300
M102
G4 P0
G90
G4 P0
G92 Z-2.35
G4 P0
(--- [END] Probe Z ---)
(--- [START] Cut Path - Operation #1 @ 5mm Pierce Height & 1.5mm Cut Height with 2500ms Pierce Delay ---)
G0 Z5 F1800
F75
S500 M3
F75
G4 P2500
F75
G0 Z 1.5 F75
F75
(--- Pierced and cutting ---)
F300
G01 X25.552 Y19.368F300
G01 X28.052 Y15.038
G03 X31.581 Y13.000 I3.529 J2.038
G01 X45.000 Y13.000
G03 X47.000 Y15.000 I0.000 J2.000
G01 X47.000 Y36.000
G03 X45.000 Y38.000 I-2.000 J0.000
G01 X15.000 Y38.000
G03 X13.000 Y36.000 I0.000 J-2.000
G01 X13.000 Y15.000
G03 X15.000 Y13.000 I2.000 J0.000
G01 X31.581 Y13.000
G03 X35.110 Y15.038 I0.000 J4.075
G01 X37.610 Y19.368
G01 X36.679 Y19.905
(--- [END] Cut Path - Operation #1 ---)
F1800
M5
G0 Z 5
G4 P 1500
G00 X36.679 Y19.905
G00 X63.905 Y51.833
G00 X63.905 Y51.833
(--- [START] Probe Z Axis: 40mm @ 300mm/s and add -2.35mm floating head offset ---)
G4 P0
M101
G91
G91 Z-40 F300
M102
G4 P0
M103
G91 Z40 F300
M102
G4 P0
G90
G4 P0
G92 Z-2.35
G4 P0
(--- [END] Probe Z ---)
(--- [START] Cut Path - Operation #2 @ 5mm Pierce Height & 1.5mm Cut Height with 2500ms Pierce Delay ---)
G0 Z5 F1800
F75
S500 M3
F75
G4 P2500
F75
G0 Z 1.5 F75
F75
(--- Pierced and cutting ---)
F300
G01 X63.368 Y52.764
G01 X59.037 Y50.264
G03 X57.000 Y46.735 I2.038 J-3.529
G01 X57.000 Y3.000
G01 X3.000 Y3.000
G01 X3.000 Y53.000
G01 X57.000 Y53.000
G01 X57.000 Y46.735
G03 X59.037 Y43.206 I4.075 J0.000
G01 X63.368 Y40.706
G01 X63.905 Y41.637
(--- [END] Cut Path - Operation #2 ---)
F1800
M5
G0 Z 5
G4 P 1500
G00 X63.905 Y41.637
(--- JOB FINISH ---)
G00 Z15.000
M5
M2

Any help / insight warmly welcomed.

With thanks in advance.

/DM

Ok.

I added an arbitrary Tool change command into my post processor and the error has gone away, however it does not combine the files, I get two seperate files generated, which is the same behavior without the plugin enabled. I also get the same result regardless of settings in the plugin.

If I try to enable multiple operations within one NC output (As you normally would in the licensed version) it generates the regular fusion error...

When using Fusion 360 for Personal Use, you cannot post process operations that contain tool changes in a single NC program... etc

So I'm a bit confused.

Normally highlighting the NC root folder and hitting post process generates separate files... one for each NC program

Which is the same behaviour that I am getting from the plugin. I assumed that "Fixing tool change restriction in Fusion 360 for Personal Use" would return it's native behaviour of generating a single file that contains all NC programs with associated tool changes. Is this not the case? or am I using this incorrectly?

With thanks in advance.

/DM

Ok.

Some more testing...

I created both operations under a single setup...

Previously I had a seperate setup for each operation which was not being picked up by the plugin.

Doing this has ended up with a single file being created, which does require the plugin to overcome the tool change limitation as otherwise I am unable to run the post processor, however I now have another issue: Whilst a single file is now being created, the individual operation order within the file is not being preserved.

Instead of spot marking all holes, cutting the inner profile and finally the outer profile what it does is spot mark one hole, then cut the inner profile, then spot mark the remaining three holes and ignore the outer profile altogether. The two setups are being merged partially and incorrectly.

I've tried adding a G28 to the end of each separate operation but the result is the same.

I feel I'm getting a little closer but not understanding exactly what the plugin is looking for, or what it might inadvertently be detecting as a file end, is proving challenging to decypher.

For reference I've included the separately generated files below, along with the generated output from the plugin.

SPOT MARK PROGRAM

(--- Created by DeeEmm DDCSV Plasma Post Processor ---)
(--- https://github.com/DeeEmm/DDCSV11-Plasma ---)
(--- Program: SPOT_MARK ---)
(--- Workpiece:   0.000 <= X <= 83.664 | 0.000 <= Y <= 100.721 | -6.000 <= Z <= 0.000 ---)
(--- Tool travel: 14.750 <= X <= 69.206 | 15.111 <= Y <= 85.958 | -6.000 <= Z <= 15.000 ---)
(--- Safe Z: 15.000 ---)
G90
M5
(--- Units: millimeters ---)
G21
G64 P0.0254
T3 M6
(--- Setup #1 ---)
G00 X63.750 Y15.111
(--- Operation #1 Move to Spot Mark Location ---)
G0 X63.75 Y15.110631942749023
(--- [START] Probe Z Axis: 40mm @ 300mm/s and add -2.35mm floating head offset ---)
G4 P0
M101
G91
G91 Z-40 F300
M102
G4 P0
M103
G91 Z40 F300
M102
G4 P0
G90
G4 P0
G92 Z-2.35
G4 P0
(--- [END] Probe Z ---)
(--- [START] Spot Mark - Operation #1 @ 1.5mm Spot Height with 400ms Spot Mark Duration ---)
S500 M3
G0 Z 1.5 F125
G4 P400
M5
(--- [END] Spot Mark - Operation #1 ---)
F1800
M5
G0 Z 5
G4 P 1500
(--- Operation #2 Move to Spot Mark Location ---)
G0 X14.75 Y15.110631942749023
(--- [START] Probe Z Axis: 40mm @ 300mm/s and add -2.35mm floating head offset ---)
G4 P0
M101
G91
G91 Z-40 F300
M102
G4 P0
M103
G91 Z40 F300
M102
G4 P0
G90
G4 P0
G92 Z-2.35
G4 P0
(--- [END] Probe Z ---)
(--- [START] Spot Mark - Operation #2 @ 1.5mm Spot Height with 400ms Spot Mark Duration ---)
S500 M3
G0 Z 1.5 F125
G4 P400
M5
(--- [END] Spot Mark - Operation #2 ---)
F1800
M5
G0 Z 5
G4 P 1500
(--- Operation #3 Move to Spot Mark Location ---)
G0 X14.75 Y85.61063385009766
(--- [START] Probe Z Axis: 40mm @ 300mm/s and add -2.35mm floating head offset ---)
G4 P0
M101
G91
G91 Z-40 F300
M102
G4 P0
M103
G91 Z40 F300
M102
G4 P0
G90
G4 P0
G92 Z-2.35
G4 P0
(--- [END] Probe Z ---)
(--- [START] Spot Mark - Operation #3 @ 1.5mm Spot Height with 400ms Spot Mark Duration ---)
S500 M3
G0 Z 1.5 F125
G4 P400
M5
(--- [END] Spot Mark - Operation #3 ---)
F1800
M5
G0 Z 5
G4 P 1500
(--- Operation #4 Move to Spot Mark Location ---)
G0 X69.20577239990234 Y85.95813751220703
(--- [START] Probe Z Axis: 40mm @ 300mm/s and add -2.35mm floating head offset ---)
G4 P0
M101
G91
G91 Z-40 F300
M102
G4 P0
M103
G91 Z40 F300
M102
G4 P0
G90
G4 P0
G92 Z-2.35
G4 P0
(--- [END] Probe Z ---)
(--- [START] Spot Mark - Operation #4 @ 1.5mm Spot Height with 400ms Spot Mark Duration ---)
S500 M3
G0 Z 1.5 F125
G4 P400
M5
(--- [END] Spot Mark - Operation #4 ---)
F1800
M5
G0 Z 5
G4 P 1500
G00 X69.206 Y85.958
(--- JOB FINISH ---)
G00 Z15.000
G28 Z15.000
M5
M2

PROFILE CUT PROGRAM

(--- Created by DeeEmm DDCSV Plasma Post Processor ---)
(--- https://github.com/DeeEmm/DDCSV11-Plasma ---)
(--- Program: PROFILE_CUT ---)
(--- Workpiece:   0.000 <= X <= 83.664 | 0.000 <= Y <= 100.721 | -6.000 <= Z <= 0.000 ---)
(--- Tool travel: 3.000 <= X <= 80.664 | -3.905 <= Y <= 97.721 | 0.000 <= Z <= 15.000 ---)
(--- Safe Z: 15.000 ---)
G90
M5
(--- Units: millimeters ---)
G21
G64 P0.0254
T1 M6
(--- Setup #1 ---)
G00 X44.871 Y70.653
G00 X44.871 Y70.653
(--- [START] Probe Z Axis: 40mm @ 300mm/s and add -2.35mm floating head offset ---)
G4 P0
M101
G91
G91 Z-40 F300
M102
G4 P0
M103
G91 Z40 F300
M102
G4 P0
G90
G4 P0
G92 Z-2.35
G4 P0
(--- [END] Probe Z ---)
(--- [START] Cut Path - Operation #1 @ 4.5mm Pierce Height & 1.5mm Cut Height with 2800ms Pierce Delay ---)
G0 Z4.5 F1800
F125
S500 M3
F125
G4 P2800
F125
G0 Z 1.5 F125
F125
(--- Pierced and cutting ---)
F325
G01 X45.817 Y71.164F325
G01 X43.441 Y75.563
G03 X39.972 Y77.700 I-3.586 J-1.936
G03 X38.528 Y27.021 I-0.722 J-25.340
G03 X39.972 Y77.700 I0.722 J25.340
G03 X36.386 Y75.764 I-0.116 J-4.073
G01 X33.764 Y71.507
G01 X34.679 Y70.943
(--- [END] Cut Path - Operation #1 ---)
F1800
M5
G0 Z 5
G4 P 1500
G00 X34.679 Y70.943
G00 X43.894 Y-3.905
G00 X43.894 Y-3.905
(--- [START] Probe Z Axis: 40mm @ 300mm/s and add -2.35mm floating head offset ---)
G4 P0
M101
G91
G91 Z-40 F300
M102
G4 P0
M103
G91 Z40 F300
M102
G4 P0
G90
G4 P0
G92 Z-2.35
G4 P0
(--- [END] Probe Z ---)
(--- [START] Cut Path - Operation #2 @ 4.5mm Pierce Height & 1.5mm Cut Height with 2800ms Pierce Delay ---)
G0 Z4.5 F1800
F125
S500 M3
F125
G4 P2800
F125
G0 Z 1.5 F125
F125
(--- Pierced and cutting ---)
F325
G01 X44.825 Y-3.368
G01 X42.325 Y0.962
G03 X38.796 Y3.000 I-3.529 J-2.038
G01 X15.000 Y3.000
G02 X3.000 Y15.000 I0.000 J12.000
G01 X3.000 Y85.721
G02 X15.000 Y97.721 I12.000 J0.000
G01 X68.664 Y97.721
G02 X77.221 Y77.309 I0.000 J-12.000
G03 X75.500 Y73.103 I4.279 J-4.206
G01 X75.500 Y15.000
G02 X63.500 Y3.000 I-12.000 J0.000
G01 X38.796 Y3.000
G03 X35.267 Y0.962 I0.000 J-4.075
G01 X32.767 Y-3.368
G01 X33.698 Y-3.905
(--- [END] Cut Path - Operation #2 ---)
F1800
M5
G0 Z 5
G4 P 1500
G00 X33.698 Y-3.905
(--- JOB FINISH ---)
G00 Z15.000
G28 Z15.000
M5
M2

And finally the output generated by the plugin

COMBINED PROGRAM

(--- Created by DeeEmm DDCSV Plasma Post Processor ---)
(--- https://github.com/DeeEmm/DDCSV11-Plasma ---)
(01 PROFILE_CUT ---)
(--- Workpiece:   0.000 <= X <= 83.664 | 0.000 <= Y <= 100.721 | -6.000 <= Z <= 0.000 ---)
(--- Tool travel: 14.750 <= X <= 69.206 | 15.111 <= Y <= 85.958 | -6.000 <= Z <= 15.000 ---)
(--- Safe Z: 15.000 ---)
G90
M5
(--- Units: millimeters ---)
G21
G64 P0.0254
T3 M6
(--- Setup #1 ---)
G00 X63.750 Y15.111
(--- Operation #1 Move to Spot Mark Location ---)
G0 X63.75 Y15.110631942749023
(--- [START] Probe Z Axis: 40mm @ 300mm/s and add -2.35mm floating head offset ---)
G4 P0
M101
G91
G91 Z-40 F300
M102
G4 P0
M103
G91 Z40 F300
M102
G4 P0
G90
G4 P0
G92 Z-2.35
G4 P0
(--- [END] Probe Z ---)
(--- [START] Spot Mark - Operation #1 @ 1.5mm Spot Height with 400ms Spot Mark Duration ---)
S500 M3
G0 Z 1.5 F125
G4 P400

(--- Units: millimeters ---)
M6
T1 M6
(--- Setup #1 ---)
G00 X44.871 Y70.653
G00 X44.871 Y70.653
(--- [START] Probe Z Axis: 40mm @ 300mm/s and add -2.35mm floating head offset ---)
G4 P0
M101
G91
G91 Z-40 F300
M102
G4 P0
M103
G91 Z40 F300
M102
G4 P0
G90
G4 P0
G92 Z-2.35
G4 P0
(--- [END] Probe Z ---)
(--- [START] Cut Path - Operation #1 @ 4.5mm Pierce Height & 1.5mm Cut Height with 2800ms Pierce Delay ---)
G0 Z4.5 F1800
F125
S500 M3
F125
G4 P2800
F125
G0 Z 1.5 F125
F125
(--- Pierced and cutting ---)
F325
G01 X45.817 Y71.164F325
G01 X43.441 Y75.563
G03 X39.972 Y77.700 I-3.586 J-1.936
G03 X38.528 Y27.021 I-0.722 J-25.340
G03 X39.972 Y77.700 I0.722 J25.340
G03 X36.386 Y75.764 I-0.116 J-4.073
G01 X33.764 Y71.507
G01 X34.679 Y70.943
(--- [END] Cut Path - Operation #1 ---)
F1800
M5
(--- [END] Spot Mark - Operation #1 ---)
F1800
M5
G0 Z 5
G4 P 1500
(--- Operation #2 Move to Spot Mark Location ---)
G0 X14.75 Y15.110631942749023
(--- [START] Probe Z Axis: 40mm @ 300mm/s and add -2.35mm floating head offset ---)
G4 P0
M101
G91
G91 Z-40 F300
M102
G4 P0
M103
G91 Z40 F300
M102
G4 P0
G90
G4 P0
G92 Z-2.35
G4 P0
(--- [END] Probe Z ---)
(--- [START] Spot Mark - Operation #2 @ 1.5mm Spot Height with 400ms Spot Mark Duration ---)
S500 M3
G0 Z 1.5 F125
G4 P400
M5
(--- [END] Spot Mark - Operation #2 ---)
F1800
M5
G0 Z 5
G4 P 1500
(--- Operation #3 Move to Spot Mark Location ---)
G0 X14.75 Y85.61063385009766
(--- [START] Probe Z Axis: 40mm @ 300mm/s and add -2.35mm floating head offset ---)
G4 P0
M101
G91
G91 Z-40 F300
M102
G4 P0
M103
G91 Z40 F300
M102
G4 P0
G90
G4 P0
G92 Z-2.35
G4 P0
(--- [END] Probe Z ---)
(--- [START] Spot Mark - Operation #3 @ 1.5mm Spot Height with 400ms Spot Mark Duration ---)
S500 M3
G0 Z 1.5 F125
G4 P400
M5
(--- [END] Spot Mark - Operation #3 ---)
F1800
M5
G0 Z 5
G4 P 1500
(--- Operation #4 Move to Spot Mark Location ---)
G0 X69.20577239990234 Y85.95813751220703
(--- [START] Probe Z Axis: 40mm @ 300mm/s and add -2.35mm floating head offset ---)
G4 P0
M101
G91
G91 Z-40 F300
M102
G4 P0
M103
G91 Z40 F300
M102
G4 P0
G90
G4 P0
G92 Z-2.35
G4 P0
(--- [END] Probe Z ---)
(--- [START] Spot Mark - Operation #4 @ 1.5mm Spot Height with 400ms Spot Mark Duration ---)
S500 M3
G0 Z 1.5 F125
G4 P400
M5
(--- [END] Spot Mark - Operation #4 ---)
F1800
M5
G0 Z 5
G4 P 1500
G00 X69.206 Y85.958
(--- JOB FINISH ---)
G00 Z15.000
G28 Z15.000
M5
M2

As you can see, the combined program generated by the plugin is not the sum of the two seperate parts. There is a gap in the code at line 37, this is where the Profile code is being incorrectly inserted, this carries on until line 80, completing the first cut path before swapping back to finish off the remaining spot mark holes. Very bizarre.

(Sorry about the verbosity, but figured that you'd need to see the complete outputs to understand what's happening)

Any ideas?

/DM

Have you looked at the code for PostProcessAll? At line 920 it details the format it is looking for:

            # Parse the gcode. We expect a header like this:
            #
            # % <optional>
            # (<comments>) <0 or more lines>
            # (<Txx tool comment>) <optional>
            # <comments or G-code initialization, up to Txx>
            #
            # This header is stripped from all files after the first,
            # except the tool comment is put in a list at the top.
            # The header ends when we find the body, which starts with:
            #
            # Txx ...   (optionally preceded by line number Nxx)
            #
            # We copy all the body, looking for the tail. The start
            # of the tail is marked by one of these:
            # M30 - end program
            # M5 - stop spindle
            # M9 - stop coolant
            # The tail is stripped until the last operation is done.

You've included a lot of code and I haven't looked at any of it. If your output follows the above rules but doesn't get a proper result, you should create a minimal example that reproduces the problem. Since you can write your own post processor, I would think you could debug it yourself using Visual Studio Code and the instructions here:

https://modthemachine.typepad.com/my_weblog/2019/09/debug-fusion-360-add-ins.html

If you want me to look into it, I would need your Fusion 360 project file (.f3z) and the post processor you're using so I could reproduce it.

Thanks for the reply Tim,

Unfortunately I do not use Visual Studio as I am on a Mac but taking a look at the PostProcessAll snippet you have quoted seems to answer my question...

I would suspect that if you are testing for the presence of M5 to determine where to split the files then this is actually the cause of the issue. The plasma process uses M5 to operate the torch and so has several M5 commands within each program. This would explain why it has split the program the way it has.

Is there a way to ignore M5 and detect on M30, M2 (both program end) or M2 (sub program end)?

Using M5 will also exclude many styles of machines from working with your code (plasma / laser / waterjet / drag knife / 3D Printers / pen plotters / etc) as they all use M5 to control the tool, whatever the tool may be. A pen plotter is another good example. The pen moves up and down many times per program, but it only calls a tool change when it needs to swap the pen to a different colour.

Being able to select this in the settings on your code would be an ideal solution. I'll change this to a feature request.

Best regards

/DM

Taking a quick look through your code I can see that you have broken out the end codes into an array so I was easily able to remove M5 from the search by removing it from the array...

constEndMcodeSet = {9,30}

This has corrected the output, however I note that there is a space placed between the combined sections.

With my NC controller processing is stopped when it encounters a space. I believe this is not uncommon.

So I have commented out the following...

            # Space between operations
           # if not fFirst:
            #    fileBody.write("\n")

Which has fixed that issue. Not really sure why a space is needed, a comment would suffice for readability.

So now the output looks as expected. (Yay!) I'm about to go and run some parts so will let you know if it works on the machine.

So from a usability perspective, the addition of user selectable end terminators (constEndMcodeSet) would allow this to work on many other machines that use M5 as an on-off control for things like lasers / engravers/ plasma / water-jets / etc.

I'm not sure how prevalent the space issue is, but it is something that I have come across with several machines.

Keep up the great work and thanks for taking the time to make this plugin.

/DM

Just an update.

I ran some parts but soon found out that using arbitrary tool values caused an issue with my z height when changing between the combined sections (I obviously should have expected this behavior - different tools have different lengths), so I changed all tools to use the same tool number (in the post processor section of tool>edit). Fortunately the plugin still detects the tool changes and joins the code together as before.

Assigning the same tool numbers has the added bonus that the post processor actually ignores the tool change altogether as the number is the same as the previous section - so it does not insert the TXX command in the output. This is desired behaviour in this case as we don't really want to change the physical tool, we just want the plugin to pick the tool change up.

Win-Win.

I think that this should work in the same manner with other plasma tables. Using a drilling operation for spot marking is a common workaround for marking out holes that are too small to cut. It's certainly not a method I invented.

/DM

I'm glad you've figured out how to get it working for you. I'd like to mention that Visual Studio Code is fully muli-platform and available for Mac (and Linux). Despite the name, it is not related to Visual Studio.

If you're using the same tool number, doesn't that eliminate the Fusion 360 tool-change limitation? If it doesn't see a tool change in a setup it should do the whole thing. In PostProcessAll, you would uncheck "Use individual operations" and my G-code parser wouldn't be used at all. This returns PostProcessAll to its original job of doing all setups at once instead of one setup at a time.

The blank line is there because all the post processors in my compatibility table add them between operations for readability, and my G-code parser was taking it out.

If you're using the same tool number, doesn't that eliminate the Fusion 360 tool-change limitation

No, each operation still uses a different tool within Fusion360 (spot drill + plasma cutter in my case), it is just the tool number that it sends to the post processor that is the same. This is simply a setting within each tool configuration.

Fusion see's the Cut Profile [Tool 1] and Drill Op [Tool 1] as separate operations with different tools, yet each operation sends Tool 1 to the post processor...

Using a single tool number means that there are no tool number changes added to the generated output as the post processor will only add a tool change command when it sees a different tool number passed to it. This prevents tool offset changes which are unwanted on a plasma.

What I have noticed with my post processor is that even when they are added, Fusion does not strip these Tool change (Txx) commands out, however despite the absence of tool changes within the generated output Fusion still will not combine the separate ops into one file. I suspect that it is the separate input operations that Fusion actually detects, it's just the warning message mentions tool numbers. it's a little bit misleading. In the real world we talk about machining operations, and Fusion 360 is no different.

So it is also worth noting that this limitation also applies to different setups and operations too. i.e. if you use a different operation under the same job it will throw up an error relating to using a different WCS, even if it's actually using the same WCS and tool, this will also not combine outputs under the free version but does so without issue under the subscribed version. Hence my suspicion that it's actually looking at the operations.

Basically Fusion is looking at the process inputs to determine whether to combine them. If you are using the free version and it has more than one input (i.e setup or operation - remembering that operations = tools) then it will throw up an error message and require you to send each input to the post processor separately.

Your code bypasses the Fusion pre-processor altogether and directly interrogates the inputs thus bypassing these limitations.

RE: Visual Studio. I prefer to use Python via the terminal, plus there's no way I would allow any Microsoft products anywhere near my machine, I would rather drive red hot pokers into my eyes. (yes I am aware that M$ bought Github 😄 ).

Regarding the feature request

I think that passing the choice of whether to detect M5 and include spaces to the user is the best option. Obviously I can easily hack the code to do what I need for my own setup, but there are many others out there who do not possess this ability that would benefit from being able to use your Add-In.

I've forked your repo and hard-coded those changes so that others using my post processor will be able to use your work but I think it would be much nicer to wrap those changes up in the UI as user settings. After all it's massively expanding the list of supported machines.

If I get a chance I'll take a look at updating your UI on my fork and sending you a push request, but TBH I am really tied up with other projects at the moment and cannot say if / when this might happen.

BTW I've given you a shout out... https://deeemm.com/cnc/2021/08/13/Fusion-360-plasma-combining-files.html

and added a heads-up to my fork... https://github.com/DeeEmm/Fusion360-Batch-Post/blob/master/README.md

There is already an option to use G28/G30 as an end mark, so rather than just add more individual options I put in a box that lets you specify exactly which G-codes are end marks. I didn't add anything to the ReadMe about this, thinking the tool tip was enough.

Instead of adding an option for allowing blank lines, it chooses to allow them if a blank line has been seen before hitting the first tool change. I did try it with your post processor (the only one I found that did not put out blank lines), and it seemed to work.

Please give it a try and let me know if everything works or not. Close the issue if you like it.

I was wondering where you draw the line: Do you allow programs written with Microsoft tools on your computer? Programs written by former Microsoft engineers? 😊

That's fantastic Tim, I'll give it a go later this week.

I will concede that I do actually have office for mac installed, simply as I need it to be able to deal with client documents, but it is no end of pain to me. Every time I use it, it wants an update, every update is massive in size. If I use Excel the computer will eventually lock up or panic, or other apps experience weird glitchy issues. It's a like a gentle reminder of why I left Windows behind - remember those good old days with the BSOD...

Personally, having developed in VB6 and VS as well as developing software in edge cases on the M$ platform I think that it's the way that the apps are written, they have poor memory management and are full of leaks, excel being one of the worst examples. They are developed for an environment that has an infinite number of hardware permutations and developed for a price, and so are always at a compromise. Whereas native Mac apps are written for a very small number of hardware configurations and are more optimized, hence working faster and with exponentially less issues.

The general software architecture is just bad. It's not *nix based and so does not benefit from the wealth of contributions that go with that, or the decades of evolvement, Windows is essentially a really bad core that has endless security patches and fixes applied just to make it work.

Ever connected a vanilla copy of XP with no firewall or antivirus to the internet and watched it get taken over within seconds? It's quite scary how bad it was. It's very scary that even today you absolutely MUST use a third party firewall and virus program with Windows and yet no one asks themselves why. It is completely normalised.

Why does no one ever stop to think 'I've just bought a brand now OS, why is it that the first thing that I need to do is secure it'? The architecture is fundamentally flawed.

Why does no one ever to to think 'my new vanilla machine was really fast, but now I've installed a firewall and real-time virus scanner it's as slow-as' Performance benchmarks are rarely set with such software installed.

Am I biased? probably. But I happily used Windows from back in the 2.1 days and used it for may years developing industrial software. I used it right up until I bought a machine with Vista on it. I lasted a day before replacing it with Ubuntu and moving permanently away from Windows to Linux. Vista was that bad.. Eventually someone gave me a Macbook and I then realised why they are twice the price of your average Windows machine. They are literally twice as good. Everything just works. I haven't looked back since. I still use a virtual machine for PLC work as no one natively supports Mac, and ironically it's heaps faster than a native install. Fortunately it rarely gets used nowadays so the only time I have to endure M$ induced pain is using Office.

Perhaps Windows is better nowadays, but I seriously doubt it. M$ are still up to their old tricks of pulling in the opposite direction from everyone else. ODF is a prime example. Why not adopt the open source formats that were already in place? Typically M$ do their own thing with disregard for whoever they tread on. If they have absolutely control then they can monetise it. With M$ it's all about the dollar whereas with Apple it's always been about the user experience, hence the higher cost as they don't stop until they have it right. Of course I will concede that there are degrees of 'right', as it is very subjective, but I can say with confidence that you will never hear the phrase 'they just got it right' associated with a M$ product.

So to answer your question, it's the philosophy that M$ employs that is flawed. I'm sure the engineers are as good as any others but that philosophy is core to M$'s principles and so flows through everything they do. When you make anything to a price it is compromised somewhere. 95% of the users will never come across that compromise, but when you use something daily and push it's limits you can guarantee you'll come across that flaw every single day, and it starts to wear thin very quickly, especially when you measure productivity tools in terms of productivity.

/rant

😄

@TimPaterson Just tried this today. The output looks good, there's no spaces in there and the separate operations have been stitched together in the correct order.

I will run some parts this arvo and let you know how it goes.

Cheers.

/DM

@TimPaterson The parts ran well with no issues. Definitely a success.

Thank you for adding this, very much appreciated.

/DM

TimPaterson / Fusion360-Batch-Post