Relation not scaling dimensions correctly

[treddie]

Hello.

I made a relation to scale a sketch independently in x and y. The relation is:

Hscale=1
Vscale=1.5

sd1=sd1*Hscale
sd0=sd0*Vscale

sd3=sd3*Hscale
sd4=sd4*Vscale

sd7=sd7*Hscale
sd8=sd8*Vscale

sd10=sd10*Hscale
sd11=sd11*Vscale

sd13=sd13*Hscale
sd14=sd14*Vscale

The problem is that the results after regen are clearly wrong (please see attached screen captures). What is weird is that it's as if ProE is regenerating multiple times, and sometimes for different amounts of times for each dimension, OR not even landing on an integer multiple of the scale values.

Is this a ProE W4 bug, or am I brain-farting here?

 

[PeterStock]

The relations you have will change the numbers each time you regenerate.

If sd0 = 1 , the first time it will be 1.5, the 2nd 1.5**2, 3rd 1.5**3.... Nth, 1.5**N

As far as "clearly wrong", Pro/E is just adjusting the positions of the points as your relations state. I do not know what you are expecting the shape to show, but you are not "scaling" the whole shape, just the points. The curves follow what constraints you have in the sketch, look and see if they are what you intend.

Peter Stockhausen
Senior Design Analyst (Checker)
Infotech Aerospace Services

http://www.infotechpr.net

 

[treddie]

Thank you for your response, PeterStock!

By "scaling", I meant somewhat inaccurately as you suggest, that it is a matter of scaling the shape with a horizontal scale AND an independent vertical scale. I know that because it is a spline, that the resultant shape of the "scaled" curve is not precisely what you would get had you, for instance, had the shape in Photoshop, and scaled the horizontal and vertical dimensions of the image independently. But the amounts I will use in practice will be minor enough that for all intents and purposes it will be good.

I guess my error is that I ASSUMED that when ProE regens, it does a single pass through the relation. Otherwise, using the "recursive" approach of sd0 = sd0 * Scale would have worked. I wanted to do it that way to avoid having to set up an external vb program to do the calculations and write the relation. Because then, I have to code in the original values as constants...all 1252 of them!

I am going to try a little experiment, by putting a counter in the relation, and by using IF/ENDIF blocks, allowing each dimension to evaluate only on a given counter value. Then resetting the counter when it passes the value 1252. If this works, at least it would verify that ProE makes multiple passes through the relation.

 

[treddie]

The test failed.

My idea was this: I started with a horizontal datum line composed of 4 equal length segments. The Relation would only be allowed to change a given coordinate of one of the points along the line (call it the Main Line) when a counter reached a corresponding value. Since a Relation cannot remember its internal values between "calls" to it by ProE, I had to store a counter somewhere. So what I did was create a simple line as a separate feature from the main sketch. The purpose of this line (call it, the Count Line) is to store the present value of the count as the Count Line's length dimension. The counter raises the count in increments of 100. The coordinates get altered by the Relation in the following order:

coordinate affected: when counter value is:
P1x 200
P1y 300

P2x 400
P2y 500

P3x 600
P3y 700

P4x 800
P4y 900

P5x 1000
P5y 1100

Each pass through the Relation SHOULD only affect a single coordinate, but the end result should be that after 10 passes through the Relation (for the 10 coordinates), the Main Line should be raised over its entire length by a value of 200 (its starting height was 200...it should end up at 400).

Here is the new Relation:

Hscale=1
Vscale=2

counter=d10 /* This is a counter. Since the relation cannot remember
/* values between "calls" to it, its values are all "0" on entry, so there
/* needed to be a place to store the counter value. It is stored as
/* a line segment's length outside of the sketch. The line length begins
/* at an arbitrary value of "100", so that it can be easily seen during
/* the test. Also, the line SHOULD increment in length by "100" for each
/* step, so that as progress proceeds, any changes can be easily seen on
/* the screen.

/* As each coordinate is processed, the counter is incremented, and the value
/* stored in the external-to-Sketcher, line segment's length.

/* -----------------------------------------------------------ProE-80chars-Limit
/*-------------------------------------------------------
/* For test only:

sd27=sd27
sd29=sd29

sd26=sd26
sd28=sd28

sd25=sd25
sd30=sd30

sd24=sd24
sd31=sd31

sd32=sd32
sd23=sd23

/*-------------------------------------------------------
/* Increment the counter:

counter=counter+100 /* "100" arbitrarily chosen for a delta length that
/* is easy to spot changes in as test proceeds.

/*-------------------------------------------------------
/* Check if last coordinate in list has been passed:

if counter > 1100 /* Have passed the last coordinate in the list.
d10=100 /* Reset the line length.
counter=d10 /* Reset the counter to the line length.
counter=counter+100 /* Increment the counter to "200".
endif

/*-------------------------------------------------------
/* Transform the appropriate coordinate:

if counter == 200
sd27=sd27*Hscale
d10=counter
endif

if counter == 300
sd29=sd29*Vscale
d10=counter
endif

if counter == 400
sd26=sd26*Hscale
d10=counter
endif

if counter == 500
sd28=sd28*Vscale
d10=counter
endif

if counter == 600
sd25=sd25*Hscale
d10=counter
endif

if counter == 700
sd30=sd30*Vscale
d10=counter
endif

if counter == 800
sd24=sd24*Hscale
d10=counter
endif

if counter == 900
sd31=sd31*Vscale
d10=counter
endif

if counter == 1000
sd32=sd32*Hscale
d10=counter
endif

if counter == 1100
sd23=sd23*Vscale
d10=counter
endif


Now, when I step through the Relation with "Show Rel", everything works fine. But when I actually run it, weird things happen. For instance, after I load the text for the Relation and regen, the first coordinate jumps to its new position, but all of the others do not. That would only make sense if ProE only made two passes through the Relation. But if that were so, then the counter should only be reading "300" when in fact it reads "800". The counter starts at 100, and SHOULD increment by 100 for each coordinate, ending with a final value of 1100, after which it resets. But in fact, since the value becomes "800", this means that the Relation has been entered by ProE, 7 times! If it made it through 7 times, why didn't the other corresponding coordinates get transformed also? And why did ProE not complete the ENTIRE sequence and end up at a counter value of 1100?

But it seems that logically, ProE should only be making a single pass for each regen. I should then have to do 10 regens to get the entire line to lift up to its new level (Not that I would want to do a regen for each step in a real situation, especially if there are 100's of points, but for this test, that's Ok.).

Also, sometimes one of the points on the Main Line will lift after a regen, while at other times, 2 will lift after a regen, but never more.

I know my code is working properly, as an isolated piece of code, but it seems that the way I am trying to store the value of the counter in The Count Line's length is not compatible with the way ProE changes the dimensions of an external feature (in this case, the Count Line).

But also, how does ProE process the contents of a Relation? Does ProE exit after each change of a dimension?

 

[treddie]

Ok, I found the solution. If I run the above Relation as a Part Relation rather than a Sketcher Relation it works as expected...I have to regen 10 times to complete the entire set of coords.

And if I run my ORIGINAL Relation as a Part Relation rather than a Sketcher Relation it all gets done on a single regen:

Hscale=1
Vscale=2

d4=d4*Hscale
d6=d6*Vscale

d3=d3*Hscale
d5=d5*Vscale

d2=d2*Hscale
d7=d7*Vscale

d1=d1*Hscale
d8=d8*Vscale

d9=d9*Hscale
d0=d0*Vscale

But that still leaves the question as to why it would not function as a Sketcher Relation.