Attention Europeans: Prevailing PLC Brands

theColonel26

Lifetime Supporting Member
theColonel26
Join Date
Feb 2014
Location
West Michigan
Posts
785
Hi my European friends.





We are wanting to expand our machine offering to Europe. Currently we use Allen Bradley PLCs. o_O Why? because U.S. customer demand them because they have a AB standard in there plant. o_O


What is the culture like in Europe? Specifically the UK and Ireland to start with? Do most plants have a single PLC Brand that is Standard and is that standard Siemens?






I want to go to something Codesys based, but senior management is concerned about plants requiring Siemens. Codesys makes Studio 5000 look like a toy and allows a lot of openness and code sharing between PLC Brands. I assume Siemens is lacking in both to compared to Codesys, would I be right?




To Recap what Studio 5000 doesn't have and what Codseys does

  • Reference Types
  • Functions, only Function Blocks (AOIs)
  • Enums
  • UDTs as Input and Outputs for Function Blocks (Yes InOut works, no is not the same since you have to declare the tag outside of the FB)
  • Arrays as Inputs and Outputs for Function Blocks (including Strings)
  • Inheritance for Function Blocks and UDTs
  • Interfaces for Function Blocks
  • Viewing of a Function Blocks instance's data when it is executed in a loop
  • Multiple Subroutines for function blocks.
  • Partial Downloads (for Function Blocks etc.)
Brands that use Codesys, a custom version of Codesys or can run a Codesys runtime are...


  • Beckoff
  • Schneider
  • Wago
  • IFM
  • Eaton
  • Beijer
  • ABB
  • Phoenix Contact
  • Opto22
  • Festo
  • Parker


P.S. I think I asked about this a couple years ago but I can't find the thread.
 
Last edited:
I'm in the UK and I'd say it's a mixed bag... Siemens and Rockwell co-exist in about 50/50 with spots of Codesys kit here and there and some OMRON and Mitsubishi. There's quite a few process plants using DeltaV.

Some companies have the approach of demanding X PLC brand from the manufacturers, but I find that to be particularly stupid and expensive when one is buying an "off the shelf" machine. Not so much when built to spec and quite wise when it's a process plant.
Some companies then don't quite care so much about the PLC brand since it pays off to have something the supplier makes dozens of in support and upgrades. Some particular machinery may well not even be available with the common brands. I'm remembering the blister packing on a pharma company that was ran off of a Codesys equipment.

The largest cookie manufacturer in the country, for example, has Rockwell in their packing machines and Siemens in their process side.

Edit:
As for sharing, Siemens does allow export of code in IL and SCL. It doesn't in Ladder, but I don't know if there's a standard for Ladder representation in text format that they could adhere... and whether it would be worth doing so.
 
Last edited:
First of all, many British based companies also use AB (many large organisations have their roots in US). The other major players are Siemens, Mitsubishi & Omron. so I think you need to be flexible in your approach and be prepared to use what ever is the particular organisations preferred equipment.
Also remember the power supply requirements, components that are commonly used in Britain etc. I worked for an all British company for 16 years & a lot of equipment came from the States, we faced a number of problems in both the electrical equipment & the mechanical side.
US machines seems to be built with equipment that is twice the size so finding a replacement becomes difficult that will fit without too many modifications. a good example was an Isolator for a small machine it was so large, took all your effort to switch it and it's size was at least 3 times the one we eventually fitted.
Many companies do have specifications for equipment supplied in control equipment and efforts should be made to source either the the company standard or at least ones that have the standard profile.
 
Not that I would know anything about the UK... but I would think they are like here in the states and its more the 'industry' not so much the location, if I walk into a feedmill I am almost positive it will be WW and AB, down the street I can go into a peach processing and its going to be AD, if its a German owned manufacture it will be Siemens, my point I would look at your competitors in the UK because odds are your potential customers are going to want the same or similar controls

Just my 2 cents

EDIT: and for some reason if its a ice machine its Mitsubishi... or the 5ish machines I have worked on were
 
Last edited:
I agree with Genius, One thing I have learnt over the many years I have been in the industry is that some of the larger companies tend to have a strict specification, some even state that you must install some standard software they (or their approved system builders) have developed for them. These companies do tend to go for the larger PLC manufacturers like AB, Siemens etc.
As I said previously I have had many dealings with US companies but that is mainly because the particular machines needed were only available from the US and the British company who sourced them deal mainly in the US or actually did work for US based companies with plant in UK & Europe.
 
We have a site requirement to use Rockwell PLCs, for many years, but in some safety functionality, they lagged behind for a while.
When our purchasing or production colleagues get involved, or see a "product" at an exhibition, they want one, without a thought at the PLC behind the panel door. So they go for the standard package. Order placed, and when it comes to paperwork, it is Siemens, or a PLC model that we have never used, or a micrologix, so us projects have to make it work as they say "it will cost too much to change it now", so they went for bargain basement costs.
Be flexible in your solution, hopefully at a similar cost, so that you can exceed the customers expectations.
 
We are an OEM so our products are off the shelf standard products with minimum customization.

Maintaining multiple programs with the same feature sets is an engineering nightmare and cost prohibitive for the customer.

I doubt a customer would be willing to pay an extra $25,000 on top of a $75,000 system for us to rewrite our Program in another PLC vendors software.

If we do offer a choice other than AB it would have to be just one other vendor and we would probably charge a Premium for the second choice to justify the maintenance costs.

So now I guess the question, Do we need to do that, or is AB ok? if just AB is not ok, what other vendor should we use? Siemens?
 
Only with structured text is there any hope of reuse of the code across brands. Even then it is not 100%. Some checking and manual adaptation will be required.

An exception could be the PLC brands that are based on Codesys.
Maybe you can reuse Ladder and FBD across Codesys based brands.

Customers may be more concerned on standardizing on a particular fieldbus, rather than on a particular PLC brand. I.e. Profinet, Ethercat, Powerlink, Ethernet/IP ...
 
I work all over Europe, and as I see it depends of state and type of industry. Generally speaking dominant players are Siemens, Schneider, Mitsubishi and Omron. Also it seems to me that in infrastructural project usually I see Siemens and Schneider, and in factories usually I see Mitsubishi and Omron. I was surprised that AB is seen only from time to time, exception were UK and Ireland. All of this brands support what you asked (or mostly), while Schneider is Codesys as you already know.
 
As others have said, I think plc preference is more industry based than regional, largely driven by the historical platform choice of the BIG OEMs that supply equipment to those industries. My guess is Siemens would be the dominant player in many industries but I don't know that. I don't even know what industry theColonel26 supplies to.

However, I think you may want to consider the reasons customers ask for specific controls platforms. This may allow you to mitigate some of the arguments for a specific platform. I think the reasons fall into two large camps:
1) Customers want some control over their exposure to downtime.
2) Customers want the ability to modify the system on their own.

I think #1 is by far the most common case. Customers want to feel comfortable that their staff can correct issues that arise and that they have components on hand to cover failures. Given the audience here you probably wouldn't think that but consider the purpose of this forum. The audience here will more likely be doers than askers so most here WANT to play with their equipment. The general population is much less adventurous.

So:
IF you or an assign is available for 24/7/365 support AND
IF you or an assign has high availability for a plant visit, say within 4 hours of a call AND
IF your company can supply any defective control component within about 4 hours AND
IF your company is willing to pay production penalties if any of the above three cases are not fulfilled THEN

you could control your machine with intelligent squirrels fueled by sunflower seeds and the customer wouldn't care. Most customers have no allegiance to any given platform. They just want 100% uptime. Reasonably guarantee them that and they will be cool with whatever you do.

The criteria I stated above are obviously unreasonable. But the closer you can get to that the more receptive any given customer that falls into group 1 will be with your selection of platform. If you are dealing with a group 2 customer there isn't much you are going to do.

Keith
 
theColonel26 said:
So now I guess the question, Do we need to do that, or is AB ok? if just AB is not ok, what other vendor should we use? Siemens?
Click to expand...


On a global level, Siemens is #1 in PLCs, and Europe is a big part of that.


If you're going to pick a 2nd platform, Siemens is probably your best bet for broad acceptance.


That said, as others have stated, it DOES vary industry to industry, so it might make sense to find (pay for?) some industry specific marketing reports or something.
 
theColonel26 said:
I want to go to something Codesys based, but senior management is concerned about plants requiring Siemens. Codesys makes Studio 5000 look like a toy and allows a lot of openness and code sharing between PLC Brands. I assume Siemens is lacking in both to compared to Codesys, would I be right?

To Recap what Studio 5000 doesn't have and what Codseys does

  • Reference Types
  • Functions, only Function Blocks (AOIs)
  • Enums
  • UDTs as Input and Outputs for Function Blocks (Yes InOut works, no is not the same since you have to declare the tag outside of the FB)
  • Arrays as Inputs and Outputs for Function Blocks (including Strings)
  • Inheritance for Function Blocks and UDTs
  • Interfaces for Function Blocks
  • Viewing of a Function Blocks instance's data when it is executed in a loop
  • Multiple Subroutines for function blocks.
  • Partial Downloads (for Function Blocks etc.)
Click to expand...


Siemens is way more powerful programmingwise than AB, but probably not quite as far as Codesys.


Siemens doesn't have any of the object oriented/class inheritance stuff, or enums.


From your list, it CAN do:

  • both functions and FBs
  • UDT as In or Out, although this is typically frowned upon for memory optimization reasons. It takes time and extra memory to actually copy all the data into the FB, whereas the INOUT just passes a pointer. (not sure how you'd have the array at an in or out without having the tag declared somewhere else in any case?)
  • Arrays as inputs and outputs, although frowned on for the same reason as above
  • You can monitor an FBs instance data. If you're calling Instance1-10 in a For loop, you could monitor each one individually. If you have a For loop inside your FB, then you'll only see the status of the last time through the loop.
The older 300s/400s fully support partial downloads. 1500s are more of a kind of. When you do a DL it only DLs the changes, so your existing data stays, unless you changed the structure of a DB (vs AB where all data is replaced by offline tag values on DL). 1500s also support Units, which allows you to only DL a section of the program. No single block DL though.



Not sure what you meant by "Multiple Subroutines for function blocks"
 
Originally posted by mk42:

You can monitor an FBs instance data. If you're calling Instance1-10 in a For loop, you could monitor each one individually. If you have a For loop inside your FB, then you'll only see the status of the last time through the loop.
Click to expand...

This goes back to a post theColonel26 made a while back. In this case he had an array of AOIs in a Logix PLC and he ran through them in a loop with an indexed reference into the array. Logix5K/Studio won't let the user select an AOI instance that is not explicitly referenced in the plc code. So the array members don't show up in the AOI instance selection list. I don't think he was referring to the data inside a loop inside an AOI.

This is a definite hole in Logix 5K/Studio. Like I told my local Rockwell guy, the Studio developers had to go out of there way to prevent the user from seeing these items. Why, I don't know.

Keith
 
mk42 said:
Siemens doesn't have any of the object oriented/class inheritance stuff, or enums.
Click to expand...
:( that blows

mk42 said:
UDT as In or Out, although this is typically frowned upon for memory optimization reasons. It takes time and extra memory to actually copy all the data into the FB, whereas the INOUT just passes a pointer. (not sure how you'd have the array at an in or out without having the tag declared somewhere else in any case?)
Click to expand...
Well, it would be nice if it also supported Public too



But if you have an In or Out, you can reference it via the AOI tag, In AB if you have an InOut you can't reference it else where by the AOI Tag.


Also with an In or Out, the data is actually stored with the AOI instance, so you don't have to read or write into it on every scan.


For example


Say I have a AOI_Blah AOI type, with an instance called AOI_Blah_Inst and I have an InOut on the AOI called Stuff and the stuff instance is called Stuff_Inst.

In AB I can't use AOI_Blah_Inst.Stuff I have to use the Tag Stuff_Inst. So I can't write in to AOI_Blah_Inst.Stuff if I want it as an Input and I can't read out of it, if I want it as an output. I have to use a separately defined tag and reference that tag.


So if I want to have a AOI for a pump for example and I want to have a string to give it a name. I can't just do

Code: 
Pump_Inst.Name := "Some Name"; //and execute it once
I have to create a separate string tag for ever pump instance.
and I have to reference that separate tag to read or write instead of just Pump_Inst.Name


mk42 said:
The older 300s/400s fully support partial downloads. 1500s are more of a kind of. When you do a DL it only DLs the changes, so your existing data stays, unless you changed the structure of a DB (vs AB where all data is replaced by offline tag values on DL). 1500s also support Units, which allows you to only DL a section of the program. No single block DL though.
Click to expand...


Well the main thing is, do I have to actually put the whole PLC in program mode?




mk42 said:
Not sure what you meant by "Multiple Subroutines for function blocks"
Click to expand...

In codesys. you can define Actions and Methods.

So you can can use Actions to organize your code and call it from the main FB routine or you can call that action or method externally to the FB.


As a consequent you can have rather large, but organized Function Blocks.



kamenges said:
This goes back to a post theColonel26 made a while back. In this case he had an array of AOIs in a Logix PLC and he ran through them in a loop with an indexed reference into the array. Logix5K/Studio won't let the user select an AOI instance that is not explicitly referenced in the plc code. So the array members don't show up in the AOI instance selection list. I don't think he was referring to the data inside a loop inside an AOI.

This is a definite hole in Logix 5K/Studio. Like I told my local Rockwell guy, the Studio developers had to go out of there way to prevent the user from seeing these items. Why, I don't know.

Keith
Click to expand...
Correct (y)
 
Last edited:
theColonel26 said:
:( that blows

Well, it would be nice if it also supported Public too
Click to expand...

theColonel26 said:
In codesys. you can define Actions and Methods.

So you can can use Actions to organize your code and call it from the main FB routine or you can call that action or method externally to the FB.

As a consequent you can have rather large, but organized Function Blocks.
Click to expand...

Agree, those are good features I wish we had in Siemens. Some of the products (soft PLC or 1518MFP) allow you to go full PC based with C code running out of the PLC. They also introduced some things that you can do with Variant pointers like references, where you can do shenanigans with the variables based on which data type it is. On the whole, though, they've stuck with the programming paradigms that have existed for a while, with some tweaks here and there.

On the plus side, they DO support methods over OPC UA, which I hadn't even known was a thing.

theColonel26 said:
So if I want to have a AOI for a pump for example and I want to have a string to give it a name. I can't just do

Code: 
Pump_Inst.Name := "Some Name"; //and execute it once
I have to create a separate string tag for ever pump instance.
and I have to reference that separate tag to read or write instead of just Pump_Inst.Name
Click to expand...

Oh, I see. yes, that is something Siemens can do. All FB instances are global, and you can nest them inside each other.

On an FB, all inputs and outputs are optional, you don't actually have to have to parameterize all of them if you don't want to (and you can actually mark some as explicitly optional, where they aren't even shown by default). Then you can refer to the tags as Instance.Name.

You cannot do that with an INOUT, because it only passes a pointer in. Those must be parameterized at the block call, or it won't compile.

I think you could also pass the string in as a constant at the original block call.

theColonel26 said:
Well the main thing is, do I have to actually put the whole PLC in program mode?
Click to expand...

The PLC modes and DL process is very different between Siemens and Rockwell.

From a code perspective:

The PLC has to go into STOP to download a HW change (new IO device, change parameters of existing IO device, etc) or to DL a safety program.

All other changes can be made in RUN, at least for 300/400/1500. I think the 1200 might have a limit to how much code can be downloaded in RUN (or maybe changes are OK but not new blocks?) but I don't use that platform much.

From a data perspective:
Going from STOP back into run causes all non-retentive data to get initialized to the defined start value for the tag. They give you ways to help your data have good useful start values, and multiple methods of storing recipes/parameters besides retentive tags. The actual values of the PLC are not stored in your offline project, unless you specifically grab them.

Also, if you change a DataBlock, the data in it usually gets initialized, unless you've previously activated the feature to prevent that.


As an aside, if you're going Siemens, you almost certainly want to go with something in the S71500 family. It's the platform with the most options and most active development. 300/400 are relatively old (although 400 is still the go to in the process world), and the 1200 is for smaller applications (slower CPU, less memory, usually gets features a version or two later, kinda like hand-me-downs to a litte brother).
 
Last edited:

Similar Topics

theColonel26
Attention Europeans: Wire Numbering Question
I have heard that in Europe the most common wire number scheme is a unique number for each wire. As opposed to wire numbers based on "Net" that is...
2 3
Replies
33
Views
11,417
lfe
L
B
Attention abb guru's
I have an L7 logix controller. I am trying to communicate with an AB ACS500 with a RETA-01 card ethernet interface. I have downloaded the EDS...
Replies
10
Views
3,207
Buzzen
B
F
CEmAt GuYs Attention Pls
hello guys Can any one tell me the link or location at Siemens Web Site or any where else from where i can ghett the manuals of Cemat 6.1 or...
Replies
3
Views
3,755
farrei
F
panic mode
Siemens PTO module with attention deficit disorder
Hi everyone, We are using ET200S I/Os which are controlled by S7-317F-PN/DP CPU. One of the modules acts strangely. It is 6ES7138-4DD00-0AB0 and...
Replies
2
Views
1,844
panic mode
panic mode
PLucas
OT..sort of... For the attention of Jesper
Jesper, Just a quick note to say thank you to you for posting a very useful reference guide in the download section. I had a need today to use...
Replies
2
Views
3,089
PLucas
PLucas
Back
Top Bottom