I'll be patient! 
551 2022-09-27 20:11:41
Re: Reproducible Crash of QET (11 replies, posted in EN : Help, suggestions, discussions, ...)
552 2022-09-27 20:09:17
Re: Symbole pour schéma hydraulique (chauffage/plomberie) (8 replies, posted in FR : Aide, suggestions, discussions, ...)
Hallo nicolas.lotito
Du kannst eine eigene Benutzersammlung füllen bzw. erstellen, in die Du die Elemente, die Du am häufigsten brauchst, nach eigenen Wünschen ablegen und auch bearbeiten kannst.
Wenn Du Deine Sammlung komplettiert hast, würden wir uns freuen, wenn Du Deine Elemente mit uns teilen würdest!
Ich kenne "Xrelais" oder "Winrelais" und deren Dateiformat nicht. Im Moment sind die Import-Funktionen von QET noch nicht sehr umfangreich. scorpio hat aber schon den Hinweis auf den DXF-zu-elmt-Converter gegeben. Manchmal ist es aber auch sinnvoller, Elemente von Anfang an selbst in QET zu erstellen, oder bestehende Elemente umzuarbeiten, um daraus neue zu erstellen...
via online-translator:
Tu peux remplir ou créer ta propre collection d'utilisateurs, dans laquelle tu peux déposer les éléments dont tu as le plus souvent besoin, mais aussi les modifier selon tes propres besoins.
Lorsque tu auras complété ta collection, nous serions heureux que tu partages tes éléments avec nous !
Je ne connais pas "Xrelais" ou "Winrelais" et leur format de fichier. Pour l'instant, les fonctions d'importation de QET ne sont pas encore très étendues. scorpio a cependant déjà donné l'indication du convertisseur DXF en elmt. Mais il est parfois plus judicieux de créer soi-même des éléments dans QET dès le début, ou de retravailler des éléments existants pour en créer de nouveaux...
553 2022-09-01 09:08:46
Re: Copy & Paste in Element-Editor (3 replies, posted in EN : Help, suggestions, discussions, ...)
554 2022-08-31 16:20:25
Re: somebody to reactivate COBAN ? (4 replies, posted in EN : Help, suggestions, discussions, ...)
Hello alberts!
Free and OpenSource software is not only there to be used, but may and should even be improved or extended by yourself!
The sources of Coban can be rewritten to a runnable program without knowing how python works!
I don't know python, but nevertheless, with the help of the error messages and an internet search engine, I managed to get the program basically running on a current "Debian/GNU Linux unstable".
I was curious to see what the programme would do and in the process I also translated some texts into English with an online translator because my French is very bad.
Some things still don't work because some data is expected in files, but they don't exist, and/or Coban can't write them to a file. Some python knowledge may be necessary to fix this...
It's just a lot of work to get this stuff working again! You just have to want to do it and invest a little time!
In the attachment you find my revised version of the program. I don't give any guarantee for it: Use it at your own risk!
Kind regards
plc-user
PS:
Please don't ask me any questions about Python!
I can't answer them anyway!
555 2022-08-30 21:10:59
Re: Reproducible Crash of QET (11 replies, posted in EN : Help, suggestions, discussions, ...)
Hello Laurent,
I guess you misunderstood something:
This thread is not about copy-and-paste - that's the other thread I started.
This thread is about a reproducible crash of QET when inserting a text-element in element-editor!
Something seems to go wrong when saving and reloading an element and QET crashes, because the source-code-line 74 of sources/editor/ui/texteditor.cpp says so:
assert(m_change_connection.isEmpty());(see above)
I can even reduce the steps to reproduce:
- create a new element
- place a text somewhere
- save the element
- reload the file (menu - file - reload)
- click at the text-element
- crash!
556 2022-08-29 22:16:05
Topic: Reproducible Crash of QET (11 replies, posted in EN : Help, suggestions, discussions, ...)
When using the Element-Editor I found a way to reproducibly crash QET.
The steps to reproduce the crash are as follows:
QET crashes reproducible when:
- create a new element
- place a text somewhere
- edit the text
- move the text somewhere else
- save the element
- reload the file (menu - file - reload)
- click at the text-element
- crash!
Same behaviour when:
- open an element-file with some text
- copy and paste a text-element
(view zooms and shifts somewhere!)
- save the element-file
- reload the file (menu - file - reload)
- click at the pasted text-element
- crash!
When starting QET from commandline these two lines appear in both cases when crashing (system-language is set to German):
qelectrotech: sources/editor/ui/texteditor.cpp:74: void TextEditor::setUpChangeConnection(QPointer<PartText>): Zusicherung »m_change_connection.isEmpty()« nicht erfüllt.
Abgebrochen
QET- and System-Info:
"QElectroTech V 0.90-DEV+d7e1813ffb0a58100c957a06d79751d3"
"Compilation: GCC 12.1.0"
"Built with Qt 5.15.4 - x86_64 - Date : Aug 16 2022 : 08:39:41"
"Run with Qt 5.15.4 using 8 thread(s)"
"CPU : model name\t: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz\n"
"RAM Total : 31 GB"
"RAM Available : 30 GB"
"GPU : Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01)\n"
"GPU RAM : "
"OS : linux - x86_64 - Version : Debian GNU/Linux bookworm/sid - Kernel : 5.18.0-4-amd64"
*** Qt screens ***
"( 1 : 1920 x 1080 )"
In the attachment you find a small element-file i use for the "crash-tests" but you can use any other element-file.
557 2022-08-29 15:38:02
Re: Copy & Paste in Element-Editor (3 replies, posted in EN : Help, suggestions, discussions, ...)
In the attachment you find the Element-File.
I edited the element-file with a text-editor to sort the elements by type and added some blank lines for readability - no changes in position-values!
558 2022-08-29 15:37:07
Topic: Copy & Paste in Element-Editor (3 replies, posted in EN : Help, suggestions, discussions, ...)
Do the developers have any influence on the position where the graphical elements are pasted from the clipboard?
When I copy and paste individual graphical elements, they are pasted with an X offset of 30. If there is a text element in the clipboard, it will be pasted with an X-Offset of 30.6094 (as shown in the example). If graphic elements are copied together with text, everything is pasted with an X-Offset of 32.1094 (see example).
On the one hand, the different treatment of graphical elements and text bothers me, and on the other hand, I find it rather strange that the paste position depends on whether text is involved.
But what I find particularly disturbing is the fact that four (!) decimals are used here, which cannot be "fixed" again with the help of the graphical editor. Especially when (text) elements are copied and pasted several times, decimals are added, so that this effect is intensified.
If the programmer(s) have any influence there, I would wish that the insert offset is at least always integer. If for some reason there are decimal places, I think it would make sense to limit the decimals to a maximum of two. When editing polygons manually, only two decimals can be entered (at least in the graphical editor).
559 2022-08-14 09:26:56
Re: freepascal-code to take a QET- Element and scale the content by a fact (38 replies, posted in Scripts)
EDITED
Just created a new version of QET_ElementScaler:
With the newly added optional parameter "-o" or "--stdout" it is now possible to write the scaled element-data to stdout instead of writing a renamed file.
The new option "-i" or "--stdin" allows QET_ElementScaler to be used with re-direction and/or pipes on the commandline:
The input-data is read from stdin and the output will be written to stdout.
Examples to write to stdout:
QET_ElementScaler -o InputElement.elmt 1.4 > NewScaledElement.elmt
QET_ElementScaler -o InputElement.elmt 1.4 | OtherSoftwareBinary
Examples to use re-direction and/or pipes:
QET_ElementScaler -i 1.4 < InputElement.elmt > NewScaledElement.elmt
cat InputElement.elmt | QET_ElementScaler -i 1.4 | OtherSoftwareBinary
Have a look and give it a try:
https://github.com/plc-user/QET_ElementScaler
560 2022-06-05 21:46:20
Re: new Elementsand some re-work for WAGO-Symbols (20 replies, posted in Elements)
Hello mezga,
at the moment the series 2003 and 2005 do not exist as front-views in QET.
But you are welcome to create and share the two series of terminal blocks in the same style as the existing ones!
Edit:
The most recent versions of the WAGO-Parts are included in the DEV-packages of QET.
Just created Pull-Request #219 including some terminal-blocks from series 2003 and many other changes.
Regards
plc-user
561 2022-05-30 14:23:19
Re: Montageplatte Schaltschrank zeichnen (3 replies, posted in DE : Hilfe, Vorschläge, Unterhaltungen...)
Hello jhonathan!
I like your rulers! 
They are created with the same scale we agreed with the developers in the other thread: https://qelectrotech.org/forum/viewtopi … 155#p16155
If I understood Joshua correctly, he wants to add the possibility to display the measurement in mm directly when creating an object (line, rectangle, etc.) in the element editor.
I think it is a good way to draw mounting plates with the help of such rulers:
There are so many possible dimensions for mounting plates that it seems impossible to create all variants as a separate element. For DIN-rails (as comparable part) I only created a few in 10cm steps...
The same challenge exists for cable ducts: They even have to be adapted to the respective situation, so there can't be standard lengths either.
562 2022-05-29 23:26:56
Re: Lines dissapear after exporting (4 replies, posted in EN : Help, suggestions, discussions, ...)
I don't have a solution but an explanation:
This seems to be a rendering-"problem" of your PDF-viewer.
Depending on how the viewer renders the thickness of the lines you may see them with all zoom-factors or not.
As far as I know there is no setting in QET for the export of line-widths.
Try another PDF-viewer.
563 2022-05-29 23:18:57
Re: scaling-factor for Drawing of front view (30 replies, posted in Elements)
Hallo Andreas,
als Problem würde ich das auch nicht ansehen:
Für eine saubere Trennung von Schaltplan und Aufbaubild braucht ihr sowieso jeweils eigene Schaltplan-Symbole für die KNX-Module, weil die Aufbaubilder bekannterweise keine Anschlüsse haben....
Für die Verknüpfung von Schaltplansymbol und Front-Ansicht hat Joshua ja schon für eine spätere Version von QET eine Lösung in Aussicht gestellt. Und für die Aufteilung eines komplexeren Gerätes in mehrere Schaltplansymbole gibt es auch bereits Feature-Wishes in anderen Threads hier im Forum.
via Online-Translator:
I wouldn't consider that a problem either:
For a clean separation of the schematic and the front view, you need separate schematic symbols for the KNX modules anyway, because the front views do not have any terminals...
Joshua has already promised a solution for linking the schematic symbol and the front view in a later version of QET. And for the division of complex devicee into more than one schematic symbols, there are already feature wishes in other threads here in the forum.
564 2022-05-10 20:29:20
Re: freepascal-code to take a QET- Element and scale the content by a fact (38 replies, posted in Scripts)
scorpio810 wrote:
Great tool, thanks plc-user.
You're welcome, Laurent!
565 2022-05-10 20:22:38
Re: scaling-factor for Drawing of front view (30 replies, posted in Elements)
Hello Joshua,
just so I understand you correctly:
What is called "front view" in the subject of this thred is what you call "thumbnail"?
These thumbnails are not supposed to appear as "duplicates" of schematic symbols in the BOM, that's right, Laurent. Then it may make sense that we also need a link between the schematic symbol and the thumbnail at some point, doesn't it?
There is Schematic-Software on the market that even goes further: They offer support for creating layout plans from the schematic, from which even drilling plans for mounting-plates are automatically generated that can be fed into a CNC. But that's still in the far future for QET!
Of course, I don't want to leave you alone with the work of scaling: You can count on my support to make the "deprecated" folder smaller! Didn't write "QET_ElementScaler" for nothing...
566 2022-05-08 18:10:45
Re: new Elementsand some re-work for WAGO-Symbols (20 replies, posted in Elements)
Start reading here:
https://qelectrotech.org/forum/viewtopi … 713#p13713
567 2022-05-08 18:08:22
Re: scaling-factor for Drawing of front view (30 replies, posted in Elements)
Hello everybody!
The discussion about simple rules for elements doesn't seem to be getting "off the ground" properly.
@Joshua and
@scorpio810:
What more does it take to get things going here?
If we agree on rules, then we also need to write them down in the QET documentation and also make sure that they are followed. This also means that we have to regularly point out to the creators of elements that these rules exist. In some cases, this also means that individual elements need to be reworked (scaled) or even rejected...
With the elements that have been added in the meantime, I see again (or rather: still see) that the "wild mixture" of scaling factors continues.
If we do not talk about it, we will not be able to reach an agreement...
568 2022-04-05 21:38:48
Re: Potentiale durch Bauteile propagieren (6 replies, posted in DE : Hilfe, Vorschläge, Unterhaltungen...)
Ja, stimmt:
Der N ist vor und hinter dem RCD blau, aber trotzdem nicht dasselbe, weil geschaltet!
569 2022-04-03 21:28:53
Re: Potentiale durch Bauteile propagieren (6 replies, posted in DE : Hilfe, Vorschläge, Unterhaltungen...)
Hallo maximalz
maximalz wrote:
Ein LS-Schalter oder ein FI verändern ja das Potential nicht, also sollte - wenn z.B. am LS L1 ankommt, der Abgang auch das Potential L1 haben.
Um Deine Logik mal weiterzuführen:
Ein Schalter verändert das Potential auch nicht, also müßte nach der Logik auch dort beidseitig dasselbe Potential sein.
Da widerspreche ich aber mal heftig!
Dann müsste ja das Potential direkt am Eingang eines Schaltschranks vor allen LS und RCDs und dahinter auch dasselbe sein - sind sie aber nicht! Sonst wären ja LS und RCD unnütz!
Abgesichert und vor den Sicherungen ist schon unterschiedliches Potential.
Eine Steckdose mit abgesicherten 400V muss was anderes sein als eine, die vor allen Sicherungen angeschlossen ist.
570 2022-04-01 10:38:59
Re: PLantage QET avec les Sommaire (15 replies, posted in FR : Aide, suggestions, discussions, ...)
Hello Joshua,
in case you didn't receive a mail from the Bug-Tracker:
I re-opened the Bug-report because (at least on Debian unstable) QET still crashes when closing the attached project-file.
571 2022-03-31 17:01:25
Re: PLantage QET avec les Sommaire (15 replies, posted in FR : Aide, suggestions, discussions, ...)
sounds very similar to why I wrote a bug report:
https://qelectrotech.org/bugtracker/view.php?id=244
(online-translator)
cela ressemble beaucoup à la raison pour laquelle j'ai écrit un rapport de bogue:
https://qelectrotech.org/bugtracker/view.php?id=244
572 2022-03-20 23:08:08
Re: scaling-factor for Drawing of front view (30 replies, posted in Elements)
Hallo Andreas,
schön, dass meine Vorschläge bei Dir/Euch Anklang finden!
In Deinem PDF habe ich gesehen, dass Du auch Hager-Teile verwendest und bearbeitest. Davon hatte ich auch noch ein paar "in der Pipeline", die ich nun bei github als pull-request hochgeladen habe. Dabei habe ich mir erlaubt, die bestehenden Teile nach meinen (scheinbar akzeptierten Vorschlägen) umzuarbeiten.
in English:
happy to see that you support my suggestions!
I saw in your PDF that you also use and edit Hager parts. I also had a few of these "in the pipeline", which I have now uploaded to github as a pull request. I took the liberty of reworking the existing parts according to my (apparently accepted) suggestions.
geänderte Teile in Verzeichnis / changed parts in directory:
elements/10_electric/98_graphics/99_assembly_plan/01_thumbnails_mounting_plate/hager/
573 2022-02-20 15:47:31
Re: Affichage d'une règle pour cotation ou dimension (16 replies, posted in FR : Aide, suggestions, discussions, ...)
Additionally an on-and-off-switchable dimensioning tool would be helpful, but first we need to find a compromise about the scaling (and other rules) for Elements.
Check out my post in the other thread where I summarized suggestions for a few simple rules.
https://qelectrotech.org/forum/viewtopi … 833#p15833
574 2022-02-20 14:55:32
Re: scaling-factor for Drawing of front view (30 replies, posted in Elements)
The drawing of the front view and the placing of the parts on a mounting plate should represent the real dimensions of the switching-cabinet or serve to determine the appropriate size of a switching-cabinet.
The scale 100 mm <-> 200 px seems to be a good compromise between level of detail and clarity.
A "crooked" scale of 100 : 222 is used for many existing graphics (especially from the installation area). This doesn't make much sense to me since you can't calculate the dimensions in your head at design time. These elements could easily be rescaled with the help of my ElementScaler...
At the moment it seems that most users of QET come from the installation area, where the control cabinets are not that huge. If the scale is even smaller than 100 mm : 200 px, a lot of detail that is already present in many elements would be lost.
From my point of view, the level of detail is not that important for a large control cabinet, so that even simple rectangles for the control panel view would probably be sufficient here. In a later version of QET, for example, these could perhaps even be generated automatically if we included the dimensions of the real components as values in the element file.
In summary, here my suggestions for fairly simple rules for creating elements:
- Scaling: 100 mm <-> 200 px
- Scaling for X- and Y-directions identical
- element for DIN-rail: Center in Y-direction = center of DIN-rail = 0
- element for DIN-rail: Center in X-direction = 0 (centered) or useful alignment for elements that are lined up
- language of static texts inside of elements: English (or the original texts printed on the part)
- separate elements for symbols and graphics
- no terminals in front-view-graphics
575 2022-01-09 19:26:42
Re: Affichage d'une règle pour cotation ou dimension (16 replies, posted in FR : Aide, suggestions, discussions, ...)
Please continue the discussion about rules for elements in a language spoken by more users:
I have the impression that many forum participants only read the posts in the language which they can (with simple means) understand. And you don't want to exclude these users from the discussion, do you?
English is not my first language either, but I've found that online French translators aren't a great deal when it comes to technical matters.
Have you looked at the arguments and suggestions for scaling (and other rules) in the other threads? At the moment they don't seem to have attracted any attention here.
In my opinion a factor of 1px = 1mm is too small for most users! This would mean, for example, that the elements cannot be labeled in a realistic manner: Since QET only processes the font sizes in whole numbers, no fine detailing could take place.
Most QET users right now will likely be people building small sub-distributions for the homes or offices. A corresponding level of detail is required here!
In my opinion, a fine level of detail is not necessary for large control cabinets. So only "rough" rectangles for the devices would be necessary for this scope of application. Then we wouldn't even need the detailed images we already have in the common collection. Do you want to achieve that? I hope: no!
Before we (you, Joshua!) implement anything in the source code, we should agree on where the journey with QET should go!
Depending on which areas we want to cover with QET, we may annoy other users. Therefore we should think carefully about what we decide.
I could just repeat the arguments and suggestions from my posts in the other threads mentioned here. But please read for yourself ...