Making my device PLC friendly

I work for a major manufacturer of industrial camera equipment. One of our initiatives this year is to make our devices PLC programmer friendly.

The current situation is that we support a serial or Ethernet (TCPIP) connection using a proprietary and overly complex protocol that is not straightforward to implement.

We have been told that implementation of Ethernet IO will make the product more attractive to PLC developers. My understanding is there are 2 options, Explicit Messaging and Implicit I/O.

So my first question is which of these is easier to implement for a PLC programmer. Which is more common for connected devices?

Go for adhering to one or both of the big industrial ethernet standards, Profinet and/or Ethernet/IP.
You may not have to develop much yourself. There are toolkits and chipsets destined for OEMs. Here is one:
http://www.innovasic.com/component/...477a56e093fa&gclid=CNeh49Lz2KoCFQgE4godDE5f6g

and another:
http://www.softing.com/home/en/indu...ons-field-devices/index.php?navanchor=3010091

JesperMP said:

Go for adhering to one or both of the big industrial ethernet standards, Profinet and/or Ethernet/IP.
You may not have to develop much yourself. There are toolkits and chipsets destined for OEMs. Here is one:
http://www.innovasic.com/component/...477a56e093fa&gclid=CNeh49Lz2KoCFQgE4godDE5f6g

Click to expand...

Yes, I'm sorry I meant Ethernet IP not Ethernet IO and as you have stated, it is our plan to find a Ethernet IP stack from a vendor rather than implement ourself.

But my question and I plead complete ignorance to all things PLC, is once I have a stack in place, I assume that using the Implicit I/O scheme, I get a 500 byte data structure from the PLC every so often and I provide a 500 byte data structure from my device every so often.

Is this basically correct?

By "implicit" I think you mean that the data is exchanged cyclically and deterministic.

Both are relevant for PLCs.

Cyclical is the most "typical", and is used for general signal exchange, interlocks, status information.

Messaging is used for when larger datasets have to be sent on event. Recipes, parameter sets.

So do most devices support both types of exchange (cyclic and messaging)? Assuming a feature/function on my device can be implemented by either type of exchange, which one cyclic or messaging is easier for the developer to work with?

IO Devices are almost always scanned cyclically by the controllers that "own" them.
Communication between higher level devices, such as from controller to controller can be both cyclically scanned and messaging.

Not sure what category your vision device falls into.
I can imagine that your vision device should signal "go" or "no go", "part OK" or "part not OK" or something like that. That would be cyclically scanned.
If on the other hand some complex set of parameters has to be sent to your vision device, then that would probably be by messaging.

First off, thank you for your replies on this subject. I apologize for my ignorance.

Our device is typically configured by telling it which job to load. Once the job is loaded and the system is online, it is triggered and reports good or bad for each inspection area. It can also return the content of each area as well.

We have been told that supplying AOP's and AOI's with our product would facilitate easier integration by PLC programmers. Any thoughts on that? My limited understanding is that AOP's describe the nature of the data/tags supported by the device and that AOI's are functions that can be called by the programmer, written by us to do some of the more common work associated with our device.

He may just be a camera manufacturer, not a vision system manufacturer. For example, Pelco uses a proprietary protocol to control the pan/tilt/zoom/etc... These protocols are used by others within the industry but I doubt you could get a PLC to speak Pelco protocol D. I could see a benefit to having a PLC controlling this type of camera, for example if an alarm is activated a camera could be moved by the PLC to also monitor the condition.

Shawn

Once the job is loaded and the system is online, it is triggered and reports good or bad for each inspection area.

Click to expand...

Sounds like a vision system to me.

rob137 said:

We have been told that supplying AOP's and AOI's with our product would facilitate easier integration by PLC programmers. Any thoughts on that?

Click to expand...

I think AOP and AOI is "candy" for Rockwell RSLogix programmers.
AOP and AOI are not part of the Ethernet/IP standard.
But since Rockwell RSlogix is the biggest Ethernet/IP vendor, it may be well worth it.

JesperMP said:

Sounds like a vision system to me.

Click to expand...

Yep, he posted while I was typing.

As I PLC guy, I have to start by telling you that I don't have a clue how hardware OEMs that can read/write PLC registers do it. So you're on your own there.

However, if you want to be "PLC-friendly," a good example would be Parker's Compumotor 6K motion control family. Within their programming software, you can list Parker registers that you want to be linked to PLC registers. There are four separate lists - Integer Read, Integer Write, Bit Read, Bit write. They communicate over Ethernet and all I have to do is set the PLC's address in the 6K, link the head ends of each list, and set number of words on each list. These are contiguous of course but that's no problem.

I only do this with AB SLC PLCs - so this is OLD tech. Bits are actually linked to binary bit words, which both AB and the 6K use. All words are only 16-bit and the 6K and PLC cannot exchange 32-bit reals, which has been and still is a limitation. Still, not much of one most of the time. AFIK the linked registers are updated as frequently as possible, probably by a clock in the Parker 6K but again this is transparent to the PLC side and it's not something I have to worry about. If you wanted to offer polling and update on change, fine but not a big deal in many cases.

So, FWIW, this might be an approach. If you really want to get my attention with your PLC interface, then something along these lines - provide the Ethernet address, link the registers that are exchanging data, and go - is the way to do it.

Now, I know there are a lot of PLCs out there, but hey you asked! LOL. Maybe your marketing guys might want to go out and ask your current customers what PLCs they're using. Good luck, I wish that more hardware vendors would ask this question. Either I would have more hardware that was easy to interface, or I'd learn more programming to do it myself. Win either way.

This is helpful. Our goal is to facilitate as easy an integration as possible. What you have just described is very similar to the way we might utilize an OCX control for an object when programming in C++. Like you I'm not sure how this is actually done for a PLC, but the concept is helpful.

How important is documentation and sample code for a developer?

Do you have a link to your web site so we can view your product information?

One such way to interface your product, would be by developing a protocol that would act as the interface to your device.

For instance, ModBus is an open protocol that many (but not all) control manufacturers offer.

Unfortunately, there are just as many protocls as there are PLCs.

Depending on how your device operates, one such way of connecting would be through an OPC server. Not at the PLC but rather interfacing directly to the OPC Client (aka HMI)

Some PLCs can accept a basic ASCII string while others can do a read/write in ASCII.

Much will depend on how much information and the type of information you are looking to make available to the PLC.

With PLCs, they each have their own addressing scheme, but with a protocol such as ModBus, it specifically identifies read registers, write registers and holding registers.

Some things for you to think about.

We have a lot of experience with Ethernet

My company makes motion controllers. In order to "play well with others" we have implemented many PLC Ethernet protocols and can have many connections open at the same time and each connection can be talking a different PLC Ethernet protocol. This requires a very good Ethernet programmer but it is necessary to "play well with others".

Doing all of this is not cheap. It takes many months to write a stack that can be certified as compatible with each protocol and there are fees associated with the testing.

I would use implicit I/O where the data just shows up in the PLC or motion controller. Messaging is much slower and often involves TCP/IP instead of the faster UDP.

One problem I see is that both the vision systems and our product are designed to be slaves. What we are looking for is a vision system that can scan product and download X and Y coordinates along with encoder/time synchronization data. This means the vision system must be the master and also have access to some means of doing the synchronization.

I have a nice motion control example where the motion controller chases down product moving on a conveyor at different intervals and locations across the conveyor. I originally did the application for chasing down knots and punching them out on-the-fly while veneer is going by. The problem is that no has yet to make a good method of directly downloading the data into the the controller. Going through the PLC is too slow.