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

 

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...

 

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