No alignment suggested by geometry could be found
Hi @mpulliam6CT22,
Could you possibly share your model or a screencast of what you are seeing? You should still be allowed to align geometry (making sure you are aligning components, not bodies) for components with joints, as long as the joint would allow that alignment. That is, you cannot request an alignment that would violate the motion of the joint.
Jeff
Jeff Strater
Engineering Director
Thanks, @mpulliam6CT22, I understand that you cannot go back to the state where you saw the problem. If you do ever run across this again, let us know. It should work OK.
As to whether having a grounded component would help, I'm not sure. In theory, it should not. It's a possibility, though.
Jeff
Jeff Strater
Engineering Director
@mpulliam6CT22 wrote:
Literally I created a bunch of components, aligned them and added as-built joints.
That is a bad idea! Use normal joints!
As built joints are intended for joining components that were created in place using a top-down design work flow. In that case no position capture is needed.
In bottom-up designs you should use normal joints.
The position capture feature stores the location and orientation of every component in yr design at that point in the timeline. As your assembly grows that data set stored in the position capture feature grows. This can slow down an assembly significantly.
I can shed some light on this. Here is what happens when a Capture Position is created:
- Any component which has been moved (not all components, just those that are not in their computed position at that point in the timeline) are put into a list in that feature
- the transforms of those components are recorded into the Capture Position feature
When this feature is executed on compute, what happens is:
- the transforms of the component in the list in the feature are set to the values stored in the feature
- an assembly solve happens.
The only part of this that can cause performance problems is the assembly solve. So, if you have a) a complex assembly with lots of joints, and b) lots of Capture Position features in your timeline, then yes, these can cause noticeable slowdown. The recommendations I would make are:
- Capture Position, itself, is not evil. I do use the "Align Components + Capture Position + As-Built Joint" workflow a fair amount. It is not as associative as I wish it could be, and certainly a "regular" joint is better, if you can find one that works for the geometry that you have. But, I have found myself in situations where that method doesn't work well, or requires jumping through hoops that I don't want to do at the moment, etc.
- What is evil is gratuitous Capture Positions. If you have 10 of these in a row, then chances are that your workflow is not ideal, and some or all of these can be eliminated. I know that Fusion enables, and even (unfortunately) encourages this bad behavior. The worst instance of this is the "regular joint" command. How many of you have dragged a component out of the way, just to make it easier to select the geometry needed to create a joint, only to have a (completely unnecessary) Capture Position in your timeline? We have a project lined up to fix that one, but it hasn't risen to the top of the priority list yet. The solution is a bit tricky in a few cases... In the meantime, if you know, at the time that you create the joint, that only the components involved in the joint have been moved by the Capture Position, then you can safely just kill that Capture Position feature immediately. That's what I do.
You might ask why Capture Position even exists, and that annoying prompt asking whether you want to create one or not. This is due to the history-based nature of Fusion assemblies. In Fusion, unlike some other CAD systems, you can perform modeling operations that are based on the positions of components at a specific time in history. For example, if you are creating a design with a folding handle, you can very easily create geometry that is driven by the handle in both the open and closed positions, all in the same timeline. So, any operation that potentially can refer to geometry in another component (project in sketch, combine, to-face extrude, etc) needs to know whether, at re-compute time, it can be assured that the components are in the same position as when that command was executed. So, it needs to "capture the position" of the components in the design, at that time. The one missing piece is some more intelligence about which components' positions need to be captured. Say you have components A, B, and C in your design, and you are about to use Combine to join A and C together. If only B is out of its computed position, then, theoretically, a Capture Position is not needed. But, Fusion is not prescient. It doesn't know, at the time you start up the Combine command, that you don't intend to even involve B in the operation, all it knows is that Combine is a position-dependent command, and some components are out of position. Now, if we were clever (and had a lot of time on our hands), we could maybe delay the creation of the Capture Position until after the geometry has been picked, and we can determine that B is not involved, and so we can skip the Capture Position for it. Maybe some day...
Sorry for the Sunday dissertation. Got a little carried away. Enjoy
Jeff Strater
Engineering Director
@jeff_strater wrote:
Sorry for the Sunday dissertation. Got a little carried away. Enjoy
No, carry on .... how else will we get "real" documentation 😉
Thanks for the in depth explanation!
I've noticed in an older design I had not deleted the position captures that could be deleted, usually those - as you described - which were only used to pull a component into a position for easier assembly.
That design also used some user parameters. After removing those position captures, when changing a user parameter re-calclation was almost twice as fast.