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é

You mean the table with clickable cross-references?  That is inserted automatically as part of the designator text.  You need to include a dynamic text item with the source "Element information" - "Annotation".

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.

Hallo Fabian,

ich glaube es ist eher so, dass das Feld "+Ort" für Bauteile ausgeblendet wird, deren Typ als "Klemme" definiert ist. Das kommt wohl aus der Philisophie der Schaltplanzeichner, dass Drähte und Klemmen zum Verbrauchsmaterial gehören und der Ort nur für andere Geräte aufgelistet wird. Wäre auch ein Haufen Arbeit, für jedes Klemmensymbol den Ort einzutragen. Stattdessen passiert das dann für die ganze Schaltplanseite.

Hoffe das hilft weiter.

Schöne Grüße
André

5

(8 replies, posted in Import)

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.

6

(8 replies, posted in Import)

Your sample file seems pretty much empty.  Tried to open it with LibreCAD and Inkscape on Linux.  It shows a circle with a vertical line through it, sometimes also some kind of arc on the right side.  I suppose your Illustrator export is broken.

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?

Making it a terminal element, however, has the effect of *ALL* pins having the same potential. I don't think there is a proper way to declare only a subset of pins to be connected.

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é

Hallo Muecke,

das geht nicht nur dir so. Ich hatte genau dieselben Startschwierigkeiten. Habe mich dann daran gewöhnt, dass es eben nur ein "besserer Bleistift" zum Zeichnen ist, kein Werkzeug zur semantischen Interpretation dessen, was man da zeichnet. Es gibt einige kleine Features in die Richtung, die sind auch ausbaufähig, aber es muss jemand die Zeit aufbringen um das in die Realität umzusetzen. Insbesondere die Anpassung der bestehenden Bibliotheken auf neue Programmfunktionen ist eine schier unendliche Aufgabe.

Ich frage mich, wie es im Vergleich zu anderer Software da aussieht. Ich hatte schon EPLAN-Schaltpläne vorliegen, wo Verweise nicht gestimmt haben (also ein "Label", was woanders hin verbinden soll, aber nirgendwo wieder auftaucht) und Signale auf unterschiedlichen Seiten unterschiedlich benannt waren. Keine Ahnung, ob der Zeichner bloß geschlafen hat, oder oder ob tatsächlich auch der Marktführer da nicht viel mehr als einen Bleistift bietet und eben keine logische Verknüpfung intern, so dass auf Konsistenz automatisch kontrolliert werden kann und die Daten strukturiert ausgewertet werden können. Für Letzteres (Beschriftung für Klemmenpläne) habe ich mir deshalb mein eigenes Skript gebaut und es wird auch fleißig am Klemmengenerator gearbeitet. Beides wurde dir im anderen Topic (https://qelectrotech.org/forum/viewtopi … 779#p18779) auch verlinkt.

Bei KiCAD funktioniert das mit der semantischen Kontrolle schon deutlich besser, da ist das A und O die "Netzliste" um später auch die Platine abzugleichen. Dafür wird man dort z. B. keine Ansichten von Schaltschränken zeichnen, wofür QET als reines "Zeichenprogramm" eben auch taugt.

Die Probleme mit der Bibliothek und eigenen Teilen zeichnen kann ich gut nachvollziehen. Egal bei welchem CAE-Tool, meiner Erfahrung nach muss man sich relativ schnell vom Gedanken verabschieden, alles aus bestehenden Bibs bestreiten zu können. Selbst zeichnen ist an der Tagesordnung. Etwas mehr Standardisierung würde da helfen, beispielsweise Steckverbinder männlich und weiblich mit Polzahl 1 bis 30, am besten automatisch generiert. KiCAD hat da enormen Aufwand in entsprechende Regelwerke und Generatoren gesteckt und deren Standardbibliothek wird laufend aufgeräumt und systematisch erweitert. Das ist aber eine Monsteraufgabe, insofern muss man froh sein, dass überhaupt so viele Nutzer ihre Elemente für QET offen zur Verfügung stellen. Auch wenn es dadurch sehr chaotisch ist im aktuellen Zustand. Letztlich muss jeder seinen eigenen Weg und Stil finden und für sich definieren, inkl. entsprechende Elemente entwerfen.

Ich habe meinen Weg in Bezug auf die Verknüpfung von Elementen z. B. hier beschrieben: https://qelectrotech.org/forum/viewtopic.php?id=2548. Es wäre natürlich toll, wenn solche Workflows standardisiert würden und die Bibliothekselemente dann gleich darauf angepasst. Aber zumindest aktuell ist es eben eher ein Zeichenprogramm mit Schablonen, die Andere dankenswerterweise geteilt haben.

Die Plattform für Fragen und Kontakt zu den Entwicklern ist schon ganz richtig hier das Forum. Ich würde allerdings Posts auf Englisch empfehlen. Die Hauptentwickler sind aus Frankreich, leider reicht mein Französisch aber sehr selten, um den aktuellen Entwicklungen zu folgen. Bevor jeder ständig den Übersetzer anwerfen muss, wäre mein Ansatz, wie in der Softwarewelt üblich, sich auf Englisch zu einigen.

Hoffe das hilft dir weiter und weiterhin gutes Gelingen mit der Einarbeitung!

André

Greg wrote:

Is there a way to have some variable that can be used for the label of the PLC that can be also used for the digital input so that both labels can be updated automatically?

I've been using the "Function" field of the wire to store what the channel is assigned to.  It works quite well together with folio references, which you can define and style yourself.  A folio reference can include a dynamic text element for its "Function" attribute, which automatically displays the Function of the connected wire (on both ends when linked together).

Attached sample project shows a little of this in action:

1. A physical view of each PLC component. This is declared as a "master" element type so that others can be linked to it. The linking results in a nice table of references where this component is referenced.

2. A logical view of each connector of the PLC components. These are declared as "slave" element type and get linked to the physical view. That automatically makes the master's properties available for text display, such as the module type and of course its ID (with a back-reference to the folio with the physical view).

3. A generic "signal description" element declared as type "previous_report".  It has a single pin that gets connected to the logical PLC connector element.  This connection (wire) then gets assigned a Function attribute naming what the channel is used for.  It automatically displays the Function and has a spare text field by default that is used to record the logical input / output number as a reference for the software developer.  These pages give you a nice overview of what channels are assigned and for what they are used.

4. The opposite "next_report" element type is drawn as a "channel header". It gets inserted wherever in the schematic the channel is needed (though limited to one place per channel).  It again has a dynamic text field displaying the Function attribute value.  Link this element to the previous one, which is rather easy to do because the possible link targets table shows the Function value, so you just need to pick the semantic name you've given the channel's signal.  Note that this "header" element could be used stand-alone, connecting its pin to the sensor directly.  But that doesn't work for the case of analog differential or RTD inputs, where several pins are required for the channel.  Thus there's a standardized "channel body" element as well, see below.

5. The "channel body" element exists in different variants, for example 1 to 4 used pins.  It is declared as element type "slave" again, to be linked to the physical module representation.  That makes it clear where the signals are connected to, and pulls in the referenced module type attribute again, so you easily see that it's an analog input for example.  It has an almost unnoticeable pin on the top-left corner which is designed to automatically connect to the "channel header" element, to make sure there's a connection and the Function attribute is actually displayed.  For the individual pins, there are separate text fields to describe exactly on which terminal of the module the channel resides.  This is unfortunately still a manual process, you need to jump back to the linked "signal description" (just double-click the folio link), remember which terminal(s) the signal is connected to, jump back (another double-click) and adjust the texts.  Doing it manually has the advantage that you can pick the order for multi-terminal channels, such as 4-wire RTD inputs, to untangle your connections.

It's a bit of work to get the PLC-specific parts set up first (because the existing library symbols have no master-slave relations there), but I think it's worth the effort.  Remapping a channel is done with a few clicks and some manual text updates.  Note that if you really need the same channel referenced in more than one place in your schematic, you could still place more "signal description" elements connected to the same PLC terminal.  I've done that for Modbus channels for example, where it nicely summarizes references to all Modbus-connected sensors.

Overall I guess I'm a programmer, used to stuff being generated for me based on a single declaration, and error-checked by the compiler.  QET is more of a "smart pencil" so I wanted to make as much as possible automated and linked together to avoid mistakes and mismatching references.  More features in this direction, allowing to link stuff together on a semantic level, would of course be great.

Wow, this seems a major burden and a piece of work to support Apple.  Frankly, I would have stopped supporting the platform at all after all these troubles.  Not a big fan of the company anyway, but charging developers to allow users running their software is just... rude!  In the early computer days, some hardware vendors had a market advantage because they made it easy for software developers to write programs for their platform.  Somehow for a company of Apple's size, these economic mechanisms don't work anymore.  Except if people start sabotaging this madness and just stay away from Apple, especially those people putting in their volunteer work to publish open source software.

Enough ranting...  I didn't understand everything in this thread, unfortunately, since my French is very rudimentary. I'd be happy if more posts could stick to English language, as it's more accessible to the rest of the world ;-)

scorpio810 wrote:

BTW I can't create python package with your code.

As you've shown now, it's quite easy to use.  If we ever need to distribute it in some other way, I'll look into creating a proper runnable Python package.

Happy it worked for your project, are the results correct?  I see there are mentions of a terminal block "XI", but there is no diagram for it.  Is that a connector on some device?  Of course the results there are wrong because the label "XI:24E2" is interpreted by SQLite as having the number

24e2 = 24.0 * 10^2 = 2400.0

Thus it generates these 2400 rows for that block.  You'd need to fix up the naming there to use only integers after the colon.  The other blocks seem fine, just that your existing diagrams actually do have duplicates, e.g. XANA:2.  What does it physically look like, are there two terminal strips next to each other, or is it actually just two connections to one strip?

Thanks for the AppImage pointer, that's actually what I'm using right now.  Just that flatpak notifies me about upgrades automatically and I prefer using it (over e.g. snap) for most software.  Hope you can resolve the build issues.  Wouldn't you just need to adjust the patch in the upstream QET repository, instead of the flathub repo?  Haven't looked closely, but that's where I would have started to look.

Compared to the existing plugin, as I tried to explain, my tool simply collapses all terminals with the same label into one row, whereas qet_tb_generator will duplicate the terminals (see repeated numbers in your screenshot).

And it doesn't insert "missing" terminals in between (number gaps), which we often have when leaving some spare room for connecting later additions.

What both tools cannot do is guess how many more spare / unused terminals there are beyond the highest number found.  That's why I went for drawing the block manually and only generating the labels.  This issue is similar to the "fill in the gaps" feature above, but cannot be solved as easily.

As a final point, we often use terminals with e.g. 4 connection points to distribute the same potential (usually GND, 24 V).  The existing plugin AFAIK only generates one terminal "slot" per reference, you can't tell it that the elements -X10:1a and -X10:1b are actually on the same terminal.  We just put this info into the elements' extra text field, separate from the label.  The terminal strip diagram then just lists the refs in no particular order, but where it's defined in the schematic, you always see which connection point was used (a, b, c, or d).

I hope the future QET-integrated version will address these points (multiple mentions of same terminal; spare terminals in between; spare terminals at the end; more than two connection points). Then it will be suitable for my use-case.

That looks pretty cool indeed, thanks for pointing it out. I'm eager to try it out in the next released version.

Until then, I need a stable solution though, based on software that I can point a customer to - no development version which is a moving target and things might just stop working at some point because they were generated with an intermediate development snapshot. Sorry I can't get much more involved with QET development, but rather just consume the stable version releases as they come. What a great software by the way, thanks to all the people making this a reality as FOSS!

Publishing my own little addition as FOSS is my way to give back to the community for being able to use a completely free CAE drawing software.

There is already a "terminal block generator" plugin for QElectroTech, but it didn't quite fit my needs.  I needed a simpler approach which just references the positions where the terminal elements are defined.  And I use the same terminal strips label (e.g. -X10:4) possibly several times, because each strip has at least two connection points that may not belong on the same folio.  The existing plugin would generate repeated terminal strips for this case.  Also the handling with closing the project to find the generated elements, etc. seems cumbersome.

Hereby I introduce my little open source project "HTML Table Generator From QElectroTech Terminal Elements", or qet_terminal_tables for short.

It works by reading the SQLite database exported from the QET project, then outputting HTML code to a separate file for each block of terminals.  The elements must be labeled with a colon separating the block name from the terminal number (which should be an integer).  The HTML code can then be copied into the Source tab of an HTML-styled text field in the original QET project.  This can be placed next to a drawing of the terminal strip as desired, which ideally has a 20 pixel grid.  Styling is rather limited because of the HTML subset supported by Qt, but a CSS file can be referenced to customize the appearance.

The Python code and docs can be found on GitHub at https://github.com/acolomb/qet_terminal_tables together with a sample project.  Attached is a screenshot.

I tried to keep the code clean and maintainable, but it's not yet properly packaged with versioned releases.  Help with building a proper Python package is very welcome, as are other suggestions and contributions.

Have fun with it and tell me your experiences :-)