For "moving" text-positions:
Use latest 0.100-dev - version!

did you go through the element-tree a bit?

see attachment

Hallo Achim,

Ich wollte nicht sagen, dass der Code nicht besser ist als vorher!
Wir kommen der Sache näher, sind aber noch nicht am Ziel!

Wenn beim Kopieren Positionen auf unsinnige Werte gesetzt werden, muss das selbstverständlich behoben werden!
Es kann aber auch nicht schaden, wenn wir das beim Speichern der Daten ins XML nochmal prüfen...

Wenn die x- und y-Positionen, die zum conductor gespeichert sind, offensichtlich keine Rolle bei der Lage des conductors spielen:
Warum setzen wir die beim Speichern nicht grundsätzlich zu "0", wenn sie negativ sind?

In meiner Testdatei habe ich spaßeshalber die x- und y-Werte mal auf ganz unsinnige Werte größer Null gesetzt, und der Plan sieht beim Laden aus wie vorher!

Einen Patch für die Korrektur habe ich in meinem github-Repository vorbereitet.

Hallo zusammen!

Ich habe nochmal ein wenig mit der Verweise.qet gespielt und etwas interessantes gefunden.
Dafür habe ich die Datei verkleinert, um den Effekt näher einzugrenzen --> "Verweise_reduziert.qet" im Anhang.

In den Folio-Einstellungen ist "Nur eine Potenzialbeschriftung je Folie anzeigen" eingestellt.
Beim Öffnen der Datei wird oben ein breiter Rand angezeigt.
Wenn der Haken bei "Nur eine Potenzialbeschriftung je Folie anzeigen" nicht gesetzt ist, gibt es keinen Rand beim Öffnen der Datei!
Haken ins Kästchen wieder rein --> Breiter Rand beim Öffnen!

--> ziemlich merkwürdiges Verhalten!

Dasselbe, wenn ich die Leiterbeschriftung wegnehme: --> Kein Rand!

30

(1 replies, posted in Elements)

There is no attachment at your post.
I only see a link to a jpeg-picture, that cannot be used as a QET-element.
If you want to attach elements to a post: Attach a zipped file of the elements.
(create post -> Preview -> Choose file -> Add file)

Hallo Achim,

achim wrote:

In den neuen Versionen von QElectroTech ist ein Patch integriert,
der das Problem mit dem kopieren von rechtsbündigen Text beheben sollte.
Also bitte mal fleißig testen!

für mich sieht das mit den kopierten Referenzen nach einem schnellen Test ziemlich gut aus!

Bist Du der Ersteller des PullRequest?
Im selben PR wird die Reihenfolge beim Einlesen der QET-Datei abgeändert:

ChuckNr11 wrote:

Manchmal gibt es das Problem das oberhalb und links vom Diagramm ein Freiraum entsteht. Den Freiraum kann man nicht entfernen kann. Es wurde ja schon vermutet das kopieren eine Rolle spielt.
Und tatsächlich konnten an dieser stelle im Code, beim Kopieren, sehr hohe negative x- und y-Koordinaten bei den conductoren entstehen die dann zu einer Verschiebung in der Scene geführt haben. Dieses Problem dürfte meiner Meinung nach jetzt nicht mehr auftreten.

In einem anderen Zusammenhang habe ich die anhängende Datei erstellt, bei der der Effekt (versehentlich) sehr deutlich zutage tritt ... trotz des XML-Patches.

You want to work with a program you're unfamiliar with, but you don't seem interested enough to even play around (with a minimal circuit diagram or a copy of the original diagram) using the options the software offers?
I don't understand that!

You've already found the option to make the conductor two-colored: take it one step further and try out the options in the other tabs of the conductor properties!

BTW:
Do you know this part of QET-Website?
https://download.qelectrotech.org/qet/m … index.html

Do your elements have terminals?
(recognizable by the blue-red coloring – see screenshot)
Then you can draw a connection from one such connection to another.
Afterwards you can double-click the connection to enter the potential, line type, etc.

In the screenshot the view is "slightly" zoomed to two lamps and the mouse-pointer is hovering over a terminal. When the end of a terminal changes to a blue circle, you can click and drag to another terminal.

Can you copy electrical connections in real life? nomicons/wink

QElectroTech is not a drawing program that you use to draw lines: you create electrical connections between terminals or clamps.

So you pull a connection from one terminal of an element to a terminal of another element.


Of course, you need to have a QET file to do this!
Other formats are not (yet) supported!

Salut Laurent !

scorpio810 wrote:

I build new QET_ElementScaler 0.5.4 macOS aarch64 binary, because binary provided by plc-user didn't work!

Thanks for the information!

That is good to know:
Then I can save myself the effort of building and uploading these packages in future!
As written in release-section:
I can't test the macos-binaries myself anyway. And if they don't work, I don't need to create them any more...

36

(209 replies, posted in Import DXF)

Hi vadoola!

Good to hear, you're ok (again)!

Can you please create win- and/or Linux-Binaries for dxf2elmt and put them also into the release at github?
So everyone gets the Software from "first hand"!

37

(7 replies, posted in Elements)

gts automação wrote:

Tenho uma uvida de como convertr elementos da biblioteca de dxf para qet. inclusive até um projeto inteiro de dxf para qet. Alguém saberia como faz?

In other words: You want to Import DXF!
There is a separate part in this forum that handles that topic.

In that part of forum you can find (among many others!) this post: https://qelectrotech.org/forum/viewtopi … 123#p21123

You can import dxf to create elements. Importing entire plans is not supported.

Recommendation: As a new user of QElectroTech you should use latest 0.100 - dev - version!

Not knowing, what you would like to save on other people's hardware ...

If you used forum-search with the keyword "cloud" you would have found this post (among others):
https://qelectrotech.org/forum/viewtopic.php?id=2969

We had that discussions before.
1. "Internal connections" inside of an element are not supported yet.
2. The line coming to a switch is electrically different from the line that is switched! Same applies for circuit-breakers, etc.

The online translation is not clear enough ...
Do you mean that the inside-connection of an element automatically uses the color of the connected wire?
No, the elements are static in that respect.
To use colors in elements, you need to create user-specific elements.

To edit multiple conductors at a time is (currently) not supported.

That sounds like you should develop a backup strategy...

As soon as the file is saved, the old information is gone!

plc-user wrote:

Absehbar wird daran aber erstmal nix geändert: Habe (leider) andere Sachen zu tun...

Das stimmt dann doch nicht nomicons/wink:
Habe das Programm ein wenig erweitert, um die ausgegebene Tabelle soweit wie möglich anpassen zu können!
Die vollständige Beschreibung ist im anderen Post geändert und sowieso im github-repository verfügbar.
Wie bislang sind die Brücker in der Tabelle (vgl. Anhang) nachträglich per Hand eingetragen.

@achim:

Ich möchte hier nur meine Beobachtung und eine Vermutung kundtun.
Vielleicht hast Du ja dasselbe festgestellt und bist dem "auf der Spur"...

Beim Kopieren von dynamischen Texten tritt der gleiche Effekt auf, den wir auch bei der nachträglichen Ausrichtung von Texten sehen:
Qt-intern wird die Text-Position unabhängig von der Ausrichtung des (dynamischen) Textes immer an der sogenannten "Bounding-Box" links oben verwendet und die Information "Ausrichtung" wird intern nicht weiter verwendet.
Deswegen ist es auch nicht möglich, nachträglich die Ausrichtung von Texten zu ändern!

Dieser Effekt betrifft selbstverständlich auch z.B. die Verweis-Position von Querverweisen.
Wird der Querverweis mit einem Gegenstück verbunden und der Positionstext eingetragen, verändert sich intern die Position des Textes! Wird dieser Querverweis dann kopiert und wieder eingefügt, steht die Textposition auf dem Wert, als ob der Text mitkopiert wurde ... wird er aber nicht!
Also stimmt die Textposition bei dem eingefügten Teil nicht mehr.

Nachtrag:
Anhang vergessen, mit Beispiel für den beschriebenen Effekt.

Moin Marcel,
glaubst du ernsthaft, dass sich jemand zurückhalten würde, um eine Lösung zu veröffentlichen?!?
Dass es blöd ist, um einen Fehler herum arbeiten zu müssen, weiß ich auch!
Achim arbeitet (in seiner Freizeit!) an einer Lösung und da sollten wir ihn nicht bedrängen!

acolomb wrote:

Wunderbar, vielen Dank!

Bitteschön! nomicons/smile

Gib' gerne mal Bescheid, was Du damit anstellst!
Bin ja neugierig, wo meine Sachen Einzug finden!

Absehbar wird daran aber erstmal nix geändert: Habe (leider) andere Sachen zu tun...

acolomb wrote:

Wäre es zu viel verlangt, den Quellcode auf GitHub oder ähnlich bereitzustellen?

Der Quellcode zum Kommandozeilen-Tool QET_Klemmenplan liegt nun in meinen github-repository:
https://github.com/plc-user/QET_Klemmenplan

Das Compilieren sollte keine besondere Herausforderung für euch sein:
Es liegt die Code::Blocks - Projekt-Datei bei und zusätzlich Shell-Skript und Batch-Datei zum Compilieren auf der Kommandozeile!

Für Leute, die keine Probleme mit der Kommandozeile und der Tastatur haben:
Habe das Programm zum Erstellen von Klemmleisten-Tabellen noch um die Möglichkeit erweitert, eine Kommentarspalte hinzuzufügen.
Dafür ist die Anleitung oben angepasst und die angehängten Binaries natürlich geändert:
https://qelectrotech.org/forum/viewtopi … 797#p21797

Viel Spaß mit der Kommandozeile und dem Programm!

Kellermorph wrote:

Die Vorgehensweise ist nur so ziemlich die selbe, (...).

... im Vergleich zu welcher anderen Vorgehensweise?

Kellermorph wrote:

Irgendetwas scheint da halt noch im argen zu sein.

Ja: Deine Vorgehensweise!
Man muss Regeln befolgen, damit etwas wie geplant funktioniert!

Kellermorph wrote:

Ich mache das etwas anders.

Du merkst selber, daß das so wie Du es machst, NICHT funktioniert?!?

Kellermorph wrote:

Ich bin absolut kein Freund vom Terminal.

Dann ist Dir mit Kommandozeilen-Tools nicht zu helfen...!