We Interrupt This Blog Post to Bring You This Important Blog Post

I've been back in Texas since October, getting acclimated to all things uniquely Texan, like great BBQ and killer margaritas. I’m also working on my Texas-speak (y’all).  While I’m back in the live music capital of the world, I’m still not sure I’m ready to go out two-stepping, but I knew it was time to start blogging again.

I was in the middle of putting together by my first blog post in over 4 months (the topic was tracking operator display access – stay tuned) when I ran into a hiccup.  The good news is the problem was resolved within a day, but there were some “sinking feeling” moments that brought into question any decision to work in a high tech industry.

So on my laptop I’ve got a couple of virtual DeltaV machines.  One is a V11.3 build using Microsoft’s VirtualPC.  The other is a VMware image of a prerelease of V12.3.  I’ve got one of those speedy Dell Latitude laptops, but it was recommended to me to put my virtual images on a solid state drive (SSD) to improve performance.

Since DeltaV Standalone Simulate will be releasing soon on a SSD, and since my laptop has an Express Card slot, I decided to go out and get a SSD card.  Now I didn’t do an exhaustive search on the internet, but there weren't many choices of manufacturers (I found one).  And since size matters, I bought the biggest one I could find, a 96 GB model.

The first issue was less than stellar installation instructions.  I know you’re thinking “Bruce, just plug it in, how hard could that be?” but in reality, it was a little more complicated.  See that USB connection on the stick?  Well, turns out to get all the right drivers to load, you need to first connect the SSD to the computer via the USB cable.  Then plug the puppy into the EC slot.  Note in the following close up that when fully inserted, the drive sticks out just a bit – this is an issue.

Anyway, now I had a new H: drive with 96 GB (actually, 86 GB available) and I get my Server 2008, V12.3 image transferred to it.  I fire it up with VMware Player and I’m rocking and rolling.

In preparing for my post, I needed to load Word and Excel onto my virtual machine.  I got out my MS Office install CD, pressed the button on the CDROM drive to open it, and (can you guess where this is going) the top of the tray caught the bottom of the slightly extended SSD card and popped it out.

Removing a USB stick without using the “Safely Remove Hardware and Eject Media” typically isn’t a problem.  But that’s not what’s going on here.  Basically what I’ve done is yank out the virtual machine’s hard drive under power.  Getting messages of a “serious I/O error” from the VMware Player had me wandering just how far back I was going to have to go to recover.

Luckily, dismounting and remounting the drive from Computer Management was all that I ended up having to do, but I had several tense hours before getting the problem resolved.  I won’t go as far as to say there’s a design flaw with the EC card slot or the SSD drive itself, but having to hold the SDD in place with one hand while pressing the eject button with the other hand is hokey.  I’m perfecting this new Texas two-handed two step technique to avoid future issues.  Just saying, y’all.

Carolina On My Mind

For those of you hoping to get a clever tidbit of control knowledge, you’ll just have to wait for my next post.

I’ll be changing jobs here in a couple of weeks; changing companies in fact. I’ll be heading to the center of Emerson Process Management universe in Austin, TX. I’ve been in the Carolinas for almost 12 years, and while I’m excited to take on new roles and responsibilities for Emerson, I’m going to miss colleagues and customers alike that I’ve gotten to know really well.

I’ve had the privilege to work on some pretty incredible projects and pursuits in 12 years that have been the inspiration for many of my posts. I’ll continue to draw upon my experiences and share the good and the bad.

On the lighter side, I can tell you flat out I am not gonna miss Carolina BBQ. My fear is I will OD on Rudy’s, Iron Works, and Pokey Joe’s my first week. And while I made this request back in August, I’ll ask again – please cool it down just a little, OK? Was it really 105 in Austin yesterday? It’s September!

If you’re headed to Nashville for EGUE, I’ll see you there. If not, watch this space for future control gems.

Cuts Like a Knife

Everyone’s had a Swiss Army knife at some point in their lives (I guess the North American version is the Leatherman Multi-tool - we always have to do things bigger, huh?). A Swiss Army knife with one or two screwdrivers, LED flashlight, a nail file, pliers and a toothpick is commonplace. I’ve seen models that had so many features, you couldn't find the blade.

I’ve known Bob Engel for at least 8 years now. Bob is Vice President of Informetric Systems (http://www.informetric.com/). InfoBatch is Informetric’s batch reporting package, and I’ve been sweet on InfoBatch ever since I first kicked its tires at the Emerson Exchange in Dallas back in 2004.

InfoBatch generates batch reports. And it does it very well. It allows you to connect to a multitude of data sources and aggregate them into a single, unified report. It doesn’t force you to replicate your data into yet another location (the “many versions of the truth” paradox). And if you don’t have another datastore to worry about, you don’t have to worry about all those pliers, toothpicks and nail files to manage it.

InfoBatch inherently understands the S88 model, from phases to recipes. It handles the concept of sub-phase triggers (for example, just show me a plot of a tank's temperature during the relevant portion of a phase). And it has connectors that understand the structure of the views from your data sources. Simple drop-down selections as opposed to flashlights and screwdrivers for managing custom SQL queries from software packages that don’t care if you’re creating batch end reports or your monthly bank statement.

Of course there has to be a shameless plug in one of my posts, so here it is: be sure and attend session 2-3041 at this year’s Emerson Global User Exchange, October 24th to 28th in Nashville. Bob and I will be presenting “Integrating Syncade S95 Orders, DeltaV S88 Batch Recipes and Continuous Data”. Please leave your knives at the door.

Stairway to Heaven

Many years ago, I was working a startup in Addis, LA and the process control technician explained to me the various titles for the operation’s staff.  At the top of the food chain was the title AAGLB.  I asked what it stood for.  The reply was “Almost A God-Like Being”.

So I was doing some Googling over the holiday weekend for Windows 7 keyboard shortcuts (I had some time to kill while I was smoking my ribs and brats). In addition to all the built-in, but little known keyboard shortcuts, I came across an interesting feature called GodMode.

GodMode (someone in Redmond has a sense of humor) is a searchable/clickable list of system tasks that automatically gets created when you create a very special folder on your Desktop named, you guessed it, GodMode.

Specifically, create a new folder on your Desktop and rename it GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}. You’ll see the icon change from the standard folder to one that’s typically associated with Control Panel. Double click on the folder and you’ll see the following:

Now you’ve got a fairly comprehensive, searchable list of system functions. Just double click on any one of them to run, or right click on one, create a shortcut, then edit the shortcut to give it a keyboard shortcut.  Hey, you're a AAGLB.

Skinning the Cat with XLReporter

At what point does control functionality requirements become just too complex to implement in the native control environment? It’s a tough call, because there are so many factors that go into the decision. Converting some massive calculation into the DCS control environment just might not make sense.

Other considerations though, especially for regulated industries like biotech and nuclear, center on the ability to validate all of the control functionality in a like manner. Having one piece of code, written in a different programming language, and existing on a different platform (typically Microsoft), may not make sense.

A few years ago, I converted some pretty complex, iterative calculations into function block and SFC logic in DeltaV. I spent many months working to optimize the code to run in the controller with the rest of the control strategy.

Earlier this year, we needed to come up with some dew point calculations as part of a project. While they were eventually easy enough to code in native DeltaV format, the source for the equations came from Excel spreadsheets.

So recently two things caught my eye on a potentially better way to “skin the cat”. First, I saw a question pop up on the DeltaV LinkedIn site about Hydro Carbon Dew Point (HCDP) calculations and how to implement them with the DCS. I googled HCDP and found some very complex equations taking place in Excel to solve these calculations.

The second thing was a product update presentation I sat through from Peter Kaprielian of Sytech for their XLReporter package. As you might gather from its name, XLReporter makes heavy use of Excel for data gathering and reporting. XLReporter is jam-packed with features, and while I can’t do justice to them all here, the one that got my attention was the ability to write data, via OPC, to other systems.

That’s when the light bulb went off – could I do HCDP calculations in Excel, feeding GC data from DeltaV to the spreadsheet and getting the results pushed back down to my controller?

Now I kind of wimped out, because I don’t know the first thing about HCDP, but I do know something about dry bulb, wet bulb and humidity calculations due to our recent project work. So I set out to implement a wet bulb temperature calculation implemented in a XLReporter spreadsheet. The idea was to read air temperature and humidity values from DeltaV, process them in my XLReporter spreadsheet, then write the result back into a parameter in my controller.

Additional internet surfing netted me a dew point spreadsheet I “borrowed” for my test. I cut and pasted the spreadsheet into the Template worksheet of an XLReporter Excel workbook. Then I added real time data links to temperature and humidity parameters from a couple of different modules in my controller:

I then tied off cells E29 and E31 with the values of C18 and C17. The final step was to take the result in J34 and write it back to a parameter in one of my modules. When you run a Report Update, the Results worksheet looks like this:

And my test module in DeltaV looked like this:

I set up a schedule within XLReporter so the calculations are processed once a minute. XLReporter is a bargain at twice the price, so if you have a particularly complex or otherwise computationally intensive application, give this technique a try.

If you'd like to know more about how I pulled this off, post a comment or shoot me an email.

Troubleshooting Help

Not that you need another reason to upgrade your DeltaV system to version 11, but there’s a way cool app in Windows 7 and Server 2008 R2 to enhance troubleshooting. It’s called Problem Steps Recorder or PSR for short.

What PSR does is record your mouse clicks along with the associated screenshots to produce a complied HTML file that chronicles everything you do between the time you click Start Record until the time you click Stop Record. PSR allows you to add a comment during the session, in case what’s going on needs more explanation. Now you can share your experiences with colleagues or that tech support guy so there’s less chance for misunderstanding.

You access this nifty tool by typing PSR in the “Search programs and files” dialog box of Windows 7 (remember, once your fire it up, you can right click on its icon in the tray and select “Pin this program to taskbar” for faster access).

The UI is simple and uncluttered:

I jumped over to my DeltaV boot, fired PSR up, selected Start Record, and through DeltaV Explorer, went online with an equipment module. When I was done, I pressed Stop Record. PSR automatically packages up the session you’ve had it record into a ZIP file. Inside the ZIP is an MHT file that opens in Internet Explorer Here’s a screenshot from the PSR file of me forcing a transition of an SFC:

It’s all hyperlinked and clicking on any of the images brings up a full screen view. If you’d like to have a look at the entire file I created, you can download it here.

A big shout out to David Rehbein of Emerson in Austin for turning me on to this great tool.

Tricking out Aliases, Part 2

Scott Thompson's commnet to my last post was a good one.  He couldn't include a screenshot example in his comment, so I'll share it with y'all:

Did you know that you can also use multiple aliases in a single line of code?

In the last action example in the post if the #ARBITRATION# alias pointed to a module which handled arbitration for multiple pieces of shared equipment, each with a named linked composite within the arbitration module, a reference could look like:

Tricking Out Aliases

I’ve been delinquent in blog entries, and while I’ve had several topics floating around in my head, finding the time to get something posted has been tough. I’m not making excuses, but it’s been really busy around here lately. So it took the above video (William Shatner paying tribute to the Shuttle Discovery) to get me writing again. The idea is I’ll pull you in with a DeltaV topic, and then you’ll see my new opening video.

The concept of aliasing has been around in class based phase logic from the introduction of batch with DeltaV. Emerson has gone on to allowing aliasing in equipment modules, but this more recent addition is implemented differently than the method used for phases. I want to touch on the former technique, because I think there’re folks who might not know how to exploit it.

Below is a typical dialog box for an alias I have on a unit class to tell me who I am:

I’ve created an alias named UNIT_MOD and since I’m at the unit class level, the Path: is grayed out. The idea is to have an alias that points to the unit instance, so my phase logic can figure out who I am. If I look at the similar dialog box for an instance of this unit class, I’ll see this:

Since this is at an instance of the unit class, the path is filled in with the name of the unit module for this particular instance. By having this alias, I can have my phase logic address any parameter associated with my unit, like below where I’m setting the U_MODE_LOCK parameter to TRUE:

If you remember from your 7016 batch class (if you haven’t been to 7016, shame on you – as soon as you finish reading this, go online and register for the next available DeltaV batch class), the #’s encapsulate your alias.

So what’s going on here? Well the truth is an alias is just another parameter. It’s a special string parameter, one that you can only add and modify from the unit class and instances. Another thing you might not remember from your batch class is you can have an alias be as high level as a module name, or as specific as an individual parameter in a function block like XV-101/DC1/SP.CV. If you get too specific though, you’ll need a ton of aliases, so common practice is to stop at the module name. When DeltaV encounters the #’s, it replaces them with the string you typed in as part of the alias resolution (it's really a little more involved than that, but it's a least a 2 beer discussion, so we'll keep it simple).

Can you use the aliases without the #’s? Of course - that’s how, if you’ve checked the Ignore box in the alias resolution, you can keep your phase from hanging up, waiting for something that’s never going to happen, by looking for the .IGN of the alias to be True.

Now here’s the trick – you can look at other attributes of an alias parameter, namely .CV. Since an alias is just a string parameter, looking at the .CV attribute will return the string. So if I needed to write who I am (unit metaphorically speaking) into another parameter in another module, I could use the following:

The #UNIT_MODE# is used to resolve the alias while the UNIT_MOD.CV is the alias parameter of the unit. So, if this was running on my SF_100 unit, then the aliased Arbitration module would have SF_100 written to its REQ_ACQUIRE parameter.

Pretty tricky, huh?

$IDLE_TIME is the Blue Devils Playground

Overall Equipment Effectiveness (OEE) is a hot topic these days, and again shows the interactions going on between levels 0, 1, 2 and level 3 of the S95 model.  Folks are exploiting the features and functions of DCS platforms to provide intelligence towards the calculation of OEE.  Bob Engel of Informetric Systems Inc, has got an excellent white paper on calculating portions of OEE by using their InfoBatch product to mine data from DCS batch historians, like the one in DeltaV.  Batch analysis and batch to batch comparisons are the key outputs.

There is a missing component from batch historians, and that’s information between batches.  One of the three components of an OEE calculation is Availability, and being able to account for a Unit’s time not making batches can be as important as recipe run time.

One of the new features in Version 10 of DeltaV was Dynamic Unit Allocation.  This had been a long awaited feature (I’ve wanted something like this since my PROVOX days working on resins projects for Monsanto).  In grossly over-simplified terms, Dynamic Unit Allocation is the programmatic selection of what units a recipe should run on.

As part of Dynamic Unit Allocation, Emerson developed the concept of the Unit Selection Policy.  You configure your Selection Policies to provide the logic to the batch engine for determining which unit or units to use while the recipe is running.  They provide a couple of default selection policies, one of which is the DEFAULT_LEAST_RECENTLY_USED:

So how does DeltaV know which unit is least recently used?  Ah ha, they’ve added a new, default unit parameter named $IDLE_TIME.  So if I have a choice of three dryer units to transfer to, and I want the one that hasn’t been used in the longest time, I can use the DEFAULT_LEAST_RECENTLY_USED policy, which in turn will somehow look at the $IDLE_TIME parameter of each dryer and pick the one with the largest value.

So this got me thinking, how could I exploit (I’m famous for this, right?) this $IDLE_TIME parameter for use in OEE calculations?  How can it help me know what I don’t know – the time between batches on a unit?

My first crash and burn was to try and create an external reference parameter in a module that pointed to $IDLE_TIME of a particular unit.  You can’t do, because you can’t see it when you browse, and you get an error when you try and just type the path in – SF_100/$IDLE_TIME.CV

A little voice in my head suggested I build up a dynamic reference string, but I’ve seen so many good configurations go bad with the over-utilization of dynamic referencing, I dismissed it.  But since I had the expression editor open anyway, I thought I’d just try typing in the path (remember, can’t browse) to the parameter – success!

At this point, there are endless possibilities on how to use it.  I decided I’d push a message to the Event Chronicle (which can then feed into the Batch Historian) the first time my unit wasn’t idle, and report how long it had been idle just prior to its use:

If your batch cycle times are measured in minutes or hours, perhaps you’d want to report a daily idle time per unit.  If your cycle times are measured in days, a weekly or monthly report would be more appropriate.

Now, go be more effective.

The Wide World of Wireless

We had a full house last week here in Charlotte, as we played host to a large group from the Savannah River Site. The focus of the three days was Wireless HART (WiHART) networks, and we had extensive, hands-on sessions.

Security was a primary focus, both to make sure the WiHART networks didn’t interfere with other RF domains and to make sure the WiHART network was secure from outside interference, both accidental and intentional.

We set up 20 different wireless instruments throughout our campus, both indoors and out, on three separate wireless gateways connected to DeltaV. Larry Wolfe, Director of Technology Deployment, and Carl Price, Director of PlantWeb Services, developed a variety of deployment scenarios to test such things as long distances (in excess of 500 ft) and signal paths through solid and glass doors.

Jeff Potter, Rosemount’s wireless security expert provided a detailed overview of the many features incorporated into Emerson’s WiHART technology specifically designed to keep it safe. One thing I learned was the way the gateway and instrument change up their encryption. See, if you had an instrument that was reading the same value all the time or one that changes very slowly (think outside air temperature), the signal back to the gateway, while encrypted, would be the same. Not so with the smarts built into WiHART. By modulating the encryption, eavesdropping or snooping become problematic.

Another clever security feature is the ability to use a HART modem attached to AMS to automatically setup the join keys on the wireless devices. This way, knowledge of the join key is limited, and only instruments that get temporally connected before being deployed to the field can join the appropriate gateway.

Our guests came well prepared also, bringing a couple of guys in from Oak Ridge with all sorts of RF sniffing tools. They were specifically looking at our 4 wireless office networks and how the WiHART devices were showing up in the RF world.

After the 3 days, the visit was considered a success.  Emerson’s WiHART passed the test and with apologies to UPS, Rosemount and RE Mason can ask “what can Blue do for you”?