In-Context relationships, intermittently, losing association.

[Arthur NY]

Am looking to see if anyone has been seeing references planes or sketches having broken relationships in the corresponding Part files than only reassociate themselves when the Assembly it is related to is opened. This isn't consistent with every file but happens often enough.

[Damo]

CONSTANTLY..! It's almost as if this is the one thing that I can count on SW doing.
And sometimes they are just broken and do not "refresh".
This is one I experienced just today.

See the baby poo brown lines.
The original entities are still there.
They are converted from the edges of a weldment profile.
The weldment profile has not changed name, shape, size, etc.
There has been no "re-assembling" the assembly.
All components are exactly as they were previously.
You will notice that some entities remain in context without issue.
But yes.! This is just how it rolls sometimes.
I will now need to perform one of the single most frustrating things I frequently need to do.
I will open the sketch to edit, change nothing, delete the offending relations, (not the entities, this would break even more things downstream.)
Reappy new relations for the exact same sketch lines to the exact same weldment edges as was previously.
It's almost like the software just forgets where it is and needs me to hold its hand and guide it back to where it was going.
This is an all-too-regular occurence.

[bnemec]

It's been implemented so complicatedly that it's a pseudo-random generator.

PDM involved? I haven't been able to nail it down, but I get the feeling that there's something to the version of the ref file(s) or if they are cached at all.

Not to be Cpt Obvious, but has this dialog been dismissed? I let it display every time and usually select Open All...

[AlexLachance]

CONSTANTLY..! It's almost as if this is the one thing that I can count on SW doing.
And sometimes they are just broken and do not "refresh".
This is one I experienced just today.
Broken Sketch Relations.png
See the baby poo brown lines.
The original entities are still there.
They are converted from the edges of a weldment profile.
The weldment profile has not changed name, shape, size, etc.
There has been no "re-assembling" the assembly.
All components are exactly as they were previously.
You will notice that some entities remain in context without issue.
But yes.! This is just how it rolls sometimes.
I will now need to perform one of the single most frustrating things I frequently need to do.
I will open the sketch to edit, change nothing, delete the offending relations, (not the entities, this would break even more things downstream.)
Reappy new relations for the exact same sketch lines to the exact same weldment edges as was previously.
It's almost like the software just forgets where it is and needs me to hold its hand and guide it back to where it was going.
This is an all-too-regular occurence.

Have you tried breaking it down in smaller steps? I've had similar issues before and resolved them by trying to figure out the root of the issue by reproducing it in a much simpler part/assembly.

For instance, it could be something as simple as adding a level to the assembly.

So the reference goes from:

Assy3>Assy1>Part1>Sketch1>Relation

To

Assy3>Assy2>Assy1>Part1>Sketch1>Relation

But

The part would still have Assy3>Assy1>Part1>Sketch1>Relation as structure reference.

The extra level being the one that causes the lost references. SolidWorks goes "There ain't no Assy1 in Assy3, there's Assy2 that contains Assy1, but that ain't Assy1!!!"

[mp3-250]

I think it depends a lot on sw settings and your workflow (and your expectations on what the software is going to do for you).

e.g. if you have the option to update the external references only when the referenced part-model is fully loaded in memory (i.e. file-open) opening the assembly alone will not update the single parts references. this is useful in some scenario where someone is working on a part and you want to see its assembly without the referenced geometries exploding in your face.

we (try to) make external references only temporary and they must be broken and converted to "static" dimensions and constraints to keep parts as independent as possible from each other.
we make machinery so you do not know where a part could be reused out of its initial context and you do not want it to be changed by mistake.
that said I think the external reference technique should be used, if necessary, only for machine specific workflows (like piping assembly) or in the early development steps.
Final design 3D parts are archived without relations, so they could be used safely outside their original design intent.

My opionion is that is an extremely counter intuitive workflow and it should be avoided.
we have some welded structure with external parts like flanges and brackets inserted instead of a feature library as they have a drw no etc.
in that case the inserted part inside another part file is just a copy of the external file and it is updated only upon opening the originally linked file.
Until opening the external file its link status is shown as "?" because our sw is set to update the external references only when the parts are fully opened, so you have to manually open those files to see their real geometry and not the copy inside the file that could be outdated.
looking at the pdm task panel could also give the false impression that the file is fully loaded, while only the parent children relations are shown.

I would be not surprised of a number of bugs related to this convulted way of linking geometries: it is complex by design and things could get out of hand and become circular references easily and hard to control unless you have a very strict workflow.

[Arthur NY]

@Damo Many thanks for the insight. In this case it is a reference plane that's losing the reference instead of a sketch but none the less, that you have to go back into the sketch to re-reference things is one of THE most annoying things to have to do over again.

@AlexLachance Yes have done simpler examples and, as a whole, this issue not 100% repeatable when doing the exact same thing. That's the intermittent part about this. It's challenging to try and troubleshoot no matter what method is applied.

@mp3-250 So the main issue is that this is functionality that should no be breaking well after the software being out for over 25 years. This is a baseline level of functionality that should be 99% bullet proof!!! These workarounds are unacceptable, and yes they can be done, but that's almost a heavier lift than even using the software the way it was meant to be. It's one thing if I'm trying to make it do something it wasn't meant to but this is something that users should be able leverage in their daily workflows and not have things blow up. What @Damo is describing can, exponentially, consume SO much time when there are other deadlines to get completed.

[mp3-250]

It is SW we are talking about.
even something straight like "save as pdf" is bug ridden since...forever.

Add to the mix all the "lightweight", "speedpak" and many half backed tricks the devs piled up and dismissed in 25 years and you could see where this mess is coming from.

the only way we could walk to defend our business and data would be to use only the most stable commands and workflows. it is bitter, but in the long run it pays back with stable, almost error free assemblies.

I would like to underline again one thing: even if error proof, external links should be used very carefully and imho only during development phase. once released the design should be as independent as possible. x years from now you or another person opening the file could not be able to fully understand the design intent or all the small caveats of the process and what files are going to change without the user explicit edit.

3d cad is a multipurpose tool not designed around my needs or your needs so we have to adapt and be careful.

[ryan-feeley]

Yes, in-context relationships are a bit flaky. They work enough of the time, or I wouldn't even bother.

If a file has had many edits in its history, stuff gets weird, and doesn't show up until just before the deadline... I've had sketch relations just disappear, relations to non-existent sketch entities with off-by-one errors (so relation is to line9, but there is only a line8 in the sketch), etc. Venture Capital wouldn't have given Onshape all the money they did if they thought our industry was full of users satisfied with their existing CAD software.

One thing you can try is to do a save-as into a dummy part. Then BREAK (not freeze) all the in-context references. Do a force-rebuild, and see what happens. Any relation that suddenly breaks, or geometry that suddenly changes, can warn you about relations that are gonna suddenly break next week. The body compare tools improved around 2020, and are pretty good about catching unexpected changes if you jack the image quality way up.

There are aspects to these softwares that are fundamentally hard problems from a computer science perspective. When the softwares launched 30 years ago, they included a bunch of hacks and empirical workarounds. The people who came up with these have retired, and nothing better has emerged. Perhaps some sort of AI-assist can help the next generation.

There are also real bugs that have nothing to do with the computational difficulty of the task. Just shitty programming, abysmal software engineering cultures, etc. But the bean counters can't tell the difference, so nothing gets better.

This is from 2005. I don't think anything has fundamentally improved:
A Feature-Based Solution to the Persistent Naming Problem

Current parametric modeling systems suffer from the persistent naming problem, which is responsible for the unpredictable, sometimes stunning, behavior of such systems when re-evaluating a model, even after simple editing operations.

[matt]

The problem I saw was that the internal names of edges would get changed due to changes in the model - sometimes seemingly unrelated. Sometimes it's just the edge projection type that changes, not the name. For example, if you have an edge between two cylindrical faces, that edge could project as a straight line, an arc, an ellipse, a spline, etc. So If the type of projected sketch element changes because it is being projected in a different direction or onto a differently angled plane, it can cause reference problems. CAD has to be a programming nightmare.

This has been a problem for well over a decade, maybe two. The way to fix it is to use something that isn't related to SW desktop.

What they're trying to do is incredibly complex. You have to have edges of a part - which are made by intersecting faces and have names - get named automatically or have flexible topology, but keep the same names through unpredictable changes from the user. I mean, how would you do that? It's incredibly complex internal bookkeeping. The fact that it works at all is kind of amazing. The fact that it stops working now and then isn't. If there is another way of doing something, I'd usually pick the other way. For example, master model, insert part, etc...

And then the fact that you're mixing history-based parts with non-history-based assemblies. Geez. And add to that some people are a little too flippant about applying fillets over edges that have in-context references...

[ryan-feeley]

Sometimes it's just the edge projection type that changes, not the name. For example, if you have an edge between two cylindrical faces, that edge could project as a straight line, an arc, an ellipse, a spline, etc. So If the type of projected sketch element changes because it is being projected in a different direction or onto a differently angled plane, it can cause reference problems. CAD has to be a programming nightmare.

Amen to that. Especially that last bit! And consider that it's all legacy code written 5 mergers ago.

I had an enhancement request out years ago to give the user the option to always select "generic spline" as the projection type. I don't think it ever went anywhere. I've had models where if you select a body to insect with a sketch plane, you get a different projection type than if you select individual faces.

I've had an idea for a while to make some sort of macro that runs overnight and just perturbs aspects of a model. Fiddles will fillet radii, lengths, etc, and watches for changes in projection type, edge/vertex count, geometric errors, broken relations, etc. With the idea that you'd want to refactor the model to avoid doing stuff that is on the bleeding edge. There are probably a million things I haven't thought about. Perhaps you'd systematically delete sketch relations, and see if the geometry ever "jumps" in the process. Or you could just run a sequence of CTRL+Q and look at the vertex coordinates out to 10 decimals, and discover areas where you where pushing up against the abstraction of "tolerate geometry".

[TTevolve]

I rarely use convert edges any more or add relationships to edges because of the issues with them changing. Surfaces change less frequently, but can still have the same issues. If I want things to move or grow/shrink I try to use master sketches in my parts connected to a master sketch in the assemblies now. Took me a few trys to work thru it but it seems much more stable. Lines in the sketches don't change like a model edge can and someone has to g into the sketch to change them where a model edge can change just by making a cut or extrude.

[Arthur NY]

In this instance of the intermittent loss of in-context relationships being lost is simply to a reference plane to a point, edge, sketch...etc. This should be low on the totem pole when it comes to things breaking.

More than anything else this is not only in the current version that is being used at the company, which is 2020, but also still exist in 2024 which just says that whatever Q&A/QC in place. I've done enough Alpha/Beta testing over the course of the past 20+ years and while it seems that they always say "These are new features that the most users requested" what, generally, is not said is "These are the outstanding bugs that we did fix".

There is very little transparency about what happens on their side when it really comes to requests and why some are just rejected when it's actually something that's really needed.

[ryan-feeley]

There is very little transparency about what happens on their side when it really comes to requests and why some are just rejected when it's actually something that's really needed.

I have a hang-up with this too. IIRC you must dig deep and then acknowledge a click-thru NDA to even access the "fixed" SPRs list for each release. It is pretty wild.

Ansys QA has a notion of a "Class3 error", which is software defect that results in a simulation result being wrong, but not easily identifiable as such. If you have a QA agreement with them, you get notified within 2-5 days of discovery, and (they claim) this obligation to notify continues for an additional 40 years after the agreement ends. 3DS doesn't need to be at this level, but the opacity is grating.

I don't know if Matt would agree to host it (given the possible NDA implications), but perhaps more public exposure of the known bugs would apply a little leverage on them. Many users are unhappy. It's unclear to me there are compelling alternatives, but if a dissatisfied user can point a boss/purchasing manager to a vetted reference to make their case that they'd like to switch platforms, that might move the needle a little.

Solidworks would be more enjoyable to use if they'd fix the low-on-the-totem pole stuff. But I think Matt's right that there is no cure that involves desktop Solidworks. You can learn the workarounds, you can take @mp3-250's advice to limit yourself to only the most stable commands and workflows, and you can get good at quickly repairing broken models.

For your current situation of an in-context reference to a plane, could you do a slight workflow alteration? What if you used a in-context sketch relation to get enough into the derived model to re-create the plane there? That's what I always do with planes when I want the effect of in-context because that gives more flexibility for repairs if something breaks. The last thing you need is a key plane at the top of your feature tree becoming unrepairable. If it's rederived from local sketch geometry, you can always save it.

[AlexLachance]

I have a hang-up with this too. IIRC you must dig deep and then acknowledge a click-thru NDA to even access the "fixed" SPRs list for each release. It is pretty wild.

Ansys QA has a notion of a "Class3 error", which is software defect that results in a simulation result being wrong, but not easily identifiable as such. If you have a QA agreement with them, you get notified within 2-5 days of discovery, and (they claim) this obligation to notify continues for an additional 40 years after the agreement ends. 3DS doesn't need to be at this level, but the opacity is grating.

I don't know if Matt would agree to host it (given the possible NDA implications), but perhaps more public exposure of the known bugs would apply a little leverage on them. Many users are unhappy. It's unclear to me there are compelling alternatives, but if a dissatisfied user can point a boss/purchasing manager to a vetted reference to make their case that they'd like to switch platforms, that might move the needle a little.

Solidworks would be more enjoyable to use if they'd fix the low-on-the-totem pole stuff. But I think Matt's right that there is no cure that involves desktop Solidworks. You can learn the workarounds, you can take @mp3-250's advice to limit yourself to only the most stable commands and workflows, and you can get good at quickly repairing broken models.

For your current situation of an in-context reference to a plane, could you do a slight workflow alteration? What if you used a in-context sketch relation to get enough into the derived model to re-create the plane there? That's what I always do with planes when I want the effect of in-context because that gives more flexibility for repairs if something breaks. The last thing you need is a key plane at the top of your feature tree becoming unrepairable. If it's rederived from local sketch geometry, you can always save it.

A lot of companies come to see us to see how we operate and I often get asked about SolidWorks. I'm Pro-SolidWorks, but I definetly will not advise someone to move to it concidering their attitude. So that's probably about 15 companies in the last year which were told "Look elsewhere then SolidWorks, unless you like consistently inconsistent issues".

As a small company we can't really pull the levers to get things moving so I take the influential avenue. I help people with their issues on the platform and on here but advise against the program both online and in real life. Words travels fast.

[Damo]

Hio bnemec

It's been implemented so complicatedly that it's a pseudo-random generator.

PDM involved? I haven't been able to nail it down, but I get the feeling that there's something to the version of the ref file(s) or if they are cached at all.

Not to be Cpt Obvious, but has this dialog been dismissed? I let it display every time and usually select Open All...

image.png

There is no PDM involved. These files are only used by myself, on one machie only, all files stored locally on the installed SSD.

This dialog has been dismissed. I did not figure it dramatic to not have the software open every referenced file.
Some of my top-down assemblies may contain dozens of externally referenced files..!
Is this a bad idea.? Does the refresh button not remedy this.?

[Damo]

Have you tried breaking it down in smaller steps? I've had similar issues before and resolved them by trying to figure out the root of the issue by reproducing it in a much simpler part/assembly.

For instance, it could be something as simple as adding a level to the assembly.

So the reference goes from:

Assy3>Assy1>Part1>Sketch1>Relation

To

Assy3>Assy2>Assy1>Part1>Sketch1>Relation

But

The part would still have Assy3>Assy1>Part1>Sketch1>Relation as structure reference.

The extra level being the one that causes the lost references. SolidWorks goes "There ain't no Assy1 in Assy3, there's Assy2 that contains Assy1, but that ain't Assy1!!!"

Alex.

Yes. This is true.
I've experienced broken references for a variety of reasons.
"Form new Assembly here" can do it.
"Dissolve Assembly" can do it.
Renaming components can do it.
Restructuring asssembly components can do it.
Plenty of times there are valid reasons and it is possible to track down the variation nad reattach broken references.
All too often, the exact same component/part/body/plane/sketch entity being referenced is still exactly as/where it was,
despite some other factor has caused the loss of reference.

Not to worry too much, I've gotten reeeaaal good at reinstating references. It is not hard, and is to be expected sometimes.
It's just frustrating..

[Damo]

I think it depends a lot on sw settings and your workflow (and your expectations on what the software is going to do for you).

This is so true. I am well aware of perception bais. And it does occasionally occur to me that I have opinions on how things "should" be, rather than how they are.
But I'm also a realist and I have this tool to work with and I need to work within the parameters of the tool.

we (try to) make external references only temporary and they must be broken and converted to "static" dimensions and constraints to keep parts as independent as possible from each other.
we make machinery so you do not know where a part could be reused out of its initial context and you do not want it to be changed by mistake.
that said I think the external reference technique should be used, if necessary, only for machine specific workflows (like piping assembly) or in the early development steps.
Final design 3D parts are archived without relations, so they could be used safely outside their original design intent.

I do understand this philosophy. But I have a different process for extracting parts that "may" be used on ather assemblies/projects.
Which I'll only implement if required and always involves breaking all external relations and endowing a new filename/part number.
I much prefer top-down for master models as it allows me the comfort of knowing when I change something, everything relevent changes with it.
For me, it is far easier to simply open all connected drawings, see what updates, and create the appropriate revisons.

[Damo]

The problem I saw was that the internal names of edges would get changed due to changes in the model - sometimes seemingly unrelated. Sometimes it's just the edge projection type that changes, not the name. For example, if you have an edge between two cylindrical faces, that edge could project as a straight line, an arc, an ellipse, a spline, etc. So If the type of projected sketch element changes because it is being projected in a different direction or onto a differently angled plane, it can cause reference problems. CAD has to be a programming nightmare.

This has been a problem for well over a decade, maybe two. The way to fix it is to use something that isn't related to SW desktop.

What they're trying to do is incredibly complex. You have to have edges of a part - which are made by intersecting faces and have names - get named automatically or have flexible topology, but keep the same names through unpredictable changes from the user. I mean, how would you do that? It's incredibly complex internal bookkeeping. The fact that it works at all is kind of amazing. The fact that it stops working now and then isn't. If there is another way of doing something, I'd usually pick the other way. For example, master model, insert part, etc...

And then the fact that you're mixing history-based parts with non-history-based assemblies. Geez. And add to that some people are a little too flippant about applying fillets over edges that have in-context references...

Totally..!!

No argument from me. I can only begin to imagine the complexity of coding required to make it work even as well as it does.
As I said before, it not too big a deal and I am reeeaally good at reassigning references.
Sometimes it's expected that references will break due to the needs of the alteration.
Sometimes it just happens and it's difficult or impractical to identify the cause.
This is something I just accept as part of the package.

[bnemec]

Hio bnemec



There is no PDM involved. These files are only used by myself, on one machie only, all files stored locally on the installed SSD.

This dialog has been dismissed. I did not figure it dramatic to not have the software open every referenced file.
Some of my top-down assemblies may contain dozens of externally referenced files..!
Is this a bad idea.? Does the refresh button not remedy this.?

Yikes. I would not attempt that, but in your case you're the only user and from reading your other posts you've chosen this work flow intentionally and seem to be aware of the problems it has and how to fix time. I have some feel for what breaks references and might not, but not enough to have every possibility and it's symptoms memorized. I would never attempt what you're doing at work with dozen or two users on a highly multi-where used data set. But since only one user you can get away with a lot more and you have no-one else to blame, but you never have to wonder, "What the hell was so and so doing? Why did they do it that way?!?"