226

(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...

Ja, stimmt:
Der N ist vor und hinter dem RCD blau, aber trotzdem nicht dasselbe, weil geschaltet!

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.

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.

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

231

(30 replies, posted in Elements)

Hallo Andreas,

schön, dass meine Vorschläge bei Dir/Euch Anklang finden!  nomicons/smile
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! nomicons/smile
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/

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

233

(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

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 ...

Hello everybody,

I have to change the language because my french is only enough to guess the subject...

What I said a year ago in this thread https://qelectrotech.org/forum/viewtopi … 975#p13975 and in the thread a.funke started https://qelectrotech.org/forum/viewtopi … 247#p14247 as spin-off:

We need some rules for the creation of the front-views of elements!
Please let's revive the topic, otherwise we will get even more wild growth in the elements-collection!

scorpio810 wrote:

Bonjour, tu peux regarder sur ce dépôt https://github.com/qelectrotech/qelectr … nt-contrib

I'm a little confused:
Shouldn't the "qelectrotech-element-contrib" repository only contain obsolete or outdated elements so they aren't completely lost?

via online-translator:
Je suis un peu confus:
Le référentiel qelectrotech-element-contrib ne devrait-il pas contenir uniquement des éléments obsolètes afin qu'ils ne soient pas complètement perdus?

in the actual debian-version (qelectrotech_0.90.r7473-1_amd64.deb qelectrotech-data_0.90.r7473-1_all.deb) QET does not find the default system-wide element-collection.

The directory where the collection is stored is "/usr/share/qelectrotech/elements",
the setting is "default" but in the tree I only see my user-elements.

In the config-file I find these settings:

[elements-collections]
common-collection-path=default
custom-collection-path=/home/ich/Projekte/qet/elements
custom-tbt-path=/home/ich/Projekte/qet/titleblocks

When I set the directory to "custom" (/usr/share/qelectrotech/elements) all elements are shown...

Du hast gesehen, dass Du die Parameter für den Bogen editieren kannst?
Du brauchst da nichts rotieren!

english:
You noticed that you can edit the arc's parameters?
You don't have to rotate!

@q.e.d.:
In die Liste der Importierten Bauteile werden die Elemente direkt aus dem Verzeichnisbaum eingefügt und auch in der gleichen Struktur belassen.

Was meinst Du mit "sobald ich die importierten Elemente editieren will"?

Möchtest Du Elemente (z.B. auch für zukünftige Projekte) ändern, dann wäre das Kopieren der einzelnen Elemente in die Benutzersammlung das Mittel der Wahl. Anschließend fügst Du das geänderte Teil aus der Benutzersammlung in Deinen Schaltplan ein und QET kopiert es damit in die Liste der importierten Elemente.

Für das Editieren von Artikelnummer, Betriebsmittelkennzeichen, etc. markierst Du das Teil im Schaltplaneditor und editierst nur die Felder unter "Auswahleigenschaften" in den Reitern "Information" oder "Texte".

Dass die "Unterverzeichnisse" bei den importierten Elementen so durcheinander geraten, wie in Deinem Screenshot, ist mir noch nicht untergekommen.
Kannst Du ein Minimal-Beispiel zur Verfügung stellen, bei dem es zu solchen Verschachtelungen kommt?
Am Besten fängst Du ein neues Projekt an und merkst Dir die Schritte bis zum "Durcheinander" bei den importierten Elementen.


EDIT:
Kann es sein, dass Du beim hin-und her-schieben der Elemente in Deiner Benutzersammlung ein paar Unterverzeichnisse "Import" erstellt hast? Schau doch mal bitte in einem Datei-Browser in das Verzeichnis Deiner Benutzersammlung mach, ob dort vielleicht schon solche Verschachtelungen vorhanden sind. Damit würden sich dann auch die mehrfachen Einträge erklären und QET wäre bei der Diskussion "Messie" ein wenig entlastet... nomicons/wink

Die Rubrik "Imported Elements" wird von QET mit den Elementen angelegt, die Du in diesem Projekt importiert hast. Soweit ich das sehe kann das sinnvoll auch nur von QET selber aufgeräumt werden, indem Du im Menü

Projekt -> Projekt bereinigen

wählst. Damit werden die nicht mehr im Projekt verwendeten Elemente (rosa markiert) aus der Rubrik entfernt.
Ein händisches Umsortieren ist hier nicht vorgesehen!

Ich kann Dir vielleicht nicht direkt helfen, aber ein vergleichender Screenshot und/oder ein Minimal-Beispiel in einer QET-Datei wären für die Fehlersuche bestimmt hilfreich! nomicons/wink

seems to be a similar topic in another language:
https://qelectrotech.org/forum/viewtopic.php?id=2104

and (even older):
https://qelectrotech.org/forum/viewtopic.php?id=1048

Hello Joshua,

I know that the number of active developers in the project is very limited, so i didn't expect this feature to come in on the fast!
(Sorry that I can't help: QT-programming is not on the list of my skills)
I just wanted to get it discussed!

In this thread an additional user-collection is also discussed:
https://qelectrotech.org/forum/viewtopi … 772#p14772
So maybe the numbers of the request and the prospect that QET may/will be used in companies, can cause the topic move up a little on the priority list? nomicons/wink

At work we have to use win and there symlinks are blocked from the IT side (no developer-mode, no administrative rights, etc.).
And the variant with switching the collection "on the fly" seems a bit impractical, when you are "in the flow" of drawing a schematic...

just created pull-request for schematic-symbols of MID-Counters.

@Jim:
You can start here to learn about using GitHub: https://qelectrotech.org/forum/viewtopi … 712#p13712
Some developers and other members helped me getting involved in that thread.

But there is another way to getting started: You can edit the qet_directory- and element-files and upload them here in the elements-forum as ZIP-file.
Of course, it is easier for the maintainer if a pull request takes place on GitHub, but at the beginning a ZIP file is a possibility here in the forum.

Looking forward to seeing you support this project with your participation! nomicons/smile

Dann können wir vorerst die Diskussion um die Schriftfeld-Größe an dieser Stelle beenden, weil

  • ein QET-TitleBlock wird immer auf die volle Zeichnungsbreite geändert

  • in ein Element bekommen wir (aktuell) die nötigen Informationen nicht automatisch rein

@RedBaron:
You can register on manufacturers website and download up to 20 parts per day.

But in the case of the Front-Views I created today, I copied parts of existing QET-Elements and pasted them into new elements.
The rectangles and circles are drawn "from scratch".

The tools I use the most:
- QElectroTech
- Inkscape
- DXF-converter
- QET_ElementScaler
- Text-Editor

Hello Arnaud,

sorry, my French is more than bad...  nomicons/wink

The RF-Modules you are missing were still on my list to create, so now i took the chance!

When creating front-views for Wago-modules:
Please keep in mind that all existing modules have the same scaling-factor of 100mm <-> 200px

Edit:
It is quite easy to draw new front-views, when you have all parts for them on harddisc... nomicons/wink
I created three front-views of MID-Counters and created a pull-request on GitHub.
The symbols for schematics are still missing...

Regards
plc-user

Die Schwierigkeit beim Schriftfeld sehe ich darin, das es immer auf die volle Breite der Spalten im Folio verändert wird. Im Anhang seht ihr das 600px-Schriftfeld von RedBaron einmal mit 3 Spalten schmal und einmal mit 20 Spalten Breite des Folios.
Dabei ist das Schriftfelt genau 180 mm breit, wenn
- das Folio breiter als schmal ist,
- im PDF-Dialog A4 hochkant gewählt ist und
- Rand links 25 mm und 5 mm rechts eingegeben wird.

Wie bereits gesagt: Die Angabe der Px für die Zeilen und Spalten im Folio haben nichts mit den realen Abmessungen auf dem Papier zu tun. Nur die Relationen hoch/breit bleiben immer erhalten, egal wie die Papiergröße gewählt wird.

In einem anderen Thread (https://qelectrotech.org/forum/viewtopic.php?id=1924) ist eine Diskussion gestartet, welches Größenverhältnis von realem Bauteil zu Anzahl Pixeln hier als Vorgabe gelten soll, aber das betrifft nur die Relationen der Bauteile untereinander. Und das auch nur für "Bilder" zur realitätsnahen Darstellung im Aufbaubild...

Bei Verwendung eines Schriftfeldes als Element kann man die Größe der Beschriftungen, die Px im Folio und die Angabe der Ränder im PDF-Export-Dialog ja so wählen, dass das auf dem gewählten Papier 180mm entspricht. (Im Zweifel hilft für die Größenänderung des so erstellten Schriftfeld-Elementes eine kleine Software: https://qelectrotech.org/forum/viewtopic.php?id=1946)
Beim Schriftfeld-Element ist aber fraglich, ob/wie ich da die Projekt-Informationen (%folio, %rev, %author, etc.) automatisiert reinbekomme!

@Laurent and/or @joshua:
Is it possible to use document-information like Folio-Number, etc. in variables of elements?

Eine elegantere Möglichkeit wäre, ein Element "Schriftfeld nach DIN" anzulegen und die Zeilen/Spalten entsprechend anlegen, dass das für die Seitengröße passt.

Hier ist mir aber nicht bekannt, ob man Projekt-Informationen (%author, %date, %folio, etc.) als Variable in ein Element einfügen kann, wie es beim Schriftfeld möglich ist. Vielleicht kann hier ein Entwickler was dazu sagen?