Drawing dimensions moving around.

This is happening because the view is changing size. As a guess, there is something about the now-suppressed model that caused the view to be larger. Once that becomes suppressed, the view changes size and appears to change location.

The simplest solution is to add snap lines for these diameter dimensions. A snap line us usually based off the view outline, but you can instead create them based off object lines in a view.

The more comples solution is to figure out why the mechanism sub-assembly is larger than the main sub-assembly. It could be a datum plane or axis, point, csys, or some other factor. Just apply due diligence.

In Reply to Dave Rosenbaum:

I am showing model assembly and part dimensions in a large assembly.

The parent assembly contains duplicate subassemblies, the first of which has placement constraints, the 2nd of which (the duplicate)contains mechanism constraints.

After the dimension values are passed down from the parent assembly to the subassemblies (via Pro/Program),the parent assembly is saved (thus saving the dimension values in the subassemblies), and then the mechanism assembly versions are suppressed (and eventually deleted from the parent assembly) This is because the mechanism assemblieswere only included in the parent assembly for the purpose of passing down their dimension values from the parent assembly, via Pro/Program.

The processworks well (we have used it for years), but I have just started to show model dimensions in the parent-assembly drawing, and I am now finding that diameter model dimensionsmove from the location they had before the mechanism subassemblies were suppressed, because the location of the view moves horizontally relative to the drawing format, once the mechanism subassemblies get suppressed.

This only happens with diameter dimensions, not linear dimensions (apparently the 2 witness lines of the linear dimensions keeps their relative position fixed to the model geometry).

Does anyone know of a way to fix the horizontal-direction location of model diameter dimensions (relative to their model geometry references), or else some way to keep the horizontal-direction location of the view from shifting in the horizontal direction, once the mechansim subassemblies get suppressed?

Thanks for your reply. You are correct. The suppressed mechanism subassemblies are definitely longer than the unsuppressed stationary subassemblies, because they contain rear kickout rods that are pushed by the kickout mechanism of the forging machine, and are used in the mechanism simulation of the forging cycle. These rear kickout rods are not shown in the stationary (non-mechanism) subassemblies, which are used for the assembly drawings. The rear kickout rods must be included in the mechanism version of the subassemblies, because their positions (and on the punchside, their lengths)are a function of the design of the forging subassemblies. So there is really nothing to be done about this.

I thought about using snap lines offset from object lines, to fix the positions of the diameter dimensions, but the problem with this approach is that many of the subassembly components are present or absent (i.e. suppressed, by Pro/Program), based upon the designconfiguration chosen by the designer. When these components become suppressed, I believe that Pro/Engineer will complain that the snap lines have lost their references. In such a case, I would wish that Pro/Engineer would simply suppress the snap lines as well, but I don't know that it will. I know that I have been getting some complaints from Pro/E already regarding draft lines attached to object lines which have lost their references, when the objects in question have been suppressed in the configuration.

But I will try experimenting with snap lines attached to object lines to anchor the moving diameter dimensions, to see if this will work.

Again, thanks for your brainstorming help.

I see your dilema. I just thought of a third solution.

Change each view where this happens from a full view into a partial view. When sketching the spline to outline your view, simply enclose the entire view that you wish to show. Any of these kickout rods that fall outside the view are simply clipped off at the boundary created by the spline. When the kickout rods are later suppressed, the view will remain exactly where you placed it. This should keep the diameter dimensions in the location you placed them while the mechanism sub-assy was present.

Due to suppressing snap line references, this may be a better solution to attempt first.

In Reply to Dave Rosenbaum:

Thanks for your reply. You are correct. The suppressed mechanism subassemblies are definitely longer than the unsuppressed stationary subassemblies, because they contain rear kickout rods that are pushed by the kickout mechanism of the forging machine, and are used in the mechanism simulation of the forging cycle. These rear kickout rods are not shown in the stationary (non-mechanism) subassemblies, which are used for the assembly drawings. The rear kickout rods must be included in the mechanism version of the subassemblies, because their positions (and on the punchside, their lengths)are a function of the design of the forging subassemblies. So there is really nothing to be done about this.

I thought about using snap lines offset from object lines, to fix the positions of the diameter dimensions, but the problem with this approach is that many of the subassembly components are present or absent (i.e. suppressed, by Pro/Program), based upon the designconfiguration chosen by the designer. When these components become suppressed, I believe that Pro/Engineer will complain that the snap lines have lost their references. In such a case, I would wish that Pro/Engineer would simply suppress the snap lines as well, but I don't know that it will. I know that I have been getting some complaints from Pro/E already regarding draft lines attached to object lines which have lost their references, when the objects in question have been suppressed in the configuration.

But I will try experimenting with snap lines attached to object lines to anchor the moving diameter dimensions, to see if this will work.

Again, thanks for your brainstorming help.

I want to thank everyone for their kind brainstorming replies.

The problem was solved, but I would have preferred a solution which was less laborious for me. Nevertheless, I have a solution, and I will now summarize it for everyone interested.

The3 suggestions offered were:

1. Set the View Origin to a model reference, so that it will not default to the center of the view outline, which was changing because the view outline was changing.
   
   Implementation:
   I reset the View Origin to reference the parent assembly default coordinate system. This worked well, I really liked it, the View remained in the middle of the Format borders when I suppressed and unsuppressed the mechanism subassemblies. However, I found that Pro/E would still shift the diameter dimensions around in the drawing, when the mechanism subassemblies were suppressed and unsuppressed. So I am retaining this setting, because I like it, but it did not solve the problem of shifting diameter dimensions.


2. Create snap lines offset from part edges.
   
   The question that arose with this approach was that Pro/E might complain about lost references, when the partsfrom which the snap lines were offset were suppressed in the user-specified configuration.
   
   Implementation:
   This approach worked.
   
   Pro/E did, in fact, complain when the partsfrom which the snap lines were offset were suppressed in the user-specified configuration, but it was only a warning message, rather than the interruption message that appears when the reference for a draft line gets suppressed. I can live with the warning message for the suppressed snap line reference, because it does not require a user response, unlike the interruption message for the suppressed draft line reference. The warning message that Pro/E issues for the suppressed snap line reference is:
   
   Highlighted snap line(s) cannot be regenerated.
   
   This is not great, because I end up with snap lines on top of each other, since the alternate parts have many edge lines in common. Therefore, I end up with red (higlighted), inactive snap lines on top of unhighlighted, active snap lines, and it is almost impossible to tell them apart. But the alternate diameter dimensions controlled by the alternate snap lines nevertheless stay put, which is the main thing. I am going to see if I can put the alternate sets of snap lines onalternate layers, to control their visibility.
   
   One other complication which occurred with the snap line approach, is that I would unwittingly attach the snap line to the part outline in the mechanism subassembly (since the two sets of parts are coincident), and then the snap line reference would disappear as soon as I suppressed the mechanism subassembly. So I learned to suppress the mechanism subassemblies before attaching the snap lines. Also, I am using Pick from List, to pick the reference from the part edge, rather than the drawing Xsection edge, because I don't know if the Xsection reference will be maintained when the part edge, from which it derives, gets suppressed and unsuppressed.
   
   Another disadvantage of the snap line approach is that one does not know how far the location that one wants to use is distanced from the part edge that one wants to use. The distance measurement tool will apparently not accept a mouse pick. So I have to temporarily create draft lines at the location that I want to use, in order to measure their distances from the part edge, with dimensions, and thenenter these dimension values as the snap line offset values. Also, the snap lines tend to offset in the wrong direction, and then I have to edit their properties in order to change the offset value to either + or -. The same part edge requires a - (minus) offset valuefor one part, and then requires a + (positive) offset value for its sister, alternate part.
   
   Like I said, it is a very laborious solution.


3. The 3rd suggestion was to change my view to a partial view to keep it centered.
   
   Implementation:
   Since this suggestion accomplishes the same thing as item 1, which has already been shown not to keep the diameter dimensions from moving, I did not experiment with this approach.
   
   I think that this matter is a candidate for an enhancement request. It would be nice to be able to right-click on a dimension and fix its location relative to a model reference, so that one does not have to physically create a snap line (with its subsequent higlighting-error problems), for this purpose.
   
   But I will soldier on.
   
   Thanks for all the help!

I have just received another suggestion from Karl Krahmer. This is to create one's own bounding box sketches, in the XY Plane and XZ Plane, which encompass the largest extremities of the components for the various subassembly variations (suppressed and unsuppressed, etc.). According to Karl, it is the unstable bounding box, which is causing Pro/E to whip the dimensions around in the assembly drawing.

Since my case was only varying in the X-direction limits, because of the presence of rear kickout rod parts in the mechanism subassemblies, which do not appear in the stationary assemblies, I only created a bounding box sketch in the XY Plane.

This approach seems to have worked. I experimented with 2 dimensions on a particular die part. I first moved these 2 dimensions to their correct locations in the assembly drawing. These 2 dimensions were ones that had moved very far away from their original locations, so I knew that they were subject to movement. I then experimented with suppressing and unsuppressing the mechanism subassemblies (which contain the outlying kickout rods), and also with suppressing and unsuppressing this particular die part (the die part was suppressed and unsuppressed via a Pro/Program input parameter).

The 2 subject dimensions did not move throughout the various experiments.

So it now seems that this is a far superior solution, because it does not require multiple, superfluous snap lines.

I'll let you know if any further problems arise with this approach, but for the time being, it seems to be the ultimate solution.