AnsweredAssumed Answered

Why do changes in driven variables not trigger a rebuild?

Question asked by Rob Edwards on Oct 18, 2016
Latest reply on Oct 19, 2016 by Mike Pogue

Like • Show 0 Likes0
Comment • 9

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.

Mike Pogue Oct 18, 2016 5:27 PM

Correct Answer

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.

See the reply in context

No one else had this question

Outcomes

9 Replies

Jeff Holliday Oct 18, 2016 3:21 PM
Mark Correct
Correct Answer
"Driven" dimensions don't control other dimensions, "Driving" dimensions do that.
Like • Show 1 Like1
Actions
- Rob Edwards @ Jeff Holliday on Oct 18, 2016 5:01 PM
  Mark Correct
  Correct Answer
  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
  Like • Show 0 Likes0
  Actions
  - Craig Schultz @ Rob Edwards on Oct 18, 2016 5:19 PM
    Mark Correct
    Correct Answer
    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.
    Like • Show 2 Likes2
    Actions
    - Rob Edwards @ Craig Schultz on Oct 19, 2016 8:00 AM
      Mark Correct
      Correct Answer
      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
      Like • Show 0 Likes0
      Actions
Mike Pogue Oct 18, 2016 5:27 PM
Unmark Correct
Correct Answer
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.
Like • Show 1 Like1
Actions
- Rob Edwards @ Mike Pogue on Oct 19, 2016 8:00 AM
  Mark Correct
  Correct Answer
  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.
  Like • Show 0 Likes0
  Actions
- Mike Pogue @ Mike Pogue on Oct 19, 2016 1:24 PM
  Mark Correct
  Correct Answer
  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.
  Like • Show 1 Like1
  Actions
  - Rob Edwards @ Mike Pogue on Oct 19, 2016 2:41 PM
    Mark Correct
    Correct Answer
    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
    Like • Show 0 Likes0
    Actions
Mike Pogue Oct 19, 2016 3:24 PM
Mark Correct
Correct Answer
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.
Like • Show 1 Like1
Actions

Why do changes in driven variables not trigger a rebuild?

Outcomes

Related Content

Recommended Content