|
Welcome to the COE Discussion Forum!
|
|
|
|
To participate in the discussion forum, you must be logged in to the website. If you forget your login information, please contact COE Headquarters at coe@coe.org or (800) 263-2255.
If you are new to the COE Discussion Forum and would like to participate, please register.
|
|
|
The COE 2008 Fall Industry Workshops
|
| Experience two days of industry-focused education and hands-on training on the Dassault PLM solutions suite of products. All education featured at the workshop is developed by and for users of CATIA®, ENOVIA®, DELMIA® and SIMULIA®. |
| |
|
|
Automotive
Oct. 15-16
Troy, Michigan
|
Aerospace & Defense
Oct. 27-28
Wichita, Kansas
|
 |
|
Register by October 10 and Save $100
|
|
| Forum Highlight: CATIA V6 |
|
|
 |
|
 |
| You are not authorized to post a reply.
|
|
| Author |
Messages |
|
IPHILLIPS
 |
| 04 Jul 2005 05:59 AM |
|
I am trying to create a for-while loop in a reaction
Both i and total are integers
Message(total,i)
for i while i < total
{
Message(total,i)
}
I would expect it to loop and display a message counting up from 1 to total. But instead it runs the loop once and displays i as total on the first run. Why does i become total straight away?
What am I doing wrong?
Ian |
|
Ian Phillips. FORCEFIVE AG, Munich, Germany |
|
|
IPHILLIPS
|
| 05 Jul 2005 05:31 AM |
|
I am now CLOSER to solving the problem.
1) Apparently the for while loop only displays the last Message.
2) I am now sucessful in performing the loop except when there is a GetItem(i)
e.g. if the loop contains a GetItem it is only returning the first Item:
for i while i < total
{
CRV1= list.GetItem(i)
join = assemble(join,CRV1)
}
Has anyone accessed a list froma for while loop? |
|
Ian Phillips. FORCEFIVE AG, Munich, Germany |
|
|
CARBAHOLIC
|
| 05 Jul 2005 10:17 AM |
|
is there any way to debug, like have it output a message to the screen or to a message box?
Eric |
|
|
|
|
CRAIG HELM
|
| 05 Jul 2005 01:52 PM |
|
One thing to keep in mind too is that it may be showing all of the messages, but it is just flying right past them and going to the next one w/o you even noticing it.
I don't see where you are changing i, but make the loop run a million times or something and see if you can see it. |
|
-craig helm
Catia V5 R16 | Windows XP SP2 | Intel P4 3.4GHz | 2GB RAM | ATI FireGL V3100 128 MB DDR |
|
|
CARBAHOLIC
|
| 05 Jul 2005 02:28 PM |
|
or if there is a way to require user input during the loop you can stop it and see how it does iteration by iteration.
Eric |
|
|
|
|
BPRASAD
|
| 05 Jul 2005 04:41 PM |
|
I added another integer j and k as a Debug. Initialize i=1 and j=1 and total =10.
Used the following modifed action script for the reaction.
================
Message ("Value total =", total, "Value i=", i)
for i while i<total
{
Message(" total= ", total," i= ", i, " j= ", j)
j=j+1
k=i
}
================
At the end of the reaction, like you (Ian) said, it gives two messages. One before the loop and one after the Loop "for i while" is completed. Theoretically, the above action should have given 9 messages one for each i.
However, One thing I notice that at the end of Reaction, the final parameter values were: i=9, j=9 and k=9. Why?
That means i and j were incremented all along. Just the "Message" was not executed until the LAST -- only when "while i<total" condition was not met.
Is this the expected behavior for "for i while" loop? Or else there is a bug?
|
|
Brian Prasad
COE-DPC/KBE Chairperson |
|
|
CRAIG HELM
|
| 05 Jul 2005 10:24 PM |
|
| I know that this is not typically expected behavior, but maybe a messagebox can be programatically "cleared from the screen" automatically and it is popping up and disappearing 10 times. With the speed of the computer, you may just not be able to notice it. |
|
-craig helm
Catia V5 R16 | Windows XP SP2 | Intel P4 3.4GHz | 2GB RAM | ATI FireGL V3100 128 MB DDR |
|
|
IPHILLIPS
|
| 06 Jul 2005 12:26 AM |
|
Thanks for all of your suggestions.
I was only using the Message in the for-while-loop to see why my next line was not working. I dont really mind if the message has a problem. But it seems that the 'GetItem' does not sequentially retrieve the next feature from the 'List'. It should work, according to the Online documentation.
I am now ready to give up. :-(
|
|
Ian Phillips. FORCEFIVE AG, Munich, Germany |
|
|
BPRASAD
|
| 06 Jul 2005 10:19 AM |
|
| I have requested DS to look into it. Let us wait for their response? Thanks. |
|
Brian Prasad
COE-DPC/KBE Chairperson |
|
|
pwebb
|
| 06 Jul 2005 05:28 PM |
|
Hi Guys
This is my first contribution to the KBE forum, I hope its of some help.
1) The message box problem. As you already found out, the message only fires on the last loop. This is actually a built in "optimization" to make the loop run quicker! This may be changed in the future to make this clearer. Incidently, the loop fires correctly in KWE.
2) I'm not sure exactly what is happening in your scenario Ian but I made a quick test.
let i(integer)
let total(integer)
let x(integer)
let y(integer)
i = 1
total = 0
for i while i <= List.1 .Size()
{
x = List.1 .GetItem(i)
y = total + x
total = y
}
Message("The sum of the list is #", total)
My loop just sums the contents of the list "list.1" which contains some numbers and it works fine. (Remember that there is a built in Kware method to do this if you really need it!). However..
1) Remember to initialize i
2) Remember the first member of the list has index 1 in this syntax
My test was run in R14 SP6 and I have no problems. Do you have anymore details of your scenario?
|
|
|
|
|
BPRASAD
|
| 08 Jul 2005 12:09 PM |
|
Talking to DS KBE Domain Leader, I found that Message rule is working as designed.
In order to avoid mutiple messages in a loop, as Paul said, DS has optimized the set when Message Function is used in a loop. In their words,
"The messages registered by Message function or wrong checks are posted but not shown synchronously. Before showing them they are filtered : any message is removed if the first argument of Message function is the same than another one (the last only is kept). "
Here is a Bypass (a trick), if you would like all your messages to be shown synchronously even if it is used in a loop.
===========
/*Rule created by bp51136 7/8/2005*/
/* Bypass (a trick), if you would like all your messages to be shown synchronously in a Loop*/
let mymessage (String)
let n (integer)
let total_3 (integer)
total_3 = 0
n=1
for n while n<=7
{
total_3 = total_3 +n
mymessage = "... for index " + ToString(n) + "..." /* this allows to have a different argument content for each iteration */
Message(mymessage, total_3)
}
===============
If you run the above rule in KWA, you will get Messages each time when "n" is incremented during the "for While" Loop. OK!!!
Let us thank DS for getting us a resolution on this problem quickly. Cheers!!!
|
|
Brian Prasad
COE-DPC/KBE Chairperson |
|
|
IPHILLIPS
|
| 12 Jul 2005 02:19 AM |
|
Paul
This is my loop that is failing:
---------------------------------------------------------------
let i(integer)
let Join(curve)
i = 1
for i while i <= List.1.Size()
{
Join= assemble( Join,List.1.GetItem(i))
}
Body\Curve.1=join
---------------------------------------------------------------
After execution, the Join only contains the first GetItem. This was the reason I used a Message. To detect where it was failing.
It is very similar to yours but uses 'geometry' in the list and the Join references itself.
Used outside the loop, the self referencing works fine, like this:
Join= assemble( Join,List.1.GetItem(1))
Join= assemble( Join,List.1.GetItem(2))
Join= assemble( Join,List.1.GetItem(3))
The explicit numbering creates a join of the list items. But inside the for-while loop it stops after the first value of (i) |
|
Ian Phillips. FORCEFIVE AG, Munich, Germany |
|
|
BPRASAD
|
| 13 Jul 2005 01:39 PM |
|
I noticed the KWA rule is doing 2-3 things: (a) Initializing the temps variables, (b) Updating the Curve “value” for each value of “I” and (c) Creating an “Assemble_Curve” from what has been created before. I believe the order of operations (especially Initializations) is causing the Rule not to function – in the way -- you wanted it to function. Fortunately, there is a way to do the same thing using “KWA/Rule and KWA/Reaction” Combination. Here is how you would go about doing it. It has worked (yielded results) successfully for me. Let us hope you may get good results in your situation -- as well.
Step 1: You would create the following 3 parameters and a List
List_Of_Curves //this is a list of all curves extracted from your List.Query statements).
MaxCounter = List_Of_Curves\ListSize // Use the Formulae Function to Create this as Integer type and add Formula.
LCounter = 1 // Use Formulae/New Parameter to Create this as Integer type
Update= true // a Boolean Parameter type
Step 2: Create ACurve // in a New Body. U
se Formulae/New Parameter to create this as a “Curve” type – do not set at this time.
Step 3: Write a KWA/Rule to reset a Curve to “A-Curve” using the following “Rule” contents
=======================================
/* KWA/Rule created by bp51136 7/12/2005*/
/* This Rule only extracts a curve from the list and rename it and save it onto the document as ACurve */
/* For Each value of LCounter, which is perturbed (reset) inside the Reaction */
let New(curve)
if (LCounter <=MaxCounter )
{
New = List_Of_Curves. GetItem(LCounter)
Body.4\ACurve = assemble(New)
}
=======================================
Step 4: Create a KWA/Reaction
Sources: Click on Update Parameter from the tree and set it to “ValueChange” condition.
Action: You copy and paste the following Knowledge Language scripts into Action window and make changes if needed.
==================================
LCounter=1
/* Written by Brian Prasad */
/* For each value of LCounter, it reads the value of ACurve based on KWA Rule and then appends that new ACurve value to Assemble_Curve*/
for LCounter while LCounter <=MaxCounter
{
OpenBody\Assemble_Curve =assemble (OpenBody\Assemble_Curve , Body.4\ACurve )
}
====================================
Step 5: To run this or Update the “Assemble_Curve,” you would toggle the value of Update parameter (false/true). The reaction would be fired since its “value is changed”
This way you would get the results you desire.
Let me know if this did work for you?
|
|
Brian Prasad
COE-DPC/KBE Chairperson |
|
|
IPHILLIPS
|
| 14 Jul 2005 09:21 AM |
|
Brain
Yes, well done, it works! You are, indeed, a bastion!
The rule updates the first curve. Then the Reaction kicks in to join everything together. So it looks like this "first curve" is somehow important. Its still not completely clear.
Occaisionally it gets stuck though!. This I will test further.
Thanks a lot.
Ian |
|
Ian Phillips. FORCEFIVE AG, Munich, Germany |
|
|
BPRASAD
|
| 14 Jul 2005 11:15 AM |
|
Thanks! I am glad you could reproduce.
I did noticed that the "LCounter" exceeds the "MaxCounter," when "for LCounter while" is completed (inside REACTION).
That may be the cause for your instability. Here is what you can do to fix it.
Use the following Logic Inside of REACTION instead of what I had told you before.
/*===========================*/
/* Written by Brian Prasad */
/* The first two lines Initialization the "Assemble_Curve" and "ACurve" */
LCounter=1
OpenBody\Assemble_Curve =Body.4\ACurve
/*For each value of LCounter, it reads the value of ACurve based on KWA Rule and then appends that new ACurve value to Assemble_Curve*/
for LCounter while LCounter <MaxCounter
{
LCounter = LCounter+1
OpenBody\Assemble_Curve =assemble (OpenBody\Assemble_Curve , Body.4\ACurve )
}
/*============================*/
Good Luck... |
|
Brian Prasad
COE-DPC/KBE Chairperson |
|
|
IPHILLIPS
|
| 15 Jul 2005 03:45 AM |
|
Brian
Yes, That has solved it. Thanks again.
I get the feeling that these measures are workarounds for weaknesses in the KWA software. Do you think there are meaningful reasons why my nice simple rule could not work?
This is now, what I call, a KWA buliding block, that complements straight GSD to add a "dynamical branching" to the structure. (Multiple features become one feature when you look at the Historical Graph.)
My next problem is to make the reaction kick in automatically. I though the rule could trigger a value that would trigger the Reaction. But it seems to get into loops despite making sure the reaction does not trigger itself. |
|
Ian Phillips. FORCEFIVE AG, Munich, Germany |
|
|
pwebb
|
| 15 Jul 2005 04:05 PM |
|
Hi Ian (& Brian)
Interesting workaround but I don't think it's necessary. I think your problem is that on the first time through the loop your Join variable has no value and that is causing some problems. I've modified your syntax to include an if statement to avoid that situation.
/*Rule created by pwc 7/15/2005*/
let i(integer)
let tempcurve(curve)
let Join(curve)
i = 1
for i while i <= List.1.Size()
{
if i ==1
tempcurve = List.1 .GetItem(i)
else
tempcurve = assemble(tempcurve, List.1 .GetItem(i))
}
`Geometrical Set.2\Curve.7` = tempcurve
The first time through the loop tempcurve is set to the first curve and then on subsequent loops it has the other curves appended to it.
This works fine for me in R15 and should work for you.
If the other method works for you then fine. It's always useful to be able to do the same thing in different ways 
Hope that helps
Cheers,
Paul |
|
|
|
|
BPRASAD
|
| 15 Jul 2005 05:10 PM |
|
Oh Yeah!! Cool!! That is our old good Nested Loop!
I am glad you pointed out to us. I didn't know we can use those inside a "for while" loop.
Thanks  |
|
Brian Prasad
COE-DPC/KBE Chairperson |
|
|
pwebb
|
| 16 Jul 2005 07:48 AM |
|
Infact you can "nest" most constructs inside each other in a similiar way to VB; so you can put loops inside of IF statements and vise-versa. You just need to maintain your brackets; as always.
Because the rule editor can make it hard to read complex rules with nested statements it's worth while adopting an indentation convention and sticking to it, then you can at least keep your opening and closing brackets in vertical alignment!
Also about the issue with the message only being displayed once. There is a simple change to the syntax which will allow the message to be displayed multiple times.
The message function usually works like this...
Message("Loop index #",i) .... where the #'s are replaced by the arguements after the ","
If you create a simpler message as follows...
Message("", i) .... If you remove the #'s the message should fire on each loop.
I've only used this method with an empty string and so the message cannot be complicated, but it is still useful for debugging. As I said before, this may change in future releases.
Happy rule writing!
|
|
|
|
|
IPHILLIPS
|
| 19 Jul 2005 04:55 AM |
|
Paul
I had already tried creating the 'first' assemble before the loop, and with no success.
And now, in R14, I am having no success with either of your suggestions. The first and second joins are successful. Because the joined result contains the first 2 curves only.
Do you think something has changed in R15? |
|
Ian Phillips. FORCEFIVE AG, Munich, Germany |
|
|
|
| You are not authorized to post a reply. |
|
|
|
ActiveForums 3.6
|
|
|
|