> For the complete documentation index, see [llms.txt](https://infosys.selmotech.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://infosys.selmotech.com/selmo-solution/selmo-solution-en/engineering-through-the-ages/1968-when-logic-left-the-circuit-diagram-birth-of-plc-programming.md).
# 1968 β When logic left the circuit diagram Birth of PLC programming
In 1968, Dick Morley invented the first **PLC** β a turning point in automation.
* Goal: replace relay circuit diagrams with **programmable logic**.
* First language: **Ladder Diagram (LD)** β a reflection of relay logic.
* Later: IL, FBD, SFC, ST β standardized in 1993 in **IEC 61131-3**.
But:
* Manufacturer dialects remained,
* programs are hard to read,
* documentation is inconsistent.
π The **clarity of circuit-diagram logic** was sacrificed in favor of flexibility.
Before 1968, logic was **visible in the circuit diagram** β any electrician could understand processes.\
After the PLC was introduced, the logic moved into **software programs**.
* Flexibility and modifiability increased.
* But the **documentation lost clarity**.
* Today, documentation often means: *βCall the programmer who wrote it.β*
π 1968 marks the break: **Logic was decoupled from the standard language of electrical engineering.**
Historical development of machine logic
### 1. Before the PLC (until approx. 1968) β **logic in the circuit diagram**
* Machine control via **relay and contactor technology**
* Every logical function (AND, OR, NOT, interlock, self-hold) β **physically wired**
* **Documentation in the circuit diagram** β unambiguous transparency:
* contacts = conditions
* coils = results
* signal flow β immediately readable for any electrician
* Advantage: **Logic was clear, traceable, documented**
* Language: **circuit diagram = electrics + logic**
***
### 2. The invention of the PLC (from 1968) β **flexibility instead of clarity**
* First **programmable logic controller (PLC)** by Dick Morley (Modicon 084)
* Goal: replace relay wiring with **flexible software**
* First language: **Ladder Diagram (LD)** β direct reproduction of the relay circuit diagram
* Advantages:
* Changes without rewiring
* Space and material savings
* Disadvantages:
* **Logic disappeared from the circuit diagram**
* Documentation only in the program β manufacturer-dependent
***
### 3. Standardization and language diversity (1980sβ1990s)
* Introduction of new programming languages:
* **IL (Instruction List)** β text-based
* **FBD (Function Block Diagram)** β graphical
* **SFC (Sequential Function Chart, GRAFCET)** β stepwise logic
* **ST (Structured Text)** β high-level language
* **IEC 61131-3 (1993)**: worldwide standardization of these five languages
* Problem: **manufacturer dialects**, lack of formal unambiguity
***
### 4. Today (2000sβ2020s) β **complexity without a clear language**
* PLC programs are powerful, but:
* hard to read for outsiders
* Documentation often incomplete or not standardized
* Logic is distributed across LD, FBD, ST, SFC, data blocks, etc.
* **Forgotten:** That logic used to be **clearly documented** β in the circuit diagram itself
* Consequence: **Clarity and competence were lost in favor of flexibility**
***
### 5. Future β **formal language for machine behavior**
* What is needed is a new, **formal, deterministic language** for machine logic,\
comparable to:
* **technical drawing (mechanics)**
* **circuit diagram (electrics)**
* Objective: **Unambiguous, globally understandable, standardized description of machine behavior**
* β Approach: **model-based methods (e.g., Selmo)**
***
#### Overview: Three languages of engineering
| Discipline | Earlier | Today | Status |
| ---------- | --------------------------------- | ----------------- | ---------------------------- |
| mechanics | Technical drawing | Technical drawing | clear, standardized |
| Electrics | circuit diagram (including logic) | Circuit diagram | clear, standardized |
| Logic | circuit-diagram logic (relays) | PLC programming | flexible but not unambiguous |
***
π This makes it clear:
* **Earlier** logic used to be part of the clear electrical language (circuit diagram).
* **Today** now it is flexible but not unambiguously documented.
* **Tomorrow** we will again need a **formal, standardized logic language** β as the third pillar alongside drawing and circuit diagram.
Historical course PLC
* **1968**: Dick Morley develops the first PLC (Modicon 084)
* **1970s**: Ladder Diagram (LD) β graphical like relay logic
* **1980s**: IL, FBD, SFC β more expressiveness
* **1993**: IEC 61131-3 defines five languages (LD, FBD, IL, ST, SFC)
* **Today**: languages standardized, but dialects and lack of transparency persist
Historical course logic
* **Before 1968**: relay circuits β logic documented in the circuit diagram
* **1968**: PLC replaces relays β flexibility rises, clarity decreases
* **1990s**: standardization IEC 61131-3, yet no real βlanguageβ
* **Today**: dependence on programmers, lack of formal traceability
Logic before the PLC
#### 1. Logic in relay technology
* Before the PLC existed, machines were controlled with **relay and contactor circuits** controlled.
* Every logical linkage (AND, OR, NOT, self-hold, interlock) was **physically wired**.
* The logic was directly **documented in the circuit diagram**:
* Relay contacts = logical conditions
* Coils = logical outputs
* Linkage in the diagram β immediate logical function
* Advantage: **100% transparency**. Any professional could immediately see from the circuit diagram how the machine works logically.
#### 2. Logic as part of the circuit diagram
* Until the 1960s, the circuit diagram was **the document for mechanics *****and***** control logic**.
* One could understand how a machine works from the circuit diagram alone.
* Thus, logic has always been a **describable and documented language** β as unambiguous as the technical drawing for mechanics.
#### 3. The break with the PLC
* With the introduction of the PLC (from 1968), logic was extracted from the circuit diagram and **shifted into software**.
* Advantage: high **flexibility** (changes without rewiring, modular programs).
* Disadvantage: loss of the **Documentation transparency**.
* The logic is no longer visible in the circuit diagram.
* Different programming languages (LD, FBD, ST) and manufacturer dialects make readability more difficult.
* The clear competence of electrical engineers, who used to be able to trace everything in the diagram, was displaced.
#### 4. Consequences to this day
* Many today see logic only as part of a PLC program β **forgotten is that logic has always had a clear, documented description**.
* Thus, the **break between electrics and software** arose.
* Where previously **drawing (mechanics) + circuit diagram (electrics + logic)** represented the whole, today the **unambiguous, formal language for control logic**.
***
### The arc: three languages of engineering
| Domain | Language (earlier) | Language (today) | Problem |
| ------------- | ---------------------------------------- | ----------------- | ------------------------------------------------ |
| **mechanics** | Technical drawing | Technical drawing | stable, clear, standardized |
| **Electrics** | circuit diagram (including logic) | Circuit diagram | stable, clear, standardized |
| **Logic** | circuit-diagram logic (relays, contacts) | PLC programming | Flexible, but no longer unambiguously documented |
***
### Conclusion
The **Logic** has always been **part of the language of engineering** β visible in the circuit diagram, unambiguous and documented.\
With the PLC it became more flexible, but at the same time **invisible and inconsistent**.\
Today it is largely forgotten that historically logic was described just as clearly as geometry and electrics.
π The task for the future is to **restore formal clarity** β with a universal, model-based language for the **behavior of machines**, comparable to the drawing in mechanics and the circuit diagram in electrics.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://infosys.selmotech.com/selmo-solution/selmo-solution-en/engineering-through-the-ages/1968-when-logic-left-the-circuit-diagram-birth-of-plc-programming.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.