Tick Talk on EsoxRepublic.com

Offsets and Conics

Posted in Geometry by Administrator on the June 26th, 2008

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

Learning COSMOS

Posted in Software by Administrator on the June 13th, 2008

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.

SW2009 to introduce disappointing version of equation-driven curves

Posted in Geometry, Software, Splines by Administrator on the June 5th, 2008

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.

2007 sp5.0 = big trouble

Posted in Software by Administrator on the June 2nd, 2008

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.