Tool orientation / aggregate-ready postprocessor

[jheinzmann]

Hi all, 

I am looking for somebody with experience using the 'tool orientation' feature in CAM, maybe using aggregates on the machine. Myself I have been using Fusion for a few years now, and was aware that the 'tool orientation' feature exists. I am working now on a project that requires this feature, and I assumed it would be not too much trouble to get it working. In fact, within Fusion everything works just great, toolpaths get generated correctly and the simulation looks all good to go. 

However, once I tried to postprocess these toolpaths, the following picture unfolded. My postprocessor failed to execute and bailed out with an error message, as do most other standard post processors. There are 17 standard postprocessors in the list which don't bail out, eight of them generate G-code which my machine controller can digest, and I tried every single one of them. 

The result is that these eight postprocessors simply ignore the error most postprocessors detect correctly and simply output a G-code file as if the tool orientation was 'standard'. So no help here at all. 

I then ran the the toolpaths through the 'Dumper' postprocessor to check out what Fusion is actually spitting out. The following is from the created .dmp file: 

  335: onSection()
    currentSection.unit=1
    currentSection.workOrigin=(0, 0, 0)
    currentSection.workPlane=[[1, 0, 0], [0, 0, -1], [0, 1, 0]]
    currentSection.wcsOrigin=(0, 0, 0)
    currentSection.wcsPlane=[[1, 0, 0], [0, 1, 0], [0, 0, 1]]
    currentSection.workOffset=0
    currentSection.dynamicWCSOrigin=(0, 0, 0)
    currentSection.dynamicWCSPlane=[[1, 0, 0], [0, 1, 0], [0, 0, 1]]
    currentSection.dynamicWorkOffset=0
    currentSection.fcsOrigin=(214.232, 36.6666, -5.70985e-14)
    currentSection.fcsPlane=[[1, 0, 0], [0, 1, 0], [0, 0, 1]]

The highlighted line in red correctly lists the rotation of my WCS by 90º, so Fusion appears to output all the information a post would need to create the correct G-code file. It just appears that not a single post in the list of standard posts takes the work plane information, creates a rotation matrix and rotates the coordinates accordingly (strictly speaking one would want a proper 4x4 coord transform which includes the origin transformation as well). I get that implementing this will slow the post down marginally for the 99% of users who use standard tool orientation, but I image that there must be some users out there with a machine with aggregate heads? Anybody? 

If there is anybody out there who has worked out how to make this work (maybe I'm missing something here), or if there is somebody out there who extended a G-code post to include the coordinate transformation for aggregates please get in contact with me. Alternatively, if you are a crack postprocessor coder and fancy creating a generic G-code post which is aggregate ready and you feel generous with your time I would love to hear from you!

Many thanks!

Cheers,

Jochen

PS: I am aware that circular and helical motions won't be able to be translated in any other way than linear approximations, but that would do me just fine. I just need the machine to run this path, even if the G-code file is lengthy. 

[jheinzmann · Accepted solution]

Ok, after a bit of DIY tinkering with the GRBL post as a template I got my aggregate to work, so my immediate problem is solved. In case anybody else runs into the same issue I have attached the post here, you can give it a try by copying the file into your ~/Autodesk/Fusion 360 CAM/Posts/ folder and it should show up in your personal posts under the name 'Aggregate'. The post will export tool paths on the XY, XZ and YZ plane, for each plane from both directions. The post will bail out with an error for tool directions which are not aligned with any of the coordinate axes. 

WARNING - WARNING - WARNING :::  I don't have the facilities or time to comprehensively test this post. If you run this post it is at your own risk. Be particularly careful with retract moves, as the general assumptions that moving +z is a safe thing to do does not hold. I strongly recommend to run any toolpath in 'air' first. 

If you try this post and run into problems please let me know, I'd be interested to make this work as well as possible.

If you are an Autodesk employee and have access to a test suite to run this through please let me know how it goes. 

Cheers, 

Jochen

[pete]

I am very interested in hearing if you were able to get this working correctly.  I design and program for a large custom shop here in Florida. We are looking into purchasing an aggregate head to be able to do door hinges and a few other items.  I assumed that Fusion360 was capable of this but now I am not too sure. Were you able to get this actually working?  Ifso I would love to hear about your processes and methods.  Are you able to view this in simulation and have it visualize the head or at least the tool angle?  Thank you for posting this information and the sample post.  I will download it and see how it might implement in our CR Onsrud CNC router. Thank you...

Pete

[jheinzmann]

Hi Pete, 

its been a while since I looked into this, but the short answer is yes, I got this working ok for my requirements. 

As mentioned in my posts, this whole thing is mostly a post-processor issue, within Fusion all this works fine. You just have to have the facilities required for the coordinate system transformation in your post. In Fusion, you just make sure you have the setup coordinate system correct for the machine coordinate system, but then in the tool paths turn the tool in the direction you need it to be. If you have a post that supports this, you just press the post process button and all should be fine. 

Except for the one caveat, and that is you have to be careful with Z retractions. If your machine controller does some of that then you have to make sure you have clear air above the tool for it. The tool path generator will not automatically take care of that. 

I'm a bit surprised aggregates get so little attention within Fusion. It is all pretty obscure unfortunately. Actually I should say the core software people really did their bit, it works great, it just seems aggregates are well down the priority list of the post processor and documentation people.  

Let me know how you go. 

Cheers, 

Jochen

[pete]

So I think I understand the post processor does most of the heavy lifting but on screen in fusion what are you seeing?  IE lets say you have an entryway door slab and it is laying flat on the substrate of the vacuum table on the router. Then you are programming say a 90 degree cut along the side of the door simulating cutting a hinge pocket or mortise for a lock etc.  do you see this inside fusion?  IE is the door oriented the same way as I am describing here or are you selecting an origin on the side of the door with the z axis being horizontal? Or is it as I hope with the door being as it would sit on the machine and the z axis is up but the toolpath and any simulation thereof are oriented horizontally along the side of the door?  I understand that fusion can basically orient the work in any position and can then be setup to select any side or corner of the work as the origin but this is a bit more complex.  I hate to ask so many questions here but since you have already done this successfully I lean on your knowledge here. Any information is most appreciated.  We have been looking into buying the head for the machine.  Do you use a 90 degree or an adjustable angle head on your machine/machines?   Thanks again for the assistance.

Pete

[jheinzmann]

Hi Pete, 

so the process to make an aggregate tool path is like this: 

Make a door with a pocket on the side. 

Create a setup in Manufacture with the normal orientation, door flat on the bed of the machine as usual. 

Create a pocket tool path. Then select the bottom of your side pocket. 

Things then look a bit off like this because you picked a face for your pocket that is aligned with the regular tool orientation. So now we need to fix the tool orientation. 

Turn on 'Tool Orientation' which should probably be called 'Non-standard Tool Orientation' so there you will need to tell Fusion which way your tool/aggregate is positioning the tool. 

For the z-axis select the bottom of your pocket, this is always safe if the bottom is flat. For the other axis select an edge that is actually aligned with that axis normally. I selected the long edge of the door for my y-axis. You could just click on the origin axis of the same direction, that would be fine, too. 

Press ok and voila, you have a tool path milling the pocket sideways. You can also simulate this, everything should work just as normal. 

Two notes at this point: 

1. All of this works independent of the post processor you have selected, this is all in-built Fusion capabilities that will always work. 

2. The Z-retract at the end of the program of this tool path is aligned with the tool, which means your spindle motor will remain level with the door when the program finishes. Some machine controllers will then do a Z-retract on their own accord to what is set to be a safe z-distance. My machine does this. If this the case, you have to make sure that there is nothing above the tool/spindle, otherwise you will crash. Neither Fusion nor your machine controller checks for this. If your machine controller does not do that then this could be inconvenient for unloading/reloading, in particular if you have automatic loading on your Onsrud. Keep your hand on the e-stop the first time you run this. 

Ok, so now to the post processor piece. I'll show you first what happens when your post does NOT support aggregates. 

If you just go for the generic post, and export the tool path, the post will realise that it actually doesn't know how to do aggregates. It looks like it actually exports it in Fusion (no error message there, sorry), but the export looks like this: 

If you open it: 

Fusion is blissfully unaware that the post couldn't digest this and will behave as if this all worked just fine. So always check if you got a .failed file!

When I instead use my aggregate post to export the tool path, all goes well. 

 

 

File is good.

G-code is good.

This would be executable on my machine as is. 

I use a 90 deg head, and the aggregate post I gobbled together can only deal with 90 deg heads as far as I can remember, it was all I needed at the time so I stopped manipulating the Python code for the post processor when I got it to do what I needed. For other angles I think we would need to get the good folks from Autodesk involved.

Hope this helps. 

Cheers, 

Jochen

 

[pete]

THANK YOU!! This is a fantastic explanation of how this should work.  So I noticed that your tool holder in simulation is long and large, did you purposely do this to be able to show the width of the offset in the aggregate head?  The retract to safe Z after the cutting operation if the program is setup correctly can be just a larger safe z distance from the relative top of the part/side of door no?   Then if the machine does decide to raise to G28 home or whatever it typically does it will then be clear of the work or am I missing something. I will try to setup this simulation in my fusion over here and see how it goes. I cannot thank you enough for your assistance here. Most appreciated for you to take the time to make this picture post.  

Pete

[jheinzmann]

Hi Pete, no worries, hope you can get this to work. 

The big tool holder I am using is actually a model of my spindle motor. I am using this in particular with aggregates so I have an idea where the motor swings around. However, I have also found it useful in other scenarios, so it is actually my default tool holder nowadays. 

If you can get your post processor to do a z-retract in the machine z direction that's great, but it doesn't do it by default. The default retract of the tool path is in the z-direction of the tool, not of the machine. As far as I know you can't get Fusion to do that, so it would need to be a little clause in the post processor to make sure that there is a retract at the end of the program. Simply passing the tool path Fusion outputs will not do that. 

G28 is a good way of doing that, so as long as you get the post processor to put a G28 at the end of program you should be good.

Cheers, 

Jochen

[pete]

@jheinzmann, 

   I am finally getting around to working on this aggregate head post and setup for our Thermwood CNC router.  We have been extremely busy with a huge job for months now and finally getting around to this. I was able to fairly easily get the tool orientation inside fusion360 to work pretty much exactly the way you had described here.  The posted code seems to be ok as well however we asked the manufacturer of our CNC for some sample code for the C axis aggregate head. Theirs was programmed using Mastercam and their proprietary post processing.  Looking at the code it seems that their code outputs C code IE C0.  C90.  C180. etc. after the initial movement to general position on the table.  Our spindle is now equipped with  a "C" axis that is powered rotation to specific degree angles so that we can machine on both sides of say an entryway door lying flat on the table.   I am trying to figure out how to get Fusion360 to output that "C" code for the aggregate head.  It seems like post you have outputs a "work plane check : forward is 0,0,1" for example and this is in parentheses.  So it does not appear to tell the machine anything I believe this is for your understanding of the posted code. It does however output the G17, G18 or G19 information.  I am under the impression that the manufacturer of our machine intended for the tool callout to contain specific information for the rotary position of the C axis spindle and then the particular parameters of the tool in the aggregate head is what adjusts the offsets for the tool to arrive at the correct position.  I believe this includes the rotational angle of the C axis but I am not sure.  Does that make sense?  I am probably not describing this at all well.  

   Either way I posted code using your post and it appears to be accounting for the head but it does not seem to account for the specific C axis position. Do you use your head in one specific rotational position and only approach parts from that side or does your aggregate head setup allow for a rotation somehow to facilitate machining on the opposite side of the part?   Thank you again for all of your assistance with this.  

Pete

[jheinzmann]

Hi Pete, 

you are explaining this very well. I use this post with a fixed C-axis, I don't have articulation on mine, so it is not a problem for my setup. 

In your situation, you can of course use everything as is by simply rotating the C-axis into the position you need and then run the appropriate code. It is pretty cumbersome admittedly, probably what you are doing right now. 

If you only do either +90deg and -90deg, you could put a few if statements in the code of the post to detect the three possible orientations (-90, 0, 90) and output the appropriate C-axis move. You will need to be careful with the change of your tool center point in machine XYZ as a result of the C rotation and make sure this is accommodated for, otherwise you will have a collision. 

For the more general case of other C-axis angles, you are out of luck with my post unfortunately, it is very basic and can only accomodate tool orientations coincident with one of the major axes. You will probably need to talk to Fusion support about how you can obtain a suitable post. 

All the best 

Jochen

[pete]

jheinzmann,

     I appreciate the help.  I am working in another thread with bob.Schultz who is apparently the senior post processor development guy at Fusion360.  

Re: 90 degree spindle, linux cnc, postprocessor for drilling horizontal holes - Page 2 - Autodesk Co...

So you are saying that the machine you are using has a fixed C axis mount either 90 or -90 degrees then?  We have a Thermwood machine and it is as I said before setup with a motorized C axis around the Z spindle.  Apparently Fusion360 can output the "C"commands in the posted code and he is helping me with that.  Perhaps it might help you with your post even tho you have it working. Good luck.

Pete

[jheinzmann]

Hi Pete, 

yes, my 'C-axis' is really a bracket that I mount between the z-axis and the spindle to turn it 90 deg. Nothing fancy here, so all I needed from the post was to convert the axes given that the setup coordinate system is, as it needs to be, aligned with the machine coordinates. This is a simple operation where you just swap z and x or y coordinates back and forth. No motorised axis control, and no rotation matrices to re-orient the vectors. Hence, this can only cope with tool axes aligned with one of the major axes. 

Good you got help from a person at Autodesk who knows the system, it will be much easier this way. Looks like they rather run you through instructions on how to make the changes yourself for presumably legal liability reasons, not much you can do about that. But I'm pretty sure you will get your C-axis going this way.

Good luck!

Cheers,

Jochen 

[AssistenzaMK24X]

I used your post processor, and I must say that it fully satisfies what I should be doing with the machine, I just wanted to ask you one thing being that I use an angular aggregate with 4 points placed at 0-90-180-270 degrees there and the possibility of rotating the "C" axis for tool change, or creating a tool in fusion that has these settings so that the processor recognizes the tools based on their positioning on the aggregate?

[jheinzmann]

Hi there, 

this is outside what of what I have the expertise to do. You might have to get in touch with somebody from Autodesk support for this. 

Cheers, 

Jochen