As I’ve covered in previous posts covering the basics of Teamcenter’s Conditions and discussing how to use Conditions in your ITK, I’ve been playing around with Conditions in Teamcenter lately and have generally found them to be useful and promising. But not everything has been wine and roses. There are some warts, some deficiencies, and some straight up errors with how they work. I feel that I would be remiss if I did not spend some time discussing the problems and pitfalls I’ve found.
If you’re using Teamcenter to store your CAD models and drawings (and most Teamcenter customers are, I believe) then one of the first issues to tackle is, how do you store those drawings? There are a few different ways I’ve seen: embedded in the CAD model dataset itself, stored as an additional dataset under the same item revision as the CAD model, and stored as a separate item from the model item. Today I’ll run through some of the issues related to each of these approaches.
The normal way of testing for and handling errors when calling the Teamcenter ITK or UG/NX Open C APIs is to
#define a macro to wrap your API calls in. Macros are a problematic and flawed solution however. If you’re compiling your code as C++ you can use a much safer inline function and use exception handling to provide a much more flexible and robust error handling mechanism.
Note: We’re covering some basic programming today. I’m interested to hear if this is too basic or not.
Previously, I’ve addressed the basic question,
I’ve been reading up lately on the differences between Product Data Management (PDM) of CAD data and Product Lifecycle Management (PLM) of part data. I must confess that I used to think of the difference between them as one of degree and not of kind — that PLM was basically PDM on steroids. But more and more I’m coming to the conclusion that I was simplistic in my understanding. The truth is that they are different tasks altogether. Because of this misunderstanding I came up with some very inelegant solutions to some of the data management issues I encountered. I have been looking for better solutions. As it happens, it seems that Teamcenter now provides us with a means for making this distinction between PDM and PLM by maintaining two independent structures, a CAD BOM of Design items and a Part BOM of Part items, and then aligning the two. Although I have some concerns with the process, I think it has potential and should be explored.
It’s late in the day and you’re running on fumes. You decide to run your code through one last unittest before calling it quits for the day.
And then it happens. Ba-boom! It all blows up. Unhandled exception. Error code 74708. No error message recorded. Where do you start looking for the cause?
One thing that can help is to be able to find out what that particular error code means, so knowing a bit about how they’re defined, and where, can be helpful.
Lately I’ve been working with Teamcenter 8.3 and one of the new features that has caught my attention is Conditions. Well, they’re new to me, anyhow. Conditions come to Teamcenter via the Teamcenter Enterprise bloodline so since my background is Teamcenter Engineering they’re new. If you’ve spent any time at all working with Teamcenter’s BMIDE application you’ve undoubtedly bumped up against Teamcenter conditions already, especially the ubiquitous
isTrue. But, what the heck do they do?