Hello,
I use Creo 2.0.
I have dome some internet research and I haven't been able to find how to convert a Real Number-type parameter (like 40.000) into an Integer-type (40) with relations. This is needed for downstream simulation purposes.
I tried the abs(), floor() and ceil() functions. They round to the correct value, but the type is still a real number.
I have tried this instruction as well: Creo String to Integer or Real Number Relation
So what I do is a double conversion: to first convert from Real to string using the itos() function, and then from string to Integer using the above... but what happens is that to output to an Integer, you must first manually create the output parameter before adding the relation (otherwise it defaults to real number), and only works on a known length string. I want to avoid that.
There must be some elegant solution around!
Any help would be appreciated.
Thanks, Alex
Solved! Go to Solution.
Hi,
First, thank you all for the suggestions and inspiration.
The only solution to this problem is to create a mapkey that runs the following steps in this particular order:
1) Create the integer parameter (in my case, N81) assigning value of 1
2) Execute ModelCHECK Interactive (which has been set up with ModelUPDATE), which inserts the relation ASM_RELATION N81 = L_BCN81 , where N81 is the integer parameter created in step 1), and L_BCN81 is the real number parameter coming from the layout
3) Regenerate
Regards!
That's a horrible method, but maybe it is necessary to prevent Creo from promoting the integer parameter to a real.
This is more compact and can be extended to as many digits as you like with little trouble, though maybe it does promote to real because of the multiplication??
(make digit_found and value integer parameters)
digitlist = "0123456789"
value = 0
digit_found = search(digitlist,extract(rel_model_name(),len(rel_model_name)-0,1)-1
value = value+digit_found
digit_found = search(digitlist,extract(rel_model_name(),len(rel_model_name)-1,1)-1
value = value+digit_found*10
digit_found = search(digitlist,extract(rel_model_name(),len(rel_model_name)-2,1)-1
value = value+digit_found*100
digit_found = search(digitlist,extract(rel_model_name(),len(rel_model_name)-3,1)-1
value = value+digit_found*1000
d0=value
Is there a reason you can't predefine the parameter to be an integer? If you need to have the parameter already exist in new parts as an integer, you could put it in a start part. Maybe I don't understand what you're trying to do and the method you need to employ to do it.
It seems like you are making this more difficult than it needs to be. If you create your output parameter as an integer before adding the relations, you can populate it directly via floor().
integer = floor(real)
If you want the result rounded:
integer = floor(real + .5)
Thanks, although I'm afraid it is more complicated to solve than what it has been suggested.
The background is that we have old models which we need to standardize.
For that, we are using ModelCHECK with ModelUPDATE.
In the model, we already have a locked parameter (L_BCN81) coming from a layout as a real number... this is I think the root cause of my trouble.
We need to map that parameter to a new name (N81) and same value, but with type Integer, because this number does never have decimals and the downstream system requires that it is defined as type Integer.
For that, if one writes in the ModelCHECK start file (.mcs file):
ASM_PARAMETER N81 INTEGER
ASM_RELATION N81 = FLOOR(L_BCN81)
The result of running ModelCHECK is that N81 gets the value but still with type Real Number.
Same result with N81 = L_BCN81 and any other combinations
I would need a work around that can be written in ModelCHECK to achieve the result we want, without having to create the parameter manually.
I don't run ModelUPDATE so I can't easily check, but what if you initialize the N81 integer parameter to a value first? Something like this?
ASM_PARAMETER N81 INTEGER EQ 1
ASM_RELATION N81=FLOOR(L_BCN81)
It works if I run through it with ModelCHECK by first adding the parameter, then the relation. If the parameter isn't initialized, then I have to give it a value before ModelCHECK will create it. Maybe it's the same for ModelUPDATE?
Hi Roger,
It doesn't work with ModelUPDATE...
What I will do is to test making a Mapkey that first creates the empty Integer parameter and then runs ModelCHECK with ModelUpdate, to see if making it by sequential steps does the trick!
Bummer. It was worth a shot. If you are writing a mapkey, you should be able to do all of the work in the mapkey (create the new parameter and write the relation). If you can't get the mapkey idea to work, my only other idea is to try and two step using ModelCHECK/UPDATE with two different start files, one that adds the integer parameter and one that add the relation. You might be able to then run ModelCHECK twice and get the desired result. Or look into something other than ModelCHECK (distributed batch, j-link/Toolkit, SmartAssembly, etc.). Good luck!
I get this to work by running separate checks one to add the parameter and one to add the relation. Requires a regen afterwards.
Try to put the following lines into your ModelCHECK start file.
PRT_PARAMETER REAL_PARAM REAL EQ 40
PRT_PARAMETER INT_PARAM INTEGER
PRT_RELATION INT_PARAM=REAL_PARAM
On the first run it will create two parameters. On the second run it will add the relation.
Did not work (because of using ModelUPDATE mode), but thanks.
I have just posted the only solution.
Hi,
First, thank you all for the suggestions and inspiration.
The only solution to this problem is to create a mapkey that runs the following steps in this particular order:
1) Create the integer parameter (in my case, N81) assigning value of 1
2) Execute ModelCHECK Interactive (which has been set up with ModelUPDATE), which inserts the relation ASM_RELATION N81 = L_BCN81 , where N81 is the integer parameter created in step 1), and L_BCN81 is the real number parameter coming from the layout
3) Regenerate
Regards!