This blog is dedicated to open, interoperable manufacturing software and the coolest, latest and greatest things I see every day while conducting business under the banner of Inductive Automation.

Hello, my name is Steve Hechtman and I am president of Inductive Automation. During the span of one day there is more excitement, more discovery than I can possibly keep to myself. This blog is, therefore, my outlet. WARNING: This site is highly biased in favor of the most powerful, affordable manufacturing software in the world - Ignition by Inductive Automation!

Inductive Automation - Where Did the Name Come From?

Every so often I get asked the question of how did we come up with our name "Inductive Automation." I think Carl first suggested it and and it stuck. This is probably because it's such a fitting name - let me explain...

From Wikipedia "Inductive reasoning, also known as induction or inductive logic, is ... commonly construed as a form of reasoning that makes generalizations based on individual instances. " That's precisely what we did when we created the framework for what was to become the Ignition platform.

Before we wrote a single line of code, I developed a philosophic stance in response to my specific experiences in the controls integration business. In other words, I established generalized principles from my specific experiences and observations. Therefore the "Inductive" part of Inductive Automation is very appropriate.

The Observations
My experiences and observations were many and varied but they boiled down to the following:

1) I was frequently being asked to develop or integrate database applications into industrial systems but industrial software just didn't deal with databases and when it did it was ugly. Developing "one offs" with custom code was not economically feasible, nor was maintaining it in the longer term.

2) Unreasonable pricing for industrial software alone was killing way too many deals. I lost one customer (for a few years - he's back now) because he thought I was trying to rip him off. The whole job was $105k but $85k of it was software which we had to buy. I'd already pared down my labor to $20k due to the high overall price tag. In retrospect, it's better I didn't get that job because my labor was so low I would have lost money.

3) Installing industrial software alone was a huge time consuming process. For an integrator you would think this would be a good thing because it's usually billable. But I would rather be putting my time toward developing a better app - not installing software.

4) Most industrial software only runs on certain versions of Windows and when IT wants to upgrade, the whole process usually becomes a nightmare – if not impossible – forcing IT to maintain different flavors of Windows.

5) Realizing the full potential of industrial software wasn't possible due to lousy deployment models and lousy licensing models.

6) I observed that standard IT software and technology was inexpensive and worked better than what I saw as expensive, non-standard, convoluted, odd-ball industrial software.

7) I also saw that the simple task of logging PLC data to an SQL database server was being portrayed as rocket science or something. Why should it take hours or days to setup a process historian? Our programmers who came straight out of the university at first had a hard time understanding what the big deal was. Nor could they understand why a historian should sell for $30k or more. They finally concluded that this industry has had the wool pulled over its eyes for a long time and that it's about 10 years behind the IT industry in general.

8) When I even mentioned the possibility of a web-based solution to customers it instantly hit a chord with them.

9) Most industrial software scaled poorly, strictly from a technology standpoint. In fact, at a certain point of scaling up maintaining it effectively usually becomes impossible, whereas normal IT technology scales very well with little effort.

10) Industrial software security was non-existent or oddball at best whereas standard IT technologies pretty well have security figured out.

11) Generally speaking, canned middleware applications offered by industrial vendors are totally out of touch with anything customers actually need. In reality, every manufacturer already has its own processes developed out of its own experiences in dealing with situations. The point is not to redefine these processes, but rather to automate them in software.

The Principles Concluded
So what are the general principles I derived from all these experiences?

1) Don't reinvent the wheel. Well established, proven and inexpensive IT technologies already exist. Use them.

2) The more eyes on the data the more useful a system is. Accessibility is paramount. Therefore leverage web-based technology.

3) Be database centric. This aligns with the principle #1 above. IT departments can support database servers (which do need backups and maintenance from time to time). Be able to support any database server an IT department uses. Database servers form the ideal interconnection point between different software applications and greatly increase the usefulness of any software application. Islands of information and proprietary data repositories are a bad thing.

4) Avoid software that imposes arbitrary limitations just to make more money. From observation, this really jacks people up.

5) Be cross platform. This includes every flavor of Windows as well.

6) KISS (Keep It Simple Stupid). Software should never be more complex than is necessary. Avoid bloatware. Avoid heavyweight installations. Software should seem lean and mean and refined.

These are the general principles I started with and when I did so I wasn't even planning to start a software company (look at the first principle again). All I wanted to do was find software out there that met these criteria. I spent several months looking exhaustively and only found isolated bits and pieces out there. Therefore, I took the plunge and started a software company. Our guiding light has always been the above principles and they seem to be good ones because we now have thousands of installations in over 50 countries.

Ignition runs on PanelView Plus 6

More than one customer has asked us if Ignition clients can run on PanelView Plus 6 operator terminals. Since PanelView Plus 6 terminals run on CE we figured it should work when using the Mobile Module. It turns out this is only partially true. The newer logic module, which runs CE version 6.0 with extended features (that last part is important), can run Ignition using the Mobile Module.


Rockwell was kind enough to provide us with a unit to try this out. The exact part number they provided us was 2711P-T12C4D9, which includes the extended features. My understanding is that the term extended features means it can run third party software and is packaged with a Word viewer, Excel viewer, PDF viewer and Media viewer. In this case we copied the open-source .NET VNCviewer.exe application onto the PanelView Plus 6 using a USB stick. This application works with the Ignition Mobile Module to deliver Ignition applications on the PanelView. VNCViewer can reference a separate configuration file with parameters to make it run in full screen mode, use 16 bit color and other settings.

While the Mobile Module normally utilizes the HTML 5 canvas component to deliver mobile applications, it is also a VNC server. The configuration for this is under the advanced checkbox in the mobile configuration section of the gateway. It's important to fill in the name of your project in this section.

Launch Clients Using the ME ActiveX Program Launcher
We got fancy and launched our Ignition client right from a PanelView application using the ME ActiveX Program Launcher. This ActiveX control is provided with FactoryTalk View ME. You must set the "program source" to path\vncviewer.exe and can set the "program parameter" to your VNCViewer configuration path\file.

One of the interesting things about this is that when your Ignition client is in full screen mode and you quit out of it, the VNCViewer also terminates. It seems to take a second click to do this.

Proof of Concept – Details Available Upon Request
This test was just a proof of concept. I'll write up all the fine details I know of and I will make them available to anyone who inquires. For example, I can provide you with my VNCViewer configuration file or project settings to make your screens scale properly without scroll bars.

I would not call the performance snappy, but depending on your situation this could be a good solution for you if you're trying to minimize the number of terminals on your floor. I would say give it a try and then decide.

One good thing is that the logic modules are separable from the screen unit and you can upgrade your logic modules using the Rockwell Step Forward program. The cost is somewhere between $1,100 and $1,500 with trade-in of your old logic module (which saves you $400 - $600 depending on the model). My understanding is that not every distributor supports this program, but I know Rexel in Sacramento does because they gave me this pricing.