1. Home
  2. Solidworks CAD Design software
  3. Macro feature performance vs equation?

Macro feature performance vs equation?

Of those of you that have experience creating macro features how do you feel they compare to using equations? Do you think there is a performance gain or loss? We have some templates that use quite a few equations and I am considering converting them to macro features but I am afraid that there might be a performance hit. I like the idea of the macro because I can have one central place to go and update our calculations rather than having multiple templates that will need to be edited and using a macro gives greater flexability to the programmer, you can do more with the output from the macro than the output from an equation.

If I have multiple sw documents with this same macro feature embeded and these docs were in an a sub-assembly and that sub-assembly is in turn in a higher level assembly what would happen if I opened the higher level assembly and hit rebuild? Would the macro feature for every document contained within this top level assembly and every sub- assembly execute? Do the docs have to be fully resolved in order for the macro to execute? If everyone of these macro features executes on every rebuild I would be concerned about the performance of the assemblies.

Would a document that has 10 equations perform slower or faster than a document that has those same equations in a macro feature? For comparison I am thinking about time to open, fully resolve, rebuild, save then close.

Thanks to anyone who has a comment.

Sam

Reply to
Sam
Loading thread data ...

I'd say : if you can do it through equations, do it. It's the simplest way to do some (simple) processing at rebuild time. There are very few macro features around, because they're difficult to program, especially if you need some user interface. It's worth the effort only if you want some feature that behaves and looks like a SolidWorks feature, but doesn't exist in SolidWorks. I see no advantage in developing a macro feature to do something that already exists like equations.

performant as equations if you use compiled macro features. With VBA macro macro features, you have to consider the overhead of loading the VBA interpreter. Anyway, equations or equations-like-macro-feature should be extremely fast compared to the rebuild time needed once the new dimensions are calculated, and on which you have no influence... The macro features (or equations) in an assembly will be computed time for every part that needs a rebuild. This means that rebuilding a top assembly isn't enough to rebuild everything (you'd need a ForceRebuild3(false) call). Likewise, Lightweight components will not be rebuild unless there is a reason to rebuild them, just like any other component. In other words, only components that have "changed" in some way will be rebuilt. Just an advice : don't forget Excel. I don't know your problem precisely, but remember you can program macros in Excel to access SolidWorks, read and write dimensions, calculate them with formulas ... In my experience, many customers who thought they'd need complex configurators or specialized developments where extremely happy with a well designed Excel sheet...

Reply to
Philippe Guglielmetti

Philippe, thanks for your response. I dont think a macro feature is going to fit our needs but I do think a macro assigned to a hotkey or button may be what we need.

An example of what we are wanting to do is to use the weight of a single component of an assembly to determine the number of instances and physical location of some components that are contained within other sub-assemblies of that same assembly. For now we are using equations in those sub-assemblies, those equations are referencing some reference dimensions, the reference dimensions are being driven by something that has external relations (either a layout sketch or some planes) back to the major component (the one whose weight is important) so that in effect we have the equations in one assembly being driven by the geometry of another component. Then those equations drive the physical location of the components in that sub- assembly. So as you can see today we are not actually using the weight of the component, but we would rather use the weight than the physical dimensions.

Maybe this will make sense (this is what we are doing today, not necessarily what we want to do), assy A contains component B and sub- assy C. C contains multiple instances of component D and external references back to component B within context of assembly A. Sub- assembly C has equations driven by the external relations from component B, the output of those equations are used to position componet D within sub-assy C. The idea is that as the geometry of component B changes then component D will be re-positioned correctly. But there is only so much that can be done with the output from an equation, if the weight falls below a certain threshold we might want to suppress an instance of D and we cannot do that with an equation.

And I am starting to like the fact that using the macro gives the user the ability to decide when to reposition the components, the equations will run automatically and at times frustrate the users, say the geometry of component B changes only slightly not enough to warrent repositioning component D but the equations are automatic so they do their job and move component D just enough to affect the dimension on a drawing and so now that dimension changes from 2'-0" to 2'-1/16". We would prefer to just leave it at 2'-0" (we have loose tolerances for this particular case) and people are looking at the user and saying "Why do you keep making these changes???"

I think the macro is making sense, we may test the theory on the next project.

Sorry for the long post and if you have any additional comments I would appreciate your feedback.

Thanks, Sam

Reply to
Sam

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.