1. Better expertise in the areas they serve (international law in the case of China Law Blog’s firm, Harris & Moure)
2. Better customer service
3. Better pricing (for example, Harris & Moure will do many jobs for a fixed fee).

I feel the same way about many of the smaller automation suppliers; I feel the products are better, the service is better, and the pricing is better than  I get from the automation giants.  OK, they aren’t covered as well by the press (or many bloggers), but that’s never concerned me.  The ones that have been around a while (such as Galil) are going to be in business just as long as the biggies, with a lot fewer strategy changes.

And, when these firms get bought out by big companies, they do seem to get at least just a little bit worse (and sometimes much worse — I can think of a couple cases where I’d find it difficult to buy from them again).

In summary, I do often feel that small is beautiful.

OK, there aren’t really that many, but it seems like there is.  Which one to use?  One approach is to look at the suppliers you like and see who they support.  For example, I like AMC and Copley drives; they both have CANOpen drives, but for Ethernet, Copley only sells EtherCAT drives and AMC only sells Ethernet PowerLink drives.

I don’t have time to list all the vendors I’d normally consider and what standards they support, but I did notice they almost all use one of four choices:

• The motion control vendors use either EtherCAT or Ethernet PowerLink
• The embedded PC / PLC / Input-Output vendors support Modbus/TCP or Ethernet/IP.

Also, the IEEE-1588 precision time protocol (used by Ethernet PowerLink and Ethernet/IP CIP) is going mainstream in a big way; I will write more about this topic later.

I find it interesting that the drive vendors and I/O vendors use different standards; I wonder how many people need a lot of motion and a lot of I/O.

And, yes, my view is very much a personal,  North American, discrete automation view.  But I’m not saying any of the other field-bus choices are bad; just apply the same approach with your supplier list.  For example, if your preferred vendor is Siemens, it’s obvious which way you should go…

Larry O’Brien comes to a similar conclusion about software developers: bad programmers are not slow programmers – they are programmers who are actively counter productive to the code base. In a fascinating post, he argues that the goal isn’t a silver bullet for programmer productivity, but a silver codebase, which bad programmers make impossible. Larry started all this discussion by dissecting the myth of the super-programmer.

My take – he makes sense to me. I’ve had to clean up code from some, well, people who shouldn’t have been programming, and it was not pretty. I’ve seen how a well designed codebase can make adding functionality much easier. On the other hand, I currently have an inherited codebase that needs some serious refactoring before it’s anything close to silver.

Tony

“Europe’s most successful PC pioneer, Hans Beckhoff, has a simple two-part formula for success: 1. Put everything in software, on one platform, and 2. Give the customer everything he needs so he doesn’t have to buy anything else. “

Interesting, since Beckhoff makes its money selling hardware. But, its hardware is all PC connected.

A lot of people view copying the PC industry as the inevitable way forward for the automation industry. This means using PC industry standards, such as OPC (originally based on MS’s OLE technology), Windows XP and CE, Ethernet, PXI, and embedded PC’s.

The big advantage is the lower cost, and theoretically more standardization, but there are many disadvantages, such as:

• The short lifespan of PC technology. A personal example – I have a PC at home with a good Quadro AGP video card. How many new AMD AM2 motherboards support AGP? 1, and it’s not very good. So building equipment designed to last 5 years or more with generic PC technology will have problems with spares down the road.
• PC technology isn’t always so cheap. Sure, generic PC’s, even in a 4U rack mount case, are cheap. But if you need IP67, or fanless, or a PanelPC, or guaranteed spares – well, your performance goes down and your price goes up.
• Innovation is shifting away from PC’s. If an automation company continues to be PC-centric, they will miss innovation based on the new innovation drivers, such as web standards (now much sexier than MS’s COM technology), cell phones, and automotive electronics.
• Commodity OS’s aren’t real time. I know, I’ve tried to do very soft real time with Windows, and it wasn’t pretty. Linux looks like it’s slowly getting there for soft real time, but it’s not mainstream yet in the factory. Yes, there are add-ons, but they cost extra in money (e.g. Venturecom) or time (learning hard RT extensions for Linux)
• PC standards often do not support industrial needs well, and thus need tweaking; for example, the PCI bus morphing into CompactPCI and PXI, and Ethernet being extended with EtherCAT. But the volume goes down, prices go up, and you lose some of what made PC technology compelling.
• Too many standards – think of all the industrial Ethernet protocols.
• Old technology does not go away, so PC automation control needs to be able to communicate with the rest of the world, including PLC’s.

A company can’t be everything to everybody, and Beckhoff is right to focus on PC-centric automation. But if I were running an automation component company, my formula would be “1. Give your customer products that help him build better machines and 2. Understand you cannot meet all of your customer’s needs – integrate easily with the rest of the world.”

Tony

There is a lot to discuss about factory automation. My background primarily in building custom or semi-custom, relatively small machines. So I’m not very interested in hydraulics. But it’s still much more enjoyable to work on physical systems made of precision metal that move, than to work on the next overhyped and unreal Web 2.0 website (and don’t get me started on marketing abominations like “Instrumentation 2.0″)
But I also enjoy learning and applying better software development methods. Most of the factory world, however, is happy to make it into the 1970’s structured programming with IEC 61131. Unfortunately, IEC 61131 (especially structured text) looks good compared to many devices I’ve programmed, such as

• Galil’s motion controllers with “intuitive” two letter commands. They finally added structured IF…THEN…ELSE blocks, but it’s still pretty primitive.
• IMS’s MDrive Motion Control products.
• Animatic’s Smart Motors.
• And too many similar products I’ve looked at but fortunately haven’t had to program.

OK, to be fair, outside of the programming those aren’t bad products. In fact, I like the IMS MDrives with just the stepper motor and driver integrated – they work very well with Panasonic PLC’s, for example.

I’ll also be taking side trips into other areas such as desktop development, embedded development, and photography.

Tony