How accurate is "If you can program one PLC, you can program them all."

nerdbotbot · Sep 28, 2017

Hi,

So far I have only dealt with Bosch - Rexroth hardware, Codesys (programming) and Indusoft Webstudio (SCADA).

However, the most widely used PLC packages in my country are from Siemens and Allen-Bradley.

Will my experience with Rexroth/ Codesys be of any help?

Thank you

bernie_carlton · Sep 28, 2017

Being able to successfully program a PLC of any type means that you have established a basic understanding of the process. The next hurdle is transitioning to another platform. You then begin the process of establishing in your mind the features common to computerised control and those which are applicable to just one line. If you have the flexibility to make the distinction and not be distracted by the differences then your previous experience will serve you well.

gclshortt · Sep 28, 2017

+1 bernie_carlton

Well stated!

AustralIan · Sep 28, 2017

Two kinds of programmers, or at least programming situations:
1. You have to think of the process and what it needs to do and come up with the correct control concept for a given process.
2. You have a simple or well described task that needs programming.

If I was hiring for number 2, I would rather someone that already knew the platform well, as they will be able to complete it faster.
If I was hiring for number 1, I would want someone with impeccable logic and previous process experience, and honestly wouldn't care which particular PLC they have used.

mk42 · Sep 28, 2017

If you know one system, that's a big help in learning the second. If you know two brands, then you probably know enough about what makes systems different to be able to learn any others quickly.

For the most part, the concepts of programming/ladder logic are the same across the board. Lots of details change though, like the names of the instructions, the data types, how memory is addressed, how you access the PLC clock, what communication methods are preferred, where the buttons in the software are, etc.

mk42 · Sep 28, 2017

AustralIan said:
Two kinds of programmers, or at least programming situations:
1. You have to think of the process and what it needs to do and come up with the correct control concept for a given process.
2. You have a simple or well described task that needs programming.

If I was hiring for number 2, I would rather someone that already knew the platform well, as they will be able to complete it faster.
If I was hiring for number 1, I would want someone with impeccable logic and previous process experience, and honestly wouldn't care which particular PLC they have used.

Programmer 1 makes more per hour and sometimes takes longer, but is more likely to be right the first time. Programmer 2 can be cheaper and quicker, as long as everything goes right.

The way I see it, some people look in the tool box to see if they have the right tool. Others really like their hammer, and aren't interested in checking to see if the problem is a nail or not.

Paullys50 · Sep 28, 2017

Much is cross-functional in-terms of basic logic understanding and fundamentals. Process understanding doesn't change, but how you create code for process solutions, and how efficient you are will determine the quality of the overall system, and just as important, the profitability of the project.

Having advanced knowledge on a few platforms means you'll produce a better project, in a more efficient manner, with advanced features at a profitable price point.

Jack of all trades and master of none? I've found I'm more valuable to companies for my advanced knowledge of the primary players rather than my diversity.

AutoMax · Sep 28, 2017

I agree with what the others have said as far the basics being applicable across programmable systems. Some things are just very starkly different between platforms and can be a pretty significant bother. If your background is in PLCOpen motion control and are asked to modify a Rockwell motion application you will become frustrated very quickly...
I typically would say if you're familiar with Rockwell, Siemens, and CoDeSys you're pretty solid. In the US, AutomationDirect experience is probably more valuable than CoDeSys, but that's changing (much to the chagrin of us MultiProg fans.)

AustralIan · Sep 28, 2017

In our case the hammer is the right tool, but sometimes you want someone with rubber mallet weidling experience. But I agree, most times you want someone that knows what they are doing and why they are here.

RET · Sep 28, 2017

mk42 said:
Programmer 1 makes more per hour and sometimes takes longer, but is more likely to be right the first time. Programmer 2 can be cheaper and quicker, as long as everything goes right.

The way I see it, some people look in the tool box to see if they have the right tool. Others really like their hammer, and aren't interested in checking to see if the problem is a nail or not.

It's funny how many people I run into who think they're a number 1, but really turn out to be a number 2!

Peter Nachtwey · Sep 28, 2017

PLCs are just a tool. It is understanding the machine and how it works or needs to work that is important. After that it is just getting to know the tools and the quality of the tool.

dogleg43 · Sep 28, 2017

In addition to the programming differences that others have mentioned, one also needs to be adept at the differences between configuration, comm protocols, and to a certain extent I/O module differences.

IMO, it not just about being able to come up with the program and punch it in.

JRW · Sep 28, 2017

A few years back I met a system integrator that took over a project from another system integrator
The system was an S5 and he was retrofitting it with an S7400. He told me "I havent met a plc I couldnt program and get working"
A few days later he put the S5 back in and I never saw him again
haha
Granted- he didnt know how the machine worked either

SoftwareJanitor · Sep 28, 2017

AustralIan said:
Two kinds of programmers, or at least programming situations:
1. You have to think of the process and what it needs to do and come up with the correct control concept for a given process.
2. You have a simple or well described task that needs programming.

Actually, it's the same person. You *should* be doing #1 first (by writing a Functional Spec), then you'd have a "well-described task" that you can use to do #2.

If you're not doing #1, and you're coding without a Functional Spec, you might be proud of yourself, but that's just not good practice.

=========

But as far as the OP's question ... I'd say it depends more on the language. You can be an object-oriented programmer using C++, but that's very different from National Instruments' object-oriented "LabView" programming language (which is graphical). But I would think, in the world of PLCs, Ladder Logic is Ladder Logic (with differences from platform to platform that would be more annoying than anything else).

mk42 · Sep 28, 2017

SoftwareJanitor said:
Actually, it's the same person. You *should* be doing #1 first (by writing a Functional Spec), then you'd have a "well-described task" that you can use to do #2.

If you're not doing #1, and you're coding without a Functional Spec, you might be proud of yourself, but that's just not good practice.

I think his #2 is when you're hiring someone and handing them the functional spec.

How accurate is "If you can program one PLC, you can program them all."

nerdbotbot

Member

bernie_carlton

Lifetime Supporting Member + Moderator

gclshortt

Member

AustralIan

Member

mk42

Lifetime Supporting Member

mk42

Lifetime Supporting Member

Paullys50

Lifetime Supporting Member

AutoMax

Lifetime Supporting Member

AustralIan

Member

RET

Member

Peter Nachtwey

Member

dogleg43

Member

JRW

Member

SoftwareJanitor

Member

mk42

Lifetime Supporting Member

Similar Topics