Merging modern software development with electrons and metal
Random header image... Refresh for more!

Category — Automation Philosophy

Automation Trends I Want To See

Here are some factory automation trends I’d like to see:

  1. Much more adaptation and appropriate use of modern software development techniques such as version control, design patterns, functional programming, unit testing, automated testing, model based design, hierarchical state machines (state charts),  and agile software development.
    1. From what I can see, most automation developers still aren’t borrowing from the best of mainstream development techniques.
    2. A big reason I started blogging was to promote these techniques.
  2. Use of modern programming languages.
    1. There’s been some progress here with more use of PC’s in automation and companies such as Beckhoff supporting the use of Visual Studio.
    2. There’s been some progress on the PLC front: IEC61131 isn’t remotely comparable to .NET, but it’s a big improvement over the past.
  3. Fewer poorly designed, vendor-specific programming languages.
    1. This is a pet peeve of mine, since I’ve had to deal with way too many.  Modern ICs have advanced far enough that we shouldn’t have to keep reverting back to 1970’s-style programming languages.  If nothing else, please use IEC61131 with PLCOpen for motion control.
    2. Unfortunately, this problem isn’t going away, but at least with companies such as CoDeSys widely licensing IEC61131 software, it hasn’t gotten worse.
  4. Advanced automation programming books.
    1. The basic problem is there aren’t any.
    2. There’s a chance Frank Lamb of Industrial Automation: Hands On fame will improve the situation.
  5. Widespread kinematics in motion controllers.
    1. This really is a trend, especially in controllers targeted towards the packaging industry, and it’s a good thing: we have enough cheap computing power that we don’t need to treat linked axes as a bunch of unrelated axes anymore.
  6. “Everything” on industrial networks (fieldbus and Ethernet) at a reasonable price premium.
    1. The situation is getting better, except for the price premium.  I’ve recently seen more unusual networked components such as barcode readers, smart cameras, and laser distance sensors.
    2. Of course, if you’re trying to get all these devices to work on the same network, your options shrink dramatically.
  7. “Everything” on industrial real time networks (fieldbus and Ethernet – such as CANOpen, EtherCAT, and Ethernet PowerLink) at a reasonable price premium.
    1. Other than servo drives, there are a lot fewer components available for the real time networks.
  8. Fewer standards, but still some variety.
    1. It’s hard to have one standard that adequately meets all the varied needs of the wide world of automation.  For example, in Ethernet there are major tradeoffs between use of standard components, robustness, and real time capabilities.
    2. But  there are way too many standards.  In Ethernet, 2-3 industrial standards should be plenty.  I think we’ll have to live with 5-6 (Ethernet/IP, Modbus TCP, Profinet, EtherCAT, Ethernet PowerLink, and maybe CC Link IE, which is sort of Ethernet (PHY only), which is manageable, but there are at least 20.  And too many companies still invent their own serial protocols (RS232, RS485, CAN, etc) instead of using a standard.
    3. I guess all these standards is good for the makers of gateway devices…

End of rant!

In between my Robot Primer posts, I will highlight some cool networked devices.

August 29, 2013   No Comments

Legacy Product Support, eBay,and Sales

Automation component suppliers should provide at least minimum support such as downloadable manuals and drivers for forever.  First, many machines last a long time, and customers need to keep them running, including if manuals or drivers get lost.

Second, it’s smart business to support the second hand market, such as eBay.  I often buy automation equipment from eBay, and I expect reasonable support, which means I can download documentation and drivers; I don’t expect free tech support.  (I understand that for controllers such as PLCs or motion controllers, the programming software often isn’t free; I won’t buy that controller if I can’t program it).

My eBay purchases have lead to some substantial orders.  I still might have selected the Copley Accelnet servo drives, but having myEBay units really helped.  Right now, I’m considering using some AllMotion servo drives for a very specific application; the only reason I am considering AllMotion is because I have one I can use to prototype the system.

Yes, I can (and have) received loaner units, but it’s a hassle, not all companies will provide them, and some times there’s a long time between using something and being able to spec it into a machine.

Microchip is the classic example; they make microcontrollers (MCUs) and owe much of their current success to the fact that they are hobbyist friendly.  Many of the their microcontrollers are still available in easy to use DIP packages, they provided good documentation, support, and free software.  Their chips became very popular with hobbyists, who created an ecosystem of designs, articles, forums, etc, which over time has led to substantial production orders, especially as people familiar with their chips moved into engineering positions.

September 23, 2012   No Comments

When Suppliers Start Milking You, Start Moving

I’ve reached this point with my local telephone service; it’s now at ~$28/month for unlimited local calling.  My cell phone bill is just a bit more, but is a much better value.

I could go cell phone only; however, my wife values the local phone number (she is the main user), and we both like having a phone number for people we don’t know, such as banks, schools, etc.  I could also change to metered local calling, but it doesn’t seem worth it to potentially get stuck with overages for a still substantial ~$22/month.

So, I’m moving to dump AT&T.  The big duaolopy (phone & cable) tries to make it hard by charging you a lot more for unbundled services, but it’s still a better deal than paying for unwanted bundling, such as voice & DSL or cable internet & TV.

I have a lot of choices for VoIP (voice over IP), such as Skype, magicJack, Ooma, iTalkBB, and Asterisk-based systems, but I’ve installed a refurbished Ooma Hub from Fry’s.  The cost is affordable (under $4/month for taxes gets me unlimited US calling), it’s simple to install (unlike Asterisk), works with our existing phone (which my wife likes), doesn’t require a computer (unlike magicJack), and it includes E911 services (unlike Skype).  So far it’s working great.

The final step is to switch my internet to non-AT&T/non-cable, for example, Dry Loop DSL.  The savings at first won’t be huge (about $10/month), especially considering I have to invest some money up front for Ooma ($100) and a new modem ($50-$100).  But there’s no chance the phone rates are going down, so the sooner I change, the sooner I’ll start saving.

The same logic applies to business.  Your CAD is asking too much in maintenance fees for too little value?  Seriously investigate changing (or use a mix); there are good alternatives, some of which are probably better than what you are using.  Your PLC vendor nickle and dime-ing you?.   At least start a pilot test using a brand that supports you better.

Changing might be painful, and may not make sense for a variety of reasons, but at least investigate the options, because the chances of these leopards changing their spots are pretty slim.  If you’re going to change eventually, you might as well start sooner than later.

March 3, 2011   1 Comment

Boutique is Beatiful

The China Law Blog recently highlighted an article about boutique law firms and why they have been doing well during this recession:

  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.

March 31, 2010   No Comments

Ethernet Fieldbus Wars: One answer

There are two million different Ethernet field-bus standards.

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…

June 5, 2009   3 Comments

“A Bad Technician Is Worth Negative Money”

“A Bad Technician Is Worth Negative Money” is something I said a lot back in the days when I had to go around and fix all the stuff the night shift technician had screwed up. A technician who causes problems is worth negative money because not only does he not do his job, he sucks up the time of others who must fix his mistakes.

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

February 1, 2008   2 Comments

Limitations to the Personal Computer Model

I was looking at automation blogs and come across this comment about Beckhoff:

“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

June 8, 2007   No Comments

Why yet another blog?

Simple – because I couldn’t find any decent factory automation blogs. I can find plenty of software development blogs, but the few automation blogs seem to be all about company strategies and new products, not about the realities of trying to integrate various components together into a working system.

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

June 4, 2007   No Comments