Incorrect post output for 3 + 2 operations in Fusion 360

[brink.gregory]

I'm trying out positional multi-axis operation of some of the Fusion 360 2D and 3D operations.  I have a head/head machine that does not have TCP.   I watched the tutorial (Positional Multi-Axis Workflow) and learned that the orientation translation is handled by the post-processor.  I selected a flat face that is perpendicular to the Y axis in the tool orientation section of the Face operation.  The resulting tool path moved the spindle to the correct orientation (pointed in the physical positive Y direction) but the facing motions were in the original YZ plane rather than the XZ plane.  I tried switching the X and Y axes but couldn't find a way to get the machine on the correct plane.  

I compared a dump post for the positional operation to a post dump for a standard operation and found that the positional has a line from CAM under the onSection():

   currentSection.workPlane=[[1, 0, 0], [0, 0, -1], [0, 1, 0]]

That seems to be changing the plane definition from:

   currentSection.wcsPlane=[[1, 0, 0], [0, 1, 0], [0, 0, 1]]

The standard operation I looked at for comparison didn't have this difference: the workPlane is defined the same as the wcsPlane. 

It seems like axis definitions for the positional are not being handled correctly.  

What can I do to get the post to handle the orientation translation correctly?  Is there a post for a head/head five axis machine without TCP that does all all the work without kicking it to the machine controller? 

[brink.gregory]

I modeled a 3" cube and then setup 2D contours of the top, front and right faces.  I posted using the dump post.  The motion for each of the three operations was only in an XY plane; the Z value was fixed for each operation.  This suggests the CAM algorithms are assuming a table/table machine.  I have a head/head machine.  The spindle rotated to the correct orientation for each of the operations so it seems like the workPlanes were defined correctly.  It appears that, for the 3 + 2 positional operations to work correctly, the post must use the workPlane definition to translate motion commands (coming from the CAM in the XY plane) to the correct plane (XZ and YZ in the case of this experiment).  

This brings us back to one of my original questions:  can any of you point me to a post for a head/head machine without TCP that successfully performs 3 + 2 positional multi-axis operations?

The post I have works OK for simultaneous 5-axis motion.

[bob.schultz · Accepted solution]

The 5axismaker post is for a 5-axis head/head machine that does not support TCP.  You can also refer to Section 7.3 Adjusting the Points for Rotary Heads in the Post Processor Training Guide to see how to implement non-TCP head offsets into your post.  One important thing that you will need to check for 3+2 settings is in the getWorkPlaneMachineABC function, make sure that TCP is set to 'true', as this will give you the tool end coordinates in the part system and not the WorkPlane system.

  var tcp = true;  // make sure this is set to 'true'
  if (tcp) {
    setRotation(W); // TCP mode
  } else {
    var O = machineConfiguration.getOrientation(abc);
    var R = machineConfiguration.getRemainingOrientation(abc, W);
    setRotation(R);
  }

[brink.gregory]

Thank you very much for your response; that fixed it for me! 

I'd already incorporated all of the stuff from the training guide.  That use of a variable named TCP is counterintuitive.  I changed that instance to true and the motion is now correct.  There is an instance of a variable named TCP in the getFeedDPM function that is set to false (the comment text states "set to false for rotary heads").  I see the same usage in both cases of the 5axismaker post as well.  

I'm going to convert the 5axismaker post for my machine and compare the performance to the one I already have.  There were some clunky behaviors I worked around and with all of the stuff I added from the training guide it'll be good to get see how that works.

Thanks again!

[bob.schultz]

I can see where the seemingly different usage of 'tcp' can be confusing.  In the getWorkPlaneMachineABC function it is referencing how the coordinates are supplied TO the post processor.  The post needs the tool end point so that it can calculate the pivot point in the original system.

The getFeedDPM function needs to know how the coordinates are output FROM the post processor, since if TCP is supported on the control, then the feedrates can be output in standard FPM values.

I hope this makes it a bit clearer and I am glad to hear that you got the 3+2 working.