This content has been marked as final. Show 11 replies
Several times I have offset a surface in an assembly to bring that surface into a part for temporary reference, I break associativity, the surface is pushed to the first feature in the part so that I can reference the shape during a part build. After a week or so, sometimes the surfaces will stop being useful and cause errors during a rebuild. For example, if I offset the surface that was brought into the assembly so that it represents the wall thickness, everything is fine for many days, then all of a sudden the offset stops working and I cannot re-select the original surface, in fact, I cannot even make that surface show in the part...
Sorry for the long explanation, no easy simple way to explain this, so any thoughts?
its random, but next time i find one that's reproducible, i'll post it here and our VAR
no, i've had offset surfaces exploded without any modifications done to parent part. I strongly believe there's a bug (surprise!) in solidworks where under certain conditions, it can re-number face IDs and then all goes to hell in a hurry.
I've also learned to avoid this problem by avoiding surface references ---> like the plague. set up a keyboard shortcut. for example, I pick the surface body, then hit F9, and SAVE AS dialog comes up, and i make sure i choose 'selected surface only', and call it something like temp.x_t. Then I hit F10, and which i mapped it to Import Surface command, and choose the X_t. Then i delete the surface offset with the ---> external reference. end result, I have an Imported Surface body, with zero change of being modified without my knowledge, than I can now use on the child part. And as a bonus, the parasolid export/import tends to catch and sometimes even clean up any corrupted surfaces.
Interesting. Same why I do it but I never knew exactly why I did it that way. :-) Thanks Ed for letting my know why I do the things I do.
Sorry - sent to early. I meant to add that by making a snapshot surface in the feature tree of the parent part, I can set the point in history where the surface is most useful for me to transfer to the child. I can set it above any fillets, holes, etc that would FUBAR the surface that gets transfered over to the child.
Is it possible that additional features in the parent part are messing up your child models? Something as innocuous as a split line will cause everything to go to hell, unless you use the snapshot approach.
For what it is worth:
I have not ever had the associativity break, but I do not offset the faces (distance zero) directly from one part (parent) into another (child) in the context of an assembly.
Here's how I do it: In the parent part, I always make an offset surface in the tree of the parent part - I call this a snashot surface. Then, in the assembly, I edit the child part and offset (0) the snapshot surface feature from the parent part.
The reason I work this way is so extra features edited into the parent part do not unpredictably change the geometry of the surface I want to transfer from one part to another. For instance, if I edit the parent part and decide to add filets or holes to a face, the child part is now getting a smaller or swiss cheese surface which WILL mess up references.
I have found that if the reference files are open, the surface offsets define OK. If they are not then there is a high likelihood of failure.
Since I use this so often, I wish that offset froom assy was more offset.
I've seen something like this and I think you understand it's because the surface change or rebuild changes the ID. It's usually because the surface knit or some edge is faulty, such as, a tolerance edge , short edge or vertex issue? Anyhow, something swithces the ID order and your reference is hosed!
Do you have a example to share with us? Or send me it,.. email@example.com
Have you had any luck using knit to copy surfaces instead of offset 0? I wonder if it would be any more robust.
You're just using them as reference. Imagine my frustration, when i do a offset surfaces at distance 0 (because Solidworks can't copy surfaces, I always have to offset at 0), and then use that external ref to cut a solid block, then modify the blcok some more, add pockets, add screw holes, etc,, and then one day, out of blue, when that file is opened up, every single thing in history tree turns into a red X and all i have is just a plain block left.
this bug is a major show stopper for us, and yet its still around for at least 3 major versions, and probably still there in 2007.
best thing is to make a shortcut to save as parasolid, and another shortcut to import parasolid surface, and get into habit of always doing them after every single external surface offset operation.
Thanks for the information John, does seem annoying. I typically only use external offset surfaces for guidelines, with references removed, but even then the surface occasionally just is no longer recoginized and I need to do it all over again. Maybe exporting and importing the offset is the way to go, may give it a try.