Do You Really Need History?
This discussion is really for current users of history-based systems. People who already use direct edit software will probably think it a little pedantic. I just want to establish that the need for history-based modeling isn’t inherent in CAD. It might be simple enough to just say that, but I’m going to try to make the case for that point of view.
You can’t create entire parts like the one on the right in one fell swoop, so you have to start somewhere, and end somewhere. Basic training for SolidWorks has been pretty successful at teaching people how to model with history-based systems. But not everybody gets it right away. There is no obvious connection between the ability to design mechanical parts and the ability to conceptualize them as time-dependent features.
What you are really interested in here is dependency. But dependency doesn’t have to be determined by which feature existed first. The shape of the rib connecting the two cylindrical bosses depends on the shape of the bottom plate. The locations of the gussets depends on the locations of the circular bosses. So yes, I agree that within mechanical design, you have to worry about dependency, but that dependency doesn’t have to be based on a time-based parent/child concept.
I can still remember when the light went on for me, and I first really understood history-based modeling. Some people described it as a “recipe”, but I wasn’t much of a cook. Instead I understood it as being much like programming, but using geometrical logic instead of process-based logic. Programming has to execute line-by-line, and it matters what the order of operations is. If something goes wrong, the whole process stops. You have to go back and fix things as they go wrong. You can’t always plan a program perfectly, so you are always editing it. Sometimes with programming, you can get a result that is wrong. Even if it doesn’t fail, it might still not be right.
Just like with programming, history-based modeling has a lot to do with planning, and fitting the end product into the process. You spend a lot of time thinking about “how” to do things and about the CAD tools, rather than thinking about the design itself. There has been some discussion lately about the allocation of brain power between design and tools on the Dezignstuff blog. Many of the ideas originated on Evan Yares’ blog. How much energy do you put into discovering, documenting, teaching, and enforcing “best practice”? Best practice is all about the tools. With history-based modeling, “how” you accomplish something matters very much because it effects how others will edit it, but it doesn’t add any value to the design.
Most programmers don’t really understand the applications that they develop. They are in the end specialists in the programming tools. It’s interesting to me that the creator is often unaware of how his creation will be used. The metaphor extends to mechanical designers. Most of us don’t use the things we design. Just think how much better things would be if the people who created them were actual users. But we can’t do that because all the tools require specialists who may or may not understand design in general and a particular product in specific.
Editing a part in history based CAD is like troubleshooting a program. You have to search back through your code (feature list) and see where the problem is. Are the inputs correct? Am I using the right calls/features? Have I set the parameters/options properly? And once you have found the problem, you run it again to see if you got the output you were expecting. Some edits are easy. Some are difficult. Some edits require a restructuring of the program.
Truth be told, I enjoyed programming until I figured out that I wasn’t any good at it. Being a good mechanical designer doesn’t make you a good programmer. Finding people who can do both really well is rare.
Part of the argument for history-based CAD that I originally felt compelling was that you edited features in the same interface used to create them. So it was consistent, and made more sense. But even if editing and creating are done with the same interface, they are still worlds apart conceptually. If you’ve done much CAD in real world projects, you know that you create once, and edit many times. You also know that it’s easy to create something, and much more difficult to edit it, even if the interface is the same. When you create, you’re only worrying about order in a kind of existential way. The only way to create dependency is to have order. But when you edit something, the order no longer matters. Only the dependency matters.
This brings us to a difficult question. Sometimes a feature eliminates the thing it was dependent upon. For example, fillets remove edges, and yet they were dependent on the edges. In reality, fillets are dependent on faces, but let’s stay with the edges for a minute. In this kind of case, applying the fillet with some sort of time-dependency really does make sense. Solid Edge can edit geometry where fillets are “just geometry”, but there are some limitations. There are other kinds of cases where certain driving topology gets eliminated, and these are all candidates for working with “ordered” features on top of the synchronous model. This is exactly what Solid Edge (ST3 and later) does. The real power here is the ability to combine both paradigms. This is what I find so compelling about Solid Edge.
I agree completely about integration and it was the one really nice thing about VX/ZW. Two clicks and you were in part edit mode and one click to return to the CAM plan with a common GUI.
Reading competing products is a problem and one I suspect many are not in a rush to fix. My only real basis for personal comparisons is VX/ZW and SE as they are the two I have used from the begining. SE is a dramatically better product for this and when you add in ST there is no looking back.
Hi Kevin,
Just a thought here on translation. UGS Siemens write the parasolid kernal and I presume they have the best implementation of it in all regards. I have had problems with ZW for instance on parasolid imports. My cylinders get broken into segments instead of remaining as a cylinder. I told this to SE about a year and a half ago and they were concerned enough about it to meet with me. I live 63 miles away from them so it was easy to do. Convenient eh! They went through some analytics with my file and watched what I was doing to create and import the file from SE into ZW. It was a ZW problem and they knew it as was later admited to me by Jarrod Schmidt a past tech support guy the Chinese ran off.
NX and SE are I would think at the forefront of accurate Parasolids implementation.
I can’t comment about the situation with VX aside to say that VX does not use the Parasolid kernel, so any translation will always be troublesome. As far as I am aware VX also used a bought in translator for Parasolid. Must admit I tended to use STEP for VX as I found it more reliable (but then my version is a few out of date now).
With regards to this situation though, I think the issue is any application trying to read a competitors native format is always going to be a problem. Often in simpler parts there are no big issues, but when you have surfacing and issues of continuity or areas where – in the native application – the kernel only just copes, then they more than likely create errors at export time.
NX and SE should be using the latest Parasolid implementations but that does not necessarily mean that a shell or round, for example, that works in SolidWorks will also work in SE – and vice versa. It depends on the calls made to the kernel (all this was explained to me one time by Rob Bou of Ashlar-Vellum – at one time Cobalt could out fillet and shell anything on the market and it was all down to the way the apps were set up).
This issue is one where integrated CAM comes into its own – there are no translation issues to deal with.
Thanks Andrew, great information. I was having a coffee there and searching YouTube and came across this series of SoldiEdge demos modelling a hand mixer.
http://youtu.be/iTEUOmnelFk
This is a series of demos running to hours – so I’ve not checked them all out 🙂
But from what I have seen there are some interesting options and workflows there. It is a bit different to what I’m used to (particularly the surfacing and master model split part approach). Any people interested should check it out.
thanks Kevin,
yes I saw them a while ago. I watched it through a few years back and it is quite involved.
There is also a video on YouTube somewhere of someone modeling a shower head with surfacing. This was very well done also.
Enjoy the coffee!!
Thanks for the link Dave. Not 100% sure what is going on without the sound but from the video it looks like the changes are being made because SolidEdge has imported the SolidWorks part with errors – there is a missing surface.
This kind of makes me wonder how good the native import actually is for more complex parts. I’ve only seen relatively simple stuff in demos – like extrudes, with a few holes and fillets being imported natively (the very parts that are incredibly easy to edit in almost any system).
Having said that, I do like the interactive surface editing. On that same part it would be interesting to see how you would go about making shape changes to the sides, or adjusting that back fillet edge. This is exactly the kind of stuff that I’d like to see Matt trying.
Hi Kevin,
You are partly correct with the SW import. It actually took 9 minutes to import but the errors were there in SW design (that’s why I had to change it). SE replaced their internal SW importer to a 3rd party and it sped up the import process to just a few seconds. It also improved the inventor import process also (now all you need is to have the Inventor viewer installed instead of the whole program). This was a huge improvement.
You can change the back fillet edge in exactly the same way. As for the shape changes, that’s where SE needs to put in the work and completely overhaul the surfacing ability and combine it with synch tech. This alone would elevate it to the top of the tree for me.
Kevin,
Here is the part Andrew used last year at the SE event in Huntsville. It was done in Solid Works and then imported into SE.http://www.youtube.com/watch?v=0X6KrwPTn6E&feature=plcp&context=C428bfc3VDvjVQa1PpcFMY8mUJ3Jk0dGVywqqiY44ScqUevX7vNG8=
Sorry Andrew. Misunderstanding. I’m just basing comments on direct experience. Often the easiest way to edit surfaces is to replace it Rhino style. Having said that I’ve never seen any demo yet of editing an imported dumb complex surfaced model where you have multiple interlinked surfaces.
Hi Kevin,
I don’t remember writing to delete and rebuild. In fact the opposite. I would use ST to manipulate.
As I said I demonstrated this approach last year at the SE launch event. No deletes no rebuilds, just manipulation using ST on a SW surfaced part.
Best
Andrew
Matt I am very interested to see where you are taking this investigation. Prior to the recent resurgence in Direct Modelling virtually all original 3d apps were direct modellers in the sense that you created geometry them tweaked it or rebuilt it. Then along came PTC and then Solidworks etc.
The problem I have with the way direct modelling is promoted by SolidEdge, NX and Spaceclaim is that they only ever show cases where parts are simple or where parts are so complex that you are waiting on some complex shells or rounds to rebuild. I do agree on that latter case the lack of the tree is a benefit but not at the expense of lack of the ability to just select the feature and change it.
I have never seen any demo featuring any direct modelling product where I can directly change a complex surface that has shells and ribs etc already in place. Every job we do where, say, we have used a boundary surface set to create a skin we need to go back and subtly tweak tangency weights, drive curves etc. or in some cases make bigger changes like rebuild the surface with new curves.
I can do all this in history and associative design apps. Nobody has demonstrated you can do this directly (except Spaceclaim in conjunction with Rhino, which to me is a way to make Rhino better).
The other situation we do a lot of is top down assemblies built from rules driven by a couple of master sketches. Again I’ve yet to see an example of how this works in Direct Modelling. We use DriveWorks Xpress for some of these and homegrown for others. Can ST accommodate this type of approach?
Kevin, I feel that I’ve answered this question (SE for complex shapes) many times. I do not hold any delusions that Solid Edge (synchronous or ordered) can currently do swoopy shape development to compete with SolidWorks. I am not replacing SolidWorks with Solid Edge in my modeling business for swoopy parts. Please refer to my Dezignstuff post on the comparison between SW and SE: http://www.dezignstuff.com/blog/?p=4139 NX does the kind of stuff you’re looking for. I have yet to see anyone show an example of a swoopy SE part that rivals what I can do in SW. I’ll do a post where I try in SE to make a verbatim copy of a complex part that I’ve already made in SW.
In terms of design table parts, KBE and such, that’s one thing I’ll be looking into. They do have family of parts, but it’s different from configurations. I don’t see why they couldn’t drive a part from a table, though, which is essentially KBE.
Hi Matt,
Can you post some of your swoopy stuff done in SW for us to take a look at (native files will do as I can import them directly in SE).
I have a similar thought to SE when it comes to surfacing. What I do know is that something has to give when it comes to development. Surfacing tools and flexibility does need updating when it comes to SE. I think it is becoming one of the hottest requested feature updates as I keep reading this on almost every blog. I’m sure it will get some attention in the future from Dan and the team there.
There is one thing that I did demonstrate in last years ST4 launch event. I imported a SW surfaced part and changed a face and some geometry errors using synchronous principles. Total change was about a minute or so. I did ask some SW users how they would have changed the part (as neither I nor they would know the design intent but had a rather large history tree to deal with). The answers varied from I wouldn’t know how to change it to a long complex verbal instruction on how it could be done, all taking longer than 1 minute.
My point is that synchronous technology has huge benefits to quickly changing something (surfaced or not) after the fact. It saved my bacon many times when I needed to change a SW or Inventor part from companies that we have purchased. I keep finding ways to do things every day that in the history days would have seemed like workarounds but now you have to start thinking creatively when designing or creating parts in synch tech.
SE cannot do everything, I think we can all agree that and I am excited about the progress and the future of history free modeling.
Andrew, for examples just refer to my Dezignstuff blog, and go to the Modeling Examples page: http://www.dezignstuff.com/blog/?page_id=6570
This doesn’t have actual models to download, but it gives a visual of several different models.
I think synchronous capabilities combined with complex surfacing would be killer. I would totally drop SW for that kind of capability.
Thanks Matt. I’m very interested in the top down sketch driven assembly methodologies. Surfacing wise it is ironically the editing that we need. I would love to just pick a bit on a surface and just raise it a few mm say. The technology that excites me right now though is Autodesk Fusion with TSplines due on their Labs site soon.
With regards to Andrew’s comment about changing surfaces by deleting and rebuilding I don’t see that as a great solution. That approach is not exclusive to ST or any direct modeller. The problem I see is that to do those kinds of edits in a direct modeller it is the ONLY option. At least with a feature tree you can edit drive curves and features.
Probably the best app I use for this kind of editing – direct and associative- is Shark FX and Ashlar Cobalt. In these you can direct edit surface control points. Any related features from that surface (like a shell, ribs, blends etc) update.
Hi Matt,
Now all we have to do is kidnap Dan, apply mind altering drugs and then release him with our new agenda for development for a total overhaul of complex surfacing plus synch tech for ST6.
We can discuss more at SEU…:-)
I was won over by the synchronous method and adopted and changed my way of thinking at ST1 and have been a huge fan of synch tech ever since. I have used ST to modify and reuse cad geometry from SW and Inventor for a few years now and now basically I don’t care who or how it was designed. All I care about is driving the geometry to where I want it to go to adjust and remake the part. I have done this successfully in a real world scenario now on numerous occasions. When someone wants something changed, all I say is “ok send me the file and I’ll do it quickly” rather than try and explain what I need. Works every time!
I feel that there is very little that ST cannot do and we are only approaching release 5.
I really like your analogy of programming as it compares to history based (ordered) vs. history free (Synchronous or non-ordered) modeling approaches. You say “Sometimes with programming, you can get a result that is wrong. Even if it doesn’t fail, it might still not be right.“ And the bells go off for me.
One of the bigger arguments I hear about going Synchronous (history free) is: “I don’t want to leave my model un-constrained, I want to force my design intent and I don’t want someone else to mess it up.” Funny thing in all of this is that I find a lot of the folks holding to this argument have un-constrained sketches that drive their models and features like cutouts and protrusions being made with a finite extent instead of a thru next or thru all; capturing true design intent. So… Some that argue this point of a wanting a “rigid feature tree” (History based model) really have, as you said, “…a result that is wrong. Even if it doesn’t fail, it might still not be right…”
We have been taught history based for so long, some of us grasped that idea and could build robust models, though not bullet proof, while other simply slap features together that can never be edited to maintain a design intent. As you continue to explore Synchronous Technology I hope that we all can learn and in some cases un-learn.
I close in rephrasing your topic: “Do You Really Need History?” to this “Your History is Failing… Get with the Times and Sync Up!”
Matt J
I look at this part and I see a one-off mechanical part that will be used in some machine to perform some function. After 10 years+ of history modeling I really don’t see the need for history in something like this. I do however want to be able to freely edit this during the design phase to ensure it will work with the design. And I want to be able to make these edits without a history tree constantly destroying.
This is a simple enough part to where this probably wouldn’t happen, but I’m pretty tired of troubleshooting feature trees that are 2/3 hundred features deep and blow up. Not even necessarily because the part was poorly constructed, but just by the fact that most of the times you can not anticipate the changes that need to be made. Consequently, they are not taken in consideration when constructing the part first.
If Sync tech proves to solve that problem, that would be very nice. And that’s understated. Very curious to find out where this goes next.
Matt,
This part is excellent for explaining some key concepts (probably not an accident on your part.) Is that where this is headed? Will you have another post with this as an example? Do you have this part handy in SolidWorks (or Solid Edge) format that you can send me (I could draw it myself, but getting the “dumb solid” might make the points even better).
Some key things that standout on this part that Synchronous will really help with:
1. Dimension anytime anywhere. Dimension between DESIGN elements as they emerge.
2. How the heck can you dimension to the “edges” of the block when they have, as you say, been consumed by the rounds.
3. Blind Alleys and design. Design is not linear. The blind alleys are legion. You must be able to navigate them.
4. The dimension between the holes drives the shape of the part, not vice-versa (from a design standpoint). But in history-based the solid material has to come before the holes (duh!) and therefore the holes can never truly drive in hb.
5. Reorder rounds. Without a history tree? What?
Great observation about the design intent being in the holes. From a history point of view, you can’t even work that way without using a layout sketch to cheat history.
So how do you take advantage of that in ST? You can’t drive the holes from a layout sketch, and you have to create the plate before you can create the holes. Ok, I see. Order really doesn’t matter except the “can’t cut what isn’t there” bit. So you can make the plate, then the holes, then make the holes drive the plate. Or I suppose you could have a nested sketch with the plate with the holes in it and just extrude that, so they are both made at the same time.
Different way of thinking. This will take a little adjustment. Although I think it will make more sense in the end.
Good luck with this new blog and Solid Edge
Devon