Nesting studies with huge computing times

[licensKKGSY]

I'm really struggling with the nesting in fusion. The study contains 30 slightly complex spline-based components, some with pocket features, but nothing crazy IMO. You can see the nest settings attached. The settings for the parts are the same, and bind/unbind doesn't seem to do much difference. I actually can complete studies, but computing times are more than 3000 seconds in some cases, and I can't complete a study at sufficiently fine increment settings for the job.  I feel like I've tried everything; different setting in nest preparation, setting very "unambitious" values in the nest study computing settings, clear cache.. you name it. I can tell the CPU is working at roughly 15% throughout the 2000 seconds of the study, using around 3 cpu cores at any point, so it is doing some work. I have used other Cam software and nesting functions and know this kind of jobs should be possible to calculate in no time. I could go on speculating about all the possible causes, but I hope someone can look into the file and see what I don't.

. 

[seth.madore]

Hmm, something went wrong, the file you shared doesn't have any data in it 🤔

[licensKKGSY]

Sorry about that. Replaced and checked it myself this time.

[licensKKGSY]

I realize my response could sound like I fixed the issue, but what I meant was that I had replaced the fusion file in the original post with the correct one, for trouble shooting.

[seth.madore]

Oh, I understand. Sorry for the delay in responding, still trying to dig into this and find the source of the issue

[seth.madore]

"Arrange" handles this rather quickly, took me less than 10 minutes to churn out some results.

[licensKKGSY]

Yes arrange is great for many jobs, particularly when parts are small compared to the sheet stock. Arrange is okay for this specific job with this few parts. However we often have multiple material thicknesses, parts that can only be nested at very specific orientation, and much higher quantities of unique parts, so optimized orientation is key. Just today I did a nest study of eight unique components with a total quantity of 200 parts. Slightly simpler parts, but also containing pocket features and curved contours. Three different materials and 5 degree increments took less than two minutes. But I've had similar issues to this one on other jobs, so it's the inconsistency and and the lack of a clear cause that bother me.

[seth.madore]

Yep, the Nesting team is going to be looking into your file, I'll post back when I have any more info for you 🙂

[seth.madore]

It's the splines, that's what's killing the process. With splines, it's creating too many sample points, causing our Nest to slow to a crawl. We've logged TRUNFSN-4968 to investigate how we can improve upon this.

[Warmingup1953]

Is grain direction important? I see your settings.

[licensKKGSY]

Seth.Madore tank you so much. That is what I was suspecting based on the nature of the components. Thinking about it, the other cam software we use, only allows nesting of geometries when splines are converted to lines/arcs using a specified tolerance, so there might be something inherently problematic in splines. Well good to know it's the splines, now I can take a dxf through the conversion in Autocad if I need to. Looking forward to hear if the team can find a solution though! 

[seth.madore]

Our Nesting solution is running at a tolerance of .001cm, and this isn't something that is able to be changed by the user (yourself, for example). As such, coupled with the large amount of sample spline points, we end up with a nest solve that takes literal hours. However, if we were to open it up to a .1 tolerance, it now takes 300 seconds. Still lengthy, but manageable. So, what we need to figure out is how to incorporate more intelligence, whether that's exposing a tolerance option or improving the logic when handling large splined items.

As mentioned, we've logged this as a bug and, over the coming weeks, will explore how to best solve this issue.

[licensKKGSY]

Hi @seth.madore,

I see i never got back to responding - Thank you for the explanation, it makes so much sense.

I'm still running into the issue from time to time, so anything new on a tolerance setting for a nest study?

I can't understand how this is not a bigger issue for more people (not just spline-rich parts but slightly complex nest studies in general are way to slow from a practical point of view IMO), but I guess the majority of the nest users must have simpler nest studies to perform. Too me it's a matter of stability in production before the degree of accuracy/optimization. 

I'm on the Insider program and would love to put a setting like that to the test if possible.

[seth.madore]

Yes, we've done extensive work in development to move towards a solution for this. It's not ready for release just yet, but it's coming along nicely

[licensKKGSY]

Hi @seth.madore 

Fantastic! Looking forward then😋

[licensKKGSY]

Hi Seth, 

We continue having massive issues with nest studies of large spline featuring parts. We are forced to maintain two cam packages at this point to get useful nest studies, and we really want fusion to be the tool for all our processes. I would very much like to get in touch with the nesting team on this topic to hear how development is coming along and to explain our usage and proposed solutions. Would it be possible for you to put me in contact with a team member? 

Best regards,

Frederik

[seth.madore]

@licensKKGSY thanks for dropping in to check on this performance issue. I can certainly connect you with some folks who know more about the deeper workings of Nesting, but first, would you be able to share a sample file that demonstrates this issue? You can either share it here to the forum, or send me a private message with a link to the file.

To send a private message, hover over my user name and select "Send Private Message"

Having the data will give our developers real examples to test improvements out on, so it's much appreciated.

 

[licensKKGSY]

Hi Seth,

Thank you for getting back so quickly. Sure, I will share the project with you via a privat message. 

[seth.madore]

File has been received. 

Looking at your file, I see that you have Nesting set to 45 degrees with an increment of 1 degree. With this, the total rotation variation is from -45 to +45, so 90 rotation variations are calculated  per individual part. And then, the next part is calculated, but that forces the part to be calculated against the prior. This leads to (believe it or not) 129,600 calculations to nest two components (90x4) x (90x4).

What software are you currently using where you find that you can nest rather quickly with these fine settings?

[frederik.mide]

Hi Seth, 

You are correct. Basically, my settings should reflect that all rotations and increments are allowed through all 360 degrees. 

The other software we use is Alphacam, which I believe is mainly used by the woodworking industries (or other sheet stock industries like plastics). Their nesting algorithm is both very stable and still highly optimized and even includes the opportunity to mirror parts. As mentioned earlier, Alphacam will only nest wire-geometries (as fusion does under the hood) and always require splines to be converted to lines and arcs using a user-defined tolerance of say 0.1mm). Their algorithm always comes up with a result and will then do iterations on top to get increasingly optimized nests, so very stable in that sense. So I guess (as a layman) the algorithm starts with a lower degree of freedom on each part and then adds DOF's to further optimize. This will allow a desired yield to be obtained by fewer rotations and only really push the computation when needed. Just guessing here off course.