I’m rudely blogging live from a breakout session. Of all people, it’s Matt Lombard I’m doing this to. He will appreciate the ironic nature of this activity. Will he hate me for it when he finds out? No, unless my typing annoys him right now.
OK, I’m far enough back in the room where this doesn’t seem to be an issue, though there may be people around me that might be annoyed. Again, no one seems to care. (If the person next to me is trying to hint to me to stop by clearing your throat, let me apologize now. Anyways, here we go!)
Matt says people are error phobic. They worry if they have errors in a model. This may cause unnecessary worry about finding errors in models.
Horizontal modelling is taking things to the extreme to protect your modelling data to avoid errors in the model. Someone interested in this type of modelling approach is interested in trying to solve a problem they are experiencing. The two methods to address such problems are to 1) ignore them when they crop up, or 2) presumptively stop daisy chaining references. Link to objects that don’t break, such as sketches and planes. Don’t link to solid faces, edges and vertices.
He compares a model created through regular practice with the same part modelled with horizontal modeling. The relationships between features are all over the place with the regular methods, compared with clean results from horizontal modeling. In the HM model, origin planes form the foundation, when are linked to reference places, then linked to reference sketch, with independent features that are all linked back to the reference sketch; at the end are the fillets.
Design intent is described by the edges. HM allows one to lay out design intent with a set of sketches. Features created from this will not fail if they are re-ordered (except for fillets). Matt then demonstrate that HM doesn’t work quite by accident, so we continue the demonstration “theoretically”. I think the failure to achieve the desired results shows just how hard it is to implement HM effectively. Thank god watching Matt is entertaining because this type of issue in any other session would result in very boring dead time. Matt actively engages the audience, which is now trying to address why SolidWorks created unintended relationships in his demonstration model. Going through this process is interesting, but distracting.
In a question from Matt about who is using HM, the audience answers. One person states they use HM for multiple configuration components, but would not bother in a simple single configuration part. Another individual states it is also useful in in-context model assemblies. HM may also be useful in 2D drawings. Of course, now the audience is trying to discuss the demonstration model. There doesn’t really seem to be a consensus; again pointing back to issues with trying to employ HM. Of course, maybe that just means there are more than one way to achieve stable HM.
HM models are modelled to live forever through changes. Concept modelling may not be able to employ HM techniques since the part may not be fully understood at the time when modelling is started.
In an almost conclusionary lament, Matt states that everything in SolidWorks is like a balance between stability versus speed of use. Using HM modelling techniques is a tool to use at the appropriate situation, such as well understood production items where the design is complete before modelling begins.
OK, just for the record (Matt), the only reason I’m live blogging is because I really do not have the time to get all the articles done that I want to this day. I promise I will not do this in the future. Thank you for your presentation.