Category: Technology

A Programmable Logic Controller (PLC) — known in German as an SPS (Speicherprogrammierbare Steuerung) — is the small industrial computer that quietly runs most of the machines and buildings around us: conveyor belts, water treatment plants, HVAC systems, elevators, and production lines. Unlike a general-purpose computer, a PLC is built to survive vibration, heat, dust, and electrical noise, and to run the same control logic reliably for years without a reboot.

At its core, PLC programming is about describing behavior: when this sensor triggers, do that; if this condition holds for five seconds, switch on that motor; if a fault occurs, shut everything down safely. The IEC 61131-3 standard defines five programming languages for this purpose, and most engineers specialize in one or two:

• Ladder Diagram (LD) — resembles electrical relay diagrams, intuitive for electricians transitioning into automation.
• Function Block Diagram (FBD) — graphical blocks wired together, popular in process and building automation.
• Structured Text (ST) — a Pascal-like text language, useful for complex math and logic.
• Instruction List (IL) — a low-level, assembly-like language, now largely legacy.
• Sequential Function Chart (SFC) — models step-by-step processes, ideal for batch and sequential operations.

In practice, a real project blends these: SFC to structure a sequence, FBD or ST inside each step to handle the details. Platforms like Siemens TIA Portal, Beckhoff TwinCAT, and CODESYS dominate the field, each with its own ecosystem of function blocks, diagnostics tools, and simulation environments.

What separates a working PLC program from a good one is discipline: clear naming conventions, modular function blocks that can be reused across projects, proper interlocks and safety logic, and documentation that lets another engineer — or your future self — understand the logic six months later without guessing. As industrial systems increasingly talk to SCADA systems, cloud dashboards, and building automation networks like KNX, the PLC is no longer an isolated island; it’s a node in a much larger, connected system, and its code has to be written with that integration in mind from day one.

Walk into a modern office, school, or well-renovated home in Europe, and there’s a good chance its lighting, blinds, heating, and access control are all speaking the same language: KNX. Unlike proprietary “smart home” ecosystems tied to a single manufacturer, KNX is an open, international standard (ISO/IEC 14543-3) supported by hundreds of manufacturers — which means a light switch from one company can control a dimmer from another, decades apart, without any cloud service in between.

At the heart of KNX is the bus: a two-wire cable (or, increasingly, IP/Wi-Fi) that carries small data telegrams between devices. A push-button doesn’t switch a light directly — it sends a telegram onto the bus with a group address, and any device configured to listen on that address reacts: a relay switches a light, a dimming actuator adjusts brightness, a display shows a status. This decoupling is what makes KNX systems so flexible: changing what a button does is a configuration change, not a rewiring job.

Design and commissioning happen in ETS (Engineering Tool Software), where the electrical planner defines group addresses, assigns devices, and programs logic — from simple “one button, one light” pairings to complex scenes, presence-based HVAC control, and shading that responds to sun position and wind speed. A well-structured group address scheme (main group / middle group / sub-group) is what separates a maintainable installation from a tangled mess that only its original installer can understand.

KNX shines especially in retrofit and long-lifecycle buildings — schools, public administration, hospitals — where the wiring topology needs to outlast any single vendor’s product roadmap. It also integrates cleanly with building-wide automation, weather stations, and increasingly with visualization systems and voice assistants via IP gateways. For an electrical planner, fluency in KNX isn’t just about knowing which actuator to specify — it’s about designing a group address structure and cabling topology today that a completely different team can still expand ten years from now.

If KNX is the open, decentralized standard of building automation, Loxone represents the opposite design philosophy: a single, centralized “Miniserver” that acts as the brain of the entire building, with proprietary software (Loxone Config) tying lighting, heating, shading, audio, irrigation, and security into one coherent system. That trade-off — less openness, more integration out of the box — has made Loxone especially popular with system integrators and private homeowners who want powerful automation without assembling it from a dozen different manufacturers’ components.

The Miniserver connects to sensors and actuators over Loxone’s own Tree bus (a simple two-wire topology that’s fast to install) or via extensions for KNX, DMX, Modbus, and other protocols — meaning a Loxone installation can absorb an existing KNX system rather than replacing it. Programming happens visually in Loxone Config, where function blocks are wired together on a canvas: a motion sensor block feeds into a logic block, which feeds into a lighting output — no textual programming required for most standard tasks, though a scripting interface exists for advanced logic.

Where Loxone particularly stands out is its native intelligence for comfort and energy: it can shift shading automatically based on sun position, outdoor temperature, and indoor CO₂ levels; learn a household’s presence patterns; and manage heating zones with weather-compensated curves — all coordinated from one place rather than stitched together across separate subsystems. Its app-based visualization is also famously polished, letting homeowners control and monitor everything from a phone without a separate visualization project.

The trade-off engineers should weigh: Loxone’s ecosystem lock-in means you’re relying on one manufacturer’s roadmap, and its Tree/Air wiring isn’t interchangeable with other brands’ hardware the way KNX devices are. But for renovation projects and new builds where a single integrator will own the whole system, Loxone often delivers a more polished result, faster, than assembling an equivalent KNX installation from scratch.

When people hear “radiation protection,” they usually think of nuclear power plants or hospital X-ray departments. In reality, ionizing and non-ionizing radiation shows up in far more everyday technical work than most people realize: X-ray inspection of welds and pipework, industrial radiography, medical imaging equipment, certain measurement and level-gauging devices, and increasingly, high-power radio and microwave installations. Anyone who plans, installs, maintains, or works near this equipment needs a working understanding of Strahlenschutz — radiation protection — even if their main job title is “electrician” or “technician,” not “radiation physicist.”

The foundation of radiation protection rests on three simple principles: time, distance, and shielding. Minimizing the time spent near a radiation source, maximizing distance (since exposure typically falls off with the square of distance), and using appropriate shielding material (lead, concrete, water, depending on radiation type) together reduce dose to a fraction of what unprotected exposure would deliver. On top of this physical foundation sits a legal and administrative framework — in Germany, primarily the Strahlenschutzgesetz (StrlSchG) and Strahlenschutzverordnung (StrlSchV) — which defines dose limits, monitoring obligations, training requirements, and the roles of a Strahlenschutzbeauftragter (radiation protection officer) and Strahlenschutzverantwortlicher (radiation protection supervisor).

Training programs — organized into Fachkundegruppen such as S4 (industrial radiography) and S5 (measuring devices, gauging, and similar low-risk applications) — are structured around exactly this combination: enough physics to understand what’s actually dangerous and why, enough legal knowledge to operate compliantly, and enough practical judgment (dosimetry, source handling, emergency procedures) to keep both yourself and others safe. A Grundmodul (basic module) covers the shared fundamentals, while a Fachkundemodul (specialist module) tailors the training to the specific device category or application.

For anyone working at the intersection of measurement technology, building automation, or industrial instrumentation, radiation protection knowledge isn’t a specialist detour — it’s part of the baseline competence needed to work safely and legally around equipment that, on the surface, looks like just another sensor on a schematic.

“Artificial intelligence” has become one of those terms that means everything and nothing at once — a chatbot, a recommendation algorithm, a self-driving car, and a spreadsheet formula that predicts sales all get called “AI” at some point. Cutting through the marketing, most of what’s driving today’s wave is a fairly specific technology: large language models (LLMs) and related deep learning systems, trained on enormous datasets to recognize statistical patterns in language, images, and other data, and then generate new content that follows those patterns.

What changed in the last few years wasn’t the basic idea — neural networks have existed since the 1950s, and the “transformer” architecture behind modern LLMs dates to 2017 — but the scale: models with hundreds of billions of parameters, trained on a meaningful fraction of all digitized human text, running on purpose-built hardware. That scale produced a genuinely surprising result: capabilities like translation, summarization, code generation, and open-ended conversation emerged from a training objective as simple as “predict the next word,” without anyone explicitly programming those skills in.

For technical fields like automation and engineering, the practical impact is showing up in a few concrete places: AI-assisted code generation and debugging for PLC and scripting tasks, natural-language interfaces layered on top of building automation systems, predictive maintenance models that flag anomalies in sensor data before a failure occurs, and design assistance tools that can draft documentation, translate technical texts, or summarize standards and regulations. None of this replaces the engineer’s judgment — a model can hallucinate a plausible-sounding but wrong answer with total confidence — but used carefully, it removes a lot of the repetitive, low-judgment work that used to eat up an engineer’s day.

The honest caveat worth stating clearly: today’s AI systems don’t “understand” in the way a human does — they’re extremely sophisticated pattern-matchers, and their failure modes (confidently wrong answers, sensitivity to how a question is phrased, no real memory between separate conversations unless explicitly built in) reflect that. Treating AI as a tireless, well-read assistant that still needs checking — rather than an oracle — is the mindset that gets the most genuine value out of it, in engineering as much as anywhere else.