Continuing Education, PLC/Software Focused

[Shaneyj]

Quick background: I've got ~ 23 years in the elec field.
15 resi/commercial
5 years industrial
Last 3 years, post degree completion (EET), I have been electrical engineer for my company (don't be offended degreed EEs - this is what's on the HR form for my job description but for those that ask I clarify my position).
I have exposure to PLCs and software development; a few entry level classes during school and OTJ stuff. I know enough to fudge my way through a conversation.
After some looking around for the last couple months, I have decided to pursue something.
I have gone through a couple Udemy courses that didn't take me much past what I knew already. I would love to do something like the Ron Beaufort course (last I looked he retired and no longer offers his trainings) but I need something either local or remote offered so I can continue my day job.
I'm in the Houston area - the only local offering I have found is through University of Houston-Downtown, which looks promising. Before I pull the trigger I'm polling the audience.
1. Any advice on PLC programs?

2. From a programming language perspective, aside from PLC, where would you start?

Thanks for your thoughts.

 

[petersonra]

I think you will find that the training classes are pretty good at teaching you the specifics of how to use the software and some of the features of the PLC's but you will never learn all that much beyond that unless you actually use them to solve real-world problems.

There isn't all that much difference between how different brands of PLCs work. They pretty much all work the same and most have very similar features. Learning to use the software for each one can be a bit of a challenge and the classes are pretty good for that.

 

[EC Dan]

All the different PLC vendors will have their own platforms for development so like petersonra said, much of the challenge is learning how to use the individual platforms. I use Studio 5000 Logix Designer for the Rockwell CompactLogix/ControlLogix series. You will want to learn the IEC 61131-3 languages (ladder, SFC, FBD, etc.) and when to best apply each one. I would also recommend branching out early into PACs (programmable automation controllers) and getting good at programming things like UDTs (user defined tags) and AOIs (add-on instructions), which requires a healthy understanding of object-oriented programming.

 

[__dan]

The best way to learn is to have the job doing it. Study, learn, practice, while they pay you. Each plant will have some specialization in which manufacturer's equipment they standardize on. There's a lot to know just in the proprietary interface (Allen Bradley, Siemens, ...). Luckily it's 2021 and when you get stuck there's Google for that.

Under the hood, the base technology is all standardized (IEEE), and mostly built by someody else (so non proprietary). The OS is Windows or a Linux variant, it's all probably Java under the hood, the processor is an old cell phone chip, SOC, that sells for $8.

That's where you need a few good CC community college courses. One good course in C or C++ will give you a good idea of data types, pointer memory addressing, and the basic conditionals. If you get C++ first, Java will be very easy to use. If you get Java first, how or what the reference is and the difference between a data type and a class could be harder to grasp. Java is very easy to use. Java and C# are indentical looking.

Take one good CC course in Networking. It helps to have the structured workload to learn what you need to know.

The base knowledge is not changing that much but the proprietary interfaces are changing all the time. It can be difficult to keep up with the rapid changes without a good understanding of what is happening under the hood, the base stuff is not changing that much, just faster and more features.

It's a good specialty that pays well but can be hard to break into. It's a lifetime of learning. I have seen a lot of I and C techs who never went to school and remain clueless, fakers, dangerously so. The guys who have gone to school are pretty good and smart, big difference.

 

[petersonra]

I am an EET too, so I would not get real excited about what title you have.

I would suggest if you have not already had a class in boolean algebra you take one. Basically ladder logic is a symbolic version of boolean algebra and once you make that connection things are a lot easier.

I would second the networking class. ethernet is everywhere and it is easier to take the class and learn the words than it is to try and pick it up as you go.

Personally, I would not worry about java or C++. I have never needed either in 40+ years. You might find that a VBA class is helpful because you may find it handy to be able to use spreadsheet in a semi automated way for various things. However, any programming class you take will probably help you to think in a more orderly way and that is probably as important as anything.

 

[Shaneyj]

I appreciate all the feedback.
We develop our controls and data acquisition in house, so I have access to Siemens and Beckhoff PLC platforms.
Staying after hours to get some time on them is available to me.
Your comments have helped to clear things up some - coupled with my Software Engineer's comments I am narrowing down a direction to go.
Thank you again - more replies welcome!

 

[EC Dan]

Personally, I would not worry about java or C++. I have never needed either in 40+ years. You might find that a VBA class is helpful because you may find it handy to be able to use spreadsheet in a semi automated way for various things. However, any programming class you take will probably help you to think in a more orderly way and that is probably as important as anything.

I started off doing lab-scale control systems in Java and I think it helped immensely when I moved into PAC programming due to the object-oriented nature of Java. Code reusability and modularity is very important in efficient plant-level PAC programming especially with regards to HMI integration. I agree it's not worth learning Java as a pre-cursor to PLC programming but I do think understanding object-oriented programming is important to fully leverage PAC capabilities.

 

[Shaneyj]

I started off doing lab-scale control systems in Java and I think it helped immensely when I moved into PAC programming due to the object-oriented nature of Java. Code reusability and modularity is very important in efficient plant-level PAC programming especially with regards to HMI integration. I agree it's not worth learning Java as a pre-cursor to PLC programming but I do think understanding object-oriented programming is important to fully leverage PAC capabilities.

What is PAC programming?
Is Python a good starting point to object-oriented programming?

 

[__dan]

What is PAC programming?
Is Python a good starting point to object-oriented programming?

My understanding is that Python is very popular, to the point of if you are programming in Python you won't be doing any electrical.

All of the languages are ultimately just an interface to the hardware, they all end up doing the same thing on the hardware (for simple tasks, for complex tasks choice of language can make it doable or not).

From there the difference is if it's an interpreted language or compiles to machine code. Python just like ladder logic are interpreted. Java compiles to a machine independent (byte code). Compiled languages run fast or faster.

High level languages are an abstraction layer, they hide complexity from you. Good for the very complex tasks but bad for the basic tasks where you don't know what the machine is doing (but should know).

Ultimately they are all just writing to the memory register, reading from the memory register, then using that in some evaluation. Starting with C will show you what the machine is doing, then the other languages will be much easier to pick up. Java is a C variant.

 

[BillyMac59]

Forgive me if I repeat what others have stated. You want to improve your PLC skills for your current job, I assume? What platforms are you or your customers using? Getting up to speed on this/these will show your employer your level of interest/skill. Do you have access to the software? Do you have the interface cables required - if any? Do you have access to a spare processor where you can upload/down load programs, configure the PLC if it's a new system? Youtube can give some "training", PLC manufacturers also offer it. If your footing the bill for the training yourself, be sitting down when you look at these numbers. Allen bradley comes to mind....

 

[petersonra]

As best I can tell there's not a whole lot of difference between a PAC and a PLC. Mostly a marketing term and a matter of scale.

 

[EC Dan]

As best I can tell there's not a whole lot of difference between a PAC and a PLC. Mostly a marketing term and a matter of scale.

This is correct, but for what it's worth I look at it as PLC for machine-level and PAC for plant-level. This goes back to code reusability; you may not be reusing much code or making use of modular code at the machine-level which will be highly specialized, but you will at the plant-level.