Search options (Page 1 of 2)

That label is the cross-reference back to the "master" device, which can be double-clicked to jump there. It is automatically attached to the "label" dynamic text of the element. So you need to be careful where you place that text.  For the master, it will extend to a list of bound slaves, with one folio reference per slave, also showing the slave's "contact type" property symbolically.

As for contributing the elements, sure you can make a pull request to include it in the standard library, if the quality / consistency is acceptable. However, this pattern of master-slave relationships between the physical and logical symbols is not common among existing library elements.  If you have for example mostly circuit breakers, for which the official library symbol already defines an according element type (master / organ of protection), then it would be kind of useful. But imagine someone not wanting to link it, they could not even give your element a label (as that is not independently possible for slaves). So it would limit the utility of the whole element.

I started doing some experiments using the new terminal block functionality as well.  I really like the new workflow and looking forward to making use of it.  So first a big thank you to Joshua and keep up the good work!

But there are some basic conceptual / design issues where I simply don't see how this can be applied to my schematics.

For connections to external equipment, where one terminal block has the outside cabling 1:1 on the bottom row, with connections to internal ports on the top row, I think this works pretty well already.  But beside the numbering / sorting issues here, I think we should consider how the terminal symbol's label is handled / parsed.  I put some terminals on the folio, e.g. "X10:1" to "X10:12".  These need to be labelled on the folio itself, at least once with the block (X10) and each terminal with the number.  So each terminal symbol already has all the info contained, where the block and number are separated by a colon ":".

The way it is shown in the last video link, each terminal only has its number as the label.  But this means that on the folio where it is placed, there is no actual hint on which one it is, as the number could appear on any block (e.g. "X10:1", "X21:1", "X25:1").  In addition, not having the block naming in each terminal's label makes it impossible to automatically process them, like generating overviews (as with my qet_terminal_tables script) from the database.  So I think the traditionally used labels like "X10:1" are the better approach.  I could see the terminal manager to automatically parse the first part (prefix) to move the terminals to the correct group.  Then the label *within* this group should just be the number (suffix).  At that point, sorting would work again as with simple numeric labels.

The second problem I see is that each terminal symbol generates its own entry in the manager.  There is some special handling for multi-level terminals, which is nice.  But what about potential distribution, where you need a central GND or +24V terminal block to connect all the equipment, each device with one wire.  The devices will be shown on different folios.  I'll use both connection points of one terminal (or even 3 or 4 points with the larger ones) in very different places.  So the terminal "X10:1" will be placed twice, on two different folios, with the same label.  What I usually do is to put a "1a" or "1b" text on each, to show which connection point (top or bottom) the wire ends at.  Even worse, with four connection points there will be "1c" and "1d" as well.

In that case, there will be four terminals shown in the terminal block manager, which really all represent the same physical element.  Just that its four connection points are used for wires to independent devices.  How would I handle that, so the generated terminal block drawing has only one column for all four of these connections?  Ideally, it should show the cross-reference (folio number) for each associated symbol, but only one physical "slot".

This is really about the data model used by the terminal manager.  I guess several terminal *symbols* with the same label should be grouped automatically and only result in one generated *physical* terminal.  Properties like terminal kind and function should be synced among the group, unless the entries are assigned to different levels.

@Joshua, what do you think about this?  Are there plans already to handle such cases?  Frankly I don't see how the current data model maps to anything but the most basic schematics with only a handful of terminals.  Failing to sort by numbers is only one symptom of this, because the labels are not "interpreted" in any way.

Wunderbar, vielen Dank!

Ich werde es mir bei Gelegenheit anschauen, was aber noch länger dauern könnte. Jedenfalls aber mal abonnieren, was in dem Repository vonstatten geht.

Klingt in Summe ziemlich nützlich und ich bin froh, dass hier Bewegung in die Sache kommt. Auch, dass meine Idee mit den HTML-Tabellen Anklang findet. Leider habe ich momentan viel anderes um die Ohren, im privaten Leben und anderen Open-Source-Projekten. Zudem in letzter Zeit kein Projekt, wo ich überhaupt mit QET arbeite.

Ich wünsche euch daher erst mal viel Erfolg. Stehe gern auch für Rückfragen und Meinungen zur Verfügung, aber leider eben nicht zum weiter daran coden.

The question was more about the mechanical CAD part I suppose.  In that case, have a look at LibreCAD or FreeCAD.  For some easy cases, SolveSpace might also be convenient.

Ein Tutorial weiß ich leider nicht auf die Schnelle, aber wenn es eines gibt, hilft Google bestimmt beim Finden.

Zur Benutzung generell: Die Klemmen müssen bereits im Schaltplan gezeichnet sein. Die entsprechenden Bibliothekssymbole vom Elementtyp "terminal" müssen platziert sein und ein BMK in der Form X00:1 haben. Sprich, eine Bezeichnung des Klemmenblocks und nach dem Doppelpunkt die Nummer der Klemme. Daraus werden dann die Blöcke im qt-terminal-generator erzeugt.

The HTML support is limited by the Qt toolkit.  You might want to check https://doc.qt.io/qt-5/richtext-html-subset.html for the tags and styling it supports.

Hi there,

you didn't actually attach any file.  But I suspect you simply need to edit the "title block" used for your folios.  The defaults contain translatable labels usually.  Could be missing a Portuguese translation there, however.

Kind regards
André

Da kannst du wahrscheinlich nur ein eigenes Bauteil erstellen, das nicht vom Typ Klemme ist. Damit verliert es aber auch die Eigenschaft, dass alle angeschlossenen Drähte gemeinsam aktualisiert werden, also eine logische Verbindung der Potenziale in QET erfasst wird.

In einer kommenden Version werden die Felder auch bei Klemmen-Bauteilen verfügbar sein, wenn ich das letztens richtig gelesen habe.

Open it in QCAD (or LibreCAD, almost the same) - not in QElectroTech.  Then the instructions apply.

To save this step in the future, teach your Illustrator to not make DXF "blocks" from grouped elements or shapes.

Sorry die Bilder schaffen mir keine zusätzliche Klarheit. Was genau willst du erreichen? Das ist doch ein Relais und alle Kontakte sind normalerweise völlig unabhängig?

Hallo Muecke,

wenn du dein modifiziertes Bauteil ein weiteres Mal aus der Bibliothek platzierst, wird es im Projekt angepasst und beim nächsten Öffnen siehst du überall die neue Version.

Das funktioniert allerdings nicht für die Texte. Diese werden für jedes platzierte Bauteil separat gespeichert und nicht mehr aus dem Template Element aktualisiert. Eine Möglichkeit, das zu umgehen, wäre die Texte einer neuen Instanz als Textkonfiguration zu speichern. In den alten Instanzen kann diese dann wieder geladen werden, wobei die Option "alte überschreiben" (oder so ähnlich) aktiv sein sollte. Sofern die Bauteile sich nur in Texten unterscheiden, die über Attribute definiert sind, geht das recht problemlos. Jedenfalls müssen keine Verbindungen neu gezogen werden.

Viel Erfolg und schöne Grüße!
André