The ArchestrAnaut

First off, yes we’re still around.  Got tied up in a rush job on a DeltaV Batch project that has taken me away for the last 3 weeks or so. 

As promised in our last article we’re going to discuss how you can write a long running script without using asynchronous scripting.  To be totally fair this only works in the situation where your script is long running because you are iterating some kind of array.  If you need an async script because you have a really long database call or some long running file transaction there’s not much I can do for you.

Before we get into the technique the first thing you need to understand is what an asynchronous script is.  When IAS executes its objects, on a particular engine all objects and scripts in those objects are executed one after another.  It’s pretty amazing that the software engines can get through so many pieces of code so fast.  Kudos to the software architects.  If you find yourself with scan overruns on an engine, the first thing to do if figure out if you have any objects hanging or hogging resources.  If everything checks out there you should create a new engine and move some objects over.  At this point you have now split your object list and allowed them to run in parallel.  A while back I saw some advice that said you shouldn’t have more engines than cores on your computer.  That seems to make sense if we’re trying to run all the engines in parallel as efficiently as possible.  By the way… getting back to the previous post… does this help you understand why it takes at least one scan to hookup to an attribute that is on another engine?  Back to what we were talking about, there’s not a lot of good information in the books on what async scripts are but here’s one line I found that helps a little bit

Asynchronous scripting mode is a group of scripts running on the same, lower priority execution thread.

There are two key points here to think about.  First, the scripts are running on a different thread.  If you know much about software development you know that in a single thread all actions are lined up and happen one after another.  In other words, if there is a slow poke in the group then everybody waits behind them to get done before they can execute, kinda like the old person in the grocery store who still insists on writing a check.  Extending the analogy a little bit imagine you’re at a Wal-Mart supercenter with 32 checkout lines.  Only problem is the manager only has 3 lines open.  Wow, did I just tie-in Wal-Mart to a discussion of asynchronous scripting in Archestra?  The second part of the analogy makes us think about the difference in speed of the checkout folks. We all know that all cashiers are not created equal.  Imagine you have one cashier that is totally focused on the customer in front of them, that customer is a high priority.  Chances are the line is going to move really fast  Let’s call this cashier Fay.  Now imagine another cashier who puts a low priority on the customer in front of them, say his name is Cletus.  They are answering their cell phone, chatting with the guy stocking the drinks, commenting on what the person behind you is wearing, in general they are being interrupted by higher priority tasks.  That process is going to move pretty slowly.  When you run your scripts in a normal fashion you get into Fay’s line.  While the line may be long she’s really efficient and gets everyone through in a quick manner.  When you run your scripts async you are in Cletus’s line.  You’ll get through, eventually, but you may be waiting around for a while.  What I have left out of this discussion though, is that Fay can only work for 15 minutes at a time and if you are standing in line when her 15 minutes is up, then you have to put everything back and start over again… this is like a scan overrun.  Enough of the Wal-Mart analogies, back to the highbrow stuff.

So we have an array we’re trying to loop through but because of the length of the array and the nature of what we’re doing in the array, there is no way we can make it through the whole array in one scan.   How do you handle this.

Well, the first thing to do is figure out how long you have to execute your script.  This is available to you via some parameters on your engine.  Here’s the expression we use to calculate what we call a Halt Time.

Me._HaltTime = MyEngine.Scheduler.ScanTime + Me._ScanFraction * MyEngine.Scheduler.ScanPeriod / 1000;

Basically what we’re doing is saying take the start time of the current scan cycle then add a portion of the scheduled scan time.  We will typically use something like 75%.  Say we start this scan at 13.2 seconds after the minute.  If we have a 1 second scan time and a 75% scan fraction we end up calculating a halt time of 13.95 seconds after the minute.  We’ll use this later in our loop.

Next, we need to setup our tracking devices.  On the first time through our script we reset our tracking variable; say we call it j to 1.  You should keep track of what you have or haven’t done either via flags or some internal step counter.  Next, before you start looping, set your loop index, say we call it i , to whatever the value of j is.  What this is doing is allowing you to restart in the middle of your loop.  After each step you should be incrementing i along with setting j equal to i.  This is a bit hard to explain in prose so here it is in pseudocode.  Apologies in advance for my code not being as pretty as David’s.  I don’t have the patience to do all the formatting like he does.

Dim j as Integer (in declarations section of script so it persists across scans)
Dim i as Integer (in regular header part of script)

If (we’re just starting this sequence) Then
       j = 1
     Go to Step 2
End If

If (we’re at Step 2)
     ‘ Initialize the loop index counter to whatever the last value of j was.  First time through this is 1, next time through it might be somewhere between 1 and the end of the array
     i = j

     ‘ Start looping and bail out of the loop if we are at the end OR we have reached our pre-calculated halt time
     While (I < ArrayLength AND Now() < Halt Time)
                { Do yo thang….}
                 {Maybe a message saying you are x% done}
                 ‘Advance the counter and track the counter with j, which persists across scans
                 i = i + 1
                 j = i

      End While

     If (I >= ArrayLength) Then
              ‘ We’ve made it all the way through so reset j and advance to the next step
               j = 1
               Go to Step 3
      End If

So, if you follow what we’re doing we’re just using a secondary variable to keep up with how far we’ve made it in the array before we had to bail out.  Then, when we jump back in on the next scan we pick up where we left off.  Pretty slick huh?

One of the interesting things we discovered while doing our testing was the idea that Async scripts are definitely slower.  During a test using this particular method above we saw a distinct 5x slowdown (70 ms to 370 ms) when we swapped to Async from Sync,  changing nothing else.  That should give you some perspective on what it means to swap to a low priority thread.

I hope this was useful and worth the wait.

Anyone else have a method they’ve developed that accomplishes something similar?

Ok so that’s a really dramatic title for what we think is a pretty cool technique we’ve been working on for the last few months. 

A little back-story if you will.  We’re working on an application for a customer that requires us to download recipe parameters to a PLC.  No big deal, right?  Just use the FMO from the EOM.  First problem was that due to some licensing changes, using the FMO wasn’t an option.  Ok, well I guess we can just write our own FMO, that can’t be too hard.  We started down this path but quickly realized that having to create multiple UDA’s for every attribute was a maintenance nightmare and not something we wanted our customers to deal with.  By the way, to get a sense of scale for what this customer needed, we have a machine where we are downloading over 2000 recipe values to a single machine.  Yes, that 2 THOUSAND.  The machine isn’t that big but it does have a massive array of implements that all have about 16 set points so you have a matrix of about 16 * 100 for one section of the machine.. that’s how you get into thousands of formula parameters.

After batting around a number of ideas we came across what ended up being the ultimate solution, and that’s what we’re going to share with you.  We’re not going to do a massive code dump and give away the keys to the kingdom (there’s lots of hours in this method) but we will show you the main idea so you can possibly implement your own solution.

It all starts with Indirects.  If you’ve never used Indirects you really should learn about them.  Basically an Indirect is a variable type you can declare in a script.  Once you declare an indirect you call the “BindTo” function on that variable.  Once you have called the BindTo you can now read and write to that indirect and the values will through to the variable you have bound to.  This method can solve a ton of issues especially if you have an unknown quantity in an array or want to write a generic object that can work in a bunch of different settings.  Below is a really really simple example.

Dim X as Indirect;
Dim Timer as Integer;

X.BindTo(“AttributeName.Value”);

‘ Wait till the quality becomes good before attempting to read or write
While NotGood(X)
     Timer = Timer + 1;
EndWhile;

‘ Read from X
LogMessage(“Value of X is “ + X);

’ Write to X
X = 12.3;

There is some basic reading in the help files that give you a little more information.  Here’s where the magic starts. Way back in the 2.1 days there used to be a note… at least I think there was… that said you couldn’t bind across engines.  I always wondered why that was?  Turns out through some other investigations that hooking up to I/O that isn’t on the same engine takes at least one scan.  Why does that matter?  Well, if in a script you declare the Indirect at the top of the script that reference is destroyed at the end of the scan cycle.  If its’ destroyed at the end of the scan cycle then how can it persist across scans to survive to hook up to another engine?

So how do you get around this limitation?  Simple, move your declaration up into the rarely used declarations section of your script. 

If you didn’t know, variables declared in this section are persisted across scans.  Now we can declare an indirect in this section, do some binding in the script itself, and use the results of that binding in a subsequent scan.  Very cool!  I’ve been doing IAS for a long time and I was frankly amazed that I never put this little trick together (thanks David!).  Actually after using this for this technique I’ve started using these guys a lot more in place of placeholder UDA’s for basic things like flags and multi-scan counters.  Just remember, these are not checkpointed so anything that needs to persist across a failover should be a UDA, not one of these variables.

So now that we’ve got the dynamic part, what’s this hyper-scale thing?

So back to the formulas.  Since the FMO was out we basically wrote our own Formula database in SQL Server.  Not terribly difficult to do a basic one.  We ended up blinging this one out with lots of really cool features; that part we’re not going to share.  At the end of the day we make a stored procedure call to the database and it not only retrieves the basic parts of the recipe (names, values, units, limits, etc.) but it also downloads I/O references.  Using these I/O references we iterate over some arrays and dynamically bind our Indirects to the appropriate I/O source.  Did you notice our arrays of Indirects in our declarations?  Pretty sweet huh?

So what does all this mean?  This means that you can have an arbitrary set of parameters that you need to read and write to and as long as you can get a list of I/O addresses you can scale to your heart’s content.

One question you might ask is how do you see the values if they aren’t UDA’s?   We solve that issue by copying out the contents to an array of strings that is dynamically scaled based on the number of I/O we’re dealing with.  Super simple example below.

Dim Count as Integer;
Dim Index as Integer;

Count = Me.ValsArray.Dimension1;

For Index = 1 to Count

              Me.ValsArray[Index] = IndirectValsArray[Index];

Next Index;

Knowing that you can access the size of an array at runtime via the Dimension1 parameter makes things a lot more flexible.  Also, did you know that you can set the Dimension1 at runtime to dynamically change the size of the array?  Even cooler is that if you set Dimension1 to 0 then immediately to some positive value you just cleared out the array.  Is this more efficient than setting the size then iterating and clearing… don’t know, never tested that.

Back to the problem at hand.

At the end of the day what matters just as much as flexibility is how well it actually scales.  We’ve tested our solution at 10,000 I/O to a Control Logix L62 PLC (yes, it’s a big array so lots of efficiency there) and we run at about 250 ms to get through the entire array reading every attribute’s value and quality and copying them into our UDA arrays so we can view them with object viewer.  If you’re doing something with 10,000 I/O you might just have to accept a 250ms cycle time for something this far off the reserve.   With something this big I’m thinking you might be on your own engine to avoid async issues with other objects and scripts.  Something we have noticed in our testing from 1 element through 10,000 elements is that the scaling is pretty linear.  That’s good to know if we needed to keep going.  To be fair things may fall apart at 11,000 elements but it looks pretty good up to that 10,000.

If you were really astute, and you’ve worked with Indirects before, one question you might ask is how in the world you design a script that waits for all of the qualities to go good before reading and writing data.  That’s going to be the subject of our next post, designing a system that allows for multi-scan execution of a script without using Asynchronous scripts.  I know you’ll be waiting with baited breath for that one

- Andy