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.
Some ideas were posted over at www.nxjournaling.com 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 ??
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?
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 ) ) of our solutions.