Deterministic network choices...

ASF said:

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 )

Click to expand...

I have some horror stories using DeviceNet back in the 90's.

Good Year plant, Union City.
All on Device Net.
Whole Line shut down.
I just so happened to be flying there for a new install.
plc: 5/40E
apparently, the beacon lights vibrated their second node switch off.
And after a power outage, a lot of them came up saying they were node 0 to the Device Net Scanner. The day that beacon lights took down the plant.

Peter Nachtwey said:

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.

Click to expand...

I think this is all good information in regards to the deterministic network portion of the OP's question/post. Obviously, from a customer's perspective, I'd much rather pass data over network, in my case EtherCAT, rather than have to use analog I/O. It saves me money, I/O, and wiring. The propagation time of both the A/O at the PLC and the A/I at the drive slow things down too, depending on the performance of your I/O. So then there goes your determinism and speed.

Peter Nachtwey said:

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.

Click to expand...

My knowledge of the protocol doesn't go that deep, other than I know its lightning fast, very robust, and can be set up using any network topology. All the things I care about first and foremost, and probably in that order. We have some Rexroth drives that are on EtherCAT, and of course there's no issue. But as stated, the shortcomings aren't immediately apparent to me. The drives are communicating over EtherCAT and they all work, that's all I know.

Here's a tidbit... We were in touch with a company last year that is a vendor of product testing stuff, super high speed data acquisition, software, etc. I don't recall the name of the company, but I can find out. They're out of Germany. At the time, we were looking for another portable, In-vehicle solution for gathering high speed data with the vehicle on the road. The company in question has these small, very robust modules that one can place in different locations throughout the car (engine compartment, under the car, wheel well, etc). Then you connect whatever sensors you require to these modules. This allows you to place the module/s and the sensor/s as close to each other as possible, without sensor wires strung all over the car and then back into the cab to the acquisition hardware. Well, it just happened to be that all these modules were interconnected via EtherCAT. I thought that was interesting and different. I asked about that and they told me that they are about 98% certain that all vehicles will eventually be on EtherCAT in lieu of the current CAN bus standard, which has been the standard for decades. I don't know much about straight CAN (not CANopen) other than its infrastructure and how it works has a strong similarity to DeviceNET.

busarider29 said:

I think this is all good information in regards to the deterministic network portion of the OP's question/post. Obviously, from a customer's perspective, I'd much rather pass data over network, in my case EtherCAT, rather than have to use analog I/O. It saves me money, I/O, and wiring.

Click to expand...

That is why we make motion controllers that fit in a J-box at the machine.

The propagation time of both the A/O at the PLC and the A/I at the drive slow things down too, depending on the performance of your I/O. So then there goes your determinism and speed.

Click to expand...

Do you think the sampling time disappears just because it is on EtherCat, No! BTW, you are thinking in PLC terms and speeds. We continuously sample the analog inputs every few microseconds then apply a low pass filter. This effectively adds two bits of resolution to our 18 bit AtoD. When the time to read the inputs occurs all channels are read at the same time over a high speed serial line like PCIe. There is little or no phase delay that one associates with PLCs or deterministic networks. Our I/O is done using a FPGA so there are no "house keeping" times where interrupts are off as in a PLC. The FPGA is very deterministic. A FPGA is like an extremely fast PLC that can execute all its rungs in parallel. This is why I am not enthusiastic about using deterministic networks for inputs. There may be time stamps that say when the data was valid but if I have to compare positions from inputs that are taken 100 microseconds apart then there will still be at least a 100 microsecond delay deciding what to do if the two positions must be synchronized.

We have some Rexroth drives that are on EtherCAT, and of course there's no issue.

Click to expand...

If you are simply controlling conveyors or feed chains then no problem.

Well, it just happened to be that all these modules were interconnected via EtherCAT. I thought that was interesting and different. I asked about that and they told me that they are about 98% certain that all vehicles will eventually be on EtherCAT in lieu of the current CAN bus standard, which has been the standard for decades. I don't know much about straight CAN (not CANopen) other than its infrastructure and how it works has a strong similarity to DeviceNET.

Click to expand...

It wouldn't surprise me. The CAN bus is ssssllloooowwww. A CAN bus packet can be about 128bits long and the rate is 1Mb/s so that is at best 8 packets per millisecond assuming there are no collisions.

Thank all of you for your input!! I've had a busy couple of days, so all I've been able to do is read what all of you wrote. As it stands right now, I'm going with:

Allen Bradley, 1769-L18ER
-No I/O is being used by the current PLC, and I suspect I'll do the same... or limited I/O
-#1 reason for AB... I get to buy my own copy of Logix5000 (and use it for this, and other jobs)
(FYI, I've used other brands on other projects)

Allen Bradley HMI, (Model not selected yet) 14" Siemens currently being used.
-#1 reason for AB... Again, the software I get to add to the quote! And AB will work just fine for this project.
(Otherwise, I like Red Lion)

Network: At this point, I don't know why I wouldn't use Ethernet I/P. I was questioning the lack of determinism, but it's a small network (4 addresses), and unless ABB tells me differently, the speed and bandwidth should outweigh any determinism concerns. (Right?)

I'm waiting to hear back from the ABB support engineers. I asked them if I could accomplish the same application with the new ACS880s. The new firmware uses different "groups" for the application parameters, and I don't want to guess and be wrong. They asked for each drive's parameter list, which I had in PDF form from the original installation in 2009.

The current ACS800s use fiber optic connections to talk to each other. I still don't know the extent of information being exchanged, or how to set it up. I suspect ABB will have some instructions for me.

BTW, thanks to your links I stumbled upon this little ABB nugget to help set everything up in Logix5000 : https://search-ext.abb.com/library/...n&DocumentPartId=LVD-PNTG07U-EN&Action=Launch

I'll also throw in new motors and encoders into the quote. One of the drives has had intermittent encorder error faults for a long time.

Originally posted by busarider29:

I'm still a firm believer that EtherCAT is the best industrial communications protocol on the planet.

Click to expand...

And that may be. And all things being equal I would say use the hottest thing you can get your hands on. But all things aren't equal, this being the real world and all.

I liken the Ethernet/IP to EtherCat discussion to comparing the mid-70's Cadillac Deville to a Lamborghini Aventador. The Caddy is big with poor acceleration and is really mushy in the corners. But, boy is it comfy to ride in, anyone can drive it and you can get it fixed at 10 different shops in any city you live in. The Lambo is screaming fast, corners like its on rails and will give you neck problems from the acceleration. But the cost of that is...well, cost, no climate control, no radio, hard uncomfortable seats and no available service for a 500 mile radius.

Sometimes the challenges are warranted due to the performance requirements. But if matching my performance requirements to the available technology allows me easier implementation with a larger available pool of resources with the "lesser" technology, I'll go with the lesser technology.

Keith

kamenges said:

And that may be. And all things being equal I would say use the hottest thing you can get your hands on. But all things aren't equal, this being the real world and all.

I liken the Ethernet/IP to EtherCat discussion to comparing the mid-70's Cadillac Deville to a Lamborghini Aventador. The Caddy is big with poor acceleration and is really mushy in the corners. But, boy is it comfy to ride in, anyone can drive it and you can get it fixed at 10 different shops in any city you live in. The Lambo is screaming fast, corners like its on rails and will give you neck problems from the acceleration. But the cost of that is...well, cost, no climate control, no radio, hard uncomfortable seats and no available service for a 500 mile radius.

Sometimes the challenges are warranted due to the performance requirements. But if matching my performance requirements to the available technology allows me easier implementation with a larger available pool of resources with the "lesser" technology, I'll go with the lesser technology.

Keith

Click to expand...

BTW... First and foremost, I'm a tech. This tidbit is important to me, and a primary reason I got asked to quote this project. The customer has had some issues with the current machine, and he knows I'll re-design this for ease in troubleshooting. If I get hit by a bus, the Allen Bradley solution, while expensive, is easy to pass on to another tech.

I had some classroom time with the Beckhoff products at the end of my "Industrial Automation, Controls and Networking" program. One of my 13 classmates went to work with them (SHE was/is a phone tech-desk person). I wouldn't mind a Beckhoff project, but this probably isn't it.

Thanks for the info, though. I really needed to hear all of this!

kamenges said:

I liken the Ethernet/IP to EtherCat discussion to comparing the mid-70's Cadillac Deville to a Lamborghini Aventador. The Caddy is big with poor acceleration and is really mushy in the corners. But, boy is it comfy to ride in, anyone can drive it and you can get it fixed at 10 different shops in any city you live in. The Lambo is screaming fast, corners like its on rails and will give you neck problems from the acceleration. But the cost of that is...well, cost, no climate control, no radio, hard uncomfortable seats and no available service for a 500 mile radius.

Click to expand...

I'm not sure I understand the "slowness" and "oldness" of Ethernet... Cisco switches I think are 10Gb rated... AB just got off of 100Mb but primarily AB is the problem with speed not Ethernet.

EtherCat doesn't work with Ethernet... making it seem to be just a new DevNet that I wish was never installed and the person that wanted/installed it is long gone and I get to fix the problems.

Ethernet will always win me over, it has huge teams working behind it and always creating better and better tools. EtherCat, who is making it better? Not huge IT teams. (But that might just because I really like Ethernet.)

VAN said:

I'm not sure I understand the "slowness" and "oldness" of Ethernet... Cisco switches I think are 10Gb rated... AB just got off of 100Mb but primarily AB is the problem with speed not Ethernet.

EtherCat doesn't work with Ethernet... making it seem to be just a new DevNet that I wish was never installed and the person that wanted/installed it is long gone and I get to fix the problems.

Ethernet will always win me over, it has huge teams working behind it and always creating better and better tools. EtherCat, who is making it better? Not huge IT teams. (But that might just because I really like Ethernet.)

Click to expand...

I love the analogy. Funny as all get out, to me. (whoops that part was to the lambo poster)
I hated devicenet too

EtherCat is not a "new" devicenet.
EtherCat run at 100 Mbps vs 500K
EtherCat avoids switches and collisions.
Devicenet has collisions, nothing is deterministic.
Our new controller has 2 Ethernet ports so that EtherCat cables can daisy chain through our controller. There is no need for a switch.

I think EtherCat is pretty good. I just isn't as good has doing everything synchronously and deterministically on the back plane.

Peter Nachtwey said:

EtherCat is not a "new" devicenet.
EtherCat run at 100 Mbps vs 500K
EtherCat avoids switches and collisions.
Devicenet has collisions, nothing is deterministic.
Our new controller has 2 Ethernet ports so that EtherCat cables can daisy chain through our controller. There is no need for a switch.

I think EtherCat is pretty good. I just isn't as good has doing everything synchronously and deterministically on the back plane.

Click to expand...

Peter my "new" devicenet comment was just pointing out that it isn't a commonly used device and requires extra to connect to it with a laptop.

https://infosys.beckhoff.com/english.php?content=../content/1033/tcsystemmanager/fieldbus/rtethernet/tci8255xinstal.htm&id=

I'm just not a big fan of doing stuff different for the sake of being different.