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 ‘CoDeSys’ Category

EtherNet/IP Node 2 Node communication

Thursday, January 28th, 2010

Every once in a while I get someone that just can’t understand why one EtherNet/IP node can’t talk to another EtherNet/IP node. It’s a common objection to CIP (Common Industrial Protocol) in general and EtherNet/IP in particular.

 

Why do they want to do that? Well, for lots of reasons. If one node detects a quality problem, other nodes may want to act on that. If a downstream impurity is high, there is no sense in injecting more expensive raw materials into the process. The best thing to do is to shut that injection process down.

 

CIP, EtherNet/IP, DeviceNet and the other protocols based on CIP are PLC-centric. That means that they are nearly always PLC based. Those systems have a PLC getting inputs from the network, processing logic and sending new outputs on the network.

 

Essentially, what these people are saying is that they want to eliminate the PLC. They don’t want to eliminate the logic – they still need the logic. They just want to move it farther down the automation architecture.

 

This is possible, even desirable in some applications. In fact, that’s what the CoDeSys Open Control Tool is designed to do. CoDeSys is an open PLC language that can be easily (within reason) ported to an embedded platform. You can then write logic for drives, valve controllers, IO blocks and anything else having the CoDeSys control engine.

 

OK, you do this and now you’ve eliminated the PLC. Great! Hooray – let’s all cheer. But now you’ve introduced a whole host of new problems. You need to keep track of all this low level code that’s distributed around the network, you need to have access to the I/O of the other nodes on the network – remember; you’ll need to make sure that outputs are only driven from one source. And how are you going to synchronize code that is running in 30 different processors.

 

Now, there is technology that addresses a lot of these problems. And there are people in universities and research labs that are trying out these solutions. Lucky for them, they have lots and lots of time and usually money to buy all sorts of stuff. But the short answer for the rest of us is to just use a PLC. Until there is a real easy way to address the backup, synchronization and management of distributed control we’ll just keep doing what we know works and has the least risk.

 

Appreciate your PLC more now? If so, just drop out to the production floor and give it a little hug…After all Valentines Day is nearly here.

What in the world is Mechantronics?

Friday, May 22nd, 2009

At this weeks CoDeSys seminar in Lund Sweden, Ken Ryan (he’s the guy with me in this picture), Director of the Mechatronics lab at Alexandria Technical College in Alexandria Minnesota, gave a very interesting talk on the evolution of manufacturing automation. As part of that talk he introduced the concept of Mechatronics; somewhat of a new term for me. I had heard it before but never gave much thought to it.

 

 

Ken started with a description of life before computers and microprocessors. If you’re under 40 now you probably don’t remember those days. We had garage doors that didn’t rise and fall on command, rotary phones (tied to a wall someplace where everyone in the family could hear your conversations) and worst of all, TVs that had only 3 channels. And you got off your butt and walked up and physically turned the dial to check out another channel. After a while, there was such a thing as a remote. They used infrared I think to transmit signals out of the remote and when you pressed the button, a stepper motor turned the dial for you. It was clunky and made a huge gnashing sound as you flipped through the channels.

 

It wasn’t any better in the factories either. Automation was a set of relays tacked up on a wall. There were literally acres of relays with wires from one relay to the next relay and that was how control functions were implemented. The relays looked something like ladders and some old wise guy electrician whose name is lost to history probably started calling it ladder logic.

 

In those early days about 95+ percent of a machine was mechanical. There might have been some lights and some switches but that’s about all. The ME (Mechanical Engineers) guys ruled. Even when I started in the 80s I remember that the Kimberly Clark converting machines had these monstrous line shafts that were 30 or 40 yards long. Every few feet there was a gear box that transferred power from the line shaft to some other mechanical device.

 

It was a real challenge to the mechanical guys. To start these huge shafts you had these huge motors. But as the motor started turning the shaft resisted it. A body at rest tends to stay at rest (Newton, right?). They had all sorts of problems with waves moving through those mechanical parts as they started it and tried to change speeds. Those waves caused product quality issues as material couldn’t be held in place very easily. And as those components wore down, the quality issues got worse and worse. There was some brilliant work done by those guys to overcome thoee problems and get maximum productivity out of the mechanical systems.

 

Now we’ve gone the other way. The majority of what happens on a machine is electronic. It’s all software. But that has just moved the problem and in some ways made it worse. Software is hard to do right, easy to screw up. It takes a lot of time to develop and debug it. Not many people have a real good handle on a process to design, implement and test it. It’s even hard to spec out what you want to do.

 

The “science” of working on this problem is called Mechatronics. That’s what Ken does in his lab way up there in Alexandria [It’s so cold up there that the only day they take off their long underwear is on the fourth of July – winter starts again on July 5].

 

A big part of the Mechatronics effort is using CoDeSys and other IEC 61131-3 software tools to make it easier to develop automation systems, produce higher quality software and reuse a lot of it so that you’re not starting from scratch every time.

 

If you have a chance, check out the Center for Applied Mechatronics website at http://www.camc-online.org/.

WOW - CoDeSys 3 Shocks Me!

Wednesday, May 20th, 2009

 

I’m spending today in lovely and I mean lovely Lund Sweden. And I’m not just talking about the Swedish ladies though I have found no where in the world with this concentration of beautiful blonde women. If the world ever ran short, it could be resupplied from here, probably without much notice. They’re like ants at a labor day picnic.

 

I’m here today to take part in the 2nd annual Scandinavian CoDeSys conference. It’s an update for all the Scandinavian partners that are using CoDeSys in all sorts of applications.

 

Best Engineering is sponsoring the event. Best is the local supplier of CoDeSys programming services and application support. They help machine builders all over this part of the world develop applications. They’re a small company, just 3 or 4 Engineers but they have a real good handle on who’s doing what in Sweden, Norway and Finland.

 

I am really stunned by the advancements made in CoDeSys. They have added some significant advancements that are going to make KW, Isagraph and the rest get the willies. Here’s a summary of the new features in no particular order:

 

Distributed Applications – This is ISAGraphs claim to fame and 3S is slowly chipping away at it. I am not sure that ISAgraph isn’t still the leader in distributed apps. It’s 64 system demo is pretty impressive but 3S is showing signs of catching up fast.

 

Conditional Compilation – You can now not only use standard conditional compilation commands but they’ve added a ton of new Pragmas. You can use the new pragmas to check if a variable is defined, if it has a value, if it has a type and a whole lot more.

 

Fieldbus Configuration – They’ve done a lot of work here to unify all their fieldbus interfaces. They now normalize everything to XML and store all the configuration files in a common place. In CoDeSys V2 they are distributed all over your hard drive.

 

OPC Server – They’ve enhanced their OPC server offering. The same server can not connect to both CoDeSys V2 and V3 controllers. There is a demo available and I might be wrong, but I think it’s free. Imagine that!

 

PLC Handler – The OPC server is now based on some technology they’ve developed called the PLC Handler. The PLC Handler is a generic way of moving data in and out of CoDeSys based controllers. Now, non windows devices have an easy way to integrate and talk to CoDeSys controllers.

 

Soft Motion – 3S has done a great job of enhancing their soft motion offering in V3. It’s fully functional and contains a wealth of predefined function blocks that can be used in these sorts of applications.

 

Object Oriented Programming (OOPs) – They’ve added support for OOP interfaces in CoDeSys and it is really going to be beneficial for those of us who’ve grown up on true Object Oriented Programming.

 

There’s a lot more, like the ability to convert between different programming languagues, between Function Block Programming and Ladder without compiling. The demo was really cool. And there is even more coming! Dimitri Phillipe,m the 3S International Sales Manager, wrapped up the day with a preview of the future and I can tell you that it’s pretty exciting.

 

If you’d like to have CoDeSys on your device and take advantage of this fantastic programming environment, it’s possible. Visit CoDeSys PLC Engine to get more information and then call me. I’d be happy to talk to you about it.

 

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.
www.rtaautomation.com


 
Real Time Automation, Inc.
150 South Sunny Slope Road. Suite 130
Brookfield, WI 53005
© Real Time Automation, Inc. All Rights Reserved. | http://www.rtaautomation.com

(262) 439-4999 (V)
(262) 439-4989 (F)
www.rtaautomation.com