Announcements
Attention for Customers without Multi-Factor Authentication or Single Sign-On - OTP Verification rolls out April 2025. Read all about it here.

Post is inverting Z values when using multiple WCS on mill/turn

jswickJ9PWC
Advocate

Post is inverting Z values when using multiple WCS on mill/turn

jswickJ9PWC
Advocate
Advocate

As I posted in another thread, I am using tools back and forth between the main spindle (G54) and the subspindle (G55.) The only way I can do this for now is to have multiple setups for each operation (see attached picture.) Problem now is when I post, the first setup on G54 has correct Z value; then it goes to setup 2 on G55 and those also have correct Z values. However, when it goes back to the third setup at G54, all the Z values are inverted--they are posting negative when they should be positive. 

 

If I post the setup by itself, the value are correct. It only happens when I post all the setups at once as one program. This is something I need to do so the post reads and stages upcoming tools correctly. 

 

I've checked the program using the dump.cps post and it seems like the issue is coming from Fusion, not my individual post. For example, using the dump post and posting all setups at once, I get the following values for the inverted operations: 

 

currentSection.fcsPlane=[[0, 0, -1], [0, -1, 0], [-1, 0, 0]]
currentSection.modelOrigin=(-1.75, 7.98123e-32, 2.69251e-16)
currentSection.modelPlane=[[-0, -0, -1], [0, -1, 0], [-1, 0, 0]]

 

But posting just the one setup by itself with the dump post gives me this: 

 

currentSection.fcsPlane=[[0, 0, -1], [0, 1, 0], [1, 0, 0]]
currentSection.modelOrigin=(-0.052, 7.06643e-15, -4.19612e-15)
currentSection.modelPlane=[[0, -0, -1], [0, 1, -0], [1, 0, 0]]

 

So you can see that the plane vectors are being inverted in the software then not corrected. They're "sticking." 

 

Any suggestion from the post gurus? 

0 Likes
Reply
Accepted solutions (2)
483 Views
7 Replies
Replies (7)

jswickJ9PWC
Advocate
Advocate

I've tested this out with multiple posts, including default unmodified posts from Autodesk and the results are the same. 

0 Likes

jswickJ9PWC
Advocate
Advocate
Accepted solution

Nevermind, I found it. There is a fault in the logic in the standard mill/turn posts that carries over to all the posts built on it. 

 

Standard code is: 

 

if (getSpindle(true) == SPINDLE_SUB) {
    invertAxes(true, false); // polar mode has not been enabled yet
 
  }
which will invert the axes just fine for the sub, but the logic is missing to re-invert if the spindle switches back to the main. So I added:
 
 else if(getSpindle(true) == SPINDLE_MAIN){
    invertAxes(false, false);
  }
1 Like

seth.madore
Community Manager
Community Manager

Thanks @jswickJ9PWC I'll send this along to the post team


Seth Madore
Customer Advocacy Manager - Manufacturing
0 Likes

bob.schultz
Autodesk
Autodesk

Hello @jswickJ9PWC,

 

I've checked a few Mill/Turn posts here and they do reset the inverted axes when switching between the secondary and main spindle.  This code can be found in the onSectionEnd function, so the axes are reset at the end of each secondary spindle operation.  Does your post have this code?

function onSectionEnd() {
...
  if (getSpindle(false) == SPINDLE_SUB) {
    invertAxes(false, false);
  }
...

 

The inversion of the axes are handled in the post processor and not in Fusion as you've found out.  FYI, the modelPlane is not used by the post processor, but rather the workPlane is used.

 



Bob Schultz
Sr. Post Processor Developer

0 Likes

jswickJ9PWC
Advocate
Advocate
Accepted solution

The posts do have that code; however the problematic part is actually in the onSection() function. 

 

function onSection() {
...
// invert axes for secondary spindle   // default code
  if (getSpindle(true) == SPINDLE_SUB) {   // default code
    invertAxes(true, false); // default code
  }
  else if(getSpindle(true) == SPINDLE_MAIN){  // added code to correct
    invertAxes(false, false);   // added code to correct
  }

 

0 Likes

bob.schultz
Autodesk
Autodesk

If your post has this code, then the axes should be reset to normal at the end of every operation and the code should not be required in onSection.  I have tried it here with a few of the library posts and it works as desired.  Is it possible for you to provide the model you are working with so that I can test it and see if there is a scenario that we missed.  If this is an issue with the library posts we would like to get it fixed.

 

Thanks



Bob Schultz
Sr. Post Processor Developer

0 Likes

jswickJ9PWC
Advocate
Advocate

What is your email so I can send it directly to you?

0 Likes