can PCB step files create speed issues?

[maker9876]

I've noticed that project files containing PCBs can get kind of slow when computing motion - like say if you try to drag-rotate a revolute joint.

A PCB (printed circuit board) in my case is typically a STEP file which may contain some 150 components which I then assemble into a Rigid Group. That group is then attached to the rest of the model with a single Rigid Joint. My STEP files are created with Altium Circuitmaker.

Is it possible that such entities slow computation?

If so, any tips? (Like is it possible to convert the many components of the PCB into a single Body, even if that's at the expense of having lots of nice colours?!)

[TrippyLighting]

Yes that is entirely possible but should be easy to remedy.

Fusion360 searches for selectable objects within a conus volume protruding from the cursor. The more geometry is in that cone, the more that algorithm has to work.

You can set those components that are on the PCB to "unselectable" ore even hide them. That will increase viewport performance.

Only those components that are interfacing with the rest of the mechanical design, say connectors you want to create breakouts in a housing for should be left as selectable.

[etfrench]

I think grounding a component will take it out of the compute loop also.  I don't currently have any large slow files to test it on though

[TrippyLighting]

Nope. Because you can still select grounded components.

[maker9876]

Thanks guys.

I tried making lots of things unselectable - nice idea - but in the end it didn't help with performance issues.

In the photo below, the frame structure is grounded at the very base and there are a number of rigid joints internal to the frame.

My impression is that Fusion is somehow getting confused or going about its calculations in an inefficient way. (My assumption is that its very first step would be to calculate everything that is GROUNDED so it would know what could be left out of all future calculations. And calculating what is grounded should be EASY and therefore FAST.)

Joints "A" and "B" were taking 5 seconds upwards to calculate a new position after a drag. They both became responsive when I grounded directly the component at "X".

Joints "a" and "b" were similarly sluggish. However did not become responsive when I grounded directly at "x".

"a" became responsive when I grounded at "y" - a good test but not helpful because that prevents the joint at "b" from working!

[TrippyLighting]

Ha, I know that model. I believe you had shared it with me privately before but I have already deleted it. Could you share it again, please ?

I'd really like to see if:

A. I see the effects you are describing on my 7 year old iMac

B. if I also see it on my new Mack Pro.

I've seen performance problems in a good variety of assemblies now when helping other users and have developed some strategies how to deal with those is this would be interesting to look at.

[maker9876]

Sure, that would be great!

Waiting for the link to arrive from online Fusion and will PM over.

There are quite a lot of assemblies in assemblies... But for good reasons.

[TrippyLighting]

@etfrench I misread the OPs first post. Sorry about that!  Yes, grounding does appear to have an effect on this performance problem.

@maker9876 I see a little late between the Mose movement and the time the arm actually moves but it's sub 1 second on both of my Macs.

I did observe, however that when I created the rigid group for one PCB assembly that you had set to unselectable in that assembly and then delete the rigid group you had created to do the same thing from the top level joint folder the lag increased. Interesting ...

[maker9876]

@TrippyLighting If you want to see sluggish behaviour in the arm in the foreground of the picture above, disable the local ground situated at "X" (it's precise location is given in my PM).

In order to see sluggish behaviour in the up / down arm at the back of the picture, instead of disabling the local ground at "y", simply try playing with the mirrored version which has no local grounds.

Note that normally, before these local grounds were added as performance improvement experiments, the whole structure is grounded simply by one of its feet.

You should see sluggishness of 5+ seconds.

[maker9876]

Well, although I may not have an optimal modelling and assembly, overall I think this is buglike behaviour.

Because:

- fusion recognises that the entire structure is grounded when only a foot at the base is grounded, but joints are VERY sluggish;

- fusion behaves in exactly the same way, but this time snappily, IF the joints are grounded LOCALLY, which is to say components very close to the joint are GROUNDED;

This smells like an inefficiency in the method of calculation.

But what would I know?