7 Replies Latest reply on Nov 4, 2016 2:09 PM by Napat Tamisanon

    BLOCKS lose references on rebuild - this is absolutely ridiculous

    Darryl Daniel

      OK I'm using SW2011 x64 (SP5.0) and I have a huge assembly which is entirely driven by a master sketch model.  All parts in my assembly are created using the master model (i.e. top-down modeling technique where the first feature in every part is to insert the master sketch model and then use it to define geometry, interfaces, etc).  This technique is awesome but I have one major problem.  I'm using some blocks in my master sketch model showing some mated connectors.  In my assemblies, when I define the connector positions and constrain them to lines on the sketch blocks (which locates them per the master model), every time I regenerate the assembly the mate constraints completely make up new relations and all my connectors end up in the wrong place.  What seems to be happening is that every time I regenerate & save my master model, the internal ID of lines within the sketch blocks seem to be changing and so in the assembly, the connector mate constraints end up wherever the internal ID of the sketch block line moved to.  This is maddening and makes using blocks completely worthless.  I've seen others have issues with this and have read all the threads.  Many simply say to not "link" the sketch block.  Mine aren't linked....so this isn't the problem.  Does anyone have any ideas how to prevent this from happening?  I have fixed the constraints about 10 times now and it just keeps happening.  Please reply if you have any suggestions.

        • Re: BLOCKS lose references on rebuild - this is absolutely ridiculous
          John Sutherland

          It would help me if you broke your problem description into point form instead of prose.

           

          I am guessing that your master model is a .sldprt document containing 2D information.

           

          Is that one block or a mix of blocks and sketches?

           

          Are your blocks saved individually in .sldblk documents?

           

          Why did you choose blocks?

           

          Are you editing blocks after they were saved, and is that in the .sldblk document or the .sldprt document or .sldasm document?

           

          Are there any solid bodies in your assembly or is everything 2D?

           

          Can you post a fragment of your document to illustrate how you are using blocks?

            • Re: BLOCKS lose references on rebuild - this is absolutely ridiculous
              Darryl Daniel

              John Sutherland wrote:

               

              It would help me if you broke your problem description into point form instead of prose.

               

              I am guessing that your master model is a .sldprt document containing 2D information. YES correct

               

              Is that one block or a mix of blocks and sketches? Both blocks & sketches

               

              Are your blocks saved individually in .sldblk documents? Yes

               

              Why did you choose blocks? I want flexibility to use the same set of blocks in multiple places/sketches in the master

               

              Are you editing blocks after they were saved, and is that in the .sldblk document or the .sldprt document or .sldasm document?  Yes and this just creates even more problems.  I have tried editing in the .sldblk document but it doesn't seem to update anywhere (even when it is linked).  I have tried updating in the .sldprt and then re-saving the block

               

              Are there any solid bodies in your assembly or is everything 2D?  The assembly is full of solid bodies whose geometry is driven by the master sketch .sldprt file (typical of master modeling process).  All parts have the same coordinate system

               

              Can you post a fragment of your document to illustrate how you are using blocks?  I can't do this unfortunately as it is proprietary design for a client.

                • Re: BLOCKS lose references on rebuild - this is absolutely ridiculous
                  John Sutherland

                  John Sutherland wrote:

                   

                  It would help me if you broke your problem description into point form instead of prose.

                   

                  I am guessing that your master model is a .sldprt document containing 2D information. YES correct

                   

                  Is that one block or a mix of blocks and sketches? Both blocks & sketches

                   

                  Are your blocks saved individually in .sldblk documents? Yes

                   

                  Why did you choose blocks? I want flexibility to use the same set of blocks in multiple places/sketches in the master

                   

                  That makes sense to me.

                   

                  Are you editing blocks after they were saved, and is that in the .sldblk document or the .sldprt document or .sldasm document? Yes and this just creates even more problems.  I have tried editing in the .sldblk document but it doesn't seem to update anywhere (even when it is linked).  I have tried updating in the .sldprt and then re-saving the block

                   

                  I can confirm that editing a .sldblk document is a waste of time, except when I have imported a .dxf profile which had gaps and duplicate elements, but even then it might have been better to fix it in Draftsight.

                   

                  It is not clear to me whether you went back to the .sldprt document containing the sketch from which the block was made.  I have not tried this but I imagine it is the best approach.

                   

                  Are there any solid bodies in your assembly or is everything 2D?  The assembly is full of solid bodies whose geometry is driven by the master sketch .sldprt file (typical of master modeling process).  All parts have the same coordinate system

                   

                  Can you post a fragment of your document to illustrate how you are using blocks?  I can't do this unfortunately as it is proprietary design for a client.

                   

                  SW will never admit that their documentation is ratshit, so we have to work out in each case whether what we infer from their documentation is correct or not.  I can understand why you expect your approach should work, but my observations of blocks help to explain why it may not.  I am forming the view that blocks are lightweight, dumb, non parametric profiles.  This is not a problem in the cases where I use them, but if you are expecting an association, reference, relation, linkage, derivation or inheritance to/from another component, then you may be disappointed.

                   

                  I am hoping that someone with more than our combined knowledge of blocks will chime in here.

                   

              • Re: BLOCKS lose references on rebuild - this is absolutely ridiculous
                Matt Wallace

                I too have run into the problem in which using blocks in a skeleton part does not work they way I would expect, and the behaviour is undesireable.  I have been working on workarounds, but this has not been tested with much thoroughness, so use at your own risk.

                 

                1. rather than blocks, you can use derived sketches.  If you don't have too many block references, this isn't too bad.

                 

                2.  I just tried this, and it appears to work.  Use blocks in your skeleton part, but for anything you want to reference, lay another sketch on top of the block-containing sketch, and convert the entities of the block.  If you do  this, it appears you get back some of the selection methods  in subsequent parts, like select chain.  Hide sketches containing blocks in your downstream parts, and this might work out OK for you as well.

                 

                If either of these methods work out for you, I would be interested in hearing about it.