Improve (electrical) diagrams

[plc-user]

Another idea for AI experts … now for the Diagram Editor:
I know of many devices that can accommodate a maximum of two conductors per terminal … some even just a single one! However, we don’t currently reflect this in the Diagram Editor: We can connect as many conductors as we want to a single terminal point!

Even sheet references can have multiple conductors connected to them, even though these are purely virtual connection points! In my opinion, only a single conductor should be connectable there! A second conductor, in my view, should only be allowed to connect to another sheet reference to enable potential transfer from one page to the next.

And when I look at some files in examples or in the forum, it makes me cringe: not all of them could be used to generate automated routing rules because “combines,” “splices,” or “thru” elements are used to indicate how the routing should actually be done.

Something like this: “A wire comes from component X1.2 and goes to component X3.5. From X3.5, the next wire goes to component K47.A1.” A wiring rule like this can only be generated automatically if QET automatically inserts corresponding (purely visual!) branches at terminal points and, accordingly, allows a maximum of two conductors per real terminal point!

And we should definitely get @scorpio810’s opinion on this enhancement!

[ispyisail]

Some numbers from the 24 example projects shipped with QET:

• Real terminals: 94 of 4,884 connected terminals have 3 or more wires (1.9 %), up to 19 on one terminal.
• Folio reports: 130 of 399 have more than one wire (33 %), mostly in industrial.qet and m_000.qet.

A hard limit would therefore stop these projects being edited as drawn. Today a symbol cannot store a per-terminal limit, and junction dots are drawn from geometry only — no wire order is saved.

[plc-user]

It shouldn't be necessary to specify a maximum number of conductors at every terminal: Are there terminals on the market that allow more than two conductors to be connected without compromising electrical safety? Off the top of my head, I can't think of any device whose terminals allow more than two conductors.

The wiring order is determined by dragging the conductors in the diagram editor: This does not need to be specified or saved separately.

At some point, we have to break with old routines and question compatibility! As long as it only affects existing sample schematics...

For this feature, I could imagine a checkbox in the project-settings that enables (default value) or disables the limitation.

[ispyisail]

Im having problem with this feature, out of all the things i could build im not convinced this is a killer app

[plc-user]

(...) up to 19 on one terminal.

I'll drop this idea, when you show me a real electric part which allows to connect 19 real conductors to one real terminal-point!

[ispyisail]

I wonder if this should be part of a bigger verification app. A list of possiable problems is created? Then get AI assiatnce to fix the ones you want fixed?

[plc-user]

It should be possible, with less effort, to check right as you're drawing the schematic whether two conductors are already connected to a terminal, and then prevent additional conductors from being added.

[plc-user]

That would even work with existing diagrams that do not yet include this limit, because only new connections would be affected by it.

[itseogo]

So, for example, a motor protection circuit breaker or a contactor with screw terminals—where you can connect a wire to the screw on the left and right of the auxiliary contact—if I use a double-ended ferrule, I can connect four wires to that terminal. I use this method quite often on construction sites.

[plc-user]

@itseogo:

(...) where you can connect a wire to the screw on the left and right of the auxiliary contact (...).

You also say, that this terminal is made for two connectors only!

That also means you need to add another component (double-ended ferrule) to be able to set up the wiring that you do!
In my opinion, this needs to be clearly shown in the schematic so that it makes sense to anyone looking at the schematic who isn't familiar with the actual setup!

And its far from 19 conductors I requested to drop the idea!

[itseogo]

From the perspective of control cabinet and plant engineering, a double wire end ferrule is not an exotic additional component, but rather standard wiring material. Since data sheets usually refer only vaguely to a “screw connection,” it is often only when examining the actual device that one can determine whether a screw-cage terminal—which would not require a wire end ferrule—is installed at all. I simply wanted to outline a real-world scenario in which additional connection points can quickly arise and the 19 terminals are not the only issue.

[plc-user]

Of course, the requirement for 19 terminals is an exaggeration, and I’m also familiar with connections where, for example, cable lugs are used and multiple eyelets are clamped onto a single screw bolt. However, this must be shown in the wiring diagram so that anyone who only has the diagram can see what they’ll find on site.

I’m talking here about the correct scenario, though, where the manufacturer has provided only one or two options for connecting conductors. And if more wires need to be connected, a terminal (-block) has to be used.
Then you won’t have to cut off the second wire and crimp on a new double ferrule when the first wire needs to be replaced for any reason. Unfortunately, I’ve often had to do this myself on-site: I usually installed a terminal to reconnect the conductors if there was enough space and noted that in the printed wiring-diagram.

[neitri]

It might not be all that bad. The example from m_000 shows conductors originating from a single point. In practice, it could be implemented as a single conductor with taps—for instance, by connecting X3:6 to X3:7, X3:7 to X3:8, and so on.

[arummler]

I think this comes back to the discussion about conductors and wired, logical and physical ones. I am afraid that goes even beyond QElectrotech and touches industry standards which are to my understanding not that well differentiated like for the kind of schematics used for PCB design.

In a diagram with "connection dots" the connections can be considered only logical per-se. Why? How is the connection point realized in reality? Double wire in some terminal? Splice in the middle of some wire with a Wago? Strange Y-cable?

For a physical DRC check like that one would need first a proper wire model (we have five discussions currently open about that) and some kind of differentiation between logical and physical schematic pages.

[arummler]

Regarding double sleeves: as mentioned in my post one function of a proper wire definition would include to define "connectors" which strictly speaking a sleeve could be considered as well. Im principle it should then be linked to a physical model and appear in the BOM.

[plc-user]

I’m always surprised by just how misleading words can be!

This is definitely not about adding any exotic components or making obvious things complicated!

I want to be able to see in the schematic where a wire should run from and to, so that the wiring of control cabinets in the workshop is done exactly as the designer intended. This includes ensuring that no more wires than allowed are inserted into a single terminal.

Here’s a simple example:

The wire comes from somewhere on the left and goes to the first switch. From there to the second, and from the second to the third. This is immediately apparent from the diagram and can be implemented by the electrician accordingly. And an automatically generated wiring list would specify it the same way.
The number of wires that can be connected per terminal is limited to two so that such wiring can be created unambiguously. The marked “bends” in the wire are, of course, not meant to be components, but rather the visual representation of the second connected wire, which is automatically displayed by QET in this way.

There was also a discussion with Joshua on this topic in the forum quite some time ago. However, I still don’t have the right search term to find that thread again...

[scorpio810]

Here in France, it’s not very common to see this in diagrams. Only on German projects.

We use a lot of this :

There are therefore two wires per terminal, or sometimes even up to two double terminals if there is a double cage. There is only one wire for the earth terminals. like "entrelec"

[elevatormind]

It's possible to have both a "logical" or "physical" style of drawing connections, if QET can have build-in T-cross symbols that preserves signals/potentials.

With this symbol, you draw an intended way of for a technician to connect wires:

With this symbol, you draw a logical way of connecting signal/potentials:

The way you draw connections in QET would make T-crossings at least a little bit intuitive, right now all T-crossings in QET get the second "dot" symbol. But having a way to change the appearance of the current "dot", say by hovering over it and press "T", to possible ways of showing a T-cross would be welcome for me at least. Four-way crossings would need to be handled in a similar way.
On a side-note, in EPlan Electrical, you actually never draw a connection yourself. You only place symbols and connection "corners", "T-crossings" or "four-way crossings", all connections are then generated automatically between all horizontally and vertically adjacent connection points. It works better than one might think, especially when working with templates to speed up drawing diagrams.

In my experience though, it's sometimes hard to draw an efficient intended "physical" way for a technician to connect all wires, when potentials and signals are spread through different sheets and reference "arrows". The technicians usually try to connect all the wires in the shortest and most efficient paths anyway, no matter how I draw the intended connection paths. So I usually just draw connections with "dots" anyway unless all the signal/potential is on the same sheet.

Another way for a technician to connect all wires, is through a generated "connection list", like an Excel-file or similar (could be a generated pdf as well). There are two ways to generate this list:

1. The connection list is generated directly from the schematics exactly how all connections are drawn.
2. The connection list is generated from a script from the cabinet layout, this would require something like the Freecad plugin. The Freecad plugin could then optimize the connections to the shortest/most efficient paths.

And for the point about having "19" wires to a single terminal, this would require something of a device/part database in QET. One device would then be connected to a symbol through the "Article number" property, and the device would then specify how many wires and what conductor areas are allowed to be connected to the symbols connections points. This is how all the "big" electric drawing programs handle it. A device could also have at minimum a 3D bounding box dimensions specified, as well as a 2D and/or 3D model specified for layout drawings.
A device database should be possible to be implemented without interfering too much with existing code, if a device is simply connected one-way to a placed symbol through the "Article number" property. To have the possibility to specify maximum number of wires connected to connection points, things would be a little bit complicated perhaps. You would either need a "generic" way to specify the order of connection points for a symbol that the device can identify, or you would have to specify "allowed" symbols in the device where the connection point limits are specified.

[ispyisail]

BTW i didn't want to build any of this.

I've gone a bit crazy on some of the other projects so......

A bit of give a take, as we say in english

[plc-user]

The more I think about it and see your interpretations, the more I start to doubt whether the graphical representation using angled branches is such a great idea!
This representation isn’t common in Germany either.
I don’t want to eliminate the automatically generated connection points, but instead the elements that some people use in their circuits as connection points or splices. But that’s yet another topic!

My main point with this suggestion here is that the designer should already be thinking about how the actual cabling should be done. To do that, it’s necessary to limit the number of possible conductors per connection point. And I do NOT want to have to manually update this limit for all terminals on the existing elements: That needs to be done in the diagram editor!

As said before:

As limiting value, I could imagine (in light of this discussion) four: That would mean two conductors in a double ferrule, one pair on the left and one on the right of the screw.

[elevatormind]

The angled branches has it's uses if you want to specify intended wiring paths for wires with larger conductor areas, like 400V supply potentials, in my opinion. But just for regular 0,75mm2 signals/24V potentials, it doesn't add as much use, but doesn't hurt either if they're automatic. The branches would also make it visually clear how the connections area actually drawn in the diagram.

A maximum of four conductors per connection point would be a sane default, two double ferrules per connection point is possible on most devices.
What's on my wish list is the device database, described below to roughly illustrate the use for this case. The device database is complete new feature, not part of the elements database.

• A Phoenix PT 2,5 terminal is in the device database (to be implemented), with a property "Article number" set to "PXC.3209510".
  The device also specifies it has two connection points, each can have two wires connected to it with a maximum combined area of 4mm2.

• A terminal element is placed in a diagram, "Article number" is set to "PXC.3209510".

  • If the element's property "Article number" is found in the device database, it uses the device values for maximum wires/area for the elements connection points.
  • If it's not found in the device database, use a default maximum of four wires connected to each connection point.

If more than max connections are drawn to each of the elements, output a warning of this.
If the elements device is found in the device database, it will also do a check of the combined area of the connections connected to each element connection point.

The hard part with implementing this is for the device in the device database to know which of the elements connection points to use. A Phoenix PT 2,5-QUATTRO device for example would need to have four connection points specified, but a terminal element normally only has two connection points drawn, one up and one down.

Implementing this wouldn't break any existing functionality, the devices are only tied to placed elements via the "Article number" property. It would still be possible to draw a diagram completely without the device database.

Building further on the device database, each device could also have a layout element/3d model specified, if a layout editor ever is implemented. The layout element/3d model could also be exported to Freecad if the layout is done there with a plugin. This is another discussion though.

[neitri]

This is certainly something worth considering.
In the past, when looking at a schematic to troubleshoot a problem, I didn't really care how many conductors were connected. Russian GOST standards don't explicitly show this level of detail on the diagram; typically, a "Phase" line enters the cabinet and is distributed to terminals, relays, etc. Honestly, I don't understand how cabinets were assembled using such schematics back then. There were also terminal block configurations I didn't fully grasp.
My priorities have shifted now; during the design phase, I consider how a single wire might connect to terminals, relays, fuses, and so on.
Another benefit of tracking the number of conductors is the ability to tally the required wire ferrules (specifically, twin-entry ferrules). A single wire requires a single ferrule, while two wires require a twin ferrule. If the wire cross-section is specified, you can generate a table listing the cross-section, the number of connected wires, and the frequency of such connections.
Example:

Cross-section | Connections | Quantity
0.5           | 1           | 25
0.5           | 2           | 10
0.75          | 1           | 6
0.75          | 2           | 30

This makes it possible to calculate the total number of each type of ferrule needed.
In most cases, a T-junction connection effectively corresponds to that twin-entry ferrule.

However, questions remain. There are components—terminals, fuses, relays (just to name a few)—that can be linked using plug-in jumpers. This raises a couple more questions: 1. How should such a jumper be represented on the schematic? 2. How should they be tallied within the project?
Bolt-on jumpers can either share the same terminal screw as the wire or be fastened separately at the center of the terminal, much like plug-in jumpers.

[plc-user]

@elevatormind:

The angled branches has it's uses if you want to specify intended wiring paths for wires with larger conductor areas, like 400V supply potentials, in my opinion. But just for regular 0,75mm2 signals/24V potentials, it doesn't add as much use, (...).

In my opinion, it would make sense to be able to set the “right-angle with connection dot” or “angled branch” option on a per-page basis rather than per project, so that the power section and the control section can be clearly separated.

[plc-user]

@neitri:

There are components—terminals, fuses, relays (just to name a few)—that can be linked using plug-in jumpers. This raises a couple more questions: 1. How should such a jumper be represented on the schematic? (...)

with terminal-strip - manager that creates a separate view of terminals used in your project.

[neitri]

The terminal-strip manager isn't suitable if the fuse is created as a simple component. And what about relays where the A1 or COM contact can be linked using a cuttable jumper?
Just thinking out loud here: is it possible to assign properties to a wire, similar to a element? Things like manufacturer, part number, quantity, and so on.
There are two use cases:

1. Specifying a part number (e.g., PXC.2966786) and quantity; the bill of materials would then reflect the required amount.
2. Cables such as Profibus patch cords or other specific pre-assembled cables; this might involve a single part number or a combination of items (cable + connectors).

[arummler]

Just thinking out loud here: is it possible to assign properties to a wire, similar to a element? Things like manufacturer, part number, quantity, and so on.

That's why we have ca. five discussions open about conductor vs wire and how to call it (cable manager, etc). The physical elements should be separate and indeed have all these properties.

Regarding the terminal blocks: in principle the terminal block is appearing multiple times in a drawing. As a "pin", as the physical object. The latter should allow all kind of bridges or internal elements. E.g. you get a Phoenix contact terminal block with built-in anti-parallel diodes - how to represent? Some of these systems become very complex. Think also of the labelling elements - in principle they should appear in the shopping list. We have currently one terminal block generator built-in and a quite popular external generator script but to cover all options it should be built in and needs far more flexibility.

[arummler]

2. Cables such as Profibus patch cords or other specific pre-assembled cables; this might involve a single part number or a combination of items (cable + connectors).

Yes, or LinkIO:
#936 (comment)

[arummler]

@plc-user Thanks for answering my question with so many details. That's exactly the discussion I wanted to trigger as it defines the whole workflow. We touched that already in discussion about conductors/wires and panel design modules. I will repeat myself as somewhere in these discussions I already gave the example of pcb design and also my concerns. Unfortunately, these discussions always vanish down in the list and new ones gets started - something to be optimized.

My personal impression was that electrical schematics have an astonishing degree of freedom and therefore the question is what kind of "styles" to support and how. For me the PCB design is close: you have a schematic (purely logical connections with connection dots; it does not matter how this connection will be realied), you have a board design (showing exactly how the PCB will be built and assembled; how the connections are really designed) and you might have a 3d model used primarily to design a housing. In some cases you might also export to specialized EMV or thermal simulation programs using this generated 3d model (mostly out of scope for a PCB CAD). Or you might export to PSPICE for an electrical simulation (naturally from the schematic).

The electronics components have equally at least 3 different representations:

• simplified schematic symbol (box with connectors and text); might be even generic e.g. for a resisitor or transistor
• specific housing foot print which is used to define its foot print on the PCB
• a more or less detailed 3d model, e.g. STL

Every PCB program has different workflows: sometimes all three representations are coupled strongly together and stand for a specific device by a specific manufacturer. Sometimes at least 1+2 can be generic and get a device name / manufacturer / number assigned. And then there can be an interface to a data base e.g. to get in-house approved components, replacement parts, etc.

Regarding the workflow: nowadays one starts with the schematic, transfers to the board editor (mode, in some programs that can be a completely different program but that's cumbersome) where the "rat nest" gets drawn into connections. One can also back annotate, ie feed changes done one board back into the schematic. E.g. 0 Ohm resistors added.

Ideally you would have something similar: a logical view (which contacts are connected together), a physical view (how are the they connected, wires are defined, have a name and connector/ferrule, are assigned a manufacturer/type), a 2d view and 3d ciew. Back annotation mean indeed: selected cable types and lengths go back to the BOM (someone needs to order that stuff as well...) as well as DIN rails, shielding ground bars and even the number of ferrules.

[plc-user]

(...) Unfortunately, these discussions always vanish down in the list and new ones gets started - something to be optimized.

English translation follows.

Ich muss mal was Allgemeines loswerden:
Im Moment haben wir so viele PRs und Diskussionen von ein paar Leuten, die völlig unabhängig voneinander so viele KI-generierte Funktionen in QET einbauen (wollen), dass zur Zeit niemand einen echten Überblick haben kann, was gerade alles im Projekt passiert.
Steckt da ein großer Plan dahinter oder ist das wirklich so völlig unkoordiniert, wie es mir erscheint?
Wenn "Ja": Kann man den Plan irgendwo einsehen?
Bitte nicht falsch verstehen: Ich begrüße es ausdrücklich, dass OpenSource-Projekte unterstützt werden, aber Laurent hat es ja auch schon mehrfach gesagt, dass er nicht hinterherkommt, die viele PRs zu reviewen und bearbeiten!
Ich habe es schon aufgegeben, alle PRs zu verstehen und auszuprobieren. Alleine schon die langen commit-Texte, die auch mittels KI generiert sind und so viele schöne Wörter aneinandergereiht haben...
Also:
Ich hoffe, es steckt ein Plan hinter diesen vielen PRs und dass es auch jemanden gibt, der das alles versteht und nachvollzieht!

English translation with the help of DeepL:

Right now, we have so many PRs and discussions from a few people who — completely independently of one another — are (or want to) implement so many AI-generated features in QET that no one can really get a clear picture of everything that’s currently happening in the project.
Is there a grand plan behind this, or is it really as completely uncoordinated as it seems to me?
If “yes”: Is there somewhere one can see the plan?
Please don’t get me wrong: I wholeheartedly welcome support for open-source projects, but Laurent has already said several times that he can’t keep up with reviewing and processing all these PRs!
I’ve already given up on trying to understand and test all the PRs. Just the long commit messages alone — which are also generated by AI and string together so many fancy words...
So:
I hope there’s a plan behind all these PRs and that there’s someone out there who understands and can make sense of it all!

[elevatormind]

Maybe an "ai"-branch could be started, to go nuts with and test new features. Or a new fork. There's a lot of new features happening, I have barely myself tested anything of them. At least all work of @ispyisail gets tagged with @claude, so it's transparent in that way.

[plc-user]

It's not about AI in principle: It's about the mass of PRs and the "great" plan behind the PRs.

[arummler]

Usually, I would not do it but as everybody went nuts with the PRs I went along and started to use GenAI as well. It is strangely addicitive and the results look - superfically at least - great. You can see immediately results.

Many features are kind of standalone / not that important for the overall functionality (like my extension of the graphics elements) and @ispyisail mentioned he was using the this list
https://qelectrotech.org/wiki_new/roadmap
primarily for new features. Additionally, the bug tracker and I believe the forum. In general it looks good at the first glance but clearly it needs to be tested extensively.

Clearly that's not an (value) ordered backlog and no complete user stories. More like a collection of ideas. So the priorities might have been skewed but in the end it is processed so quickly that this aspect probably does not matter so much.

For the big changes of functionality like wires, how an electrical schematic should look like (and whether it should be enforced by QElectrotech), I think some architectur decisions before implementation might be necessary. This discussion here is for me in the moment the most promising.

[ispyisail]

I hope there’s a plan behind all these PRs and that there’s someone out there who understands and can make sense of it all!

I think we are all guilty of too many concepts in one thread

[ispyisail]

At least all work of @ispyisail gets tagged with @claude, so it's transparent in that way.

It can be turned off, i left it on for that reason

I think to myself why did i even touch this thread,

I going to have another go at getting the angles better, if it goes get better i'll remove the feature.

The other option is a button where you manully click the intersection tocreate the angle, what do you think about that?

[plc-user]

As already written:

The more I think about it and see your interpretations, the more I start to doubt whether the graphical representation using angled branches is such a great idea!

[ispyisail]

Im think about removing all the PR based on this thread, are there any that people want to keep test and verify?

[plc-user]

Limiting the number of conductors per connection in #1272 works pretty well!
I just would have liked this discussion to have progressed far enough first that we could really agree on the feature and how to move forward.

[ispyisail]

:( I don't mind small discussions but most of the time they tend to go in circles.

Just build it, if they don't like, delete/modify/edit

[arummler]

Provocative counter argument against everything goes in iterations without any global architectural decision:

What for example, if I introduce in one month a physical wire object and cable type database implemented in SQL and a totally different data structure how to describe cables. Both cannot co-exist (easily) so the old gets kicked out. If someone created drawings or filled cable databases by that time: well, that's now broken, tough luck?

All these parts are connected (and originate in the "philosophical" musing) and in a kick-off I would tend to start drawing a network diagram/ flow chart at that point. That's my main concern: backwards compatibility with data is hard, really hard. That's the same like the discussion about the 2d/3d panel generator where someone pushed ahead with the width/height/depth properties for elements: it is harmless on its own, just another data field, but but if someone starts filling it in the library and then it gets abandondend and replaced by svg and step....

[ispyisail]

I agree, i acknowledge its a problem, im trying see #1267

I've tryed to get project scopes from people with knowledge.......

[ispyisail]

I've just gone back and done a full read and it's really interesting.

It's my view if we adopt IEC standards half these questions will go away. We just follow the book. It will make devopment simpler

BTW I'm running out of stuff to build and fix. Just about finished all issues in github, bug tracker, forum and wiki road map. As some people have mentioned we need testers now.

[arummler]

Could you elaborate? What does it say about logical vs physical? Does it allow an unspecified connection dot? Whether there are different "views" of a schematic and how to differentiate between them.

And then there are the usability and (software) technical questions:

• abstraction conductor / wire / cable definition (I still believe that at least these three are needed
  • e.g. does a logical conductor have a colour (ideal state) and can the color of the assigned core from the assigned cable type (taken from the cable database) differ? If yes: what is shown? Simple example: a two way switch, at least in Germany afaik you are allowed to mis-use blue for a switched phase even if is not recommended.
• what should a cable definition support and how should it be technically realized

Personally I have read at a time the device letter one and found it very open to interpretation. How to classify a device (particularly using the full three letters) is a judgment call and one can arrive at different interpreations.

[ispyisail]

yeah, i might have overstated its value.

[arummler]

And could we keep the structured discussion in this thread before doing a WBS decomposition and going into technical details? There are more and more discussion thread, just about 6-7 concerning wires/conductors/cables, most of them get immediately abandoned without a conclusion.

[abinjoyal]

I think this would be a valuable improvement for the Diagram Editor, especially for making the electrical model closer to real-world terminal constraints. Limiting real terminals to the appropriate number of conductors and treating sheet references as single virtual connection points could also make the diagrams more consistent.
I also like the idea of automatically adding visual branches or splice points where needed. That could make the connection structure much clearer and provide a more reliable basis for generating automated wiring and routing rules. Getting @scorpio810’s input on the proposed behavior would definitely be useful.

[arummler]

In #1267 we are discussing (at least in my mind) a strict differentiation between schematics and connection diagrams. Behaviour like this would then build on top of it but comes later when there is the ground work laid. In the existing state one type of object (a conductor) is supposed to do / enforce contradictory things depending on what the user thinks they actually want.