While I am a big Rockwell user I am also a Codesys fan. As you said, the ST development environment is pretty well thought out. And the Beckhoff stuff is fast at a very reasonable price. There are definitely some things you can do with a Beckhoff system that would be difficult to impossible to do with CLX. But this does come back to product differentiation. The things that tend to make Rockwell Rockwell are kind of part and parcel to the control structure they now have. Something like true online editing requires some compromises. If you want to keep that there is a price to be paid.
Resurrecting this thread!
"Fast" machine to me is a combination of everything, not just scan times. Like a "fast" PC, its only as fast as its slowest component. With that said..
Here's a little story....
About 4 years ago, we came to a crossroads in our R&D and testing department with relation to our controls platforms and what we would standardize to. Up until then, we used strictly AB PLCs, both in our testing machines and production lines. Most likely reason for that was because like many places, that's what we knew and that's what we liked , and naturally
we like what we know, and we don't like what we don't know. That's just human nature. Well, the problem that we were having with the AB PLC, or what I consider a "traditional" PLC, was with a number of things, but mainly the analog I/O sampling rates. They just weren't fast enough. Not even close. We needed a bare minimum of 8 kHz sampling with analog inputs, but preferably 10 kHz. The best that AB could do was around 5.5 kHz, and that was with their mother-ship platform, ControlLogix. So obviously what we had to do to get around this was integrate 3rd party hardware and software - National Instruments with LabView, which we did and I had the "privilege" of learning. Now, you think your Maintenance personnel (or possibly you) have a hard time with anything other than RSLogix(??), show them a Labview program and have them try and troubleshoot that!! So, to
hopefully get around this cobbled up way of doing it, we started looking at other PLC vendors, and hopefully one of them had something that could meet our needs and do everything in one machine - Machine control, "high speed" measurement and high speed data acquisition. Fat chance I thought, but we had to look. Enter Beckhoff, which I do
not consider a "traditional" PLC. At the time (4 years ago), their fastest analog I/O (XFC series I/O) could sample at 10 kHz. Perfect. Now, by
sheer chance, just last year they introduced their Measurement Series modules which can sample at
50 kHz! Measure from two of those modules and stagger their sample times and you've got 100 kHz sampling!! Again perfect, since now the customer is asking us to gather audio and accelerometer data @ >= 30kHz sampling. Go ask a Rockwell sales guy if their platform can do anything close to this. As far as I know, they still can't meet a meager 6 kHz with their analog I/O sampling rates, unless that's changed in the last 4-5 years. So if you require high rate of analog sampling or anything high speed data acquisition, you're not getting it with a "traditional" PLC, which includes AB. The only platforms that can do-all as described, that I know of, are National Instruments (hope you like LabView!) and now Beckhoff. By the way, I was at the Instrument and Measurement symposium in Detroit last year while Beckhoff was showing off these new Measurement modules. A couple National Instruments sales guys stop at the Beckhoff booth, obviously to check out their new competition. The jist of this is that if you require a one-all-does-all platform that is a "PLC" per say, then its Beckhoff.
Here's another little story....
On our production side of the house, they still use and swear by AB. Again, IMO, same reason as stated before -
that's what they like because that's what they know. Well, we just had a brand new line put in over there that uses the ControlLogix platform. One of our Sr. guys was debugging and tells me there's a timing issue here and there on the line, with the root cause likely being scan time of the PLC program. Someone might say, "Well, that's the programmer's fault, not the platform". Maybe so and maybe that's why he was in there editing the code to make it more efficient? But consider this - what if one had a 8 or 12 core, 2 GHz processor where he/she could allocate each one of those CPU cores to a specific task in the PLC configuration? Well, you can do just that with the Beckhoff platform and TwinCAT. Now also put the entire I/O bus on fast EtherCAT. Bye-bye scan time and timing issues. But that's neither here nor there since they aren't using Beckhoff.
Last little story...
Way back 4 years ago, prior to me knowing anything Beckhoff or EtherCAT, I did some research of my own on the most common industrial communication protocols. We had several machines that had at least 2-3 different communications protocols going on in them. To make things simple, I wanted to put everything on one bus using one communication protocol (all devices talking the same language). But at the same time, I wanted speed. I started looking at EtherCAT. I called up EtherCAT.org and got them on the phone and asked (what I consider now to be not a very smart question) if it was possible to put an AB platform PLC on EtherCAT. He says to me, there's over 2000 vendors out there that make everything from sensors, to drives, to PLCs and everything in between. They
ALL have some sort of support for EtherCAT......except one of them. Then he asks me, now guess which vendor that one is? I say...."Ummm....AB??" You got it, he replies. The jist of this story is that if you want the fastest communication bus on your line/machine, you're not getting it with the AB platform. I posed a question regarding EtherCAT to a Rockwell sales guy asking him why doesn't AB have support for EtherCAT? His reply was that they don't see a real need for real-time communications. Seriously, that was his answer.
