More on the new eVSM Calculator Engine

In my last post I talked about the new eVSM Calculator engine.  I mentioned how this new more flexible engine allowed us to do some cool new things, and I'd like to go over some of those cool things here.

The first new tool is the Source/Target capability in v6 (I think available after 6.15 or so).  Source/Target is simple enough in principle, in that it simply enables you to link a variable shape to one or more other variable shapes.  This actually works between pages in a single Visio document, so you can cross-link from one map to another.

Here are the shapes you use:

The pink shape is a Data Source, and is basically a named variable on the map.  You just specify a short alphanumeric name for the source, and then you add one of those blue shapes, called a Data Target.  You just make the link by making the target name the same as the source name.

You can actually have multiple data sources with the same name, and if you look closely at the target shape it says "SUM".  This is the default way the target handles multiple data sources: it sums their values.  If you right click the target shape you can change it to take the average, max, or min value of the sources available with that name.

You can also make the target path-based, meaning it only uses sources that are on centers with the same path number.  There's also a new (in v6.20) option when you right click a target shape for viewing the sources that the target will use.

One important note here is that by default, the calculator engine will only search the current map, for data sources and targets.  If you want to link to another page, you have to set the "Page Scope", so that the calculator engine knows what pages to search.  We do this because we actually calculate each page in the scope, in order to make sure the values we use are current.  We also do this because if you copy a map to build a future state map, your source and target names would stay the same, and so we'd actually start using a lot of data we shouldn't.

To modify the Page Scope, click the Name Unit Manager button in the eVSM Toolbar/Ribbon, and click "Page Link Scope" near the bottom.  You'll then see a list of all the pages in the current document, except for the current page.  We don't list the current page since it's included in the page scope by default.

Now, here are some advanced tips for using source/target:

• Every variable shape on the map actually has a "hidden" Data Source shape on it, with the variable name as the text.  So if you wanted to simply put the sum of all Cycle Time variables in the Lead Time variable, you would just add a Data Target to the lead time and set its text to Cycle Time, and that's it!
• The source/target engine uses text matching to find matches, so not only are they case-insensitive, you can use simple wildcards to make the target a bit more flexible.  For instance, if you had three sources, S1, S2, and S3, you could get the Sum of all three by setting your Data Target text to "S*".  The * character tells us to just look for the letter S followed by anything.  You could also do "S#", which would only match the letter S followed by a single number.

Source/Target gives eVSM users a powerful method for linking between maps, especially with our new Wizards we are creating (I'll talk about those in the future).  If you're curious, you can actually see that the way this works is very simple.  We are just linking cells in the eVSM document's Excel workbook, the same that you could do manually.  This is just a way for you to tell eVSM to make those links.

New Developments with eVSM

I just realized I've been working on eVSM for almost a year, and haven't really talked about any of the changes we've made in that time.  Part of the reason for that is I've not wanted to talk about new upcoming features until they were released and well documented.

I now realize many features have been in use for at least three months, if not longer.

The first I'd like to talk about is one of the flagship functions of eVSM, the eVSM Calculator.  This tool has been around since early versions of eVSM, and has grown new features over the whole time of its existence.  What used to be a simple function for exporting shape data fields to Excel and pulling user equations back in from Excel has grown into a powerful tool that writes the equations for you.

The complexity of the code behind the calculator grew quite a lot, since the original base code was never really designed to handle some of the functionality it grew to support.  This ultimately ended up in long run times for calculating a map.  While probably good for the coffee, water bubbler, and gossip industries, we realized the calculator was getting too slow.

So we rewrote the tool from scratch.  Which is usually a bad idea.  But in our case, we sort of treated the old calculator as a 10 year old prototype that happened to work wonderfully in production.

The old calculator used VBA collections to hold a lot of the data from the map in memory, which made things really hard to debug.  I did modify the collection code to also store the keys for the collection within the collection, so I could at least see what data was where.  But in the end I ended up designing a simple object model using VBA Classes, which provides us an "early binding" of many of the properties we want to know about our eVSM shapes (tag ID, paths present, variables present).

The overall hierarchy we have now is a Map class at the top level, which holds all the data for a single Visio page.  Each map has a list of all the "Row" centers, which are individual process (or other type) blocks, which we store as a Tag object.  The Tag object keeps a pointer to the center shape, the tag shape, and holds a list of Paths and Data.  The Data collection is a list of NVU objects.

By putting all the page data into this object model, we found we could read the Visio page one time, and keep all the data we wanted in memory, in very convenient and (relatively) efficient objects.  The other big performance gain came from using batch array techniques to talk to the Excel application object as few times as possible.  We found we could make our VBA code as inefficient as we wanted, as long as we minimized the number of calls to Excel and Visio's application objects.

Overall we found we were getting at least 5x speed improvements, while maintaining the functionality of the tool.  We did have to find and fix many bugs, most of which were probably encountered the first time writing the old calculator.  But I'm happy we ended up rewriting from scratch, as this new object model has enabled us to do some great things, which I'll have to put in other posts.

Server Load Balancing Simulation

I read an interesting (to me) post about scaling a web application using the Heroku stack, and how they ended up having capacity issues not from the servers, but from the load balancing router.

Heroku recently changed the router from selecting the next available server to just selecting a server from the pool randomly and passing it without blocking.  Each server has its own blocking queue, in this case.  The justification from Heroku was that for a non-blocking server (like Node.js) this wouldn't be an issue, and should improve utilization.

But, the folks at RapGenius use Ruby on Rails, which is a blocking server, meaning they can process just one request at a time.

So I was reading the article, and they were complaining that they now needed to increase the number of servers, in order to meet the demand on their website.  I was starting to get antsy when they seemed to be speculating, but then they showed results from a simulation they ran in R, and that made me really happy.  Especially since they were able to put together statistics for their request processing times and identify a distribution.

I can't help but think how easy this model would be to build, run, and analyze in any of the available discrete event simulation tools we use, rather than use R.  But, R is free to use and our favorite discrete event simulators are not so much.  But, I wonder how many of these startups would ever consider using something like Simio to model their website infrastructure, and ultimately help themselves scale up.

Here's the post.

Etch a Sketch Charting

Every metrics board on every shop floor needs one of these.  Don't like the latest metric?  Shake it until you forget...

Someone should hook one of these up to MT Connect.

Lifehacker Link

eVSM User Group

There is a user group for eVSM on LinkedIn where I and the other developers of the software are members.  We actively read the activity on the group, and it's a great place to reach us for help with mapping problems, as well as submitting feature requests.  We also form feature review groups, which help drive improvement in the software.

Even though it's on LinkedIn, it's an open group, meaning anyone can at least view the contents, without having to have a LinkedIn membership.

eVSM User Group on LinkedIn

As an aside, if you have any suggestions for eVSM you can also submit them by using the Contact Me link on the side of this page...

Player Piano and MT Connect

I recently read Player Piano, by Kurt Vonnegut. The book is about a society that has had almost all manufacturing automated away, and the skilled labor relegated to fixing potholes, essentially being paid to do nothing.

The beginning of the book goes over how things are made. So at one point bright young engineers devised a way to record the movements of master machinists and play them back over again, obviating the need for machinists. Aside from the issue of how you'd go about making a new product or process change without a machinist to record, the idea had to be intriguing in 1952 when the book came out.

The really interesting part, though, is Vonnegut's description of the status display in the office in a factory (which had about 3 people working, total). The display simply shows a brass plaque for each machine, with a status lamp that would flash red if there was a problem.

The point of the book has little to do with how the factories worked, instead dealing with the resentment between the few people who still had meaningful jobs, and those that didn't. It did, however, get me to think a bit about what the point of MT Connect is. If you think you need MT Connect in order to keep all your machines working all the time, then that is completely misguided.

I suggest instead you read The Goal and put some thought into which machines need to be fully utilized. Spoiler: it's only a few of the many.

Which leads me to an encouraging thought: you don't need to connect all your machines in order to get value from MT Connect. You don't need a massive investment in Adapter installation and IT infrastructure. You could instead find your bottleneck resource(s) and monitor those to start correlating downtime with its root causes. Then you can fix the root causes and increase throughput without worrying about the 97% (made up statistic) of machines where it doesn't matter if they're working 100% of the time.

So the question I have now is what would you use to monitor bottleneck machines with MT Connect? Would it be as simple as a lamp for each machine that matters? Really, it could just be a smartphone app that shows a list of machines and flashes red for problems. Ideally it would route alerts to the right people automatically and keep some statistics on performance over time.

If no one beats me to it, maybe I'll build the app. As an aside, it would probably be easy to build using Firebase, which is excellent.

In conclusion, read The Goal and Player Piano and you'll be better off than you were.

Now For Something Not Entirely Different

I've quit my job at the CT Center for Advanced Technology (CCAT), after over six years.  CCAT was the first real job I had out of college, and I learned an incredible amount of skills and worked on incredible projects with incredible people.

I couldn't help it.

I've been given the opportunity to join the folks at eVSM as a consulting developer, helping them add new features to their product, which, if you've read much of this blog, I'm a pretty big fan of.  We'll also get into some new areas which I can't discuss, but it's very exciting for me.

The reason I couldn't help but leave CCAT was, the eVSM gig allows me to be my own boss, and take on contract work with anyone I want to work with.  The upsho is that I'm already contracting with CCAT on some MT Connect work, and look forward to helping them on interesting projects in the future.  I'll post a link when this first contract is done.

At the moment I'm pretty tied up with CCAT and eVSM work, but over time as I get acclimated to working in this manner (read: when I want, where I want, and what I want) I hope to create some great software products that will help people in manufacturing (and healthcare, services, etc...) be great at their jobs.  I also hope some of the five people who read this blog might consider taking on my services at some point.

This probably means I'm not going to be doing much of anything with QUEST, though I expect to be doing something with simulation very soon (probably with Simio though).  I also plan on continuing my participation in the MT Connect standardization process, because I truly think it will be a game changer in the field of Industrial Engineering.