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

This:

Originally posted by Archie:

When I did my first Beckhoff TwinCAT project, I dove in head first to a big project. My mistake was going into it with an AB programming mentality.

ties in intimately with this:

Originally posted by Archie:

After 15+ years working with Beckhoff and 20+ years with AB...

15 years ago Rockwell had nothing that even resembled Codesys in terms of upper level formatting. Then along came AOIs in the CLX family. I absolutely admit that Rockwell's AOI functionality is nowhere near as clean as a Codesys function/function block implementation (not even considering the distinction between a function and a function block). However, had you come at your first Beckhoff project with 5 years of today's CLX experience under your belt as opposed to 5 years of PLC5/SLC or even early CLX experience under your belt I strongly suspect you would have done things much differently.

Rockwell is behind and playing catch-up and so are Rockwell programmers. But considering all the "I HATE that tag-based ****!!" posts we get on this forum, can you blame Rockwell for not living on the bleeding edge? Perception is reality.

Keith
 
How does the Beckhoff processors handle online editing? Excuse my curiosity as I have no experience in the Codesys world.

Well, a bit better than RSLogix 500, I would say. When online, you hit F12 (confusingly called "Logoff"), type in the changes, then hit F11 (called "Logon", just as confusingly). The software is smart enough to update only what has changed, very fast.

Compare this to AB's "Edit" - "Assemble" - "Test" - "Accept" sequence or Omron's CX-Programmer online editing procedure - not bad. Of course my favorite Yaskawa Motionworks allows me to start typing in the changes directly und update upon hitting F8 "Compile" key... but not everyone is so customer-concious yet :)
 
Originally posted by LadderLogic:

When online, you hit F12 (confusingly called "Logoff"), type in the changes, then hit F11 (called "Logon", just as confusingly). The software is smart enough to update only what has changed, very fast.

Well...kinda.

In my somewhat limited experience Codesys is much more sensitive to structural changes than the AB stuff is. At the end of the day, there is no such thing as online editing with Codesys. You are editing an offline copy and if the development environment can insert your changes into a running system then, by Gumby, you have an online change. But there are things you can do online with an AB processor that, if attempted in Codesys, will require a processor stop to load. At that point it isn't online so much.

Keith
 
Rockwell is behind and playing catch-up and so are Rockwell programmers. But considering all the "I HATE that tag-based ****!!" posts we get on this forum, can you blame Rockwell for not living on the bleeding edge? Perception is reality.

Would you mind expanding?

I’m pretty green to Codesys, but did spend most of last year getting familiar with it (v3) and came away impressed. Knowing it was a limited experience I did try to re-create the complexities I have needed on a Logix system into Codesys. UDTs, Function Blocks, sequence engine, modularity and even re-created the functionality of Rockwell’s “Phase Manager”. All-in-all, I find it a strong 2nd to Rockwell but I wouldn't use it on large process systems, much to do with the online editing you just mentioned. I crashed the controller quite a bit.

+1 on having a simple FUNCTION, I was able to refactor some complex logic by having this option.

I’m curious about the AOI/FB comparison, I currently view them as one and the same. I didn’t see anything that really differentiated the two. Granted I use these features primarily for device control however I’ve done plenty of specialty math AOIs as well. Perhaps I’m just not exposed to some additional benefit.

Same with user-defined datatypes. I was able to create the same complex tag schemes in both platforms, including nesting. So one and the same.

Codesys make ST logic a pleasure, and part of my exercise was to become more familiar with ST so mission accomplished. I pretty much wrote the bulk of code in ST. The Ladder editor isn’t great, not the worst I’ve used but advantage AB.

Rockwell may not follow the 61131-3 instruction set but I’d give AB the advantage here specific to data type conversation and documentation. Codesys, like many other platforms require more logic and consideration for handling varying data types. The ability to add additional libraries to Codesys (like OSCAT) is nice but I found documentation to be a bit lacking. AB has code references as well, just not bundled that I'm aware (plant PAX maybe?). I’m sure there are plenty of advantages for Codesys here, I just don’t have the exposure.

I use alias tags a lot in Logix and implementing similar in Codesys takes some extra effort. Possible, just more code to write.

I noticed data retention is big difference. Logix, if you have setpoints in memory and you loss power, well it keeps the data. Codesys, gone. I understand there are ways to define retentive memory in Codesys however it’s a limited amount and easy to max out from what I found. My experience working on large process systems means thousands of setpoints that can be adjusted via the HMI/SCADA, which could get completely wiped to 0, bad times for all. So additional measures are required to accommodate, I’m not what those measures are. Thought I read about writing values text file for storage.

Codesys is a bit of a challenge because the vendors who use it put their spin on it. So it’s “similar” yet different. And if you’re programming a variety of controllers which use Codesys, you can’t necessarily have a single installation of Codesys on your computer. I do realize some vendors give you the option to run “bare-bones” Codesys, the custom nature of it all makes it a bit more convoluted then what marketing presents.

Overall, I didn't feel I noticed anything substantial to say that one is far ahead of the other. I will say it's nice to have sim mode on Codesys and it was neat to mess with the WebVisu feature. I'd say machine control it looks to be a great option (didn't dig into motion), but for process control I'd have to see some real-world solutions to get a warm fuzzy about it.
 
Last edited:
I largely agree with your assessment, Paully's5.0. My comment about AB and catch-up is based largely on history and timeframe. Codesys has been Codesys for a long time. The cool tools we all like so much in the CLX platform are a relatively new occurrence. And they are a significant departure from the previous AB platforms. With the history and install base Rockwell has with plcs it was a bit of a leap going from PLC5 to CLX. They tried to maintain as much look and feel as they could so they didn't shock the customer base to death but in the end they needed to change stuff to get where they wanted to go. And they have been slowly changing ever since, on their way to where they want to go (wherever that might be) without leaving their existing customer base in the dust.
Contrast this with Codesys, which has been what it is since its inception. Don't get me wrong. There have been significant changes and enhancements to Codesys through its life. But the basic software design philosophy hasn't changes since I looked at my first Beckhoff control program in 2002.

My comments about AOIs as opposed to FBs and functions is that Rockwell doesn't have an equivalent to a function. It would be nice to be able to implement a true function that could be used inline with other logic. I don't have any experience with Codesys ladder so it is hard for me to comment on this. But in a Rockwell AOI you can't tie an output directly to what would be a boolean output, for example. From a ladder perspective this would be useful.

Automatic data type conversion is something most Rockwell user really like, to the point that they have a hard time getting used to not having it in other platforms. But that nice little feature is expensive in terms of processing time as it allows users to get lazy. I think making type conversion explicit makes for better programming simply because people are lazy and will avoid type conversion if they can.

I don't mind the various front ends applied to Codesys by various vendors. That allows for more product differentiation, which also spurs development environment advancement. It really isn't much different than the Electrical add-on for AutoCAD. The difference is you can't get away from the format imposed by the various Codesys front ends.

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.

Originally posted by LadderLogic:

...but yes, some major changes would indeed require stopping the CPU and redownloading the whole program.

We apparently hold different opinions on the nature of 'major'. I have unfortunately not used Codesys based systems enough to really nail down what requires a processor stop to load. But I do know that anything but a relatively minor logic restructuring will likely trigger it.

Keith
 
Last edited:
Thanks for the additional perspective kamenges! I do admit I am one of those lazy AB guys used to datatype conversion, but I also experienced the polar opposite when dealing with Mitsubishi last year. I can understand your argument but at the same time if aligning datatypes results in 8-12 variations of an a basic compare instruction, it gets a bit tedious and if you are like me and write scripts to auto-generate some code here and there it really eliminates that option. Mitsubishi makes it worse as the instruction required can change pending the location and use on a rung!
 
I wouldn't term Beckhoff "small" since currently almost 1 Billion USD annual sales worldwide. I started w/ Beckhoff in 2005 because we needed "fast", which to us was <1 msec response from analog in to digital out, and only Beckhoff's EtherCAT could meet that. B&R was 2nd fastest (~2 msec). EtherCAT was new then, but has grown tremendously. My boss preferred A-B, but Contrologix response was >5 msec for even a few analog inputs and we needed at least 32 channels. Fast is relative, and most apps consider 20 msec response sufficient. Process plants are happy w/ 10 sec response. But high-speed has improved products in apps such as plastic extrusion and CNC machining.

I have used Contrologix just a few times. My impression is that it is targeted more at factory electricians using Ladder Logic, which is common in the U.S. I learned Beckhoff's TwinCAT on my own, and several other engineers here picked it up w/ just a few pointers. It seems targeted more to engineers/techs who prefer Structured Text and FBD, which is more common in Europe and the developing world. Anyone with experience in programming, especially embedded code or more scientific apps like National Instruments products can pick it up easier. Since they moved to TwinCAT 3 in Visual Studio, it is much more familiar to anyone who has used Visual Basic or C#. Non-programmers can still use their System Manager to configure I/O and trouble-shoot, without delving into the PLC code.

Re support, Beckhoff has a vast warehouse in MN so I receive most parts in a few days. It is easy to swap the slice I/O, so all users would be wise to keep spare modules (aka "terminals") and most cost <$200. Their tech support is excellent. I have a support engineer 20 miles away, who is an excellent engineer, always responsive and very detailed. My only experience with A-B was talking w/ a support tech at a local conference who seemed to have a more "pile-driver" attitude and make outrageous claims. Plant-wide, we have mostly A-B PLC's and we pay high annual support fees for them. In one case, one hung-up and ruined a $1M part, but that was more the fault of the HMI design.
 
I wouldn't term Beckhoff "small" since currently almost 1 Billion USD annual sales worldwide.

??? where did you get your numbers.... I have not used Beckoff so I will refrain from commenting about there product and I have only heard good things about them but I think your numbers are off

Also when you compare them to others... they are small, Rockwell 6.6B and Siemens would be about 15 times that, that does not mean that they are bad just smaller
 
??? where did you get your numbers.... I have not used Beckoff so I will refrain from commenting about there product and I have only heard good things about them but I think your numbers are off

Also when you compare them to others... they are small, Rockwell 6.6B and Siemens would be about 15 times that, that does not mean that they are bad just smaller

I don't think he meant they are not "smaller", but just they are not "small"...

And I agree..
 
I don't think he meant they are not "smaller", but just they are not "small"...

And I agree..

They are not small no. Maybe around $680M USD, if you believe the 2015 market report from ControlGlobal


But way higher on the list for PLC vendors would be:
Siemens
Schneider
Rockwell
Mitsubishi
Omron


It doesn't mean those PLCs are the best, just that they sold more.
 
Statements like this makes me cringe:

I couldn't agree more..... If you need to get online with your PLC to troubleshoot a sensor...............my goodness.....

Furthermore, if you need to google how to get online with your PLC....put the laptop down and step away from the PLC.....
 
I couldn't agree more..... If you need to get online with your PLC to troubleshoot a sensor...............my goodness.....

Furthermore, if you need to google how to get online with your PLC....put the laptop down and step away from the PLC.....

Oh, I agree completely - but the unfortunate reality is, whether we like it or not, that's the type of worker that are given the task of looking after these machines. I've watched a senior maintenance electrician at a major multinational factory spend 10 minutes trying to work out how to reset a Powerflex VSD fault from the keypad, because it didn't have a button that explicitly said "press here to reset fault". I can argue until I'm blue in the face that if that's his level of expertise, he shouldn't be touching any PLC's, but at the end of the day if I put in a system that he can't get online with and troubleshoot, I won't get any more work at that factory.

It doesn't matter how satisfied I am that my methods/equipment selection/programming language are the "best" if nobody will pay me to implement them.
 

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
833
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
754
Hello sameone have Beckhoff PLC Siemens Sinamics V90 configuration example?
Replies
0
Views
85
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