You are welcome Paul and thanks for seeing the value of it. I’m glad that you could implement a new, out of the frame strategies where most of others want to just stick only to their traditional methods.
What about using the tired and true simple expression function that pushes all the top level expressions down into all the piece parts? I know in the Excel version it was Root Part Cascade function. Later it was added to the expression editor. Will this functionality be going away? If so it is a sad day for NX! This provided the user to create a strategy and drive everything without having to wave link or build interpart expressions.
Since I’m only couple of years with NX, I wouldn’t know about this Root Part Cascade.
When I started NX, I saw a huge lack of underused/under developed File properties/Attributes and its property attribute editor. I was complaining (may be it was too much irritation for some guys) in the forums and somehow now we see some new developments in bulk editing capabilities. (I’m not sure if most of the users are aware of Bulk editing in NX)
Because of unavailability of a bulk editor, we started pulling assembly attributes through expressions (e.g., Job #, Customer, Dates etc..) in to the parts and I was in search of something like your Root Part Cascade to control them. I asked in forums and got no answer. So I think Root Part Cascade isn’t used anymore.
Now we are dumping the expression method and starting to use the Bulk Editors in NX and also with PDW, where you could control the file attributes from a central location. Now the issue is that we got some unused Expressions in cloned jobs and I need to find a method to bulk clean those dead expressions to avoid that annoying warning popup in the file opening.
PS: I see some silence in this thread, including about my posting in KB. Is it too simple or too complicated to understand?
So, I've ben thinking about this one a bit, and in the end, other than the Assembly Constraint Override, I don't know of a way to allow one subassembly to take on more than one set of assembly positions in multiple instances within an assembly.
And as I think you've accurately described, the Assembly Constraint Override doesn't yet know about underlying limits for constrained motion.
So I think you might have a great Enhancement Request on your hands. :-)
You could certainly add some component-to-component measurements and Requirement Checks (with HD3D tags) at the assembly level to warn you if any of these cylinder rods ended up in invalid positions. But I don't know of a way to enforce/disallow dragging outside these limits today.
Sorry I don't have a better answer for you. :-/
I'll confess that in twenty years with the company (including eight years as an application engineer) I have no recollection of having ever used the Root Part Cascade option. I had to look that one up, for better or for worse.
I see it now, lurking there in the Modeling Spreadsheet options, but having owned the Expressions dialog for over a decade now, I don't ever remember it being part of that world. Can you steer me toward any documentation of the usage you described outside the Modeling Spreadsheet?
For the record, the Modeling Spreadsheet (with all of its NX-specific automation) is still there, and still continues to function as designed, though I personally never steer new users that direction. The fundamental challenge with the Modeling Spreadsheet is the fact that the normal NX Update doesn't know it's there. If your workflow involves always changing your models from the context of the Modeling Spreadsheet, then you can be sure that you're taking advantage of whatever calculations are happening there. But if you're a new user or a casual user or even an experienced user and don't realize that a portion of the design intent is buried inside the Modeling Spreadsheet, then you may be inclined to start editing features and expressions directly and fail to take advantage of the embedded spreadsheet "smarts."
With the more modern spreadsheet interactions through expressions functions, calculations that take place in spreadsheets can be associatively connected to the model, and expressions drawn from spreadsheets can be automatically updated by the normal NX Update without manually going to the spreadsheet to initiate the update every time -- whether that update is happening as the result of a local feature or expression edit, or a feature or expression change on the other end of the assembly, via an interpart expression, for instance. In a nutshell, there are much more associative, much more robust workflows these days that I would recommend before suggesting the Modeling Spreadsheet.
Plus, with the new table interaction in the Expressions dialog for NX 11 (we all missed you at PLM World, where I showed this) you're most of the way toward working directly in a spreadsheet anyway.
I agree that most users don't know about the modeling spreadsheet and that can be due to not simply knowing you have the functionality in NX at all! I don't even know if it is even taught anymore. But this tool can be a very powerful tool with some great benefits. Here's the benefits I see:
1. Doesn't create ANY external references to any other components!
2. Allows for CTO/ETO processes
3. Doesn't create ANY external references to any other components
4. Allows for quick design changes for large assemblies (1,000s of unique part files)
5. Doesn't create ANY external references to any other components
I think you get my main point. This is important when doing any CTO/ETO workflows. You have the ability to make changes to the piece parts without having to worry about something else changing without your knowledge.
Is this for everyone. No.
We used this process with modeling spreadsheet as a Master Assembly. You clone the master assy, open up the new "top level" assembly, make you changes to the key design parameters and then force the new/updated expressions down into the entire assembly. When this is happening your piece parts are updated one at a time and when all done you have a new configuration that is more than 80% complete in 10-15 minutes. It was beautiful and simple. You just have to setup/program you piece parts to use the key design parameters for size and shape. Mating conditions took care of positioning while the changes are being made.
When we were using the modeling spreadsheet, back in the late 90's I recall, this was the only location that provided spreadsheet calculations and allowed us to insert images. What we did was take a snapshots of the overall product design, insert them into the spreadsheet and use that sheet as "design form template". On a secondary sheet (Expressions) we extracted the expressions from modeling, defined some more manually, and defined a range of expressions that were the design driving expressions. We would link the cells from "form sheet" into the expressions cells and then run some max/min checks. Finally, we told NX to use the root part cascade to push the defined range of expressions down into each part under the top assembly. Bam, you have instant configure-to-order (CTO) or engineer-to-order (ETO) functionality.
I actually did do a presentation at PLM World on this awhile back...ok more than awhile back! Maybe 10-12 years ago.
The key to using this is that you basically have to have the child components parameters using the top level range expressions in the feature calculations. So if you have Overall_length expression in the top level and it is copied into (and overwrites any existing Overall_length) value in the child component the parameters that use that value are updated automatically. This was great for design simplification because it simply removes all interpart relationships, no need to WAVE link geometry and all the parts have no "external references" to any other part. This made life easy for anyone using working on the parts and you didn't have to worry about a change in one part effecting any other parts.
If you are familiar with Rulestream or DriveWorks, its exactly the same process.
At the Donaldson Company, where Alan (another great NX users) and I built this process into several product lines for the large gas turbine division- driving inlet air transitions, silencer sections, elbow duct and straight duct sections. These were large assemblies constructed of weldments sections. Here we drove the product with simple inlet design parameters of the inlet width, height, depth, and inlet centerlines. It was beautiful and simple. These assemblies could easy have 1,000 of unique part numbers and could reach the 10s of thousands of components- we had to have fully defined 3D models which included all attaching hardware, silencer pillow assemblies for each little nook and cranny for clearance and weight analysis, defining CGs for lifting, etc. Oh, the good old days!
Now, NX did come along with some other tools that helped with some of the process I described above but when you have no external references to other parts it sure makes design life easy. Now, for the record, I will say that we did use some geometry linking on some of the product lines. For the transitions we used a catenary curve to move air from the filter inlet area down to the intake ducting design. Each side (top, bottom, sides) had their own law curve that drove the catenary design built into those weldments.
we controled the strokes max/min values inside the assy (where the overides are located) using if/then statements.
Then the overide mating expression is equal to some if/then statements. I don't have the exact wording here but something like:
Overide=if(Stroke=<Min_stroke),Min_stroke else if(Stroke=>Max_Stroke),Max_Stroke else Stroke
You can get poor man mechanism here if you then use the slider bar to adjust the Stroke expression! Once again I did this more than 6 years ago! It's been a few years since I've used NX.
I have an issue with my Expressions.
I created a standard mould base that I could use for each new job. I made the main assembly file and put in all my expressions and then for each component I used those expressions so when I change the size of the mould base for example it will update all the plates.
My issue is for each job I will rename the main assembly and components according to job number so they don't get mixed up with a previous job by some freakish chance. When doing this the components can no longer take the expressions from the main assembly. Below is what I did to fix the issue but I keep coming up with an error when opening the files
I went into each component and right clicked on the expression and clicked "Edit single interpart expression", then a window opens and shows all the components in the assembly. I click on the assembly file and pick the proper expression. This updates the expression but I have to do this for each one. When I reopen the assembly I get a window pop up called "Update event list". Please see image below for the error message. Why is it still showing its trying to get the expression from the previous named file, when I went through and updated all the expressions?
Also is there a quicker way to update all the expressions when I change the main assembly file name?
"My issue is for each job I will rename the main assembly and components according to job number so they don't get mixed up with a previous job by some freakish chance."
What is your procedure for renaming the files? If you copy a folder full of files with windows explorer and start renaming them at the OS level, the links in the files will not be properly updated. With the assembly fully loaded in NX, you should perform a "save-as" or "clone" on the assembly and the components. This will give you a new copy of the assembly and components with the links properly updated.