Beckhoff vs. Allen Bradley... who is better?

That's not a 5585. These "retail" for over $20K. But hey, you can get a used one for about $11K. :p Can you do better than that? What's your price for new, not used?

The 5585 was not quoted

Both the new 5380 CompactLogix and 5580 ControlLogix series processors from Rockwell have quad-core processors.

But yes I sell the (New) 1756-L85e for just over 3,000 but I dont have any in stock :p
 
What I find really strange about a few projects I have/am quoting to a specialty machine builder customer... We have two specific testing machines that have no specification on controls components from the end user. They basically said we have to use Keyence Lasers on one machine, and a few features they would like. The company they are building these for is based out of Germany, and they have a couple factories in Michigan. Basically, we use what we want. Pretty straight forward.


Another machine in the works was designed in Germany and it's all Beckhoff/Rexroth for controls. These machines go in the same factory, basically side by side. I don't get it. I would rather make them all the same.
 
Last edited:
Yea it was just a joke... but you do get very good pricing


We also have an account manager at Rockwell that works with our rep. I can usually submit a BOM to them and they usually give us even better pricing. Seems to average another 7% on most items, but the biggest discounts are on VFD's.
 
Both Siemens and AB for anything really fast, they try to push their special "motion" CPUs, which to me is arcaic. CPUs ought to be so powerful these days, that there shouldnt be a need for special CPU hardware - except for that you choose the performance for your need.
Instead there should be software libraries to facilitate special needs such as motion. That is exactly what Beckhoff does. So I think Beckhoff has a better concept than the two big automation players.

Both Siemens and AB are not really that interested in the bleeding edge of data sampling. Instead, where Siemens and possibly also AB really want to grab market share is in the largest of plants and installations, that is where you would be using DCS rather than PLCs. Here you need other features, redundancy at every level, configuration-in-run, hot swapping, software tools to manipulate thousands of I/O, software libraries tailored to specialised industries. Also, for really huge installations, the decision makers wants "big" suppliers with plenty of oompf.
Beckhoff is not really able to participate with the big players here.
Siemens are about to launch redundant CPUs on the S7-1500 platform, so that shows where their priorities are.

The software and hardware requirements for huge process installations are so different to what Beckhoff does, that I dont think Siemens/AB and Beckhoff will ever become direct competitors.

All very good points that I can mostly agree with. Maybe that's why Beckhoff decided to reach out into the high-speed measurement realm since there currently wasn't anything out there that could be both a PLC (programmed with Ladder) and provide lab-level high speed measurement all in one platform. There was definitely a market for something like that, as we were certainly happy to see it. We had 5 of the ELM measurement modules on order before they were even available for sale. Just two years ago, I was in Chicago at a National Instruments "NI Days" conference and I recall asking around some of the different vendor booths there if they could help us as this is what we were really looking for (PLC with high speed measurement and data acquisition capabilities). I got the same answer from a lot of them and that was basically - "Hey, welcome to the club because there are a lot of companies looking for that too, but there's nothing out there". Then they would give me their card and try to push their $200K system on me that could do it, although it wasn't a PLC and it wasn't programmed in IEC61131 languages, and it was all closed proprietary type stuff.

With Beckhoff's PC based controllers, I can't help but to think that a redundant CPU type controller is somewhere in their future.
 
I don't know what to say after re-re-re-re-reading this thread. My thoughts:
#1 - Ladder Logic Hate is just plain stupid.
#1A - Ladder Logic reads to the eye easier then STL
#1B - 'Bubba' (if he's allowed access to PLC code can understand it
#1C - It is well suited for 92% of decision making cases.


#2 - 'Bubba' must understand the PLC Code
#2A - No, he doesn't. HMI's are cheap. Put up a message detailing the problem, point him to where to look to fix it.
#2B - 'Bubba' should NOT have access to PLC code online. This is both a security and safety issue.
#2C - In the case of a problem, 'Bubba' should understand that the PLC program hasn't changed. If something stopped working, it is a REAL WORLD DEVICE that failed, and needs to be fixed. (This applies to operators, supervisors, and management as well).


#3 - My PLC is better then Your plc
#3A - BS. I use PLC's from Rockwell, that perform well. At the same time, I use PLC's from Automation Direct that perform just as well, but the entire rack cost's less then a single AB Processor.
#3B - Many things I have run perfectly fine on SLC-500's, and PLC-5's. And ControlLogix. And Automation Direct. You size your PLC for the requirements of the application.
#3C - Running a primary (cyclic) task in 40 mSec vs. 0.02 mSec makes absolutely zero difference if your IO updates at 50-100mSec.
#3D - "My PLC Does Motion!" It may, but if you really need Motion Control, you need a real Motion Controller (Use Pete Nactway's, they are FREAKING AWESOME). And seriously, today, in 2018, many of what "Used To Be" Motion tasks aren't. Simple followers don't need motion control, as drives now-a-days can be relied on to take a speed (or torque) reference and hold it. Speed Matching the 12 bit analog reference to a nominal 100v/k tachometer days are over.
#3E - If you are building a new plant, pick ANY modern generation PLC, and run with it.
#3F - No matter HOW good your PLC is, for specialized applications, you might still need to turn to specialized systems, like National Instruments for serious, high-speed data acquisition and control.
#3G - You Should Choose (based on needs) to have Common, Non-Proprietary communications capabilities.


#4 - Depends on What You Do...
#4A - A 'Systems Integrator' should be able to handle anything a customer wants. You might point out advantages and disadvantages of various platforms, but if your customer wants a PLC-2, deal with it.
#4B - A 'Machine Manufacturer' needs to follow #4A, unless there are singular capabilities of the platform they insist on... in which case, look for another machine manufacturer.
#4C - An 'End User' (will be using the equipment in the plant) should freely be able to decide what platform to base said equipment on. If the SI or MM can't manage that, shop around.


phew.
I have more rules/suggestions, but I'm tired.
 
As much as I would like to be able to say AB is conceding the machine control market to platforms much better suited to machine control, that isn't the case. At PackExpo, easily half the equipment had PanelView Plus, AB motors, and presumably an AB PLC. AB will continue to be a major presence in machine control even though we are already past the point where their competitors are objectively better in every way. Much like imperial measurement, US industry is very slow to take on inevitable change.

Tellingly, the Pharma side of PackExpo was mostly B&R with a smattering of Beckhoff and PacDrive. AB was virtually unused on the Pharma side because it can't meet the integration needs of the industry. Also, when you look at weighing and inspection equipment, it's either custom or B&R because IO requirements.

busarider29, B&R offers oversampling analog input modules that can do 25kHz (40us conversion time). They may have specialty IO modules that can do faster analog conversion.
 
With the risk of getting off-topic on some of this, I'll comment. This should be the last of it though as I think I've pushed it to the absolute limits.

#1 - Ladder Logic Hate is just plain stupid.
#1A - Ladder Logic reads to the eye easier then STL
#1B - 'Bubba' (if he's allowed access to PLC code can understand it
#1C - It is well suited for 92% of decision making cases.
#1A: Very generalizing but for those here in the US, most would agree. However, try and push that theory to those on the other side of the pond and you'll most likely get laughed at all the way out the door. I once had a colleague that could read and write ST and VB like it was nobody's business, but for the sake of his own life, could not grasp LD. I forced myself to code in ST just for the sake of learning it, plus having a CS background, it is more natural for me since its much like C and VB. Still, I can code in LD just the same. I recommend that anyone, when given the opportunity, code in either LD or ST, whichever one you're not as polished with, that way you can learn something new and/or get better with that language.
#1B: Not always. See 1A above. With that said, if one is persistent enough and practices, can pick it up and understand it.
#1C: Agreed. 🍺


#2 - 'Bubba' must understand the PLC Code
#2A - No, he doesn't. HMI's are cheap. Put up a message detailing the problem, point him to where to look to fix it.
#2B - 'Bubba' should NOT have access to PLC code online. This is both a security and safety issue.
#2C - In the case of a problem, 'Bubba' should understand that the PLC program hasn't changed. If something stopped working, it is a REAL WORLD DEVICE that failed, and needs to be fixed. (This applies to operators, supervisors, and management as well).
#2A: Well, if its anything AB PanelView, then no, its not cheap. If its a simple PC monitor, then yes, its cheap. But yes, I agree on messaging detail. What will always get my blood boiling is when a machine/line is down and all the HMI says is something like "Machine Fault" or worse yet, nothing at all and just a flashing red beacon light. :mad:
#2B: I can agree with this for sure. Too many fingers in the code and access to it running can lead to bad things, especially when you have no good reliable way of documenting who made the online change and when. I worked at a facility in TN where it was expected for skilled trades (electricians) to go online with the running PLC. They were pretty good and I rarely got called to a line. If I did get called, it was usually something with a robot, not the PLC. But there were times where I saw an Electrician online with a PLC and I thought to myself, "Okay, what the $@#$#@ is he doing?"
#2C: Agreed. 🍺 But how many places actually practice this? Everywhere I've been, anytime the machine/line goes down and the cause isn't immediately obvious, everyone outside the controls engineer says, "Oh, it must be a bug in the PLC program":confused:

#3 - My PLC is better then Your plc
#3A - BS. I use PLC's from Rockwell, that perform well. At the same time, I use PLC's from Automation Direct that perform just as well, but the entire rack cost's less then a single AB Processor.
#3B - Many things I have run perfectly fine on SLC-500's, and PLC-5's. And ControlLogix. And Automation Direct. You size your PLC for the requirements of the application.
#3C - Running a primary (cyclic) task in 40 mSec vs. 0.02 mSec makes absolutely zero difference if your IO updates at 50-100mSec.
#3D - "My PLC Does Motion!" It may, but if you really need Motion Control, you need a real Motion Controller (Use Pete Nactway's, they are FREAKING AWESOME). And seriously, today, in 2018, many of what "Used To Be" Motion tasks aren't. Simple followers don't need motion control, as drives now-a-days can be relied on to take a speed (or torque) reference and hold it. Speed Matching the 12 bit analog reference to a nominal 100v/k tachometer days are over.
#3E - If you are building a new plant, pick ANY modern generation PLC, and run with it.
#3F - No matter HOW good your PLC is, for specialized applications, you might still need to turn to specialized systems, like National Instruments for serious, high-speed data acquisition and control.
#3G - You Should Choose (based on needs) to have Common, Non-Proprietary communications capabilities.
#3A and #3B: You're implying a PLC is a PLC and any will do. I just don't buy into that at all, sorry. I've done the performance and capability study comparisons (AB vs Beckhoff), comparing both "high Performance" classes from both vendors. It's been well stated in this thread and one other, so no need to rehash it all in this post. But in short, my conclusions are that if you have any sort of high speed operation, such as possibly this Coca-Cola factory (?), it is far better suited for a super high performance PLC platform that puts a strong emphasis on speed at all levels (Processor, I/O, communications bus, program, etc). This is where Beckhoff leads the pack, by a very large margin in my opinion. If you're just doing moderate pick-and-place, some conveyors, light curtains, etc, then yeah, any PLC will do. But if that's all you're doing, then why spend the outrageous cost on AB? Just go with something from AutomationDirect. Or spend a bit more on a low end Beckhoff PLC and you'll still get the benefits of their fast I/O and EtherCAT?
#3C: Agreed, and again, this is why you go with Beckhoff, because they have very fast sampling rates for their analog I/O and some screaming fast discrete I/O (XFC I/O). You're only as fast as you're slowest component, so don't leave out the fast I/O when spec'ing a machine. Of course you'll need a fast comms bus too - EtherCAT (Beckhoff).
#3D: Eh...I'm not as fluent with Beckhoff's motion library as I wish I were, but we are using strictly their motion library (does come at an extra cost) for motion control on one of our machines. It works just fine and pretty extensive so my guess is that its a fully capable motion controller within TwinCAT. No need to buy dedicated motion control hardware. With that said, yes, I agree that Delta Motion controllers are a fabulous piece of hardware, easy to program, and screaming fast. I integrated an RMC150 motion controller about 4 years ago in one of our machines for servo valve control and it works great. There's only one drawback to their motion controllers though that I see: they currently have no support for EtherCAT. I wanted to move register data from the motion controller directly over EtherCAT into the TwinCAT PLC. Couldn't do it that way, which was a real bummer. Anyway, I digress
#3E: See 3A, 3B, and 3C.
#3F: Well, if you're rolling with a "traditional" PLC (AB) and doing specialized applications, then chances are you will have to turn to specialized systems like NI, like we did. If going with Beckhoff, a PC based PLC controls platform, then your chances of having to turn to something else because it can't do it decreases dramatically. We still use NI hardware and Labview, but its not married to our machines anymore. We now just use NI stuff for lab bench, one-off type testing that doesn't need to be integrated into the machine.

Well, that was long and I'm tired and really do need a 🍺 I think I've stated my case enough and hopefully didn't **** off the moderators too much with carrying on this thread. Cheers.🍻
 
Last edited:
I don't know what to say after re-re-re-re-reading this thread. My thoughts:
#1 - Ladder Logic Hate is just plain stupid.
#1A - Ladder Logic reads to the eye easier then STL
#1B - 'Bubba' (if he's allowed access to PLC code can understand it
#1C - It is well suited for 92% of decision making cases.

Your 1C comment contradicts 1 and 1A comments.

Ladder logic isn't suited for calculations... some brands overcome this better than others, but generally it isn't. So hating rungs upon rungs of calculations is well justified. However, it isn't a problem with the language itself, just with the user that wrote it (or the brand that charges extra to use a better suited language).

Likewise, FBD can be a lot easier on the eye than ladder logic if done right as you can see the entire logic flow right there. No need to cross reference across functions and what not.

Each language has an area where it is great. Ladder is still great in some areas and that's why it won't be dropped anytime soon.
 
Ladder logic isn't suited for calculations...

A great majority of automated equipment does not require any calculations or require very little of them. On the other hand, even the greater majority of automated equipment require something like start-up permissives or a similar linear logic.

A long chain of conditions that allow a machine to start is much easier to troubleshoot when looking at ladder code online - it is as simple as an electrical circuit and one can quickly spot a "break" in it. And yes, the fact that the machine owner does not need to hire a highly-paid engineer but can rely on a worker to find and fix a problem, greatly reduces the cost of ownership.

The point is, as always - each has its proper place; none is better than other.
 
A great majority of automated equipment does not require any calculations or require very little of them. On the other hand, even the greater majority of automated equipment require something like start-up permissives or a similar linear logic.

A long chain of conditions that allow a machine to start is much easier to troubleshoot when looking at ladder code online - it is as simple as an electrical circuit and one can quickly spot a "break" in it. And yes, the fact that the machine owner does not need to hire a highly-paid engineer but can rely on a worker to find and fix a problem, greatly reduces the cost of ownership.

The point is, as always - each has its proper place; none is better than other.

I don't dispute this. In my experience there are always calculations and even small bits of calculations look funky in Ladder. Of course, this can also be overcome with proper use of functions where the non-ladder bits of logic are hidden away from Bubba and all he has to care about is the ladder permissive rung.
 
I wonder what this debate will look like in 25 years. Maybe then we will all be out of a job and spend time talking to our assigned AI head-shrink.
 
All I know is we had one line with a AB PLC never really had problems with it unlike the Mitsubishi we have we have went threw thousands of dollars replacing them from them going out over the 12 years we been in this building. This year I had to replaced 4 Mitsubishi's.


It is kinda sad we don't have that AB here any more.


So between AB and Mitsubishi I pick AB
 
Last edited:
I don't know if this totally applies here but...

fordchevy_1.jpg
 

Similar Topics

Hi guys, I'm looking to design and program a robot pick and place cell. I'm in between using a Beckhoff or Allen Bradley. I like the Beckhoff...
Replies
2
Views
832
Hi, I would like to know what are the basic things we should consider before start migrate from the AB PLC to Beckhoff Controller? Is ther any...
Replies
1
Views
2,002
Hi everyone, This is my first time posting, so please forgive any omissions or mistakes. I am attempting to control the velocity of a stepper...
Replies
18
Views
751
Hello sameone have Beckhoff PLC Siemens Sinamics V90 configuration example?
Replies
0
Views
83
hello, I am using Beckhoff with TwinCAT3 and when I change or add some new hardware or for any reason, there is a mismatch in the real hardware vs...
Replies
1
Views
111
Back
Top Bottom