plexil-support — A mailing list for PLEXIL technical support.

Re: [plexil-support] Memory issue

[Dalal, M. (ARC-TI)[S. G. T. I. (S. Inc.)] <mic...@na...>]

Catherine,

3.5 GB does sound excessive.  Some questions…

Can you provide some quantitative information about the plans: total number of nodes (<Node> elements in the .plx files), total number of lines of the .plx files?

Can you characterize the memory usage?  Does plexilexec occupy 3.5 GB upon loading the Main plan (which effectively loads all the library plans)?  Or after running for a while?  Does memory size increase monotonically?

No suggestions offhand for reducing the memory footprint, but I'll talk about this with others, and  the information above will help.   I don't think the Plexil Viewer or the related startup options are an issue.

Mike


On Mar 12, 2014, at 8:14 AM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>> wrote:

Hello,
                We have a Main plan that will eventually have 32 plans with LibraryAction dependencies. We tried running the plan through the plexilexec with 25 of these dependent plans integrated. The plexilexec is using about 3.5 GB of memory, which seems excessive. We have several more plans to go that will be fairly large, so this is going to be a growing problem. Is there anything we can do to better manage the memory being used by the plexilexec to make the memory use more reasonable?

Thanks,
Catherine
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support

Re: [plexil-support] Memory issue

[Catherine S. <Cat...@ti...>]

To clarify, we are running with the -v option but not -b, so we have the Plexil viewer but not the blocking/debugging option.

From: Catherine Szeto
Sent: Wednesday, March 12, 2014 10:15 AM
To: ple...@li...
Subject: Memory issue

Hello,
                We have a Main plan that will eventually have 32 plans with LibraryAction dependencies. We tried running the plan through the plexilexec with 25 of these dependent plans integrated. The plexilexec is using about 3.5 GB of memory, which seems excessive. We have several more plans to go that will be fairly large, so this is going to be a growing problem. Is there anything we can do to better manage the memory being used by the plexilexec to make the memory use more reasonable?
Thanks,
Catherine

[plexil-support] Memory issue

[Catherine S. <Cat...@ti...>]

Hello,
                We have a Main plan that will eventually have 32 plans with LibraryAction dependencies. We tried running the plan through the plexilexec with 25 of these dependent plans integrated. The plexilexec is using about 3.5 GB of memory, which seems excessive. We have several more plans to go that will be fairly large, so this is going to be a growing problem. Is there anything we can do to better manage the memory being used by the plexilexec to make the memory use more reasonable?

Thanks,
Catherine

Re: [plexil-support] How to fail the parent plan if LibraryCalled plan fails?

[Dalal, M. (ARC-TI)[S. G. T. I. (S. Inc.)] <mic...@na...>]

Hi Catherine,

A plan fails if and only if one of its check conditions (Pre, Post, Invariant) fail.  The default value of these conditions is true, so if you don't use them, there's no failure.  You just need to decide which one is best for your parent and child plans to achieve the desired results.

Cheers,
Mike


Hello,
        I thought that if a parent plan calls another plan through a LibraryCall and the child plan fails, the parent plan fails as well. I tested this and saw that this wasn’t the case. Is there a way to make this possible?

Catherine Szeto

[plexil-support] How to fail the parent plan if LibraryCalled plan fails?

[Catherine S. <Cat...@ti...>]

Hello,
        I thought that if a parent plan calls another plan through a LibraryCall and the child plan fails, the parent plan fails as well. I tested this and saw that this wasn't the case. Is there a way to make this possible?

Catherine Szeto

Re: [plexil-support] Ideas for running a continuous loop that calls other plans when needed?

[Dalal, M. (ARC-TI)[S. G. T. I. (S. Inc.)] <mic...@na...>]

The most helpful documentation in understanding the details of PLEXIL execution, especially when a plan has many interacting Conditions, is the node state transition diagrams found in the appendix of the user documentation on Sourceforge.   Unfortunately, the flexibility of PLEXIL comes at a price in complexity -- there are over a dozen diagrams for describing the execution semantics. 

But your suggestion is noted.  I'll also look into the history of the RepeatCondition-in-root-node problem.

Cheers,
Mike



> This is an interesting idea. The cycling issue might have been the one causing the problems with the StartCondition approach we had. Thanks for noting the issues about the RepeatCondition, as we were beginning to wonder if there were limits to it. 
> 
> If I can put a suggestion for the plexil documentation, I would like to see more details added for the Conditions. For example, it looks like a node with a StartCondition will be stuck at WAITING until its StartCondition is met, versus SKIPPED like I thought it might be. 
> 
> Thanks,
> Catherine
> 
> -----Original Message-----
> From: Dalal, Michael (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)] [mailto:mic...@na...] 
> Sent: Friday, February 28, 2014 2:25 PM
> To: Catherine Szeto
> Cc: ple...@li...
> Subject: Re: [plexil-support] Ideas for running a continuous loop that calls other plans when needed?
> 
> I just thought of something else.  Perhaps Main is just not cycling to catch UI variable changes.  Below is one way to induce the cycling within PLEXIL.  Note that Main is a Sequence again, with two actions: first a Concurrence to check all the UI variables, and then a Wait.
> 
> Like I suggested for the original plan, you can also experiment with the location of the Repeat Condition here, i.e. move it into the sub-plans.  I'm now recalling issues we've had with repeat conditions on root nodes.  I'd have to check our bug database history for more information.
> 
> Hope this helps,
> Mike
> 
> 
> 
> Main:
> {
>  RepeatCondition mainOn; //mainOn is always set to true
> 
>  TestVariables: Concurrence
>  {
>      PlanA:
>      {
>           StartCondition Lookup(PlanAUI) == 1;
>           SkipCondition Lookup(PlanAUI) != 1;
> 
>           LibraryCall PlanA();
>          //switch PlanAUI back to 0;
>      }
> 
>      // insert PlanB, etc here, following same pattern
> 
>  } // end TestVariables
> 
>  Sleep: 
>  {  
>     Wait 1.0;  // sleep 1.0 time units -- use whatever value makes sense
>  }
> }  //end of Main
> 
> 
> 

Re: [plexil-support] Ideas for running a continuous loop that calls other plans when needed?

[Dalal, M. (ARC-TI)[S. G. T. I. (S. Inc.)] <mic...@na...>]

Glad to hear you found the problem, and that it was so easy to fix.  In the telecon with a few JSC folks earlier this week, Chuck and I had mentioned to NOT use the '-b' option for another reason -- so that the plan does not wait for viewer interaction to start.

I still think the more elegant solution would not have explicit loops, but if your WHILE approach is working and you're happy with it, that's more important.   I didn't know the sub-plans had Preconditions; these would fail a parent Sequence when failed, but not a parent Concurrence or UncheckedSequence.

Cheers,
Mike



I may have run across the numbingly simple, Captain Obvious cause of the issue, to my embarrassment. I executed the plans and left off the –b by accident this time. The plans executed very quickly. I went back to the documentation and saw the note about –b: Note that use of this option significantly slows the execution of the plan.”. I checked with the team and the speed meets our needs now. For debugging purposes, we will have to start the plan nearly a day ahead of time before testing it when it’s connected to the rest of the system, but we can work with that.

We are going to use the Concurrence concept like you suggested. We noticed that the RepeatCondition is ignored and the whole plan fails if the subplan nodes fail, so we’re using a big while loop instead, and put PreConditions instead of StartConditions, since StartConditions seem to keep hanging for us in this plan. The while loop keeps going despite the failed PreConditions, so it is working.

Thanks for your help again, and sorry for not catching the –b part earlier.

Catherine

From: Dalal, Michael (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)] [mailto:mic...@na...<http://nasa.gov>]
Sent: Friday, February 28, 2014 2:03 PM
To: Catherine Szeto
Cc: ple...@li...<mailto:ple...@li...>
Subject: Re: [plexil-support] Ideas for running a continuous loop that calls other plans when needed?

Thanks for the additional information.  Having sub-plans run concurrently or more than once is just fine and shouldn't pose any significant challenge -- I just wanted to make sure the proper logic is coded.  As it stands, you get both features.

Yes, I should have caught the fact that the master plan was a Sequence and not a Concurrence -- you definitely want the latter, otherwise the plan would wait until the first action executed (unless you added Skip Conditions, but that's not a better approach overall).

I'm stumped about the slowness in approach (2).  The PLEXIL executive should actually be very fast in responding to the changes in your UI variables.  I'm suspecting some delay in how the variable updates are getting to the executive, and the source would be in your interface adapter, or something in the external application (UI) itself.

To debug this further in PLEXIL alone, try removing the Repeat Condition and see if you can trigger individual sub-plan(s) once, and how fast that is.  In addition, try moving the Repeat Condition to the sub-plans, removing it from Main.  One would look like this:

   PlanA:
   {
     StartCondition Lookup(PlanAUI) == 1;
     RepeatCondition Lookup(PlanAUI) == 1;
     LibraryCall PlanA();
     //switch PlanAUI back to 0;
   }

You need both the Start and Repeat conditions.

Good luck,
Mike




On Feb 27, 2014, at 8:19 AM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>> wrote:


To give some background, the intention of the plan is to pick up “UI variables” that are set to 1 from the code connected to the UI (i.e. when user selects on the UI to run a plan, that plan’s UI variable is switched to 1). Then the Main.ple plan, which is constantly watching these variables, will call any subplans that have their UI variable set to 1. Then the UI variable is reset to 0.

              Can sub-plans run concurrently, or just one at at time?

1.       I’ll need to get confirmation from the customer for the first question, but right now we don’t have any intention of stopping a user from calling multiple sub-plans from the UI, which would switch on multiple Lookup variables at the same time. Right now, the expected use is for the user to call for one subplan, wait for it to finish, then call another. I’ll let you know more details after I get word from the customer.
    Can a sub-plan run more than once?

2.       Yes, in the sense that a user will often call for a sub-plan, wait for it to finish, perhaps call another plan and finish, then call the same previous plan again. If a user calls for a subplan, we want to run it only once per call.

We had no idea why approach #1 would be so slow either since it was a simple if/elseif statement, albeit rather large. For approach 2, I did some experimenting with a separate plan. It seems like in a sequence, execution does not proceed until each subaction has their StartCondition fulfilled when it’s that subaction’s turn. Is that correct behavior, or was I possibly seeing some other issue? To note, for the Main plan, we did try using Concurrence instead of a Sequence for approach 2, and we got the same results.

Catherine
From: Dalal, Michael (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)] [mailto:mic...@na...<http://nasa.gov>]
Sent: Wednesday, February 26, 2014 5:07 PM
To: Catherine Szeto
Cc: ple...@li...<mailto:ple...@li...>
Subject: Re: [plexil-support] Ideas for running a continuous loop that calls other plans when needed?

Interesting plan, and what you want should be doable, but I need to understand it better.

Can sub-plans run concurrently, or just one at at time?
Can a sub-plan run more than once?

The Start Condition approach (2) sounds like the best one, but perhaps some additional conditions are needed, depending on the desired semantics.

Approach (3) is probably off -- Preconditions are specifically for failing a node.  I don't know why (1) would be so slow.  For both (1) and (2) I suspect some problem in how the external interface is managing macro steps (quiescence cycles) in the plan.  It is responsible for the desired wakeups, and somehow the executive is not getting them (or getting them fast enough).  Would need more information (e.g. if your application is multi-threaded, it could be a thread issue).  But first let's get the semantics of the plan right….

Mike


On Feb 26, 2014, at 9:23 AM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>>
 wrote:



Hello all,
             We have a critical Main plan that continuously needs to check for certain Lookup variables. Once the variables are switched to a certain value, a plan is called depending on which variable, while the Main plan continues to cycle to keep checking the Lookup variables. We are trying Main with just three plans to check for right now, but it eventually can check for as many as 60 plans. Here’s pseudocode of what’s going on:

Main:
{
       RepeatCondition mainOn; //mainOn is always set to true

       PlanA:
      {
            StartCondition Lookup(PlanAUI) == 1;

           LibraryCall PlanA();
          //switch PlanAUI back to 0;
      }


       PlanB:
      {
            StartCondition Lookup(PlanBUI) == 1;

           LibraryCall PlanB();
           //switch PlanBUI back to 0;

      }

       PlanC:
      {
            StartCondition Lookup(PlanCUI) == 1;

           LibraryCall PlanC();
           //switch PlanCUI back to 0;

      }


}//end of Main

We tried the following scenarios:
1.       if/elseif statements instead of StartConditions. This worked, but it was ridiculously slow. For just 3 if/elseif statements, it took 10 minutes after PlanAUI was switched to 1 for Main to go through all three of the possible plans and then all the nested plans that those plans called and mark them as SKIPPED, then finally call PlanA. The three plans and the ones that they call are all simple. After the Main took the initial 10 min to mark all the SKIPPED plans, the following loop iterations were a lot faster and called PlanA much more quickly when its Lookup variable was switched.

2.       The StartCondition scenario as described in the pseudocode. This did not work at all. All three nodes were marked as WAITING for at least 15 min after the PlanAUI variable was switched to 1. It seems like after the nodes check their StartConditions and see that they are false through the first iteration, they won’t “wake up” again for the following loop iterations when the appropriate Lookup variables are switched to 1.

3.       Instead of StartConditions, we used PreConditions. This quickly failed all the plans before the PlanAUI variable could be switched to 1 and Main.ple failed as a result (expected, but worth a shot).

This is an important plan, so any suggestions would be appreciated! Thank you.

Catherine
------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support

Re: [plexil-support] Ideas for running a continuous loop that calls other plans when needed?

[Catherine S. <Cat...@ti...>]

This is an interesting idea. The cycling issue might have been the one causing the problems with the StartCondition approach we had. Thanks for noting the issues about the RepeatCondition, as we were beginning to wonder if there were limits to it. 

If I can put a suggestion for the plexil documentation, I would like to see more details added for the Conditions. For example, it looks like a node with a StartCondition will be stuck at WAITING until its StartCondition is met, versus SKIPPED like I thought it might be. 

Thanks,
Catherine

-----Original Message-----
From: Dalal, Michael (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)] [mailto:mic...@na...] 
Sent: Friday, February 28, 2014 2:25 PM
To: Catherine Szeto
Cc: ple...@li...
Subject: Re: [plexil-support] Ideas for running a continuous loop that calls other plans when needed?

I just thought of something else.  Perhaps Main is just not cycling to catch UI variable changes.  Below is one way to induce the cycling within PLEXIL.  Note that Main is a Sequence again, with two actions: first a Concurrence to check all the UI variables, and then a Wait.

Like I suggested for the original plan, you can also experiment with the location of the Repeat Condition here, i.e. move it into the sub-plans.  I'm now recalling issues we've had with repeat conditions on root nodes.  I'd have to check our bug database history for more information.

Hope this helps,
Mike



Main:
{
  RepeatCondition mainOn; //mainOn is always set to true

  TestVariables: Concurrence
  {
      PlanA:
      {
           StartCondition Lookup(PlanAUI) == 1;
           SkipCondition Lookup(PlanAUI) != 1;
  
           LibraryCall PlanA();
          //switch PlanAUI back to 0;
      }
 
      // insert PlanB, etc here, following same pattern

  } // end TestVariables

  Sleep: 
  {  
     Wait 1.0;  // sleep 1.0 time units -- use whatever value makes sense
  }
}  //end of Main
 
 

Re: [plexil-support] Ideas for running a continuous loop that calls other plans when needed?

[Catherine S. <Cat...@ti...>]

I may have run across the numbingly simple, Captain Obvious cause of the issue, to my embarrassment. I executed the plans and left off the -b by accident this time. The plans executed very quickly. I went back to the documentation and saw the note about -b: Note that use of this option significantly slows the execution of the plan.". I checked with the team and the speed meets our needs now. For debugging purposes, we will have to start the plan nearly a day ahead of time before testing it when it's connected to the rest of the system, but we can work with that.

We are going to use the Concurrence concept like you suggested. We noticed that the RepeatCondition is ignored and the whole plan fails if the subplan nodes fail, so we're using a big while loop instead, and put PreConditions instead of StartConditions, since StartConditions seem to keep hanging for us in this plan. The while loop keeps going despite the failed PreConditions, so it is working.

Thanks for your help again, and sorry for not catching the -b part earlier.

Catherine

From: Dalal, Michael (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)] [mailto:mic...@na...]
Sent: Friday, February 28, 2014 2:03 PM
To: Catherine Szeto
Cc: ple...@li...
Subject: Re: [plexil-support] Ideas for running a continuous loop that calls other plans when needed?

Thanks for the additional information.  Having sub-plans run concurrently or more than once is just fine and shouldn't pose any significant challenge -- I just wanted to make sure the proper logic is coded.  As it stands, you get both features.

Yes, I should have caught the fact that the master plan was a Sequence and not a Concurrence -- you definitely want the latter, otherwise the plan would wait until the first action executed (unless you added Skip Conditions, but that's not a better approach overall).

I'm stumped about the slowness in approach (2).  The PLEXIL executive should actually be very fast in responding to the changes in your UI variables.  I'm suspecting some delay in how the variable updates are getting to the executive, and the source would be in your interface adapter, or something in the external application (UI) itself.

To debug this further in PLEXIL alone, try removing the Repeat Condition and see if you can trigger individual sub-plan(s) once, and how fast that is.  In addition, try moving the Repeat Condition to the sub-plans, removing it from Main.  One would look like this:

   PlanA:
   {
     StartCondition Lookup(PlanAUI) == 1;
     RepeatCondition Lookup(PlanAUI) == 1;
     LibraryCall PlanA();
     //switch PlanAUI back to 0;
   }

You need both the Start and Repeat conditions.

Good luck,
Mike




On Feb 27, 2014, at 8:19 AM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>> wrote:


To give some background, the intention of the plan is to pick up "UI variables" that are set to 1 from the code connected to the UI (i.e. when user selects on the UI to run a plan, that plan's UI variable is switched to 1). Then the Main.ple plan, which is constantly watching these variables, will call any subplans that have their UI variable set to 1. Then the UI variable is reset to 0.

              Can sub-plans run concurrently, or just one at at time?

1.       I'll need to get confirmation from the customer for the first question, but right now we don't have any intention of stopping a user from calling multiple sub-plans from the UI, which would switch on multiple Lookup variables at the same time. Right now, the expected use is for the user to call for one subplan, wait for it to finish, then call another. I'll let you know more details after I get word from the customer.
    Can a sub-plan run more than once?

2.       Yes, in the sense that a user will often call for a sub-plan, wait for it to finish, perhaps call another plan and finish, then call the same previous plan again. If a user calls for a subplan, we want to run it only once per call.

We had no idea why approach #1 would be so slow either since it was a simple if/elseif statement, albeit rather large. For approach 2, I did some experimenting with a separate plan. It seems like in a sequence, execution does not proceed until each subaction has their StartCondition fulfilled when it's that subaction's turn. Is that correct behavior, or was I possibly seeing some other issue? To note, for the Main plan, we did try using Concurrence instead of a Sequence for approach 2, and we got the same results.

Catherine
From: Dalal, Michael (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)] [mailto:mic...@na...<http://nasa.gov>]
Sent: Wednesday, February 26, 2014 5:07 PM
To: Catherine Szeto
Cc: ple...@li...<mailto:ple...@li...>
Subject: Re: [plexil-support] Ideas for running a continuous loop that calls other plans when needed?

Interesting plan, and what you want should be doable, but I need to understand it better.

Can sub-plans run concurrently, or just one at at time?
Can a sub-plan run more than once?

The Start Condition approach (2) sounds like the best one, but perhaps some additional conditions are needed, depending on the desired semantics.

Approach (3) is probably off -- Preconditions are specifically for failing a node.  I don't know why (1) would be so slow.  For both (1) and (2) I suspect some problem in how the external interface is managing macro steps (quiescence cycles) in the plan.  It is responsible for the desired wakeups, and somehow the executive is not getting them (or getting them fast enough).  Would need more information (e.g. if your application is multi-threaded, it could be a thread issue).  But first let's get the semantics of the plan right....

Mike


On Feb 26, 2014, at 9:23 AM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>>
 wrote:



Hello all,
             We have a critical Main plan that continuously needs to check for certain Lookup variables. Once the variables are switched to a certain value, a plan is called depending on which variable, while the Main plan continues to cycle to keep checking the Lookup variables. We are trying Main with just three plans to check for right now, but it eventually can check for as many as 60 plans. Here's pseudocode of what's going on:

Main:
{
       RepeatCondition mainOn; //mainOn is always set to true

       PlanA:
      {
            StartCondition Lookup(PlanAUI) == 1;

           LibraryCall PlanA();
          //switch PlanAUI back to 0;
      }


       PlanB:
      {
            StartCondition Lookup(PlanBUI) == 1;

           LibraryCall PlanB();
           //switch PlanBUI back to 0;

      }

       PlanC:
      {
            StartCondition Lookup(PlanCUI) == 1;

           LibraryCall PlanC();
           //switch PlanCUI back to 0;

      }


}//end of Main

We tried the following scenarios:
1.       if/elseif statements instead of StartConditions. This worked, but it was ridiculously slow. For just 3 if/elseif statements, it took 10 minutes after PlanAUI was switched to 1 for Main to go through all three of the possible plans and then all the nested plans that those plans called and mark them as SKIPPED, then finally call PlanA. The three plans and the ones that they call are all simple. After the Main took the initial 10 min to mark all the SKIPPED plans, the following loop iterations were a lot faster and called PlanA much more quickly when its Lookup variable was switched.

2.       The StartCondition scenario as described in the pseudocode. This did not work at all. All three nodes were marked as WAITING for at least 15 min after the PlanAUI variable was switched to 1. It seems like after the nodes check their StartConditions and see that they are false through the first iteration, they won't "wake up" again for the following loop iterations when the appropriate Lookup variables are switched to 1.

3.       Instead of StartConditions, we used PreConditions. This quickly failed all the plans before the PlanAUI variable could be switched to 1 and Main.ple failed as a result (expected, but worth a shot).

This is an important plan, so any suggestions would be appreciated! Thank you.

Catherine
------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support

Re: [plexil-support] Ideas for running a continuous loop that calls other plans when needed?

[Dalal, M. (ARC-TI)[S. G. T. I. (S. Inc.)] <mic...@na...>]

I just thought of something else.  Perhaps Main is just not cycling to catch UI variable changes.  Below is one way to induce the cycling within PLEXIL.  Note that Main is a Sequence again, with two actions: first a Concurrence to check all the UI variables, and then a Wait.

Like I suggested for the original plan, you can also experiment with the location of the Repeat Condition here, i.e. move it into the sub-plans.  I'm now recalling issues we've had with repeat conditions on root nodes.  I'd have to check our bug database history for more information.

Hope this helps,
Mike



Main:
{
  RepeatCondition mainOn; //mainOn is always set to true

  TestVariables: Concurrence
  {
      PlanA:
      {
           StartCondition Lookup(PlanAUI) == 1;
           SkipCondition Lookup(PlanAUI) != 1;
  
           LibraryCall PlanA();
          //switch PlanAUI back to 0;
      }
 
      // insert PlanB, etc here, following same pattern

  } // end TestVariables

  Sleep: 
  {  
     Wait 1.0;  // sleep 1.0 time units -- use whatever value makes sense
  }
}  //end of Main
 
 

Re: [plexil-support] Ideas for running a continuous loop that calls other plans when needed?

[Dalal, M. (ARC-TI)[S. G. T. I. (S. Inc.)] <mic...@na...>]

Thanks for the additional information.  Having sub-plans run concurrently or more than once is just fine and shouldn't pose any significant challenge -- I just wanted to make sure the proper logic is coded.  As it stands, you get both features.

Yes, I should have caught the fact that the master plan was a Sequence and not a Concurrence -- you definitely want the latter, otherwise the plan would wait until the first action executed (unless you added Skip Conditions, but that's not a better approach overall).

I'm stumped about the slowness in approach (2).  The PLEXIL executive should actually be very fast in responding to the changes in your UI variables.  I'm suspecting some delay in how the variable updates are getting to the executive, and the source would be in your interface adapter, or something in the external application (UI) itself.

To debug this further in PLEXIL alone, try removing the Repeat Condition and see if you can trigger individual sub-plan(s) once, and how fast that is.  In addition, try moving the Repeat Condition to the sub-plans, removing it from Main.  One would look like this:

   PlanA:
   {
     StartCondition Lookup(PlanAUI) == 1;
     RepeatCondition Lookup(PlanAUI) == 1;

     LibraryCall PlanA();
     //switch PlanAUI back to 0;
   }

You need both the Start and Repeat conditions.

Good luck,
Mike




On Feb 27, 2014, at 8:19 AM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>> wrote:

To give some background, the intention of the plan is to pick up “UI variables” that are set to 1 from the code connected to the UI (i.e. when user selects on the UI to run a plan, that plan’s UI variable is switched to 1). Then the Main.ple plan, which is constantly watching these variables, will call any subplans that have their UI variable set to 1. Then the UI variable is reset to 0.

              Can sub-plans run concurrently, or just one at at time?

1.       I’ll need to get confirmation from the customer for the first question, but right now we don’t have any intention of stopping a user from calling multiple sub-plans from the UI, which would switch on multiple Lookup variables at the same time. Right now, the expected use is for the user to call for one subplan, wait for it to finish, then call another. I’ll let you know more details after I get word from the customer.
    Can a sub-plan run more than once?

2.       Yes, in the sense that a user will often call for a sub-plan, wait for it to finish, perhaps call another plan and finish, then call the same previous plan again. If a user calls for a subplan, we want to run it only once per call.

We had no idea why approach #1 would be so slow either since it was a simple if/elseif statement, albeit rather large. For approach 2, I did some experimenting with a separate plan. It seems like in a sequence, execution does not proceed until each subaction has their StartCondition fulfilled when it’s that subaction’s turn. Is that correct behavior, or was I possibly seeing some other issue? To note, for the Main plan, we did try using Concurrence instead of a Sequence for approach 2, and we got the same results.

Catherine
From: Dalal, Michael (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)] [mailto:mic...@na...<http://nasa.gov>]
Sent: Wednesday, February 26, 2014 5:07 PM
To: Catherine Szeto
Cc: ple...@li...<mailto:ple...@li...>
Subject: Re: [plexil-support] Ideas for running a continuous loop that calls other plans when needed?

Interesting plan, and what you want should be doable, but I need to understand it better.

Can sub-plans run concurrently, or just one at at time?
Can a sub-plan run more than once?

The Start Condition approach (2) sounds like the best one, but perhaps some additional conditions are needed, depending on the desired semantics.

Approach (3) is probably off -- Preconditions are specifically for failing a node.  I don't know why (1) would be so slow.  For both (1) and (2) I suspect some problem in how the external interface is managing macro steps (quiescence cycles) in the plan.  It is responsible for the desired wakeups, and somehow the executive is not getting them (or getting them fast enough).  Would need more information (e.g. if your application is multi-threaded, it could be a thread issue).  But first let's get the semantics of the plan right….

Mike


On Feb 26, 2014, at 9:23 AM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>>
 wrote:


Hello all,
             We have a critical Main plan that continuously needs to check for certain Lookup variables. Once the variables are switched to a certain value, a plan is called depending on which variable, while the Main plan continues to cycle to keep checking the Lookup variables. We are trying Main with just three plans to check for right now, but it eventually can check for as many as 60 plans. Here’s pseudocode of what’s going on:

Main:
{
       RepeatCondition mainOn; //mainOn is always set to true

       PlanA:
      {
            StartCondition Lookup(PlanAUI) == 1;

           LibraryCall PlanA();
          //switch PlanAUI back to 0;
      }


       PlanB:
      {
            StartCondition Lookup(PlanBUI) == 1;

           LibraryCall PlanB();
           //switch PlanBUI back to 0;

      }

       PlanC:
      {
            StartCondition Lookup(PlanCUI) == 1;

           LibraryCall PlanC();
           //switch PlanCUI back to 0;

      }


}//end of Main

We tried the following scenarios:
1.       if/elseif statements instead of StartConditions. This worked, but it was ridiculously slow. For just 3 if/elseif statements, it took 10 minutes after PlanAUI was switched to 1 for Main to go through all three of the possible plans and then all the nested plans that those plans called and mark them as SKIPPED, then finally call PlanA. The three plans and the ones that they call are all simple. After the Main took the initial 10 min to mark all the SKIPPED plans, the following loop iterations were a lot faster and called PlanA much more quickly when its Lookup variable was switched.

2.       The StartCondition scenario as described in the pseudocode. This did not work at all. All three nodes were marked as WAITING for at least 15 min after the PlanAUI variable was switched to 1. It seems like after the nodes check their StartConditions and see that they are false through the first iteration, they won’t “wake up” again for the following loop iterations when the appropriate Lookup variables are switched to 1.

3.       Instead of StartConditions, we used PreConditions. This quickly failed all the plans before the PlanAUI variable could be switched to 1 and Main.ple failed as a result (expected, but worth a shot).

This is an important plan, so any suggestions would be appreciated! Thank you.

Catherine
------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support

Re: [plexil-support] Ideas for running a continuous loop that calls other plans when needed?

[Catherine S. <Cat...@ti...>]

To give some background, the intention of the plan is to pick up "UI variables" that are set to 1 from the code connected to the UI (i.e. when user selects on the UI to run a plan, that plan's UI variable is switched to 1). Then the Main.ple plan, which is constantly watching these variables, will call any subplans that have their UI variable set to 1. Then the UI variable is reset to 0.

              Can sub-plans run concurrently, or just one at at time?


1.       I'll need to get confirmation from the customer for the first question, but right now we don't have any intention of stopping a user from calling multiple sub-plans from the UI, which would switch on multiple Lookup variables at the same time. Right now, the expected use is for the user to call for one subplan, wait for it to finish, then call another. I'll let you know more details after I get word from the customer.
    Can a sub-plan run more than once?


2.       Yes, in the sense that a user will often call for a sub-plan, wait for it to finish, perhaps call another plan and finish, then call the same previous plan again. If a user calls for a subplan, we want to run it only once per call.

We had no idea why approach #1 would be so slow either since it was a simple if/elseif statement, albeit rather large. For approach 2, I did some experimenting with a separate plan. It seems like in a sequence, execution does not proceed until each subaction has their StartCondition fulfilled when it's that subaction's turn. Is that correct behavior, or was I possibly seeing some other issue? To note, for the Main plan, we did try using Concurrence instead of a Sequence for approach 2, and we got the same results.

Catherine
From: Dalal, Michael (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)] [mailto:mic...@na...]
Sent: Wednesday, February 26, 2014 5:07 PM
To: Catherine Szeto
Cc: ple...@li...
Subject: Re: [plexil-support] Ideas for running a continuous loop that calls other plans when needed?

Interesting plan, and what you want should be doable, but I need to understand it better.

Can sub-plans run concurrently, or just one at at time?
Can a sub-plan run more than once?

The Start Condition approach (2) sounds like the best one, but perhaps some additional conditions are needed, depending on the desired semantics.

Approach (3) is probably off -- Preconditions are specifically for failing a node.  I don't know why (1) would be so slow.  For both (1) and (2) I suspect some problem in how the external interface is managing macro steps (quiescence cycles) in the plan.  It is responsible for the desired wakeups, and somehow the executive is not getting them (or getting them fast enough).  Would need more information (e.g. if your application is multi-threaded, it could be a thread issue).  But first let's get the semantics of the plan right....

Mike


On Feb 26, 2014, at 9:23 AM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>>
 wrote:


Hello all,
             We have a critical Main plan that continuously needs to check for certain Lookup variables. Once the variables are switched to a certain value, a plan is called depending on which variable, while the Main plan continues to cycle to keep checking the Lookup variables. We are trying Main with just three plans to check for right now, but it eventually can check for as many as 60 plans. Here's pseudocode of what's going on:

Main:
{
       RepeatCondition mainOn; //mainOn is always set to true

       PlanA:
      {
            StartCondition Lookup(PlanAUI) == 1;

           LibraryCall PlanA();
          //switch PlanAUI back to 0;
      }


       PlanB:
      {
            StartCondition Lookup(PlanBUI) == 1;

           LibraryCall PlanB();
           //switch PlanBUI back to 0;

      }

       PlanC:
      {
            StartCondition Lookup(PlanCUI) == 1;

           LibraryCall PlanC();
           //switch PlanCUI back to 0;

      }


}//end of Main

We tried the following scenarios:
1.       if/elseif statements instead of StartConditions. This worked, but it was ridiculously slow. For just 3 if/elseif statements, it took 10 minutes after PlanAUI was switched to 1 for Main to go through all three of the possible plans and then all the nested plans that those plans called and mark them as SKIPPED, then finally call PlanA. The three plans and the ones that they call are all simple. After the Main took the initial 10 min to mark all the SKIPPED plans, the following loop iterations were a lot faster and called PlanA much more quickly when its Lookup variable was switched.

2.       The StartCondition scenario as described in the pseudocode. This did not work at all. All three nodes were marked as WAITING for at least 15 min after the PlanAUI variable was switched to 1. It seems like after the nodes check their StartConditions and see that they are false through the first iteration, they won't "wake up" again for the following loop iterations when the appropriate Lookup variables are switched to 1.

3.       Instead of StartConditions, we used PreConditions. This quickly failed all the plans before the PlanAUI variable could be switched to 1 and Main.ple failed as a result (expected, but worth a shot).

This is an important plan, so any suggestions would be appreciated! Thank you.

Catherine
------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support

Re: [plexil-support] Concurrence not working (previously sent before, but this time without attachment)

[Dalal, M. (ARC-TI)[S. G. T. I. (S. Inc.)] <mic...@na...>]

Glad that did the trick.  Thanks for the feedback regarding Skipped actions in a Sequence.  I'll update our documentation on Sequence.

Mike


On Feb 26, 2014, at 2:45 PM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>>
 wrote:

I tried your suggestion of using the StartCondition for the timeout and it worked, thank you.

As for the ApplyVacuumTo succeeding even with skipped subactions, I do see that happening. I tested this by putting a SkipCondition in a subaction that was guaranteed to be skipped; I’m not sure if this makes a difference to you.

From: Dalal, Michael (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)] [mailto:mic...@na...<http://nasa.gov>]
Sent: Tuesday, February 18, 2014 5:16 PM
To: Catherine Szeto
Cc: Fry, Charles R. {Chuck} (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)]; ple...@li...<mailto:ple...@li...>
Subject: Re: [plexil-support] Concurrence not working (previously sent before, but this time without attachment)

I see something else, which is probably unrelated to the concurrency problem, but wanted to point out.

ApplyVacuumTo_Sequence is a normal sequence, and according to the reference doc, "A Sequence succeeds if and only if all its actions succeed…".   One action in your sequence has outcome Skipped.  From looking at the code, we check only for a Failure outcome, so ApplyVacuumTo_Sequence should succeed even if actions in it are skipped.  This seems like the desirable behavior, so we should correct our documentation, after confirm it with a test.  I'm unable to do so at the moment, but if you (hopefully) see this action succeed, let us know.

An alternative to a normal sequence is

  UncheckedSequence {
    …
  }

which as you would guess ignores the outcome of its subactions.

BTW, sorry for not replying earlier, but I'm buried in another project, one that doesn't use PLEXIL.

Cheers,
Mike





Catherine,

Perhaps the while loop in MonitorTimeout is just spinning and hence blocking the plan.  Monitors are typically written with Start conditions, which are checked once per macro step or quiescence cycle.  Could you try this:

MonitorTimeout:
{
          ExitCondition isVacuumApplied;
          StartCondition  Lookup(time,0.1) - startTime <= timeOut;

          pastTimeOut = true;
}

I'll think about this some more, and may have another idea…

Mike



On Feb 18, 2014, at 7:50 AM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>> wrote:


Any feedback or alternatives I should try?

From: Catherine Szeto
Sent: Thursday, February 13, 2014 10:45 AM
To: 'Fry, Charles R. {Chuck} (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)]'
Cc: ple...@li...<mailto:ple...@li...>
Subject: RE: [plexil-support] Concurrence not working (previously sent before, but this time without attachment)

Sure. MonitorTimeout is simple so I put its entirety here and I put a snippet of ApplyVacuumTo_Sequence:

MonitorTimeout:
{
          ExitCondition isVacuumApplied;

         while((Lookup(time,0.1) - startTime) <= timeOut) {}
                   pastTimeOut = true;
}

ApplyVacuumTo_Sequence
{
**variable assignments here**

      ExitCondition (Lookup(time,0.1) - startTime) > timeOut;
      RepeatCondition …;

      LibraryCall SetSpecialValves();
      LibraryCall TurnVacuumValves();

      ….
      isVacuumApplied =true;
}

My goal is to have ApplyVacuumTo_Sequence execute while have some kind of timer that forces ApplyVacuumTo_Sequence to abort if it goes over the given “timeOut” time before it finishes execution.  If it is aborted, I need to print to the terminal that ApplyVacuumTo_Sequence was aborted due to timeout. I put MonitorTimeout as a way to set a flag in case ApplyVacuumTo_Sequence is forced to finish due to being overtime, so another node can read that flag to print to the terminal about the timeout.

Catherine


From: Fry, Charles R. {Chuck} (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)] [mailto:chu...@na...]
Sent: Wednesday, February 12, 2014 6:15 PM
To: Catherine Szeto
Cc: ple...@li...<mailto:ple...@li...>
Subject: Re: [plexil-support] Concurrence not working (previously sent before, but this time without attachment)

What is the interaction between MonitorTimeout and ApplyVacuumTo_Sequence? Can you send us a code fragment?

-- Chuck

On Feb 12, 2014, at 3:00 PM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>> wrote:

Hello,
         I am trying to run two actions concurrently, but one (ApplyVacuumTo_Sequence) always waits with its first subaction as “skipped”  while the other (MonitorTimeout) continues to execute. The waiting action doesn’t continue until the other one is finished. Without the MonitorTimeout action, ApplyVacuumTo_Sequence executes all of its subactions without a problem. All MonitorTimeout has is a while loop that exits after a timeout is reached. If it is relevant, the subaction that is waiting is one that calls another plan through LibraryCall.

Please confirm if this is correct Concurrence behavior or not. Thank you.

Catherine Szeto


------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support

Chuck Fry
Senior Software Engineer
Dell | Services, Federal Government
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 Dell, SGT, Code TI, or NASA, nor do they speak for me.



------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support

------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support

Re: [plexil-support] Ideas for running a continuous loop that calls other plans when needed?

[Dalal, M. (ARC-TI)[S. G. T. I. (S. Inc.)] <mic...@na...>]

Interesting plan, and what you want should be doable, but I need to understand it better.

Can sub-plans run concurrently, or just one at at time?
Can a sub-plan run more than once?

The Start Condition approach (2) sounds like the best one, but perhaps some additional conditions are needed, depending on the desired semantics.

Approach (3) is probably off -- Preconditions are specifically for failing a node.  I don't know why (1) would be so slow.  For both (1) and (2) I suspect some problem in how the external interface is managing macro steps (quiescence cycles) in the plan.  It is responsible for the desired wakeups, and somehow the executive is not getting them (or getting them fast enough).  Would need more information (e.g. if your application is multi-threaded, it could be a thread issue).  But first let's get the semantics of the plan right….

Mike


On Feb 26, 2014, at 9:23 AM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>>
 wrote:

Hello all,
             We have a critical Main plan that continuously needs to check for certain Lookup variables. Once the variables are switched to a certain value, a plan is called depending on which variable, while the Main plan continues to cycle to keep checking the Lookup variables. We are trying Main with just three plans to check for right now, but it eventually can check for as many as 60 plans. Here’s pseudocode of what’s going on:

Main:
{
       RepeatCondition mainOn; //mainOn is always set to true

       PlanA:
      {
            StartCondition Lookup(PlanAUI) == 1;

           LibraryCall PlanA();
          //switch PlanAUI back to 0;
      }


       PlanB:
      {
            StartCondition Lookup(PlanBUI) == 1;

           LibraryCall PlanB();
           //switch PlanBUI back to 0;

      }

       PlanC:
      {
            StartCondition Lookup(PlanCUI) == 1;

           LibraryCall PlanC();
           //switch PlanCUI back to 0;

      }


}//end of Main

We tried the following scenarios:
1.       if/elseif statements instead of StartConditions. This worked, but it was ridiculously slow. For just 3 if/elseif statements, it took 10 minutes after PlanAUI was switched to 1 for Main to go through all three of the possible plans and then all the nested plans that those plans called and mark them as SKIPPED, then finally call PlanA. The three plans and the ones that they call are all simple. After the Main took the initial 10 min to mark all the SKIPPED plans, the following loop iterations were a lot faster and called PlanA much more quickly when its Lookup variable was switched.

2.       The StartCondition scenario as described in the pseudocode. This did not work at all. All three nodes were marked as WAITING for at least 15 min after the PlanAUI variable was switched to 1. It seems like after the nodes check their StartConditions and see that they are false through the first iteration, they won’t “wake up” again for the following loop iterations when the appropriate Lookup variables are switched to 1.

3.       Instead of StartConditions, we used PreConditions. This quickly failed all the plans before the PlanAUI variable could be switched to 1 and Main.ple failed as a result (expected, but worth a shot).

This is an important plan, so any suggestions would be appreciated! Thank you.

Catherine
------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support

Re: [plexil-support] Concurrence not working (previously sent before, but this time without attachment)

[Catherine S. <Cat...@ti...>]

I tried your suggestion of using the StartCondition for the timeout and it worked, thank you.

As for the ApplyVacuumTo succeeding even with skipped subactions, I do see that happening. I tested this by putting a SkipCondition in a subaction that was guaranteed to be skipped; I'm not sure if this makes a difference to you.

From: Dalal, Michael (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)] [mailto:mic...@na...]
Sent: Tuesday, February 18, 2014 5:16 PM
To: Catherine Szeto
Cc: Fry, Charles R. {Chuck} (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)]; ple...@li...
Subject: Re: [plexil-support] Concurrence not working (previously sent before, but this time without attachment)

I see something else, which is probably unrelated to the concurrency problem, but wanted to point out.

ApplyVacuumTo_Sequence is a normal sequence, and according to the reference doc, "A Sequence succeeds if and only if all its actions succeed...".   One action in your sequence has outcome Skipped.  From looking at the code, we check only for a Failure outcome, so ApplyVacuumTo_Sequence should succeed even if actions in it are skipped.  This seems like the desirable behavior, so we should correct our documentation, after confirm it with a test.  I'm unable to do so at the moment, but if you (hopefully) see this action succeed, let us know.

An alternative to a normal sequence is

  UncheckedSequence {
    ...
  }

which as you would guess ignores the outcome of its subactions.

BTW, sorry for not replying earlier, but I'm buried in another project, one that doesn't use PLEXIL.

Cheers,
Mike





Catherine,

Perhaps the while loop in MonitorTimeout is just spinning and hence blocking the plan.  Monitors are typically written with Start conditions, which are checked once per macro step or quiescence cycle.  Could you try this:

MonitorTimeout:
{
          ExitCondition isVacuumApplied;
          StartCondition  Lookup(time,0.1) - startTime <= timeOut;

          pastTimeOut = true;
}

I'll think about this some more, and may have another idea...

Mike



On Feb 18, 2014, at 7:50 AM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>> wrote:


Any feedback or alternatives I should try?

From: Catherine Szeto
Sent: Thursday, February 13, 2014 10:45 AM
To: 'Fry, Charles R. {Chuck} (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)]'
Cc: ple...@li...<mailto:ple...@li...>
Subject: RE: [plexil-support] Concurrence not working (previously sent before, but this time without attachment)

Sure. MonitorTimeout is simple so I put its entirety here and I put a snippet of ApplyVacuumTo_Sequence:

MonitorTimeout:
{
          ExitCondition isVacuumApplied;

         while((Lookup(time,0.1) - startTime) <= timeOut) {}
                   pastTimeOut = true;
}

ApplyVacuumTo_Sequence
{
**variable assignments here**

      ExitCondition (Lookup(time,0.1) - startTime) > timeOut;
      RepeatCondition ...;

      LibraryCall SetSpecialValves();
      LibraryCall TurnVacuumValves();

      ....
      isVacuumApplied =true;
}

My goal is to have ApplyVacuumTo_Sequence execute while have some kind of timer that forces ApplyVacuumTo_Sequence to abort if it goes over the given "timeOut" time before it finishes execution.  If it is aborted, I need to print to the terminal that ApplyVacuumTo_Sequence was aborted due to timeout. I put MonitorTimeout as a way to set a flag in case ApplyVacuumTo_Sequence is forced to finish due to being overtime, so another node can read that flag to print to the terminal about the timeout.

Catherine


From: Fry, Charles R. {Chuck} (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)] [mailto:chu...@na...]
Sent: Wednesday, February 12, 2014 6:15 PM
To: Catherine Szeto
Cc: ple...@li...<mailto:ple...@li...>
Subject: Re: [plexil-support] Concurrence not working (previously sent before, but this time without attachment)

What is the interaction between MonitorTimeout and ApplyVacuumTo_Sequence? Can you send us a code fragment?

-- Chuck

On Feb 12, 2014, at 3:00 PM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>> wrote:

Hello,
         I am trying to run two actions concurrently, but one (ApplyVacuumTo_Sequence) always waits with its first subaction as "skipped"  while the other (MonitorTimeout) continues to execute. The waiting action doesn't continue until the other one is finished. Without the MonitorTimeout action, ApplyVacuumTo_Sequence executes all of its subactions without a problem. All MonitorTimeout has is a while loop that exits after a timeout is reached. If it is relevant, the subaction that is waiting is one that calls another plan through LibraryCall.

Please confirm if this is correct Concurrence behavior or not. Thank you.

Catherine Szeto


------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support

Chuck Fry
Senior Software Engineer
Dell | Services, Federal Government
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 Dell, SGT, Code TI, or NASA, nor do they speak for me.



------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support

------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support

[plexil-support] Ideas for running a continuous loop that calls other plans when needed?

[Catherine S. <Cat...@ti...>]

Hello all,
             We have a critical Main plan that continuously needs to check for certain Lookup variables. Once the variables are switched to a certain value, a plan is called depending on which variable, while the Main plan continues to cycle to keep checking the Lookup variables. We are trying Main with just three plans to check for right now, but it eventually can check for as many as 60 plans. Here's pseudocode of what's going on:

Main:
{
       RepeatCondition mainOn; //mainOn is always set to true

       PlanA:
      {
            StartCondition Lookup(PlanAUI) == 1;

           LibraryCall PlanA();
          //switch PlanAUI back to 0;
      }


       PlanB:
      {
            StartCondition Lookup(PlanBUI) == 1;

           LibraryCall PlanB();
           //switch PlanBUI back to 0;

      }

       PlanC:
      {
            StartCondition Lookup(PlanCUI) == 1;

           LibraryCall PlanC();
           //switch PlanCUI back to 0;

      }


}//end of Main

We tried the following scenarios:

1.       if/elseif statements instead of StartConditions. This worked, but it was ridiculously slow. For just 3 if/elseif statements, it took 10 minutes after PlanAUI was switched to 1 for Main to go through all three of the possible plans and then all the nested plans that those plans called and mark them as SKIPPED, then finally call PlanA. The three plans and the ones that they call are all simple. After the Main took the initial 10 min to mark all the SKIPPED plans, the following loop iterations were a lot faster and called PlanA much more quickly when its Lookup variable was switched.



2.       The StartCondition scenario as described in the pseudocode. This did not work at all. All three nodes were marked as WAITING for at least 15 min after the PlanAUI variable was switched to 1. It seems like after the nodes check their StartConditions and see that they are false through the first iteration, they won't "wake up" again for the following loop iterations when the appropriate Lookup variables are switched to 1.



3.       Instead of StartConditions, we used PreConditions. This quickly failed all the plans before the PlanAUI variable could be switched to 1 and Main.ple failed as a result (expected, but worth a shot).

This is an important plan, so any suggestions would be appreciated! Thank you.

Catherine

Re: [plexil-support] Concurrence not working (previously sent before, but this time without attachment)

[Catherine S. <Cat...@ti...>]

I haven't had a minute to try this yet, but I will definitely give this a shot as soon as I can. Thank you very much for your feedback.

From: Dalal, Michael (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)] [mailto:mic...@na...]
Sent: Tuesday, February 18, 2014 5:16 PM
To: Catherine Szeto
Cc: Fry, Charles R. {Chuck} (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)]; ple...@li...
Subject: Re: [plexil-support] Concurrence not working (previously sent before, but this time without attachment)

I see something else, which is probably unrelated to the concurrency problem, but wanted to point out.

ApplyVacuumTo_Sequence is a normal sequence, and according to the reference doc, "A Sequence succeeds if and only if all its actions succeed...".   One action in your sequence has outcome Skipped.  From looking at the code, we check only for a Failure outcome, so ApplyVacuumTo_Sequence should succeed even if actions in it are skipped.  This seems like the desirable behavior, so we should correct our documentation, after confirm it with a test.  I'm unable to do so at the moment, but if you (hopefully) see this action succeed, let us know.

An alternative to a normal sequence is

  UncheckedSequence {
    ...
  }

which as you would guess ignores the outcome of its subactions.

BTW, sorry for not replying earlier, but I'm buried in another project, one that doesn't use PLEXIL.

Cheers,
Mike





Catherine,

Perhaps the while loop in MonitorTimeout is just spinning and hence blocking the plan.  Monitors are typically written with Start conditions, which are checked once per macro step or quiescence cycle.  Could you try this:

MonitorTimeout:
{
          ExitCondition isVacuumApplied;
          StartCondition  Lookup(time,0.1) - startTime <= timeOut;

          pastTimeOut = true;
}

I'll think about this some more, and may have another idea...

Mike



On Feb 18, 2014, at 7:50 AM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>> wrote:


Any feedback or alternatives I should try?

From: Catherine Szeto
Sent: Thursday, February 13, 2014 10:45 AM
To: 'Fry, Charles R. {Chuck} (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)]'
Cc: ple...@li...<mailto:ple...@li...>
Subject: RE: [plexil-support] Concurrence not working (previously sent before, but this time without attachment)

Sure. MonitorTimeout is simple so I put its entirety here and I put a snippet of ApplyVacuumTo_Sequence:

MonitorTimeout:
{
          ExitCondition isVacuumApplied;

         while((Lookup(time,0.1) - startTime) <= timeOut) {}
                   pastTimeOut = true;
}

ApplyVacuumTo_Sequence
{
**variable assignments here**

      ExitCondition (Lookup(time,0.1) - startTime) > timeOut;
      RepeatCondition ...;

      LibraryCall SetSpecialValves();
      LibraryCall TurnVacuumValves();

      ....
      isVacuumApplied =true;
}

My goal is to have ApplyVacuumTo_Sequence execute while have some kind of timer that forces ApplyVacuumTo_Sequence to abort if it goes over the given "timeOut" time before it finishes execution.  If it is aborted, I need to print to the terminal that ApplyVacuumTo_Sequence was aborted due to timeout. I put MonitorTimeout as a way to set a flag in case ApplyVacuumTo_Sequence is forced to finish due to being overtime, so another node can read that flag to print to the terminal about the timeout.

Catherine


From: Fry, Charles R. {Chuck} (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)] [mailto:chu...@na...]
Sent: Wednesday, February 12, 2014 6:15 PM
To: Catherine Szeto
Cc: ple...@li...<mailto:ple...@li...>
Subject: Re: [plexil-support] Concurrence not working (previously sent before, but this time without attachment)

What is the interaction between MonitorTimeout and ApplyVacuumTo_Sequence? Can you send us a code fragment?

-- Chuck

On Feb 12, 2014, at 3:00 PM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>> wrote:

Hello,
         I am trying to run two actions concurrently, but one (ApplyVacuumTo_Sequence) always waits with its first subaction as "skipped"  while the other (MonitorTimeout) continues to execute. The waiting action doesn't continue until the other one is finished. Without the MonitorTimeout action, ApplyVacuumTo_Sequence executes all of its subactions without a problem. All MonitorTimeout has is a while loop that exits after a timeout is reached. If it is relevant, the subaction that is waiting is one that calls another plan through LibraryCall.

Please confirm if this is correct Concurrence behavior or not. Thank you.

Catherine Szeto


------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support

Chuck Fry
Senior Software Engineer
Dell | Services, Federal Government
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 Dell, SGT, Code TI, or NASA, nor do they speak for me.



------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support

------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support

Re: [plexil-support] Concurrence not working (previously sent before, but this time without attachment)

[Dalal, M. (ARC-TI)[S. G. T. I. (S. Inc.)] <mic...@na...>]

I see something else, which is probably unrelated to the concurrency problem, but wanted to point out.

ApplyVacuumTo_Sequence is a normal sequence, and according to the reference doc, "A Sequence succeeds if and only if all its actions succeed…".   One action in your sequence has outcome Skipped.  From looking at the code, we check only for a Failure outcome, so ApplyVacuumTo_Sequence should succeed even if actions in it are skipped.  This seems like the desirable behavior, so we should correct our documentation, after confirm it with a test.  I'm unable to do so at the moment, but if you (hopefully) see this action succeed, let us know.

An alternative to a normal sequence is

  UncheckedSequence {
    …
  }

which as you would guess ignores the outcome of its subactions.

BTW, sorry for not replying earlier, but I'm buried in another project, one that doesn't use PLEXIL.

Cheers,
Mike




Catherine,

Perhaps the while loop in MonitorTimeout is just spinning and hence blocking the plan.  Monitors are typically written with Start conditions, which are checked once per macro step or quiescence cycle.  Could you try this:

MonitorTimeout:
{
          ExitCondition isVacuumApplied;
          StartCondition  Lookup(time,0.1) - startTime <= timeOut;

          pastTimeOut = true;
}

I'll think about this some more, and may have another idea…

Mike



On Feb 18, 2014, at 7:50 AM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>> wrote:

Any feedback or alternatives I should try?

From: Catherine Szeto
Sent: Thursday, February 13, 2014 10:45 AM
To: 'Fry, Charles R. {Chuck} (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)]'
Cc: ple...@li...<mailto:ple...@li...>
Subject: RE: [plexil-support] Concurrence not working (previously sent before, but this time without attachment)

Sure. MonitorTimeout is simple so I put its entirety here and I put a snippet of ApplyVacuumTo_Sequence:

MonitorTimeout:
{
          ExitCondition isVacuumApplied;

         while((Lookup(time,0.1) - startTime) <= timeOut) {}
                   pastTimeOut = true;
}

ApplyVacuumTo_Sequence
{
**variable assignments here**

      ExitCondition (Lookup(time,0.1) - startTime) > timeOut;
      RepeatCondition …;

      LibraryCall SetSpecialValves();
      LibraryCall TurnVacuumValves();

      ….
      isVacuumApplied =true;
}

My goal is to have ApplyVacuumTo_Sequence execute while have some kind of timer that forces ApplyVacuumTo_Sequence to abort if it goes over the given “timeOut” time before it finishes execution.  If it is aborted, I need to print to the terminal that ApplyVacuumTo_Sequence was aborted due to timeout. I put MonitorTimeout as a way to set a flag in case ApplyVacuumTo_Sequence is forced to finish due to being overtime, so another node can read that flag to print to the terminal about the timeout.

Catherine


From: Fry, Charles R. {Chuck} (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)] [mailto:chu...@na...]
Sent: Wednesday, February 12, 2014 6:15 PM
To: Catherine Szeto
Cc: ple...@li...<mailto:ple...@li...>
Subject: Re: [plexil-support] Concurrence not working (previously sent before, but this time without attachment)

What is the interaction between MonitorTimeout and ApplyVacuumTo_Sequence? Can you send us a code fragment?

-- Chuck

On Feb 12, 2014, at 3:00 PM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>> wrote:

Hello,
         I am trying to run two actions concurrently, but one (ApplyVacuumTo_Sequence) always waits with its first subaction as “skipped”  while the other (MonitorTimeout) continues to execute. The waiting action doesn’t continue until the other one is finished. Without the MonitorTimeout action, ApplyVacuumTo_Sequence executes all of its subactions without a problem. All MonitorTimeout has is a while loop that exits after a timeout is reached. If it is relevant, the subaction that is waiting is one that calls another plan through LibraryCall.

Please confirm if this is correct Concurrence behavior or not. Thank you.

Catherine Szeto


------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support

Chuck Fry
Senior Software Engineer
Dell | Services, Federal Government
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 Dell, SGT, Code TI, or NASA, nor do they speak for me.



------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support

------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk_______________________________________________
plexil-support mailing list
ple...@li...
https://lists.sourceforge.net/lists/listinfo/plexil-support

Re: [plexil-support] Concurrence not working (previously sent before, but this time without attachment)

[Dalal, M. (ARC-TI)[S. G. T. I. (S. Inc.)] <mic...@na...>]

Catherine,

Perhaps the while loop in MonitorTimeout is just spinning and hence blocking the plan.  Monitors are typically written with Start conditions, which are checked once per macro step or quiescence cycle.  Could you try this:

MonitorTimeout:
{
          ExitCondition isVacuumApplied;
          StartCondition  Lookup(time,0.1) - startTime <= timeOut;

          pastTimeOut = true;
}

I'll think about this some more, and may have another idea…

Mike



On Feb 18, 2014, at 7:50 AM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>> wrote:

Any feedback or alternatives I should try?

From: Catherine Szeto
Sent: Thursday, February 13, 2014 10:45 AM
To: 'Fry, Charles R. {Chuck} (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)]'
Cc: ple...@li...<mailto:ple...@li...>
Subject: RE: [plexil-support] Concurrence not working (previously sent before, but this time without attachment)

Sure. MonitorTimeout is simple so I put its entirety here and I put a snippet of ApplyVacuumTo_Sequence:

MonitorTimeout:
{
          ExitCondition isVacuumApplied;

         while((Lookup(time,0.1) - startTime) <= timeOut) {}
                   pastTimeOut = true;
}

ApplyVacuumTo_Sequence
{
**variable assignments here**

      ExitCondition (Lookup(time,0.1) - startTime) > timeOut;
      RepeatCondition …;

      LibraryCall SetSpecialValves();
      LibraryCall TurnVacuumValves();

      ….
      isVacuumApplied =true;
}

My goal is to have ApplyVacuumTo_Sequence execute while have some kind of timer that forces ApplyVacuumTo_Sequence to abort if it goes over the given “timeOut” time before it finishes execution.  If it is aborted, I need to print to the terminal that ApplyVacuumTo_Sequence was aborted due to timeout. I put MonitorTimeout as a way to set a flag in case ApplyVacuumTo_Sequence is forced to finish due to being overtime, so another node can read that flag to print to the terminal about the timeout.

Catherine


From: Fry, Charles R. {Chuck} (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)] [mailto:chu...@na...]
Sent: Wednesday, February 12, 2014 6:15 PM
To: Catherine Szeto
Cc: ple...@li...<mailto:ple...@li...>
Subject: Re: [plexil-support] Concurrence not working (previously sent before, but this time without attachment)

What is the interaction between MonitorTimeout and ApplyVacuumTo_Sequence? Can you send us a code fragment?

-- Chuck

On Feb 12, 2014, at 3:00 PM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>> wrote:

Hello,
         I am trying to run two actions concurrently, but one (ApplyVacuumTo_Sequence) always waits with its first subaction as “skipped”  while the other (MonitorTimeout) continues to execute. The waiting action doesn’t continue until the other one is finished. Without the MonitorTimeout action, ApplyVacuumTo_Sequence executes all of its subactions without a problem. All MonitorTimeout has is a while loop that exits after a timeout is reached. If it is relevant, the subaction that is waiting is one that calls another plan through LibraryCall.

Please confirm if this is correct Concurrence behavior or not. Thank you.

Catherine Szeto


------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support

Chuck Fry
Senior Software Engineer
Dell | Services, Federal Government
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 Dell, SGT, Code TI, or NASA, nor do they speak for me.



------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support

Re: [plexil-support] Concurrence not working (previously sent before, but this time without attachment)

[Catherine S. <Cat...@ti...>]

Any feedback or alternatives I should try?

From: Catherine Szeto
Sent: Thursday, February 13, 2014 10:45 AM
To: 'Fry, Charles R. {Chuck} (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)]'
Cc: ple...@li...
Subject: RE: [plexil-support] Concurrence not working (previously sent before, but this time without attachment)

Sure. MonitorTimeout is simple so I put its entirety here and I put a snippet of ApplyVacuumTo_Sequence:

MonitorTimeout:
{
          ExitCondition isVacuumApplied;

         while((Lookup(time,0.1) - startTime) <= timeOut) {}
                   pastTimeOut = true;
}

ApplyVacuumTo_Sequence
{
**variable assignments here**

      ExitCondition (Lookup(time,0.1) - startTime) > timeOut;
      RepeatCondition ...;

      LibraryCall SetSpecialValves();
      LibraryCall TurnVacuumValves();

      ....
      isVacuumApplied =true;
}

My goal is to have ApplyVacuumTo_Sequence execute while have some kind of timer that forces ApplyVacuumTo_Sequence to abort if it goes over the given "timeOut" time before it finishes execution.  If it is aborted, I need to print to the terminal that ApplyVacuumTo_Sequence was aborted due to timeout. I put MonitorTimeout as a way to set a flag in case ApplyVacuumTo_Sequence is forced to finish due to being overtime, so another node can read that flag to print to the terminal about the timeout.

Catherine


From: Fry, Charles R. {Chuck} (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)] [mailto:chu...@na...]
Sent: Wednesday, February 12, 2014 6:15 PM
To: Catherine Szeto
Cc: ple...@li...<mailto:ple...@li...>
Subject: Re: [plexil-support] Concurrence not working (previously sent before, but this time without attachment)

What is the interaction between MonitorTimeout and ApplyVacuumTo_Sequence? Can you send us a code fragment?

-- Chuck

On Feb 12, 2014, at 3:00 PM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>> wrote:

Hello,
         I am trying to run two actions concurrently, but one (ApplyVacuumTo_Sequence) always waits with its first subaction as "skipped"  while the other (MonitorTimeout) continues to execute. The waiting action doesn't continue until the other one is finished. Without the MonitorTimeout action, ApplyVacuumTo_Sequence executes all of its subactions without a problem. All MonitorTimeout has is a while loop that exits after a timeout is reached. If it is relevant, the subaction that is waiting is one that calls another plan through LibraryCall.

Please confirm if this is correct Concurrence behavior or not. Thank you.

Catherine Szeto


------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support

Chuck Fry
Senior Software Engineer
Dell | Services, Federal Government
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 Dell, SGT, Code TI, or NASA, nor do they speak for me.

Re: [plexil-support] Concurrence not working (previously sent before, but this time without attachment)

[Catherine S. <Cat...@ti...>]

Sure. MonitorTimeout is simple so I put its entirety here and I put a snippet of ApplyVacuumTo_Sequence:

MonitorTimeout:
{
          ExitCondition isVacuumApplied;

         while((Lookup(time,0.1) - startTime) <= timeOut) {}
                   pastTimeOut = true;
}

ApplyVacuumTo_Sequence
{
**variable assignments here**

      ExitCondition (Lookup(time,0.1) - startTime) > timeOut;
      RepeatCondition ...;

      LibraryCall SetSpecialValves();
      LibraryCall TurnVacuumValves();

      ....
      isVacuumApplied =true;
}

My goal is to have ApplyVacuumTo_Sequence execute while have some kind of timer that forces ApplyVacuumTo_Sequence to abort if it goes over the given "timeOut" time before it finishes execution.  If it is aborted, I need to print to the terminal that ApplyVacuumTo_Sequence was aborted due to timeout. I put MonitorTimeout as a way to set a flag in case ApplyVacuumTo_Sequence is forced to finish due to being overtime, so another node can read that flag to print to the terminal about the timeout.

Catherine


From: Fry, Charles R. {Chuck} (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)] [mailto:chu...@na...]
Sent: Wednesday, February 12, 2014 6:15 PM
To: Catherine Szeto
Cc: ple...@li...
Subject: Re: [plexil-support] Concurrence not working (previously sent before, but this time without attachment)

What is the interaction between MonitorTimeout and ApplyVacuumTo_Sequence? Can you send us a code fragment?

-- Chuck

On Feb 12, 2014, at 3:00 PM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>> wrote:


Hello,
         I am trying to run two actions concurrently, but one (ApplyVacuumTo_Sequence) always waits with its first subaction as "skipped"  while the other (MonitorTimeout) continues to execute. The waiting action doesn't continue until the other one is finished. Without the MonitorTimeout action, ApplyVacuumTo_Sequence executes all of its subactions without a problem. All MonitorTimeout has is a while loop that exits after a timeout is reached. If it is relevant, the subaction that is waiting is one that calls another plan through LibraryCall.

Please confirm if this is correct Concurrence behavior or not. Thank you.

Catherine Szeto


------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support

Chuck Fry
Senior Software Engineer
Dell | Services, Federal Government
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 Dell, SGT, Code TI, or NASA, nor do they speak for me.

Re: [plexil-support] Concurrence not working (previously sent before, but this time without attachment)

[Fry, C. R. {C. (ARC-TI)[S. G. T. I. (S. Inc.)] <chu...@na...>]

What is the interaction between MonitorTimeout and ApplyVacuumTo_Sequence? Can you send us a code fragment?

-- Chuck

On Feb 12, 2014, at 3:00 PM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>> wrote:

Hello,
         I am trying to run two actions concurrently, but one (ApplyVacuumTo_Sequence) always waits with its first subaction as “skipped”  while the other (MonitorTimeout) continues to execute. The waiting action doesn’t continue until the other one is finished. Without the MonitorTimeout action, ApplyVacuumTo_Sequence executes all of its subactions without a problem. All MonitorTimeout has is a while loop that exits after a timeout is reached. If it is relevant, the subaction that is waiting is one that calls another plan through LibraryCall.

Please confirm if this is correct Concurrence behavior or not. Thank you.

Catherine Szeto


------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support

Chuck Fry
Senior Software Engineer
Dell | Services, Federal Government
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 Dell, SGT, Code TI, or NASA, nor do they speak for me.

[plexil-support] Concurrence not working (previously sent before, but this time without attachment)

[Catherine S. <Cat...@ti...>]

Hello,
         I am trying to run two actions concurrently, but one (ApplyVacuumTo_Sequence) always waits with its first subaction as "skipped"  while the other (MonitorTimeout) continues to execute. The waiting action doesn't continue until the other one is finished. Without the MonitorTimeout action, ApplyVacuumTo_Sequence executes all of its subactions without a problem. All MonitorTimeout has is a while loop that exits after a timeout is reached. If it is relevant, the subaction that is waiting is one that calls another plan through LibraryCall.

Please confirm if this is correct Concurrence behavior or not. Thank you.

Catherine Szeto

Re: [plexil-support] Typecasting in Plexil?

[Fry, C. R. {C. (ARC-TI)[S. G. T. I. (S. Inc.)] <chu...@na...>]

This is a major weakness in the PLEXIL language at present. We do not have conversion operators.

In practice, everything is represented as a Real internally. So there's probably a way to do what you need. What's the use case?

-- Chuck

On Feb 11, 2014, at 10:05 AM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>> wrote:

Hello again,
         Can typecasting be done in Plexil? Namely, from Real to Integer is what I attempted to do, but without success.

Catherine Szeto

------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support

Chuck Fry
Senior Software Engineer
Dell | Services, Federal Government
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 Dell, SGT, Code TI, or NASA, nor do they speak for me.

[plexil-support] Typecasting in Plexil?

[Catherine S. <Cat...@ti...>]

Hello again,
         Can typecasting be done in Plexil? Namely, from Real to Integer is what I attempted to do, but without success.

Catherine Szeto