Terminal strips
A terminal strip in QElectroTech is a separate object from the terminals drawn on your folios. The folio terminals stay where they are; the strip is a list that references them, adds the terminals that exist only in the cabinet, records levels and bridges, and can be drawn on a folio as a strip plan.
Status: marked (DEV). The menu entry is Project → Terminal strip manager (DEV), and that label is in the shipped source. The feature works and its data is saved in the project file, but the developers have not declared it finished. Treat it as usable and evolving rather than settled.
Source: sources/TerminalStrip/ — terminalstrip.cpp, physicalterminal.cpp,
realterminal.cpp, terminalstripbridge.cpp, and ui/ for the editor.
1. The three objects
The model has three layers, and almost every confusion about terminal strips comes from collapsing two of them.
| Object | Is | Example |
|---|---|---|
| Terminal strip | the whole strip | -X1, 24 terminals on a rail |
| Physical terminal | one block clipped onto the rail | position 7 on -X1 |
| Real terminal | one electrical level within that block | the front level of position 7 |
A physical terminal is composed of one or more real terminals. One real terminal is an ordinary single-level block. More than one means the block has levels — a two- or three-tier terminal.
Levels are ordered back to front, from the mounting plate towards the cabinet door:
mounting plate door
| |
| +---+ |
| | 0 | +---+ |
| | | | 1 | +---+ |
| | | | | | 2 | |
| +---+ +---+ +---+ |
| |
|<---- one physical terminal, 3 levels ----->|
Level 0 is the back. That ordering is the same one the editor's Level column shows and the same one bridging compares against.
Real terminals that are not on any folio
A real terminal does not have to correspond to a drawn terminal element. A terminal you have reserved on the rail but not drawn — a spare, a future connection, a manufacturer-supplied end block — exists in the strip as a real terminal with no element behind it.
This is what the editor's free terminal list is for: terminals that exist in the strip and not in the schematic. It is also why a strip's terminal count can legitimately exceed the number of terminal elements in your folios.
2. Creating and filling a strip
Project → Terminal strip manager (DEV) opens the editor window. It shows the project's strips in a tree on the left, and the selected strip's terminals in a table.
A strip carries five pieces of identification: installation, location,
name, comment and description. Installation and location are the
same concepts as a folio's plant and locmach — a strip is addressed the same
way an element is.
Terminals reach a strip by being added to it, either from the drawn terminal elements the project already has, or as free terminals you create in the strip itself.
The terminal table
| Column | Meaning |
|---|---|
| Position | order on the rail |
| Level | which tier of a multi-level block, 0 = back |
| Label | the terminal's number or name |
| Conductor number | the wire number arriving |
| Cross-reference | where the terminal is drawn |
| Cable | cable this terminal belongs to |
| Cable wire colour / number | the core within that cable |
| Type | generic, fuse, sectional, diode, ground |
| Function | generic, phase, neutral |
| LED | whether the block carries an indicator |
Type and function come from the terminal element's own definition — see Linking elements for how an element declares them.
3. Grouping, levels and sorting
Two operations change the shape of the strip rather than its contents:
- Grouping takes several real terminals and makes them levels of one physical terminal. That is how you tell QET "these three are one three-tier block", not three blocks.
- Ungrouping reverses it, giving each real terminal a block of its own.
Sorting sets the order of physical terminals on the rail. Both are undoable — the module has its own undo commands for grouping, sorting, level changes, bridging and colour.
4. Bridging
A bridge (comb, jumper) links terminals that must be at the same potential. QET's rules are strict, and knowing them saves guessing why the bridge button is greyed out. To be bridgeable, the selected real terminals must:
- number at least two;
- all belong to this strip;
- all be at the same level — you cannot bridge a front level to a back one;
- be consecutive on the rail;
- belong to different physical terminals — the levels of one block are not bridged to each other;
- include at least one terminal that is not already bridged.
Fail any of the six and the operation is refused rather than partially applied.
Bridges carry a colour, chosen from a fixed palette — red, blue, white, dark grey, black — with dark grey the default. The colour is a drawing convention, not electrical meaning; use it consistently across a project and it reads as documentation.
5. Drawing a strip on a folio
A strip can be placed on a folio as a graphical item. What gets drawn is governed by a layout pattern, a named, reusable set of geometry: header rectangle and text orientation, spacer, per-level terminal rectangles, terminal and cross-reference text height, position and orientation, font, and the diameter and vertical offsets of the bridge dots.
Layouts are managed per project, so a house style can be defined once and applied to every strip.
The drawing supports up to four levels. The layout pattern holds four terminal rectangles and four bridge-point offsets. The data model itself does not impose that limit — a physical terminal can hold more real terminals than the drawing has rows for. If you build five-level blocks, the model will keep them; the strip plan will not show them all.
6. How it is stored
Strips live in the project file, not in the folios:
<project>
...
<terminal_strips>
<terminal_strip>
<terminal_strip_data uuid="{…}">
<informations>
<information name="installation">…</information>
<information name="location">…</information>
<information name="name">-X1</information>
<information name="comment">…</information>
<information name="description">…</information>
</informations>
</terminal_strip_data>
<layout>
<!-- one entry per physical terminal, each listing its
real terminals in level order -->
</layout>
<terminal_strip_bridge>…</terminal_strip_bridge>
</terminal_strip>
</terminal_strips>
</project>
Empty identification fields are omitted rather than written blank, so a minimal strip's XML is short.
Real terminals are stored by the uuid of the element they refer to. On load, the strip is reconnected to the project's terminal elements by that uuid; real terminals with no element are rebuilt as free terminals. This is the usual consequence of identity being element-based: an element that loses or changes its uuid loses its place in the strip.
7. What to expect, honestly
- The feature is labelled (DEV) in the interface. Its data is saved and reloaded, but its scope is still moving.
- The strip is a view over your terminals plus the ones only it knows about. It does not renumber your folios and does not create terminal elements.
- Terminal renumbering is a separate feature — see
auto_num_lockedin Linking elements for how to exempt a terminal from it. - Nothing in the shipped example projects uses terminal strips, so there is no worked example in the box to copy from.
See also: Linking elements · Variables & formulas · The project database
Getting Started
🌐 Languages — English · Français · Deutsch
Guides
Conductors — wire properties, what feeds which export, and cables
Wire & cable catalogue — cable types, IEC 60757 core colours, assigning a core to a conductor
Printing and exporting — paper, PDF, images, and what each path does differently
Linking elements — master, slave, terminal
PLC modules — I/O tables and linking a wire to a specific point
Using the element editor — drawing tools, saving, checks
Preferences reference — what each settings page does
Keyboard-only control — mouseless QET, and the one real gap
Mouse modifiers — what Shift, Ctrl and Alt change while you drag
Managing collections — folders, writability, building your own shortlist
Templates — reusable multi-element blocks, and why clicking one does nothing
Search & Replace — bulk property changes
Building a nomenclature query — the BOM/summary table builder
Linking wires across pages — folio reports
Variables & formulas — %f, %{label}, sequences
Auto-numbering — schemes, sequences, freezing
Terminal strips — strips, levels, bridges
Title block templates — the .titleblock format
Importing EPLAN parts (.edz) — EPLAN Data Portal
DXF import & export — two unrelated features, one format
The project database — the in-memory SQLite cache
Development
Automating QET — CLI, XML formats, external tools
CLI Reference — command line usage
JavaScript Scripting — --run, geometry editing, undo
Vision — proposal, under discussion
