Real Time Automation 1-800-249-1612 Contact Real Time Automation Contact Us Real Time Automation Product Support Support    
  Real Time Automation Homepage Real Time Automation Products Technologies We Offer Industrial Library Company Information

Archive for the ‘Source Code’ Category


Thursday, December 2nd, 2010

I’ve come to realize that my world is pretty different from the world experienced by many others. For example, I have the freedom to set my schedule. I pretty much come and go as I please and lately I’ve decided to stay out of the office until 10 or 11 each day.


Pretty nice, huh? The other half of that is that I still work 12 hours a day. There are always blogs like this to, plans to make, books to ready and study and a myriad of other things that go into running a business.


My world is different in how I look at the automation industry. In one of the ways I look at it there are only two classes of devices; messaging devices and I/O devices.


I/O devices, of course, are the work horse devices of EtherNet/IP. EtherNet/IP I/O devices, officially called EtherNet/IP I/O Adapters, are the sensors and actuators of the factory floor. They gather inputs from the field, condition them and send them to a Scanner device. If you have an I/O device and need to get your I/O device on EtherNet/IP, we’ve been successfully donning that now for about 12 years. It can take as little as a few hours but that’s not what I want to talk about today.


Today, I’d like to talk about those Messaging Devices. So, what are Messaging Devices and why would you want Messaging Devices on EtherNet/IP.


In my terminology Messaging Devices are any device that produces data at an intermittent rate greater than 3, 4 or 500 ms. In that definition, barcode devices, scales, RFID devices are all messaging devices.


Now scales are interesting. You could have a scale in continuous mode where you want it to deliver it’s current value continuously. In that scenario, you have a EtherNet/IP Scale that is just like an I/O Adapter. In fact, I would configure it as an I/O Adapter on EtherNet/IP.


But if your scale delivered it’s current weight every 2 seconds when the conveyor places a product on it, then it’s a messaging device. In fact, when we do scale applications we make them into dual EtherNet/IP devices able to act either as a messaging device or as an I/O device.


So what’s a messaging device on EtherNet/IP?


Well, the RTA approach is a little different than what many other EtherNet/IP implementers do. We make messaging devices as EtherNet/IP Client devices that are able to open connections to PLCs and other controllers and initiate messages.


Because they can open the connection and issues messages, our EtherNet/IP devices don’t monopolize the Ethernet bus. They only send messages when data is available.


An EtherNet/IP Barcode reader sends its barcode only when a barcode is available. An EtherNet/IP RFID device sends tag data to the controller only after reading a tag. And an EtherNet/IP Scale sends its scale data either when it is read or continuously.


So, if you are developing an EtherNet/IP Scale, developing an EtherNet/IP Barcode Reader or developing an EtherNet/IP RFID device, RTA has the perfect technology for you.


Monday, July 12th, 2010

There are all kinds of ways for Microsoft Windows users to get data in and out of ControlLogix and CompactLogix PLCs. Rockwell sells a of tool called RSLinx. There are a bunch of different models and ways to use it.


There are also OPC Servers. OPC  uses native Microsoft technology to move data between applications. With that technology, one application can consume data generated by another application. If for example, you have a database collecting user names that accessed your stockroom. With this technology you could automatically transfer today’s access list to a Microsoft Word document. It’s relatively easy to get data from one MS application to another MS application.


But what about those of us that want to use Linux. How can a Linux application read and write data in a ControlLogix or CompactLogix? Or even access some of the Legacy PLCs like PLC5E or SLCs? Rockwell provides nothing for that.


In that case, you have to take a look at our Linux EtherNet/IP Tag Client software. This is ANSI C software that runs as a task in your Linux application. Your App simply opens a connection to the PLC, fills in a structure with the Tags (variable identification in the PLC) you want to read (or write) and sends that structure to the Tag Client Software. You get a callback when the operation is complete.


The beauty of this software is two fold. One, since it is ANSI C, it compiles using any IDE. And two, the API is so simple, it is really easy to use. Most customers get everything running in an hour or two.

What’s wrong with RsLinx?

Thursday, January 14th, 2010

I get a lot of questions from customers about replacing RsLinx in their automation systems. It’s something that I have always wondered about. RsLinx is a good tool and provides a lot of functionality so why are these customers trying to eliminate it?


Well, for those of you that don’t know, what the heck is RsLinx? RsLinx is a software driver that knows all about talking to PLCs. Every PLC RA makes as a matter of fact. It can read and write registers in the PLC5s, SLCs, Logix and more. It is a communication server that can talk to any RA PLC that has an Ethernet interface. Sorry, for you PLC2 fans, you’re still out of luck [By the way, got a call today from an OEM that has hundreds of PLC2s and wants to keep them running – I’m going to build him a little interface box].


RsLinx has the PCCC drivers to talk to the PLC5 series, the SLC series and the MicroLogix. PCCC is the Programmable Controller Command and Control Language. It’s a binary protocol that implements the Read and Write command set that every RA PLC uses. RsLinx also has a little known, proprietary driver for the Logix series. That driver allows RsLinx to resolve tag names into an address and then pull data out of a PLC in a block read.


That’s the biggest difference between the way 3rd party devices access RA Logix processors and how RA devices access Logix processors. 3rd Party devices have to use the open CIP Data Service protocol standard to access the data tables of PLCs. The CIP Data Service protocol is open but not widely distributed. It’s on the RA website but you have to really hunt to find it.


The biggest drawback to the CIP Service is that you have to send the tag names to a Logix PLC to read and write data. That sucks big time! The packets going to the Logix processor are limited to 514 bytes and if you have 20 character string names plus 10 bytes of overhead per tag you can only get 10 to 15 tags in a message. Best case you are only going to get 30 or so messages through a second so your limited to less than 500 tags per second. That’s really slow for lots and lots of applications.


Though it doesn’t work very well for data intensive applications. If you just want to build your own solution with smaller data sets or you don’t have a critical time constraints, 3rd party applications like the RTA EtherNet/IP Tag Client work really well. From your app you simply build a structure full of tags to read or write and send it to the Tag Client. It does a call back when your data is ready. That software is really handy for a lot of non-data intensive applications.


So, why don’t people want to use RsLinx? Mostly it’s price. If you have an application that is a dashboard, a vision system or something else; you have to include the RsLinx in every runtime. If you use something like our Tag Client to access a Logix processor, you avoid that runtime cost. As long as you don’t have thousands of tags to access or need millisecond response you’ve saved yourself a lot of money over the long run.


But what if you need that kind of response or if you have lots and lots of tags? Well I have some thoughts on that and I’ll share them in the next article.


Tuesday, January 5th, 2010

I had one of those calls the other day. I’d actually love getting these out of the blue calls. You never know who they are, where they are or what they might say.


Most of the time these people are pretty capable and smart, sometimes they’re whack jobs.


One time a guy asked me if I could go to Malaysia. Well, I like to travel and don’t really know for sure where Malaysia is, so I said sure, I’ll go. If he thought I could help, who am I to deny him?


Then he tells me that I have to fly in on a helicopter. Oh – Oh. I am just terrified of helicopters. I have this perception that in a jet, we can just glide to a landing but in a helicopter I’m just gonna drop out of the sky. It turns out that I once, a long time ago, knew a dancer (ok, a stripper) that was a helicopter pilot. She assured me that they can “freewheel” or whatever the term is without an operating engine and land safely. In fact she practices that every week. I didn’t believe a lot of what she told me and I really didn’t want to experience a helicopter ride in which the pilot is going to turn the Engine off.


So the next thing out of his mouth is that the reason for the helicopter is that it’s too dangerous to go in on the ground. So, now I’m thinking that if I survive the crash, they’ll be a bunch of people who want to torture/eat/kill me. My rule of foreign business trips is to try to come back alive – you can’t tell a great story at a cocktail party if you’re dead. So, in the end I passed on the trip.


Anyway, the guy the called the other day asked me to tell him what the input and outputs were. “What inputs and what outputs?”, I said. He says he wants to implement his own embedded EtherNet/IP device and needs to know what the message in is and what the message out is.


After a few minutes of this it finally occurs to me that this guy thinks that EtherNet/IP is just some sort of Modbus messaging system. There’s a Master. The Master sends a message. The device responds to it. It’s no big deal.


Well I start to tell him about CIP object Models, Forward Opens, IGMP Multicasting, IO Messaging and all the rest but he doesn’t want to hear it. He just wants to know what  the GUZZINTOS and GUZZOUTTOS are. I tried to tell him that’s it a 6 or 8 inch specification of how all this works. That it took us almost 2 years to get it implemented and that we went through 2 years of field trials before we did this.


He was kind of shocked by that. But in the end, I really think he didn’t believe me. So I told him he could get the free version at the ODVA site. It’s not really up to date, there’s no one to tell you how to customize it for your device, how to build an object model with it or support you at the ODVA lab or when your product doesn’t work at a customer site.


Finally, he terminated the conversation. Probably to throw darts at my picture (which you can get at Some folks just want to believe that life is simpler than it really is.


Thursday, December 17th, 2009

Recently, I’ve had some interesting conversations with a developer in Texas about EtherNet/IP. They have customers that are requiring their I/O device to speak EtherNet/IP. This company doesn’t have much of a presence in the industrial market so EtherNet/IP is something completely foreign to them. Having EtherNet/IP means they can meet this customer’s requirement but might not add a lot of other product sales.


Naturally they want it to pay for itself through additional product sales. And their not sure they are going to get those sales. That presents quite a quandary for them as our software isn’t exactly cheap. In fact, I am very honest with everyone that our stuff is usually one of the most expensive solutions that they can find. 


Why is that? To provide the very best product we can and the very best service is expensive. We travel to all the ODVA meetings, all the SIG meetings and we often provide assistance for customers throughout the lifecycle of their product at no extra charge. We also provide tools, extra software modules that extend EtherNet/IP capabilities, test lab support and object model design assistance. Customers sometimes come here and camp out to learn what they need to know to make their product successful.


It is really true that you get what you pay for.  My friend John Mendocha was just telling me yesterday how his wife bought him new flashlights (Chinese made – very low price) and how within 24 hours both flashlights had broken.


So, what happened? Well, I encouraged this guy in Texas to get the free EtherNet/IP software. I couldn’t possibly discount our software enough and still provide him with the service he will need in the future. I told him that the free stuff presents a lot of risks, but short term, nothing is cheaper than free.


Some of the risks with the free stack are:

·       Designing an Object Model that makes sense when you don’t really understand what an EtherNet/IP Object Model is

·       Implementing your application objects without breaking the EtherNet/IP stack

·       Finding a device to test your EtherNet/IP device. If you use a ControlLogix you’ll be looking at $5K for the programming software plus RsNetworx.

·       Getting a listing of the last 100 hex messages sent to your device at the ODVA test lab and not knowing what the hell to do now

·       Having a problem at your first customer site where you device intermittently connects and disconnects and now knowing what to do


Essentially these are mid term and long term costs that pale in the face of the short term cost for a proven, reliable Royalty Free EtherNet/IP Source code stack, the tools you need to test it, the support you need to get it implemented correctly and having someone to call who’ll work with you when your customer is waiting for a response.


In the end, Mr. Texas decided that the short term cost for an “expensive” EtherNet/IP source code stack wasn’t really that expensive after all. It was really just a prudent business expense. And I think that was the right decision.


And now a blatantly commercial message: we have a royalty free Client and Server solutions for lots of platforms and operating systems including: Linux EtherNet/IP, Netburner EtherNet/IP, VxWorks EtherNet/IP and Freescale EtherNet/IP.

RTA, Inc. - The Industrial Networking Home for DeviceNet, EtherNet/IP, Ethernet Drive,
Modbus TCP, Modbus RTU, PROFINET CBA, PROFINET IO, BACnet, IEC 61131-3,
IEEE 1588, AS-Interface, PROFIBUS, EtherCAT and other networks.
© 2009 Real Time Automation, Inc.

Real Time Automation, Inc.
150 South Sunny Slope Road. Suite 130
Brookfield, WI 53005
© Real Time Automation, Inc. All Rights Reserved. |

(262) 439-4999 (V)
(262) 439-4989 (F)