BIG WARNING ON 5-AXIS SIMULTANEOUS (HEIDENHAIN & HAAS)

[Laurens-3DTechDraw]

Hello people,

We have a 5-axis milling machine(Doosan VC630/5AX)
Which is a Table-table machine and I've found a case where even with the C-Axis set to cyclic the post outputs a rewind of the machine axis. If this happens it will 99% of the times completely ruin your part. Just happened to me and just the material costs more than I can make up for this month.

So search you outputted NC files for the text "rewind" and if it's there don't run it on the machine.
Or set-up your machine to be only negative A or only positive A, will stop this from happening.(This will not be possible for all parts, and The A axis can also be the B axis of course)

Laurens


PS. Tested with the latest Haas UMC 750 post and that has the rewinds as well.

[al.whatmough]

Laurens,


Thank-you for taking the time today to work through this issue with Achim. 


The videos you sent in where also very helpful.


We will be making the following immediate fixes:

• When a rewind is required we will produce an "ERROR" instead of a warning.  The default way we where handling rewinds was incorrect.


• Achim has produced a solution in the post that will correctly handle the rewind.  However, this is a machine specific solution.  As such, it will require post modifications.


• We are updating the UMC-750 post to include this improved method of handling the rewind.

While Achim was able to avoid crashes with his solution, there is also longer term items that need to happen:

• Rewinds should happen in the operation to provide smooth lead-in/lead outs


• This requires the software to be fully aware of the kinematics of the machine (Machine configurations


• Toolpaths should be generated in a way the reduces the need for rewinds

As with many things in the software, this is an area that heavily relies on machine configurations.  This is what also makes handling machine configurations properly such a large task.


I trust the short term solution will meet your immediate needs and look forward to working with you on the ultimate solution.

[Laurens-3DTechDraw]

A. Whatmough wrote:

Laurens, Thank-you for taking the time today to work through this issue with Achim.  The videos you sent in where also very helpful. We will be making the following immediate fixes: When a rewind is required we will produce an "ERROR" instead of a warning.  The default way we where handling rewinds was incorrect. Achim has produced a solution in the post that will correctly handle the rewind.  However, this is a machine specific solution.  As such, it will require post modifications. We are updating the UMC-750 post to include this improved method of handling the rewind. While Achim was able to avoid crashes with his solution, there is also longer term items that need to happen: Rewinds should happen in the operation to provide smooth lead-in/lead outs This requires the software to be fully aware of the kinematics of the machine (Machine configurations Toolpaths should be generated in a way the reduces the need for rewinds As with many things in the software, this is an area that heavily relies on machine configurations.  This is what also makes handling machine configurations properly such a large task. I trust the short term solution will meet your immediate needs and look forward to working with you on the ultimate solution.

Hi Al,(and everybody else)


Thank you very much for the update.

A hard error is a good way to fix this for new customers and people using the generic posts. We do have to think about people that use "old" edited posts as well. I don't need an answer to that, just trying to stop as many people from ruining part or machine.

I'll see if I can make the time to test the "no crash" post Achim has made. It's cool for some parts but for a lot of parts stopping the feed, go straight up turn the table and go back in will certainly not give a good product. So reducing the need for rewinds and therefor implementing serious machine configuration for the toolpath generation will indeed be needed. As I'm sure the coming months were already fully planned for the development team, we'll have to see if we can work around this as much as possible(We do more and more 5-axis work every week so was really looking forward to doing the work the competition can't).

The guys know where to find me and I'm always available for being part of the solution.

[al.whatmough]

Laurens,


With the error handling, old posts will error out too if they do not explicitly handle rewinds

(provided that the axis limits are set in the post)

[Laurens-3DTechDraw]

A. Whatmough wrote:
Laurens, With the error handling, old posts will error out too if they do not explicitly handle rewinds (provided that the axis limits are set in the post)

Good.

[Anonymous]

> We are updating the UMC-750 post to include this improved method of handling the rewind.


Has there been any progress on this? I just took a look at your newest UMC post, and it appears to still be missing any references to rewind.

Under what conditions do you think I can safely do 5-axis moves?

If I manually verify that the end positions of the operation are ok, it shouldn't crash in the middle of an operation, correct?

Edit: Also, I'd be happy to work with you folks on figuring out a solution for the UMC, I'm in SF and have time available.

[Laurens-3DTechDraw]

---

@Anonymous wrote:

Edit: Also, I'd be happy to work with you folks on figuring out a solution for the UMC, I'm in SF and have time available.

---

There is no solution in doing retracts as such. It will still scrap the part.(The finish and accuracy is gone when this is handled in the post)

So the only thing that you can do when you allow the rewinds is roughing and we don't have 5-axis roughing strategies.

The way you can safely do 5-axis is work, is not having any rewind code in the post. This means that if a rewind of axis would be needed the post processor errors out and you know you have to make the path different.

I'm sorry to say that a solution to this issue is also very far away.

[Anonymous]

Laurens, I'm interested in what you're saying when you say it will reduce accuracy and finish. Those might be acceptable sacrifices for me.

Are you saying that removing the tool from the surface, re-indexing, and starting cutting again causes visible seams/discontinuity?

Would that be because of rapid repositioning? If not, what's the cause?

Alternatively, do you know how I can command the machine to always feed so it doesn't need to rewind?

I'd be happy to sacrifice cycle time if it gains me the ability to do 5-axis. I've already marked some post options:

HIGHFEEDMAPPING = ALWAYS

USE G0 = NO

and I don't see any other places I could do it. Any suggestions? I have made a test part that replicates the failure I'm having. (dome66.sldprt) I also made a similar test part that's NOT failing to post, and I can't understand why the difference. (diamond pyramid.sldprt) The only difference I can see is a reorientation move made with the tool still on the surface - in the dome part.

(The stock simulation of the dome also gouges the part, and I can't tell if that's actually happening or if it's a simulation issue.)

[Laurens-3DTechDraw]

---

@Anonymous wrote:

Laurens, I'm interested in what you're saying when you say it will reduce accuracy and finish. Those might be acceptable sacrifices for me.

Are you saying that removing the tool from the surface, re-indexing, and starting cutting again causes visible seams/discontinuity?

Would that be because of rapid repositioning? If not, what's the cause?

Alternatively, do you know how I can command the machine to always feed so it doesn't need to rewind?

I'd be happy to sacrifice cycle time if it gains me the ability to do 5-axis. I've already marked some post options:

HIGHFEEDMAPPING = ALWAYS

USE G0 = NO

and I don't see any other places I could do it. Any suggestions? I have made a test part that replicates the failure I'm having. (dome66.sldprt) I also made a similar test part that's NOT failing to post, and I can't understand why the difference. (diamond pyramid.sldprt) The only difference I can see is a reorientation move made with the tool still on the surface - in the dome part.

(The stock simulation of the dome also gouges the part, and I can't tell if that's actually happening or if it's a simulation issue.)

---

I'll look at your files later. But you can't see a rewind in the CAM software. It's because certain moves can't be completed at the machine due to  it's configuration. For example your machine goes to A-30 but that is the max so it needs to flip the C 180 degrees and to A30. When this happens you need to stop, move the tool up. Reposition the A and C and move the tool back. But since there is no lead-in or out you'll not get a finish you can accept.

[Anonymous]

Thanks for clearing up the specific definition of rewind. It's interesting, none of my toolpaths in that part move any rotational axis more than a few degrees, and so wouldn't require a rewind. But stock simulation shows lots of gouges on the part as well, and with the number of problems I'm having, I'm uncertain whether it's a simulation bug or a real gouge. I suspect it's a real gouge due to mis-detection of faces. I'm going to send in feedback and try to talk to someone directly.

[Rob_Lockwood]

I still can't really figure out why rewinds seem to occur in certain places. The example Laurens outlines is easy to fathom, an axis running out of travel due to asymmetric travel allowance..

But if you have symmetric travels, and an unlimited/cyclic C.. in what instance is a rewind actually necessary?

[Anonymous]

I'd like to figure that out too, Rob. My machine is -30/+110 on the trunnion, and +/-16384 on the table, it should certainly do the part I posted. But here's an interesting update: when I post it using the very latest beta (HSMWorks 2016 R3.41050) it doesn't require a rewind! Maybe some changes they'd already put in the post are working with the latest 5-axis toolpath generation algorithms.

[Laurens-3DTechDraw]

---

@Rob_Lockwood wrote:

I still can't really figure out why rewinds seem to occur in certain places. The example Laurens outlines is easy to fathom, an axis running out of travel due to asymmetric travel allowance..

But if you have symmetric travels, and an unlimited/cyclic C.. in what instance is a rewind actually necessary?

---

Since the CAM system doesn't know how the part is in the machine and how the travels are it might wel be possible it starts a cut on the "wrong side" of the A-axis.(Or B) and therefor causes it's self to still run into the axis end problem. Cyclic Axis can only be defined in the post processor not in the machine configuration so, if you are running your post with a machine config you bet you will see more rewinds. 

Theoretically they won't be needed, and a lot of competitor products don't have those rewind either but for now we have to live with the harsh limitations of this system.

---

@Anonymous wrote:

I'd like to figure that out too, Rob. My machine is -30/+110 on the trunnion, and +/-16384 on the table, it should certainly do the part I posted. But here's an interesting update: when I post it using the very latest beta (HSMWorks 2016 R3.41050) it doesn't require a rewind! Maybe some changes they'd already put in the post are working with the latest 5-axis toolpath generation algorithms.

---

 The Algorithm hasn't really changed, but it would be possible it generates a slightly different path that doesn't need the rewind anymore. The gouging you see is real and will also show on the part. I you made toolpaths on this part in the way a true programmer would, with a little effort as possible. And let's be clear, I understand that and would try something like it myself but this is not what the operation was designed for. So I understand it has some problems. Programming it 3+2 would give a lot better result.

[Anonymous]

> you made toolpaths on this part in the way a true programmer would, with a little effort as possible.

I consider that a fine compliment, Laurens, thank you! It's a real shame that the program has so many five axis toolpaths that we just can't use. I want so much for it to work.

When I do every face individually (which isn't going to work on my real part, as I'm dramatically simplifying this one for demonstration purposes) I have some concave edges between faces. And for some reason 2d contour isn't cleaning them up all the way to the corners, it's leaving a huge cusp. I'll keep fiddling with it.

[Rob_Lockwood]

I haven't had a rewind post failure in quite awhile; since the last time i've screwed with a bunch of stuff, so not sure when they stopped happening..

It seemed to behave differently once I pointed the post to the machine def file in the post dialog box rather than within the post itself. It seems illogical, as the data is identical, but some stuff wasn't populating from the machine def until then.

Most recently, I swapped to limiting B to -110->0, and that's taken care of a few other weird issues involving axis preference.. Now it's just forced to use negative full time, and is working much better (see my other post on heidenhain 5-axis stuff)..

Honestly, *KNOCK ON WOOD* I haven't had any odd 5-axis behavior since then, so lately I've just been trying to optimize the code stream to get better performance, tweaking maximum sweep/fragment length in conjunction with different cycle 32 methods (initially was using something based off of the tolerance, decided this really doesn't make much sense).

[Laurens-3DTechDraw]

@al.whatmough

Is there any progress to solving this issue?

Since the onRewindMachine isn't a fix. It's a hack that fails in 99% of cases we are still desperate for a true fix.

And since we are a year on from this point I would expect us to have some view on if ever and when we plan to fix this.

For me a ASAP fix of this would be great since I run into this on a daily basis and I don't understand we can just act like it's not a problem.

[Anonymous]

I need a fix for the onRewindMachine error too. It is a daily issue affecting my ability to use HSM, and will send us elsewhere if not resoled soon.

[Rob_Lockwood]

---

@Anonymous wrote:

I need a fix for the onRewindMachine error too. It is a daily issue affecting my ability to use HSM, and will send us elsewhere if not resoled soon.

---

This thread is fairly old and outdated; have you seen this thread?

https://forums.autodesk.com/t5/hsm-post-processor-forum/enhancements-to-rotary-axis-positioning-and-rewind-procedure/td-p/7340513

In most cases, these recently released features mitigate rewind issues to where they're significantly less of an issue.