Newsletter Insert March 2013

Drew & Scott’s Young Gun Automation Insert

A Bank Brain Drain is a Technology Sector Gain

Drew Baryenbruch

Through the 1990’s and 2000’s Wall Street lured in the best and brightest minds the world had to offer. They brought them in with piles of cash and used their brilliance and creativity to innovate and manipulate the market. It worked for a time. Trillions of dollars were made. Then came the financial implosion of 2008. Turns out it was partly triggered by the best and the brightest on Wall Street engineering products that helped inflate a massive housing bubble, and then magnified the losses that resulted. Now regulations have stepped up and the freewheeling times are over. Young talent is fleeing and Wall Street executives are worried about who is going to take over when they are gone.

I think this is the best economic news to come out since the great recession started. After 20 years the best and brightest minds in America will finally be working on goods and services that add value to the collective whole instead of finding ways to take their piece of market pie. We finally took the aura off a profession that requires more liquor and guessing than marketing. Don’t agree? In 2011 84% of mutual funds underperformed the S&P index. 56% missed the mark over the last five years. That means that when picking a fund you would have been better buying an index fund or flipping a coin than listening to the hot air a well paid picker was spewing about his fund.

The reason this is exciting is that the next highest grossing product released will not be subprime mortgage backed security but a tangible asset that adds real value to GDP and the human collective. The US will again have its greatest assets working on goods.

Innovation in Automation:
I don’t think it is a stretch to say that our industry is due for some real innovation. Hopefully some of these great minds find their way to our industry. Don’t get me wrong, new protocols come out, and new products offer new and improved functions but there has been very little innovation that makes a compelling argument to throw out the old and adopt the new. In an article featured on Automation.com last week, IMS research estimates that fieldbus protocols accounted for 75% of new industrial automation component connections deployed in 2011. Ethernet enabled devices are not projected to represent 50% of installs in a given year for 10-15 more years! That is mind boggling to me.

I am usually the first to argue all the business cases for staying with what works and to the merit legacy protocols and devices have in many applications. The problem is that by accepting those arguments we close the door on meaningful innovation in our industry. We all talk ourselves out of great ideas. It’s laughable how cryptic our world is by comparison. Plug a Smartphone into a PC and the PC automatically finds the phone driver and can sync files and folders with no human interaction. Yet adding a device like a drive, simple by functional comparison, to a PLC requires lots of human interaction. The user is defining the relevance and type of the data being moved.

We need a fresh face with the gall to tell us how dated we are. More importantly they have to be visionary enough to ignore all the friendly advice our entrenched industry would offer when kindly explaining why the idea would not work “here.”

Paradigm shifts rarely seem logical until after they happen. There is a lot of luck, a lot of work, and a lot of ego behind most. Maybe a few Ivy League’rs will now make it to our industry with enough of those attributes to shake up the automation market.

If not, our lethargic advances insure that the need for our Fieldbus to Ethernet Protocol gateways will be in demand for some time to come. If you have and application that requires moving CanOpen, DeviceNet, Profibus, Modbus RTU or ASCII data to an Ethernet protocol give me a call.


Note:
The idea behind this bimonthly insert is to get Generation Y ready to take reigns of the Automation industry. Scott and I both fall in the 20 something range. If there are particular topics you would like addressed drop us an email.

DrewandScott@ rtaautomation.com

What is LONworks?

Scott Zukewich

LonWorks™ is an open device networking Protocol. It was originally developed by Echelon Corp in 1988. In 1999 it received ANSI certification and the solution moved from a Proprietary IC to open software that could be ported to other embedded processors. The Neuron IC from Echelon is still by far the most popular form implemented.

Why is Lon Unique:
LonWorks is very different from the open device networks like DeviceNet, Profibus and Modbus typically found on the factory floor. First, unlike these popular device busses, LonWorks is a completely peer-peer network. Instead of moving data through a “Master” device, any device can exchange data with any other LonWorks device on the network. Second, LonWorks is not tied to a single physical communication layer. Where DeviceNet is limited to CAN and Profibus and Modbus are limited to RS485, LonWorks can use a twisted pair, Ethernet or even a power line as its communication channel. Central Controllers are still used in many LON applications but they are not necessary for the transfer of data.

What is Binding?
Network data exchanged on LonWorks is configured by a network configuration tool. This operation, called “binding,” ties an input of one device to an output of another device.

What Are Network Variables?
A major goal of the LonTalk protocol is to give developers the ability to design products that will be able to interact with one another. The LonTalk protocol provides a common applications framework that ensures interoperability using powerful concepts called network variables and Standard Network Variable Types (SNVTs). Functional device models have been developed by the LONMARK Interoperability Association to assure plug and play compatibility.

Data Interaction:
Communication between nodes on a network takes place using the network variables that are defined in each node. The product developer defines the network variables when the application program is created. Network variables can be shared by multiple nodes. Some nodes may send a network variable while others may receive. By only allowing links between inputs and outputs of the same type, network variables enforce an object-oriented approach to product development. This greatly simplifies the process of developing and managing distributed systems.

Whenever a node program writes a new value into one of its output variables, the new value is propagated across the network to all nodes with input network variables connected to that output network variable. This action is handled by the protocol within the Neuron Chip.

Just What are SNVTs?
The use of Standard Network Variable Types (SNVTs, pronounced “snivets”) contributes to the interoperability of LonWorks products from different manufacturers. For example, a SNVT for continuous level is defined as SNVT_lev_contin.

LONmaker:
LONmaker is the leading software that allows users to bind data between the multiple devices in an application.

Node Builder:
The software used to define the profile within a LON device.

SNVTS in Action
Let’s look at a Profile from a simple device like a light.

  • SNVT_SWITCH (95) –
    Structure of…
    unsigned value (0 to 200)
    with a resolution (0.5)
    signed state (On or Off)
  • SNVT_AMP_F (48) –
    Floating Point Value…
    (-3.4×10-38 to 3.4×1038)

The SNVT_SWITCH gives you the state of the light, On or Off and the percent of brightness the light is set to 0-200 with a resolution .5.

The SNVT_AMP_F is a floating point value that gives the amperage being used by the light.

Future:
The popularity of BACnet/IP has greatly diminished the dominance LonWorks once held. While there are still companies holding strong to LON (including the US Defense Department), there are fewer applications where it has a definitive technological advantage.

With a strong hold in military applications, LON is going to be a legacy protocol you should have a basic knowledge of for some time to come.

Any Questions about your system? Give us a call or Email.

Drew&Scott@rtaautomation.com