2

I come from a C/C++ background, a lot of which has been in an embedded systems context. None of those embedded systems have involved PLCs - it had never make sense to have one CPU doing all it's C/C++ logic, then surrendering control of the I/O to some other device when (usually) you could just do it yourself because the I/O was directly connected to your CPU.

With the advent of EtherCAT, we are seeing advantages in moving our I/O onto EtherCAT for its flexiblity, modularity, etc. However, the preferred mode of driving a lot of the EtherCAT hardware seems to be via a PLC. In the case of the Beckhoff TwinCAT PLC environment, trying to bypass the PLC seems to be either technically difficult or expensive or both.

Which makes us want to know a lot of things about PLCs... starting with:

  • is it best to think about them as a serial processing device, parallel processing device, or neither (does it depend on the specific device)?
  • are they a "Turing Complete" general purpose computing device, or do they have limitations?
  • do they run the entire PLC program (loops and all) every PLC cycle?
  • if the PLC I/O is not controlling some industrial process under the supervision of a maintenance department, and/or takes place on millisecond timescales, might those be good reasons to make full use of more modern programming techniques (structured text rather than ladder diagrams, for example), in contrast to advice in the likes of this answer?
Community
  • 1
  • 1
omatai
  • 3,448
  • 5
  • 47
  • 74

2 Answers2

3

Just to cover both interpretations of serial and parallel -PLC logic processing is sequential.

Most PLC's can be programmed via Serial, USB or Ethernet connections

As regards to devices that PLCs' connect to, they are usually serial. For instance many industrial control system networks uses Profibus which is a serial bus based communication - typically Profibus uses the RS-485 serial interface. I can’t really think of a place where I have seen parallel communication. Most are serial - MODBUS, DeviceNet etc....with parallel you have problems with the extra cost of cabling, noise, long distances etc.

Yes PLC languages are Turing complete but probably not as convenient as other programming languages. For example with a Siemens PLC you have a choice of how you implement the logic - Ladder, S7 Graph (these are graphical based), Statement List (instruction based), Function Block Diagram, Structured Control Language (similar to Pascal). This is a nice article comparing PLC programming languages with guidelines for how to choose a language http://www.automation.com/pdf_articles/IEC_Programming_Thayer_L.pdf

The PLC scan time is the time taken by a PLC to read inputs, execute the whole program and based on the logic just processed update the outputs accordingly. PLC scan time is not deterministic as it depends on inputs, outputs, timers, memory etc. Usually PLC's are used where speed is required - for slower processes DCS's can be used. It would be usual to see execution times of between 4-6 ms. With most PLC's you can modify the default maximum cycle monitoring time. If this time expires, the CPU can be commanded to stop or an interrupt can be triggered with the required logic. Note in many cases greater then 1 second scan time is "undesirable"!

I have found that in my experience that nearly all of the PLC's I have worked on are never composed of simple ladder logic networks. PLC’s are not simple representations of physical relays. They are used to control intricate often safety critical processes interacting with a multitude of different devices/equipment. Also in the majority of cases you have a SCADA system to implement and you may have enterprise level applications (MES,ERP) system to consider. Many processes require complex scheduling and logic control algorithms -- vial filling, bio pharma, electrical, oil & gas….there is a long list. As per the above link it depends on your need but modern processes often dictate the need for more then a simple program composed of a few ladder networks

A Murray
  • 421
  • 1
  • 9
  • 15
0

More "modern" programming language (actually ST is more modern than C) often means also more complexity on the program, which is something that should be avoided in the PLC world. They are Real Time machines, where the cycle times, maintainability, robustness and clarity are far more important than regular PC (which are not RT) and embedded world. If PLCs would be programmed with same way as most handheld devices, we would be living in the world where having lights on would be totally random act, since the powerplant just tilted because of programming bug.

A Murrays answer is better than I would ever write, but since I can't comment yet I wanted to underline these parts I wrote here.

V.Tile
  • 1
  • 1