Machine setup rotary axis offsets question

[jensen_remote]

I'm trying to setup my trunnion table, and can't quite figure out what the A Rotary and B Rotary "Offset" values actually do.  They don't seem to have any effect on my posted code.

I wanted to tell Fusion that the a-axis axis of rotation is 3.59488 inches below (in Z) my Work Coordinate System (WCS) which is at the center of the b-axis plate.  I thought I could enter this number into the offset in the machine configuration for the A axis.  However, this seems to have no effect, and when machining with a tool orientation other than zero, the post just assumes the part rotated about the WCS, not an a-axis a few inches below the WCS.

I suspect I'm just not understanding what this offset value is supposed to do.  However, I really do need some way to specify that the a-axis and b-axis are not about the work coordinate system, because mechanically these two axes are not perfectly aligned (the a-axis is a couple thou away from where the b-axis line crosses it).  And I'd like to set my WCS at the center of the B axis, not at some unreachable point in the middle of the trunnion where the a-axis rotates about.

I'm using the stock machine setups and posts from the Autodesk library from "HAAS with AB-axes" (Pre-NGC) with the "hass trunnion.cps" post.  This is a pre-ngc machine, which has no tool center point control.  I have TCP turned off in the machine setup.

Thanks for any help,

-Peter

[Mattxer]

He's using a pre-ngc machine with no DWO or TCPC

[bob.schultz]

Hello Peter,

The post processor does in fact support offset tables/heads now.  I am guessing that you are using 3+2 operations which is why you are not seeing any difference in the output, I'll explain further below.

First, you need to define the offset for each table based on the programmed 0,0,0 origin.  Do not define the difference between the 2 rotary axes (in the case of the B-axis rotating around C, the Z-distance is not important, but use this as a general rule).

  if (true) {
    var aAxis = createAxis({coordinate:0, table:true, axis:[-1, 0, 0], range:[-30 - 0.0001, 120 + 0.0001], offset:[0, 0, -3.59488], preference:1});
    var bAxis = createAxis({coordinate:1, table:true, axis:[0, 0, 1], cyclic:false, range:[-360, 360], offset:[.0015, 0, -3.59488]});
    machineConfiguration = new MachineConfiguration(aAxis, bAxis);

    setMachineConfiguration(machineConfiguration);
    optimizeMachineAngles2(1); // map tip mode
  }

 If you run a multi-axis operation, you should now see differences in the output.  For 3+2 operations, the library posts use a standard matrix rotation to solve for the rotations that does not apply the offsets.  There is a new function that will rotate the coordinates based on the offset centers.  Find this code in the getWorkPlaneMachineABC function.

  var tcp = false;
  if (tcp) {
    setRotation(W); // TCP mode
  } else {
    var O = machineConfiguration.getOrientation(abc);
    var R = machineConfiguration.getRemainingOrientation(abc, W);
    setRotation(R);
  }

And replace it with this code.

  var tcp = false;
  if (tcp) {
    setRotation(W); // TCP mode
  } else {
    currentSection.optimize3DPositionsByMachine(machineConfiguration, abc, 1);
  }

The output coordinate rotations should now respect the table offsets.

[DarthBane55]

---

@jensen_remote wrote:

Even simpler would be to have the post issue a G10 before and after each tool orientation command.  The math is the same, though.

---

Hi, @franky.the.pierre and I are the same, just my private license vs commercial one (just saying this so you know I'm aware of the post your are writing).  My posts output G10, but it can only output it for the 1st workshift of the setup.  Most of our machines have DWO, so this works out just perfect for us...  but we do have a couple of horizontal mills that do not have DWO, and for those, what we do is that since we get the G10 for the main WCS, we plug that offset in the spreadsheet to get the other WCS.  Sorry it is not in the post for all offsets, and seeing you are making a "disco ball", I can see this will be a lot of work.  However it is not too too bad, because each WCS has its own number right, for example G54.1P1, G54.1P2, etc.  So I just do a search in my program for each WCS and I then get the angle from the code easily, and plug that into spreadsheet.  I don't know if you can get a G10 for each WCS, at the time of getting our posts done, it was not possible, but there seems to be some new functionality as mentioned by @bob.schultz .  I just am not sure if that is what you need.

Below is the code that output our G10, this is for a B-C machine, so some tweaking would need to be done.  Also, I don't know if there is more code later in the post to do the math or not, I did not make this section of the post and truthfully, I don't understand all of it...  but here it is, maybe it gets you started.

writeComment("===G10 WORKSHIFT DATA===");
	
	var wcsOrigin = getSection(0).getDynamicWCSOrigin();
	var wcsPlane = getSection(0).getDynamicWCSPlane();
	
	var fcsOrigin = new Vector(getSection(0).getFCSOrigin().x, getSection(0).getFCSOrigin().y, getSection(0).getFCSOrigin().z);
	var fcsPlane = getSection(0).getFCSPlane();
	
	var machineHomePosition = new Vector(18.7008, 7.874, 26.9677);
	
	var wcsToCor = Vector.diff(wcsOrigin, fcsOrigin);
	var corToMachine = Vector.diff(wcsToCor, machineHomePosition);
	
	var workOffset = getSection(0).workOffset;
	var workOffsetToWrite = "";
	//Force the use of G54.1 P#
	if (workOffset > 0) {
		if (workOffset > 300) {
			error(localize("Work offset out of range."));
			return;
		  } else {
			  workOffsetToWrite = "P" + workOffset; // G54.1P
		  }
	}
	
	var abc = new Vector(0, 0, 0);
	abc = fcsPlane.getEuler2(EULER_ZXZ_R);

	writeBlock("G10", "L20",  workOffsetToWrite, 
			"X" + xyzFormat.format(corToMachine.x), "Y" + xyzFormat.format(corToMachine.y), "Z" + xyzFormat.format(corToMachine.z),
			conditional(machineConfiguration.isMachineCoordinate(0), "A" + abcFormat.format(abc.x)),
			conditional(machineConfiguration.isMachineCoordinate(1), "B" + abcFormat.format(abc.y)),
			conditional(machineConfiguration.isMachineCoordinate(2), "C" + abcFormat.format(-1*abc.z)));

[jensen_remote]

Bob,

I'm getting an error on the call to

currentSection.optimize3DPositionsByMachine(machineConfiguration, abc, 1);

which is:

Error: Error: Machine coordinates for section have already been optimized.

Any ideas what this means?  Looking through the code, I see lots of currentSection.isOptimizedForMachine() calls, but no other optimize calls other than the optimizeMachineAngles2() call at setup, and the all that generates the error.

Also, shouldn't the b-axis setup have an offset of [0,0,0], since this axis passes perfectly through the WCS?

Thanks so much for your help,

-Peter

[jensen_remote]

Thanks for the code snippet.  I added G10 calls to the setWorkPlane() function.  It's pretty kludgey, and I might have some signs backwards, but it does insert the G10 commands every time the work plane changes (i.e., a 3+2 tool orientation change).  See code below.

I think this pretty much does what the spreadsheet would do, but automatically in the post.  And it uses the post properties to hold the axis offsets, so I can change them as needed if there is drift.  I couldn't figure out how to get these variables from the machine configuration, so post parameters will do the trick.

I'm still going to see if the currentSection.optimize3DPositionsByMachine method can be made to work, as that's much more elegant, but this will be a good plan B.

function setWorkPlane(abc) {
  if (!machineConfiguration.isMultiAxisConfiguration()) {
    return; // ignore
  }

  var workOffset = currentSection.workOffset;
  if (workOffset == 0) {
    workOffset = 1;
  }

  var adjYDest = properties.aAxisDisplacementY * Math.cos(abcFormat.format(abc.x) * Math.PI / 180.0) - properties.aAxisDisplacementZ * Math.sin(abcFormat.format(abc.x) * Math.PI / 180.0) - properties.aAxisDisplacementY;
  var adjZDest = properties.aAxisDisplacementY * Math.sin(abcFormat.format(abc.x) * Math.PI / 180.0) + properties.aAxisDisplacementZ * Math.cos(abcFormat.format(abc.x) * Math.PI / 180.0) - properties.aAxisDisplacementZ;

  if (adjYDest != lastRotationPlaneAdjY || adjZDest != lastRotationPlaneAdjZ) {
    //writeComment("Adjusting Y from " + JSON.stringify(lastRotationPlaneAdjY));
    //writeComment("Adjusting Z from " + JSON.stringify(lastRotationPlaneAdjZ));
    if (lastRotationPlaneAdjY != 0.0 || lastRotationPlaneAdjZ != 0.0) {
      writeBlock(gFormat.format(10), "L2", "P" + workOffset, gAbsIncModal.format(91), "Y" + lastRotationPlaneAdjY, "Z" + lastRotationPlaneAdjZ);
    }
    //writeComment("Adjusting Y TO " + JSON.stringify(adjYDest));
    //writeComment("Adjusting Z TO " + JSON.stringify(adjZDest));
    if (adjYDest != 0 || adjZDest != 0) {
      writeBlock(gFormat.format(10), "L2", "P" + workOffset, gAbsIncModal.format(91), "Y" + -adjYDest, "Z" + -adjZDest);
    }
    lastRotationPlaneAdjY = adjYDest;
    lastRotationPlaneAdjZ = adjZDest;
    writeBlock(gAbsIncModal.format(90));
  }

...

Thanks,

-Peter

[bob.schultz · Accepted solution]

Hello Peter,

It seems that the Haas trunnion post is calling getWorkPlaneMachineABC twice, which is causing this error.  You can add a check to make sure that optimize3DPositionsByMachine is not processed twice.

    if (!currentSection.isOptimizedForMachine()) {
      currentSection.optimize3DPositionsByMachine(machineConfiguration, abc, 1);
    }

You are correct as far as the offset for the B-axis being set to (0, 0, 0).  The small offset for the A-axis as compared to the B-axis should be placed in the A-axis offset.  I also noticed that the offset values seem to require input in MM even when programming in inch.  You should try this and verify it at the machine.  I will research the discrepancy here. 

[jensen_remote]

Thanks everyone for the help, I now seem to have a post that adjusts for the offsets I enter in the machine setup in Fusion360.  I haven't run the code on the machine yet, but a visual inspection of the posted gcode seems to check out.

I do not seem to have an issue with the offsets needing to be in MM.  I entered them in inches and it's posting to the code in inches.  I did some tool-paths with the A-axis at 90 degrees and verified the output gcode x/y/z values are indeed at the correct locations, taking into account the offsets I passed as post properties.  Maybe because I am passing the offsets as properties, fusion360 is auto-converting my inch values to MM?

This will really make life easier, thanks!

[Anonymous]

Hi, this thread has been very useful for me to adapt a Siemens post for an A-C machine with 70mm offset between axes. Using your code has got all my milling operations working a treat. I still have a problem with the canned drilling and tapping cycles though. The initial positioning in X-Y-Z is perfect but the Z values in CYCLE81 etc. are all out if the table is tilted over.

Any neat tips for me? If not I'm thinking of adding some trig corrections to RTP, RFP etc.

[sportbikeryder]

The ability to use offsets should make my previous efforts become reality. I have a 5 axis with a rotary trunion on the A axis and a tilt table on the B axis...but the B is about 7.5" below the rotary centerline as shown in the attached pic. Hopefully the offsets work as I was trying some weird modification of the thermwood post to try to get it to work. 

John

[bob.schultz]

---

@Anonymous wrote:

Hi, this thread has been very useful for me to adapt a Siemens post for an A-C machine with 70mm offset between axes. Using your code has got all my milling operations working a treat. I still have a problem with the canned drilling and tapping cycles though. The initial positioning in X-Y-Z is perfect but the Z values in CYCLE81 etc. are all out if the table is tilted over.

Any neat tips for me? If not I'm thinking of adding some trig corrections to RTP, RFP etc.

---

Hello @Anonymous, sorry for the delay, I am not always getting notified when someone replies to a thread that I am active in.  You are correct that the cycle parameters are not adjusted for offset rotary axes and we will fix this issue.  If you still need a work around for now I can look into seeing if there is a direct method for adjusting the cycle parameters.  You can also expand cycles on this machine for now, which appear to output the correctly modified positions.

[mattdlr89]

@bob.schultz 

I want to look at doing something similar. Are these offsets now in the machine definition (see screenshot). If I plug in the offset values then this should fix any issues with the axis being off?

[bob.schultz]

Hello @mattdlr89,

Yes, if you are using a Machine Configuration then you can place the offset values exactly where you noted in the picture.  The post will use these offset values for adjusting the points for the rotary axes.

[mattdlr89]

@bob.schultz 

and does this now work correctly with 3+2 machining and canned cycles? Or do I need to expand the cycles to get correct Z values? 

[bob.schultz]

Yes, 3+2 canned cycles should be output correctly.

[mattdlr89]

@bob.schultz 

I seemed to get it working but I now get an "ABC coordinates do not match instructed pose" warning in the NC Program. As far as I can tell Machine Simulation is doing the same as my outputted gcode. 

[bob.schultz]

It looks like you resolved this issue by regenerating the NC Program.  Mentioning it here in case someone else runs into the same issue.

[mattdlr89]

Yes I managed to solve by deleting the NC Program in the browser and recreating it. Thanks again.