Menu
▾
▴
plexil-support — A mailing list for PLEXIL technical support.
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
|
Feb
|
Mar
(2) |
Apr
(6) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
(6) |
Feb
(28) |
Mar
(27) |
Apr
(28) |
May
|
Jun
(6) |
Jul
(3) |
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2015 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(13) |
Aug
|
Sep
|
Oct
|
Nov
(5) |
Dec
|
| 2016 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(6) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(10) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2021 |
Jan
(9) |
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Fry, C. R. {C. (ARC-TI)[S. INC] <chu...@na...> - 2015-07-29 17:30:00
|
Yes, it appears that was the cause. ExitCondition behaves very similarly to InvariantCondition with a reversed logical sense: as soon as the ExitCondition of a parent node becomes true, every descendant node is aborted.
This includes Assignment nodes. When aborted, an Assignment node restores the variable's previous value.
-- Chuck
On Jul 29, 2015, at 10:20 AM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>> wrote:
I tried that and I got successful results! To be sure, I tried the test with the pressures meeting the StartCondition and then not meeting the StartCondition. The loops stops when the StartConditions are all met and keeps going if they are not, which is expected.
Was the redundancy between the ExitCondition and the RepeatCondition the root cause of my original issue?
Catherine
From: Fry, Charles R. {Chuck} (ARC-TI)[SGT, INC] [mailto:chu...@na...<http://nasa.gov>]
Sent: Wednesday, July 29, 2015 11:15 AM
To: Catherine Szeto
Cc: Fry, Charles R. {Chuck} (ARC-TI)[SGT, INC]; <ple...@li...<mailto:ple...@li...>>
Subject: Re: [plexil-support] Three near-identical StartConditions, only one is not working
Remove the ExitCondition on WaitingForCorrectPressureLevel and see what happens. It appears this redundant test is causing the loop to exit as soon as the last flag is assigned the value true.
-- Chuck
On Jul 29, 2015, at 7:53 AM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>>
wrote:
Chuck,
Since I couldn't figure out anything wrong with the distiller pressure node, I tried rearranging the three "Check...Pressure" nodes as brine, distiller, and product, versus the brine, product, and distiller. This time the product node was having issues exiting out. It seems to me that the loop is not correctly executing the third node, no matter which one it is. For easier testing, all three pressures are coded as "0" with the "scaledNomVacPressure" coded as "35".
I used the debug feature as you suggested. Below is what the console output was for one iteration. I highlighted the distiller pressure check in question. I've attached a screenshot of the Plexil viewer screen.
[Node:transition]Transitioning 'CheckBrinePressure' from WAITING to FINISHED at 1438124839.65869
[Node:outcome]Outcome of 'CheckBrinePressure' is SKIPPED
[Node:transition]Transitioning 'ASSIGNMENT__44' from FINISHED to INACTIVE at 1438124839.65869
[Node:transition]Transitioning 'PrintBrinePressure' from FINISHED to INACTIVE at 1438124839.65869
[Node:transition]Transitioning 'ASSIGNMENT__46' from FINISHED to INACTIVE at 1438124839.65869
[Node:transition]Transitioning 'PrintProductPressure' from FINISHED to INACTIVE at 1438124839.65869
[Node:transition]Transitioning 'ASSIGNMENT__48' from FINISHED to INACTIVE at 1438124839.65869
[Node:transition]Transitioning 'PrintDistillerPressure' from FINISHED to INACTIVE at 1438124839.65869
[Node:transition]Transitioning 'CheckProductPressure' from WAITING to FINISHED at 1438124839.65869
[Node:outcome]Outcome of 'CheckProductPressure' is SKIPPED
[Node:transition]Transitioning 'ASSIGNMENT__44' from INACTIVE to FINISHED at 1438124839.65869
[Node:outcome]Outcome of 'ASSIGNMENT__44' is SKIPPED
[Node:transition]Transitioning 'PrintBrinePressure' from INACTIVE to FINISHED at 1438124839.65869
[Node:outcome]Outcome of 'PrintBrinePressure' is SKIPPED
[Node:transition]Transitioning 'CheckDistillerPressure' from WAITING to EXECUTING at 1438124839.65869
[Node:transition]Transitioning 'ASSIGNMENT__46' from INACTIVE to FINISHED at 1438124839.65869
[Node:outcome]Outcome of 'ASSIGNMENT__46' is SKIPPED
[Node:transition]Transitioning 'PrintProductPressure' from INACTIVE to FINISHED at 1438124839.65869
[Node:outcome]Outcome of 'PrintProductPressure' is SKIPPED
[Node:transition]Transitioning 'ASSIGNMENT__48' from INACTIVE to WAITING at 1438124839.65869
[Node:transition]Transitioning 'PrintDistillerPressure' from INACTIVE to WAITING at 1438124839.65869
[Node:transition]Transitioning 'ASSIGNMENT__48' from WAITING to EXECUTING at 1438124839.65869
[Node:transition]Transitioning 'ASSIGNMENT__48' from EXECUTING to FAILING at 1438124839.65989
[Node:transition]Transitioning 'PrintDistillerPressure' from WAITING to FINISHED at 1438124839.65989
[Node:outcome]Outcome of 'PrintDistillerPressure' is SKIPPED
[Node:transition]Transitioning 'CheckDistillerPressure' from EXECUTING to FAILING at 1438124839.65989
[Node:transition]Transitioning 'WaitingForCorrectPressureLevel' from EXECUTING to FAILING at 1438124839.65989
[Node:transition]Transitioning 'ASSIGNMENT__48' from FAILING to FINISHED at 1438124839.65998
[Node:outcome]Outcome of 'ASSIGNMENT__48' is INTERRUPTED
[Node:transition]Transitioning 'CheckDistillerPressure' from FAILING to FINISHED at 1438124839.65998
[Node:outcome]Outcome of 'CheckDistillerPressure' is INTERRUPTED
[Node:transition]Transitioning 'WaitingForCorrectPressureLevel' from FAILING to ITERATION_ENDED at 1438124839.65998
Catherine
From: Fry, Charles R. {Chuck} (ARC-TI)[SGT, INC] [mailto:chu...@na...<http://nasa.gov/>]
Sent: Tuesday, July 28, 2015 4:34 PM
To: Catherine Szeto
Cc: Fry, Charles R. {Chuck} (ARC-TI)[SGT, INC]; <ple...@li...<mailto:ple...@li...>>
Subject: Re: [plexil-support] Three near-identical StartConditions, only one is not working
I don't see any issues with the files you sent this time.
Are you familiar with Plexil's debug trace faciliity? Is this running in an environment where you can spill a lot of debug info to a "console" or log file?
If you can, I'd like to see the output from a run with the following debug configuration:
:Node:transition
:Node:outcome
:Node:failure
The text above should be placed in a file named 'Debug.cfg' in the working directory from which Plexil is launched.
If you can't do this, let me see if I can find another way to ferret out what's really happening.
-- Chuck
On Jul 28, 2015, at 6:13 AM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>> wrote:
Sorry about that. I attached a plan with a similar name. Attached are the correct files.
Yes, the pressures start high and go lower. I cannot figure out if I have any incorrect syntax either, but it's bizarre that the nodes for the other two pressures are working fine while the last one is not.
Catherine
From: Fry, Charles R. {Chuck} (ARC-TI)[SGT, INC] [mailto:chu...@na...<http://nasa.gov/>]
Sent: Monday, July 27, 2015 6:28 PM
To: Catherine Szeto
Cc: <ple...@li...<mailto:ple...@li...>>
Subject: Re: [plexil-support] Three near-identical StartConditions, only one is not working
Hi Catherine. The attached files don't contain the fragments you quote below. Are you paraphrasing or did you mean to send some other files?
I don't see anything in the quoted code that looks incorrect.
I presume all the pressures are starting high and trending lower?
-- Chuck
On Jul 27, 2015, at 2:56 PM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>> wrote:
Hello Plexil team,
I have this part in my code in the attached Plexil plan:
CheckDistillerPressure:
{
StartCondition Lookup(PressureCdsskmCdTank) <= scaledNomVacPressure;
SkipCondition distillerPressureCorrect || (Lookup(PressureCdsskmCdTank) > scaledNomVacPressure);
distillerPressureCorrect = true;
PrintDistillerPressure: { pprint("EVT: distiller", Lookup(PressureCdsskmCdTank), "." );}
}
The plan basically has two separate loops and the plan runs one of the loops depending on a “full” or “empty” parameter. Both the “full” and “empty” loops have an inner loop that keeps checking “product”, “brine”, and “distiller” pressures. The inner loop prints out a statement when each pressure has met the correct pressure, and then exits when all three have met the correct pressure. When I run the plan, the “brine” and “product” pressures have no issues. The node checking for distiller pressure (the one copied and pasted above) never starts. I did some simple debugging by having the “distiller” pressure continuously printed, and was able to verify that the distiller pressure, “Lookup(PressureCdsskmCdTank)”, is reading the correct input and actually is meeting the correct pressure. I tried hard-coding the “scaledNomVacPressure” in the StartCondition to “35”, which is the correct pressure threshold, but that didn’t changed anything.
The nodes that check for the product, brine, and distiller pressures are virtually identical, so I cannot figure out why the distiller pressure is having trouble while the brine and product are not. I would appreciate any suggestions to look into. For context, this is the loop that checks for the pressures:
WaitingForCorrectPressureLevel:
{
ExitCondition ((Lookup(time,0.1) - StartTimer.EXECUTING.START) > Lookup(VacuumTimeoutINTL)) ||
(brinePressureCorrect && productPressureCorrect && distillerPressureCorrect);
RepeatCondition (Lookup(time,0.1) - StartTimer.EXECUTING.START) <= Lookup(VacuumTimeoutINTL) &&
(!brinePressureCorrect || !productPressureCorrect || !distillerPressureCorrect);
CheckBrinePressure:
{
StartCondition Lookup(PressureCdsskmBrineTank) <= scaledNomVacPressure;
SkipCondition brinePressureCorrect || (Lookup(PressureCdsskmBrineTank) > scaledNomVacPressure);
brinePressureCorrect = true;
PrintBrinePressure: { pprint("EVT: brine", Lookup(PressureCdsskmBrineTank), "." );}
}
CheckProductPressure:
{
StartCondition Lookup(PressureCdsskmProductTank) <= scaledNomVacPressure;
SkipCondition productPressureCorrect || (Lookup(PressureCdsskmProductTank) > scaledNomVacPressure);
productPressureCorrect = true;
PrintProductPressure: { pprint("EVT: product", Lookup(PressureCdsskmProductTank), "." );}
}
CheckDistillerPressure:
{
StartCondition Lookup(PressureCdsskmCdTank) <= scaledNomVacPressure;
SkipCondition distillerPressureCorrect || (Lookup(PressureCdsskmCdTank) > scaledNomVacPressure);
distillerPressureCorrect = true;
PrintDistillerPressure: { pprint("EVT: distiller", Lookup(PressureCdsskmCdTank), "." );}
}
} //end of WaitingForCorrectPressureLevel
} //end of ApplyVacuumToAll_Sequence_FullLoop
Thanks,
Catherine
<ApplyVacuumTo.ple><ApplyVacuumTo.plx>------------------------------------------------------------------------------
_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support
Chuck Fry | QTS Inc.
Office: 650 604 1882 Mobile: 408 230 2715
M/S 269-1, Building N269/260-7
NASA Ames Research Center
Moffett Field, CA 94035-1000
I do not speak for QTS Inc., SGT, Code TI, or NASA, nor do they speak for me.
<ApplyVacuumToAll.ple><ApplyVacuumToAll.plx>
Chuck Fry | QTS Inc.
Office: 650 604 1882 Mobile: 408 230 2715
M/S 269-1, Building N269/260-7
NASA Ames Research Center
Moffett Field, CA 94035-1000
I do not speak for QTS Inc., SGT, Code TI, or NASA, nor do they speak for me.
<Pressure check issue.PNG>
Chuck Fry | QTS Inc.
Office: 650 604 1882 Mobile: 408 230 2715
M/S 269-1, Building N269/260-7
NASA Ames Research Center
Moffett Field, CA 94035-1000
I do not speak for QTS Inc., SGT, Code TI, or NASA, nor do they speak for me.
Chuck Fry | QTS Inc.
Office: 650 604 1882 Mobile: 408 230 2715
M/S 269-1, Building N269/260-7
NASA Ames Research Center
Moffett Field, CA 94035-1000
I do not speak for QTS Inc., SGT, Code TI, or NASA, nor do they speak for me.
|
|
From: Catherine S. <Cat...@ti...> - 2015-07-29 17:21:18
|
I tried that and I got successful results! To be sure, I tried the test with the pressures meeting the StartCondition and then not meeting the StartCondition. The loops stops when the StartConditions are all met and keeps going if they are not, which is expected.
Was the redundancy between the ExitCondition and the RepeatCondition the root cause of my original issue?
Catherine
From: Fry, Charles R. {Chuck} (ARC-TI)[SGT, INC] [mailto:chu...@na...]
Sent: Wednesday, July 29, 2015 11:15 AM
To: Catherine Szeto
Cc: Fry, Charles R. {Chuck} (ARC-TI)[SGT, INC]; <ple...@li...>
Subject: Re: [plexil-support] Three near-identical StartConditions, only one is not working
Remove the ExitCondition on WaitingForCorrectPressureLevel and see what happens. It appears this redundant test is causing the loop to exit as soon as the last flag is assigned the value true.
-- Chuck
On Jul 29, 2015, at 7:53 AM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>>
wrote:
Chuck,
Since I couldn't figure out anything wrong with the distiller pressure node, I tried rearranging the three "Check...Pressure" nodes as brine, distiller, and product, versus the brine, product, and distiller. This time the product node was having issues exiting out. It seems to me that the loop is not correctly executing the third node, no matter which one it is. For easier testing, all three pressures are coded as "0" with the "scaledNomVacPressure" coded as "35".
I used the debug feature as you suggested. Below is what the console output was for one iteration. I highlighted the distiller pressure check in question. I've attached a screenshot of the Plexil viewer screen.
[Node:transition]Transitioning 'CheckBrinePressure' from WAITING to FINISHED at 1438124839.65869
[Node:outcome]Outcome of 'CheckBrinePressure' is SKIPPED
[Node:transition]Transitioning 'ASSIGNMENT__44' from FINISHED to INACTIVE at 1438124839.65869
[Node:transition]Transitioning 'PrintBrinePressure' from FINISHED to INACTIVE at 1438124839.65869
[Node:transition]Transitioning 'ASSIGNMENT__46' from FINISHED to INACTIVE at 1438124839.65869
[Node:transition]Transitioning 'PrintProductPressure' from FINISHED to INACTIVE at 1438124839.65869
[Node:transition]Transitioning 'ASSIGNMENT__48' from FINISHED to INACTIVE at 1438124839.65869
[Node:transition]Transitioning 'PrintDistillerPressure' from FINISHED to INACTIVE at 1438124839.65869
[Node:transition]Transitioning 'CheckProductPressure' from WAITING to FINISHED at 1438124839.65869
[Node:outcome]Outcome of 'CheckProductPressure' is SKIPPED
[Node:transition]Transitioning 'ASSIGNMENT__44' from INACTIVE to FINISHED at 1438124839.65869
[Node:outcome]Outcome of 'ASSIGNMENT__44' is SKIPPED
[Node:transition]Transitioning 'PrintBrinePressure' from INACTIVE to FINISHED at 1438124839.65869
[Node:outcome]Outcome of 'PrintBrinePressure' is SKIPPED
[Node:transition]Transitioning 'CheckDistillerPressure' from WAITING to EXECUTING at 1438124839.65869
[Node:transition]Transitioning 'ASSIGNMENT__46' from INACTIVE to FINISHED at 1438124839.65869
[Node:outcome]Outcome of 'ASSIGNMENT__46' is SKIPPED
[Node:transition]Transitioning 'PrintProductPressure' from INACTIVE to FINISHED at 1438124839.65869
[Node:outcome]Outcome of 'PrintProductPressure' is SKIPPED
[Node:transition]Transitioning 'ASSIGNMENT__48' from INACTIVE to WAITING at 1438124839.65869
[Node:transition]Transitioning 'PrintDistillerPressure' from INACTIVE to WAITING at 1438124839.65869
[Node:transition]Transitioning 'ASSIGNMENT__48' from WAITING to EXECUTING at 1438124839.65869
[Node:transition]Transitioning 'ASSIGNMENT__48' from EXECUTING to FAILING at 1438124839.65989
[Node:transition]Transitioning 'PrintDistillerPressure' from WAITING to FINISHED at 1438124839.65989
[Node:outcome]Outcome of 'PrintDistillerPressure' is SKIPPED
[Node:transition]Transitioning 'CheckDistillerPressure' from EXECUTING to FAILING at 1438124839.65989
[Node:transition]Transitioning 'WaitingForCorrectPressureLevel' from EXECUTING to FAILING at 1438124839.65989
[Node:transition]Transitioning 'ASSIGNMENT__48' from FAILING to FINISHED at 1438124839.65998
[Node:outcome]Outcome of 'ASSIGNMENT__48' is INTERRUPTED
[Node:transition]Transitioning 'CheckDistillerPressure' from FAILING to FINISHED at 1438124839.65998
[Node:outcome]Outcome of 'CheckDistillerPressure' is INTERRUPTED
[Node:transition]Transitioning 'WaitingForCorrectPressureLevel' from FAILING to ITERATION_ENDED at 1438124839.65998
Catherine
From: Fry, Charles R. {Chuck} (ARC-TI)[SGT, INC] [mailto:chu...@na...<http://nasa.gov>]
Sent: Tuesday, July 28, 2015 4:34 PM
To: Catherine Szeto
Cc: Fry, Charles R. {Chuck} (ARC-TI)[SGT, INC]; <ple...@li...<mailto:ple...@li...>>
Subject: Re: [plexil-support] Three near-identical StartConditions, only one is not working
I don't see any issues with the files you sent this time.
Are you familiar with Plexil's debug trace faciliity? Is this running in an environment where you can spill a lot of debug info to a "console" or log file?
If you can, I'd like to see the output from a run with the following debug configuration:
:Node:transition
:Node:outcome
:Node:failure
The text above should be placed in a file named 'Debug.cfg' in the working directory from which Plexil is launched.
If you can't do this, let me see if I can find another way to ferret out what's really happening.
-- Chuck
On Jul 28, 2015, at 6:13 AM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>> wrote:
Sorry about that. I attached a plan with a similar name. Attached are the correct files.
Yes, the pressures start high and go lower. I cannot figure out if I have any incorrect syntax either, but it's bizarre that the nodes for the other two pressures are working fine while the last one is not.
Catherine
From: Fry, Charles R. {Chuck} (ARC-TI)[SGT, INC] [mailto:chu...@na...<http://nasa.gov/>]
Sent: Monday, July 27, 2015 6:28 PM
To: Catherine Szeto
Cc: <ple...@li...<mailto:ple...@li...>>
Subject: Re: [plexil-support] Three near-identical StartConditions, only one is not working
Hi Catherine. The attached files don't contain the fragments you quote below. Are you paraphrasing or did you mean to send some other files?
I don't see anything in the quoted code that looks incorrect.
I presume all the pressures are starting high and trending lower?
-- Chuck
On Jul 27, 2015, at 2:56 PM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>> wrote:
Hello Plexil team,
I have this part in my code in the attached Plexil plan:
CheckDistillerPressure:
{
StartCondition Lookup(PressureCdsskmCdTank) <= scaledNomVacPressure;
SkipCondition distillerPressureCorrect || (Lookup(PressureCdsskmCdTank) > scaledNomVacPressure);
distillerPressureCorrect = true;
PrintDistillerPressure: { pprint("EVT: distiller", Lookup(PressureCdsskmCdTank), "." );}
}
The plan basically has two separate loops and the plan runs one of the loops depending on a "full" or "empty" parameter. Both the "full" and "empty" loops have an inner loop that keeps checking "product", "brine", and "distiller" pressures. The inner loop prints out a statement when each pressure has met the correct pressure, and then exits when all three have met the correct pressure. When I run the plan, the "brine" and "product" pressures have no issues. The node checking for distiller pressure (the one copied and pasted above) never starts. I did some simple debugging by having the "distiller" pressure continuously printed, and was able to verify that the distiller pressure, "Lookup(PressureCdsskmCdTank)", is reading the correct input and actually is meeting the correct pressure. I tried hard-coding the "scaledNomVacPressure" in the StartCondition to "35", which is the correct pressure threshold, but that didn't changed anything.
The nodes that check for the product, brine, and distiller pressures are virtually identical, so I cannot figure out why the distiller pressure is having trouble while the brine and product are not. I would appreciate any suggestions to look into. For context, this is the loop that checks for the pressures:
WaitingForCorrectPressureLevel:
{
ExitCondition ((Lookup(time,0.1) - StartTimer.EXECUTING.START) > Lookup(VacuumTimeoutINTL)) ||
(brinePressureCorrect && productPressureCorrect && distillerPressureCorrect);
RepeatCondition (Lookup(time,0.1) - StartTimer.EXECUTING.START) <= Lookup(VacuumTimeoutINTL) &&
(!brinePressureCorrect || !productPressureCorrect || !distillerPressureCorrect);
CheckBrinePressure:
{
StartCondition Lookup(PressureCdsskmBrineTank) <= scaledNomVacPressure;
SkipCondition brinePressureCorrect || (Lookup(PressureCdsskmBrineTank) > scaledNomVacPressure);
brinePressureCorrect = true;
PrintBrinePressure: { pprint("EVT: brine", Lookup(PressureCdsskmBrineTank), "." );}
}
CheckProductPressure:
{
StartCondition Lookup(PressureCdsskmProductTank) <= scaledNomVacPressure;
SkipCondition productPressureCorrect || (Lookup(PressureCdsskmProductTank) > scaledNomVacPressure);
productPressureCorrect = true;
PrintProductPressure: { pprint("EVT: product", Lookup(PressureCdsskmProductTank), "." );}
}
CheckDistillerPressure:
{
StartCondition Lookup(PressureCdsskmCdTank) <= scaledNomVacPressure;
SkipCondition distillerPressureCorrect || (Lookup(PressureCdsskmCdTank) > scaledNomVacPressure);
distillerPressureCorrect = true;
PrintDistillerPressure: { pprint("EVT: distiller", Lookup(PressureCdsskmCdTank), "." );}
}
} //end of WaitingForCorrectPressureLevel
} //end of ApplyVacuumToAll_Sequence_FullLoop
Thanks,
Catherine
<ApplyVacuumTo.ple><ApplyVacuumTo.plx>------------------------------------------------------------------------------
_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support
Chuck Fry | QTS Inc.
Office: 650 604 1882 Mobile: 408 230 2715
M/S 269-1, Building N269/260-7
NASA Ames Research Center
Moffett Field, CA 94035-1000
I do not speak for QTS Inc., SGT, Code TI, or NASA, nor do they speak for me.
<ApplyVacuumToAll.ple><ApplyVacuumToAll.plx>
Chuck Fry | QTS Inc.
Office: 650 604 1882 Mobile: 408 230 2715
M/S 269-1, Building N269/260-7
NASA Ames Research Center
Moffett Field, CA 94035-1000
I do not speak for QTS Inc., SGT, Code TI, or NASA, nor do they speak for me.
<Pressure check issue.PNG>
Chuck Fry | QTS Inc.
Office: 650 604 1882 Mobile: 408 230 2715
M/S 269-1, Building N269/260-7
NASA Ames Research Center
Moffett Field, CA 94035-1000
I do not speak for QTS Inc., SGT, Code TI, or NASA, nor do they speak for me.
|
|
From: Fry, C. R. {C. (ARC-TI)[S. INC] <chu...@na...> - 2015-07-29 16:15:01
|
Remove the ExitCondition on WaitingForCorrectPressureLevel and see what happens. It appears this redundant test is causing the loop to exit as soon as the last flag is assigned the value true.
-- Chuck
On Jul 29, 2015, at 7:53 AM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>>
wrote:
Chuck,
Since I couldn't figure out anything wrong with the distiller pressure node, I tried rearranging the three "Check...Pressure" nodes as brine, distiller, and product, versus the brine, product, and distiller. This time the product node was having issues exiting out. It seems to me that the loop is not correctly executing the third node, no matter which one it is. For easier testing, all three pressures are coded as "0" with the "scaledNomVacPressure" coded as "35".
I used the debug feature as you suggested. Below is what the console output was for one iteration. I highlighted the distiller pressure check in question. I've attached a screenshot of the Plexil viewer screen.
[Node:transition]Transitioning 'CheckBrinePressure' from WAITING to FINISHED at 1438124839.65869
[Node:outcome]Outcome of 'CheckBrinePressure' is SKIPPED
[Node:transition]Transitioning 'ASSIGNMENT__44' from FINISHED to INACTIVE at 1438124839.65869
[Node:transition]Transitioning 'PrintBrinePressure' from FINISHED to INACTIVE at 1438124839.65869
[Node:transition]Transitioning 'ASSIGNMENT__46' from FINISHED to INACTIVE at 1438124839.65869
[Node:transition]Transitioning 'PrintProductPressure' from FINISHED to INACTIVE at 1438124839.65869
[Node:transition]Transitioning 'ASSIGNMENT__48' from FINISHED to INACTIVE at 1438124839.65869
[Node:transition]Transitioning 'PrintDistillerPressure' from FINISHED to INACTIVE at 1438124839.65869
[Node:transition]Transitioning 'CheckProductPressure' from WAITING to FINISHED at 1438124839.65869
[Node:outcome]Outcome of 'CheckProductPressure' is SKIPPED
[Node:transition]Transitioning 'ASSIGNMENT__44' from INACTIVE to FINISHED at 1438124839.65869
[Node:outcome]Outcome of 'ASSIGNMENT__44' is SKIPPED
[Node:transition]Transitioning 'PrintBrinePressure' from INACTIVE to FINISHED at 1438124839.65869
[Node:outcome]Outcome of 'PrintBrinePressure' is SKIPPED
[Node:transition]Transitioning 'CheckDistillerPressure' from WAITING to EXECUTING at 1438124839.65869
[Node:transition]Transitioning 'ASSIGNMENT__46' from INACTIVE to FINISHED at 1438124839.65869
[Node:outcome]Outcome of 'ASSIGNMENT__46' is SKIPPED
[Node:transition]Transitioning 'PrintProductPressure' from INACTIVE to FINISHED at 1438124839.65869
[Node:outcome]Outcome of 'PrintProductPressure' is SKIPPED
[Node:transition]Transitioning 'ASSIGNMENT__48' from INACTIVE to WAITING at 1438124839.65869
[Node:transition]Transitioning 'PrintDistillerPressure' from INACTIVE to WAITING at 1438124839.65869
[Node:transition]Transitioning 'ASSIGNMENT__48' from WAITING to EXECUTING at 1438124839.65869
[Node:transition]Transitioning 'ASSIGNMENT__48' from EXECUTING to FAILING at 1438124839.65989
[Node:transition]Transitioning 'PrintDistillerPressure' from WAITING to FINISHED at 1438124839.65989
[Node:outcome]Outcome of 'PrintDistillerPressure' is SKIPPED
[Node:transition]Transitioning 'CheckDistillerPressure' from EXECUTING to FAILING at 1438124839.65989
[Node:transition]Transitioning 'WaitingForCorrectPressureLevel' from EXECUTING to FAILING at 1438124839.65989
[Node:transition]Transitioning 'ASSIGNMENT__48' from FAILING to FINISHED at 1438124839.65998
[Node:outcome]Outcome of 'ASSIGNMENT__48' is INTERRUPTED
[Node:transition]Transitioning 'CheckDistillerPressure' from FAILING to FINISHED at 1438124839.65998
[Node:outcome]Outcome of 'CheckDistillerPressure' is INTERRUPTED
[Node:transition]Transitioning 'WaitingForCorrectPressureLevel' from FAILING to ITERATION_ENDED at 1438124839.65998
Catherine
From: Fry, Charles R. {Chuck} (ARC-TI)[SGT, INC] [mailto:chu...@na...<http://nasa.gov>]
Sent: Tuesday, July 28, 2015 4:34 PM
To: Catherine Szeto
Cc: Fry, Charles R. {Chuck} (ARC-TI)[SGT, INC]; <ple...@li...<mailto:ple...@li...>>
Subject: Re: [plexil-support] Three near-identical StartConditions, only one is not working
I don't see any issues with the files you sent this time.
Are you familiar with Plexil's debug trace faciliity? Is this running in an environment where you can spill a lot of debug info to a "console" or log file?
If you can, I'd like to see the output from a run with the following debug configuration:
:Node:transition
:Node:outcome
:Node:failure
The text above should be placed in a file named 'Debug.cfg' in the working directory from which Plexil is launched.
If you can't do this, let me see if I can find another way to ferret out what's really happening.
-- Chuck
On Jul 28, 2015, at 6:13 AM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>> wrote:
Sorry about that. I attached a plan with a similar name. Attached are the correct files.
Yes, the pressures start high and go lower. I cannot figure out if I have any incorrect syntax either, but it's bizarre that the nodes for the other two pressures are working fine while the last one is not.
Catherine
From: Fry, Charles R. {Chuck} (ARC-TI)[SGT, INC] [mailto:chu...@na...<http://nasa.gov/>]
Sent: Monday, July 27, 2015 6:28 PM
To: Catherine Szeto
Cc: <ple...@li...<mailto:ple...@li...>>
Subject: Re: [plexil-support] Three near-identical StartConditions, only one is not working
Hi Catherine. The attached files don't contain the fragments you quote below. Are you paraphrasing or did you mean to send some other files?
I don't see anything in the quoted code that looks incorrect.
I presume all the pressures are starting high and trending lower?
-- Chuck
On Jul 27, 2015, at 2:56 PM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>> wrote:
Hello Plexil team,
I have this part in my code in the attached Plexil plan:
CheckDistillerPressure:
{
StartCondition Lookup(PressureCdsskmCdTank) <= scaledNomVacPressure;
SkipCondition distillerPressureCorrect || (Lookup(PressureCdsskmCdTank) > scaledNomVacPressure);
distillerPressureCorrect = true;
PrintDistillerPressure: { pprint("EVT: distiller", Lookup(PressureCdsskmCdTank), "." );}
}
The plan basically has two separate loops and the plan runs one of the loops depending on a “full” or “empty” parameter. Both the “full” and “empty” loops have an inner loop that keeps checking “product”, “brine”, and “distiller” pressures. The inner loop prints out a statement when each pressure has met the correct pressure, and then exits when all three have met the correct pressure. When I run the plan, the “brine” and “product” pressures have no issues. The node checking for distiller pressure (the one copied and pasted above) never starts. I did some simple debugging by having the “distiller” pressure continuously printed, and was able to verify that the distiller pressure, “Lookup(PressureCdsskmCdTank)”, is reading the correct input and actually is meeting the correct pressure. I tried hard-coding the “scaledNomVacPressure” in the StartCondition to “35”, which is the correct pressure threshold, but that didn’t changed anything.
The nodes that check for the product, brine, and distiller pressures are virtually identical, so I cannot figure out why the distiller pressure is having trouble while the brine and product are not. I would appreciate any suggestions to look into. For context, this is the loop that checks for the pressures:
WaitingForCorrectPressureLevel:
{
ExitCondition ((Lookup(time,0.1) - StartTimer.EXECUTING.START) > Lookup(VacuumTimeoutINTL)) ||
(brinePressureCorrect && productPressureCorrect && distillerPressureCorrect);
RepeatCondition (Lookup(time,0.1) - StartTimer.EXECUTING.START) <= Lookup(VacuumTimeoutINTL) &&
(!brinePressureCorrect || !productPressureCorrect || !distillerPressureCorrect);
CheckBrinePressure:
{
StartCondition Lookup(PressureCdsskmBrineTank) <= scaledNomVacPressure;
SkipCondition brinePressureCorrect || (Lookup(PressureCdsskmBrineTank) > scaledNomVacPressure);
brinePressureCorrect = true;
PrintBrinePressure: { pprint("EVT: brine", Lookup(PressureCdsskmBrineTank), "." );}
}
CheckProductPressure:
{
StartCondition Lookup(PressureCdsskmProductTank) <= scaledNomVacPressure;
SkipCondition productPressureCorrect || (Lookup(PressureCdsskmProductTank) > scaledNomVacPressure);
productPressureCorrect = true;
PrintProductPressure: { pprint("EVT: product", Lookup(PressureCdsskmProductTank), "." );}
}
CheckDistillerPressure:
{
StartCondition Lookup(PressureCdsskmCdTank) <= scaledNomVacPressure;
SkipCondition distillerPressureCorrect || (Lookup(PressureCdsskmCdTank) > scaledNomVacPressure);
distillerPressureCorrect = true;
PrintDistillerPressure: { pprint("EVT: distiller", Lookup(PressureCdsskmCdTank), "." );}
}
} //end of WaitingForCorrectPressureLevel
} //end of ApplyVacuumToAll_Sequence_FullLoop
Thanks,
Catherine
<ApplyVacuumTo.ple><ApplyVacuumTo.plx>------------------------------------------------------------------------------
_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support
Chuck Fry | QTS Inc.
Office: 650 604 1882 Mobile: 408 230 2715
M/S 269-1, Building N269/260-7
NASA Ames Research Center
Moffett Field, CA 94035-1000
I do not speak for QTS Inc., SGT, Code TI, or NASA, nor do they speak for me.
<ApplyVacuumToAll.ple><ApplyVacuumToAll.plx>
Chuck Fry | QTS Inc.
Office: 650 604 1882 Mobile: 408 230 2715
M/S 269-1, Building N269/260-7
NASA Ames Research Center
Moffett Field, CA 94035-1000
I do not speak for QTS Inc., SGT, Code TI, or NASA, nor do they speak for me.
<Pressure check issue.PNG>
Chuck Fry | QTS Inc.
Office: 650 604 1882 Mobile: 408 230 2715
M/S 269-1, Building N269/260-7
NASA Ames Research Center
Moffett Field, CA 94035-1000
I do not speak for QTS Inc., SGT, Code TI, or NASA, nor do they speak for me.
|
|
From: Catherine S. <Cat...@ti...> - 2015-07-29 14:54:08
|
Chuck,
Since I couldn't figure out anything wrong with the distiller pressure node, I tried rearranging the three "Check...Pressure" nodes as brine, distiller, and product, versus the brine, product, and distiller. This time the product node was having issues exiting out. It seems to me that the loop is not correctly executing the third node, no matter which one it is. For easier testing, all three pressures are coded as "0" with the "scaledNomVacPressure" coded as "35".
I used the debug feature as you suggested. Below is what the console output was for one iteration. I highlighted the distiller pressure check in question. I've attached a screenshot of the Plexil viewer screen.
[Node:transition]Transitioning 'CheckBrinePressure' from WAITING to FINISHED at 1438124839.65869
[Node:outcome]Outcome of 'CheckBrinePressure' is SKIPPED
[Node:transition]Transitioning 'ASSIGNMENT__44' from FINISHED to INACTIVE at 1438124839.65869
[Node:transition]Transitioning 'PrintBrinePressure' from FINISHED to INACTIVE at 1438124839.65869
[Node:transition]Transitioning 'ASSIGNMENT__46' from FINISHED to INACTIVE at 1438124839.65869
[Node:transition]Transitioning 'PrintProductPressure' from FINISHED to INACTIVE at 1438124839.65869
[Node:transition]Transitioning 'ASSIGNMENT__48' from FINISHED to INACTIVE at 1438124839.65869
[Node:transition]Transitioning 'PrintDistillerPressure' from FINISHED to INACTIVE at 1438124839.65869
[Node:transition]Transitioning 'CheckProductPressure' from WAITING to FINISHED at 1438124839.65869
[Node:outcome]Outcome of 'CheckProductPressure' is SKIPPED
[Node:transition]Transitioning 'ASSIGNMENT__44' from INACTIVE to FINISHED at 1438124839.65869
[Node:outcome]Outcome of 'ASSIGNMENT__44' is SKIPPED
[Node:transition]Transitioning 'PrintBrinePressure' from INACTIVE to FINISHED at 1438124839.65869
[Node:outcome]Outcome of 'PrintBrinePressure' is SKIPPED
[Node:transition]Transitioning 'CheckDistillerPressure' from WAITING to EXECUTING at 1438124839.65869
[Node:transition]Transitioning 'ASSIGNMENT__46' from INACTIVE to FINISHED at 1438124839.65869
[Node:outcome]Outcome of 'ASSIGNMENT__46' is SKIPPED
[Node:transition]Transitioning 'PrintProductPressure' from INACTIVE to FINISHED at 1438124839.65869
[Node:outcome]Outcome of 'PrintProductPressure' is SKIPPED
[Node:transition]Transitioning 'ASSIGNMENT__48' from INACTIVE to WAITING at 1438124839.65869
[Node:transition]Transitioning 'PrintDistillerPressure' from INACTIVE to WAITING at 1438124839.65869
[Node:transition]Transitioning 'ASSIGNMENT__48' from WAITING to EXECUTING at 1438124839.65869
[Node:transition]Transitioning 'ASSIGNMENT__48' from EXECUTING to FAILING at 1438124839.65989
[Node:transition]Transitioning 'PrintDistillerPressure' from WAITING to FINISHED at 1438124839.65989
[Node:outcome]Outcome of 'PrintDistillerPressure' is SKIPPED
[Node:transition]Transitioning 'CheckDistillerPressure' from EXECUTING to FAILING at 1438124839.65989
[Node:transition]Transitioning 'WaitingForCorrectPressureLevel' from EXECUTING to FAILING at 1438124839.65989
[Node:transition]Transitioning 'ASSIGNMENT__48' from FAILING to FINISHED at 1438124839.65998
[Node:outcome]Outcome of 'ASSIGNMENT__48' is INTERRUPTED
[Node:transition]Transitioning 'CheckDistillerPressure' from FAILING to FINISHED at 1438124839.65998
[Node:outcome]Outcome of 'CheckDistillerPressure' is INTERRUPTED
[Node:transition]Transitioning 'WaitingForCorrectPressureLevel' from FAILING to ITERATION_ENDED at 1438124839.65998
Catherine
From: Fry, Charles R. {Chuck} (ARC-TI)[SGT, INC] [mailto:chu...@na...]
Sent: Tuesday, July 28, 2015 4:34 PM
To: Catherine Szeto
Cc: Fry, Charles R. {Chuck} (ARC-TI)[SGT, INC]; <ple...@li...>
Subject: Re: [plexil-support] Three near-identical StartConditions, only one is not working
I don't see any issues with the files you sent this time.
Are you familiar with Plexil's debug trace faciliity? Is this running in an environment where you can spill a lot of debug info to a "console" or log file?
If you can, I'd like to see the output from a run with the following debug configuration:
:Node:transition
:Node:outcome
:Node:failure
The text above should be placed in a file named 'Debug.cfg' in the working directory from which Plexil is launched.
If you can't do this, let me see if I can find another way to ferret out what's really happening.
-- Chuck
On Jul 28, 2015, at 6:13 AM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>> wrote:
Sorry about that. I attached a plan with a similar name. Attached are the correct files.
Yes, the pressures start high and go lower. I cannot figure out if I have any incorrect syntax either, but it's bizarre that the nodes for the other two pressures are working fine while the last one is not.
Catherine
From: Fry, Charles R. {Chuck} (ARC-TI)[SGT, INC] [mailto:chu...@na...<http://nasa.gov/>]
Sent: Monday, July 27, 2015 6:28 PM
To: Catherine Szeto
Cc: <ple...@li...<mailto:ple...@li...>>
Subject: Re: [plexil-support] Three near-identical StartConditions, only one is not working
Hi Catherine. The attached files don't contain the fragments you quote below. Are you paraphrasing or did you mean to send some other files?
I don't see anything in the quoted code that looks incorrect.
I presume all the pressures are starting high and trending lower?
-- Chuck
On Jul 27, 2015, at 2:56 PM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>> wrote:
Hello Plexil team,
I have this part in my code in the attached Plexil plan:
CheckDistillerPressure:
{
StartCondition Lookup(PressureCdsskmCdTank) <= scaledNomVacPressure;
SkipCondition distillerPressureCorrect || (Lookup(PressureCdsskmCdTank) > scaledNomVacPressure);
distillerPressureCorrect = true;
PrintDistillerPressure: { pprint("EVT: distiller", Lookup(PressureCdsskmCdTank), "." );}
}
The plan basically has two separate loops and the plan runs one of the loops depending on a "full" or "empty" parameter. Both the "full" and "empty" loops have an inner loop that keeps checking "product", "brine", and "distiller" pressures. The inner loop prints out a statement when each pressure has met the correct pressure, and then exits when all three have met the correct pressure. When I run the plan, the "brine" and "product" pressures have no issues. The node checking for distiller pressure (the one copied and pasted above) never starts. I did some simple debugging by having the "distiller" pressure continuously printed, and was able to verify that the distiller pressure, "Lookup(PressureCdsskmCdTank)", is reading the correct input and actually is meeting the correct pressure. I tried hard-coding the "scaledNomVacPressure" in the StartCondition to "35", which is the correct pressure threshold, but that didn't changed anything.
The nodes that check for the product, brine, and distiller pressures are virtually identical, so I cannot figure out why the distiller pressure is having trouble while the brine and product are not. I would appreciate any suggestions to look into. For context, this is the loop that checks for the pressures:
WaitingForCorrectPressureLevel:
{
ExitCondition ((Lookup(time,0.1) - StartTimer.EXECUTING.START) > Lookup(VacuumTimeoutINTL)) ||
(brinePressureCorrect && productPressureCorrect && distillerPressureCorrect);
RepeatCondition (Lookup(time,0.1) - StartTimer.EXECUTING.START) <= Lookup(VacuumTimeoutINTL) &&
(!brinePressureCorrect || !productPressureCorrect || !distillerPressureCorrect);
CheckBrinePressure:
{
StartCondition Lookup(PressureCdsskmBrineTank) <= scaledNomVacPressure;
SkipCondition brinePressureCorrect || (Lookup(PressureCdsskmBrineTank) > scaledNomVacPressure);
brinePressureCorrect = true;
PrintBrinePressure: { pprint("EVT: brine", Lookup(PressureCdsskmBrineTank), "." );}
}
CheckProductPressure:
{
StartCondition Lookup(PressureCdsskmProductTank) <= scaledNomVacPressure;
SkipCondition productPressureCorrect || (Lookup(PressureCdsskmProductTank) > scaledNomVacPressure);
productPressureCorrect = true;
PrintProductPressure: { pprint("EVT: product", Lookup(PressureCdsskmProductTank), "." );}
}
CheckDistillerPressure:
{
StartCondition Lookup(PressureCdsskmCdTank) <= scaledNomVacPressure;
SkipCondition distillerPressureCorrect || (Lookup(PressureCdsskmCdTank) > scaledNomVacPressure);
distillerPressureCorrect = true;
PrintDistillerPressure: { pprint("EVT: distiller", Lookup(PressureCdsskmCdTank), "." );}
}
} //end of WaitingForCorrectPressureLevel
} //end of ApplyVacuumToAll_Sequence_FullLoop
Thanks,
Catherine
<ApplyVacuumTo.ple><ApplyVacuumTo.plx>------------------------------------------------------------------------------
_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support
Chuck Fry | QTS Inc.
Office: 650 604 1882 Mobile: 408 230 2715
M/S 269-1, Building N269/260-7
NASA Ames Research Center
Moffett Field, CA 94035-1000
I do not speak for QTS Inc., SGT, Code TI, or NASA, nor do they speak for me.
<ApplyVacuumToAll.ple><ApplyVacuumToAll.plx>
Chuck Fry | QTS Inc.
Office: 650 604 1882 Mobile: 408 230 2715
M/S 269-1, Building N269/260-7
NASA Ames Research Center
Moffett Field, CA 94035-1000
I do not speak for QTS Inc., SGT, Code TI, or NASA, nor do they speak for me.
|
|
From: Fry, C. R. {C. (ARC-TI)[S. INC] <chu...@na...> - 2015-07-28 21:33:41
|
I don't see any issues with the files you sent this time.
Are you familiar with Plexil's debug trace faciliity? Is this running in an environment where you can spill a lot of debug info to a "console" or log file?
If you can, I'd like to see the output from a run with the following debug configuration:
:Node:transition
:Node:outcome
:Node:failure
The text above should be placed in a file named 'Debug.cfg' in the working directory from which Plexil is launched.
If you can't do this, let me see if I can find another way to ferret out what's really happening.
-- Chuck
On Jul 28, 2015, at 6:13 AM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>> wrote:
Sorry about that. I attached a plan with a similar name. Attached are the correct files.
Yes, the pressures start high and go lower. I cannot figure out if I have any incorrect syntax either, but it's bizarre that the nodes for the other two pressures are working fine while the last one is not.
Catherine
From: Fry, Charles R. {Chuck} (ARC-TI)[SGT, INC] [mailto:chu...@na...<http://nasa.gov/>]
Sent: Monday, July 27, 2015 6:28 PM
To: Catherine Szeto
Cc: <ple...@li...<mailto:ple...@li...>>
Subject: Re: [plexil-support] Three near-identical StartConditions, only one is not working
Hi Catherine. The attached files don't contain the fragments you quote below. Are you paraphrasing or did you mean to send some other files?
I don't see anything in the quoted code that looks incorrect.
I presume all the pressures are starting high and trending lower?
-- Chuck
On Jul 27, 2015, at 2:56 PM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>> wrote:
Hello Plexil team,
I have this part in my code in the attached Plexil plan:
CheckDistillerPressure:
{
StartCondition Lookup(PressureCdsskmCdTank) <= scaledNomVacPressure;
SkipCondition distillerPressureCorrect || (Lookup(PressureCdsskmCdTank) > scaledNomVacPressure);
distillerPressureCorrect = true;
PrintDistillerPressure: { pprint("EVT: distiller", Lookup(PressureCdsskmCdTank), "." );}
}
The plan basically has two separate loops and the plan runs one of the loops depending on a “full” or “empty” parameter. Both the “full” and “empty” loops have an inner loop that keeps checking “product”, “brine”, and “distiller” pressures. The inner loop prints out a statement when each pressure has met the correct pressure, and then exits when all three have met the correct pressure. When I run the plan, the “brine” and “product” pressures have no issues. The node checking for distiller pressure (the one copied and pasted above) never starts. I did some simple debugging by having the “distiller” pressure continuously printed, and was able to verify that the distiller pressure, “Lookup(PressureCdsskmCdTank)”, is reading the correct input and actually is meeting the correct pressure. I tried hard-coding the “scaledNomVacPressure” in the StartCondition to “35”, which is the correct pressure threshold, but that didn’t changed anything.
The nodes that check for the product, brine, and distiller pressures are virtually identical, so I cannot figure out why the distiller pressure is having trouble while the brine and product are not. I would appreciate any suggestions to look into. For context, this is the loop that checks for the pressures:
WaitingForCorrectPressureLevel:
{
ExitCondition ((Lookup(time,0.1) - StartTimer.EXECUTING.START) > Lookup(VacuumTimeoutINTL)) ||
(brinePressureCorrect && productPressureCorrect && distillerPressureCorrect);
RepeatCondition (Lookup(time,0.1) - StartTimer.EXECUTING.START) <= Lookup(VacuumTimeoutINTL) &&
(!brinePressureCorrect || !productPressureCorrect || !distillerPressureCorrect);
CheckBrinePressure:
{
StartCondition Lookup(PressureCdsskmBrineTank) <= scaledNomVacPressure;
SkipCondition brinePressureCorrect || (Lookup(PressureCdsskmBrineTank) > scaledNomVacPressure);
brinePressureCorrect = true;
PrintBrinePressure: { pprint("EVT: brine", Lookup(PressureCdsskmBrineTank), "." );}
}
CheckProductPressure:
{
StartCondition Lookup(PressureCdsskmProductTank) <= scaledNomVacPressure;
SkipCondition productPressureCorrect || (Lookup(PressureCdsskmProductTank) > scaledNomVacPressure);
productPressureCorrect = true;
PrintProductPressure: { pprint("EVT: product", Lookup(PressureCdsskmProductTank), "." );}
}
CheckDistillerPressure:
{
StartCondition Lookup(PressureCdsskmCdTank) <= scaledNomVacPressure;
SkipCondition distillerPressureCorrect || (Lookup(PressureCdsskmCdTank) > scaledNomVacPressure);
distillerPressureCorrect = true;
PrintDistillerPressure: { pprint("EVT: distiller", Lookup(PressureCdsskmCdTank), "." );}
}
} //end of WaitingForCorrectPressureLevel
} //end of ApplyVacuumToAll_Sequence_FullLoop
Thanks,
Catherine
<ApplyVacuumTo.ple><ApplyVacuumTo.plx>------------------------------------------------------------------------------
_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support
Chuck Fry | QTS Inc.
Office: 650 604 1882 Mobile: 408 230 2715
M/S 269-1, Building N269/260-7
NASA Ames Research Center
Moffett Field, CA 94035-1000
I do not speak for QTS Inc., SGT, Code TI, or NASA, nor do they speak for me.
<ApplyVacuumToAll.ple><ApplyVacuumToAll.plx>
Chuck Fry | QTS Inc.
Office: 650 604 1882 Mobile: 408 230 2715
M/S 269-1, Building N269/260-7
NASA Ames Research Center
Moffett Field, CA 94035-1000
I do not speak for QTS Inc., SGT, Code TI, or NASA, nor do they speak for me.
|
|
From: Catherine S. <Cat...@ti...> - 2015-07-28 13:14:03
|
Sorry about that. I attached a plan with a similar name. Attached are the correct files.
Yes, the pressures start high and go lower. I cannot figure out if I have any incorrect syntax either, but it's bizarre that the nodes for the other two pressures are working fine while the last one is not.
Catherine
From: Fry, Charles R. {Chuck} (ARC-TI)[SGT, INC] [mailto:chu...@na...]
Sent: Monday, July 27, 2015 6:28 PM
To: Catherine Szeto
Cc: <ple...@li...>
Subject: Re: [plexil-support] Three near-identical StartConditions, only one is not working
Hi Catherine. The attached files don't contain the fragments you quote below. Are you paraphrasing or did you mean to send some other files?
I don't see anything in the quoted code that looks incorrect.
I presume all the pressures are starting high and trending lower?
-- Chuck
On Jul 27, 2015, at 2:56 PM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>> wrote:
Hello Plexil team,
I have this part in my code in the attached Plexil plan:
CheckDistillerPressure:
{
StartCondition Lookup(PressureCdsskmCdTank) <= scaledNomVacPressure;
SkipCondition distillerPressureCorrect || (Lookup(PressureCdsskmCdTank) > scaledNomVacPressure);
distillerPressureCorrect = true;
PrintDistillerPressure: { pprint("EVT: distiller", Lookup(PressureCdsskmCdTank), "." );}
}
The plan basically has two separate loops and the plan runs one of the loops depending on a "full" or "empty" parameter. Both the "full" and "empty" loops have an inner loop that keeps checking "product", "brine", and "distiller" pressures. The inner loop prints out a statement when each pressure has met the correct pressure, and then exits when all three have met the correct pressure. When I run the plan, the "brine" and "product" pressures have no issues. The node checking for distiller pressure (the one copied and pasted above) never starts. I did some simple debugging by having the "distiller" pressure continuously printed, and was able to verify that the distiller pressure, "Lookup(PressureCdsskmCdTank)", is reading the correct input and actually is meeting the correct pressure. I tried hard-coding the "scaledNomVacPressure" in the StartCondition to "35", which is the correct pressure threshold, but that didn't changed anything.
The nodes that check for the product, brine, and distiller pressures are virtually identical, so I cannot figure out why the distiller pressure is having trouble while the brine and product are not. I would appreciate any suggestions to look into. For context, this is the loop that checks for the pressures:
WaitingForCorrectPressureLevel:
{
ExitCondition ((Lookup(time,0.1) - StartTimer.EXECUTING.START) > Lookup(VacuumTimeoutINTL)) ||
(brinePressureCorrect && productPressureCorrect && distillerPressureCorrect);
RepeatCondition (Lookup(time,0.1) - StartTimer.EXECUTING.START) <= Lookup(VacuumTimeoutINTL) &&
(!brinePressureCorrect || !productPressureCorrect || !distillerPressureCorrect);
CheckBrinePressure:
{
StartCondition Lookup(PressureCdsskmBrineTank) <= scaledNomVacPressure;
SkipCondition brinePressureCorrect || (Lookup(PressureCdsskmBrineTank) > scaledNomVacPressure);
brinePressureCorrect = true;
PrintBrinePressure: { pprint("EVT: brine", Lookup(PressureCdsskmBrineTank), "." );}
}
CheckProductPressure:
{
StartCondition Lookup(PressureCdsskmProductTank) <= scaledNomVacPressure;
SkipCondition productPressureCorrect || (Lookup(PressureCdsskmProductTank) > scaledNomVacPressure);
productPressureCorrect = true;
PrintProductPressure: { pprint("EVT: product", Lookup(PressureCdsskmProductTank), "." );}
}
CheckDistillerPressure:
{
StartCondition Lookup(PressureCdsskmCdTank) <= scaledNomVacPressure;
SkipCondition distillerPressureCorrect || (Lookup(PressureCdsskmCdTank) > scaledNomVacPressure);
distillerPressureCorrect = true;
PrintDistillerPressure: { pprint("EVT: distiller", Lookup(PressureCdsskmCdTank), "." );}
}
} //end of WaitingForCorrectPressureLevel
} //end of ApplyVacuumToAll_Sequence_FullLoop
Thanks,
Catherine
<ApplyVacuumTo.ple><ApplyVacuumTo.plx>------------------------------------------------------------------------------
_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support
Chuck Fry | QTS Inc.
Office: 650 604 1882 Mobile: 408 230 2715
M/S 269-1, Building N269/260-7
NASA Ames Research Center
Moffett Field, CA 94035-1000
I do not speak for QTS Inc., SGT, Code TI, or NASA, nor do they speak for me.
|
|
From: Fry, C. R. {C. (ARC-TI)[S. INC] <chu...@na...> - 2015-07-27 23:28:04
|
Hi Catherine. The attached files don't contain the fragments you quote below. Are you paraphrasing or did you mean to send some other files?
I don't see anything in the quoted code that looks incorrect.
I presume all the pressures are starting high and trending lower?
-- Chuck
On Jul 27, 2015, at 2:56 PM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>> wrote:
Hello Plexil team,
I have this part in my code in the attached Plexil plan:
CheckDistillerPressure:
{
StartCondition Lookup(PressureCdsskmCdTank) <= scaledNomVacPressure;
SkipCondition distillerPressureCorrect || (Lookup(PressureCdsskmCdTank) > scaledNomVacPressure);
distillerPressureCorrect = true;
PrintDistillerPressure: { pprint("EVT: distiller", Lookup(PressureCdsskmCdTank), "." );}
}
The plan basically has two separate loops and the plan runs one of the loops depending on a “full” or “empty” parameter. Both the “full” and “empty” loops have an inner loop that keeps checking “product”, “brine”, and “distiller” pressures. The inner loop prints out a statement when each pressure has met the correct pressure, and then exits when all three have met the correct pressure. When I run the plan, the “brine” and “product” pressures have no issues. The node checking for distiller pressure (the one copied and pasted above) never starts. I did some simple debugging by having the “distiller” pressure continuously printed, and was able to verify that the distiller pressure, “Lookup(PressureCdsskmCdTank)”, is reading the correct input and actually is meeting the correct pressure. I tried hard-coding the “scaledNomVacPressure” in the StartCondition to “35”, which is the correct pressure threshold, but that didn’t changed anything.
The nodes that check for the product, brine, and distiller pressures are virtually identical, so I cannot figure out why the distiller pressure is having trouble while the brine and product are not. I would appreciate any suggestions to look into. For context, this is the loop that checks for the pressures:
WaitingForCorrectPressureLevel:
{
ExitCondition ((Lookup(time,0.1) - StartTimer.EXECUTING.START) > Lookup(VacuumTimeoutINTL)) ||
(brinePressureCorrect && productPressureCorrect && distillerPressureCorrect);
RepeatCondition (Lookup(time,0.1) - StartTimer.EXECUTING.START) <= Lookup(VacuumTimeoutINTL) &&
(!brinePressureCorrect || !productPressureCorrect || !distillerPressureCorrect);
CheckBrinePressure:
{
StartCondition Lookup(PressureCdsskmBrineTank) <= scaledNomVacPressure;
SkipCondition brinePressureCorrect || (Lookup(PressureCdsskmBrineTank) > scaledNomVacPressure);
brinePressureCorrect = true;
PrintBrinePressure: { pprint("EVT: brine", Lookup(PressureCdsskmBrineTank), "." );}
}
CheckProductPressure:
{
StartCondition Lookup(PressureCdsskmProductTank) <= scaledNomVacPressure;
SkipCondition productPressureCorrect || (Lookup(PressureCdsskmProductTank) > scaledNomVacPressure);
productPressureCorrect = true;
PrintProductPressure: { pprint("EVT: product", Lookup(PressureCdsskmProductTank), "." );}
}
CheckDistillerPressure:
{
StartCondition Lookup(PressureCdsskmCdTank) <= scaledNomVacPressure;
SkipCondition distillerPressureCorrect || (Lookup(PressureCdsskmCdTank) > scaledNomVacPressure);
distillerPressureCorrect = true;
PrintDistillerPressure: { pprint("EVT: distiller", Lookup(PressureCdsskmCdTank), "." );}
}
} //end of WaitingForCorrectPressureLevel
} //end of ApplyVacuumToAll_Sequence_FullLoop
Thanks,
Catherine
<ApplyVacuumTo.ple><ApplyVacuumTo.plx>------------------------------------------------------------------------------
_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support
Chuck Fry | QTS Inc.
Office: 650 604 1882 Mobile: 408 230 2715
M/S 269-1, Building N269/260-7
NASA Ames Research Center
Moffett Field, CA 94035-1000
I do not speak for QTS Inc., SGT, Code TI, or NASA, nor do they speak for me.
|
|
From: Catherine S. <Cat...@ti...> - 2015-07-27 22:09:29
|
Hello Plexil team,
I have this part in my code in the attached Plexil plan:
CheckDistillerPressure:
{
StartCondition Lookup(PressureCdsskmCdTank) <= scaledNomVacPressure;
SkipCondition distillerPressureCorrect || (Lookup(PressureCdsskmCdTank) > scaledNomVacPressure);
distillerPressureCorrect = true;
PrintDistillerPressure: { pprint("EVT: distiller", Lookup(PressureCdsskmCdTank), "." );}
}
The plan basically has two separate loops and the plan runs one of the loops depending on a "full" or "empty" parameter. Both the "full" and "empty" loops have an inner loop that keeps checking "product", "brine", and "distiller" pressures. The inner loop prints out a statement when each pressure has met the correct pressure, and then exits when all three have met the correct pressure. When I run the plan, the "brine" and "product" pressures have no issues. The node checking for distiller pressure (the one copied and pasted above) never starts. I did some simple debugging by having the "distiller" pressure continuously printed, and was able to verify that the distiller pressure, "Lookup(PressureCdsskmCdTank)", is reading the correct input and actually is meeting the correct pressure. I tried hard-coding the "scaledNomVacPressure" in the StartCondition to "35", which is the correct pressure threshold, but that didn't changed anything.
The nodes that check for the product, brine, and distiller pressures are virtually identical, so I cannot figure out why the distiller pressure is having trouble while the brine and product are not. I would appreciate any suggestions to look into. For context, this is the loop that checks for the pressures:
WaitingForCorrectPressureLevel:
{
ExitCondition ((Lookup(time,0.1) - StartTimer.EXECUTING.START) > Lookup(VacuumTimeoutINTL)) ||
(brinePressureCorrect && productPressureCorrect && distillerPressureCorrect);
RepeatCondition (Lookup(time,0.1) - StartTimer.EXECUTING.START) <= Lookup(VacuumTimeoutINTL) &&
(!brinePressureCorrect || !productPressureCorrect || !distillerPressureCorrect);
CheckBrinePressure:
{
StartCondition Lookup(PressureCdsskmBrineTank) <= scaledNomVacPressure;
SkipCondition brinePressureCorrect || (Lookup(PressureCdsskmBrineTank) > scaledNomVacPressure);
brinePressureCorrect = true;
PrintBrinePressure: { pprint("EVT: brine", Lookup(PressureCdsskmBrineTank), "." );}
}
CheckProductPressure:
{
StartCondition Lookup(PressureCdsskmProductTank) <= scaledNomVacPressure;
SkipCondition productPressureCorrect || (Lookup(PressureCdsskmProductTank) > scaledNomVacPressure);
productPressureCorrect = true;
PrintProductPressure: { pprint("EVT: product", Lookup(PressureCdsskmProductTank), "." );}
}
CheckDistillerPressure:
{
StartCondition Lookup(PressureCdsskmCdTank) <= scaledNomVacPressure;
SkipCondition distillerPressureCorrect || (Lookup(PressureCdsskmCdTank) > scaledNomVacPressure);
distillerPressureCorrect = true;
PrintDistillerPressure: { pprint("EVT: distiller", Lookup(PressureCdsskmCdTank), "." );}
}
} //end of WaitingForCorrectPressureLevel
} //end of ApplyVacuumToAll_Sequence_FullLoop
Thanks,
Catherine
|
|
From: Fry, C. R. {C. (ARC-TI)[S. INC] <chu...@na...> - 2015-07-22 17:42:26
|
[Resending in hopes that SF mail lists are alive again - no changes in content] [Added back plexil-support to share your comments with others on the team] Hello Héctor. Thanks for the feedback on compiler flags. IPC is not very actively maintained by its creators. I'll merge your fix into our version. The PLEXIL website issues are probably problems within Sourceforge. I tried to look at the website and got an error page: The sourceforge.net website is temporarily in static offline mode. Only a very limited set of project pages are available until the main website returns to service. The issues you report suggest that SF temporarily restored an older backup of the site. I have noticed that the default download link SF shows you depends on the platform you are using. 4.0.1 is supposed to be current for OS X, Linux, and FreeBSD. When the site is back up, I will try to figure out why you got an obsolete download link. You should always be able to go into the Files section of the site to find the latest. And of course read-only anonymous SVN access is available. The PLEXIL language itself has not changed very much, other than adding some Real to Integer conversions, and the SF website should be current - when it is accessible. I will take another look later when the site is available. -- Chuck On Jul 17, 2015, at 8:39 AM, Hector Fabio Cadavid Rengifo <hec...@gm...> wrote: > Dear Chuck, > > Excuse me for the late reply!, and yes, I’m still in touch with Cesar, but only by sporadic email interchanges. > > Thank you for your clarification about the dynamic libraries. Now I’m working in a library that get/write information from a Intel Galileo’s GPIO (which is connected to a real robot micro-controller and a bunch of sensors). > I don’t know if it could be useful for your documentation, but I had to change a compilation flag in order to be able to compile Plexil in Linux Yocto (the official distribution for the Galileo board): -"mtune=i486" instead of “-m486” (this is used in the ‘ipc’ target). > > Just a couple of questions… do you know why the last Plexil version (4.0.1) was removed from Sourceforge website (it shows 2.5 as the latest one) ?, on the other hand, do you know where could I get an updated reference of the Plexil language?, unfortunately Sourceforge’s link seems to be also broken... > > > As always, thank you so much for your support, > > sincerely yours, > Héctor > > > > On Jun 23, 2015, at 4:55 PM, Fry, Charles R. {Chuck} (ARC-TI)[SGT, INC] <chu...@na...> wrote: > >> I remember you, Héctor. I'm happy to see you are still working with PLEXIL. Are you still in touch with Cesar? >> >> The convention for naming libraries is simple. If you have an adapter or listener named "MyRobot", the dynamic library would be named "libMyRobot.so'' (or .dylib on Mac), and the library initialization routine is called "initMyRobot". >> >> Of course the directory containing the dynamic libraries must be on the library path: LD_LIBRARY_PATH for Linux and Unix, DYLD_LIBRARY_PATH on Mac. >> >> The library initialization routine must register the adapter (or listener). Typical examples are in src/interfaces/IpcAdapter/initIpcAdapter.cc and src/interfaces/GanttListener/GanttListener.cc . >> >> This is not new, but much about PLEXIL 4 is new, and I would appreciate your comments on the documentation. We are always happy to see new applications. >> >> -- Chuck >> >> On Jun 23, 2015, at 2:20 PM, Hector Fabio Cadavid Rengifo <hec...@gm...> wrote: >> >>> Dear Chuck, >>> >>> Thank you so much for your advice, I have been ‘playing' with the examples and plexil’s interfacing is way clearer to me now!, >>> >>> However, I still have a question… as far I understand, in order to link the execution of a Plexil plan with a certain interface (defined in a dynamic library), a configuration file is required (interface-config.xml by default). However, after looking such file content, I can’t figure how the dynamic library is linked to such configuration. So, I would like to know, are there any naming conventions for dynamic libraries in order to make them work with a Plexil plan? >>> >>> By the way, it is a nice surprise to receive the reply of my message from you. I don’t know if you remember me, but few years ago I was involved with a Plexil-related research project with NIA, under the supervision of Cesar Muñoz, and back then we exchanged a couple of emails … >>> >>> Now I’m working (from Colombia) in a robotic prototype for "precision agriculture”, and we want to use Plexil and the executive as the processing core, so I would really appreciate if you can help us with your advice (about this technology) in the future. In the same way, we hope being able to share with you our progress with the project soon! >>> >>> >>> Sincerely yours, >>> >>> Héctor Cadavid >>> >>> >>> >>> >>> >>> On Jun 19, 2015, at 5:49 PM, Fry, Charles R. {Chuck} (ARC-TI)[SGT, INC] <chu...@na...> wrote: >>> >>>> Hello Héctor. We are aware that the UDP adapter has a number of shortcomings. Another project here at Ames is using it for interfacing to other hardware, and has pointed out several possible improvements. >>>> >>>> There are simple examples of custom interface adapters in the sample-app and sample-app1 example directories. >>>> >>>> You could implement a socket-based adapter, but of course some C++ code will be necessary to integrate it. >>>> >>>> Please feel free to contact me if you have any other questions. >>>> >>>> -- Chuck >>>> >>>> On Jun 19, 2015, at 3:18 PM, Hector Fabio Cadavid Rengifo <hec...@gm...> wrote: >>>> >>>>> Dear support team, >>>>> >>>>> My name is Héctor, and I’m involved in a robotics project. We are interested in using Plexil as the core language for the specification of robot’s tasks, but a little advice is required... >>>>> >>>>> We already have configured the universal executive in the robot’s controller hardware (an intel galileo board) and everything is working well, but now I’m looking for a way to integrate such executive with robot’s sensing devices and actuators (gears, servomotors, etc). I was able to perform the integration through the UDP adapter, but as far I understand this intended only for interoperability between executives, not for interfacing with external systems. >>>>> >>>>> Now I’m looking for a way to integrate ‘lookupOn’/‘lookUpOnChange’ events with information provided by a micro controller trough a serial port. The official documentation (http://plexil.sourceforge.net/wiki/index.php/Advanced_PLEXIL_Interfacing#Construction) states that we have to create a C++ shared library that implements the ‘InterfaceAdapter’ in order to enable an interface with external systems. I understand the idea, but, could you please provide us a sample implementation of a custom InterfaceAdapter, and an example of how to integrate the generated dynamic library in the <Interfaces> configuration file?… If there is already an example in the distribution, I would appreciate if you indicate me where it is located... >>>>> >>>>> Just for curiosity, could it be possible to use a a socket-based adapter -as an alternative to the C++ adapters- in order to achieve the same interfacing scenario? (in this case, I would implement a socket server that ‘talk’ directly with the hardware according with the received events). >>>>> >>>>> >>>>> Sincerely yours, >>>>> >>>>> Héctor >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> _______________________________________________ >>>>> plexil-support mailing list >>>>> ple...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/plexil-support >>>> >>>> Chuck Fry | QTS Inc. >>>> Office: 650 604 1882 Mobile: 408 230 2715 >>>> M/S 269-1, Building N269/260-7 >>>> NASA Ames Research Center >>>> Moffett Field, CA 94035-1000 >>>> >>>> I do not speak for QTS Inc., SGT, Code TI, or NASA, nor do they speak for me. >>>> >>>> >>>> >>> >> >> Chuck Fry | QTS Inc. >> Office: 650 604 1882 Mobile: 408 230 2715 >> M/S 269-1, Building N269/260-7 >> NASA Ames Research Center >> Moffett Field, CA 94035-1000 >> >> I do not speak for QTS Inc., SGT, Code TI, or NASA, nor do they speak for me. >> >> >> > Chuck Fry | QTS Inc. Office: 650 604 1882 Mobile: 408 230 2715 M/S 269-1, Building N269/260-7 NASA Ames Research Center Moffett Field, CA 94035-1000 I do not speak for QTS Inc., SGT, Code TI, or NASA, nor do they speak for me. |
|
From: Pablo M. <pm...@au...> - 2015-07-14 12:40:07
|
Dear Chuck,
Finally we found the problem. The problem was when in MyAdapter we
execute a command that calls to fork()+exec(cmd) in an external library.
After that moment we have two UniversalExec processes and, as a
consequence, the mentioned problems.
We solve the problem simply changing the fork()+exec(cmd) to system(cmd).
Thanks for your attention and great work,
Pablo
On 13/07/15 19:42, Fry, Charles R. {Chuck} (ARC-TI)[SGT, INC] wrote:
> Hello, and my apologies for the delayed response. Please use
> ple...@li...
> <mailto:ple...@li...> for help requests and
> trouble reports.
>
> You have not given me enough information to identify the problem. Can
> you send your adapter code (specifically the executeCommand() method)
> and the plan you used to generate the output below? Thank you.
>
> -- Chuck
>
> On Jul 10, 2015, at 10:05 AM, Pablo Muñoz <pm...@au...
> <mailto:pm...@au...>> wrote:
>
>> Dear PLEXIL support,
>>
>> I'm developing a robotic application with PLEXIL and UE and I have a
>> problem with the InterfaceAdapters created to control the robotic
>> platform. Please notice that I'm using version 2.5 (for compatibility
>> reasons).
>>
>> I have an adapter (let call it MyAdapter) that, as a result of a
>> particular ExecuteCommand call from the executive, creates a thread.
>> This thread implements a telecommand system by means of a TCP
>> connection that is working fine. The problem is the following:
>> MyAdapter has an attribute (boolean, int, whatever), which is shared
>> and, sometimes, modified by the thread. I can see that the attribute
>> is effectively modified in the thread, however, when the executive
>> invokes the ExecuteCommand on MyAdapter, the attribute has the
>> initial value, like if the thread hasn't perform any modification.
>>
>> Anyway, in MyAdapter I have other attributes that seems to be shared
>> between the thread and the ExecuteCommand function, but not
>> correctly. I perform a test sharing an integer (starting from 8) that
>> is incremented each ExecuteCommand, and show in the MyAdapter thread
>> after receive a TC command. You can see the low below, being the
>> debug messages generated by the thread identifies as THREAD.
>>
>> I read the following on the PLEXIL wiki:
>> "Results of execution (LookupOnChange data, command and update
>> acknowledgments, command return values) are often (but not always)
>> delivered by other threads. These results are stored temporarily in a
>> /queue/ inside the interface manager, and delivered to the execution
>> engine when its thread is active again."
>>
>> I suppose that there are different thread executing commands, but I'm
>> really stuck at this point and I really appreciate any clarification
>> about.
>>
>>
>> Thanks in advance,
>> Pablo
>>
>> ==========================================
>> Reading interface configuration from config.xml
>> Initializing application
>> [MyAdapter] Using MyAdapter
>> [MyAdapter] Initialize called...
>> [InterfaceManager:defaultRegisterAdapter] for adapter id_9
>> [MyAdapter] done
>> Starting interfaces
>> [MyAdapter] Started
>> Starting the exec
>> [MyAdapter]ExecuteCommand: 9
>> [MyAdapter]ExecuteCommand: 10
>> [MyAdapter]Command execution request ...
>> [MyAdapter]Started TC MyAdapter thread.
>> [MyAdapter]THREAD: 10
>> [MyAdapter]ExecuteCommand: 11
>> [MyAdapter]ExecuteCommand: 12
>> [MyAdapter]ExecuteCommand: 13
>> [MyAdapter]ExecuteCommand: 14
>> [MyAdapter]ExecuteCommand: 15
>> [MyAdapter]ExecuteCommand: 16
>> [MyAdapter]ExecuteCommand: 17
>> [MyAdapter]THREAD TC recv
>> [MyAdapter]THREAD: 14
>> ...
>> ==========================================
>>
>> --
>> ··································
>> Pablo Muñoz Martínez, PhD student
>> Departamento de Automática
>> Universidad de Alcalá (Spain)
>>
>> Email:pm...@au...
>> Phone: 918856603
>> ··································
>>
>>
>
> Chuck Fry | QTS Inc.
> Office: 650 604 1882 Mobile: 408 230 2715
> M/S 269-1, Building N269/260-7
> NASA Ames Research Center
> Moffett Field, CA 94035-1000
>
> I do not speak for QTS Inc., SGT, Code TI, or NASA, nor do they speak
> for me.
>
>
>
--
··································
Pablo Muñoz Martínez, PhD student
Departamento de Automática
Universidad de Alcalá (Spain)
Email: pm...@au...
Phone: 918856603
··································
|
|
From: Fry, C. R. {C. (ARC-TI)[S. INC] <chu...@na...> - 2015-07-13 17:42:46
|
Hello, and my apologies for the delayed response. Please use ple...@li...<mailto:ple...@li...> for help requests and trouble reports. You have not given me enough information to identify the problem. Can you send your adapter code (specifically the executeCommand() method) and the plan you used to generate the output below? Thank you. -- Chuck On Jul 10, 2015, at 10:05 AM, Pablo Muñoz <pm...@au...<mailto:pm...@au...>> wrote: Dear PLEXIL support, I'm developing a robotic application with PLEXIL and UE and I have a problem with the InterfaceAdapters created to control the robotic platform. Please notice that I'm using version 2.5 (for compatibility reasons). I have an adapter (let call it MyAdapter) that, as a result of a particular ExecuteCommand call from the executive, creates a thread. This thread implements a telecommand system by means of a TCP connection that is working fine. The problem is the following: MyAdapter has an attribute (boolean, int, whatever), which is shared and, sometimes, modified by the thread. I can see that the attribute is effectively modified in the thread, however, when the executive invokes the ExecuteCommand on MyAdapter, the attribute has the initial value, like if the thread hasn't perform any modification. Anyway, in MyAdapter I have other attributes that seems to be shared between the thread and the ExecuteCommand function, but not correctly. I perform a test sharing an integer (starting from 8) that is incremented each ExecuteCommand, and show in the MyAdapter thread after receive a TC command. You can see the low below, being the debug messages generated by the thread identifies as THREAD. I read the following on the PLEXIL wiki: "Results of execution (LookupOnChange data, command and update acknowledgments, command return values) are often (but not always) delivered by other threads. These results are stored temporarily in a queue inside the interface manager, and delivered to the execution engine when its thread is active again." I suppose that there are different thread executing commands, but I'm really stuck at this point and I really appreciate any clarification about. Thanks in advance, Pablo ========================================== Reading interface configuration from config.xml Initializing application [MyAdapter] Using MyAdapter [MyAdapter] Initialize called... [InterfaceManager:defaultRegisterAdapter] for adapter id_9 [MyAdapter] done Starting interfaces [MyAdapter] Started Starting the exec [MyAdapter]ExecuteCommand: 9 [MyAdapter]ExecuteCommand: 10 [MyAdapter]Command execution request ... [MyAdapter]Started TC MyAdapter thread. [MyAdapter]THREAD: 10 [MyAdapter]ExecuteCommand: 11 [MyAdapter]ExecuteCommand: 12 [MyAdapter]ExecuteCommand: 13 [MyAdapter]ExecuteCommand: 14 [MyAdapter]ExecuteCommand: 15 [MyAdapter]ExecuteCommand: 16 [MyAdapter]ExecuteCommand: 17 [MyAdapter]THREAD TC recv [MyAdapter]THREAD: 14 ... ========================================== -- ·································· Pablo Muñoz Martínez, PhD student Departamento de Automática Universidad de Alcalá (Spain) Email: pm...@au...<mailto:pm...@au...> Phone: 918856603 ·································· Chuck Fry | QTS Inc. Office: 650 604 1882 Mobile: 408 230 2715 M/S 269-1, Building N269/260-7 NASA Ames Research Center Moffett Field, CA 94035-1000 I do not speak for QTS Inc., SGT, Code TI, or NASA, nor do they speak for me. |
|
From: Fry, C. R. {C. (ARC-TI)[S. INC] <chu...@na...> - 2015-06-19 22:49:59
|
Hello Héctor. We are aware that the UDP adapter has a number of shortcomings. Another project here at Ames is using it for interfacing to other hardware, and has pointed out several possible improvements. There are simple examples of custom interface adapters in the sample-app and sample-app1 example directories. You could implement a socket-based adapter, but of course some C++ code will be necessary to integrate it. Please feel free to contact me if you have any other questions. -- Chuck On Jun 19, 2015, at 3:18 PM, Hector Fabio Cadavid Rengifo <hec...@gm...<mailto:hec...@gm...>> wrote: Dear support team, My name is Héctor, and I’m involved in a robotics project. We are interested in using Plexil as the core language for the specification of robot’s tasks, but a little advice is required... We already have configured the universal executive in the robot’s controller hardware (an intel galileo board) and everything is working well, but now I’m looking for a way to integrate such executive with robot’s sensing devices and actuators (gears, servomotors, etc). I was able to perform the integration through the UDP adapter, but as far I understand this intended only for interoperability between executives, not for interfacing with external systems. Now I’m looking for a way to integrate ‘lookupOn’/‘lookUpOnChange’ events with information provided by a micro controller trough a serial port. The official documentation (http://plexil.sourceforge.net/wiki/index.php/Advanced_PLEXIL_Interfacing#Construction) states that we have to create a C++ shared library that implements the ‘InterfaceAdapter’ in order to enable an interface with external systems. I understand the idea, but, could you please provide us a sample implementation of a custom InterfaceAdapter, and an example of how to integrate the generated dynamic library in the <Interfaces> configuration file?… If there is already an example in the distribution, I would appreciate if you indicate me where it is located... Just for curiosity, could it be possible to use a a socket-based adapter -as an alternative to the C++ adapters- in order to achieve the same interfacing scenario? (in this case, I would implement a socket server that ‘talk’ directly with the hardware according with the received events). Sincerely yours, Héctor ------------------------------------------------------------------------------ _______________________________________________ plexil-support mailing list ple...@li...<mailto:ple...@li...> https://lists.sourceforge.net/lists/listinfo/plexil-support Chuck Fry | QTS Inc. Office: 650 604 1882 Mobile: 408 230 2715 M/S 269-1, Building N269/260-7 NASA Ames Research Center Moffett Field, CA 94035-1000 I do not speak for QTS Inc., SGT, Code TI, or NASA, nor do they speak for me. |
|
From: Hector F. C. R. <hec...@gm...> - 2015-06-19 22:18:59
|
Dear support team, My name is Héctor, and I’m involved in a robotics project. We are interested in using Plexil as the core language for the specification of robot’s tasks, but a little advice is required... We already have configured the universal executive in the robot’s controller hardware (an intel galileo board) and everything is working well, but now I’m looking for a way to integrate such executive with robot’s sensing devices and actuators (gears, servomotors, etc). I was able to perform the integration through the UDP adapter, but as far I understand this intended only for interoperability between executives, not for interfacing with external systems. Now I’m looking for a way to integrate ‘lookupOn’/‘lookUpOnChange’ events with information provided by a micro controller trough a serial port. The official documentation (http://plexil.sourceforge.net/wiki/index.php/Advanced_PLEXIL_Interfacing#Construction) states that we have to create a C++ shared library that implements the ‘InterfaceAdapter’ in order to enable an interface with external systems. I understand the idea, but, could you please provide us a sample implementation of a custom InterfaceAdapter, and an example of how to integrate the generated dynamic library in the <Interfaces> configuration file?… If there is already an example in the distribution, I would appreciate if you indicate me where it is located... Just for curiosity, could it be possible to use a a socket-based adapter -as an alternative to the C++ adapters- in order to achieve the same interfacing scenario? (in this case, I would implement a socket server that ‘talk’ directly with the hardware according with the received events). Sincerely yours, Héctor |
|
From: Fry, C. R. {C. (ARC-TI)[S. INC] <chu...@na...> - 2015-01-06 21:29:39
|
Thanks Andrew. You are correct, and I'll put up corrected diagrams shortly. -- Chuck On Jan 2, 2015, at 6:21 AM, Andrew Harris <and...@gm...<mailto:and...@gm...>> wrote: Hello, In the node transition diagrams at this page: http://plexil.sourceforge.net/wiki/index.php/Node_State_Transition_Diagrams#EXECUTING_state I think the "EXECUTING - Command Nodes" and "EXECUTING - Update Nodes" diagrams have the logic on the AncestorExit condition backwards. That is, they should branch to the right on T, not F. -andrew ------------------------------------------------------------------------------ Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net_______________________________________________ plexil-support mailing list ple...@li...<mailto:ple...@li...> https://lists.sourceforge.net/lists/listinfo/plexil-support Chuck Fry | QTS Inc. Office: 650 604 1882 Mobile: 408 230 2715 M/S 269-1, Building N269/260-7 NASA Ames Research Center Moffett Field, CA 94035-1000 I do not speak for QTS Inc., SGT, Code TI, or NASA, nor do they speak for me. ---- The CIA torturers and their overseers MUST be prosecuted, to the fullest extent of national and international law. Anything less condones and encourages future torture. |
|
From: Andrew H. <and...@gm...> - 2015-01-02 14:21:56
|
Hello, In the node transition diagrams at this page: http://plexil.sourceforge.net/wiki/index.php/Node_State_Transition_Diagrams#EXECUTING_state I think the "EXECUTING - Command Nodes" and "EXECUTING - Update Nodes" diagrams have the logic on the AncestorExit condition backwards. That is, they should branch to the right on T, not F. -andrew |
|
From: Fry, C. R. {C. (ARC-TI)[S. INC] <chu...@na...> - 2014-10-06 17:56:22
|
Thank you for your message Chris.
This is the correct behavior, according to the PLEXIL specifications. Assignment nodes retract the assignment on failure, and failure is defined to include failure of an ancestor node.
-- Chuck
On Oct 6, 2014, at 10:33 AM, Chris LANGLEY <Chr...@md...<mailto:Chr...@md...>>
wrote:
Dear Plexil Support,
It appears when one assigns a value to a variable in a child node, that assignment fails if it also impacts an InvariantCondition. This means that the parent doesn’t ever see the value of the variable which caused it’s child to exit.
An example helps to clarify. The following is the minimal case for reproducing the problem:
Command pprint(...);
BooleanProblem : UncheckedSequence
{
// Here is my trigger boolean
Boolean quitNow = false;
BailOutWrapper:
{
InvariantCondition quitNow == false;
// EndCondition quitNow == true; // Commented; See notes below for the case which worked
pprint("I'm in BailOutWrapper now.");
pprint("quitNow = ", quitNow);
quitNow = true;
pprint("I don't think this should print.");
}
pprint("quitNow = ", quitNow);
if (quitNow == true)
{
pprint("This is the desired behaviour");
}
else
{
pprint("This behaviour is NOT COOL!");
}
endif
}
When I compile and run this, I get:
Error: No config defined or Config does not exist.
Warning: using default config: /home/ugps/plexil-3/examples/dummy-config.xml
Running executive from /home/ugps/plexil-3
Plan: BooleanProblem.plx
Configuration: /home/ugps/plexil-3/examples/dummy-config.xml
Libraries:
Library directories:
PORT:
Reading interface configuration from /home/ugps/plexil-3/examples/dummy-config.xml
Initializing application
Starting interfaces
Socket.cpp(62) MARK
Starting the exec
I'm in BailOutWrapper now.
[Node:outcome]Outcome of 'COMMAND__0' is SUCCESS
quitNow = 0
[Node:outcome]Outcome of 'COMMAND__1' is SUCCESS
[Node:outcome]Outcome of 'COMMAND__3' is SKIPPED
[Node:outcome]Outcome of 'ASSIGNMENT__2' is FAILURE
[Node:outcome]Outcome of 'BailOutWrapper' is FAILURE
quitNow = 0
[Node:outcome]Outcome of 'COMMAND__4' is SUCCESS
[Node:outcome]Outcome of 'ep2cp_IfSetup' is SUCCESS
[Node:outcome]Outcome of 'ep2cp_IfThenCase' is SKIPPED
[Node:outcome]Outcome of 'BLOCK__6' is SKIPPED
This behaviour is NOT COOL!
[Node:outcome]Outcome of 'BLOCK__8' is SUCCESS
[Node:outcome]Outcome of 'ep2cp_IfElseCase' is SUCCESS
[Node:outcome]Outcome of 'ep2cp_IfBody' is SUCCESS
[Node:outcome]Outcome of 'if__5' is SUCCESS
[Node:outcome]Outcome of 'BooleanProblem' is SUCCESS
Plan complete, Exec exited without errors
As this shows, the moment quitNow is set to true, the child exits (as you’d expect) because the pprint is SKIPPED. However, for some reason ASSIGNMENT__2 is FAILURE, so when it checks the value of quitNow in the parent, it’s still set to FALSE, and we see the “NOT COOL” pprint.
Now, using the same example, comment out the InvariantCondition and uncomment the EndCondition. Without the full :node:outcome statements:
Starting the exec
I'm in BailOutWrapper now.
quitNow = 0
quitNow = 1
This is the desired behaviour
Plan complete, Exec exited without errors
And ASSIGNMENT__2 is now SUCCESS, so we get the expected behaviour.
Is the failed assignment a bug, or a feature of InvariantCondition? If a feature, why would it be useful? I can imagine a workaround to get the behaviour I want by introducing a “shadow variable”:
Boolean quitNowParent = false;
BailOutWrapper:
{
Boolean quitNowChild = false;
InvariantCondition quitNowChild == false;
quitNowParent = true;
quitNowChild = true;
}
Thanks for your attention,
Chris
Chris Langley
MDA
9445 Airport Road
Brampton, ON
L6S 4J3
------------------------------------------------------------------------------
Slashdot TV. Videos for Nerds. Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support
Chuck Fry | QTS Inc.
Office: 650 604 1882 Mobile: 408 230 2715
M/S 269-1, Building N269/260-7
NASA Ames Research Center
Moffett Field, CA 94035-1000
I do not speak for QTS Inc., SGT, Code TI, or NASA, nor do they speak for me.
|
|
From: Chris L. <Chr...@md...> - 2014-10-06 17:45:40
|
Dear Plexil Support,
It appears when one assigns a value to a variable in a child node, that assignment fails if it also impacts an InvariantCondition. This means that the parent doesn't ever see the value of the variable which caused it's child to exit.
An example helps to clarify. The following is the minimal case for reproducing the problem:
Command pprint(...);
BooleanProblem : UncheckedSequence
{
// Here is my trigger boolean
Boolean quitNow = false;
BailOutWrapper:
{
InvariantCondition quitNow == false;
// EndCondition quitNow == true; // Commented; See notes below for the case which worked
pprint("I'm in BailOutWrapper now.");
pprint("quitNow = ", quitNow);
quitNow = true;
pprint("I don't think this should print.");
}
pprint("quitNow = ", quitNow);
if (quitNow == true)
{
pprint("This is the desired behaviour");
}
else
{
pprint("This behaviour is NOT COOL!");
}
endif
}
When I compile and run this, I get:
Error: No config defined or Config does not exist.
Warning: using default config: /home/ugps/plexil-3/examples/dummy-config.xml
Running executive from /home/ugps/plexil-3
Plan: BooleanProblem.plx
Configuration: /home/ugps/plexil-3/examples/dummy-config.xml
Libraries:
Library directories:
PORT:
Reading interface configuration from /home/ugps/plexil-3/examples/dummy-config.xml
Initializing application
Starting interfaces
Socket.cpp(62) MARK
Starting the exec
I'm in BailOutWrapper now.
[Node:outcome]Outcome of 'COMMAND__0' is SUCCESS
quitNow = 0
[Node:outcome]Outcome of 'COMMAND__1' is SUCCESS
[Node:outcome]Outcome of 'COMMAND__3' is SKIPPED
[Node:outcome]Outcome of 'ASSIGNMENT__2' is FAILURE
[Node:outcome]Outcome of 'BailOutWrapper' is FAILURE
quitNow = 0
[Node:outcome]Outcome of 'COMMAND__4' is SUCCESS
[Node:outcome]Outcome of 'ep2cp_IfSetup' is SUCCESS
[Node:outcome]Outcome of 'ep2cp_IfThenCase' is SKIPPED
[Node:outcome]Outcome of 'BLOCK__6' is SKIPPED
This behaviour is NOT COOL!
[Node:outcome]Outcome of 'BLOCK__8' is SUCCESS
[Node:outcome]Outcome of 'ep2cp_IfElseCase' is SUCCESS
[Node:outcome]Outcome of 'ep2cp_IfBody' is SUCCESS
[Node:outcome]Outcome of 'if__5' is SUCCESS
[Node:outcome]Outcome of 'BooleanProblem' is SUCCESS
Plan complete, Exec exited without errors
As this shows, the moment quitNow is set to true, the child exits (as you'd expect) because the pprint is SKIPPED. However, for some reason ASSIGNMENT__2 is FAILURE, so when it checks the value of quitNow in the parent, it's still set to FALSE, and we see the "NOT COOL" pprint.
Now, using the same example, comment out the InvariantCondition and uncomment the EndCondition. Without the full :node:outcome statements:
Starting the exec
I'm in BailOutWrapper now.
quitNow = 0
quitNow = 1
This is the desired behaviour
Plan complete, Exec exited without errors
And ASSIGNMENT__2 is now SUCCESS, so we get the expected behaviour.
Is the failed assignment a bug, or a feature of InvariantCondition? If a feature, why would it be useful? I can imagine a workaround to get the behaviour I want by introducing a "shadow variable":
Boolean quitNowParent = false;
BailOutWrapper:
{
Boolean quitNowChild = false;
InvariantCondition quitNowChild == false;
quitNowParent = true;
quitNowChild = true;
}
Thanks for your attention,
Chris
Chris Langley
MDA
9445 Airport Road
Brampton, ON
L6S 4J3
|
|
From: Chris L. <Chr...@md...> - 2014-07-07 15:36:16
|
Chuck,
Thanks for the clarification.
I was unable to call .outcome on the library action's name (GraspPreconditions). I got:
ERROR: :168206: Node 'Action0001' is trying to access node 'GraspPreconditions' which is out of scope or does not exist
I got everything working by adding a return status variable into GraspPrecondition's interface:
InOut Boolean theResult;
and then using
PostCondition theResult == true;
in the parent node.
Best regards,
Chris
From: Fry, Charles R. {Chuck} (ARC-TI)[SGT, INC] [mailto:chu...@na...]
Sent: Thursday, July 03, 2014 5:00 PM
To: Chris LANGLEY
Cc: ple...@li...
Subject: Re: [plexil-support] Failure of a LibraryAction does not result in failure of a LibraryCall node?
Hi Chris. I agree that this behavior seems unintuitive, but by default a node's invariants (which determine failure) are dependent solely on its ancestors, not its children. You can argue that this dependency should go both ways for LibraryCall nodes.
Off the top of my head, you could add to the call node an invariant condition of GraspPreconditions.OUTCOME != FAILURE. That should give the behavior you're looking for.
-- Chuck
On Jul 3, 2014, at 1:23 PM, Chris LANGLEY <Chr...@md...<mailto:Chr...@md...>> wrote:
Dear PLEXIL support,
Is there a way to make a LibraryCall node fail when the action it calls fails?
For example, I have:
// Declaration of library action
LibraryAction GraspPreconditions(In Integer theEndEffectorID, In Integer theGrappleID, In Boolean theCmdState);
// Some other declarations etc. here
// Then:
GraspPrecondCallNode: LibraryCall GraspPreconditions(theEndEffectorID = 5, theGrappleID = 9, theCmdState = true);
When I execute this in such a way that I know GraspPreconditions(...) will fail, I get the following output:
[Node:outcome]Outcome of 'GraspPreconditions' is FAILURE
[Node:outcome]Outcome of 'GraspPrecondCallNode' is SUCCESS
Does this mean that the "call" was a success, even though the actual action was a failure? Intuitively I would expect that if the latter failed, then so should the library call, so the result of (for example)
PostCondition GraspPrecondCallNode.outcome == SUCCESS;
did not behave as I expected. My idea is to work around this by introducing an InOut parameter to GraspPreconditions which acts as the return value, but is there a cleaner way to achieve the desired behavior?
Thanks and regards,
Chris
Chris Langley
MDA
9445 Airport Road
Brampton, ON
L6S 4J3
(905) 790-2800 x4199
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support
Chuck Fry | QTS Inc.
Office: 650 604 1882 Mobile: 408 230 2715
M/S 269-1, Building N269/260-7
NASA Ames Research Center
Moffett Field, CA 94035-1000
I do not speak for QTS Inc., SGT, Code TI, or NASA, nor do they speak for me.
|
|
From: Fry, C. R. {C. (ARC-TI)[S. INC] <chu...@na...> - 2014-07-03 21:00:02
|
Hi Chris. I agree that this behavior seems unintuitive, but by default a node's invariants (which determine failure) are dependent solely on its ancestors, not its children. You can argue that this dependency should go both ways for LibraryCall nodes.
Off the top of my head, you could add to the call node an invariant condition of GraspPreconditions.OUTCOME != FAILURE. That should give the behavior you're looking for.
-- Chuck
On Jul 3, 2014, at 1:23 PM, Chris LANGLEY <Chr...@md...<mailto:Chr...@md...>> wrote:
Dear PLEXIL support,
Is there a way to make a LibraryCall node fail when the action it calls fails?
For example, I have:
// Declaration of library action
LibraryAction GraspPreconditions(In Integer theEndEffectorID, In Integer theGrappleID, In Boolean theCmdState);
// Some other declarations etc. here
// Then:
GraspPrecondCallNode: LibraryCall GraspPreconditions(theEndEffectorID = 5, theGrappleID = 9, theCmdState = true);
When I execute this in such a way that I know GraspPreconditions(…) will fail, I get the following output:
[Node:outcome]Outcome of 'GraspPreconditions' is FAILURE
[Node:outcome]Outcome of 'GraspPrecondCallNode' is SUCCESS
Does this mean that the “call” was a success, even though the actual action was a failure? Intuitively I would expect that if the latter failed, then so should the library call, so the result of (for example)
PostCondition GraspPrecondCallNode.outcome == SUCCESS;
did not behave as I expected. My idea is to work around this by introducing an InOut parameter to GraspPreconditions which acts as the return value, but is there a cleaner way to achieve the desired behavior?
Thanks and regards,
Chris
Chris Langley
MDA
9445 Airport Road
Brampton, ON
L6S 4J3
(905) 790-2800 x4199
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support
Chuck Fry | QTS Inc.
Office: 650 604 1882 Mobile: 408 230 2715
M/S 269-1, Building N269/260-7
NASA Ames Research Center
Moffett Field, CA 94035-1000
I do not speak for QTS Inc., SGT, Code TI, or NASA, nor do they speak for me.
|
|
From: Chris L. <Chr...@md...> - 2014-07-03 20:23:43
|
Dear PLEXIL support,
Is there a way to make a LibraryCall node fail when the action it calls fails?
For example, I have:
// Declaration of library action
LibraryAction GraspPreconditions(In Integer theEndEffectorID, In Integer theGrappleID, In Boolean theCmdState);
// Some other declarations etc. here
// Then:
GraspPrecondCallNode: LibraryCall GraspPreconditions(theEndEffectorID = 5, theGrappleID = 9, theCmdState = true);
When I execute this in such a way that I know GraspPreconditions(...) will fail, I get the following output:
[Node:outcome]Outcome of 'GraspPreconditions' is FAILURE
[Node:outcome]Outcome of 'GraspPrecondCallNode' is SUCCESS
Does this mean that the "call" was a success, even though the actual action was a failure? Intuitively I would expect that if the latter failed, then so should the library call, so the result of (for example)
PostCondition GraspPrecondCallNode.outcome == SUCCESS;
did not behave as I expected. My idea is to work around this by introducing an InOut parameter to GraspPreconditions which acts as the return value, but is there a cleaner way to achieve the desired behavior?
Thanks and regards,
Chris
Chris Langley
MDA
9445 Airport Road
Brampton, ON
L6S 4J3
(905) 790-2800 x4199
|
|
From: Dalal, M. (ARC-TI)[S. INC] <mic...@na...> - 2014-06-24 23:41:06
|
Thanks for the traces, Chris. I can't quite tell which thread is crashing, do you know? In any case, I don't see any with Plexil expression issues (which is common in Plexil crashes). I'm suspecting a thread-related issue.
One culprit might be that both calls to WaitForATP() occur during the same quiescence cycle in Plexil. This would be the case if the code you have abstracted with:
DoSomethingMeaningfulUntilNextATP
did not interact with the external world, i.e. with a command or lookup. Does it?
Mike
On Jun 24, 2014, at 12:53 PM, Chris LANGLEY <Chr...@md...<mailto:Chr...@md...>>
wrote:
Mike,
Please find the trace below.
Thanks,
Chris
Thread 12 (Thread 0xaaefeb40 (LWP 2835)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb69b6d06 in nanosleep () from /lib/i386-linux-gnu/libc.so.6
#2 0xb69e765d in usleep () from /lib/i386-linux-gnu/libc.so.6
#3 0x08096fe4 in RoboticsSimulation::MainLoopThread (this=0xbffff0b0)
at ../src/RoboticsSimulation.cpp:300
#4 0x08096d83 in RoboticsSimulation::mainThreadEntry (me=0xbffff0b0)
at ../src/RoboticsSimulation.cpp:242
#5 0xb68e8d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#6 0xb69edbae in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 11 (Thread 0xab6ffb40 (LWP 2834)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb69ee766 in epoll_wait () from /lib/i386-linux-gnu/libc.so.6
#2 0x080d5fd7 in boost::asio::detail::epoll_reactor::run(bool, boost::asio::detail::op_queue<boost::asio::detail::task_io_service_operation>&) ()
#3 0x080d87fa in boost::asio::detail::task_io_service::run(boost::system::error_code&) ()
#4 0x080d5355 in sapient::TcpServer::run(sapient::IMessageHandler*) ()
#5 0x080b1d77 in sapient::FlightCommunicationModule::FlightCommunicationModuleImpl::threadRunServer() ()
#6 0xb7607f3c in thread_proxy ()
---Type <return> to continue, or q <return> to quit---
from /home/ugps/SAPIENT/Flight/lib/libboost_thread.so.1.55.0
#7 0xb68e8d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#8 0xb69edbae in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 10 (Thread 0xac2feb40 (LWP 2833)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb69b6d06 in nanosleep () from /lib/i386-linux-gnu/libc.so.6
#2 0xb69e765d in usleep () from /lib/i386-linux-gnu/libc.so.6
#3 0x0809c988 in Sapient::pSapientComm::threadFunc (this=0x9ea8470)
at ../src/pSapientComm.cpp:366
#4 0x0809c5e9 in Sapient::pSapientComm::threadEntry (me=0x9ea8470)
at ../src/pSapientComm.cpp:295
#5 0xb68e8d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#6 0xb69edbae in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 9 (Thread 0xacaffb40 (LWP 2832)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb69b6d06 in nanosleep () from /lib/i386-linux-gnu/libc.so.6
#2 0xb69e765d in usleep () from /lib/i386-linux-gnu/libc.so.6
#3 0x08081a54 in MissionExecutiveManager::MainLoopThread (this=0x9e4b0e0)
at ../src/MissionExecutiveManager.cpp:312
#4 0x0808179d in MissionExecutiveManager::mainThreadEntry (me=0x9e4b0e0)
at ../src/MissionExecutiveManager.cpp:201
---Type <return> to continue, or q <return> to quit---
#5 0xb68e8d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#6 0xb69edbae in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 8 (Thread 0xad407b40 (LWP 2831)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb68eecc5 in sem_wait@@GLIBC_2.1 ()
from /lib/i386-linux-gnu/libpthread.so.0
#2 0xb6c59302 in PLEXIL::ThreadSemaphore::wait (this=0x9e4cdfc)
at ThreadSemaphore.cc:78
#3 0xb6e3c025 in PLEXIL::ExecApplication::waitForExternalEvent (
this=0x9e4cbe8) at ExecApplication.cc:552
#4 0xb6e3ca3d in PLEXIL::ExecApplication::runInternal (this=0x9e4cbe8)
at ExecApplication.cc:489
#5 0xb6e3d06e in PLEXIL::ExecApplication::execTopLevel (
this_as_void_ptr=0x9e4cbe8) at ExecApplication.cc:473
#6 0xb68e8d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#7 0xb69edbae in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 7 (Thread 0xaffacb40 (LWP 2830)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb692c6f1 in ?? () from /lib/i386-linux-gnu/libc.so.6
#2 0xb692c785 in sigwait () from /lib/i386-linux-gnu/libc.so.6
#3 0xb6e5a342 in PLEXIL::TimeAdapter::timerWaitThreadImpl (this=0x9e4e698)
---Type <return> to continue, or q <return> to quit---
at TimeAdapter.cc:235
#4 0xb6e5740e in PLEXIL::TimeAdapter::timerWaitThread (
this_as_void_ptr=0x9e4e698) at TimeAdapter.cc:210
#5 0xb68e8d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#6 0xb69edbae in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 6 (Thread 0xadcffb40 (LWP 2829)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb69b6d06 in nanosleep () from /lib/i386-linux-gnu/libc.so.6
#2 0xb69e765d in usleep () from /lib/i386-linux-gnu/libc.so.6
#3 0x08096fe4 in RoboticsSimulation::MainLoopThread (this=0x9e4eab0)
at ../src/RoboticsSimulation.cpp:300
#4 0x08096d83 in RoboticsSimulation::mainThreadEntry (me=0x9e4eab0)
at ../src/RoboticsSimulation.cpp:242
#5 0xb68e8d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#6 0xb69edbae in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 5 (Thread 0xb07ffb40 (LWP 2828)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb69df460 in poll () from /lib/i386-linux-gnu/libc.so.6
#2 0xb56f1a3b in g_poll () from /lib/i386-linux-gnu/libglib-2.0.so.0
#3 0xb56e406e in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#4 0xb56e452b in g_main_loop_run () from /lib/i386-linux-gnu/libglib-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#5 0xb20a44aa in ?? () from /usr/lib/i386-linux-gnu/libgio-2.0.so.0
#6 0xb5707673 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#7 0xb68e8d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#8 0xb69edbae in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 4 (Thread 0xb11d3b40 (LWP 2827)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb69df460 in poll () from /lib/i386-linux-gnu/libc.so.6
#2 0xb56f1a3b in g_poll () from /lib/i386-linux-gnu/libglib-2.0.so.0
#3 0xb56e406e in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#4 0xb56e452b in g_main_loop_run () from /lib/i386-linux-gnu/libglib-2.0.so.0
#5 0xb42b0134 in ?? ()
from /usr/lib/i386-linux-gnu/gio/modules/libdconfsettings.so
#6 0xb5707673 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#7 0xb68e8d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#8 0xb69edbae in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 3 (Thread 0xb4affb40 (LWP 2826)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb68ec96b in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/i386-linux-gnu/libpthread.so.0
#2 0xb69fb4bc in pthread_cond_wait () from /lib/i386-linux-gnu/libc.so.6
#3 0xb5a9d350 in QWaitCondition::wait(QMutex*, unsigned long) ()
---Type <return> to continue, or q <return> to quit---
from /usr/lib/i386-linux-gnu/libQtCore.so.4
#4 0xb7f61a6e in SoQtSignalThread::run (this=0xb4b00678)
at SoQtSignalThread.cpp:66
#5 0xb5a9cde0 in ?? () from /usr/lib/i386-linux-gnu/libQtCore.so.4
#6 0xb68e8d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#7 0xb69edbae in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 1 (Thread 0xb5488980 (LWP 2822)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb69b6d06 in nanosleep () from /lib/i386-linux-gnu/libc.so.6
#2 0xb69e765d in usleep () from /lib/i386-linux-gnu/libc.so.6
#3 0x0806d589 in main (argc=3, argv=0xbffff244) at ../src/FlightMain.cpp:421
From: Dalal, Michael (ARC-TI)[SGT, INC] [mailto:mic...@na...<http://nasa.gov>]
Sent: Tuesday, June 24, 2014 1:55 PM
To: Chris LANGLEY
Cc: ple...@li...<mailto:ple...@li...>
Subject: Re: [plexil-support] When are Lookups checked for Exit and Invariant Conditions?
Chris,
Offhand, I'm not sure what's happening. However, an exec crash is pretty serious, and we don't want that to ever happen. Could you please provide a stack trace? (E.g. by opening the core file, if you can get one, with gdb, or running the application inside gdb). That will at least pinpoint the source of the problem.
Thanks,
Mike
On Jun 24, 2014, at 7:25 AM, Chris LANGLEY <Chr...@md...<mailto:Chr...@md...>>
wrote:
Dear PLEXIL Support,
I have a problem which is very similar to the one described by Catherine and Mike in the trail below.
The short description is: When using a Lookup as part of an ExitCondition in a library node, the second time the node is called, the program crashes.
Long description follows.
I am using PLEXIL within a standalone application. The plan I am running models a system with Authority To Proceed (ATP) points, where the human gives the autonomous agent permission to continue. A typical plan looks like this:
LibraryAction WaitForATP();
MasterPlan:
{
LibraryCall WaitForATP();
DoSomethingMeaningfulUntilNextATP: { … }
LibraryCall WaitForATP();
DoSomethingElseUntilNextATP: { … }
// … and so on
}
Wait for ATP library node looks like this:
Boolean Lookup IsAuthorizationGiven();
WaitForATP:
{
pprint(“Waiting for ATP…”);
WaitActual:
{
EndCondition Lookup(IsAuthorizationGiven()) == true;
// The following pprint does not affect the bug behavior either commented or uncommented
pprint(“This is a just-in-case pprint based on plexil-support notes.”);
}
pprint(“Done waiting for ATP”);
}
The external Lookup for IsAuthorizationGiven checks a Boolean flag which can be set and cleared by a separate object in the program. The code is based on SampleAdapter.cc.
The test program does an ExecApplication::addPlan(), then waits a few seconds, then sets the ATP flag. The flag gets cleared when IsAuthorizationGiven gets the true. The test program waits a few more second, then sets the flag again. The process repeats.
TEST CASE 1:
If my external code simply sets the flag, then the first time WaitForATP is called, the Lookup is accessed once and then everything just waits. I believe this is related to the behavior discussed below.
TEST CASE 2: (The real problem)
If my external code sets the flag, then calls Adapter->propagateValueChange(State (LabelStr(“IsAuthorizationGiven”), EmptyArgs), vals) [with propagateValueChange based on SampleAdapter.cc], then the first time WaitForATP is called, the behavior is correct: a pause for a moment until the external flag goes high, then execution proceeds. As soon as it gets the second call to WaitForATP and the Lookup is executed, my program crashes. I do see the “This is just in case pprint…” message, which is then followed by “User defined signal 1”.
I’ve tried several variations on the same theme (where exactly the Lookup gets handled, whether or not to use the publish/subscribe pattern given in the SampleAdapter example, how handleValueChange and notifyOfExternalEvent get called), and the result is always either everything waits (Test Case 1), or the program crashes on the second call to WaitForATP (Test Case 2).
I’ve been trying to squash this one (part-time) for a week, so any help would be greatly appreciated. Am I doing something incorrectly? Alternatively, can you suggest a workaround way of designing my PLEXIL code to achieve the same desired “wait for authorization” behavior?
Thanks and best regards,
Chris
You need only ever use "Lookup", which compiles to LookupNow or LookupOnChange depending (completely) on the context. I've added a note on this in the Lookup documentation, which should answer your question.
I'll try to write a small plan that reproduces the behavior you're getting, as I don't have any new ideas at the moment. This could be an opportunity to discover and document an important property (or bug?) of PLEXIL. Any portion of your plan you can send (just to me) will be helpful.
Mike
On Apr 30, 2014, at 10:16 AM, Catherine Szeto <Catherine.Szeto@...<mailto:Catherine.Szeto@...<mailto:Catherine.Szeto@...%3cmailto:Catherine.Szeto@...>>> wrote:
Mike,
Thanks for the reply. The adapter code is based straight off of the SampleAdapter.cc, so notifyOfExternalEvent should be called when I send a value to SwitchPlanFailed, the command that changes PlanFailed.
I did consider the macro step case, as in the previous issue where I ended up putting a blank 'print' to force the step. I don't think it is the exact same case here. I tried putting the a blank 'print' in, but it didn't work, not to mention that the rest of the code in PlanA has print statements as well. I did check the node diagrams, but I'm not sure if that will help point out the issue. The EXECUTING diagram showed the EndCondition pushing the state back to Executing if it's false, so I tried putting one in for the heck of it to see if it would trigger anything. I also tried using LookupOnChange instead of plain Lookup. No luck. It seems the only thing that gets the state to update is to perform another Lookup on the PlanFailed, whether it is done in Plan A or Plan B.
What does LookupOnChange do versus LookupNow? I assumed the former checks the state if it has changed, but that doesn't seem to be true.
Catherine
From: Dalal, Michael (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)] [mailto:michael.dalal@...<http://nasa.gov><http://nasa.gov%3E/>;]
Sent: Tuesday, April 29, 2014 2:44 PM
To: Catherine Szeto
Cc: plexil-support@...<mailto:plexil-support@<mailto:plexil-support@...%3cmailto:plexil-support@>...>
Subject: Re: [plexil-support] When are Lookups checked for Exit and Invariant Conditions?
Catherine,
Is your interface adapter code for the PlanFailed flag calling ExecInterface's notifyOfExternalEvent when the flag changes? If not, that would contribute to the behavior your describe.
Still, this may be another case of the desired behavior being delayed until the plan completes a quiescence cycle or macro step. Namely, the Exit condition is not checked "immediately" when the flag changes because the plan execution has not yet quiesced, i.e. there are pending node transitions in progress. Your inserting the 'pprint' (or any other command) after that library call effectively creates a macro step boundary.
Another solution, not great but at least clear, is to enclose the code following the library call in "if not plan failed…".
Time lookups can behave differently because the interface adapter (provided by the PLEXIL framework) effectively triggers a new macro step when the time updates. (Though I'm not sure a time lookup in this context would make any difference).
I agree this is an unintuitive and complicated aspect of PLEXIL. The node transition diagrams (an appendix section in the documentation) are helpful (even essential) for understanding PLEXIL behavior at this level, yet they only describe the atomic steps of execution (see the PLEXIL semantics chapter).
I'll try to think of a better way we can explain these kinds of plan behaviors.
Mike
On Apr 29, 2014, at 10:33 AM, Catherine Szeto <Catherine.Szeto@...<mailto:Catherine.Szeto@...<mailto:Catherine.Szeto@...%3cmailto:Catherine.Szeto@...>>>
wrote:
Hello,
When I use a Lookup(time,0.1) in a Exit or Invariant Condition, I've found the result to reliably abort the plan when the time between a Lookup(time,0.1) and a start time goes beyond a specified time limit. However, the Exit and Invariant Conditions don't work if I use a Boolean variable that can be switched outside of the plan. For example, I have this case:
PlanA:
{
ExitCondition Lookup(PlanFailed) == true;
LibraryCall PlanB();
//PlanB switches PlanFailed to true
//rest of code
}
When PlanB switches PlanFailed to true, I expect PlanA to stop executing, but it doesn't. To debug, I put a pprint to output Lookup(PlanFailed) after the LibraryCall to Plan B. I suppose the Lookup caused the ExitCondition to update, because PlanA stopped executing when I put that pprint there.
I noticed this part in the reference:
"The second context for lookups is the synchronous context implied by an action's check conditions (Pre, Post, Invariant) and its body. In these contexts, a lookup is processed on demand, that is, its value is fetched at specific points in execution of the action."
I thought ExitCondition and InvariantCondition would constantly check the Lookup(PlanFailed), but that doesn't seem to be the case. Is something like my pprint the only way to get the Exit or Invariant Conditions to recheck a Boolean Lookup like Lookup(PlanFailed)?
Catherine
Chris Langley
MDA
9445 Airport Road
Brampton, ON
L6S 4J3
(905) 790-2800 x4199
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support
|
|
From: Chris L. <Chr...@md...> - 2014-06-24 19:53:41
|
Mike,
Please find the trace below.
Thanks,
Chris
Thread 12 (Thread 0xaaefeb40 (LWP 2835)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb69b6d06 in nanosleep () from /lib/i386-linux-gnu/libc.so.6
#2 0xb69e765d in usleep () from /lib/i386-linux-gnu/libc.so.6
#3 0x08096fe4 in RoboticsSimulation::MainLoopThread (this=0xbffff0b0)
at ../src/RoboticsSimulation.cpp:300
#4 0x08096d83 in RoboticsSimulation::mainThreadEntry (me=0xbffff0b0)
at ../src/RoboticsSimulation.cpp:242
#5 0xb68e8d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#6 0xb69edbae in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 11 (Thread 0xab6ffb40 (LWP 2834)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb69ee766 in epoll_wait () from /lib/i386-linux-gnu/libc.so.6
#2 0x080d5fd7 in boost::asio::detail::epoll_reactor::run(bool, boost::asio::detail::op_queue<boost::asio::detail::task_io_service_operation>&) ()
#3 0x080d87fa in boost::asio::detail::task_io_service::run(boost::system::error_code&) ()
#4 0x080d5355 in sapient::TcpServer::run(sapient::IMessageHandler*) ()
#5 0x080b1d77 in sapient::FlightCommunicationModule::FlightCommunicationModuleImpl::threadRunServer() ()
#6 0xb7607f3c in thread_proxy ()
---Type <return> to continue, or q <return> to quit---
from /home/ugps/SAPIENT/Flight/lib/libboost_thread.so.1.55.0
#7 0xb68e8d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#8 0xb69edbae in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 10 (Thread 0xac2feb40 (LWP 2833)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb69b6d06 in nanosleep () from /lib/i386-linux-gnu/libc.so.6
#2 0xb69e765d in usleep () from /lib/i386-linux-gnu/libc.so.6
#3 0x0809c988 in Sapient::pSapientComm::threadFunc (this=0x9ea8470)
at ../src/pSapientComm.cpp:366
#4 0x0809c5e9 in Sapient::pSapientComm::threadEntry (me=0x9ea8470)
at ../src/pSapientComm.cpp:295
#5 0xb68e8d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#6 0xb69edbae in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 9 (Thread 0xacaffb40 (LWP 2832)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb69b6d06 in nanosleep () from /lib/i386-linux-gnu/libc.so.6
#2 0xb69e765d in usleep () from /lib/i386-linux-gnu/libc.so.6
#3 0x08081a54 in MissionExecutiveManager::MainLoopThread (this=0x9e4b0e0)
at ../src/MissionExecutiveManager.cpp:312
#4 0x0808179d in MissionExecutiveManager::mainThreadEntry (me=0x9e4b0e0)
at ../src/MissionExecutiveManager.cpp:201
---Type <return> to continue, or q <return> to quit---
#5 0xb68e8d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#6 0xb69edbae in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 8 (Thread 0xad407b40 (LWP 2831)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb68eecc5 in sem_wait@@GLIBC_2.1 ()
from /lib/i386-linux-gnu/libpthread.so.0
#2 0xb6c59302 in PLEXIL::ThreadSemaphore::wait (this=0x9e4cdfc)
at ThreadSemaphore.cc:78
#3 0xb6e3c025 in PLEXIL::ExecApplication::waitForExternalEvent (
this=0x9e4cbe8) at ExecApplication.cc:552
#4 0xb6e3ca3d in PLEXIL::ExecApplication::runInternal (this=0x9e4cbe8)
at ExecApplication.cc:489
#5 0xb6e3d06e in PLEXIL::ExecApplication::execTopLevel (
this_as_void_ptr=0x9e4cbe8) at ExecApplication.cc:473
#6 0xb68e8d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#7 0xb69edbae in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 7 (Thread 0xaffacb40 (LWP 2830)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb692c6f1 in ?? () from /lib/i386-linux-gnu/libc.so.6
#2 0xb692c785 in sigwait () from /lib/i386-linux-gnu/libc.so.6
#3 0xb6e5a342 in PLEXIL::TimeAdapter::timerWaitThreadImpl (this=0x9e4e698)
---Type <return> to continue, or q <return> to quit---
at TimeAdapter.cc:235
#4 0xb6e5740e in PLEXIL::TimeAdapter::timerWaitThread (
this_as_void_ptr=0x9e4e698) at TimeAdapter.cc:210
#5 0xb68e8d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#6 0xb69edbae in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 6 (Thread 0xadcffb40 (LWP 2829)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb69b6d06 in nanosleep () from /lib/i386-linux-gnu/libc.so.6
#2 0xb69e765d in usleep () from /lib/i386-linux-gnu/libc.so.6
#3 0x08096fe4 in RoboticsSimulation::MainLoopThread (this=0x9e4eab0)
at ../src/RoboticsSimulation.cpp:300
#4 0x08096d83 in RoboticsSimulation::mainThreadEntry (me=0x9e4eab0)
at ../src/RoboticsSimulation.cpp:242
#5 0xb68e8d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#6 0xb69edbae in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 5 (Thread 0xb07ffb40 (LWP 2828)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb69df460 in poll () from /lib/i386-linux-gnu/libc.so.6
#2 0xb56f1a3b in g_poll () from /lib/i386-linux-gnu/libglib-2.0.so.0
#3 0xb56e406e in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#4 0xb56e452b in g_main_loop_run () from /lib/i386-linux-gnu/libglib-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#5 0xb20a44aa in ?? () from /usr/lib/i386-linux-gnu/libgio-2.0.so.0
#6 0xb5707673 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#7 0xb68e8d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#8 0xb69edbae in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 4 (Thread 0xb11d3b40 (LWP 2827)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb69df460 in poll () from /lib/i386-linux-gnu/libc.so.6
#2 0xb56f1a3b in g_poll () from /lib/i386-linux-gnu/libglib-2.0.so.0
#3 0xb56e406e in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#4 0xb56e452b in g_main_loop_run () from /lib/i386-linux-gnu/libglib-2.0.so.0
#5 0xb42b0134 in ?? ()
from /usr/lib/i386-linux-gnu/gio/modules/libdconfsettings.so
#6 0xb5707673 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#7 0xb68e8d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#8 0xb69edbae in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 3 (Thread 0xb4affb40 (LWP 2826)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb68ec96b in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/i386-linux-gnu/libpthread.so.0
#2 0xb69fb4bc in pthread_cond_wait () from /lib/i386-linux-gnu/libc.so.6
#3 0xb5a9d350 in QWaitCondition::wait(QMutex*, unsigned long) ()
---Type <return> to continue, or q <return> to quit---
from /usr/lib/i386-linux-gnu/libQtCore.so.4
#4 0xb7f61a6e in SoQtSignalThread::run (this=0xb4b00678)
at SoQtSignalThread.cpp:66
#5 0xb5a9cde0 in ?? () from /usr/lib/i386-linux-gnu/libQtCore.so.4
#6 0xb68e8d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#7 0xb69edbae in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 1 (Thread 0xb5488980 (LWP 2822)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb69b6d06 in nanosleep () from /lib/i386-linux-gnu/libc.so.6
#2 0xb69e765d in usleep () from /lib/i386-linux-gnu/libc.so.6
#3 0x0806d589 in main (argc=3, argv=0xbffff244) at ../src/FlightMain.cpp:421
From: Dalal, Michael (ARC-TI)[SGT, INC] [mailto:mic...@na...]
Sent: Tuesday, June 24, 2014 1:55 PM
To: Chris LANGLEY
Cc: ple...@li...
Subject: Re: [plexil-support] When are Lookups checked for Exit and Invariant Conditions?
Chris,
Offhand, I'm not sure what's happening. However, an exec crash is pretty serious, and we don't want that to ever happen. Could you please provide a stack trace? (E.g. by opening the core file, if you can get one, with gdb, or running the application inside gdb). That will at least pinpoint the source of the problem.
Thanks,
Mike
On Jun 24, 2014, at 7:25 AM, Chris LANGLEY <Chr...@md...<mailto:Chr...@md...>>
wrote:
Dear PLEXIL Support,
I have a problem which is very similar to the one described by Catherine and Mike in the trail below.
The short description is: When using a Lookup as part of an ExitCondition in a library node, the second time the node is called, the program crashes.
Long description follows.
I am using PLEXIL within a standalone application. The plan I am running models a system with Authority To Proceed (ATP) points, where the human gives the autonomous agent permission to continue. A typical plan looks like this:
LibraryAction WaitForATP();
MasterPlan:
{
LibraryCall WaitForATP();
DoSomethingMeaningfulUntilNextATP: { ... }
LibraryCall WaitForATP();
DoSomethingElseUntilNextATP: { ... }
// ... and so on
}
Wait for ATP library node looks like this:
Boolean Lookup IsAuthorizationGiven();
WaitForATP:
{
pprint("Waiting for ATP...");
WaitActual:
{
EndCondition Lookup(IsAuthorizationGiven()) == true;
// The following pprint does not affect the bug behavior either commented or uncommented
pprint("This is a just-in-case pprint based on plexil-support notes.");
}
pprint("Done waiting for ATP");
}
The external Lookup for IsAuthorizationGiven checks a Boolean flag which can be set and cleared by a separate object in the program. The code is based on SampleAdapter.cc.
The test program does an ExecApplication::addPlan(), then waits a few seconds, then sets the ATP flag. The flag gets cleared when IsAuthorizationGiven gets the true. The test program waits a few more second, then sets the flag again. The process repeats.
TEST CASE 1:
If my external code simply sets the flag, then the first time WaitForATP is called, the Lookup is accessed once and then everything just waits. I believe this is related to the behavior discussed below.
TEST CASE 2: (The real problem)
If my external code sets the flag, then calls Adapter->propagateValueChange(State (LabelStr("IsAuthorizationGiven"), EmptyArgs), vals) [with propagateValueChange based on SampleAdapter.cc], then the first time WaitForATP is called, the behavior is correct: a pause for a moment until the external flag goes high, then execution proceeds. As soon as it gets the second call to WaitForATP and the Lookup is executed, my program crashes. I do see the "This is just in case pprint..." message, which is then followed by "User defined signal 1".
I've tried several variations on the same theme (where exactly the Lookup gets handled, whether or not to use the publish/subscribe pattern given in the SampleAdapter example, how handleValueChange and notifyOfExternalEvent get called), and the result is always either everything waits (Test Case 1), or the program crashes on the second call to WaitForATP (Test Case 2).
I've been trying to squash this one (part-time) for a week, so any help would be greatly appreciated. Am I doing something incorrectly? Alternatively, can you suggest a workaround way of designing my PLEXIL code to achieve the same desired "wait for authorization" behavior?
Thanks and best regards,
Chris
You need only ever use "Lookup", which compiles to LookupNow or LookupOnChange depending (completely) on the context. I've added a note on this in the Lookup documentation, which should answer your question.
I'll try to write a small plan that reproduces the behavior you're getting, as I don't have any new ideas at the moment. This could be an opportunity to discover and document an important property (or bug?) of PLEXIL. Any portion of your plan you can send (just to me) will be helpful.
Mike
On Apr 30, 2014, at 10:16 AM, Catherine Szeto <Catherine.Szeto@...<mailto:Catherine.Szeto@...<mailto:Catherine.Szeto@...%3cmailto:Catherine.Szeto@...>>> wrote:
Mike,
Thanks for the reply. The adapter code is based straight off of the SampleAdapter.cc, so notifyOfExternalEvent should be called when I send a value to SwitchPlanFailed, the command that changes PlanFailed.
I did consider the macro step case, as in the previous issue where I ended up putting a blank 'print' to force the step. I don't think it is the exact same case here. I tried putting the a blank 'print' in, but it didn't work, not to mention that the rest of the code in PlanA has print statements as well. I did check the node diagrams, but I'm not sure if that will help point out the issue. The EXECUTING diagram showed the EndCondition pushing the state back to Executing if it's false, so I tried putting one in for the heck of it to see if it would trigger anything. I also tried using LookupOnChange instead of plain Lookup. No luck. It seems the only thing that gets the state to update is to perform another Lookup on the PlanFailed, whether it is done in Plan A or Plan B.
What does LookupOnChange do versus LookupNow? I assumed the former checks the state if it has changed, but that doesn't seem to be true.
Catherine
From: Dalal, Michael (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)] [mailto:michael.dalal@...<http://nasa.gov><http://nasa.gov%3E/>;]
Sent: Tuesday, April 29, 2014 2:44 PM
To: Catherine Szeto
Cc: plexil-support@...<mailto:plexil-support@<mailto:plexil-support@...%3cmailto:plexil-support@>...>
Subject: Re: [plexil-support] When are Lookups checked for Exit and Invariant Conditions?
Catherine,
Is your interface adapter code for the PlanFailed flag calling ExecInterface's notifyOfExternalEvent when the flag changes? If not, that would contribute to the behavior your describe.
Still, this may be another case of the desired behavior being delayed until the plan completes a quiescence cycle or macro step. Namely, the Exit condition is not checked "immediately" when the flag changes because the plan execution has not yet quiesced, i.e. there are pending node transitions in progress. Your inserting the 'pprint' (or any other command) after that library call effectively creates a macro step boundary.
Another solution, not great but at least clear, is to enclose the code following the library call in "if not plan failed...".
Time lookups can behave differently because the interface adapter (provided by the PLEXIL framework) effectively triggers a new macro step when the time updates. (Though I'm not sure a time lookup in this context would make any difference).
I agree this is an unintuitive and complicated aspect of PLEXIL. The node transition diagrams (an appendix section in the documentation) are helpful (even essential) for understanding PLEXIL behavior at this level, yet they only describe the atomic steps of execution (see the PLEXIL semantics chapter).
I'll try to think of a better way we can explain these kinds of plan behaviors.
Mike
On Apr 29, 2014, at 10:33 AM, Catherine Szeto <Catherine.Szeto@...<mailto:Catherine.Szeto@...<mailto:Catherine.Szeto@...%3cmailto:Catherine.Szeto@...>>>
wrote:
Hello,
When I use a Lookup(time,0.1) in a Exit or Invariant Condition, I've found the result to reliably abort the plan when the time between a Lookup(time,0.1) and a start time goes beyond a specified time limit. However, the Exit and Invariant Conditions don't work if I use a Boolean variable that can be switched outside of the plan. For example, I have this case:
PlanA:
{
ExitCondition Lookup(PlanFailed) == true;
LibraryCall PlanB();
//PlanB switches PlanFailed to true
//rest of code
}
When PlanB switches PlanFailed to true, I expect PlanA to stop executing, but it doesn't. To debug, I put a pprint to output Lookup(PlanFailed) after the LibraryCall to Plan B. I suppose the Lookup caused the ExitCondition to update, because PlanA stopped executing when I put that pprint there.
I noticed this part in the reference:
"The second context for lookups is the synchronous context implied by an action's check conditions (Pre, Post, Invariant) and its body. In these contexts, a lookup is processed on demand, that is, its value is fetched at specific points in execution of the action."
I thought ExitCondition and InvariantCondition would constantly check the Lookup(PlanFailed), but that doesn't seem to be the case. Is something like my pprint the only way to get the Exit or Invariant Conditions to recheck a Boolean Lookup like Lookup(PlanFailed)?
Catherine
Chris Langley
MDA
9445 Airport Road
Brampton, ON
L6S 4J3
(905) 790-2800 x4199
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support
|
|
From: Dalal, M. (ARC-TI)[S. INC] <mic...@na...> - 2014-06-24 17:55:02
|
Chris,
Offhand, I'm not sure what's happening. However, an exec crash is pretty serious, and we don't want that to ever happen. Could you please provide a stack trace? (E.g. by opening the core file, if you can get one, with gdb, or running the application inside gdb). That will at least pinpoint the source of the problem.
Thanks,
Mike
On Jun 24, 2014, at 7:25 AM, Chris LANGLEY <Chr...@md...<mailto:Chr...@md...>>
wrote:
Dear PLEXIL Support,
I have a problem which is very similar to the one described by Catherine and Mike in the trail below.
The short description is: When using a Lookup as part of an ExitCondition in a library node, the second time the node is called, the program crashes.
Long description follows.
I am using PLEXIL within a standalone application. The plan I am running models a system with Authority To Proceed (ATP) points, where the human gives the autonomous agent permission to continue. A typical plan looks like this:
LibraryAction WaitForATP();
MasterPlan:
{
LibraryCall WaitForATP();
DoSomethingMeaningfulUntilNextATP: { … }
LibraryCall WaitForATP();
DoSomethingElseUntilNextATP: { … }
// … and so on
}
Wait for ATP library node looks like this:
Boolean Lookup IsAuthorizationGiven();
WaitForATP:
{
pprint(“Waiting for ATP…”);
WaitActual:
{
EndCondition Lookup(IsAuthorizationGiven()) == true;
// The following pprint does not affect the bug behavior either commented or uncommented
pprint(“This is a just-in-case pprint based on plexil-support notes.”);
}
pprint(“Done waiting for ATP”);
}
The external Lookup for IsAuthorizationGiven checks a Boolean flag which can be set and cleared by a separate object in the program. The code is based on SampleAdapter.cc.
The test program does an ExecApplication::addPlan(), then waits a few seconds, then sets the ATP flag. The flag gets cleared when IsAuthorizationGiven gets the true. The test program waits a few more second, then sets the flag again. The process repeats.
TEST CASE 1:
If my external code simply sets the flag, then the first time WaitForATP is called, the Lookup is accessed once and then everything just waits. I believe this is related to the behavior discussed below.
TEST CASE 2: (The real problem)
If my external code sets the flag, then calls Adapter->propagateValueChange(State (LabelStr(“IsAuthorizationGiven”), EmptyArgs), vals) [with propagateValueChange based on SampleAdapter.cc], then the first time WaitForATP is called, the behavior is correct: a pause for a moment until the external flag goes high, then execution proceeds. As soon as it gets the second call to WaitForATP and the Lookup is executed, my program crashes. I do see the “This is just in case pprint…” message, which is then followed by “User defined signal 1”.
I’ve tried several variations on the same theme (where exactly the Lookup gets handled, whether or not to use the publish/subscribe pattern given in the SampleAdapter example, how handleValueChange and notifyOfExternalEvent get called), and the result is always either everything waits (Test Case 1), or the program crashes on the second call to WaitForATP (Test Case 2).
I’ve been trying to squash this one (part-time) for a week, so any help would be greatly appreciated. Am I doing something incorrectly? Alternatively, can you suggest a workaround way of designing my PLEXIL code to achieve the same desired “wait for authorization” behavior?
Thanks and best regards,
Chris
You need only ever use "Lookup", which compiles to LookupNow or LookupOnChange depending (completely) on the context. I've added a note on this in the Lookup documentation, which should answer your question.
I'll try to write a small plan that reproduces the behavior you're getting, as I don't have any new ideas at the moment. This could be an opportunity to discover and document an important property (or bug?) of PLEXIL. Any portion of your plan you can send (just to me) will be helpful.
Mike
On Apr 30, 2014, at 10:16 AM, Catherine Szeto <Catherine.Szeto@...<mailto:Catherine.Szeto@...>> wrote:
Mike,
Thanks for the reply. The adapter code is based straight off of the SampleAdapter.cc, so notifyOfExternalEvent should be called when I send a value to SwitchPlanFailed, the command that changes PlanFailed.
I did consider the macro step case, as in the previous issue where I ended up putting a blank 'print' to force the step. I don't think it is the exact same case here. I tried putting the a blank 'print' in, but it didn't work, not to mention that the rest of the code in PlanA has print statements as well. I did check the node diagrams, but I'm not sure if that will help point out the issue. The EXECUTING diagram showed the EndCondition pushing the state back to Executing if it's false, so I tried putting one in for the heck of it to see if it would trigger anything. I also tried using LookupOnChange instead of plain Lookup. No luck. It seems the only thing that gets the state to update is to perform another Lookup on the PlanFailed, whether it is done in Plan A or Plan B.
What does LookupOnChange do versus LookupNow? I assumed the former checks the state if it has changed, but that doesn't seem to be true.
Catherine
From: Dalal, Michael (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)] [mailto:michael.dalal@...<http://nasa.gov><http://nasa.gov%3E/>;]
Sent: Tuesday, April 29, 2014 2:44 PM
To: Catherine Szeto
Cc: plexil-support@...<mailto:plexil-support@...>
Subject: Re: [plexil-support] When are Lookups checked for Exit and Invariant Conditions?
Catherine,
Is your interface adapter code for the PlanFailed flag calling ExecInterface's notifyOfExternalEvent when the flag changes? If not, that would contribute to the behavior your describe.
Still, this may be another case of the desired behavior being delayed until the plan completes a quiescence cycle or macro step. Namely, the Exit condition is not checked "immediately" when the flag changes because the plan execution has not yet quiesced, i.e. there are pending node transitions in progress. Your inserting the 'pprint' (or any other command) after that library call effectively creates a macro step boundary.
Another solution, not great but at least clear, is to enclose the code following the library call in "if not plan failed…".
Time lookups can behave differently because the interface adapter (provided by the PLEXIL framework) effectively triggers a new macro step when the time updates. (Though I'm not sure a time lookup in this context would make any difference).
I agree this is an unintuitive and complicated aspect of PLEXIL. The node transition diagrams (an appendix section in the documentation) are helpful (even essential) for understanding PLEXIL behavior at this level, yet they only describe the atomic steps of execution (see the PLEXIL semantics chapter).
I'll try to think of a better way we can explain these kinds of plan behaviors.
Mike
On Apr 29, 2014, at 10:33 AM, Catherine Szeto <Catherine.Szeto@...<mailto:Catherine.Szeto@...>>
wrote:
Hello,
When I use a Lookup(time,0.1) in a Exit or Invariant Condition, I've found the result to reliably abort the plan when the time between a Lookup(time,0.1) and a start time goes beyond a specified time limit. However, the Exit and Invariant Conditions don't work if I use a Boolean variable that can be switched outside of the plan. For example, I have this case:
PlanA:
{
ExitCondition Lookup(PlanFailed) == true;
LibraryCall PlanB();
//PlanB switches PlanFailed to true
//rest of code
}
When PlanB switches PlanFailed to true, I expect PlanA to stop executing, but it doesn't. To debug, I put a pprint to output Lookup(PlanFailed) after the LibraryCall to Plan B. I suppose the Lookup caused the ExitCondition to update, because PlanA stopped executing when I put that pprint there.
I noticed this part in the reference:
"The second context for lookups is the synchronous context implied by an action's check conditions (Pre, Post, Invariant) and its body. In these contexts, a lookup is processed on demand, that is, its value is fetched at specific points in execution of the action."
I thought ExitCondition and InvariantCondition would constantly check the Lookup(PlanFailed), but that doesn't seem to be the case. Is something like my pprint the only way to get the Exit or Invariant Conditions to recheck a Boolean Lookup like Lookup(PlanFailed)?
Catherine
Chris Langley
MDA
9445 Airport Road
Brampton, ON
L6S 4J3
(905) 790-2800 x4199
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support
|
|
From: Dalal, M. (ARC-TI)[S. INC] <mic...@na...> - 2014-06-24 17:50:50
|
Chris, Good question. No procedure for this is documented explicitly. Briefly, here are some ways you can do it, ordered roughly from best to worst. a) Add an Update node to your plan that informs the executive that it has finished. This is the basic reflection capability of PLEXIL. b) Write an ExecListener that checks for a FINISHED state on the root node. c) As you have already tried, enable the :Node:outcome debug flag and poll for it. One thing that *won't* work, as you've discovered, is checking the ExecApplication state, because that's not automatically set to SHUTDOWN. However, I think (though am not positive) that you can programmatically shutdown the application on cue from one of the approaches above. I wanted to add this information to our docs, but find that our wiki on Sourceforge is not up at the moment. I've contacted Sourceforge. Best, Mike Dear PLEXIL Support, My simple question for the day is on how to determine that a plan has finished executing. [There is also a hard question, but I’ll pose it later in a separate thread.] I am using PLEXIL from within a standalone application (i.e., not using UniversalExec with shared libraries). Currently I start an execution by issuing ExecApplication::addPlan(), and then I check for completion in my external loop by looking for ExecApplication::getApplicationState() != APP_RUNNING. When I test this approach, I can see my final pprint message and with :Node:outcome enabled I can see that the root node in my plan has completed, but getApplicaitonState() continues to return APP_RUNNING into the future. What is the actual check I should use? Or have I perhaps set up the ExecApplication incorrectly, and so it is not behaving as expected? Thanks very much. Chris ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft_______________________________________________ plexil-support mailing list ple...@li...<mailto:ple...@li...> https://lists.sourceforge.net/lists/listinfo/plexil-support |
|
From: Chris L. <Chr...@md...> - 2014-06-24 14:25:45
|
Dear PLEXIL Support,
I have a problem which is very similar to the one described by Catherine and Mike in the trail below.
The short description is: When using a Lookup as part of an ExitCondition in a library node, the second time the node is called, the program crashes.
Long description follows.
I am using PLEXIL within a standalone application. The plan I am running models a system with Authority To Proceed (ATP) points, where the human gives the autonomous agent permission to continue. A typical plan looks like this:
LibraryAction WaitForATP();
MasterPlan:
{
LibraryCall WaitForATP();
DoSomethingMeaningfulUntilNextATP: { ... }
LibraryCall WaitForATP();
DoSomethingElseUntilNextATP: { ... }
// ... and so on
}
Wait for ATP library node looks like this:
Boolean Lookup IsAuthorizationGiven();
WaitForATP:
{
pprint("Waiting for ATP...");
WaitActual:
{
EndCondition Lookup(IsAuthorizationGiven()) == true;
// The following pprint does not affect the bug behavior either commented or uncommented
pprint("This is a just-in-case pprint based on plexil-support notes.");
}
pprint("Done waiting for ATP");
}
The external Lookup for IsAuthorizationGiven checks a Boolean flag which can be set and cleared by a separate object in the program. The code is based on SampleAdapter.cc.
The test program does an ExecApplication::addPlan(), then waits a few seconds, then sets the ATP flag. The flag gets cleared when IsAuthorizationGiven gets the true. The test program waits a few more second, then sets the flag again. The process repeats.
TEST CASE 1:
If my external code simply sets the flag, then the first time WaitForATP is called, the Lookup is accessed once and then everything just waits. I believe this is related to the behavior discussed below.
TEST CASE 2: (The real problem)
If my external code sets the flag, then calls Adapter->propagateValueChange(State (LabelStr("IsAuthorizationGiven"), EmptyArgs), vals) [with propagateValueChange based on SampleAdapter.cc], then the first time WaitForATP is called, the behavior is correct: a pause for a moment until the external flag goes high, then execution proceeds. As soon as it gets the second call to WaitForATP and the Lookup is executed, my program crashes. I do see the "This is just in case pprint..." message, which is then followed by "User defined signal 1".
I've tried several variations on the same theme (where exactly the Lookup gets handled, whether or not to use the publish/subscribe pattern given in the SampleAdapter example, how handleValueChange and notifyOfExternalEvent get called), and the result is always either everything waits (Test Case 1), or the program crashes on the second call to WaitForATP (Test Case 2).
I've been trying to squash this one (part-time) for a week, so any help would be greatly appreciated. Am I doing something incorrectly? Alternatively, can you suggest a workaround way of designing my PLEXIL code to achieve the same desired "wait for authorization" behavior?
Thanks and best regards,
Chris
You need only ever use "Lookup", which compiles to LookupNow or LookupOnChange depending (completely) on the context. I've added a note on this in the Lookup documentation, which should answer your question.
I'll try to write a small plan that reproduces the behavior you're getting, as I don't have any new ideas at the moment. This could be an opportunity to discover and document an important property (or bug?) of PLEXIL. Any portion of your plan you can send (just to me) will be helpful.
Mike
On Apr 30, 2014, at 10:16 AM, Catherine Szeto <Catherine.Szeto@...<mailto:Catherine.Szeto@...>> wrote:
Mike,
Thanks for the reply. The adapter code is based straight off of the SampleAdapter.cc, so notifyOfExternalEvent should be called when I send a value to SwitchPlanFailed, the command that changes PlanFailed.
I did consider the macro step case, as in the previous issue where I ended up putting a blank 'print' to force the step. I don't think it is the exact same case here. I tried putting the a blank 'print' in, but it didn't work, not to mention that the rest of the code in PlanA has print statements as well. I did check the node diagrams, but I'm not sure if that will help point out the issue. The EXECUTING diagram showed the EndCondition pushing the state back to Executing if it's false, so I tried putting one in for the heck of it to see if it would trigger anything. I also tried using LookupOnChange instead of plain Lookup. No luck. It seems the only thing that gets the state to update is to perform another Lookup on the PlanFailed, whether it is done in Plan A or Plan B.
What does LookupOnChange do versus LookupNow? I assumed the former checks the state if it has changed, but that doesn't seem to be true.
Catherine
From: Dalal, Michael (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)] [mailto:michael.dalal@...<http://nasa.gov><http://nasa.gov%3E/>;]
Sent: Tuesday, April 29, 2014 2:44 PM
To: Catherine Szeto
Cc: plexil-support@...<mailto:plexil-support@...>
Subject: Re: [plexil-support] When are Lookups checked for Exit and Invariant Conditions?
Catherine,
Is your interface adapter code for the PlanFailed flag calling ExecInterface's notifyOfExternalEvent when the flag changes? If not, that would contribute to the behavior your describe.
Still, this may be another case of the desired behavior being delayed until the plan completes a quiescence cycle or macro step. Namely, the Exit condition is not checked "immediately" when the flag changes because the plan execution has not yet quiesced, i.e. there are pending node transitions in progress. Your inserting the 'pprint' (or any other command) after that library call effectively creates a macro step boundary.
Another solution, not great but at least clear, is to enclose the code following the library call in "if not plan failed...".
Time lookups can behave differently because the interface adapter (provided by the PLEXIL framework) effectively triggers a new macro step when the time updates. (Though I'm not sure a time lookup in this context would make any difference).
I agree this is an unintuitive and complicated aspect of PLEXIL. The node transition diagrams (an appendix section in the documentation) are helpful (even essential) for understanding PLEXIL behavior at this level, yet they only describe the atomic steps of execution (see the PLEXIL semantics chapter).
I'll try to think of a better way we can explain these kinds of plan behaviors.
Mike
On Apr 29, 2014, at 10:33 AM, Catherine Szeto <Catherine.Szeto@...<mailto:Catherine.Szeto@...>>
wrote:
Hello,
When I use a Lookup(time,0.1) in a Exit or Invariant Condition, I've found the result to reliably abort the plan when the time between a Lookup(time,0.1) and a start time goes beyond a specified time limit. However, the Exit and Invariant Conditions don't work if I use a Boolean variable that can be switched outside of the plan. For example, I have this case:
PlanA:
{
ExitCondition Lookup(PlanFailed) == true;
LibraryCall PlanB();
//PlanB switches PlanFailed to true
//rest of code
}
When PlanB switches PlanFailed to true, I expect PlanA to stop executing, but it doesn't. To debug, I put a pprint to output Lookup(PlanFailed) after the LibraryCall to Plan B. I suppose the Lookup caused the ExitCondition to update, because PlanA stopped executing when I put that pprint there.
I noticed this part in the reference:
"The second context for lookups is the synchronous context implied by an action's check conditions (Pre, Post, Invariant) and its body. In these contexts, a lookup is processed on demand, that is, its value is fetched at specific points in execution of the action."
I thought ExitCondition and InvariantCondition would constantly check the Lookup(PlanFailed), but that doesn't seem to be the case. Is something like my pprint the only way to get the Exit or Invariant Conditions to recheck a Boolean Lookup like Lookup(PlanFailed)?
Catherine
Chris Langley
MDA
9445 Airport Road
Brampton, ON
L6S 4J3
(905) 790-2800 x4199
|
2 messages has been excluded from this view by a project administrator.
