Fixed Fusion360 Post Processor

[val]

Hello everyone,

I’ve noticed that when using the supplied Fusion 360 post-processor for the MR-1, the G-code for setting the plane, units, etc., is not always included in the subprograms when using multiple tools with the “Split File” option.

To fix this issue, you can add the following lines to the post-processor script below the call to redirectToFile on line 413:

function onSection() {
    // ... existing code ...

    if (splitHere) {
        // ... existing code ...

        redirectToFile(path);

       // ADDED: Reset modal variables to ensure G-code outputs in new subprograms
       gMotionModal.reset();
       gAbsIncModal.reset();
       gFeedModeModal.reset();
       gPlaneModal.reset();
       gUnitModal.reset();

        // ... existing code ...
    }

    // ... existing code ...
}

For those who prefer not to edit it themselves, you can download the file from my GitHub: Modified PostProcessor for Fusion360 for the MR-1 · GitHub

[brian_e]

Is there a way to pass the fusion tool comment (from the tool library) on to CutControl rather than it trying to read the T line? as example, I have many form mills that are custom profiles, and CutControl just displays that it is 0.231" form mill as example. or sometimes it shows a weird fraction, I.E. there 2.25" Fly cutter shows 11/5 face mill.

If I can put the tool setup info directly in the comment, then I could probably avoid having to use the fusion setup sheet.

[brian_e]

also, if you have the same tool used at the end of one setup, and is the same tool at the start of the next setup, fusion does not split it. I would like to have that happen, since I need to reposition the workpiece even though there is no actual tool change.

[AlexW]

@brian_e You can post each setup individually and that should get you unique files.

[brian_e]

I know that I CAN do that but I would someday LIKE to be able to use the split by tool function better. Even having the option to add a send to front command at the end of a tool would be awesome.

For now, I am doing split by tool, but only 1 setup at a time, so still have to post 6 times per part… which helps, a lot of my stuff is 6-10 tools per face., so posting each time would be 40-60 post routines and a LOT more clicks (and opportunities for human error forgetting to select an operation and post it…

There is another plugin for fusion that does it into folders (GitHub - TimPaterson/Fusion360-Batch-Post: Fusion add-in to post all CAM setups at once, optionally dividing them into folders.) that I am playing with to see if that will make it a clean 1 click routine to post all setups at once in a way that cut control can still understand.

[val]

Re: tool display in CutControl: You could update the post processor to give a more human readable tool format BUT CutControl is expecting the exact format. Looks like CutControl does render the name of the tool, so you could try putting more info in the name.

Re: Postprocessor splitting by OP rather than tool, this is something I was looking into the other day, still working on it - I am not seeing anything in the f360 api that allows you to detect when you are entering a new setup.

[brian_e]

so i did get the post updated to use the tool comment (from tool library/postprocessor/comment) and seems to work fine.

I’m also working on changing the “output M6” to be a “Send to Front” option.

[brian_e]

Alright folks, I’m fairly confident this is good, but as with anything else you get from the interwebz, use at your own risk.

Key Functions:

Removed Output Tool stuff as I don’t see where that is ever going to be used. It’s still there in the backend, just not shown on the front end.

Added options for end of file action: Auto Send to Front, Send to Home, or just Z Up. If nothing is selected, the tool machine just stops motion and stays where it was at, spindle on etc. If multiples are selected, Z Up has priority, then Front, then Home.

Send to Front location is independent of machine send to front macro, you set it in the post, so could be different for different setups.

All programs start with G53 Z0 as well, had a few close calls coming off the tool setter where tool was not high enough to clear something.

Changed the file comments so it displays the Post-Processor Tool Comment in Cut Control. Tool numbers can be whatever you want, there is essentially no upper limit. Fusion does seem (for whatever reason) to have an upper tool limit of 1316134911? A very off the wall number but whatever. If you have more than 1.3B Tools, you aren’t reading this.)

It does NOT split at setup change if the same tool is used at the end of one setup and start of next setup, however I have found that to be a rare use case, so I’m not digging into it.

Has val’s unit fix (above) for split files also.

https://tinyurl.com/ycxbbt4f

[brian_e]

Well I have already found my first bug, it is injecting the send to front (or whatever is selected) after each tool path, regardless of split options, even when using same tool from one path to the next. The bigger problem is that it does not call for spindle back on if spindle is same speed as previous path.

[brian_e]

Alight I finally got back at this, so far seems to work well.

Feedback is appreciated.
MR1_Custom_Post_v1.0.3.zip (10.5 KB)

[InPower_Concepts]

This is some awesome work. I have waited to dabble in some post editing, but would be starting from ground zero. I messed with this post, I love the tool info at the beginning of the file, saves some steps on double checking tool stick out. Also, the G53 Z0 after tool set, good move, couple close calls myself.

Unfortunately I am using the free version of Fusion since this is a hobby, so I couldn’t post multiple tools at one time to see the output. However, I wanted to try the send to front feature after one tool that has multiple tool paths.

First Piece of Feedback:
I think I am seeing the error you described in January. After my adaptive path the spindle is commanded off after the Z retract, it would then go into the contour path without the spindle on, which would obviously cause a crash. I try to bunch together multiple tool paths with one tool if I can, roughing and finishing as many features with the biggest endmill at the beginning of a part. Would be nice if the send to front section of code only went after all toolpaths are complete with a given tool and you are ready to make a tool change. Not sure if I interpreted the use instructions wrong, so I also have a screenshot of my settings before posting.

Second Piece of Feedback:
The send to front position settings, I assume these are in inches. Would be nice to either A) have a note in the dialog box that denotes the input as such or B) cooler method would be take the document units and convert this input (guess you would still have to know input units) to match the program units. I default design in inches, because America, but sometimes it does just make more sense to design and program in mm. In the particular part I tested this post with, the send to front command would send the spindle closer to home than the front because it is programmed in mm lol.

Again super nice work, just opening the post code made my head spin, can’t imagine editing it at the moment. Just curious are you doing this all your own interpretation of the code? I thought about feeding it to ChatGPT and seeing what it can do, but that might end up doing more harm than good.

[brian_e]

ChatGPT (not the free one )has done a lot of the heavy lifting, but it is still a lot of trial and error, and a little bit of skill.

RE: your first feedback, yes that is a bug, it is supposed to run all tool paths for 1 tool then perform the end of run function as selected for tool change, etc, should NOT be doing it between each tool path.

2nd point, I can probably add a note that position is in inches, but I don’t think I will go thru the trouble of SAE vs Metric, that is actually quite a bit of code to do a (IMO) cosmetic feature.

[InPower_Concepts]

This motivated me to take a stab at this. I tried implementing the changes I mentioned above. On the test I did earlier I was able to have the tool go through all tool paths before inputting the Send to Front code. I also have a note for the send to front dimensions being in inches and the post will add a G20 line to switch the machine back to inches before sending to front. Did a test on the machine over the weekend and it worked. Looking at the code in-depth it seems like the post is back to using a G28 for the Z retract, which I don’t think is the end of the world, but I must have inadvertently changed something that got rid of the always using G53, even for the Z retract.

These simple edits make the work flow so much easier. Would be nice to find a way to command the machine to do a tool touch off and then go right into the program after a tool change, but I think that has a lot more to do with the cut control side than the g code side unfortunately. One button click per tool change would be a nice setup, but this post eliminated several at least. No more send to front after the program is finished, no having to Z up after tool touch off to start the program and tool stick out information is right there in the main program for you.

MR1 Fusion Post CutControl-v1.0.4.zip (410.4 KB)

[brian_e]

for the ATS and other commands the cut control requires you to basically do docusign and captcha workflow…

a 10 button macro pad and autohotkey work well. I just built macros for common commands (like ATS) that click on the buttons, wait, then click on the ok popup. Can also add in mappings for other functions that already have hotkeys, like start / pause, etc.

Also have a wireless NES controller as a jog wheel…