Re: [plexil-support] Assignment in a child node fails when it involves an InvariantCondition

[Fry, C. R. {C. (ARC-TI)[S. INC] <chu...@na...>]

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.