Improve terminal_strip

[scorpio810]

Terminal strip: natural sort fix, and why the strip plan cannot host real terminals

1. What was done

Bug: the “Position automatique” button (SortTerminalStripCommand::sort()) sorted terminal labels as plain strings. A label such as XAUZ1:10 does not start with a digit, so the old ^\d+ regex never matched and the code fell back to string comparison. The result was XAUZ1:1, :10, :13 … :19, :2, :20. The int/string mix was also not a strict weak ordering, which std::sort requires.
First attempt: QCollator with setNumericMode(true). It did not work: with a Qt build without ICU (tested with Qt 6.4), numeric mode is ignored, even with the default locale.
Fix: a new QETUtils::naturalLessThan(), a hand-written natural comparison. Digit runs are compared by value, the comparison is case insensitive, and 1 comes before 01 on a tie. I tested the logic with Qt 6.4: it gives :1, :2, :3 … :9, :10, :11 and 1AUZ1 < 01AUZ1 < 2AUZ1 < 10AUZ1, with a consistent ordering.
Used in: SortTerminalStripCommand, FreeTerminalModel and TerminalStripTreeDockWidget (strip names and free terminals).

2. Why the strip plan cannot host real terminals

The strip plan is not an element. TerminalStripItem derives from QetGraphicsItem and its content is painted directly with QPainter by TerminalStripDrawer::paint(). The drawer only receives abstract interfaces (strip, physical terminal, real terminal, bridge) and draws rectangles and text.

As far as I can tell, conductors attach to Terminal objects, which belong to an Element and come from the PartTerminals of its definition. The strip plan has no element definition, so it has no Terminal objects for a conductor to attach to. Drawing a “terminal” in the plan only adds pixels.

Adding terminals to the plan would mean either:

turning TerminalStripItem into an element-like item that creates and owns real Terminal objects, one or two per physical terminal, positioned from the layout and kept in sync when the strip changes (reorder, group, bridge); or
generating a static element from the strip, as the external tool qet_tb_generator does. That gives real terminals but a frozen symbol: no live xrefs, and positions do not follow the strip.

3. What we want to achieve

Draw a symbol per terminal type (fuse, disconnect, diode, ground, LED), adapted to the cell width. A fuse with LED shows both.
Real connection terminals at the top and bottom of each terminal rectangle in the plan.

Cable and wire display as in the qet_tb_generator tutorial. Columns: HOSE (cable name, e.g. 9W2, shared by several terminals) and CONDUCTOR (wire mark). A single connection at the top, and at the bottom a cable drawn with its input wires, its name, its output wires and the shield (SH) as a dotted ellipse.
Cable data (wire colour or wire number) can be exported from a spreadsheet, so the cable and wire columns can be filled from existing cable lists instead of being typed by hand.
The plan must stay live: xrefs and positions follow the strip.

[arummler]

I would say this is part of the discussion in #1267 and #1158 and others regarding differenet kinds of schematic (views), how to represent them internally and whether to have linked element views.

I saw your change regarding functional (diode & Co) terminals: that's good but complex terminals are still not covered. E.g. a terminal element with two anti parallel diodes (available from Wago or Phoenix) where one potential is connected to e.g. connection points:

• requires a logical (generated?) symbol showing the situation
• requires a physical symbol showing the contacts and where real wires are connected
• on the logical level internal connections should be known

[arummler]

Cable and wire display as in the qet_tb_generator tutorial. Columns: HOSE (cable name, e.g. 9W2, shared by several terminals) and CONDUCTOR (wire mark). A single connection at the top, and at the bottom a cable drawn with its input wires, its name, its output wires and the shield (SH) as a dotted ellipse.
Cable data (wire colour or wire number) can be exported from a spreadsheet, so the cable and wire columns can be filled from existing cable lists instead of being typed by hand.

That has to be covered by the cable manager which also has to provide for more complex cables. See e.g. figure 83 in IEC 61082-1

[Kellermorph]

Cable and wire display as in the qet_tb_generator tutorial. Columns: HOSE (cable name, e.g. 9W2, shared by several terminals) and CONDUCTOR (wire mark). A single connection at the top, and at the bottom a cable drawn with its input wires, its name, its output wires and the shield (SH) as a dotted ellipse.
Cable data (wire colour or wire number) can be exported from a spreadsheet, so the cable and wire columns can be filled from existing cable lists instead of being typed by hand.

That has to be covered by the cable manager which also has to provide for more complex cables. See e.g. figure 83 in IEC 61082-1

I'm currently working on designing a cable manager. And yes, that was exactly my idea. Using the cable manager, I enter the cable into the line on the schematic, and it can then be automatically transferred to the terminal diagram as a cable, including the wires in the terminals.

[scorpio810]

I needed it for my work, and qet_tb_generator couldn’t be used because sorting by label is too time-consuming, so I took Joshua’s work and improved it for my project. And so push it for all QET guys.

[scorpio810]

I haven’t heard from Joshua (the lead developer) for several months now; he’s set about building a terminal block manager – a highly complex task – on his own and without the help of AI, as is the case today, just as it was when he first started working on it. Rather than leaving the code faulty and abandoned, I decided to improve it, as I needed it.

[scorpio810]

Rather than keeping the code to myself, I thought I’d share it with all our users – is that a problem for anyone here...!?

[ispyisail]

Push it

[scorpio810]

I saw your change regarding functional (diode & Co) terminals: that's good but complex terminals are still not covered. E.g. a terminal element with two anti parallel diodes (available from Wago or Phoenix) where one potential is connected to e.g.

[arummler]

How would you e.g. draw this one:
https://www.wago.com/global/rail-mount-terminal-blocks/component-terminal-block/p/2002-2214_1000-490

or this one
https://www.wago.com/global/rail-mount-terminal-blocks/3-conductor-sensor-terminal-block/p/2000-5311_1102-950

There are a bunch of speciality terminals including pluggable rectifiers, etc.

[arummler]

Ideally it should be clear what is connected between which terminal ports. Otherwise one needs to look up product numbers to understand the circuit and the schematic is no longer sufficient.

[scorpio810]

How would you e.g. draw this one:
https://www.wago.com/global/rail-mount-terminal-blocks/component-terminal-block/p/2002-2214_1000-490

or this one
https://www.wago.com/global/rail-mount-terminal-blocks/3-conductor-sensor-terminal-block/p/2000-5311_1102-950

There are a bunch of speciality terminals including pluggable rectifiers, etc.

You use it?, me not!
How these terminals was drawn in other electrical software?

[arummler]

You use it?, me not!
How these terminals was drawn in other electrical software?

Well, yes. I tried QET and ran exactly into this problem. In the schematic I drew then two diodes and a box with explaining text around it even that workaround totally back fires regarding BOM, etc.

[scorpio810]

Short answer: with what is in master today, I can’t draw them properly.

At the moment a terminal has one type (fuse, diode, LED, ground, anti-parallel diodes…) and the strip plan draws one small symbol for it. That works for a simple diode or a fuse with LED. It says nothing about the inside of the terminal, so it is a stop-gap, not a solution for your two examples.

From the product pages (I only have the titles, not the internal diagrams):

2002-2214/1000-490: double-deck, 2 diodes 1N4007, anode on top.
2000-5311/1102-950: 3-conductor sensor terminal, yellow LED, for PNP (high-side) sensors.
I looked at how other tools handle this:

EPLAN has main and auxiliary terminals, which lets one housing be represented by several terminals, and a multi-level terminal is defined by a level and a sort code. Its tech tip on variable terminals builds a sensor (initiator) terminal exactly this way: a base terminal plus supplementary terminals, combined into one multi-level terminal.
AutoCAD Electrical (Arkance article) uses custom symbols: fuse, resistor, diode, diode rotated 180°, LED, test link, and for two decks the second terminal is defined as the second deck of the first.
In both, the logical level is one symbol per level or function, with the component drawn inside it, and the part data is separate. I did not find a tool that generates a physical view from a description, so I can’t say how they handle that part.

For QET I would not add more types to the list. I would rather describe the terminal itself:

connection points (id, position: deck, top/bottom),
internal components (type, between which two points, orientation),
internal links (points on the same potential).
The logical symbol and the physical drawing in the strip plan would both be generated from that description. Pluggable rectifiers and other special terminals would be the same model with more points and components.

Open question: where does this description live? In the element definition, or in part data attached to the terminal? That seems to be part of the discussion about views and linked element views in #1267 and #1158, so I would rather not invent something in the strip code before that is decided.

EPLAN, présentation des bornes : https://eplan.help/en-us/infoportal/content/Plattform/2.9/Content/htm/terminalgui_k_start.htm
EPLAN, TechTip bornes à structure variable : https://www.eplan.help/techtipps/en-US/Klemmen/TechTip-Terminals-with-variable-structure.pdf
Arkance, AutoCAD Electrical : https://ukcommunity.arkance.world/hc/en-us/articles/24881332342546-AutoCAD-Electrical-Terminal-Blocks-with-Electronic-Components

[arummler]

From the product pages (I only have the titles, not the internal diagrams):

But the data sheets are on the web site?

[arummler]

Indeed that touches the question of different views and the role of auto generated elements. It goes beyond the concrete drawing so I agree that it requires first a clear definition of the "views" (==schematic types) and how different elements representations are assigned, saved or generated. That includes internal state. The links are interesting.

[scorpio810]

[scorpio810]

https://qelectrotech.org/forum/viewtopic.php?pid=23489#p23489

[scorpio810]

https://qelectrotech.org/forum/viewtopic.php?pid=23508#p23508
https://qelectrotech.org/forum/viewtopic.php?pid=23516#p23516