Showing results for 
Search instead for 
Do you mean 

PLM World NX Programming Special Interest Group

For those of you who are not aware. The PLM World organiztion had been supporting a special interest group focused on NX automation programming. I was briefly recently the chairman of the group. There has been a lot of reorganization going on with respect to the focus and special interest groups. The PLM World organization is eliminating the SIGs and replacing them with what they are calling Working Groups. I am interested in continuing the Programming group in the new form. The main difference between the old SIGs and the new Working Groups is that PLM World wants the purpose of each group to be more focused and potentially temporary to solve a fairly specific goal in a given timeframe. Groups may disband after the problem is solved (or if no progress is made) or just refocus on a new topic. What I am looking for is some topics that people would be interested in focusing on. Here is a topic that was suggested by the Working Group committee
1. Compile a formal document describing the various NX automation tools. Including.
a. What automation tools are available
b. What are the pros and cons of each tool
c. Which tool is the best to use for what condition.
Anyone have other suggestions?



P.S. If you are interested in joining the group, let me know.

Ric Hotchkiss
Applications Consultant

O: 860-749-3832x214
F: 860-749-3842
C: 860-463-8486
Design Automation Associates Inc
68 Bridge Street, Suffield CT 06078

Engineering Software & Engineering Services:
Design Automation, Training & Mentoring
NX, Knowledge Fusion, NX/Open, Checkmate
Mechanical Design, Structural & Thermal Analysis

Re: PLM World NX Programming Special Interest Group

Some ideas were posted over at that look interesting to me:


(1) The Economics of Programming: What are the economics of programming? How do you justify doing it, from a business point of view? How do you respond to management folks who say things like "our business is building cars/planes/widgets, not writing code". How do you estimate ROI? How do you justify expenditures on tools or training?


(2) Programming for the Rest of Us: How do you get the average designer/engineer interested in programming? How do you explain the benefits? How do you convince him/her that it's not all that difficult? What are some effective methods of evangelism and training?


(3) Code As Knowledge: What is the role of programming in capturing process knowledge? A Design Handbook can explain how you should do some engineering task. But a program is even better -- it can lead you through the process, and even do some of the tasks for you. Is writing the program code any harder than writing the Design Handbook? Is it any more difficult to maintain as time goes by? Back to ROI; topic #1.


(4) Non-Vanilla Tools: Current NX tools are (for the most part) based on plain vanilla programming technology -- C/C++, .NET, Java, Python, etc. But the most successful tool was probably GRIP, and this wasn't vanilla technology, it was a special proprietray language. So, would something other than a general-purpose programming language be better, maybe? How about driving NX from Mathematica, or Maple, or Matlab, or Excel, or whatever? How about a DSL (Domain-Specific Language)?


(5) Programming Across Products: How can we write code that works with NX and Teamcenter and maybe even other (Siemens) products, too? Seems like we have to learn several different tool-sets. Maybe we need a general programming SIG, not an NX Programming SIG. Is there a TC programming SIG ??


Re: PLM World NX Programming Special Interest Group

[ Edited ]

I would also be interested in getting involved with a working group focused on programming. What would be the format and how could we go about collaborating and sharing knowledge with one another?

Re: PLM World NX Programming Special Interest Group



Something that we have discussed with Siemens before (but never really got anywhere) is a way of getting NX customisation 'signed off' by Siemens themselves.

We use a LOT of customisation and automation onsite here. 

One of the biggest hedaches we have is if we have an issue with NX that we have to contact support about.  NX crashing out etc.

As soon as they see NXOpen code they invariably blame the crash on custom code.

Until we can repeat the issue with no cutom code used in a session we find it difficult to get anywhere.

Our thought was that if there was some kind of sign off or certification for our custom code this would help massively when dealing with these types of support issues.

It might even help us to develop better code in the long run as we'd be getting feedback on the neatness (or lack of Smiley Surprised) ) of our solutions.