9 Replies Latest reply on Oct 19, 2016 3:24 PM by Mike Pogue

    Why do changes in driven variables not trigger a rebuild?

    Rob Edwards
    Rob Edwards Oct 18, 2016 3:01 PM

      It's really got me baffled why this is the case.  I've searched and searched but have found no-enlightenment so I'm hoping someone here can put me straight.

      I've constructed the simplest case I can imagine to illustrate.

       

      An assembly with a single sketch of a vertical line coincident one end at the origin (center/green)

      There's two parts.  The orange line on the right is a sketch in a part that has horizontal relationships to the assembly sketch at its endpoints and a driven dimension.

      The driven dimension is then used to drive the length of the rightmost line.  It doesn't update... even when you open the part, the sketch or the equations.  Notice D1 has a different value in the sketch and in the equations at the same time.  There's nothing.  A CTRL-Q will fix it, but that's no good

      The two lines on the left update perfectly.  They are similarly constructed, ie using a driven variable, but the variable is driven by a sketch referencing a boss extrude up to vertex.

      I really dislike using 'stupid' workarounds, it seems to me like a pretty straightforward situation to want to get the length of something and use it to make decisions on the fly.  I just don't get it.. how should I be doing this?

       

      thanks for looking.

      • 738 Views
      • Tags:
        • Re: Why do changes in driven variables not trigger a rebuild?
          Jeff Holliday
          Jeff Holliday Oct 18, 2016 3:21 PM (in response to Rob Edwards)

          "Driven" dimensions don't control other dimensions, "Driving" dimensions do that.

            • Re: Why do changes in driven variables not trigger a rebuild?
              Rob Edwards
              Rob Edwards Oct 18, 2016 5:01 PM (in response to Jeff Holliday)

              Thanks Jeff .  I understand what you say, but it would be nice to be able to use them to make decisions.  For example a door has a width (driving), and a stile width (driving) which leaves a panel width (driven).  Do I really have to do all the maths myself? How do I interogate my model?  It would be nice to be able to look at a driven dim and use it to decide whether to split the panel into two.  I just don't understand what seems to me convenient is not possible except by a round-a-bout trick

                • Re: Why do changes in driven variables not trigger a rebuild?
                  Craig Schultz
                  Craig Schultz Oct 18, 2016 5:19 PM (in response to Rob Edwards)

                  I would set up your door and stile widths as global variables.  Set up your panel width as an IF statement with the equations you need..  (Or something along those lines with me not doing that for about 2 years.......)

                   

                  If you can post (or PM) a general idea of what the equation is, and when you'd split into 2 panels, I can attempt to do it.

                    • Re: Why do changes in driven variables not trigger a rebuild?
                      Rob Edwards
                      Rob Edwards Oct 19, 2016 8:00 AM (in response to Craig Schultz)

                      Thanks Craig, thats good advice and a great offer. My problem here isn't really a door - I was just using that example as illustration.  It's a flight of a staircase, it worked great in development, but then when I mated multiple copies of it into a master assembly so that a layout sketch was doing the driving I got all kind of problems, multiple rebuilds of hundreds of features, the whole thing kind of ground to a halt.  I need to use the driven dimension to work out a load of reference geometry.  I think I've got it now but yes if it doesn't work I will probably be forced to use global variables in the master assembly.  I dislike using them in assemblies because you then always have to edit the part equations in context or SW says you have an error, but I can live with that.  Thanks again

                • Re: Why do changes in driven variables not trigger a rebuild?
                  Mike Pogue
                  Mike Pogue Oct 18, 2016 5:27 PM (in response to Rob Edwards)

                  Stab in the dark:

                   

                  Probably because it is essentially a read-only variable, and has no setter, only a getter, so there is nothing to trigger the property change notification. There are ways to bubble up the property change notifications, but they mostly entail knowing what is driving the read-only variable. Anything could be driving a driven dimension.

                    • Re: Why do changes in driven variables not trigger a rebuild?
                      Rob Edwards
                      Rob Edwards Oct 19, 2016 8:00 AM (in response to Mike Pogue)

                      Thanks Mike

                      I think you're exactly right, I couldn't believe just how stealthy driven variables are.  It's finding out 'the ways' to bubble up the change notification I'm interested in .

                      I was really surprised that assignment to a variable to a driven dim didn't do this.

                      Also I was mistaken that it was the extrude up to vertex that triggered the update in my example, it was actually a horizontal sketch relation.

                       

                      This example works because of that stray point in Sketch3 that is merely coincident to a line in Sketch2.  Sketch2 works because it has a coincident relation at one end to Sketch1 (not the origin, or layout sketch)

                       

                      I found this slightly surprising because once I had Sketch2 working and updating (effectively translated a driven dim to a driving dim) I would expect the notifications to chain along, but they didn't. 

                      • Re: Why do changes in driven variables not trigger a rebuild?
                        Mike Pogue
                        Mike Pogue Oct 19, 2016 1:24 PM (in response to Mike Pogue)

                        Well, I don't think you personally will be able to do anything about it. It's the programmer. To use a highly simplified example, imagine you have a block and it has 3 properties.

                        Block.Length

                        Block.Width

                        Block.Height

                         

                        Block.Length has a getter and a setter (so that you can get or set it). You can see that when you set it, in addition to setting the value, it fires a property changed event. The even handler for this will trigger a rebuild, and anything else that needs to be done when the length changes.

                         

                        public decimal Length

                        {

                            get { return Length; }

                            set{ Length = value; OnPropertyChanged("Length")}
                        }

                         

                        I want to add a driven property

                         

                        public decimal HalfLength

                        {

                            get { return Length / 2; }
                        }

                         

                        There is no setter for this, because I cannot set the half length in a world where I've already set the length. So there is nothing to fire the property changed event. But, I could at this moment go back to the length definition and add this

                         

                        public decimal Length

                        {

                            get { return Length; }

                            set{ Length = value; OnPropertyChanged("Length"); OnPropertyChanged("HalfLength") }
                        }

                         

                        I can do this, because there is only one place that might affect the half length property. But in your case, there is no way to know where the change might be coming from. The half length needs the change pushed to it, it has no way to pull the change. And the programmer has no way to know where to push it from.

                         

                        The actual implementation would be much more complicated than I've described. But I think what I've explained here is closely-related to why you are not getting the trigger you want. It's not a matter of unfeeling Tetris gods maliciously or stupidly not giving you what you need.

                          • Re: Why do changes in driven variables not trigger a rebuild?
                            Rob Edwards
                            Rob Edwards Oct 19, 2016 2:41 PM (in response to Mike Pogue)

                            Thanks Mike

                            I'm not trying to knock SW, believe me I think it's awesome and I'm not trying to argue or labour the point- I'm just trying to understand how it works, so that I can work better.

                             

                            I have limited programming knowledge so I just about follow your argument.

                             

                            I can see that if I assign a driven value to a variable, then that variable might not notice changes as it's just holding a reference.

                            The driven value itself must have a setter somewhere, but as you say no knowledge of what else might be referencing it.

                            No doubt the implementation would be complicated but in my mind no more complicated what SW already does elsewhere.

                            I suppose I assumed that when an assignment to a driven value is made a request for an on-change-notification would be created. Anyway there's no point me hypothesizing about stuff I know nothing about and doesn't work anyway - I'll end up looking even more dumb ;p

                            Thankyou for your time, I like delving into this stuff.  And today I have managed to get what I want working through carefully creating the notifications through the parent child sketch relationship.  I found that SW could only handle one equation per sketch

                             

                            I mention I have limited programming knowledge, but that is what is getting me in this trouble in the first place.  I am trying to construct an assembly where the parts behave a bit like methods.  Geometry in - Geometry out  - with all the complexity hidden away.  Another one of my flawed experiments no doubt

                        • Re: Why do changes in driven variables not trigger a rebuild?
                          Mike Pogue
                          Mike Pogue Oct 19, 2016 3:24 PM (in response to Rob Edwards)

                          I could easily come up with a hack that does what you want, but the behavior would look pretty goofy.

                           

                          The reality is , SW could probably solve this issue in  a non-hacky way pretty easily, since they are likely 10x - 50x my skill level. Add an enhancement request.