some things never change, I Still hate relations

[TerryJohnson]

so I have a part to represent some edge grommet, and I need it to be AR

I add the following relation

if asm_mbr_partnumber =="85085K4"
num = "AR"
else
num = rpt_qty
endif

and it works perfectly..

then I add two bulk items
( we already have relations that set bulk items to AR ) <do i=" need=" to<br="/>possibly delete this??

now my bulk items come in as qty 1
so I add 2 new relations for the bulk items same as above..

and the bulk items are now AR but the original one that I wrote the first
relation for comes in as 1

#havingtowriteazillionrelationsforyourpartslisttoworkproperlybites
#spending20minutestryingeveryvariationandgettingdifferentresultsbites
#relationsbite
#Ineedchocolate



                                                      
                                                      
                                                      

This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

[BrianMartin]

Hi Terry,

The 'else' statement is causing your issue. Remove all of them from each relation (and the statements that come after them). Instead, BEFORE you process those 'if' statements, add a line that says:

num = rpt_qty

Then below that add all of your of statements like this:

if asm_mbr_partnumber =="85085K4"
num = "AR"
endif

<next if=" statement=" goes=" here=">

This will correct your issues. At each if statement you're performing a test and if the test fails, you're reseting your num variable back to the default of rpt_qty. This is why it seems like some of your statements work and some do not. This is a common issue for people. Programmers learn to think through such strange logic and become comfortable understanding how to manipulate it. But this can be a sticking point for people unfamiliar with programming logic.

I hope that helps! Please write back if you cannot get this to work.

Thanks!
Brian



Sent from my T-Mobile 4G LTE Device

[bfrandsen]

To have it even shorter the OR operator || can be used:

num=rpt_qty
IF asm_mbr_type == "BULK ITEM" || asm_mbr_partnumber == "85085K4"
num="AR"
ENDIF

/Bjarne

[TerryJohnson]

Removing the else fixed it, now my bulk items are reading correctly

I don't think I've ever done this without the else  - maybe that's why
sometimes it works and sometimes it doesn't

[drichards]

There's some help with relations in Help.

[ptc-131571]

I think the phrase < If you don't use it, you'll lose it > applies here
too. I've been a ProE/Creo user for 21 years. The first four years of
modeling and NC programming involved customizing post-processors and
writing relations day after day. The last 15 years all I've been doing is
detail models and some assemblies (with really big family tables). I
haven't written a relation since 1998, and if I had to do it today, yes, I
would have to look it up in PTC University. And yes, life was a lot
simpler then using Unix OS.

There is no such thing as a dumb question. I've been with this company 49
years and still ask them.
"A pilot spends his entire life trying to make the perfect landing"

Gordon Caha, CMfgE
Mfg. Engineering
Complex Machining & Assembly
Solar Turbines Inc.
Phone 619 544-2329

[TerryJohnson]

think back.. when was the last time you saw me ask a relations question??
I think it was 2001 (I know I was at GOEX and we had NO SUPPORT and this
forum was my salvation) and yes EXCUSE ME.. I FORGOT!!! Heaven forbid!!

My searches (I always search first) turned up nothing.  The only
documentation I could find at my desk was exactly they way I did it.
Surprisingly I did not forget it.

It just wasn't working that way...

Really Dan?? If you didn't want me to take it personally maybe you
shouldn't have asked?

& Gordon, thank you!

[kimndave9]

"This is why it seems like some of your statements work and some do not. This is a common issue for people. Programmers learn to think through such strange logic and become comfortable understanding how to manipulate it. But this can be a sticking point for people unfamiliar with programming logic"

It would be less a problem if PTC provided Switch/Case or cascaded IF/ELSEIF/ELSE/ENDIF structures.

The cascade can be simulated using nested IF/ELSE/ENDIF as below from http://www.mcadcentral.com/creo-modeling/20554-proe-if-statements-w-string-params.html It allows the use of ELSE without non-obvious side-effects.

if search(DESCP , "LH") >0
Z = (W/2) - (.744/2) - .015
if search(DESCP , "RH") >0
Z = (W/2) + (.744/2) - .015
ELSE

Z = W/2

ENDIF
ENDIF

Alternatively, the structure below, redundant in the report qty case, can make for more capable relations, obviously only changing the value for num once, but controlling secondary variables based on it.

num="
mult=1

if asm_mbr_partnumber =="85085K4" & num=="
num = "AR"
endif

if asm_mbr_partnumber =="XYZ123" & num=="
mult=2
endif

if num == "
num = rpt_qty * mult
endif

x

[iceblink1]

On 2014-05-06 06:52, David Schenken wrote:
> The cascade can be simulated using nested IF/ELSE/ENDIF as below from
>
>
> Z = (W/2) - (.744/2) - .015
> if search(DESCP , "RH") >0
> Z = (W/2) + (.744/2) - .015
> ELSE
>
> Z = W/2
>
> ENDIF
> ENDIF
>

Bad example.

Let me rewrite the above with some extra white space to clarify:

IF search(DESCP , "LH") >0
Z = (W/2) - (.744/2) - .015
IF search(DESCP , "RH") >0
Z = (W/2) + (.744/2) - ....

[kimndave9]

Well, there was no additional whitespace kept by the editor, but the comment does reinforce my assertion that PTC needs to add a Switch/Case, without drop-throughor IF/ELSE IF/ELSE/ENDIF cascade.

Properly written with the stone knives and bearskins available ("."s to keep editor from eating white space):

IF search(DESCP , "LH") >0
Z = (W/2) - (.744/2) - .015
ELSE

.....IF search(DESCP , "RH") >0
.....Z = (W/2) + (.744/2) - .015
.....ELSE
.....Z = W/2
.....ENDIF

ENDIF

What it could look like with decent structure:

IF search(DESCP , "LH") > 0THENZ = (W/2) - (.744/2) - .015
ELSE IF search(DESCP , "RH")> 0 THEN Z = (W/2) + (.744/2) - .015
ELSE Z = W/2
END IF

x

[JonathanHodgson]

I think the clue is in "people _given_ admin responsibilities":

"Hey you, you're good at using Pro/E - you can be the admin."

See also: Peter Principle (and possible Dilbert Principle).

Jonathan

[iceblink1]

To be fair, for most companies the CAD admin job is not a full time
job. So you can either give it to a CAD engineer who knows all about the
software and engineering but not much about IT and other things, or to
the IT guy who knows all about IT and software in general but nothing
about CAD or engineering. Or the third option is to give it to a
contractor specialised in CAD admin, who knows all he should know about
the subject, but he will need time to get to know the company he is
working for.

Or another option is that PTC makes the software easier w.r.t.
relations, but this is difficult due to required backward compatibility.
There are loads of parts with relations, and you can't have them fail
due to a newer better relations scheme. Probably a case of "Law of the
handicap of a head start".

Best regards,
Patrick Asselman

[kimndave9]

My money is always on those who, like Terry, can and do ask good questions when there is something going wrong. That's the best kind of employee.

In Reply to Jonathan Hodgson:

I think the clue is in "people _given_ admin responsibilities":

"Hey you, you're good at using Pro/E - you can be the admin."

See also: Peter Principle (and possible Dilbert Principle).

Jonathan

x