Learning PLCs from the very beginning

[janoc]

This pointless argument is fun to watch.

I am not aware of an CPU/MCU capable of running e.g. ladder logic directly!

I'm not familiar any CPU/MCU that is capable of running any programming language directly.

There were ARM CPUs capable of running Java bytecode directly (Jazelle), for ex. But yes, strictly speaking it all gets compiled into some kind of machine code.

[Vtile]

This pointless argument is fun to watch.

I am not aware of an CPU/MCU capable of running e.g. ladder logic directly!

I'm not familiar any CPU/MCU that is capable of running any programming language directly.

There were ARM CPUs capable of running Java bytecode directly (Jazelle), for ex. But yes, strictly speaking it all gets compiled into some kind of machine code.

Exactly.

[Nerull]

The pedagogical value, we seek, is possibly is out there somewhere. For the sake of making systems absolutely correct with provable correctness, unhackable.

Are you familiar with Stuxnet, the virus designed to attack PLCs, subtly modifying their behavior to destroy equipment connected to them?

PLCs are far from unhackable.

[janoc]

PLCs are far from unhackable.

I would even go as far as saying that they are notorious for being insecure. Get on the plant's network and it is game over. Even the PLC security holes notwithstanding, the PLCs have rarely any meaningful access control or authentication. If there is a password and it isn't the vendor default one, it is likely a trivial one and identical for the entire plant to simplify maintenance. Oh and having the plant LAN directly connected to the administrative networks (which are connected to the Internet) is also very commonplace - the management wants to see pretty dashboards and blinking lights. And then a stupid virus strikes and there is suddenly a blackout or production stoppage ...

And the bugs are pretty much never fixed because it would mean taking the plant offline and updating firmware in every single affected one. All the while risking that who knows what stops working afterwards. Not going to happen.

[Berni]

The pedagogical value, we seek, is possibly is out there somewhere. For the sake of making systems absolutely correct with provable correctness, unhackable.

Are you familiar with Stuxnet, the virus designed to attack PLCs, subtly modifying their behavior to destroy equipment connected to them?

PLCs are far from unhackable.

Well technically the PLC was working as intended since being able to load in new programs or to read/write variables is what that network interface is supposed to do. The idea being that networks that PLCs sit on are dedicated isolated networks. Much like telephone line is dedicated for that one task and is not supposed to have any security features. Just that some PLCs happen to be able to use normal consumer Ethernet as its transport medium. Much like in the old days there was individual wires carrying analog and digital signals to individual meters and dials in the control room, this wiring is now replaced by digital data running trough twisted pair.

The actual vulnerability was that people plugged random USB drives into PCs on this isolated network so by peppering the Stuxnet virus all over the facility eventually someone would infect a USB drive by plugging it into a infected machine and then at some point plug the same USB drive into the isolated control room PC.

Security is hard tho, especially when a nation pours mountains of money into the effort of breaking your security.

[RoGeorge]

I hope that this can help someone else, who is just starting with PLCs. The fascinating devices which are designed to never fail no matter what.
So thanks to work duties, I was volonteered by my team to go and learn PLC thing. To learn officially in 4 days.
Here is my thoughts about PLCs at day 3 of learning, from the point of view of software/firmware developer, a list of things I made for myself, to share with other newbies. It is mostly conclusions, not the direct content of what they teach you.

1. No fancies there in a languages (ladder language, plain text, diagrams etc. they are all about the same)
2. No pointers
3. No stack (nearly everything as parameter is passed by value, may be using stack after all, but hard to tell)
4. No loops (they are there, but not recommended, I mean loops like FOR, WHILE, REPEAT UNTIL)
5. No strings (not recommended, unless you really need it)
6. No heap
7. No dynamic allocation, deallocation
8. No exceptions (except may be divide by zero or similar)
9. No jumps or goto (can be used but explicitely not recommended)
10. No need for code address labels, since no goto
11. No ends, returns, exits or halts. The scanning keeps looping forever.
12. No stepping, so no debugger, only monitor
13. No breakpoints
14. No OS or kernel or framework, it is true bare metal
15. No error handling since it is not an OS
16. No tracing outputs, only monitoring (or I did not lean it yet)
17. No threads
18. No locks since there is no threads

So what you have ? So far it looks like a sort of pre FORTRAN with only static manual allocation of DATA and CODE.
I hope this is helpful for software minded people who wonders what PLC actually is.
It is not a criticism, but just an observation how much of usefulness one can get from programming, when everything unnecessary is removed.
ha ha.

Edit: And the good news is that you need nothing, just a bunch of relays to build civilization upward from the complete disaster, just by using PLCs alone.

Overall, my advice is to let it sink for a while before jumping to conclusions.  Do a few real world implementations (recommended at least 3-5 of them) before commenting about it.

Pretty much every conclusion is not OK.  Nothing about blaming you here, just that a 4 days training classes is obviously not enough to get a taste of the subject.  Again, not your fault, but you are looking at it from a very wrong angle.  First of al you need to drop the "programming/algorithms" priority, and think about it in terms of "real world process control" priorityies, which are very different, each with their own set of problems.

By the way, overall you are obviously on a good path already, and the way you treated so far this dialogue is highly appreciated!   

[Nerull]

The pedagogical value, we seek, is possibly is out there somewhere. For the sake of making systems absolutely correct with provable correctness, unhackable.

Are you familiar with Stuxnet, the virus designed to attack PLCs, subtly modifying their behavior to destroy equipment connected to them?

PLCs are far from unhackable.

Well technically the PLC was working as intended since being able to load in new programs or to read/write variables is what that network interface is supposed to do. The idea being that networks that PLCs sit on are dedicated isolated networks. Much like telephone line is dedicated for that one task and is not supposed to have any security features. Just that some PLCs happen to be able to use normal consumer Ethernet as its transport medium. Much like in the old days there was individual wires carrying analog and digital signals to individual meters and dials in the control room, this wiring is now replaced by digital data running trough twisted pair.

The actual vulnerability was that people plugged random USB drives into PCs on this isolated network so by peppering the Stuxnet virus all over the facility eventually someone would infect a USB drive by plugging it into a infected machine and then at some point plug the same USB drive into the isolated control room PC.

Security is hard tho, especially when a nation pours mountains of money into the effort of breaking your security.

There's more to it than that. Stuxnet installed a rootkit on the PLC allowing it to hide itself from monitoring systems. It was an incredibly sophisticated attack that relied on simultaneously attacking multiple systems at multiple network layers.

[rstofer]

I have always asked myself:  Why was the control system exposed to the Internet?  Who would be that stupid?  Sure, it allows consultants, thousands of miles away, to update the program but that's a bug, not a feature.

[rstofer]

No stack, you say?  I was looking at a PLC yesterday and it was clearly stack oriented and, in fact, had just 8 levels for expression evaluation.  The programming language was specifically designed for stack operations.

https://www.automationdirect.com/adc/shopping/catalog/programmable_controllers/directlogic_series_plcs_(micro_to_small,_brick_-a-_modular)/directlogic_06_(expandable_micro_brick_plc)/plc_units/d0-06dd1

Chapter 5 has the instruction set:

https://cdn.automationdirect.com/static/manuals/d006userm/dl06userm.pdf

[Workalot]

To the OP...

Ladder logic starts with a document. It is the graphical representation of the control algorithms. This is important as there is then a document that others can consult to fix issues or advance performance.

Further, ladder is familiar to field technicians. 

How the ladder logic diagram is translated for execution is PLC specific. Some may have an interpretive regime (Java like) but the best result is to have the ladder diagram rendered to machine code.

The mechanism to update is preferably done independently of the PLC's operating system. As with mobile phone system updates it is done while the system remains active.

C/C++ based solutions require a system recompile and system stoppage when downloading the replacement runtime. Beyond field technicians pay grade I'll bet.

And yes, no pointers, no threads, no heap etc - just a look, think, act in a repeating sequence.

[wizard69]

I really hope this training course wasn't from one of the major PLC vendors because it looks like they have made the wrong impression on you.

I hope that this can help someone else, who is just starting with PLCs. The fascinating devices which are designed to never fail no matter what.
So thanks to work duties, I was volonteered by my team to go and learn PLC thing. To learn officially in 4 days.

4 days is basically an introduction.

Here is my thoughts about PLCs at day 3 of learning, from the point of view of software/firmware developer, a list of things I made for myself, to share with other newbies. It is mostly conclusions, not the direct content of what they teach you.

1. No fancies there in a languages (ladder language, plain text, diagrams etc. they are all about the same)

There is actually a language standard for PLC's.   In some cases though you can make use of C type languages or at least you could, there is little demand for that.   Also it isn't uncommon for a plug in module to run a different language.   At one time BASIC co-processors where a thing.   

2. No pointers
3. No stack (nearly everything as parameter is passed by value, may be using stack after all, but hard to tell)
[/quote
]Not exactly.   Depending upon how the boolean processor is implemented it may be using a stack.   In the old days you could run out of stack room pretty easy.

4. No loops (they are there, but not recommended, I mean loops like FOR, WHILE, REPEAT UNTIL)

One of the key concepts that needs to be understood with respect to PLC's is that you are in fact executing a non stop loop.   As for loop instructions I don't know why they would tell you they are not recommended.   Like all thisng programming it depends upon the problem at hand if it makes sense to use such instructions.

5. No strings (not recommended, unless you really need it)

I'm not sure why this is stated this way.   You don't need strings for machine control in the sense of solving the relay logic but stings can be very useful for communications.

6. No heap
7. No dynamic allocation, deallocation
8. No exceptions (except may be divide by zero or similar)

Maybe no user exceptions (probably a good thing) but many controllers do generate errors that you may or may not have control over.

9. No jumps or goto (can be used but explicitely not recommended)

I'm pretty sure many controllers implement some sort of jump.   Again I'm not sure why they are teahcing you that they are not recommended.   Like all things there are places where jumps make sense.

10. No need for code address labels, since no goto

However the rungs are numbered.   Mentally this is important as you may be moving constantly between rungs when debugging.

11. No ends, returns, exits or halts. The scanning keeps looping forever.

Exactly there is an implied loop that does not stop at all.

12. No stepping, so no debugger, only monitor

Actually any decent PLC programming software is a debugger.

13. No breakpoints
14. No OS or kernel or framework, it is true bare metal

In the vast majority of cases there is a real time kernel supporting all of the magic.

15. No error handling since it is not an OS
16. No tracing outputs, only monitoring (or I did not lean it yet)
17. No threads

Maybe not in the conventional sense.

18. No locks since there is no threads

So what you have ? So far it looks like a sort of pre FORTRAN with only static manual allocation of DATA and CODE.

Not really!   The concept of a PLC started out in the auto industry as a way to emulate complex relay logic and sometimes card logic controllers.   In effect they visualize the control panel.   FORTRAN fist cam on the scene in 1957, Modicon produced the first PLC in 1968 so technically FORTRAN is older.   However what a PLC does is recreates the machine control logic that is decades older.   Imagine if you will a period of time when transistor did not exist.   When I was new to the industry in the late 1970's there where machines built in the 50's with not a transistor in sight.    Even timers where electromechnical and to this day PLC software emulates how those old timers worked.

I hope this is helpful for software minded people who wonders what PLC actually is.
It is not a criticism, but just an observation how much of usefulness one can get from programming, when everything unnecessary is removed.
ha ha.

PLC's are cool no doubt there.   The problem is sometimes control engineers get wedded to the controllers and implement systems that might be better done on a PC or industrial computer.   However there is one huge advantage to PLC's that you might not grasp until you have an entire production line down for a problem.   That is they are extremely handy for debugging an issue in ways that can't easily be accomplished with conventional programming.   In effect you can have a technician or even an engineer, with little exposure to the code be able to do diagnostic work.   It is the ability to see what is happening in a way that can not be done with software written in C on a PC (without a lot of infrastructure created).   In other words you get a lot of debugging capability for free with a good PLC IDE, that is very oriented to machine control.

Edit: And the good news is that you need nothing, just a bunch of relays to build civilization upward from the complete disaster, just by using PLCs alone.

Actually PLC are one of the reasons that we have the civilization we have today.   Without this invention it would not have been possible to drive the mechanization of industry, in the way it was.   If an EMP spike where to take out all of our PLC's today, tomorrow would be looking very sad indeed.

As a side note one of the first PLC's I worked on was the 5TI system from Texas Instruments.   The controller supplied with the machine had 256 bytes of storage.   Note the lack of a K there.   

[mfro]

PLCs do have everything you mentioned missing (including fatal bugs, sometimes).

It's just they don't let you access it.

[Berni]

Yeah deep down the PLCs still do a lot of programmery stuff, but its hidden away as much as possible from the user.

Its the PLCs OS that is doing all the magic while running on just a regular MCU in there. The user software that is loaded on there is almost always ran as an interpreter. It is the PC software job to turn whatever you created into the PLCs proprietary byte code that then gets loaded in. But yes this intermediate language that the PLC is executing is typically designed to work with a stack made to easily represent ladder diagrams.

And yes while you don't have directly debugger access to the CPU, but any decent PLC has high level debug functionality (Provided by its OS and the PC software). Its possible to see ladder diagrams light up like a christmas tree with signals flowing trough them live. Its possible to stop it at any point. Its possible to see memory fields changing in real time. You can force signals to high or low, write into variables...etc. This is incredibly useful in tracking down problems, be it in the software logic, or just looking at the PLCs inputs to troubleshoot a wonky sensor.

If you ever try to run any more advanced modules on a PLC such as fancy analog cards or VFDs you will see that it looks a lot like programing a peripheral on a MCU where you configure and give it commands by writing to memory registers.

But yes in general the way PLCs are programed is to make it more difficult to mess things up accidentally while at the same time the jobs that PLCs do are generally very simple. They typically just repetitively run a machine trough a work cycle or regulate some process values. Things too complex for just a few relays, but not complex enough to require a full on computer. You don't use a PLC to run a CNC machine or 3D printer or heck a chess playing robot.

[rstofer]

In the beginning...

Machines were run with relay based control systems and it is darn difficult to create a Finite State Machine with relays.  In some cases we used stepper switches.  This worked well if the sequence was relatively linear, step by step.  I was working on relay control systems in the aerospace industry back in '69, fully 10 years before C was invented.  At the time we would probably have used an IBM 1800 minicomputer and a rack full of addons if we wanted to use computer control.  Too expensive and too hard for electricians to deal with FORTRAN.   In those days, the alternatives were COBOL or assembly language and assembly might have been the easiest.  But for ordinary electricians?  No chance!

The IBM System 7 was just being introduced.

Take a simple machine, a riveter, for example.  There is a sequence start signal that tells the positioner to move the fuselage panel to the next rivet position.  This was set up with a template and photo sensors running on rails attached to the floor.  The template had multiple lines of holes, one for each stringer on the panel.  Remember, these panels are probably 20 feet long and 10 feet wide, more or less.  Once the horizontal position is achieved, the panel is leveled using pneumatic gauging devices.  The panel is a 3D shape, not a simple flat sheet of aluminum.

Eventually the panel is in position and level.  Raise the bottom ram and lower the clamp then drill the hole and dwell to clean it out.  Retract the drill and, in some cases, position a squirt tube over the new hole and apply some paint.  Retract the squirt tube.  Now move the rivet inserter mechanism into place and place the rivet.  Hold the rivet head down tight with the upper ram and upset the rivet with the lower punch.  Retract the rivet tooling and unclamp the part. Move to the next hole.

Rinse and repeat for weeks on end times 4 machines.  BTW, everything was hydraulic except the sensors.

I never counted the number of relays but there were probably 50 DPDT ice cube relays in the main machine and another 20 or so industrial relays in the positioner.  On a good day they all worked.  Oh, let's not forget manual step-by-step operation from a control panel along with some switches and lights.  Lots and lots of IO points but we didn't call them that.  Obviously, there was some interlocking to consider.  We couldn't unclamp if the upper ram was down, things would break - violently!

The ladder diagram was about 36" wide and over 30 feet long.  We rolled it out on the shop floor when we had to troubleshoot something.

I was on that program for nearly a year!

All of this could be done with a relatively small PLC and a bunch of IO modules.  There would probably have to be intermediate relays to handle the current of the various valves and actuators but they wouldn't be involved with the logic.  PLCs were brand new and Allen Bradley probably had the best.  We were an AB shop anyway - all of our controls, including the GE Mark Century NC controls, were required to use AB relays!  I'll bet GE loved that...

Some time around '71, another engineer decided to use Dow Corning Fluidics modules to create a machine control.  I give him points for originality but an 'F' for maintainability.  Electricians don't work with air controls and plumbers are, well, plumbers.  Still, it was interesting.  Corning had logic gates and flip-flops so, in theory, you could build an entire pneumatic computer.  There were operating environments where this would be handy.  The machine shop floor probably wasn't the place.  Diagnostics of air flow is another issue - it's sort of hidden.  You can't stick your Simpson 260 probes in there and tell what is happening.

https://en.wikipedia.org/wiki/Fluidics

Electricians (and most electrical engineers) prefer ladder diagrams and the ability to program PLCs in ladder logic.  I have come across some PLCs that actually force the programmer to write the expression for each output in terms of RPN logic.  That's great if you know how to do it (and I do) but it's a lot like programming an HP calculator.  The logic printout doesn't look at all like the ladder diagram!

Diagnostics and debugging favor the PLC over relays, no doubt about it.  Adding another relay is usually as easy as adding another IO module (if needed) and writing the ladder rung.  If you run out of IO space, add another chassis! 

I'm really fond of GE Fanuc controls and have used them in a number of non-machine applications including power monitoring over 26 unit substations all tied to the GEnius bus.  Very cool stuff!

My last project, about 20 years ago, used one of the Fanuc man-machine interface panels with a touch screen.  That was a very nice control system!  At the time, I thought this was the future of control systems.

I expect PLCs in one form or another to be around forever.  They are simply the best way to build machine controls.

[tszaboo]

They are meant to do tasks, that a trained monkey can do.
" Tank almost empty, must fill tank"
" Tank almost full, must stop filling tank"
So yeah, thats not the point. The point is this:

And if you need to read a ethernet connected profibus  level sensor, and control a valve with a mirocontroller, good luck.