u can do it with appimagetool.
I build an .sh with all.
you have to adjust the paths etc. in there.
You are not logged in. Please login or register.
QElectroTech → Posts by Kellermorph
u can do it with appimagetool.
I build an .sh with all.
you have to adjust the paths etc. in there.
oh damn. copy mistake.
/QET_Klemmenplan -l Vorlage_MSR.qet >Klemmen.txt
>
I got this result.
did u build an appimage?
...QElectrotech/Projekte/QET_Klemmenplan -l Vorlage_MSR.qet Klemmen.txt
>
Bei mir kommt nur das und gibt keine Ausgabe.
Beim händischen Eintragen bin ich raus, sorry. Das ist viel zu aufwändig. Dann bleibe ich eher bei meinem Tool.
Das steht auch so weit. Ich muss gerade nur noch eine Lösung für eine gebrückte Klemmleiste finden. Aber ich denke, dass ich hier in QET passend zeichnen werde, damit die Funktion sauber klappt.
The Program from Alfonos? No i didnt? Why are u asking?
Was frag' ich auch, was ihr wollt...
Kellermorph wrote:Wenn ich mein Programm ganz fertig habe, (...) und dann auf c++ anpassen?
Nicht mit mir!
Ich werde mich bestimmt nicht in generierten Python-Krempel einarbeiten und das dann auf C++ umschreiben!stefan.helmert wrote:Also, es würde eine Tabelle aller Betriebmittel rauskommen.
Auch: nein!
Gefragt war nach einer Liste für Klemleisten!
Allein bei Brückern sind wir wieder beim Kleimmleisten-Manager von Joshua: Woanders sind die Brücken nicht definiert!
Wenn es nix zum Auslesen gibt, kann man keine Informationen herzaubern!Also könnte als "Übergangs-Tool" sowas herauskommen, was acolomb bereits beschrieben bzw. angefangen hat:
Ein Freitext-Feld mit den Informationen, die im Moment nicht vom Klemmleisten-Manager geliefert werden.Und beim automatischen Herausfinden von "Quelle" und "Ziel" einer Verbindung sind wir wieder an dem Punkt, den ich in einen anderen Post bereits ansatzweise beschrieben habe.
Dazu habe ich mal einen kleinen Plan erstellt und das Problem im Plan beschrieben. Hoffentlich erkennt ihr es!
evtl habe ich mich doof ausgedrückt.
Ich meinte in die Richtung:
Das was das Programm raus schmeißt, ist ok oder braucht noch Änderung xy. Und von da gehts dann los. So dass man einen gemeinsamen Weg findet.
Ich habe mir eine Formel überlegt, wie das Programm die Brücke findet (im Prinzip wie es WSCAD macht).
Ich definiere die Verbindungen mit einer Funktion z.B. 0VAC int
Das Programm geht jetzt die Conductoreinträge durch.
An Klemme X4:1 ist die Funktion 0VAC X4. An Klemme X4:5 ist auch 0VAC X4. Dann muss dort eine Brücke rein.
Bei Klemme X4:2 ist 24VAC X4 und an Klemme X4:6 auch. Dann muss dort auch eine Brücke sein. Allerdings versetzt zu der vorherigen.
Die Brücken stelle ich momentan allerdings nur mit Punkten dar und nicht mit extra Strichen.
Hier muss jetzt der Schaltschrankbauer nachher selbst gucken wie es ganz genau passt(max länge vom Brückenstecker etc.)
Quelle habe ich noch Probleme mit den Slave-Elementen. Deshalb habe ich es erstmal raus genommen.
Das Ziel funktioniert allerdings. Hier werden wieder die Conductoreinträge durchgegangen und dann nachher mit dem y-Wert verglichen.
Da du aber viel tiefer im Thema bist, solltest du evtl vorgeben, wie wir vorgehen könnten.
Aber deshalb meinte ich meine Funktion um eine Grundlage zu finden, welchen Weg wir evtl gehen wollen / können.
Zum Thema "Klemmen neu nummerieren":
Das ist etwas, was nicht jeder Anwender braucht oder will! Das sollte eine Funktion sein, die nur auf Anfrage ausgeführt wird und hat erstmal nichts mit der Ausgabe einer Klemmenliste zu tun, finde ich.Zum Thema "Abzweige", "Verbinder", "Splices", "Sprünge", etc.:
Aus meiner Sicht: Eine Pest!!!
Die sind als Bauteil verfügbar und als Klemmen definiert, sind aber nur für die grafische Darstellung in der Zeichnung nutzbar!
Es sind keine realen Bauteile, die auch das Erstellen eines Kabelplans total unmöglich machen: Wie soll man automatisch unterscheiden, ob das eine reale Klemme ist, oder einfach nur vergessen wurde, ein BMK zu vergeben?
Unter anderem deswegen und wegen der Möglichkeit mehr als einen Leiter an Verweis-Elementen anzubinden, habe ich die Software-Erstellung für einen Kabelplan (vorerst) verworfen: Man bekommt nicht zuverlässig heraus, von wo nach wo ein Draht gezogen werden kann, wenn im Schaltplan z.B. an einem Verweis mehr als ein Leiter angebunden ist und der Ziel-Verweis auch mit mehr als einem Leiter verbunden ist.
Das sollte meiner Meinung nach von QET unterbunden werden, dass dort mehr als ein Leiter angebunden werden kann! Aber das ist ein anderes Thema und Zukunftsmusik...Abzweige, Splices und Sprünge sollten automatisch von QET erstellt werden und nur grafische Elemente (nicht im Sinne von "eingefügtes Bauteil"!) sein! Aber auch das ist Zukunftsmusik...!
Zurück zum Thema Klemmenliste:
Welche Informationen brauchen wir für die Liste?
Und können wir (vorerst) mit wenig manueller Nacharbeit leben?
Dann würde ich eine html-Tabelle aus den vorhandenen Klemmen erstellen, die dann manuell in ein Textfeld eingefügt werden kann. (vgl. Ansatz von acolomb)
Natürlich ist das nur auf Wunsch.
Jetzt kann man die Funktion separat durch mein Tool abrufen, wenn man will.
Ich finde, dass die Abzweige super sind. Es sollte aber dafür eine expliziten Bauteiltyp geben. Das würde es einfacher machen.
Man muss in diesem Fall halt sauber zeichnen, dann klappt es. Läuft bei mir ja schon.
Die Informationen, die man braucht, sind auf jeden Fall Klemmleistennamen und Klemmennummer, wie diese gebrückt werden. Im besten Fall internes und externes Ziel und wenn angeschlossen welches Kabel, welcher typ von Kabel.
Wenn ich mein Programm ganz fertig habe, sollen wir es uns mal zusammen angucken? Gucken ob man damit zufrieden ist und was mehr / weniger soll und dann auf c++ anpassen?
Ich habe das überarbeitet. Jetzt wurde es auch in dem Beispielprojekt von stefan.helmert erkannt.
ich bin gerade noch dran, dass man die Listen direkt in qet integrieren kann.
Danach kann ich ein Update hochladen.
Ein Problem, dass ich noch lösen muss sind gebrückte Klemmen z.B. für XN. Vermutlich muss ich diese in QET anders zeichnen.
Eine Funktion die ich dann auch noch ergänzen wollte, ist dass man massenhaft Seiten löschen kann. Gerade wenn man schon so viele Seiten für die Listen drin hat, dass man nicht jede einzeln anklicken muss.
@stefan.helmert:
Ich weiß nicht, was Du als Ausgabe errwartest, stefan!
Das liefert mein Programm mit Deiner Datei:Label | Position | Type | LED | Function | Function | Text | Tension/Protocol -X1:22 | 1-E5 | generic | 0 | generic | | -W1 | -X1:23 | 1-E12 | generic | 0 | generic | | -W1 |
Wie ihr seht, ist inzwischen auch die Position als Folio-/Zeile/Spalte enthalten.
Das wird ohne weiteres zutun als gültige Tabelle von LibreOffice Calc geöffnet, wenn es als *.csv gespeichert ist!@Kellermorph:
In der qet-Datei liegen die Klemmen unabhängig von der im Programm eingestellten Sprache.
Deswegen sollte esauch für ein solches Tool irrelevant sein, welche Sprache eingestellt ist,..
Das muss jedenfalls das Ziel sein und so bin ich an die Aufgabe rangegangen.
Mir ist wieder eingefallen, weshalb ich nach Klemmen abfrage.
Ich benutze im Plan selbst gebaute Abzweigungen. Diese sind Bauteiltechnisch auch als Klemme definiert. Und damit die nicht in der Liste erscheinen, habe ich die damit raus gefiltert.
Schöner wäre evtl einfach zu gucken, dass man denen kein BMK gibt und man dann die mit einem leeren Label raus filtert. Dann dürfte das klappen.
Kellermorph wrote:Ich habe in meinen Zusatzfunktionen die Funktion von Klemmen durchnummerieren drin.
???
Die Klemmen werden doch vom Benutzer oder einer automatischen Regel innerhalb von QET durchnummeriert.
Erstellst / ersetzt Du das Label (BMK) damit?
Nach welchem Schema nummerierst Du die Klemmen?
Eine laufende Nummer kann ich auch leicht hinzufügen, wenn es das sein sollte...
So wie ich es in dem Post beschrieben habe.
Die Funktion geht die ganze .qet Datei durch und sortiert die Klemmen nach dem Teil vom BMK, welcher vor dem Doppelpunkt steht. Der Wert vor dem Doppelpunkt bleibt bestehen und der Wert nach dem Doppelpunkt wird durchnummeriert.
Die Nummerierung ist nach dem Prinzip:
1. Seite.
2. auf der Seite dann nach X Position von links nach rechts. Sollten 2 Klemmen den gleichen x-Wert haben wird dann die Klemme mit dem niedrigen y-Wert genommen.
3. Es werden nur nummerische Werte angepasst. z.B. N und PE bleiben erhalten und werden auch nicht mitgezählt. Wenn man jetzt z.B. 5 Klemmen hat die von 1 -4 nummeriert sind und am Ende ist PE und dann kommen die nächsten 5 Klemmen, geht es mit Wert 5 weiter.
4. Die Nummerierung startet bei jedem neuen Teil vor dem Doppelpunkt neu. Sprich -X1 startet bei 1 und geht z.B. bis 36. -X2 würde wieder bei 1 starten usw.
Wie vorher schon einmal geschrieben, habe ich für mich dann noch den Teil hinter dem Doppelpunkt in interne Nummer eingetragen, da ich eine andere Darstellung der Klemmen bevorzuge.
Das ist eine klassische Funktion von z.B. WSCAD die ich damit nachgebaut habe.
Das hat den Vorteil, dass ich mir am anfang nur einmal die Mühe machen muss und die Klemmen "sauber" vor dem Doppelpunkt definieren muss.
Dann kann ich mir den entsprechenden Block einfach nehmen und kopieren. Jetzt stehen da die gleichen Nummern drin. Ist mir aber egal, da ich nachher einmal die Funktion durchlaufen lasse und alle sauber nummeriert habe.
Das spart sehr viel Zeit und man muss nicht so aufmerksam beim platzieren der Klemmen sein.
Ich hoffe, du konntest es verstehen.
Ja, hast du absolut recht. Im nachhinein ist das auch einfach nur logisch.
Ich bin halt ein absoluter Programmieranfänger und habe es auch mit der Hilfe von Chatgpt gemacht.
Ich habe die V0.100 dev.
Im Prinzip genau so wie Achim es beschrieben hat.
Ich kopiere ganze Seiten und bei Verweisen und Slaveelementen versetzt sich die Schrift, wenn diese im Bauteil nicht linksbündig ist.
Wir sollten uns nicht darüber streiten, an welcher Position welche Information einer Klemme stehen soll:
Das kann jeder für sich entscheiden, indem er seine Klemmen selber zeichnet und die Texte dort positioniert, wo er will!Ich möchte lieber auf die Ausgabe einer Klemmenliste zurückkommen, um die es hier ursprünglich ging.
Das kann ja wohl nicht wahr sein:
Da machen mehrere Leute, die auch noch dieselbe Sprache sprechen, unabhängig voneinander Stand-Alone-Tools für die Erstellung von Klemmenlisten, die dann (mehr oder weniger) aufwendig wieder in QET importiert werden.
Sollte es nicht Ziel sein, das alles direkt in QET zu integrieren?
Mit dem QET_ElementScaler hat das ja auch ziemlich gut geklappt...!Was haltet ihr davon, wenn wir drei (vier) das nun "in Angriff" nehmen und versuchen, das Erstellen einer Klemmenliste in QET einzubauen?
Programmiersprache in QElectroTech ist C++ mit Qt als GUI-Toolkit. Also sollten wir (trotz eurer Anfänge mit Python) auch C++ wählen! Da kommt es mir sehr entgegen, dass in QET_ElementScaler bereits das komplette "drumherum" für das Einlesen und Verarbeiten von XML vorhanden ist!
Das habe ich als Basis genommen, um ein einfaches Tool zu schreiben, das aus der qet-Datei alle Klemmen extrahiert, die Klemmeneigenschaften hinzufügt und die Verknüpfung zum jeweiligen Folio herstellt. Die Position auf dem Folio ist grundsätzlich auch schon verfügbar, aber noch nicht passend aufbereitet. Zusätzlich dazu stehen auch die Funktionstexte des Leiters (function, text, tension/protocol) an der Klemme zur Verfügung.
Zur Zeit sieht eine Beispiel-Ausgabe so aus:
Label | Folio | Type | LED | Function | Function | Text | Tension/Protocol -X0:PE | 3 | ground | 0 | generic | PE | PE | PE -X1:1 | 4 | generic | 0 | generic | CAN High | CAN_H | CAN_H -X1:2 | 4 | generic | 0 | generic | CAN Low | CAN_L | CAN_L -X1:3 | 4 | generic | 0 | generic | CAN Ground | CAN_GND | CAN_GND -X1:4 | 4 | generic | 0 | generic | 24V | 24V | 24V -X1:5 | 4 | generic | 0 | generic | 0V | 0V | 0V -X2:1 | 7 | generic | 0 | generic | | | -X2:2 | 7 | generic | 0 | generic | | | -X2:3 | 7 | generic | 0 | generic | | | -X2:4 | 7 | generic | 0 | generic | | | -X2:5 | 7 | generic | 0 | generic | | | -X2:6 | 7 | generic | 0 | generic | | |
Die nächste Aufgabe besteht nun darin, das entsprechend "schön" auszugeben!
Die Variante von acolomb mit dem Einbetten in einen Freitext gefällt mir dabei schon ganz gut! Das ist für den Normalbenutzer recht einfach mit Bordmitteln des Betriebssystems zu erledigen!In einem weiteren Schritt muss das in QET integriert werden, damit wir von den Stand-Alone-Tools wegkommen und alles "geschmeidig" innerhalb der GUI von QElectroTech erledigt werden kann!
Eine Idee, die ich hätte, die VLLT funktionieren könnte.
Ich habe in meinen Zusatzfunktionen die Funktion von Klemmen durchnummerieren drin.
Ich kann versuchen, daraus ein C++ Programm (mit Hilfe von Chatgpt) mit kleiner GUI zu machen.
Die sollte man dann doch integrieren können und unter einen separaen Menüpunkt unter Projekt integrieren können oder ist das falsch gedacht?
Ach vermutlich liegt es daran, dass mein Programm auf meine Bauteile zugeschnitten ist. Der guckt nach Klemme. Das Bauteil heißt aber irgendwie Borne oder so. Wenn ich die Klemme von mir rein packe erkennt er es problemlos.
Ob ich das so schnell geupdated kriege wage ich zu bezweifeln.
Wenn du die Klemme im Anhang nimmst und für dich anpasst, dürfte es gehen.
Wir sollten uns nicht darüber streiten, an welcher Position welche Information einer Klemme stehen soll:
Das kann jeder für sich entscheiden, indem er seine Klemmen selber zeichnet und die Texte dort positioniert, wo er will!Ich möchte lieber auf die Ausgabe einer Klemmenliste zurückkommen, um die es hier ursprünglich ging.
Das kann ja wohl nicht wahr sein:
Da machen mehrere Leute, die auch noch dieselbe Sprache sprechen, unabhängig voneinander Stand-Alone-Tools für die Erstellung von Klemmenlisten, die dann (mehr oder weniger) aufwendig wieder in QET importiert werden.
Sollte es nicht Ziel sein, das alles direkt in QET zu integrieren?
Mit dem QET_ElementScaler hat das ja auch ziemlich gut geklappt...!Was haltet ihr davon, wenn wir drei (vier) das nun "in Angriff" nehmen und versuchen, das Erstellen einer Klemmenliste in QET einzubauen?
Programmiersprache in QElectroTech ist C++ mit Qt als GUI-Toolkit. Also sollten wir (trotz eurer Anfänge mit Python) auch C++ wählen! Da kommt es mir sehr entgegen, dass in QET_ElementScaler bereits das komplette "drumherum" für das Einlesen und Verarbeiten von XML vorhanden ist!
Das habe ich als Basis genommen, um ein einfaches Tool zu schreiben, das aus der qet-Datei alle Klemmen extrahiert, die Klemmeneigenschaften hinzufügt und die Verknüpfung zum jeweiligen Folio herstellt. Die Position auf dem Folio ist grundsätzlich auch schon verfügbar, aber noch nicht passend aufbereitet. Zusätzlich dazu stehen auch die Funktionstexte des Leiters (function, text, tension/protocol) an der Klemme zur Verfügung.
Zur Zeit sieht eine Beispiel-Ausgabe so aus:
Label | Folio | Type | LED | Function | Function | Text | Tension/Protocol -X0:PE | 3 | ground | 0 | generic | PE | PE | PE -X1:1 | 4 | generic | 0 | generic | CAN High | CAN_H | CAN_H -X1:2 | 4 | generic | 0 | generic | CAN Low | CAN_L | CAN_L -X1:3 | 4 | generic | 0 | generic | CAN Ground | CAN_GND | CAN_GND -X1:4 | 4 | generic | 0 | generic | 24V | 24V | 24V -X1:5 | 4 | generic | 0 | generic | 0V | 0V | 0V -X2:1 | 7 | generic | 0 | generic | | | -X2:2 | 7 | generic | 0 | generic | | | -X2:3 | 7 | generic | 0 | generic | | | -X2:4 | 7 | generic | 0 | generic | | | -X2:5 | 7 | generic | 0 | generic | | | -X2:6 | 7 | generic | 0 | generic | | |
Die nächste Aufgabe besteht nun darin, das entsprechend "schön" auszugeben!
Die Variante von acolomb mit dem Einbetten in einen Freitext gefällt mir dabei schon ganz gut! Das ist für den Normalbenutzer recht einfach mit Bordmitteln des Betriebssystems zu erledigen!In einem weiteren Schritt muss das in QET integriert werden, damit wir von den Stand-Alone-Tools wegkommen und alles "geschmeidig" innerhalb der GUI von QElectroTech erledigt werden kann!
Hast du grundsätzlich absolut Recht. Das wäre viel schöner.
Aber ich kann weder C++ noch habe ich jemals in so großer Software gearbeitet. Ich habe absolut gar keine Ahnung wie ich hier vorgehen würde / müsste / könnte.
Das kann ich nicht nachvollziehen. Laut DIN EN IEC 81346 werde Doppelpunkte doch nur für Funktionsbezeichnungen verwendet. In den meisten Fällen wird er gar nicht verwendet, sonmdern höchsten der normale Punkt, z. B. -XD1.1 und -XD1.2 für die 230V Stromversorgung und -XE1.1 für den zugehörigen Schutzleiter.
Ich verstehe auch nicht, warum der name des Klemmblocks "unter" dem BMK stehen muss. Heißt das, es muss ein separates Textfeld in der gleichen Spalte sein?
Vielleicht schreibe ich die Software einfach um...
Richtig. Die Funktionskennung wäre dort ja, z.B. dass X2:2 die 2. Klemme ist.
Wenn du magst, lad deine .qet Datei einmal hoch und ich gucke drüber wo es scheitert.
Bevor ich vergesse es zu schreiben.
Bei dem Klemmen durchnummerieren werden nur nummerische Werte gezählt. Sprich Zahlen werden durchnummeriert. Alphabetische (N, PE...) bleiben unberührt und werden auch nicht mitgezählt
Kellermorph wrote:https://qelectrotech.org/forum/viewtopic.php?id=2938
Ich habe da eine eigene Funktion gebaut.
Gut! Ich habe es ausprobiert. Leider sind alle CSVs bis auf die Kopfzeile leer. Was habe ich falsch gemacht?
Hast du dir mein Beispielprojekt angeguckt?
Die Klemmen müssen auf eine bestimmte Art und Weise definiert sein, dass es klappt.
Unter dem BMK muss der Name des Klemmblockes stehen, z.B. X2 gefolgt von einem Doppelpunkt und der dann Klemmennummer. Beispielsweise -X2:1. Die Klemmen müssen als Bauteil natürlich auch als Klemme definiert sein.
Das ist die Grundvoraussetzung, dass die Klemmen gefunden werden können.
Bevor du in das Projekt guckst und dich wunderst.
Da ich diese Darstellung der Klemmen allerdings nicht schön finde, habe ich diese bei mir etwas anders dargestellt.
Das BMK sieht man nicht. Dafür habe ich die Rubriken Kommentar und Interne Nummer vergewal***t. Unter Kommentar trage ich HÄNDISCH den Klemmenblocknamen ein, wenn dieser angezeigt werden soll. Unter interne Nummer trage ich die Klemmennummer ein.
Wenn du das so machst wie ich, kannst du auch die Funktion der Klemmen durchzählen nutzen, was händisch super aufwändig wäre. Wenn du noch Fragen hast, kannst du dich gerne melden.
https://qelectrotech.org/forum/viewtopic.php?id=2938
Ich habe da eine eigene Funktion gebaut.
Noch muss dies dann per csv in eine excel, welche dann als pdf exportiert wird, umgewandelt in png und dann ein png import durchgeführt wird.
Ist noch etwas umständlich aber funktioniert.
Wenn ich nochmal zeit habe, wollte ich gucken, ob ich die Funktion noch erweitert kriege, dass dort direkt Tabellen in die qet Datei geschrieben werden. Bin ich aber noch nicht zu gekommen.
Allerdings ist das jetzt ein Appimage für Linux.
Der Quellcode liegt allerdings dabei, dass du, sofern du die Fähigkeiten hast, daraus eine .exe für Windows bauen kannst.
The tool isn't perfect and needs more work, but it's the first one that's worked for me.
no, it's not the first one to run. i'm already using my tool effectively with my first created plans.
ach ok.
Ja das wäre echt genial, weil man dann schnell eine ganze Seite rüber kopieren kann.
Danke für deine Mühe!
Moin.
Gibt es schon Resonanz zu deinem Bug-Fix?
sehr cool, danke.
Guten Tag zusammen.
Ich habe das Problem, wenn ich einem Bauteil bei den dynamischen Texten eine andere Ausrichtung als die Standardausrichtung nehme und dann ein Bauteil auf eine andere Seite kopiere, dass dann nicht die ursprüngliche Ausrichtung genommen wird sondern an dem vorherigen Text neu ausgerichtet wird. Beispiel im Anhang. Kann man irgendwo eine Einstellung ändern, dass immer die ursprüngliche Position beibehalten wird?
QElectroTech → Posts by Kellermorph
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.016 seconds (42% PHP - 58% DB) with 5 queries