Setup tips: 3+2 with 5ax toolhead

[matty.fuller]

Hello, looking some help on a technique I'm trying to resolve. I'm currently working on a large project that is a bit of a doozy: organic surfaces with undercuts, converted from a high polygon mesh. I will be machining 100mm slabs of styrofoam using a 5 axis Biesse Rover. Yes, a woodworking machine - don't leave yet.

The approach I am using to access undercuts is 3+2 machining, by using parallel with tool orientation:

The issue I have is that changing the tool orientation takes the WCS with it, which makes sense for a VMC where the 4th/5th axes are on the table but my machine has a full 5 axis toolhead - I want the co-ordinate system to remain aligned with the stock/model, which is how I need to machine it.

I have been able to fudge it by taking the toolpath into the machine's proprietary software and programming the cut onto a custom face, which is just a custom WCS which it is able to rotationally translate onto. This is SLOW and not very versatile - I will be running a large number of different part sizes and different tool orientations to selectively clear undercut areas.

It would be far simpler if I was able to export the toolpath in relation to the WCS of my setup - this would still only require XYZ output, since I can manually set the static B/C values at the machine or patch them into my post as user variables.

Any advice on how to accomplish this within Fusion/HSM? Tips and ideas are greatly appreciated, thanks.

Background:

In case you're wondering, it is not possible to program for this geometry using swarf or contour, since the surface of the parts is comprised of many many triangles/quads - there are no usable guide curves, and trying to select individual facets is impossible for a job this size.

Aside from that, my post does not yet support continuous 5 axis anyhow - that is a work in progress. It will be possible to modify the post so that it can pass through a rototranslated work plane, but dealing with Biesse NC is a whole different box of frogs due to their proprietary format and it's proving hard enough to get some of the basics nailed down at this stage.

The job itself is an unrolled 3D scan of a fossilized log, and the foam mold I machine will be used to cast a 'pelt' from the log. Yep, I work for a university.

[daniel_lyall]

can you post your post processor and the the models files

[RandyKopf · Accepted solution]

@matty.fuller

"The issue I have is that changing the tool orientation takes the WCS with it, which makes sense for a VMC where the 4th/5th axes are on the table but my machine has a full 5 axis toolhead - I want the co-ordinate system to remain aligned with the stock/model, which is how I need to machine it."

Sounds like your CAM SETUP is correct but your missing a key aspect in setting up individual Tool Paths...

Under CAM with a normal 3+2 SETUP you define your WCS. That is the math coordinate system that all the output is based on. That is the baseline origin for all XYZ math. And more importantly for how all rotary motion is calculated. That should not change unless you literally move the part off that actual location on the machine.

With that said AFTER YOUR SETUP IS COMPLETE WITH WCS, as you create any tool paths, you should define your Tool Orientation as part of each Tool Path definition. That is as an added controlling function for Multi-axis machining. In the Tool Orientation screen as you define each Tool Path you have the option to use WCS as defined from the SETUP. And you can use a different Tool Orientation for the currently being defined Tool Path. In this scenario all the math from an part program origin stand point will be based on the WCS from the SETUP. However the Z Axis that you end up defining in this Tool Path Operation will be used as the basis from which the tool approaches the part. And it influences all the elevations like retract, feed, start elevation and end elevations etc. It also is used by the post to compare the difference between the SETUP Z axis and the Tool Path Z Axis and if there is a difference the post will calculate the appropriate Rotary angles for 1 or more axis depending on the difference in vector math. Additionally the X Axis that is defined in the Tool Path also influences the cut direction with respect to parallel tool paths etc. But only in a way that the tool path by default follows the X axis as angle 0. But the actual output on the machine is always based on WCS.

I can't access my data so I'll point you to a couple help files on another forum related to FUSION 360 CAM 3+2 machining.

This post explains 3+2 setup in Fusion

https://groups.google.com/forum/#!category-topic/pocket-nc/I1CGDW8Mtqc

This post has a few example 3+2 CAM files...

https://groups.google.com/forum/#!category-topic/pocket-nc/anfiQrBirvU

 

[matty.fuller]

Thanks Daniel & Randy. After a good sleep and another solid day on it, I think I understand the issue and the path forward now.

I went back to double check Daniel's suggestions about WCS origin; you are correct, in that moving the origin does exactly what it says on the tin, but as per below the WCS axes stay aligned with the tool rather than the setup...

WCS for my setup:

Operation with Tool Orientation enabled - the axes have tilted and the WCS is different, resulting in Z values beyond the bounds of the machine:

There seems to be no way to make the WCS stay relative to the setup within Fusion/HSM, but after looking at the dump post it seems like the real issue is that my post is not sophisticated enough; at some point it was modified from a generic FANUC post to resemble the proprietary Biesse format, but has never produced working NC before now and still has a ways to go.

In the dump there are 4 sets of coordinate system data getting passed through, so it should be relatively straightforward to add the required math for calculating the machine axis positions in relation to the work plane of the current operation . Looks like the coordinate systems available in the post are for work, world, dynamic, and fixture.

353: onSection()
  currentSection.unit=1
  currentSection.workOrigin=(0, 0, 0)
  currentSection.workPlane=[[0.890737, 9.91763e-07, -0.454518], [-0.276413, 0.793826, -0.541697], [0.360808, 0.608144, 0.707091]]
  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=(195.547, -0.539426, -101)
  currentSection.fcsPlane=[[-1, 8.7295e-10, 1.61733e-06], [0, -1, 0.000539749], [1.61733e-06, 0.000539749, 1]]
  currentSection.type=0
  currentSection.quality=0
  currentSection.jetMode=0
  currentSection.tailstock=false
  currentSection.partCatcher=false
  currentSection.spindle=0
  currentSection.feedMode=0
  currentSection.toolOrientation=0

The deal is that I could calculate the corrected positions of the axes and output these, but there is a lot of incentive to use the rototranslation approach since I can then use all the regular circle/arc geometry, cycles, and retraction stuff on that plane. The way Biesse handles it is actually pretty simple in that you get a gumball style control over the work plane, with 6 parameters: X/Y/Z rotation, and X/Y/Z offset, looks like top left corner as the origin, so it might not be that hard to figure out actually.

I am not able to share the post at the moment, but if anyone has tips for further reading or approaches to try that is great, thanks.

[RandyKopf]

@matty.fuller

Thanks for the detail message back...

I think there is a bit of a misnomer here as you state:

There seems to be no way to make the WCS stay relative to the setup within Fusion/HSM, but after looking at the dump post it seems like the real issue is that my post is not sophisticated enough; at some point it was modified from a generic FANUC post to resemble the proprietary Biesse format, but has never produced working NC before now and still has a ways to go.

Just to clarify the WCS is the math origin as defined in the SETUP. That means it is THE WCS ALWAYS STAYS RELATIVE TO HOW IT IS DEFINED IN THE SETUP. That is unless you change setups.

When I look at your 2nd graphics image it shows the tool path is aligned with how the Tool Orientation. And it looks to be defined correctly.  But behind the scenes the actual output code will be based on the WCS AS YOU DEFINED IN YOUR SETUP

And all output XYZ values are based on that WCS origin. And the starting Rotary angles are based on that WCS Origin's Vectors.

What you are experiencing is the change in math that is occurring as a difference of rotary translation. And you elude to that in your dialog. And it is likely your post needs updating OR you simply have a part that exceeds the working envelope of the machine?

You also mention 4 sets of coordinates, that is standard as the origin has an XYZ value. There is a second point that defines the X Axis Vector as an XYZ value. The difference of these two allow vector math to occur. The third set is for Y and it desribes its vector as an XYZ Point relative to the origin again to obtain a vector and finally one for the Z Axis. It also has a point defined as XYZ that allows it's vector to be calculated. That is called a transformation matrix and it has 12 sets of values it tracks. The post deals with all that stuff. This is like looking at a printer driver file. Do you really care about that? I don't so I leave it to experts. 

Maybe someone familiar with the posts like @LibertyMachine or @George-Roberts can chime in to help.

That is one thing about 5 Axis it needs breathing room and consumes lots of the work envelope just to get around a part.

[matty.fuller]

I disagree somewhat about the WCS and what information that is getting sent to the post for this operation, but I can see how I will be able to modify it to make it work for our machines now.

See below example (same parallel operation as above) where there are no Y values being passed to the onLinear() function while cutting, and then some very small Y values come in as it starts to do the linking between passes:

The same operation in HSMWorks backplot, showing the enlarged bounding box, top view, and range of values:

A copy of the dump is here also: https://drive.google.com/file/d/0BzZ3R9qIRbdgbENFMlg1M21nZ3c/view?usp=sharing

I'm working through modifying debugging the post, and it seems quite clear that by default it is passing through data that represents XYZ coordinates relative to a tilted workplane, rather than global XYZ values with added B/C conditions. It returns currentSection.isMultiAxis() as false and currentSection.ToolAxis() as Z. I have found the appropriate parameters and tools I need to calculate everything I need and build both absolute axes and rototranslation into my post, so in a sense the problem is solved. That said, I do think that the way Fusion handles it is misleading - personally I would deem it to be setting the part orientation rather than the tool orientation, but maybe that is my inexperience or the lack of sophistication in the post I was given to work with.

The work envelope is only an issue because of the way the coordinates are described; it is a gantry type machine with a massive XY field but limited Z height (~170mm max to fit under the gantry) so you do lose some range in XY when using 5 axis near the edges, but you can theoretically have a Z range of over 3000mm if you rotate the workplane 90 degrees and there is more than enough room to access these parts. A PocketNC it is not.

Thanks for your help @RandyKopf, much appreciated. Regarding the printer driver comment, I work for an architecture & design school where we are involved in parametric design, spatial math, and robotic fabrication research, plus I am a software developer and furniture designer by trade... so yes we do care about (and enjoy) getting under the hood and generally aspire to be the experts you're talking about 🙂

Cheers,

Matty

[RandyKopf]

@matty.fuller

Well after reading your message I can concur that this is intriguing stuff to say the least. It's why it's held my attention for 30 years. I'm not so excited to dig into print drivers to be an expert in my own mind as I've dealt with so many post systems over the years. ICAM was the most expensive an most renowned. I don't need to say anything more. Post Processors are like looking at everyone's opinion of what the superior math language should be or is. Is it Fortran or C++ or Java Basic, or PureMath. The last  in the list is what GOD USES TO BS PEOPLE haha just made that up.

I know it will take a while for you head to wrap around the concept I've explained regarding WCS. However the concept is industry wide. You'll  get it, and your close. Just something is skewing your perception. It's awesome that you are not on board with my thinking. We should question everything always and never stop. But you are clearly hung up on the difference of World Coordinates VS Local Coordinate Systems. Every major CAM system I've used is based on these very concepts. And the way I explained it in my initial reply to you was as reader digest as it gets. It's worth reading again. Eventually after you find the thing that is skewing your concepts you owe it to your self to re read that reply once again and you will see it's very simplistic but it's just how it all works.

So what it comes down to is your perception and mine and others... And everything you see clearly shows that the LCS is superior and controlling the WCS. But in actuality you likely are basing your assumptions on a Post that is not properly defined. 

If you go back and re read my initial message to you it explains clearly the role of the WCS. And how the LCS subordinates to it and it is absolutely true that the two combined affect the combined total output code.

The crazy thing here is I'm not talking out my arse, I've lived and breathed this week after week year after year. CAM system after CAM system and what I am stating is true to the best of my ability to speak haha another funny line. 

Conclusion, We need to engage someone as passionate as you about the printer driver aka HSM Post Processor system to get you a real working 5 axis post. The you will see the order in which the math must be initially defined and setups established and tool paths created and output G code generated and with a proper matching setup on your CNC you can execute reliably to make incredible parts.

Keep the dialog rolling you are obviously very smart but don't let it go to your head. This is a very deep complex world. That is CAM and CNC machining. And just when you think you are all that... Well it only takes one single parameter entered incorrectly and you will look like a fool on the shop floor. Believe me it happened to me this very day... And sadly like many others. 

🙂

PS that machine you have sounds almost as nice as my CMS ARES 5 AXIS ROUTER

http://www.cmsindustries.us/en/products/plastic-working-systems.c12323/5-axis-cnc-machining-centres....

[RandyKopf]

@matty.fuller

I wonder if you may have missed selecting the WCS as the origin in your Tool Path 5 Axis Tool Orientation definition???

This would explain everything you are seeing... VS what I've been stating.

I am creating a sample CAM program that shows the difference of what I've been explaining VS what you seem to be experiencing.

Please let me circle back with an example file...

:-)

[RandyKopf]

@matty.fuller

I wonder if you may have missed selecting the WCS as the origin in your Tool Path 5 Axis Tool Orientation definition?

This would explain everything you are seeing... VS what I've been stating.

I am creating a sample CAM program that shows the difference of what I've been explaining VS what you seem to be experiencing.

Please let me circle back with an example file...

:-)

[RandyKopf]

@matty.fuller

I wanted to get you a simple example that can be studied without extra complexity.

Here is a basic 3+2 example file that includes:

1) A CAM SETUP with a WCS

2) A as 3 Axis basic linear motion using the WCS and a Tool Axis that is matched.

3) The same tool path duplicated using the WCS and a rotated Tool Axis A90 degrees

4) A linear motion on a 3+2 Plane using WCS and Tool Orientation normal to the compound plane.

5) A duplicate of item 4 but NOT using WCS but only the Tool Axis. (Same as if you re oriented your part)

The math looks correct to me in all situations as I have described previously.

I hope this helps, 

[matty.fuller]

@RandyKopf thanks for taking the time to put that together mate. I went back over your posts and I can confirm that we are both on the same page about what Fusion is doing with the WCS/LCS, I'm just struggling to reconcile it with how this machine has been programmed until now and my lack of experience with other tools. Probably the main struggling block is that I'm flying blind by trying to modify a generic post that is incomplete, and reverse engineering code that we know works but can't seem to get complete documentation for. Apologies if came off as argumentative - very much eager to learn.

To illustrate that the problem is with the post rather than my setup, I took your file and posted it out... same result, because it is not doing anything to account for the altered LCS yet (also looks upside down because this machine has an inverted Z axis):

Not sure how closely this aligns with other machines, but it looks fairly straightforward to specify the LCS in Biesse's format... this is an example of how their post handles it; just a rotation and offset for each cartesian axis, pivoting on the top left corner:

N280 TRSX=0.0 TRSY=0.0 TRSZ=-LPZ ; DATI DELLA TRASLAZIONE
N290 ROTX=45.0 ROTY=0.0 ROTZ=0.0 ; DATI DELLA ROTAZIONE ASSI

The concept is not that hard, I think the stumbling block is that pretty much every job we've ever run on these machines uses the WCS exclusively, including some quite complex 5 axis stuff, so I have been looking for absolute values in the output rather than thinking about how to use a rotated LCS, and maybe put a bit too much faith in the generic post. In my defense, the reason I'm doing this is that Autodesk and Biesse think it's a bit too hard to provide a post and we're sick of standing in the workshop telling people we can't make their project because of a software bottleneck.

Thanks again. Will post some pics/vid when I have it machining this week.