Deterministic network choices...

I'm working on a project where I get to update the controls of a wind/unwinder machine, and I'm trying to decide different components of it. I'd like to chat a little about the network choice.

The current system has a Siemens HMI/PLC, and 3 ABB, ACS800 drives, with wind/unwind firmware, connected by a Profibus network. The application is run by the software in the drives, and the HMI is used to do some basic math and enter variables into the drives and monitor feedback values, like tension and roll diameter. It's a simple system, and I think I'll keep it that way, since I'm the guy who gets the phone call when something goes wrong.

A little history.... This machine was my first exposure to Siemens- Simatic Manager (Step 7) and Profibus a couple years ago. I understand more than when I started, but my school was more Allen Bradley and 61131-3... not Siemens. I find it a little hard to follow, especially understanding the memory addresses without labels. So when I re-design the controls, I think I'm going to choose Allen Bradley (there is a good budget for this project).

I'm not sure about my network choice, though.

Some of my customers have DeviceNet networks, so I have the RSNetworks, which includes ControlNet. I've never worked with ControlNet... which is one reason to include it in this project. The engineer who designed the current system used a deterministic network, so I'm inclined to do the same out of inexperience. But I have thought about EthernetIP. I'd just like to hear from peers who have more experience with this choice. What would you use, and why?

Here are more details:
HMI- Allen Bradley (although I have used, and like Red Lion on other projects. I can put the software in the budget- then I'll have it for other projects.)
PLC- Allen Bradley (The customer expects it and wants to pay for it. Again, I'll put Logix 5000 in the budget.)
VFDs- ABB, ACS880s, with wind/unwind firmware. (Because the current machine is my template, and I'm uneasy about inviting problems that might come from inexperience)

Load cells provide feedback to the unwind drives, and a prox sensor provides roll dimension feedback to the winder drive.

I need to have my plan and quote together by the end of next week. Thoughts about the network, or anything that comes to mind about this project are appreciated.

Doesn't sound like the actual PLC logic or IO count is large, so you could probably get away with an entry level CompactLogix L16ER, PanelView Plus 7 Standard HMI, chuck a couple of Ethernet/IP adapters on the ABB drives and have everything networked over Ethernet/IP. This small setup will run fine on an unmanaged Stratix 2000 network switch.

Swap out the PVP7 HMI for a Red Lion if you want some more flexibility.

I've used ABB ACS800 series drives over Ethernet/IP before but not with wind/unwind firmware. You might just want to talk to your ABB rep about whether there are any implications using this firmware and controlling them over Ethernet/IP (there might be some limitations in terms of what parameters you can read or write to with the standard Ethernet/IP profile).

One quick word of warning on brendan's suggestion - the 1769-L16ER processor can only have 6 expansion cards, at 8 I/O points each (plus the 16DI/16DO onboard). That doesn't leave you a lot of breathing room for anything more than a very small machine.

Of course, you can always add a point I/O rack if you need more - but the other limitation of the L16 is 4 ethernet/IP nodes. Three VFD's on ethernet and one for an I/O rack leaves you hard up against the wall for expansion.

I'd probably go for an L18 at the very least, just to give yourself a liiiiitle more breathing room.

Other than that - I agree with brendan. Ethernet/IP is probably the way to go, but definitely speak to an ABB rep about the application if you're using ABB drives.

(disclaimer: I'm an insolent young whippersnapper and I love me some ethernet. I don't think I've ever recommended ControlNet or DeviceNet for a new application, and I'm not likely to start now )

AutomationTechBrian said:

I find it a little hard to follow, especially understanding the memory addresses without labels.

Click to expand...

This tells me that either you uploaded the software from the PLC and are working your way back, or you have the variable comments turned off in the editor.

I really appreciate the responses. I'm watching the board today! I still hope to get more thoughts about the network.

+1 for Ethernet/IP. I have two DeviceNet systems in my facility and if I could find all the components necessary to replace them with Ethernet/IP, I would do it in an heartbeat. Never used ControlNet.

ASF said:

I agree with brendan. Ethernet/IP is probably the way to go, but definitely speak to an ABB rep about the application if you're using ABB drives.

(disclaimer: I'm an insolent young whippersnapper and I love me some ethernet. I don't think I've ever recommended ControlNet or DeviceNet for a new application, and I'm not likely to start now )

Click to expand...

Exactly, I wish ControlNet and DeviceNet would just die off (add datahighway as well). I keep getting people bringing it up for long runs. I would rather fight with fiber than have to figure out why ControlNet randomly dropped.

If you're going to re-design with new controls platform, then it would be an easy choice for me: Beckhoff PLC on EtherCAT. Click here to read why you need EtherCAT. The customer is king, so if they absolutely have to have AB, well you go with that. Still, I would at least mention to the customer the benefits (performance, flexibility, and cost) with the Beckhoff platform.

You can get a CX2040 for around $2800 brand new direct from Beckhoff. From a performance standpoint, it is probably better than anything you'll find in any other platform's CPU (believe it or not), and the CX2040 is not even Beckhoff's top-of-the-line. Its sounds like it would be overkill for what you're doing, but you'll have loads of over-head performance if you ever need it in the future on that machine. You won't need to worry about I/O count limitations. You need/want determinism, then without question its EtherCAT hands down. But if you go AB, you're not getting EtherCAT. They don't have support for it. TwinCAT interfaces very easy with ABB drives so that's not a problem. You'll have all the 61131 languages inside TwinCAT so you'd be covered there too.

This solution gives you top-notch performance, determinism/speed, at a fraction of the cost.

EDIT: I forgot to mention if you already have the drives, then most likely they don't have an EtherCAT interface (??). So you would need to get an EtherCAT to whatever bridge from Beckhoff. The perfect system would be to have EtherCAT-ready drives. But hey, if you've got the budget for new AB hardware, then you could easily purchase new drives with that money saved with the Beckhoff solution, and then still have a bunch of $$ left over. I'm sure managemen/customer would appreciate that.

If you're going to re-design with new controls platform, then it would be an easy choice for me: Beckhoff PLC on EtherCAT.

You can get a CX2040 for around $2800 brand new direct from Beckhoff. From a performance standpoint, it is probably better than anything you'll find in any other platform's CPU (believe it or not), and the CX2040 is not even Beckhoff's top-of-the-line. Its sounds like it would be overkill for what you're doing, but you'll have loads of over-head performance if you ever need it in the future on that machine. You won't need to worry about I/O count limitations. You need/want determinism, then without question its EtherCAT hands down. But if you go AB, you're not getting EtherCAT. They don't have support for it. TwinCAT interfaces very easy with ABB drives so that's not a problem. You'll have all the 61131 languages inside TwinCAT so you'd be covered there too.

This solution gives you top-notch performance, determinism/speed, at a fraction of the cost.

https://new.abb.com/drives/connectivity/fieldbus-connectivity/modbus-tcp
Your communication cards in the ABB look like they would do Ethernet IP and Modbus TCP.
Have you looked at the Productivity Series of PLC?
https://www.automationdirect.com/productivity

Regards,

Does the current system have drive-to-drive communication for speed references or does all that go back through the network link to the PLC and then back down to the drives?

If you will have a drive-to-drive link then what plc side network you choose is pretty irrelevant from a performance standpoint. Go with what you feel comfortable with.

Strictly speaking very few of the networks in major use today are truly deterministic. Also, while determinism seems to infer speed, there is no requirement that a deterministic network be fast. It just needs to be able to deliver data on time, at exactly the same time, every time, no questions asked (application reliable and very low jitter). What MOST of us really want (not you, Peter) are reasonably fast networks. With those networks we can live with some jitter and some message delay because the data is coming at you so fast that that the jitter (if we even care about jitter) is still below our control needs. So don't get hung up too much on determinism unless you are ABSOLUTELY SURE you really need it.

Long story short, any of the popular modern networks today (which all happen to be Ethernet based, go figure) will work fine for most general purpose winder applications even if you are generating drive speed commands from the plc, which you aren't. Back in the early 2000's I implemented a group of 2000 FPM winders with a PLC5 over Remote I/O (the AB network, not the concept). The stuff today is leaps and bounds better than that. Don't lose too much sleep over this.

Keith

kamenges said:

Does the current system have drive-to-drive communication for speed references or does all that go back through the network link to the PLC and then back down to the drives?

Click to expand...

This is the best question asked so far.

Strictly speaking very few of the networks in major use today are truly deterministic.

Click to expand...

Ditto

Also, while determinism seems to infer speed, there is no requirement that a deterministic network be fast. It just needs to be able to deliver data on time, at exactly the same time, every time, no questions asked (application reliable and very low jitter). What MOST of us really want (not you, Peter) are reasonably fast networks.

Click to expand...

Ha, ha, you knew I would be monitoring this.

With those networks we can live with some jitter and some message delay because the data is coming at you so fast that that the jitter (if we even care about jitter) is still below our control needs. So don't get hung up too much on determinism unless you are ABSOLUTELY SURE you really need it.

Click to expand...

I agree. It depends on the performance requirements but.....

Long story short, any of the popular modern networks today (which all happen to be Ethernet based, go figure) will work fine for most general purpose winder applications even if you are generating drive speed commands from the plc, which you aren't. Back in the early 2000's I implemented a group of 2000 FPM winders with a PLC5 over Remote I/O (the AB network, not the concept). The stuff today is leaps and bounds better than that. Don't lose too much sleep over this.

Keith

Click to expand...

If you only need synchronizing within a millisecond then fine.
I have talked to some Rockwell integrators that think 100Mhz is not fast enough.



We/Parker Fluid Power, have had pretty good luck synchronizing 32 controllers over Ethernet/IP. The project worked very well an no appreciable phase delay was detected. However, if you want to avoid transferring data to a PLC and then back to another controller then I have a solution where there are only microseconds of delay.


We will support EtherCat next year because so many have been bamboozled into thinking distributed control is the best way.


CIP motion might be good if Rockwell would make a generic CIP motion option for RSLogix. We are members of the Rockwell group that determines the future of CIP motion and synchronization. They have their meeting most Friday morning over Skype or similar but you need to be a member of the group.


BTW, we have the specifications for CIP motion but until Rockwell allows third parties to participate we and others are excluded. Last week we had a meeting with the Temposonic engineers and they too complain about this.

Peter Nachtwey said:

We will support EtherCat next year because so many have been bamboozled into thinking distributed control is the best way

Click to expand...

It's nice to know that Delta will have the support for ECat next year sometime. I'm looking forward to it. Appears you may have been monitoring the other thread I was heavily active in

I suppose I'm one of those that has been "bamboozled" and maybe that was intentionally directed my way? Is there a better way than distributed control, and if so, why? I'm open to learn. I'm still a firm believer that EtherCAT is the best industrial communications protocol on the planet. If someone can educate me on a better one, I can be humbled and I'm open to learn.

Peter Nachtwey said:

CIP motion might be good if Rockwell would make a generic CIP motion option for RSLogix. We are members of the Rockwell group that determines the future of CIP motion and synchronization. They have their meeting most Friday morning over Skype or similar but you need to be a member of the group.


BTW, we have the specifications for CIP motion but until Rockwell allows third parties to participate we and others are excluded. Last week we had a meeting with the Temposonic engineers and they too complain about this.

Click to expand...

I'm not well-versed at all with CIP, but reading this, it appears that this may be Rockwell's rendition of Beckhoff's EtherCAT (??). Maybe this is why Rockwell doesn't support EtherCAT and why they don't allow third parties to participate - "If you want CIP, then you have to buy our hardware" (??).

busarider29 said:

I'm not well-versed at all with CIP, but reading this, it appears that this may be Rockwell's rendition of Beckhoff's EtherCAT (??). Maybe this is why Rockwell doesn't support EtherCAT and why they don't allow third parties to participate - "If you want CIP, then you have to buy our hardware" (??).

Click to expand...

Just to clarify, CIP is Common Industrial Protocol which is the protocol that runs on Ethernet/IP, DeviceNet, ControlNet. Nothing to do with motion really, this is what normal remote IO communication uses for example.

CIP Motion (utilising CIP Sync) on the other hand is a different beast, and is what Peter is referring to. This is the Ethernet/IP solution to determinism for closed loop motion control. This is the part that Rockwell have closely wrapped up and aren't allowing 3rd party manufacturers to integrate with Logix using CIP Motion profies.

Some good reading here if you're interested.

https://www.odva.org/Technology-Standards/Common-Industrial-Protocol-CIP/Overview
https://www.odva.org/Technology-Standards/Common-Industrial-Protocol-CIP/CIP-Sync
https://www.odva.org/Technology-Standards/Common-Industrial-Protocol-CIP/CIP-Motion

busarider29 said:

It's nice to know that Delta will have the support for ECat next year sometime.

Click to expand...

This is being forced upon us because there are fewer and fewer drives that have analog inputs. Many drives have optional analog input cards but these are probably kludges. I am still extremely skeptical about using EtherCat for inputs but not so much for outputs. The details get geeky.

I'm not well-versed at all with CIP, but reading this, it appears that this may be Rockwell's rendition of Beckhoff's EtherCAT (??). Maybe this is why Rockwell doesn't support EtherCAT and why they don't allow third parties to participate - "If you want CIP, then you have to buy our hardware" (??).

Click to expand...

Every PLC company needs to make up yet another protocol to perpetuate the tower of Babel syndrome. CIP, Sercos, PowerLink, and EtherCat are all basically trying to do the same thing. The problem is that whomever comes up with the first deterministic network wants to patent it and licence it for money. Other companies need to either licence it, feeding their competitor, or make up their own deterministic network.

I do have problems with EtherCat. The standard way of using EtherCat for motion control is to send data back and forth in CanOpen packets that are only 8 bytes. I view this as a HYUGE limitation unless I only want to send output values to drives which is exactly how we intend to use EtherCat.

What I like about EtherCat is that it is a relatively light protocol that doesn't consume a lot of resources like ProfiNet.