cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Nested pattern: Reorder to minimize toolchanges

Nested pattern: Reorder to minimize toolchanges

This idea can save a ton of time in ineffecient toolchanges and programming:

2 examples below: 

From 48 to 3 toolchanges! From 28 to 17 minutes

From 9 to 3 toolchanges!

 

If you nest a pattern, there is no possibility to have efficient toolchanges. It just multiplies the lower pattern and any toolchange available which lead to ineffectient toolpath and a lot of changes.

3 toolchanges3 toolchanges48 toolchanges48 toolchanges

It can look something like thisIt can look something like this

And it would also be benefical for multiple parts in one sheet with patterns like this example:

9 toolchanges instead of 39 toolchanges instead of 3

For those of you who want to play with a file, I included the first example as IPT

 

 

 

29 Comments

You can at least get the output you want if you put the operations each in their own folder/pattern.

ArjanDijk
Advisor

Thats true, but it multiplies for the number of patterns X number of tools per pattern. So in case of the example you need 9 patterns which have to be sorted manually. This number increases fast in practice. This is not a workflow I wish, and solving the issue should not be so much work.

 

With more and more users working from sheet/vacuum this would be a welcome and timesaving addition.

@ArjanDijk

in the example part you provided I needed 4 patterns.

1 overall and three separate one's in there.

ArjanDijk
Advisor

9 patterns is needed for the parts that are show in the picture, in the IPT, 4 is enough indeed.

 

But do you want to prove that the problem is not so big in my example? That I did not point at the right picture? Or that you don't see the point for this idea?

I'm trying to prove that the result you are after can be achieved, even though it might not be through the desired route.

And I disagree with the fact that it's becoming more common. It's commong for certain machines and users. And not for others.

So the problem isn't getting bigger, it's the same as has been, and I'm sure is still a niche market for HSM. (Not saying should be neglected)

So I feel there are bigger things to worry about when the result you want can be achieved, lots of things where that isn't possible yet or where the software actually does the wrong thing.

ArjanDijk
Advisor

In my first post I mentioned: This idea can save a ton of time in ineffecient toolchanges and programming, you remove the inefficient toolchanges by making programming less efficient and manually reordering every operation. This gets worse by increasing the number of patterns and operation. 

 

 

Autodesk spends much time on the Datron Post and Datron pushes HSM and Fusion to their customers, so yeah, its getting more common. 

 

But good for you, that you are not bothered by this problem. 

scottmoyse
Mentor
Actually Laurens there are new markets and opportunities being missed because of these types of things. Saying things like 'this issue is no bigger than it ever was' and 'this is only an issue for a niche group of users' doesn't help and belittles the opportunity. Normally you have things like an API to help with these types of 'niche' markets, but that isn't the case here, the HSM API if it's even available is woefully underpowered to solve these issues. There are a few subtle things which can be changed in the product which will help no end, this idea being one of them, but there's a strong resistance to doing any of it and a lack of willingness to engage seriously on these topics. It's one of the things I intend to talk to a few people about face to face next week.

@scottmoyse I agree and disagree.

Just saying something is being used more and more these days to sell your idea is wrong in my opinion. I mean if you interact with a certain group of people you will see it more, doesn't mean it happens more now than before, and I believe that is the case here.

 

I'm all for creating a fix for this, just the way it was presented was like there as no possibility and people were running programs that were 2 times too long because there was no option to fix this.

 

But there are a lot of markets being missed for sure. A lot of people being turned down by or the inconsistency or the lack of features. And both have to be tackled, sadly I don't think we can do that at the same time. And since everything needs to be voted for now I will save my votes for the stuff I feel is needed ASAP, and/or is relevant to a lot of people, and this one might not be one of those.

scottmoyse
Mentor
I didn't say people are using it more and more, I said there is missed potential in what is a large market... by the same token, your field of view is very narrow compared to those who interact with the broad range of manufacturers, so sh*tting on an idea based on your experience as a machine shop and existing users in the forums, because you have proposed a far from ideal workaround, isn't really very fair

@scottmoyse

I didn't disagree with you.

If every reseller was like you there would be a lot less questions and discussions on here.

scottmoyse
Mentor
Ok... it might be that this only gets resolved, when nesting is added to Fusion 360.
Anonymous
Not applicable

@Laurens-3DTechDraw

I mean, on some level - why are you basically defending broken functionality?

 

A few months ago, I spent hours programing a multi-op fixture expecting I could finish it up and click "Minimize Tool Changes." When I got it all done, the functionality did absolutely nothing, requiring many more hours of having to go through and reprogram stuff. Come to the forum and guess what? "Oh, that's broken and we've kinda known about it being broken forever."

 

WTF? The documentation does not mention the limitations of the functionality. It promises that if you output multiple jobs, it smartly reorders tool changes... But then it doesn't. That is totally broken.

 

"But there are a lot of markets being missed for sure. A lot of people being turned down by or the inconsistency or the lack of features. And both have to be tackled, sadly I don't think we can do that at the same time. And since everything needs to be voted for now I will save my votes for the stuff I feel is needed ASAP, and/or is relevant to a lot of people, and this one might not be one of those."

 

I'm trying to figure out how exactly the $27B market cap company needs us ration our feature requests to have basic functionality brought up to the level that has been promised by the documentation for years.

@Anonymous

A totally different button you are talking about. And that one should be fixed ASAP since it used to work much better. But I'm not sure why they don't do anything about it. It could give the same result in practice as what's being discussed here I guess though indeed.

 

Well the trick isn't always money to get development faster. It's not like you can just call in 20 guys and have the wanted result in a month we have been told over and over. The CAM stuff tends to be pretty specific in development. Especially toolpath wise, and for example the tool library stuff.

The UI and reordering button I believe anyone with serious programming skills should be able to tackle it. But it seems there isn't much interest in that.

And in the end it actually is about money, of course, it's not like they will spend all their profit on HSM, pretty sure internally it's you will get what you earn.

 

And we see in practice it's true. We have been waiting on Tool Library 2.0, turning fixes/updates, blend for years.

ArjanDijk
Advisor

Ok, don't see how this contributes to the idea. This should not be implemented because Tool Library 2.0, turning fixes, blend is not implemented.

 

Please leave this topic for the ones that value the idea.

Anonymous
Not applicable

@ArjanDijk

As far as I am concerned, there is no idea to be implemented here...

 

My point is that the functionality is already supposed to be there, when you select Reorder To Minimize Tool Changes during the post. The way it should work is that everything selected (multiple jobs, patterns, nested patterns, mirrors) all get spit out with ordered tool changes across the entire output. It apparently worked like that at one time and was inexplicably changed years ago to break this functionality... and this change was neither documented or explained.

 

This isn't Tool Library 2.0, or Blend, or whatever... this is a feature the dev team broke, and it does not work as promised. That's the problem.

ArjanDijk
Advisor

ok, in that case I understand. But I though that reorder was meant for posting multiple setups.

 

I found out that if I split the patterns in multiple setups and multiple wcs and afterwards set all to the same WCS in the NC code it kinda works, but is still is a big workaround.

 

Would be nice if @fonsecr or @porsbym could respond if this is by design of by accident and if it is easy to solve?

 
fonsecr
Alumni

@porsbym did ask me about this one - but I couldn't remember what I did - too long ago. We will need to have a closer look (AFTER AU 🙂 )

 

ArjanDijk
Advisor

@fonsecr. Perfect!

ArjanDijk
Advisor

@fonsecr Hi Rene, did you find anything?

Anonymous
Not applicable

@fonsecris there already a solution for this problem? It would be nice if you want to work with multiple WCS to have the option to use order by tool what also works in the used patterns inside the setup.... 

Can't find what you're looking for? Ask the community or share your knowledge.

Submit Idea