[Closed] PLC programming.

I did some PLC stuff a few years ago, but glad I don't have to do it anymore. Just too different from modern programming. I also used an Arduino based industrial device, so much easier (if you already use one).
Unless you use a PLC, I'd not bother trying to learn how to program them.

don't know but interested! Whenever anyone on the Arduino groups mentions using one for industrial/mission critical stuff they are laughed off the boards and everyone yells "PLC!" but no-one really explains [I]why[/I]! I have never had an Arduino crash or fail, they're cheaply made devices though so I suppose one could just die! Which Arduino-based devices do you use @richmars?

Equally I've never had a Pi just fall over, but they're definitely over-complicated if an embedded processor would do.

PID theory - lots of relatively easy to understand graphs and difficult to understand laplace transforms

PID reality - hit autotune and make educated guesses from there.

Unless you use a PLC, I’d not bother trying to learn how to program them.

this is the thing, we have them in some of our kit, and currently have it as a bit of a financial block to try out novel ideas for specialist land remediation work.

if it breaks in use, it's never going to be a life or death matter, and arduino is cheap so easily replaced.

bear in mind that no one currently has experience of programming PLC's (or arduino for that matter, that I'm aware of) which is why I'm thinking something relatively easy to pick up and isn't as fickle as basic on a ZX81.

I think it was an Industrial Shield, something like RS 885-0945.
PLC's are pretty bomb proof, which is why I used one, but the assumption is the software is correct. It may be less risky to use something that is easier to program and debug.
The PLC I used was from IMO, something like RS 847-4730.

I’m thinking something relatively easy to pick up and isn’t as fickle as basic on a ZX81.

PID reality – hit autotune and make educated guesses from there.

Funnily enough this is how we teach it for BAS! Have a few wild stabs at prop, and check the log.

I have done a fair bit of programming PLC (several systems) and normal programming (C++, C#, python, C loads of others on little bits and bobs). Message me if you want more information.

There are many advantages to PLC depending on the system you choose, and the system you choose is quite an investment due to the specifics of each system.

PLC isn't "programming", it's relay logic in software.

You could buy one of the cheap and nasty ones from eBay to experiment with - they're only about twenty quid, or there are countless ladder-logic simulators you can take a look at.

I've got to be honest and admit that I'd rather gnaw off my own testicles than get involved in ladder logic again.

Depends what you want to do?

Sort out the low level control logic and keep the process running - maybe plc programming.

Tune the PID controllers - you need to understand control theory, work out what you want then hand the parameters to the PLC programmers.

Change settings on the plc dependant on other factors - you probably want level 2 control adjusting setpoints etc. and sending them to the PLC.

Needless to say any change to any of these systems always needs risk assessment. Might seem overkill for a domestic heating system but this is sort of the way it works from domestic heating to complex petrochemical plants.

Well that's my view as a mechanical engineer trying to get these things sorted and improvement projects done! Don't know whether that is any help though. As above get a cheapo PLC and have a go with it. It's based in simple ladder logic and should be robust in programme execution. Just always take care with understanding what you are potentially controlling first, second and last! The controllers are just another cog in the machine.

A typical setup may be something like this:
Maintain a setpoint level in a borehole using a pressure transducer downhole 4-20mA most likely, controlling a pump frequency controller.
That alongside high level triggers in receiver tanks to switch off, then switch on pumps.
Now, this can be done using a pump controller, and a load of float switches, but it's quite restrictive if you also want to add in other controllers like flow rate.
Other thing we've been looking at is pump control either via level, or flow, programmable steps, recording of flow, pressure, level, pump frequency %effort.
So, that type of thing.
To my mind it's relatively simple logic, the pump control will have some PID, but it may just be a bit of P, but may be more, depending on the recharge characteristics of the aquifer over time.

I do PLC stuff on Allen Bradley and Siemens S7 for massive PU plants on COMAH sites.

The upside is massive reliability - I have an AB SCADA system that hasn't been touched in 9years and prior to that a Siemens S5 that was 25years with rock steady reliability.

The downside is you need to keep an eye on obsolescence - we let a really complex Siemens S5 system go on for too long which then cost us £350k to upgrade. The 9year system above is coming up for review/possible renewal.

Programming is fine if you come from an electrical engineering background - it's only inputs/outputs and a bit of twiddling around inside the PLC.

Regarding PID/closed loops - I distribute that control out to a dedicated bits of kit, for example temp control of polyols is crucial via plate heat exchangers, I have a dedicated PID controller operating the water valve feeding the PHE's. It's given an analogue signal and does its own thing. Same with motors and drives - don't bog the PLC down with stuff that can be distributed out.

I'd recommend getting hold of a Siemens LOGO starter kit. I get them for my apprentice's at work. They allow you to 'see' the Boolean logic at work by 'dragging' wires around the software.

Arduino and Pi's are toys still.

PLC isn’t “programming”, it’s relay logic in software.

That 's a very very outdated view of PLCs.

It can be just relay logic or it can be full on programming. There is even an effective universal assembly code within one of the 5 iec languages. I've done network programming, dealing with xml etc, path simulations, 3D vector calculations etc. Its full featured. Its seems to be mainly the yanks that think PLC = ladder logic.

P.S. On that note if you can avoid it unless its a customer requirement I would recommend avoiding ladder logic. Depending on the problem sequential flowchart programming or function block programming is good for the high level stuff that field engineers can plug in and diagnose what step / block is in error then keep anything complex within that block written in structured txt or if your PLC provider is a bit rubbish instruction list if you have to.

Same principles apply as to normal programming. Don't end up with one massive bit of code, abstract away functionality, separate functions, etc.

To my mind it’s relatively simple logic, the pump control will have some PID, but it may just be a bit of P, but may be more, depending on the recharge characteristics of the aquifer over time.

It can be but there can also be caveats. PID falls down in some situations. E.g. significant lag and its better to model and control the system yourself.

don’t bog the PLC down with stuff that can be distributed out.

I'd say that depends, as with most points of engineering on the use case and the PLC, also the industry you work in standard ways. As I am sure you're awear some guys in industry are very conservative...

don’t know but interested! Whenever anyone on the Arduino groups mentions using one for industrial/mission critical stuff they are laughed off the boards and everyone yells “PLC!” but no-one really explains why!

1. Reliability.
2. Lego like construction for extra IO and even CPUs. Not just IO, drives as well (this is a big one)
3. Test and certified for various environments.
4. Industrial standard 24V.
5. Standard systems for service engineers to go online and diagnose basic issues.
6. No expensive electronics development. You have abstracted that level of design away. Just choose the correct card with correct sample rate, bus, voltage etc.
7. Integration into safety systems. (Which is a hole different ball game from safety relays to safety PLCs, everything has a rating and has to be certified and documented in a steema file ).
8. Speed of development. On site you can be swapping adding changing system quite extensively as mechanical and electrical issues are found its its the person on the end of the line (software) has to deal with these changes. (and it works the other way too)

There are more subtle one and of course some case it could be better to go down the microcontroller route but less so when developing large one off, lower number machinery. he underlying CPU can vary as well from little 16bit muc where you have to consider where you put io to the correct hardware address just like bare bone muC to industrial computers that are rugged desktops, just panel mounted and everything in-between.

Maintain a setpoint level in a borehole

If there are is any potential safety implication from the performance or non-performance of the system then then may steer you down a particular path. The ability for auditing of the code is also then a factor.

don’t know but interested! Whenever anyone on the Arduino groups mentions using one for industrial/mission critical stuff they are laughed off the boards and everyone yells “PLC!” but no-one really explains why!

I've been using Arduinos for work stuff for about 10 years. No issues (yet), my stuff tends to run 7 days a week and is used by members of the public who will do what they can to make things not work. They are ideal for me as they are so versatile but I can see some issues for industrial use. It would be very hard for someone to come to one cold and work out what is going on and do fault finding, and without a copy of the software probably impossible. If used correctly reliability is not an issue but they don't have much in built protection if something else goes wrong.

This takes me back!

In a previous career I did lots of design and programming of PLC's... from their fairly early days, through until about 2009. Used to favour Siemens S5 and S7 (Can't remember the name of their little stand-alone blocks) and lots of Mitsubishi kit.
Used them from really simple "Finishing shop" applications, right through to larger networks that fed multiple lines of robots. Used to enjoy the HMI side of things too... (Enjoy is the wrong word!).
Still have a couple of old Mitsubishi FX's controlling lights and things around the house 🙂

Its seems to be mainly the yanks that think PLC = ladder logic.

To be fair I was doing it straight out of uni 15 years ago using software that would only run in DOS.

I did actually look into it again recently when I was asked to replace a water control system but it was easier to use an ESP8266 and a bunch of relays on a custom PCB from China than to go down the PLC route because it needed GSM control.

(Five boards + components were cheaper than one PLC and my sanity in programming it. Reliability not an issue - if it breaks or gets zapped by lightning there are 4 spares which have a single connector and clip onto a DIN rail).

it was easier to use an ESP8266 and a bunch of relays on a custom PCB from China than to go down the PLC route because it needed GSM control.

I did actually look into it again recently when I was asked to replace a water control system but it was easier to use an ESP8266 and a bunch of relays on a custom PCB from China than to go down the PLC route because it needed GSM control.

I'd agree for that I'd do esp32 (or similar) as well but for a industrial machine, PLC in most cases.

Nice thread! I have done bits of PLC programming, granted it was 15 odd years ago and it was DOS based. It has moved on massively. I'm a technical sales engineer for a sensor company and things are moving at a great pace. Currently looking at MQTT/IO-Link/OPC UA cloud based solutions. Didn't think we would be at this point with sensors 20 years ago.

For PID, would a dedicated PID controller not work?

Currently looking at MQTT

Yea, it's very good when implemented correctly. Big step up from OPC UA.

In the sensor world, it takes text info from the sensor IODD file (from IO-Link world) for conditioning and monitoring. You can live track what your sensors are doing, levels in tanks etc, sensors on conveyor lines. Your sensors are connected to a master, and that then works on a server/client basis.

In the sensor world, it takes text info from the sensor IODD file (from IO-Link world) for conditioning and monitoring. You can live track what your sensors are doing, levels in tanks etc, sensors on conveyor lines. Your sensors are connected to a master, and that then works on a server/client basis.

That all sounds like a huge security risk, particularly when none of these sensors were presumably designed with online security in mind.

Yes, security is an issue, but can be solved. IO-Link itself is at the bottom of the hiearchy, and is point to point comms (serial, basically). MQTT is making use of it. But security solutions are out there, like for many cloud based solutions. I've just done some basic training on MQTT, using free demo software to access the sensors sitting on my desk. Basic passords etc can be set-up easily. I understand proper security goes way beyond that.

I did actually look into it again recently when I was asked to replace a water control system but it was easier to use an ESP8266 and a bunch of relays on a custom PCB from China than to go down the PLC route because it needed GSM control.

Even low end Siemens LOGO has GSM control for very little cost with expandable IO including relay modules and is an absolute doddle to program.

I have an early LOGO monitoring tank levels and has been running constantly for +10years now. Another moves a massive linear actuator mounted mixing head with limit detection via a small HMI operator panel, again bulletproof for circa 15years.

https://www.automation24.co.uk/gsm-gprs-communication-module-siemens-logo-8-cmr2020-6gk7142-7bx00-0ax0

https://www.automation24.co.uk/logo-mini-controllers

I remember trying to sell the Mitsubishi Alpha programmer in place of basic PLCs, for basic jobs. But it never took off. People didn't seem to want to embrace a slightly different way of doing things, ladder vs boolean, and they thought the hardware was much inferior. It was so much cheaper, too.