onRewindMachine Issues DMU-60T

[todd_sandercock]

Hi Guys,

I am tweaking my post for a Deckel DMU 60T which has a rotating table (C-axis) and a tilting head (B-axis). To make the most of the work area with 5 axis moves, the B-axis limits are 0 to -90 degrees therefore when sweeping over the vertical axis the rotating table has to swing around 180 degrees to continue following the surface.

My issue is that the onRewindMachine command is not called when the B-axis is actually at zero:

58 L Y+141.729 Z+367.827 B-8.708 F1074
59 L Y+142.365 Z+367.911 B-6.259
60 L Y+143.003 Z+367.967 B-3.81
61 L Y+143.644 Z+367.996 B-1.361
62 ; onRewindMachine
63 L Y+144.285 Z+367.997 B-1.089 C+270
64 L Y+144.926 Z+367.971 B-3.538
65 L Y+145.565 Z+367.918 B-5.987
66 L Y+146.201 Z+367.838 B-8.436
67 L Y+146.833 Z+367.73 B-10.886

As a workaround I can reduce the tolerance to a small enough value, force the B axis to 0, rotate the table with TCPM on and continue on:

96 L Y+143.587 Z+367.994 B-1.579
97 L Y+143.758 Z+367.998 B-0.923
98 L Y+143.93 Z+368 B-0.267
99 ; onRewindMachine
100 L B+0
101 L C+270
102 L Y+144.102 B-0.389
103 L Y+144.274 Z+367.997 B-1.045
104 L Y+144.445 Z+367.993 B-1.701
105 L Y+144.617 Z+367.987 B-2.357

With some dirty code something like this:

var rewind = false;

function onRewindMachine(_a, _b, _c) {
 writeComment("onRewindMachine");
 rewind = true
 return;
}

function onLinear5D(x, y, z, a, b, c, feed) {
  ......
	
  if (currentSection.isOptimizedForMachine()) {
    var f = getFeed(feed);
    
    if (rewind) {
      writeBlock("L B+0" + f);
      writeBlock("L" + cOutput.format(c) + radiusCompensationTable.lookup(radiusCompensation) + f);
      rewind = false;
    }

    var xyzabc = xOutput.format(x) + yOutput.format(y) + zOutput.format(z) + aOutput.format(a) + bOutput.format(b) + cOutput.format(c);
  .....
}

The drama I have with this is that onRewindMachine is called when the C axis crosses 0 and when the B axis tries to go past 0. There doesn't seem to be a way to differentiate between them 

I can trick the post processor to avoid C axis 0 crossings by defining the C axis limits in a non-ideal way:

var bAxis = createAxis({coordinate:1, table:false, axis:[0, -1, 0], range:[-91.001, 0.0], preference:-1});
//var cAxis = createAxis({coordinate:2, table:true, axis:[0, 0, 1], range:[0, 360], cyclic:true});
var cAxis = createAxis({coordinate:2, table:true, axis:[0, 0, 1]});
machineConfiguration = new MachineConfiguration(bAxis, cAxis);
machineConfiguration.setModel("DMU 60T");

This causes issues down the track with cyclic commands like multi-axis tilting while contouring:

11422 L X+149.769 Y+140.211 B-10.603 C+17113.894
11423 L X+150.012 Y+139.849 B-10.657 C+17115.649
11424 L X+150.235 Y+139.556 B-10.702 C+17117.132
11425 L X+150.412 Y+139.356 B-10.735 C+17118.209
11426 L X+150.592 Y+139.158 B-10.768 C+17119.286

The controller doesn't actually care because of the shortest path feature but I'm sure there is a limit to the maximum c input. 

Any help would be appreciated.

Thanks,

Todd

[Laurens-3DTechDraw]

You shouldn't do the rewind move in the onLinear().

It's supposed to be done with or in the onRewindMachine Function.

Have a look at this post. That has the latest and most advanced rewind logic: http://cam.autodesk.com/posts/?p=haas_umc-750

When doing 5-axis I highly recommend using a tolerance of 0.001 or even lower. When you do that you can most probably check 

When you do that you can most probably check if the B-axis is at 0 for the rewind move and then not retract, just do the C-axis move.

[todd_sandercock]

Hi Laurens,

I have read through the UMC-750 post fairly thoroughly. From reading through the code and then confirming it with some test posts I believe it does not handle this condition properly and anyone using that post should have a very detailed look at what code is output because they will find they are gouging their parts......

Detailed analysis:

function onRewindMachine(_a, _b, _c) {

this function receives _a, _b, _c in the orientation before the rewind is actually required, not after.

So if I output some values from my old post with some added comments I get this: (Notice the C-90 on line 68)

42 L X+144.6 Y+157.695 Z+424.213 B-10.886 C-90 FMAX
......
66 L Y+144.076 Z+385.072 B-0.136
67 ; onRewindMachine
68 ; B-0.136 C-90
69 L X+141.5 Y+143.391 Z+385.066 B-1.089 C+90 F1074
70 L Y+142.706 Z+385.046 B-2.313

Then if I output the same section with the UMC-750 post I get this: (Notice the plunge position is identical to the position before the rewind and the C axis rotation occurs with the tool plunged in)

N85 G0 B10.886 C-90.
N90 G1 Y139.09 Z378.532 F5000.
......
N365 Y143.93 Z368. B0.267
(REWIND: Tool is retracting due to rotary axes limits.)
N370 Y143.804 Z395. F500.
N375 G53 G0 Z0.
N380 G53 X-736.6 Y-203.2
N390 G1 X163. Y143.804 F5000.
N395 G0 Z395.
N400 G1 Y143.93 Z368. F250.
N405 Y144.102 B0.389 C90. F1074.3

so my workaround was to push the onRewindMachine into the next position, that way I can correctly handle the table rotation when i actually need it. The trap is that if onLinear5D or onRapid5D is not called straight after onRewindMachine then it could lead to some pretty nasty results although I don't think this can currently happen.

Todd

[Laurens-3DTechDraw]

@todd_sandercock 

What version of HSMWorks are you running?(Shouldn't matter but apparently it does.)

Because when I test I get C-Axis repositioning with the UMC post:

N350 X-29.267 Y0.197 Z-17.561 B34.992 C359.722
N355 X-29.27 Y0.102 Z-17.559 B35. C360.
(REWIND: Tool is retracting due to rotary axes limits.)
N360 X-16.975 Z0. F500.
N365 G53 G0 Z0.
N370 G53 X-736.6 Y-203.2
N375 C0.
N380 G1 X-16.975 Y0.102 F5000.
N385 G0 Z0.
N390 G1 X-29.27 Z-17.559 F250.
N395 X-29.262 Y-4.163 Z-17.548 B35.124 C5.496 F1921.8
N400 X-29.24 Y-8.42 Z-17.516 B35.497 C10.958

Even does it correctly when it doesn't get to C360 or C0:

N1170 X-32.241 Y7.097 Z-16.726 B45.426 C350.149
N1175 X-32.265 Y3.121 Z-16.751 B45.092 C355.409
(REWIND: Tool is retracting due to rotary axes limits.)
N1180 X-15.515 Y1.776 Z0. F500.
N1185 G53 G0 Z0.
N1190 G53 X-736.6 Y-203.2
N1195 C-4.591
N1200 G1 X-15.515 Y1.776 F5000.
N1205 G0 Z0.
N1210 G1 X-32.265 Y3.121 Z-16.751 F250.
N1215 X-32.272 Y-0.865 Z-16.757 B45.002 C0.707 F1921.8
N1220 X-32.26 Y-4.849 Z-16.746 B45.157 C6.
N1225 X-32.231 Y-8.82 Z-16.716 B45.555 C11.242

[todd_sandercock]

Hi Laurens,

I am using Fusion 360.

The case that you have there is when the C axis goes past 360. I modified the stock UMC 750 post to replicate your results by changing the axis limits as per below:

var cAxis = createAxis({coordinate:2, table:true, axis:[0, 0, 1], cyclic:true, range:[0, 360], preference:0});

When the C axis goes past the zero I get the same results as you:

N630 X-38.827 Y5.739 C1.373
N635 X-38.842 Y6.626 B45. C0.
(REWIND: Tool is retracting due to rotary axes limits.)
N640 X-34.913 Z0. F500.
N645 G53 G0 Z0.
N650 G53 X-736.6 Y-203.2
N655 C360.
N660 G1 X-34.913 Y6.626 F5000.
N665 G0 Z0.
N670 G1 X-38.842 Z-3.929 F250.
N675 X-38.827 Y7.53 B44.996 C358.681 F1289.16

When the B axis hits zero and the table needs to rotate 180 to efficiently continue down the other side of a slope it does not though:

N2035 X0.375 Z-24.552 B0.706
(REWIND: Tool is retracting due to rotary axes limits.)
N2040 X0.677 Z0. F500.
N2045 G53 G0 Z0.
N2050 G53 X-736.6 Y-203.2
N2060 G1 X0.677 Y-38.385 F5000.
N2065 G0 Z0.
N2070 G1 X0.375 Z-24.552 F250.
N2075 X-0.456 Z-24.556 B1.2 C180. F1289.16
N2080 X-1.287 Z-24.587 B3.105

Here is my example part:

For whatever reason fusion won't let me share the link to the part at the moment but it's simple enough I think. The second contour is just wrapped around the curve. Nothing tricky.

Todd

[Laurens-3DTechDraw]

If I try this in HSMWorks I can't get it to rewind on the A or B Axis.

So exporting the model to .f3d could help.

We can load that in and see the paths you have...

[todd_sandercock]

That's very interesting if it's not occurring on HSM works

Fusion file attached along with the UMC-750 post, in case it is different to the one you are testing with.

Todd

[Laurens-3DTechDraw]

---

@todd_sandercock wrote:

That's very interesting if it's not occurring on HSM works

Fusion file attached along with the UMC-750 post, in case it is different to the one you are testing with.

Todd

---

I've e-mail the guy responsible for this.

I see the same.

@bob.schultz

I've send you an email on this too. But this is a major issue.

[todd_sandercock]

Thanks for your help Laurens,

Ideally there should be some way to differentiate between the 2 cross over points in onRewindMachine. The B limit hit would be treated differently to a C limit unwind/crossover.

Thanks,

Todd

[Laurens-3DTechDraw]

---

@todd_sandercock wrote:

Thanks for your help Laurens,

Ideally there should be some way to differentiate between the 2 cross over points in onRewindMachine. The B limit hit would be treated differently to a C limit unwind/crossover.

Thanks,

Todd

---

Well,

You could always check if the B is at 0.

In any other case the actual moves you have to do should be the same for a C or B axis rewind.

(For machines with a cyclic C you should never get a C-axis rewind anyway. I know that is being looked at too.)

[bob.schultz]

Hello Todd,

I'll try to address all of your concerns here.  First I'll let you know that we are working on improving how we handle the necessity for rewinding the rotary axes when a limit is reached.  The first step you can see in the latest version of the haas umc-750 post processor, which will be added to other 5-axis posts and a description of the rewind features in this post will be made available as soon as it is added to the other posts.

For your problems ...

onRewindMachine is not called with the B-axis is actually at 0 degrees.

  This is known and has not been addressed yet.  It is outside of the scope of the original project and will take a bit of redesign to get it to work properly.

the rotary positions passed to onRewindMachine sometimes are not correct, either they are the same as the current position or outside of the machine limits

 This is a known problem and is fixed in the post kernel undergoing testing

there should be some way to differentiate between the 2 crossover points in onRewindMachine

  Take a look at the 'unwindRotaryEncoder' function.  You can test both axes to see which one is being adjusted to stay within the limits of the machine by either the B-axis crossing the apex point or the number of degrees the C-axis moves.  You can have the post ignore the C-axis rewinds simply by returning 'true' in this function that lets the post know that it handled the rewind requirement.  In the new post kernel the way 'cyclic' axes are handled has been improved so they are treated as true cyclic axes and will not cause the machine to rewind the rotaries and will resolve this concern.

I would suggest that you set the B-axis limits to the actual limits, or at least give it a small negative limit so that the post kernel is able to position it within limits if B0 is not reached and a rewind is required.

Hopefully this addresses your concerns.

[Laurens-3DTechDraw]

---

@bob.schultz wrote:

Hello Todd,

I'll try to address all of your concerns here.  First I'll let you know that we are working on improving how we handle the necessity for rewinding the rotary axes when a limit is reached.  The first step you can see in the latest version of the haas umc-750 post processor, which will be added to other 5-axis posts and a description of the rewind features in this post will be made available as soon as it is added to the other posts.

For your problems ...

onRewindMachine is not called with the B-axis is actually at 0 degrees.

  This is known and has not been addressed yet.  It is outside of the scope of the original project and will take a bit of redesign to get it to work properly.

the rotary positions passed to onRewindMachine sometimes are not correct, either they are the same as the current position or outside of the machine limits

 This is a known problem and is fixed in the post kernel undergoing testing

there should be some way to differentiate between the 2 crossover points in onRewindMachine

  Take a look at the 'unwindRotaryEncoder' function.  You can test both axes to see which one is being adjusted to stay within the limits of the machine by either the B-axis crossing the apex point or the number of degrees the C-axis moves.  You can have the post ignore the C-axis rewinds simply by returning 'true' in this function that lets the post know that it handled the rewind requirement.  In the new post kernel the way 'cyclic' axes are handled has been improved so they are treated as true cyclic axes and will not cause the machine to rewind the rotaries and will resolve this concern.

I would suggest that you set the B-axis limits to the actual limits, or at least give it a small negative limit so that the post kernel is able to position it within limits if B0 is not reached and a rewind is required.

Hopefully this addresses your concerns.

---

@bob.schultz

That means the current post is still very much able to create a massive crash?

Have you seen my comment in the e-mail on the updated kernel?

[bob.schultz]

Hello Laurens,

In a simple word, Yes.  The production version of the post kernel has not changed recently as far the onRewindMachine logic goes and it still has the same issues that it always had.

I did see your e-mail, but did not answer it yet.  Since it applies to the new kernel, which has been discussed in this thread, I'll go ahead and answer it here.

The reason for the error Rewind of machine axes could not be accomplished within defined range. is that since the B-axis negative limit is set to 0 and the B-axis does not stop exactly at 0 degrees, causing the B-axis to be positioned outside of its limits during the onRewindMachine logic to avoid a crash.  You will notice that onRewindMachine is still called prior to this error being generated, so you can see the solution that takes the B-axis outside of its limits.  For the provided test case you will see the following output.

N2050 X0.0148 Y-1.5112 Z-0.9666 B0.706 C0  <-- last valid move prior to rewind
(REWIND: Tool is retracting due to rotary axes limits.)
N2055 X0.0267 Z0. F20.
N2060 G53 G0 Z0.
N2065 G53 X-29. Y-8.
N2070 B-0.706 C180.  <-- rewind move takes the B-axis outside of the limits

There is no other solution, so the error message is valid.  This is one of the reasons that I recommend setting the B-axis negative limit to be its actual limit, rather than using the trick of setting it to 0.

[todd_sandercock]

Hi Bob,

Thankyou for your reply,

I think I understand enough of what is going on behind the scenes to know why it's difficult to get B to be zero at the crossover point thanks to Rob Lockwoods, explanation of tolerancing and the STL surface that is created.

If I understand your discussion with Laurens correctly:

The B axis crossover occurs when the B limit is set to zero and also when the final B axis position is outside the limit of the B axis of the machine... So on my machine, the limit is +12 to -90 degrees. If the toolpath sweeps from B+45 to B-45 it will still need to unwind at B = 0. Setting the B limit to something other than zero still has the same issues. Personally I will limit the B on my machine from 0 to -90 as there is other issues with X travel when the head is tilted in the +ve direction.

Todd

[Laurens-3DTechDraw]

@todd_sandercock

A small positive value would most probably be enough. So 1 or 2 degrees will work most of the time.

@bob.schultz 

But this means we still got life threatening stuff going on. The whole idea of the onRewindMachine function was to stop these crashes from happening and now they still are in the UMC750 post. You can't help it but this really is unacceptable.

You can't give out posts that you know will crash a machine, part and possibly hurt the user.

@al.whatmough @jeff.pek

Guy's, seriously we are giving out posts with onRewindMachine logic enabled while we know it doesn't solve the problem I've reported here: https://forums.autodesk.com/t5/hsm-post-processor-forum/big-warning-on-5-axis-simultaneous-heidenhai...

Almost two years ago and now we just send out posts again that crash.

[ArjanDijk]

Interesting discussion. I also give big warnings to a customer when using the rewindcycle. Good to hear @bob.schultz that its going into the UI instead of the post.

[Laurens-3DTechDraw]

---

@ArjanDijk wrote:

Interesting discussion. I also give big warnings to a customer when using the rewindcycle. Good to hear @bob.schultz that its going into the UI instead of the post.

---

@ArjanDijk

That not what he says.

It all stays in the post.

[ArjanDijk]

@Laurens-3DTechDraw. Maybe I read what I want to 🙂

I really think it needs to be in the UI to plan a proper lead-in lead-out. 

But its good to see that this topic is being discussed.

[Laurens-3DTechDraw]

---

@ArjanDijk wrote:

@Laurens-3DTechDraw. Maybe I read what I want to 🙂

I really think it needs to be in the UI to plan a proper lead-in lead-out. 

But its good to see that this topic is being discussed.

---

There is only one CAM package that claims to do this.

And for HSM that would have a lot of implications. (You always need to program in your machine assembly, and locate the part exactly like in the machine for example)

So that really would be a couple of year plan as far as I know.

[todd_sandercock]

To do lead ins and leadouts in the UI for the rewind wouldn't be any different to doing 5 axis moves without the full machine assembly as we do now..... It's a great idea @ArjanDijk

Thanks,

Todd