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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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?

Plan execution language and executive

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