Tick Talk on EsoxRepublic.com

One of the challenges when writing API code is keeping track of objects and their methods and properties. Early binding can help with that.

“Early binding” simply refers to the way that object variables are defined. Instead of defining an object variable with “Dim swApp as Object”, define it as the specific object type, i.e. “Dim swApp as SldWorks.SldWorks”.

Here is what SW gives you when you record a macro:

Dim swApp As Object
Dim Part As Object
Dim SelMgr As Object
Dim boolstatus As Boolean
Dim longstatus As Long, longwarnings As Long
Dim Feature As Object

This is what the same code would look like adjusted for early binding:

Dim swApp As SldWorks.SldWorks
Dim Part As SldWorks.ModelDoc2
Dim SelMgr As SelectionMgr
Dim boolstatus As Boolean
Dim longstatus As Long, longwarnings As Long
Dim Feature As SldWorks.Feature

Ctrl+J and Intellisense

One of the handy features in the VBA editor (macro editor) is a list of available commands that pops up when typing, known as “intellisense”. Details can be found in the VBA help under “List Properties/Methods Command (Edit Menu)”. With intellisense, there is no need to commit an endless list of commands, objects, methods and properties to memory. It’s all right there.

Screen shot of intellisense Pop-up drop-down menu. Menu pops up after typing “.” after a valid object name or “ctrl+J”

Intellisense pops up immediately when one types a period following the name of an existing object. But, there’s a catch: if the object is defined with a Dim statement using “As Object” instead of as a specific type, it is not available.

Also, intellisense is available to add commands and objects by pressing ctrl+J.

The other advantage to early binding comes when a program is run. Early binding decreases the time it takes to set an object. Not a big deal for small macros, but it could add up for larger program.

When I was in the navy, one was considered out-of-uniform if one did not have a pen and notepad on his person. On my workstation, I have a few tools to use for “jotting things down” when simple copy-and-paste is not quite enough.

Quick access shortcuts

I like to use MS Notepad as an on-screen scratchpad. I find it is handy for storing quick notes and lists of numbers that I may need elsewhere during the course of my CAD modelling. To make Notepad readily available, I add a shortcut key to the Windows menu. That way, I can have my scratchpad ready with a quick “Ctrl + Alt +N”.

To add a shortcut key, go to the Windows menu and find the application of interest (i.e. MS Notepad). Instead of left-clicking to start, right-click and select “Properties”. You will see a line for the shortcut key. Here, you can enter a “Ctrl + Alt + {letter}” or “Ctrl + Shift + {letter}” for a shortcut key. Once set, the application will start when the shortcut key combination is pressed.

Quick shortcuts for screenshots

I have a key shortcut for MS Paint, which I use for editing screenshots. Use “Shift + Printscreen” to capture the screen, open MS Paint, and paste (Ctrl + v). MS Paint will allow you to select a portion of the screenshot to crop or copy. The copied protion can be pasted into email, PowerPoint, MS Word, etc.

Other handy tools

Two other tools I like to keep on “hot standby” are the Windows Calculator and the Character Map. Character Map is handy for those odd symbols, Greek letters, etc. Calculator is good for, well, calculating. BTW, if you haven’t discovered it yet, Calculator does have a scientific mode w/ trig & log functions, etc.

Offset entities in a sketch is a very handy sketch tool. It comes in handy in so many ways: shelling parts, creating slots, scaling geometry, making sheet-like profiles. Not much more need be said.

Offsetting sketch entities creates a set of entities that are a constant distance from the original selected entities. For the simplest geometry, arcs and lines, the resulting entities are the same type: an offset of a line is a parallel line, an offset of an arc is a concentric arc. Splines, well, are still splines, no surprise there.

Offsets of conics are not conics

The surprise for some is the result of offsetting conics, eliipses and parbolae. The obvious assumption from experience is that the offset of an ellipse is an ellipse, and the offset of a parabola is a parabola. This assumption would be a mistake.

The offset of an ellipse is not an ellipse. The result looks like an ellipse, and is certainly oval-shaped, but is not a true ellipse.

Pictured below is the result of a quick experiment. Sketch A (green) is an ellipse. Sketch B (black) is an offset of the ellipse. Sketch C (red) is an ellipse with the same major and minor diameters as the offset. They do not match.

Offset of ellipse vs. ellipse of same major & minor diameter. Green = original 1 x 3 ellipse; black = 0.25 offset; red = ellipse w/ same major/minor diameters as offset. Click image for larger version.

Try the same experiment with a parabola and see what happens.

The Implications

I first started this article simply as a brief academic discussions of the results of offsets. While googling arond to see what else is out there, I found this subject does have some relevance beyond curiosity, especially for toolpaths in CNC programming.

For CNC programmers the important fact is that the toolpath to create a 2D ellipse is not a true ellipse. Creating a toolpath by scaling an ellipse or by creating a second ellipse with major/minor diameters increased by half a tool diameter will yield erroneous results. An offset must be used, and the offset is not an ellipse.

This past couple weeks I have been learning COSMOSMotion and COSMOSWorks. My current contract assignment had these sitting in a drawer for years waiting for someone to use. Now I have.

This job is at a place that designs and manufactures hospital beds. Lots of cool 4-bar gadgets. Definitely a great environment for C-Motion. Initial results are promising and management is enthused.

Now starting on COSMOSWorks, hammering through tutorials. I’ve done FEA on MSC NASTRAN before, so it’s mostly learning button-pushes and discovering functionality. I am definitely impressed by ease-of-use. Makes for a good product.

Against my grain

Those who know me well know that I like to get inside of things. I like to know why things work, and then why the things that make things work work. That’s why I like SW API; that’s what I liked about NASTRAN. I like having access to the inner workings.

I wouldn’t call me a control freak. I do like having control of some things, tough. I am suspicious of defaults, and I am usually certain there are better ways toward better results. With NASTRAN, I liked the meshing functions that allowed me to define mesh shapes in critical areas. Also better element choices: P-elements and quad meshes. Lots off good stuff.

I like the results I am getting from COSMOS, but I am out-of-place without a window to peer deep inside.

“Classic” Vince Adams

I met Vince Adams in 1996, when I just completed MSC NASTRAN training. Vince joined our end-of-training golf outing. He was starting a new company, and with it, a new venture.

The venture was the “MESH” conferences. MESH was a regional (WI-IL area) “ecumenical” conference of FEA users. It had nothing to do with a particular software. It focused on broader FEA issues: problem solving, testing, material properties, etc. Software comes and goes and always changes, but the fundamentals behind successful FEA are the same for everyone.

I was privileged to attend a couple of MESH conferences. Circumstances forced a sad end to them (2002-ish?). Vince and MESH had a profound effect on my approach to FEA and also engineering in general.

It would be wonderful if SW could let “classic” Vince out among us again.

Solidworks briefly published then pulled a PDF showing what was new in SWX 2009. Among the items listed was equation-driven curves.

This is a feature that is long overdue. SW’s current connect-the-dots-with-a-rusty-crayon curve-thru-points is not an acceptable substitute. I was excited to see they had finally introduced an equation-driven curve feature. That is, until I read the descriptioin…

According to that “what’s new” document, the equation-driven curve feature only allows a user to create 2D curves with functions y=f(x). An improvement, but hardly close to where they need to go. Only works in two dimensions. Does not allow for higher degrees of “x”, as one would find in conics or common forms like wave washers or gear teeth.

SW needs to introduce parameterized curves: x=f(i), y=g(i), z=h(i) for i=0 to 1, like the rest of the grownups in math-land.

List of things y=f(x) curves can’t do:

• involutes (gear teeth)
• cardioids
• spirals around a path
• wave-washer outlines

Disappointing. Keep trying, SW. In another five years, you could catch up to where Pro/E was ten years ago.

Yes, still on SW 2007 at client site. Installed SW 2007 on new computer and updated to SP 5.0. Opened a top-level assembly with lots of width and symmetry mates. Most of them failed.

Uninstall. Update to only SP 4.0. All better.

As promised, more [yawn] detail about spline curvature, involutes, and Geartrax. Part 1 of this subject is here.

As I wrote before, there are some errors in the involute spline generated by Geartrax. While the spline passes through all of the defining points, it meanders between these points, introducing minute error as it goes. This is due to the fact that the spline is only defined by its points, with no attention paid to tangency or curvature at any point.

Screen shot of spur gear sample from Geartrax’ web site.	Curvature comb of Geartrax tooth profile. (Click image to view full size)

Curvature of an involute

The curvature profile of an involute with respect to its length is asymptotic. It is infinite (zero radius) at the root and approaches (but never reaches) zero as the length increases. The formula is c=1/sqrt(s), where c is curvature and s is length from the root. For details, see 2dcurves.com.

The problem with the Geartrax “involute” is that it does not follow this curvature profile. The curvature is zero at each end. Also, there are inflecctions in the curvature comb. The curvature should always get smaller as the length from the root increases. The Geartrax spline has regions where the curvature increases with distance. the image below shows the Geartrax spline with curvature comb along with a curve showing what the idealized curvature comb should look like.

Curvature comb of Geartrax tooth profile (purple) vs. ideal (red line) A: Ideal curvature is infinite at root, Geartrax spline curvature abruptly reverts to zero B: Geartrax spline curvature has region where curvature increases as distance from root increases C: Geartrax spline curvature is zero at endpoint. Ideal curvature approaches but never reaches zero (Click image to view full size)

Is this a problem?

Probably not. It depends on how much detail you need in your involutes. If you are cutting gear teeth right from CAD data, you are copying the errors. If you are cutting gear teeth with hobs, the error would not be carried through. For most common uses, performance will not be noticeably affected in either case.

I did have one application where this could have been an issue. I was tasked to model a very large gear for a very large press. The gear was to be wire EDM cut right from CAD geometry. The gear was large enough that CAD geometry errors could possibly be detected. Being a former submariner, I appreciate large, quiet, smooth gears.

Still, I am disappointed. Involutes are nothing new, and the mathematics behind them are clear and well-established. Geartrax’ results are a bit ham-fisted when placed next to an ideal involute’s simple elegance.

What you can learn

The big lesson is that there is more to drawing splines than connecting the dots. Many spline control problems are only made worse by adding more points. Controlling tangency and curvature at key points will go a long way toward creating a spline that suits your needs.

Try to live a life that shows you aspire to be worthy of the blood that was shed for you.

Plenty of buzz about Siemens/UGS new synchronous technology. All I can say for the moment is that it will be interesting to watch.

I love UG. It’s where I cut my 3D teeth. Later, I was baptized in fire at Apple, modelling transluscent blue shells for demanding and temperamental industrial designers. For that, UG was the right tool for the job. I also learned Pro/E there, and was a dual-user for a while. Pro/E lets you play doctor, UG lets you play god.

At that time, UG already had a lot of great tools for dealing with unfeatured data. We could (and often did) abandon the feature tree and model exclusively with these tools. UG could also already assimilate “unfeatured” data into its feature tree. For instance, raw “curves in space” could be swept or extruded, then those curves could be brought into a sketch and constrained/parameterized accordingly. Neat stuff.

I could go on. I’ve carved a nice career from SW, but UG still has a siren song.

What it is; how it works

For those who haven’t seen, here are a couple links explaining UG/NX6’s new “synchronous technology”. The video is an attention getter. The PDF white paper provides a more detailed explanation.
Propaganda video
White paper

The video does a great job of showing how synchronous technology should work. Looks slick. I would hope so. That’s what video editor folks are supposed to do. The white paper provides a reasonable explanation of what is happening. Very intriguing. Apparently, the synchronous technology evaluates the model to determine what feature edits it must do in order to change geometry in a certain way. Neat!

We can see how it works. What will prove more interesting is how it doesn’t work. Models and model trees come in all degrees of complexity. Some are complex by necessity. Some are complex due to poor training or bad hiring decisions. In either case, I’m sure it won’t take long before folks are finding the limits of this budding technology.

What kind of model tree goes from this…	…to this???

Here is a good specimen of a bad example. This is an .avi of a really extreme example of poor model tree management. Pure hack-slashery. The video is a series of screen shots as the part feature tree is rolled back and then forward. I would love to see how UG/NX6 handles something like this.

I would also like to see how UG/NX6 handles well-constructed surface modelling. I can’t imagine that synchronous techology has evolved to a point where it could handle a fully-featured model of something complex like an iMac shell or an auto interior console. I do hope it can, but I doubt it.

Your jobs are safe

The CAD users of today are not going to be instantaneously supplanted by an invading army of synchronous-using replacements I also don’t foresee a great improvement in the CAD-user populace. The aces will still be aces. The putzes will still be putzes. There will be a market shift, but there will be no mass-divestment in current parametric modelling technology.

Originally posted on the SW website API forum, forums.solidworks.com
Compare file internal ID’s

There is no way in SW API to get a document’s internal ID (”IID”). SW doesn’t make that data publicly available, apparently because it would be too convenient for programmers who need that information. Still, there is a way to divine some useful information about a file’s internal ID.

SW recognizes two files as having the same IID if
1.) they were created at the exact same second
2.) they were created by the same installation of SW

Very difficult to ascertain #2, but #1 comes easy.

To answer the question, “Do these two files have the same internal ID?”, one need only check the creation date. But, not just any creation date. There are many ways to check creation date, and most will not work for this purpose. The creation date of interest is the one generated the instant a user clicked the final “OK” when creating a new file in SW. What’s the right way? Use DSOfile.dll. The property “SummaryProperties.DateCreated” records the moment SW brought this file into being. It does not change when a SW file is moved, renamed, or copied. It is the “mitochondrial DNA” date stamp, passed down intact through generations of saves, moves, and copies.

What’s the wrong way? Nearly any other creation date property or method. SW’s custom property “SW-Created Date” can change due to a Save As operation. Windows API methods creation dates can change depending on how and where a file is moved or copied.

How reliable is the DSOfile create date for determining if two files share an IID? The inverse of the probability that two files of interest were created by two separate people at the exact same second. Good enough.