Offset tilt axis from rotary axis

[sewais]

Hello,

In this post, https://forums.autodesk.com/t5/hsm-post-processor-forum/how-to-set-up-a-4-5-axis-machine-configurati... , its mentioned that 'using machine configurations in Fusion is the preferred method to specify your machine configuration, kinematics and options like home positions, axes limits and more', however, I'm having a difficult time getting the standard Okuma post to show an offset when the b axis is tilted. I built the XYZBC axis all into the machine builder, & added all the positions & center of rotation for each axis, yet the output is still incorrect.

My current solution is to post w. a modified post that enables 3+2. This was done using the steps in that article, along w. disabling TCP, & changing this bit of code per @bob.schultz. This presents its own issues however, w/ drilling cycles having a G00 at the end that plunges the tool into the part. This can easily be edited out of the code, but is time consuming.

Below are two screen shots showing what I'm seeing when posting using the modified post (the one w. the B rotation offset hard coded into it) & the non modified post that's supposed to grab all this info from the Kinematics Advanced Settings:

Modified Post, also attached (see changes here😞

Latest Okuma post version 44084

You can see that the difference between the two numbers is exactly the F value from the Nikken image below, in metric:

W/ all that said, I'd like to only use the post that uses the kinematics. Is it still in development to offer the offset feature? My original post was moved to HSM Post Processor Forum, & received no replies except for my own updates. 

Thank you,

Sam E.

[bob.schultz]

Hello Sam,

I was able to duplicate your issue and will need to research it further to determine the issue.  For now, you can use the hardcoded machine configuration.

I can give you a fix for the retract move after the canned cycle being in the wrong location.  Make this change in the onCycleEnd function.

      // Change getCurrentPosition().z to cycle.clearance
      writeBlock(gMotionModal.format(0), zOutput.format(cycle.clearance)); // avoid spindle stop

There is also an issue where you define your hardcoded machine configuration in defineMachine.  You will want to remove the following line as this is now handled in activateMachine for both Machine Configurations and hardcoded configurations.

        // Remove the following line in defineMachine
        optimizeMachineAngles2(1); // TCP disabled (eg. M128, TRAORI, G43.4, G243)

[sewais]

Thank you very much for the reply Bob. I've spent days trying to figure this out. I've made the changes above & it solves the G00 retract issue. I'm looking forward to your answer on the kinematics side of things.  Here is a screenshot of the code using the Cycle.Clearance:

Here is the original post that was moved to the HSM forum for reference, which I'm using to track my progress more than anything at this point.

https://forums.autodesk.com/t5/hsm-post-processor-forum/3-2-okuma-4020-nikken-5ax230-b-amp-c-axis-no...

[bob.schultz]

I ended up having transposed numbers in my B-axis offset in the Machine Configuration and this is what caused the differences in the output.  When the offsets are the same as they are hardcoded in the post the results are the same.  Make sure that your kinematics and offsets match in the Machine Configuration.  If you have checked these and still get differences, then can you provide the Machine Configuration that you are using.  Thanks.

[sewais]

Thank you for the reply. Our Nikken is setup on the right side of the machine, video below for reference.

We picked up the center of the C @ X +14.8553"/ 377.325mm & Y+2.4675"/62.675mm.

This info was entered in the C axis advanced settings. The Z rotation of the C was also entered as 'D' from the Nikken cert. This didn't really matter, I don't think, but we did it anyways.

Same numbers for the B, but w. the 'F' dimensions from the Nikken cert subtracted from the X

All of this allows the models to move precisely to what we see in real life, but doesn't out put.

W/ all that said, I'm under the impression that the post processer shouldn't need anything changed in it, if all the numbers above are good to go, since setting the below statement to True, disables any kinematics?

[bob.schultz · Accepted solution]

It looks like I was not clear in my explanation.  If you are expecting the same results when using a Machine Configuration as when using a hardcoded machine then the rotary axes must be defined the same in both cases.  This includes the Offset values.  You will see the offset values when you edit the Machine Configuration and view the Advanced Settings of the B-axis in the Kinematics.

There is an issue in that once you make this change that the machine may no longer be simulated correctly when using the Machine Simulation playback.  This is due to the offsets no longer referencing the origin of the machine as it was defined.  If this is the case, then you will need to change the origin of the machine so that it is at the location where the part will be attached to the machine (usually at the center of the rotary table) and the Setup origin in the Manufacturing operation must be placed where the model will attach to this position on the table.

This is a known issue with non-TCP machines and is currently being worked on.

[sewais]

Hey Bob,

That explanation makes sense. For now, I will continue using two posts, one for correct simulation & the other for machining. Not sure if there is much demand for this kind of thing for non TCP machines.

Side note, I'm noticing an issue w. entry Z moves while B is tilted. The code below is the same as above, but notice line N17, this causes the spindle to come down, go up, & then go back down. Only happens when tilted.

Can you advise on an edit to fix this please?

Thanks,
Sam E.

For reference, this is what the line before G71's Z move looks like when not tilted in the B axis:

[bob.schultz · Accepted solution]

HI Sam,

This move is being generated by the repositionToCycleClearance call and it looks like there may be an issue with offset tables.  You can comment out this line since the tool should already be positioned at this level and you are outputting the clearance position on the G71 block.

  if (isFirstCyclePoint() || isProbeOperation()) {
    if (tool.type != TOOL_PROBE) {
      // return to initial Z which is clearance plane and set absolute mode
      // repositionToCycleClearance(cycle, x, y, z); // <<< COMMENT OUT THIS LINE
      var g71 = z71Output.format(cycle.clearance);
      if (g71) {
        g71 = formatWords(gFormat.format(71), g71);
      }
    }

[sewais]

Thank you Bob, this has solved the issue. The post is looking really clean now.