Tag Archives: hmi

The User Interface Makes the Difference, Except in Automation

Start by watching this video about the Aeryon Scout robot (kudos Kareem):

I think what sets this aerial robot apart, as Kareem says, is the intuitive user interface. When I look at the state of automation today, I can see that good user interfaces are typically an after-thought. Custom solutions are sometimes so cobbled together that there isn’t enough bandwidth between one black box and the HMI, or the HMI is just a simple two line text display that ends up saying FAULT 53 (the manual with the list of faults, of course, is stuck inside the door of the panel, and it’s the only thing in the area that isn’t covered in grease because nobody bothers to look at it).

People frequently blame engineers for this mess, which I find a bit silly. Certainly user interfaces are a critical component of any system, but why do you hire an electrical designer to do the electrical design, hire a programmer to write the software, but expect one of these people to magically become a usability expert, which is a field unto itself?

I think there used to be an idea that there was no payback on usability. Certainly if you’re selling something like a VCR, you can only print features on the box (you can’t accurately represent the experience of using it) and people only buy one. However, as items become more social (think iPhone), we’re starting to see great user interfaces create viral marketing for products. I think I first saw this with the TiVo – once you saw what it could do, and how easy it was, you were hooked. Apple’s technology seems to be the same way, and I can see how the Aeryon Scout probably has the same “shock and awe” effect when you demo it.

Where does that leave us with industrial automation interfaces? Automation is always purchased based on a cost-benefit analysis because of the high capital cost. The operators typically don’t participate in the purchasing decision at all. I don’t think effort put into a better user interface is wasted; in fact I’m certain there’s a long term payback. But it’s not a selling feature and it takes more time to do right.

Still, when I programmed a machine recently, it was nice to overhear someone say, “it’s pretty intuitive, isn’t it?” So I guess I’ll keep trying, even if it’s not in my own best interest. Engineers are weird that way.

If you’re interested in making better user interfaces, first I recommend reading The Design of Everyday Things by Donald Norman. I also recommend this video called the least you can do about usability by Steve Krug, author of Don’t Make Me Think: A Common Sense Approach to Web Usability, 2nd Edition.

Beckhoff TwinCAT: a First Impression

Those of you who know me remember I’ve been itching to get my hands on a Beckhoff TwinCAT PLC industrial control system for a few years now, but I never found a project or customer willing to take on the risk of trying something new. Like a bunch of penguins on a cliff of ice, nobody wanted to be the first in the water.

I’ve recently had the opportunity to apply a TwinCAT PLC and HMI system to a relatively low-risk application, so I finally have something to share. Those of you who know me also know I don’t pull my punches when I talk about products, so here’s an honest review of the TwinCAT system: the good, the bad, and the ugly.

Benefits

Cost

What draws you to TwinCAT is its combination of low cost with a ton of features. I can’t publish prices, but I encourage you to compare prices from Beckhoff, Allen-Bradley, Omron, and others. Beckhoff offers a similar or better feature-set, with as many or more communication options than it’s competitors, for significantly less money (it’s real-time PC control instead of dedicated hardware). On specs it can do everything, and doesn’t bend you over the table when it comes to the price.

Scalability

First, Beckhoff TwinCAT PLC takes advantage of a PC CPU and memory, which means you can scale up the performance of your system for a fraction of the cost of scaling up to large PLC and PAC systems.

Secondly, if you use EtherCAT, you get to scale up your I/O sizes without as much impact on performance or price. The individual I/O slices are significantly cheaper than for other bus technologies, and the servo drives are less expensive because the bus speed is fast enough to close the loop from the PLC rather than in the device itself.

Where TwinCAT really shines is when you need to integrate it to the MES layer in your organization. Most other vendors require you to buy expensive OPC or other connection software, but Beckhoff provides a free DLL for Windows applications to communicate with the PLC over a communication protocol called ADS. (They also provide an OPC server as an add-on if you need it.)

What’s the Catch

Switching software vendors is never easy. If you’re used to your existing PLC software like RSLogix, you’ve got a bit of a learning curve ahead of you. Here are the things that down-right annoyed me about TwinCAT when I was coming from the RSLogix/PanelView realm:

  • When you do an online edit, it resets all of your forces. You have to reload your watch list to re-apply them. (Fortunately I always write perfect code the first time, so I never had to do an online change…)
  • The ladder logic editor doesn’t seem to auto-wrap (unless I’m missing a setting somewhere)
  • The HMI editor crashed a couple of times when I was modifying the HMI, and I had to restart the TwinCAT system (not the PC, just the software)
  • The English documention is lacking
  • The TwinCAT System Manager DeviceNET master configuration had a bug where it wouldn’t recognize EDS files where the Class value was stored as a 16 bit, rather than an 8 bit value. The EDS file was valid, according to EZ-EDS, but it wouldn’t read it. Changing the value to 8-bit made it recognize the parameter. This made it hard, but not impossible, to integrate an Allen-Bradley Point I/O DeviceNET node.
  • Even though the HMI will log an alarm history, there’s no alarm history control for you to view it in the HMI itself (it’s saved to a CSV file)

Here are some things that are just really different, but I’ve had no trouble adapting to:

  • You have to define all variables (tags) in a text syntax, instead of in a spreadsheet-like tag editor
  • I/O isn’t mapped directly. You define your hardware I/O and your program I/O and then you map them.
  • You don’t do online changes while you’re online with the PLC. You “log off”, then make your change, and then “log on” and tell it to upload your change. (You can do this while the machine is running.)

What’s Cool

Using a PC based controller opened up some interesting features, particularly in the HMI:

  • You can launch another application from a button click on the HMI (Excel, etc.)
  • You can configure some interesting alarm actions, like launching a program, or sending an email
  • There’s an (optional) add-in to let the PLC communicate in a limited fashion with a SQL Server
  • It runs on commodity hardware. PC hardware is cheap and you can get much larger touch screens for a lot less than the cost of an equivalent PanelView. The “fieldbus” card (EtherCAT) is under $100. Even a Beckhoff EtherCAT to DeviceNET master solution is cheaper than a straight-up DeviceNET card from another manufacturer.
  • TwinSAFE – a Safety Controller sitting right on your fieldbus for less than a stand-alone safety controller from another vendor.

Support

I had nothing but superb support from the local Beckhoff technical support guys during this experience. They respond to emails personally usually within a couple of hours, and they have no problem taking the two hour drive to see us if we have any issues that can’t be resolved over the phone or with email. We’re not a “big” customer in any way.

Summary

I’ve just spent about 2 weeks coming up to speed on TwinCAT, having come from an AB/Omron background, with a smattering of other PC based controllers like Phoenix Contact’s Visual Logic Controller (VLC) and MultiProg (formerly PCWorx).

The ease-of-use of TwinCAT doesn’t measure up to RSLogix, but it’s comparable to Omron, and it blows products like PCWorx/MultiProg out of the water (I think I was using version 3 of PCWorx, and I know there’s a version 5 now). Most of my issues with TwinCAT are that its ladder editor just isn’t polished enough compared with RSLogix, but that’s not surprising given its roots in Germany. North America tends to favor ladder logic, where Europe seems to favor instruction list, structured text, and function block diagram. It feels like the TwinCAT ladder logic editor was neglected a bit, but it is certainly workable. Comparing the TwinCAT sequential function chart editor with the RSLogix sequential function chart editor, they were actually reasonably close. I liked that I didn’t have to position individual steps in TwinCAT – it just auto-arranged everything for me.

Price-wise, TwinCAT is significantly less expensive than any other serious player in the industrial automation equipment space, particularly when you start ramping up the amount of I/O and drives you need, and it has similar (and in some cases better) features to offer. It’s even significantly less expensive than the Phoenix Contact solution (from my memory), and given that, there’s no reason I’d ever recommend a PCWorx/MultiProg solution from Phoenix Contact. The Phoenix offering is worse and more expensive.

If you’re in a position where your facility is in the market for a new automation platform, I definitely recommend including the Beckhoff TwinCAT platform in your deliberations. It hits a really unique sweet-spot on price, flexibility, and features that nobody else seems to be able to offer right now. Now that we’re a few weeks in, we have a running machine, it looks like the project will be successful and I have no reservations about saying: if you don’t mind learning something new, give them a try.

Lost Display (Graphics) in RSView Studio

I’ve been working on an HMI application recently (RSView ME). At the end of the day I saved everything, closed the project, then used Application Manager to backup the application to an .apa file and store it on the server.

This morning I opened the local copy of the application, and a significant portion of the work I had done yesteday was “undone”. It was only one of the displays, but all of the changes were missing. I restored a copy of the backup, and it was the same there. Now I’m pretty paranoid about saving my work, so I probably saved that display about 50 times yesterday, and it was definitely saving somewhere. The question was, where?

Here’s what I did to get myself into this problem:

  1. Started by copying one display (let’s say “A”) to make a new one (let’s say “B”).
  2. I then renamed the duplicate (let’s say from “B” to “C”). I probably didn’t close the display before renaming it (which might have caused the problem).
  3. I made all of my changes to the display, saving along the way.

It turns out that the changes I made were being saved against “B”, not “C” even though “B” didn’t really exist anymore. I was able to recover from this problem with the following procedure:

  1. Close the application (but leave RSView Studio open if you want)
  2. Goto C:\Documents and Settings\All Users\Documents\RSView Enterprise\ME\HMI projects\[proj-name]\Gfx
  3. Rename C.Gfx to D.Gfx
  4. Rename B.Gfx to C.Gfx
  5. Open the application again in RSView Studio. The changes should be restored.

I hope that helps someone one day. 🙂