Relations: Parameter defined as INTEGER changes to REAL

[KenFarley]

I'm working in Creo 4.

I have a parameter numSets, that I define as an Integer.

Now, I calculate the value of that parameter using dimensions of the model in the following relation:

numsets = ( lenmain - 2 * dxsltstrt ) / ( 2 * diaslot ) - 2

 Here's the part that irks me. After the relation has been entered and evaluated, Creo changes my parameter from Integer to Real, assigning it a value that has a fractional component to it.

The expected behavior, based upon every other programming language I've used, is for the type of parameter to be left as I defined it and the value be rounded or truncated to a whole INTEGER value. Switching the parameter type is absolutely NOT an acceptable result.

Knowing this, I'm going to have to be careful to explicitly use floor() or ceil() to restrict the assigned value.

Why is this kind of tomfoolery type conversion built into Creo?

[TomU]

Using relations is actually a sneaky way of changing a parameter's type.  Even though you can't do it manually without deleting and recreating the parameter, relations will gladly change the type for you.  It shouldn't work, but it does.  😁

[Dale_Rosema]

WOW!

[TomU]

What do you want to bet that this is 'working to spec'.  😂

[Dale_Rosema]

Maybe "working to spec", but definitely not "working as expected".

[TomU]

That is my number one frustration with PTC's products.  Frequently 'working to spec' does not equal 'what a normal person actually using the software would expect'.  There is just this huge disconnect.

[tbraxton]

Has anyone inquired with PTC whether this behavior using relations is working to spec? This article from PTC addresses this issue but apparently not thoroughly.

https://www.ptc.com/en/support/article/CS116590 

@TomU Do you know if the parameter is set in a layout declared to a model if the model relations still allow the type to be changed in the relations?

I am guessing that the relations are designed to take precedence because of the regeneration sequence handling. Surely there must be some way to set a type to a parameter that can not be altered in relations. 

[TomU]

---

@tbraxton wrote:

Has anyone inquired with PTC whether this behavior using relations is working to spec? This article from PTC addresses this issue but apparently not thoroughly.

https://www.ptc.com/en/support/article/CS116590

---

I will open a case and ask.

---

@TomU Do you know if the parameter is set in a layout declared to a model if the model relations still allow the type to be changed in the relations?

---

Layout (notebook) parameters are read only in the models they are declared to so those cannot have their type or their value changed in the children models.  It also seems like one the layout is declared to a model that the layout parameters inside the layout can no longer change type either.

[KenFarley]

Wow. I had no idea this behavior could go as far as switching to a non-numeric type. I wonder what would happen if there were further relations that used the value of ABC. Would they fail? Probably.

This is the kind of hard to debug stuff you see in Perl programs and the like, not what I'd expect in an environment where parameters are strongly typed.

I want to know, as I see someone has asked below, a means of "locking" the parameter to the type I declared.

[TomU]

---

@KenFarley wrote:

Wow. I had no idea this behavior could go as far as switching to a non-numeric type. I wonder what would happen if there were further relations that used the value of ABC. Would they fail?

---

Nope.  Subsequent relations can switch them back and forth with no complaining whatsoever.

[tbraxton]

I just quickly tested out the concept of using a layout to "lock" the parameter in the context of part mode relations. It does appear that a variable defined in a layout  is "protected" in part mode while the layout is declared. If the layout is undeclared the parameter type remains protected.

In a layout I defined a parameter of type string v1=testv1. I declared this layout to a part and then attempted to redefine the variable using a relation. This is the result; Cannot assign to a part-driven value. 

[tbraxton]

When Pro/Notebook (now Layout) was first deployed one of the functions was to serve as a method to declare global variables for use in other models. So it would be reasonable to expect that parameters defined in a layout should not be subject to modification in a dependent model. I think based on my limited testing that this is the case and would be one way to address your issue. I am not sure if it is the only way but it is worth trying. You should be able to undeclare the layout and maintain this "protection" of the declared variables in any dependent models.

[KenFarley]

The trouble is, we don't have Layout. I can perform the same basic functions of that module using what I call a Master Assembly. Make all the simple sketches that will define the product, define all the parameters I want to use to drive design criteria, like min wall thickness, hole sizes, etc. Build the component parts within that assembly and use the parameters and sketches to drive the definition of the parts. It works really well, but it's not Layout. It lacks the controls and protections that Layout apparently provides.

[tbraxton]

You do not need Creo Layout product/module for this. Layouts (.lay) are part of core Creo parametric functionality. PTC naming of products causes so much confusion.

Try this in Creo; CTRL+N and look for Notebook file type. If you see Notebook in this window then you can create and use a layout.

[TomU]

I'm pretty sure you have to have the Advanced Assembly extension...

[tbraxton]

@TomU  may be correct about having AAX or equivalent to use Notebook files. I have never been without AAX ever so I sometimes forget that you can buy a license without it. If Creo Parametric is being used to design things I sure would not want to have to work without the AAX Top Down Design Tools. In my case the cost would be recovered in less than a week of work in lost productivity without it.

If you do not have AAX then ask your management to get it if you are using Creo to design things that consist of more than one part. IMO it is not leveraging the advantage of Creo Parametric without the top down design tools. In layman's terms consider using an axe vs a chainsaw to fell big trees.

[KenFarley]

When I attempt to create a Notebook get the following:

This functionality requires one of: NOTEBOOK

So we evidently don't have whatever module includes this.

[HamsterNL]

Creo will use a REAL number because (most likely) your formula outputs a REAL number.

If you want your formula to output an INTEGER, you should always use a CEIL or FLOOR function.

I do wonder...numSets sounds like you want to calculate the "number of sets" of (for example) fasteners. If your formula results in 4.15782564 "sets"...do you want to use 4 sets...or 5 sets? And 4.856284618...4 sets or 5 sets?

Also, know that a formula that uses "CEIL((x-b)/a)" can have a different outcome compared to "FLOOR((x-b)/a) + 1". That will become apparent when (x-b)/a results in an integer value.

[KenFarley]

But that's not the issue I have with it. The problem is Creo *changing* the type of a parameter I defined. In any other programming language I've used that is based on strong typing, i.e. requires you to define the type of the variable before you can use it, variable types are not changed willy-nilly to comply with what the assigned value is. When I define an Integer, it better stay an integer, regardless of the assigned value. If this results in quirky behavior because I didn't take into account rounding or truncation, that's my fault, but that's not the problem here.

As for floor and ceil, yes I'm all to well aware of how they work. Bear in mind that these functions actually output Real numbers, too.

The numSets, not that it matters, is sets of pairs of items I was placing. I needed to place two of an item close together and was calculating how many sets of them would fit in a particular area. When given the choice I like to have things spaced as evenly as possible - fasteners, slots, position markers, etc.

[pausob]

I always thought that INTEGER type of parameters were kind of odd - for example, it's not supported in Pro/PROGRAM...  And you can't do the "force" a parameter to become an INTEGER type though this relations tomfoolery.

I'd avoid using them altogether.  What's the point?  It's not like you need to have integers for that infamous itos() function to work 🙂

Anyway, I found a Pro/Work-Around if you want the error thrown if a "real" or "string" value is being assigned to your integer valued parameter: Make it a restricted integer type - let's say less than 32767 and more than -32768:

If this kind of parameter is then assigned an incompatible value:

[KenFarley]

Integers, when properly implemented, have advantages over other data types. In general, for any programming language, there are these:

(1) Unambiguous values. For a real number, what is a "2" could be, due to rounding or whatever, 2.0000001, or 1.9999998, depending on what has happened to that variable. This could, if you're not a cautious programmer, lead to erroneous results if you're relying on a conditional statement like IF x < 2 THEN...

(2) Integers take less memory space, particularly if the language you are using has implemented different length variants, like C's short and long. Probably not a concern with Creo.

(3) Mathematical calculations with integers are faster than floating point. Again, probably not a concern with Creo, but I've had to do real-time data acquisition and leaving the data as the "raw" integers greatly improved max data rates possible.

The trouble I'm seeing with Creo is, if an "Integer" is just a "Real" that has a temporary or honorary status as an integer until something changes it, then none of the advantages of integer data types is applicable. The most worrisome is the possibility of errant IF/THEN conditionals, but I can deal with that by avoiding the "==" logical comparison, I suppose.

[Dale_Rosema]

Looking at Tom's first video, I think it would be more scary if the number is turned into a string.

[pausob]

Ok, forget about my comment about integers; no doubt that they have advantages.  I submit that you were are operating under a (false) assumption that Creo relations form some kind of a "strongly typed" computer programming language.  To me, it's no surprise that the system works in a wonky ways.

does the provided workaround address your type-concerns?

[KenFarley]

No, I don't see any workarounds that will prevent Creo from doing this terrible behavior.

And, yes, Creo does have a lot of weird behaviors (My personal favorite is ITOS ( 0 ) = "". What genius thought that was the correct result?) I just have to know them and anticipate them in the relations I write, I suppose. No more absolute ( ==, <> ) comparisons for (might be) integers, anymore.

[pausob]

I'm curious as to why the demonstrated "restricting-the-parameter" trick would not qualify as a work-around that addresses your concerns about the data type of the variable changing on you.