3

Trying to figure out the best way of controlling industrial PLC's with Raspberry Pi/linux server - specifically using python and pymodbus (modbusTCP) over ethernet...

Once the PLC internal registry is mapped properly to modbus, can software written in python take the place of ladder logic programming in the PLC and control it completely?

Or will ladder logic/ native PLC code still need to be written?

user3300423
  • 33
  • 1
  • 1
  • 5

5 Answers5

7

You should not replace PLC logic with your linux server. You need real time OS for that. Even running real time OS and controlling PLC with it is a bad idea. PLC-s have all kind of checks built in for controlling inputs/outputs, program cycle, internal diagnostics and so on. They are a tool meant specifically for that task. IMHO ladder logic is easier to learn than real time OS.

You should use your server as HMI - human machine interface, that sends control data to PLC and displays it back to the user.

If your project is for learning experience or personal project then you should of course do whatever you feel like.

user3597496
  • 180
  • 1
  • 9
  • 2
    Thank you for your expertise. It is starting to make more sense to me. To summarize, the linux server would communicate through python periodically only to change settings on the PLC program (speed, turning degrees, etc.) or get status updates/data, but the ladder-logic program and real-time OS on the PLC would be doing all the heavy lifting. When the linux server sends control data to the PLC, the available control options will be pre-determined by the ladder-logic program running on the PLC, correct? – user3300423 Jan 23 '16 at 19:50
  • I have one contradict question to ask you. Raspberry PI has a quad-core processor. If RTOS comes in the picture, RPi cannot replace the PLC then it is wrong. You should manage the processing power and strong memory management then it will run on industries. Could you possibly give the full explanation Why RPi cannot take place of PLC? – Hacker Jan 03 '19 at 05:54
  • 1. Factories usually want some kind of guarantee, that spare parts, programming know-how will be available for tens of years. Kind of like big companies like Microsoft and Oracle. 2. PLC-s are modular. You have modules for pretty much all kinds of inputs: digital, analog, voltage, current, encoders, cnc, various communication protocols... the list goes on. 3. You can't reliably write your own RTOS that has all capabilities of PLC. It's herculean task. 4. Safety. In recent years, before i left automation world, PLC-s had built in safety features, that were certified. 5. Debugging. – user3597496 Jan 16 '19 at 10:41
1

I don't know if you can do this in the specific configuration you are discussing; in fact you don't say which PLC you are using so I doubt any respondant can tell you.

But under the assumption you can technically connect the pieces, you will probably discover the performance is not adequate to really carry out reliable mechanical control.

Normally PLCs run through their program hundreds of times per second, each time sampling inputs and computing new outputs. This is fast enough so mechanics effectively see "smooth" control. (5 Hz would likely cause mechanical chatter and jerky movements of hardware).

If you "involve" Python to compute that, somehow you have pay bus communication times to/from the PLC to the Python, the Python wakeup time, Python execution time, and Python message packing/unpacking time. I doubt you can achieve all of this at several hundred times per second reliably (what happens when the OS interrupts Python to write 10M of data onto the disk for some other background process)?

If you insist in involving Python somehow, it should act only in an advisory role. That is, the PLC does all the work (e.g., you need that "ladder logic/..." to be written) but the Python code sends occasional messages to the PLC to change its overall behavior, e.g, control mode, feed rates, etc.

Ira Baxter
  • 93,541
  • 22
  • 172
  • 341
  • Thank you for your answer. I'm starting to see the light. I apologize for not stating which PLC - the model of PLC has not been decided, but Automation Direct is being considered. Is modbusTCP not a universal method of communicating with any PLC of any spec/make? Are the advantages of direct communication (i.e. Step7 on Siemens PLCs) significant enough to switch? – user3300423 Jan 23 '16 at 19:58
  • I doubt if choice of PLC makes any practical difference. All the vendors have some type of PC integration at this point; they may be configured differently and have different APIs, but the net result is the same: somehow the PC and the PLC can exchange information about the data held by the PLC. Whether Python will talk to that API easily depends on the API; Python is its own world (I think it has access to C code somehow and that I'm sure would interface). I suggest you read the literature carefully, and maybe talk to an application engineer. – Ira Baxter Jan 23 '16 at 20:23
1

This video looks like a good place to start:

https://www.youtube.com/watch?v=EAXJ_3dfeNI

I would personally write all of my machine control code on the PLC. I would then share the status of my variables through ModbusTCP with the Pi to do whatever else

tkezy
  • 162
  • 7
1

Well let's assume that you have really efficient code. And you created some dictionaries, did some lambda. You can cycle through a logic set of 2000 IO points in 5ms.

I do this in Lua everyday. PLC hardware is FPGA based. But never scan faster than 10ms. Using data slows them down. And usually end up at a 25ms scan.

Python and Lua programmed correctly can scan at 1-2ms over 2600 lines of code.

You need a C wrapper to run the scan. Use TCP modbus devices. And never more than 32 IO per IP address. It's actually very easy.

Those who do not know PLC's or only know PLC's will steer you in the wrong direction. Do your homework. Learn Lua. And then prove them wrong.

Hope that helps.

Don Bozarth
  • 11
  • 1
0

You can experiment with your PLC logic in Python using:

https://github.com/QQuick/SimPyLC

And then generate C++ and use an Arduino to run it in realtime.

But only use this for non-safetycritical projects. It is not suited for anything that can cause damage or injury. And always test your eventual real PLC code rather than relying on the Python tool for correctness.

Jacques de Hooge
  • 6,750
  • 2
  • 28
  • 45