mirror of
https://github.com/qelectrotech/qelectrotech-source-mirror.git
synced 2026-09-20 15:24:14 +02:00
Document terminal strips, 9k lines of shipped feature with no user docs
sources/TerminalStrip/ is 66 files and ~9,250 lines, and the words "terminal strip" appeared on the wiki only in the roadmap, history, vision and contributing pages -- discussed as a topic, never documented as a feature. Covers the part that actually causes confusion: the three-layer model of strip / physical terminal / real terminal, where a physical terminal's several real terminals are its levels, ordered back to front from the mounting plate. Also the six conditions a selection must meet to be bridgeable (the reason the button greys out), free terminals that exist in the strip but on no folio, the four-level ceiling in the drawing that the data model itself does not impose, and the <terminal_strips> XML. States the honest caveats: the menu entry is labelled (DEV) in the shipped source, and no example project contains strip data -- verified, the 143 "terminal_strips" hits in industrial.qet are all element collection paths, not strip data. EN/FR/DE.
ispyisail
+2
@@ -22,6 +22,8 @@
|
||||
|
||||
**[Variables & formulas](variables)** — `%f`, `%{label}`, sequences
|
||||
|
||||
**[Terminal strips](terminal_strips)** — strips, levels, bridges
|
||||
|
||||
**[Elements XML](elements_XML)**
|
||||
* [attribute](elements_definition_attribute)
|
||||
* [uuid](elements_child_uuid)
|
||||
|
||||
+1
@@ -60,6 +60,7 @@ Beginnen Sie mit der deutschen Version dieses Wikis:
|
||||
| Linking elements | ✅ | ✅ | ✅ |
|
||||
| Project database | ✅ | ✅ | ✅ |
|
||||
| Variables & formulas | ✅ | ✅ | ✅ |
|
||||
| Terminal strips | ✅ | ✅ | ✅ |
|
||||
|
||||
**Legend:** ✅ Translated | 📋 Planned | ❌ Not yet started
|
||||
|
||||
|
||||
@@ -0,0 +1,219 @@
|
||||
# Klemmenleisten
|
||||
|
||||
Eine Klemmenleiste ist in QElectroTech ein **eigenes Objekt, getrennt von den
|
||||
auf den Folios gezeichneten Klemmen**. Die Folio-Klemmen bleiben, wo sie sind;
|
||||
die Leiste ist eine Liste, die sie referenziert, die nur im Schrank
|
||||
vorhandenen Klemmen ergänzt, Ebenen und Brücken festhält und sich als
|
||||
Klemmenplan auf ein Folio zeichnen lässt.
|
||||
|
||||
> **Status: als (DEV) gekennzeichnet.** Der Menüeintrag lautet
|
||||
> *Projekt → Klemmenleisten-Verwaltung (DEV)*, und diese Kennzeichnung steht so
|
||||
> im ausgelieferten Quellcode. Die Funktion arbeitet, und ihre Daten werden in
|
||||
> der Projektdatei gespeichert, doch die Entwickler haben sie nicht für fertig
|
||||
> erklärt. Betrachten Sie sie als nutzbar und in Bewegung, nicht als
|
||||
> abgeschlossen.
|
||||
|
||||
Quellen: `sources/TerminalStrip/` — `terminalstrip.cpp`, `physicalterminal.cpp`,
|
||||
`realterminal.cpp`, `terminalstripbridge.cpp`, und `ui/` für den Editor.
|
||||
|
||||
---
|
||||
|
||||
## 1. Die drei Objekte
|
||||
|
||||
Das Modell hat drei Ebenen, und fast alle Verwirrung um Klemmenleisten entsteht
|
||||
daraus, zwei davon zusammenzuwerfen.
|
||||
|
||||
| Objekt | Ist | Beispiel |
|
||||
|---|---|---|
|
||||
| **Klemmenleiste** | die ganze Leiste | `-X1`, 24 Klemmen auf einer Schiene |
|
||||
| **Physische Klemme** | ein auf die Schiene geclipster Block | Position 7 von `-X1` |
|
||||
| **Reale Klemme** | eine elektrische Ebene dieses Blocks | die vordere Ebene von Position 7 |
|
||||
|
||||
Eine physische Klemme besteht aus **einer oder mehreren** realen Klemmen. Eine
|
||||
einzelne reale Klemme ist ein gewöhnlicher einstöckiger Block. Mehrere bedeuten,
|
||||
dass der Block **Ebenen** hat — eine zwei- oder dreistöckige Klemme.
|
||||
|
||||
Die Ebenen sind von hinten nach vorn geordnet, von der Montageplatte zur
|
||||
Schranktür:
|
||||
|
||||
```
|
||||
Montageplatte Tür
|
||||
| |
|
||||
| +---+ |
|
||||
| | 0 | +---+ |
|
||||
| | | | 1 | +---+ |
|
||||
| | | | | | 2 | |
|
||||
| +---+ +---+ +---+ |
|
||||
| |
|
||||
|<---- eine physische Klemme, 3 Ebenen ----->|
|
||||
```
|
||||
|
||||
Ebene 0 liegt hinten. Es ist dieselbe Ordnung, die die Spalte *Ebene* im Editor
|
||||
zeigt, und dieselbe, gegen die das Brücken prüft.
|
||||
|
||||
### Reale Klemmen, die auf keinem Folio stehen
|
||||
|
||||
Eine reale Klemme muss **nicht** einer gezeichneten Klemme entsprechen. Eine auf
|
||||
der Schiene reservierte, aber nicht gezeichnete Klemme — eine Reserve, ein
|
||||
künftiger Anschluss, ein vom Hersteller gelieferter Endblock — existiert in der
|
||||
Leiste als reale Klemme ohne Element dahinter.
|
||||
|
||||
Dafür ist die Liste der **freien Klemmen** im Editor da: Klemmen, die in der
|
||||
Leiste vorkommen und im Schaltplan nicht. Deshalb kann die Klemmenzahl einer
|
||||
Leiste die Zahl der Klemmenelemente in den Folios berechtigterweise übersteigen.
|
||||
|
||||
---
|
||||
|
||||
## 2. Eine Leiste anlegen und füllen
|
||||
|
||||
*Projekt → Klemmenleisten-Verwaltung (DEV)* öffnet das Editorfenster. Links
|
||||
stehen die Leisten des Projekts in einem Baum, rechts die Klemmen der gewählten
|
||||
Leiste in einer Tabelle.
|
||||
|
||||
Eine Leiste trägt fünf Kennzeichnungen: **Anlage**, **Ort**, **Name**,
|
||||
**Kommentar** und **Beschreibung**. Anlage und Ort sind dieselben Begriffe wie
|
||||
die Felder `plant` und `locmach` eines Folios — eine Leiste wird adressiert wie
|
||||
ein Element.
|
||||
|
||||
Klemmen gelangen in eine Leiste, indem sie ihr hinzugefügt werden: entweder aus
|
||||
den bereits gezeichneten Klemmenelementen des Projekts oder als freie Klemmen,
|
||||
die man in der Leiste selbst anlegt.
|
||||
|
||||
### Die Klemmentabelle
|
||||
|
||||
| Spalte | Bedeutung |
|
||||
|---|---|
|
||||
| Position | Reihenfolge auf der Schiene |
|
||||
| Ebene | welche Etage eines mehrstöckigen Blocks, 0 = hinten |
|
||||
| Label | Nummer oder Name der Klemme |
|
||||
| Leiternummer | der ankommende Draht |
|
||||
| Querverweis | wo die Klemme gezeichnet ist |
|
||||
| Kabel | Kabel, zu dem die Klemme gehört |
|
||||
| Kabeladerfarbe / -nummer | die Ader in diesem Kabel |
|
||||
| Typ | generisch, Sicherung, trennbar, Diode, Erde |
|
||||
| Funktion | generisch, Phase, Neutralleiter |
|
||||
| LED | ob der Block eine Anzeige trägt |
|
||||
|
||||
Typ und Funktion stammen aus der Definition des Klemmenelements — siehe
|
||||
**[Elemente verknüpfen](element_linking)**.
|
||||
|
||||
---
|
||||
|
||||
## 3. Gruppieren, Ebenen, Sortieren
|
||||
|
||||
Zwei Operationen ändern die Gestalt der Leiste statt ihres Inhalts:
|
||||
|
||||
- **Gruppieren** fasst mehrere reale Klemmen zu Ebenen einer physischen Klemme
|
||||
zusammen. So sagt man QET „diese drei sind ein dreistöckiger Block“ und nicht
|
||||
drei Blöcke.
|
||||
- **Aufheben** kehrt das um und gibt jeder realen Klemme einen eigenen Block.
|
||||
|
||||
Das Sortieren legt die Reihenfolge der physischen Klemmen auf der Schiene fest.
|
||||
Beides ist rückgängig zu machen: Das Modul bringt eigene Undo-Kommandos für
|
||||
Gruppieren, Sortieren, Ebenenwechsel, Brücken und Farbe mit.
|
||||
|
||||
---
|
||||
|
||||
## 4. Brücken
|
||||
|
||||
Eine Brücke (Kamm, Bügel) verbindet Klemmen, die auf gleichem Potential liegen
|
||||
müssen. QETs Regeln sind streng, und sie zu kennen erspart das Rätselraten,
|
||||
warum die Brückenschaltfläche ausgegraut ist. Brückbar sind die gewählten
|
||||
realen Klemmen nur, wenn sie:
|
||||
|
||||
1. **mindestens zwei** sind;
|
||||
2. alle zu **dieser** Leiste gehören;
|
||||
3. alle auf **derselben Ebene** liegen — eine vordere Ebene lässt sich nicht mit
|
||||
einer hinteren brücken;
|
||||
4. auf der Schiene **aufeinanderfolgen**;
|
||||
5. zu **verschiedenen physischen Klemmen** gehören — die Ebenen eines Blocks
|
||||
werden nicht untereinander gebrückt;
|
||||
6. **mindestens eine noch nicht gebrückte** Klemme enthalten.
|
||||
|
||||
Fehlt eine der sechs Bedingungen, wird die Operation abgelehnt statt teilweise
|
||||
ausgeführt.
|
||||
|
||||
Brücken tragen eine Farbe aus einer festen Palette — Rot, Blau, Weiß,
|
||||
Dunkelgrau, Schwarz — mit **Dunkelgrau** als Vorgabe. Die Farbe ist eine
|
||||
Zeichnungskonvention, keine elektrische Bedeutung; konsequent im ganzen Projekt
|
||||
eingesetzt, liest sie sich als Dokumentation.
|
||||
|
||||
---
|
||||
|
||||
## 5. Eine Leiste auf ein Folio zeichnen
|
||||
|
||||
Eine Leiste lässt sich als grafisches Objekt auf einem Folio platzieren. Was
|
||||
gezeichnet wird, bestimmt ein **Layoutmuster**: ein benannter, wiederverwendbarer
|
||||
Satz von Geometrien — Rechteck und Textausrichtung der Kopfzeile, Abstandhalter,
|
||||
Klemmenrechtecke je Ebene, Höhe, Position und Ausrichtung der Klemmen- und
|
||||
Querverweistexte, Schrift sowie Durchmesser und vertikale Versätze der
|
||||
Brückenpunkte.
|
||||
|
||||
Layouts werden je Projekt verwaltet; ein Hausstil lässt sich also einmal
|
||||
festlegen und auf jede Leiste anwenden.
|
||||
|
||||
**Die Zeichnung unterstützt bis zu vier Ebenen.** Das Layoutmuster enthält vier
|
||||
Klemmenrechtecke und vier Brückenpunkt-Versätze. Das Datenmodell selbst kennt
|
||||
diese Grenze nicht — eine physische Klemme kann mehr reale Klemmen aufnehmen,
|
||||
als die Zeichnung Reihen hat. Wer fünfstöckige Blöcke baut, behält sie im
|
||||
Modell; der Klemmenplan zeigt nicht alle.
|
||||
|
||||
---
|
||||
|
||||
## 6. Speicherung
|
||||
|
||||
Leisten leben in der Projektdatei, nicht in den Folios:
|
||||
|
||||
```xml
|
||||
<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>
|
||||
<!-- ein Eintrag je physischer Klemme, jeweils mit ihren
|
||||
realen Klemmen in Ebenenreihenfolge -->
|
||||
</layout>
|
||||
<terminal_strip_bridge>…</terminal_strip_bridge>
|
||||
</terminal_strip>
|
||||
</terminal_strips>
|
||||
</project>
|
||||
```
|
||||
|
||||
Leere Kennzeichnungsfelder werden weggelassen statt leer geschrieben; das XML
|
||||
einer minimalen Leiste ist daher kurz.
|
||||
|
||||
Reale Klemmen werden über die **uuid des Elements** gespeichert, auf das sie
|
||||
verweisen. Beim Laden wird die Leiste über diese uuid wieder mit den
|
||||
Klemmenelementen des Projekts verbunden; reale Klemmen ohne Element entstehen
|
||||
als freie Klemmen neu. Das ist die übliche Folge einer elementbasierten
|
||||
Identität: Ein Element, das seine uuid verliert oder ändert, verliert seinen
|
||||
Platz in der Leiste.
|
||||
|
||||
---
|
||||
|
||||
## 7. Was ehrlicherweise zu erwarten ist
|
||||
|
||||
- Die Funktion ist in der Oberfläche mit **(DEV)** gekennzeichnet. Ihre Daten
|
||||
werden gespeichert und gelesen, ihr Umfang bewegt sich aber noch.
|
||||
- Die Leiste ist eine **Sicht auf** Ihre Klemmen, ergänzt um die, die nur sie
|
||||
kennt. Sie nummeriert Ihre Folios nicht um und legt keine Klemmenelemente an.
|
||||
- Die Klemmennummerierung ist eine **eigene** Funktion — siehe `auto_num_locked`
|
||||
unter **[Elemente verknüpfen](element_linking)**, um eine Klemme davon
|
||||
auszunehmen.
|
||||
- Kein mitgeliefertes Beispielprojekt verwendet Klemmenleisten; ein fertiges
|
||||
Beispiel zum Abschauen gibt es also nicht.
|
||||
|
||||
---
|
||||
|
||||
Siehe auch: **[Elemente verknüpfen](element_linking)** ·
|
||||
**[Variablen und Formeln](variables)** ·
|
||||
**[Die Projektdatenbank](project_database)**
|
||||
@@ -0,0 +1,222 @@
|
||||
# Borniers
|
||||
|
||||
Dans QElectroTech, un bornier est un **objet distinct des bornes dessinées sur
|
||||
vos folios**. Les bornes des folios restent où elles sont ; le bornier est une
|
||||
liste qui les référence, y ajoute les bornes qui n'existent que dans l'armoire,
|
||||
enregistre les étages et les ponts, et peut être dessiné sur un folio sous forme
|
||||
de plan de bornier.
|
||||
|
||||
> **État : marqué (DEV).** L'entrée de menu est
|
||||
> *Projet → Gestionnaire de borniers (DEV)*, et cette mention figure dans les
|
||||
> sources livrées. La fonction marche et ses données sont enregistrées dans le
|
||||
> fichier projet, mais les développeurs ne l'ont pas déclarée achevée.
|
||||
> Considérez-la comme utilisable et évolutive, non comme figée.
|
||||
|
||||
Sources : `sources/TerminalStrip/` — `terminalstrip.cpp`,
|
||||
`physicalterminal.cpp`, `realterminal.cpp`, `terminalstripbridge.cpp`, et `ui/`
|
||||
pour l'éditeur.
|
||||
|
||||
---
|
||||
|
||||
## 1. Les trois objets
|
||||
|
||||
Le modèle comporte trois niveaux, et presque toutes les confusions au sujet des
|
||||
borniers viennent de la fusion de deux d'entre eux.
|
||||
|
||||
| Objet | Est | Exemple |
|
||||
|---|---|---|
|
||||
| **Bornier** | le bornier entier | `-X1`, 24 bornes sur un rail |
|
||||
| **Borne physique** | un bloc clipsé sur le rail | la position 7 de `-X1` |
|
||||
| **Borne réelle** | un étage électrique de ce bloc | l'étage avant de la position 7 |
|
||||
|
||||
Une borne physique est composée d'**une ou plusieurs** bornes réelles. Une seule
|
||||
borne réelle correspond à un bloc simple ordinaire. Plusieurs signifient que le
|
||||
bloc a des **étages** — une borne à deux ou trois étages.
|
||||
|
||||
Les étages sont ordonnés de l'arrière vers l'avant, de la platine de montage
|
||||
vers la porte de l'armoire :
|
||||
|
||||
```
|
||||
platine de montage porte
|
||||
| |
|
||||
| +---+ |
|
||||
| | 0 | +---+ |
|
||||
| | | | 1 | +---+ |
|
||||
| | | | | | 2 | |
|
||||
| +---+ +---+ +---+ |
|
||||
| |
|
||||
|<---- une borne physique, 3 étages -------->|
|
||||
```
|
||||
|
||||
L'étage 0 est celui du fond. C'est le même ordre que celui affiché par la
|
||||
colonne *Étage* de l'éditeur, et celui que compare le pontage.
|
||||
|
||||
### Des bornes réelles absentes des folios
|
||||
|
||||
Une borne réelle ne correspond **pas nécessairement** à une borne dessinée. Une
|
||||
borne réservée sur le rail mais non dessinée — une réserve, un raccordement
|
||||
futur, un bloc d'extrémité fourni par le fabricant — existe dans le bornier
|
||||
comme borne réelle sans élément derrière elle.
|
||||
|
||||
C'est à cela que sert la liste des **bornes libres** de l'éditeur : des bornes
|
||||
qui existent dans le bornier et pas dans le schéma. C'est aussi pourquoi le
|
||||
nombre de bornes d'un bornier peut légitimement dépasser le nombre d'éléments
|
||||
bornes de vos folios.
|
||||
|
||||
---
|
||||
|
||||
## 2. Créer et remplir un bornier
|
||||
|
||||
*Projet → Gestionnaire de borniers (DEV)* ouvre la fenêtre d'édition. Elle
|
||||
présente les borniers du projet dans une arborescence à gauche, et les bornes du
|
||||
bornier sélectionné dans un tableau.
|
||||
|
||||
Un bornier porte cinq éléments d'identification : **installation**,
|
||||
**localisation**, **nom**, **commentaire** et **description**. Installation et
|
||||
localisation sont les mêmes notions que les champs `plant` et `locmach` d'un
|
||||
folio : un bornier s'adresse comme un élément.
|
||||
|
||||
Les bornes rejoignent un bornier en y étant ajoutées, soit depuis les éléments
|
||||
bornes déjà dessinés dans le projet, soit comme bornes libres créées directement
|
||||
dans le bornier.
|
||||
|
||||
### Le tableau des bornes
|
||||
|
||||
| Colonne | Signification |
|
||||
|---|---|
|
||||
| Position | ordre sur le rail |
|
||||
| Étage | quel étage d'un bloc multi-étages, 0 = arrière |
|
||||
| Label | numéro ou nom de la borne |
|
||||
| Numéro de conducteur | le fil qui arrive |
|
||||
| Référence croisée | où la borne est dessinée |
|
||||
| Câble | câble auquel la borne appartient |
|
||||
| Couleur / numéro de fil câble | le conducteur dans ce câble |
|
||||
| Type | générique, fusible, sectionnable, diode, terre |
|
||||
| Fonction | générique, phase, neutre |
|
||||
| led | si le bloc porte un voyant |
|
||||
|
||||
Type et fonction proviennent de la définition de l'élément borne — voir
|
||||
**[Lier des éléments](element_linking)** pour la façon dont un élément les
|
||||
déclare.
|
||||
|
||||
---
|
||||
|
||||
## 3. Regrouper, étager, trier
|
||||
|
||||
Deux opérations changent la forme du bornier plutôt que son contenu :
|
||||
|
||||
- **Regrouper** prend plusieurs bornes réelles et en fait les étages d'une seule
|
||||
borne physique. C'est ainsi qu'on indique à QET « ces trois-là forment un seul
|
||||
bloc à trois étages », et non trois blocs.
|
||||
- **Dégrouper** fait l'inverse, en donnant à chaque borne réelle son propre
|
||||
bloc.
|
||||
|
||||
Le tri fixe l'ordre des bornes physiques sur le rail. Les deux sont annulables :
|
||||
le module possède ses propres commandes d'annulation pour le regroupement, le
|
||||
tri, le changement d'étage, le pontage et la couleur.
|
||||
|
||||
---
|
||||
|
||||
## 4. Pontage
|
||||
|
||||
Un pont (peigne, barrette) relie des bornes qui doivent être au même potentiel.
|
||||
Les règles de QET sont strictes, et les connaître évite de chercher pourquoi le
|
||||
bouton de pontage est grisé. Pour être pontables, les bornes réelles
|
||||
sélectionnées doivent :
|
||||
|
||||
1. être **au moins deux** ;
|
||||
2. appartenir toutes à **ce** bornier ;
|
||||
3. être toutes au **même étage** — on ne ponte pas un étage avant à un étage
|
||||
arrière ;
|
||||
4. être **consécutives** sur le rail ;
|
||||
5. appartenir à des **bornes physiques différentes** — les étages d'un même bloc
|
||||
ne se pontent pas entre eux ;
|
||||
6. comporter **au moins une borne pas déjà pontée**.
|
||||
|
||||
Si l'une des six conditions manque, l'opération est refusée plutôt
|
||||
qu'appliquée partiellement.
|
||||
|
||||
Les ponts portent une couleur, choisie dans une palette fixe — rouge, bleu,
|
||||
blanc, gris foncé, noir — le **gris foncé** étant la valeur par défaut. La
|
||||
couleur est une convention de dessin, non une signification électrique ;
|
||||
utilisée de façon cohérente dans un projet, elle se lit comme une
|
||||
documentation.
|
||||
|
||||
---
|
||||
|
||||
## 5. Dessiner un bornier sur un folio
|
||||
|
||||
Un bornier peut être placé sur un folio comme objet graphique. Ce qui est
|
||||
dessiné est régi par un **modèle de mise en page** : un jeu de géométries
|
||||
nommé et réutilisable — rectangle et orientation du texte d'en-tête,
|
||||
espacement, rectangles de bornes par étage, hauteur, position et orientation
|
||||
des textes de borne et de référence croisée, police, diamètre et décalages
|
||||
verticaux des points de pont.
|
||||
|
||||
Les mises en page sont gérées par projet : une charte graphique se définit une
|
||||
fois et s'applique à tous les borniers.
|
||||
|
||||
**Le dessin gère jusqu'à quatre étages.** Le modèle de mise en page contient
|
||||
quatre rectangles de bornes et quatre décalages de points de pont. Le modèle de
|
||||
données, lui, n'impose pas cette limite : une borne physique peut contenir plus
|
||||
de bornes réelles que le dessin n'a de rangées. Si vous créez des blocs à cinq
|
||||
étages, le modèle les conservera ; le plan de bornier ne les montrera pas tous.
|
||||
|
||||
---
|
||||
|
||||
## 6. Stockage
|
||||
|
||||
Les borniers vivent dans le fichier projet, pas dans les folios :
|
||||
|
||||
```xml
|
||||
<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>
|
||||
<!-- une entrée par borne physique, chacune listant ses
|
||||
bornes réelles dans l'ordre des étages -->
|
||||
</layout>
|
||||
<terminal_strip_bridge>…</terminal_strip_bridge>
|
||||
</terminal_strip>
|
||||
</terminal_strips>
|
||||
</project>
|
||||
```
|
||||
|
||||
Les champs d'identification vides sont omis plutôt qu'écrits vides : le XML d'un
|
||||
bornier minimal est donc court.
|
||||
|
||||
Les bornes réelles sont stockées par l'**uuid de l'élément** qu'elles
|
||||
référencent. Au chargement, le bornier est reconnecté aux éléments bornes du
|
||||
projet par cet uuid ; les bornes réelles sans élément sont reconstruites comme
|
||||
bornes libres. C'est la conséquence habituelle d'une identité fondée sur
|
||||
l'élément : un élément qui perd ou change d'uuid perd sa place dans le bornier.
|
||||
|
||||
---
|
||||
|
||||
## 7. À quoi s'attendre, honnêtement
|
||||
|
||||
- La fonction est marquée **(DEV)** dans l'interface. Ses données sont
|
||||
enregistrées et relues, mais son périmètre bouge encore.
|
||||
- Le bornier est une **vue sur** vos bornes, plus celles qu'il est seul à
|
||||
connaître. Il ne renumérote pas vos folios et ne crée pas d'éléments bornes.
|
||||
- La renumérotation des bornes est une fonction **distincte** — voir
|
||||
`auto_num_locked` dans **[Lier des éléments](element_linking)** pour en
|
||||
exempter une borne.
|
||||
- Aucun projet d'exemple livré n'utilise de bornier : il n'y a donc pas de cas
|
||||
concret fourni dont s'inspirer.
|
||||
|
||||
---
|
||||
|
||||
Voir aussi : **[Lier des éléments](element_linking)** ·
|
||||
**[Variables et formules](variables)** ·
|
||||
**[La base de données du projet](project_database)**
|
||||
+211
@@ -0,0 +1,211 @@
|
||||
# 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](element_linking)** 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:
|
||||
|
||||
1. number **at least two**;
|
||||
2. all belong to **this** strip;
|
||||
3. all be at the **same level** — you cannot bridge a front level to a back one;
|
||||
4. be **consecutive** on the rail;
|
||||
5. belong to **different physical terminals** — the levels of one block are not
|
||||
bridged to each other;
|
||||
6. 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:
|
||||
|
||||
```xml
|
||||
<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_locked` in
|
||||
**[Linking elements](element_linking)** 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](element_linking)** ·
|
||||
**[Variables & formulas](variables)** ·
|
||||
**[The project database](project_database)**
|
||||
Reference in New Issue
Block a user