Can standard controllers be combined in automation?

[bonzer]

Hello! I have a curiosity.. When dealing with control regulators: my question could sound strange because I'm at the beginning of an electronics engineering degree and not automation but I was thinking about automation control. I know they usually use standard blocks like P, PI, PD, PID. But I don't think you can do any function you want with them. But they are simple and confortable when dealing with discretizations. But if I want a general function because I find it particularly helpful for my system. For example (s+x1)/(s+x2) where x2>x1 how do they deal with that? Is it all just programmable for example in PLC? (I know nothing about PLC) . Or they use some combinations, for example: this function could be acquired with a block of a PD controller if it has an external proportional constant feedback (like a P controller) so this closed loop system would give me that type of function.
In analog electronics you can place capacitors and resistors with opamps to get almost any transfer function you want.
But in automation where it looks like they usually use blocks? Anyway this is my curiosity. I also see that discretization methods are usually made for standard control blocks.

[Mattjd]

I'm not sure I fully understand your question and I've never dealt with programmable logic controllers but I do not believe they're the same controller as in a PID controller.

The discretization of a PID controller is done the same way as for a filter. The proper way is with dsp techniques, but that can be overkill in a lot of cases.

The general method is create the transfer function for your system, converting any mechanical components to their equivalent electrical counter part. Once the transfer function is made, a PID controller is tuned to obtain the desired rise, fall, settling times, over shoot error, etc.

With the s domain equivalent obtained, and gain parameters found, the discretization occurs by applying one of a few different transformation techniques. The most popular is the bilinear transformation, this will convert your complex algebraic equation of variable s into a complex recurrence relation of variable z. The inverse z transform can then be taken which provides you with a finite difference equation which is the discrete counter part to an ordinary Differential equation.

[Sedly]

There are quite a few types of PLCs as well as distributed control systems.  Many are quite sophisticated and feature a selection of programming languages  from ladder logic to sequential function blocks to structured text. Block functions such as PID blocks as well as math functions and multi-dimentional arrays are available. They are quite capable and support sophisticated I/O as well as communications. They can easily perform the type of trnansform you outlined.

The hardware tends to be expensive and the programming tools are proprietary with significant license fees. These are the tools used by Controls and Automation engineers.

[Medium]

The hardware tends to be expensive and the programming tools are proprietary with significant license fees. These are the tools used by Controls and Automation engineers.

Programming PLCs is a big part of my daily job, and thanks to the availability of high level language support I practically do not need any knowledge of electronics to automate entire plants*. (Provided that anything that happens outside the PLC is handled by someone else.) PLCs are practically a µC on steroids. In industry application, no one would really implement functions in dedicated hardware these days anymore. Even simple small machines have at least some type of µC to do most of the logic stuff. They cost pennies and are reliable enough.


*) And in fact, I have next to none. I'm an IT guy (application development) that ended up doing automation for a living.

[Berni]

This is why they are called Programmable Logic Controllers.

As long as they have a means of analog input and output they will also have math functions to implement anything you want. Its essentially a super robust microcontroller with some fancy underlying firmware and a IDE to program it in.

Just like a computer it will want everything is discrete form in order to run it real time. So no plopping down integrals and derivatives, you need to turn it into a series of additions and multiplies first. But in most cases of process control the PLC will be much faster than the sluggish industrial process it is controlling, so simply doing your integration as i = i+x and derivative as d = x-i tends to be close enough.

None of this is done analog anymore since PLCs offer so many advantages. A big thing with PLCs is also that they can be wired up on a network. This means your process control room can simply be some ethernet cable running into a PC running SCADA software, so that operators click virtual buttons on a screen. As opposed to having to wire up tens, hundreds or even thousands of wires into individual gauges and switches on a huge custom built control panel.

[Mattjd]

Interesting comments in this thread. I was sort of under the impression that a PLC was something for just digital signals.

After looking through the Simulink documentation for PLCs I get what you guys are saying now.

Thanks

[bonzer]

I have a little problem, I'm still a student as I sad and I don't know if it's worth for me to try to attend a PLC course (at my university as part of career).
Being specialized in analog/power electronics (with little FPGA) and having done something about motor control, electric drives and system/control theory will it enable me to anyway compete with  programmers from computer science or automation engineers in programming PLC? Is it worth?

I mean could I find after that anyway a PLC job or it's more likely that they will employ a programmer or automation engineer?

[Medium]

I have a little problem, I'm still a student as I sad and I don't know if it's worth for me to try to attend a PLC course (at my university as part of career).
Being specialized in analog/power electronics (with little FPGA) and having done something about motor control, electric drives and system/control theory will it enable me to anyway compete with  programmers from computer science or automation engineers in programming PLC? Is it worth?

I mean could I find after that anyway a PLC job or it's more likely that they will employ a programmer or automation engineer?

From my perspective, it's a mixed bag. I as an IT guy personally tend to dread the works of an electric engineer that obviously just dabbled in programming, especially when it comes to higher level language stuff. A lot of the things I see around just reeks of early 90s basement dwellers' C64 BASIC experience carried over to the, erm, somewhat modern world, and is a nightmare to read, reverse-engineer, understand and/or expand. There is just sooo much legacy code going around made by people that most probably only worked to make themselves indispensable, it hurts. (Which is understandable to a degree, because many of the techniques (or lack thereof) were state of the art back in their prime.)
Another issue I have with EEs having a go at modern PLCs is that many resort to using the hardware imitating "languages", which at basic IO-level is pretty much mandatory, but at functional stages the higher level languages provide much much better workflow, modularity and ressource usage. Not to mention maintainability. This is further facillitated by the creators of the respective toolchains often beeing rooted in EE fields, that try to force such a kind of programming. (I.e. there are no gates or latches in programming. These are artificial constructs from a programmer's point of view.)

A lot of this can be attributed to the fact that the entire field of automation is and so far always has been ~5-10 years behind the end-user application developer world, even in terms of hardware. Which is also explained well enough by the need to have very well evaluated stable and thoroughly tested platforms. But especially in terms of programming paradigms, automation is behind by at least two generations so far.

I also don't want to poop on the now about 50-70 years old people that mostly make up the demographic I just talked about. These were absolute pioneers in the field, and deserve all the praise they got and get! Even more today, since a lot of the knowledge and mindsets they have is sorely missed among many of my generation (and then some), don't get me wrong. But these skills nowadays are best used in R&D, less so in actual production and field deployment.



So what would be my recommendation for someone going into automation today?

(1) If your goal is developing automation devices, get an EE degree and expand on its portion of software development in your spare time, and dare to look at current private end-user developments on the PC and phone side to gauge what you may have to deal with 10+ years down the line. This is also where intricate µC knowledge comes in very handy.

(2) If your goal is development and deployment of industrial end-user automation systems, there are now two paths to take: (2.1) Electrical engineering, and (2.2) "logic engineering". The EE will mostly be concerned with the "power and signal" side of things, feeding the machines and PLCs. The "logic engineer" is tasked with making a PLC program to implement a machine's (or plant's) higher level functions, and often also the user interface, now usually done with some kind of touch display instead of buttons, lamps and gauges.

Path 1 is best served by experience in the EE field and being able to calculate electric networks and complicated circuitry coupled with low level programming skills going as deep as FPGA development.

Path 2.1 is the fairly traditional path of the industrial electrical engineer that knows how to wire up field sensors and actors and how to dimension parts to be able to deal with the electrical demands of a machine/plant.

Path 2.2 is relatively abstract and mostly deals with the high level functions of a machine or plant. It is much more akin to a software developer than an electrical engineer. The latter they usually "feed on" for their "basic" IO.

Being able to configure isolated machines like individual motor controls is shared between 2.1 and 2.2. Both should be able to keep up with stuff like that. Ideally. Path 1 only needs to know how to not make this a total pain for members of the path 2 groups =)


TL;DR: If you are on the path of an EE, any opportunity to look at any kind of programming experience for little or free will definitly be worth your time.

[bonzer]

Thanks a lot! Even though they taught us java programming, algorithms and data structures in some common courses, we have never designed software and I'm not even interested in that high level programming so I most likely will fall in the first case or case 2.1.

I'm glad I'll anyway be able to be close to the automation or industrial application because I'm not a big fan of HF devices and all the stuff that is related to ICT, microwave devices and antennas. It's kinda another side of small power electronics applications.

[Berni]

I actually did a my degree in automation.

Its not actually all that complicated of a field and most of the reason why i did that instead of masters in electronics is due to one professor. I really didn't like him but he was teaching like 1/3 of all classes for that direction. Nothing personal but in the 1st year all of his lectures ware so dull that i had trouble staying awake trough them. Also his lecture slides are handwritten in permanent marker on transparency sheets, that are scanned in and flipped trough using windows image viewer(Im guessing the only reason they are scanned in is because we didn't have any transparency projectors in the university anymore, only digital projectors). The direction for electronics in my uni is common for the 1st year and then splits off into electronics, power, telecommunications and automation/robotics. Also we share some classes between the fields. The reason i picked automation is that it seamed the most interesting and hands on from all of these.

As my job i ended up being a electronics design engineer anyway where i design electronics, draw schematics and PCBs, assemble and test prototypes etc.

So it doesn't really matter what direction you pick at school as long as its vaguely in the right direction. Having a degree in anything technical and engineering related will help you land any technical job, be it electronics, automation, programming, IT, heck even mechanical engineering. Its what you KNOW that counts. As long as you know how to hook up a PLC and program it to do stuff you can get a job in automation.

Its the jobs of electronics engineer and programmer that require the most know how. If you have a degree in electronics engineering and you never done any electronics as a hobby then you suck. There is no putting it mildly, you will be a trainwreck at your first engineering job even if you can bullshit your way trough the interviews. In these fields schools don't teach enough to make you competent, so you have to learn on your own by doing hobby projects and get good at it. Automation tho is not all that hard as long as you have a good engineering problem solving mindset.