You are not logged in. Please login or register.
QElectroTech → Posts by plc-user
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!
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/titleblocksWhen 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... 
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 bereinigenwä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!
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?
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! 
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...
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...
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?
Nachtrag:
Unter Linux gibt es im Druckoptionen-Fenster (Menü->Datei->Als PDF speichern) in der Symbolleiste ganz rechts einen Knopf "Seite einrichten". Bei win ist der ausgegraut. Hier kann zumindest die Papiergröße und die Seitenränder für die PDF-Datei eingestellt werden. (vgl. Anhang)
Hello everybody!
What do you think of introducing a second "user collection"?
For explanation:
In a company it would then be possible to have an official QET-, a company-wide and a personal collection. All elements that are published and valid for the entire company (e.g. on a network drive) would then be in the company-wide collection. Then the personal collection would be available on your own computer as a "playground" until these elements are also transferred to the company-wide collection, or even to the QET collection!
On Linux systems such a scenario can be achieved by using symbolic links, but on Win? Some say there are symlinks on win but I haven't seen any! Additionally the creation of symbolic links is often forbidden by company IT...
Regards
plc-user
Hallo Philipp,
für die Seitengröße auf Papier kann man nur sagen: Drucke es auf A2 aus!
Im Ernst: Die Zeichenfläche von QET steht in keinem Verhältnis zur Papiergröße, außer, dass QET versucht, beim Druck das Papier so gut als möglich zu füllen. Dabei bleibt aber das Seitenverhältnis der Zeilen und Spalten erhalten.
Beispiel: Wenn Du 10 Zeilen und nur 2 Spalten á 75px in QET einstellst, wird der Ausdruck schmal aber auf voller Seitenhöhe erscheinen (vgl. Anhang).
Dabei ist das Schriftfeld (nach meiner Erfahrung!) immer auf die gesamte Zeichnungsbreite skaliert. Ich habe noch keine Möglichkeit gefunden, ein normgerechtes Schriftfeld zu erzeugen: Wenn es dafür eine Lösung gibt, nehme ich die auch gerne!
HTH
plc-user
Hi Jim,
if you know the part-number of the standard in combination with the chapter the editing should be very easy:
The element-files are named by part-number of the standard, chapter and consecutive number.
Your Screenshot showed some typos in the German translation, so I corrected them!
Additionally the screenshot shows that you do not use the current development-version in which many translations are added/corrected. The next development-release brings some english translations for the 60617-directory as well.
As Laurent already said: This is an Open-Source-Project from volunteers that is delivered for no costs!
So: Feel free to get involved and translate element- and/or directory-names.
BTW:
There is a new beta-release-Version of the element-scaler available.
https://github.com/plc-user/QET_ElementScaler/releases
Changes: added XML-Element "input" for scaling
Hallo Andreas,
schön, dass ich zumindest Dich davon überzeugen konnte, eine Skalierung zu wählen, mit der man auch noch im Kopf die Relationen zum Original berechnen kann!
Aber zunächst zum Skalierungs-Tool. Der Aufruf ist recht einfach:
QET_ElementScaler.exe ElementDatei.elmt Faktor
Der Faktor wird als Gleitkommazahl mit Punkt als Dezimal-Trennzeichen erwartet. Zum Beispiel:
QET_ElementScaler.exe ElementDatei.elmt 0.9
Das Tool fügt als erste Zeile die XML-Version ein, die bei QET-Elementen nicht enthalten ist und sollte deshalb nachträglich entfernt werden! Wie das bei Win automatisiert möglich ist, dafür habe ich im Moment keine Idee, da ich mit Linux arbeite! Da gibt es das schöne Tool "grep" mit dem man innerhalb eines Bash-Skriptes ganz prima viele Dateien in einer Schleife bearbeiten kann:
for i in `find . -name "*.SCALED.elmt"` ; do
# remove "xml version"
grep -v -i "xml version" "$i" > "$i".NEW.elmt
doneBeim Benutzen von skalierten Elementen in QET tappst Du wahrscheinlich in dieselbe Falle, wie ich auch zu Anfang:
Wenn Du die Dateien mit einem Text-Editor ansiehst, solltest Du einen Unterschied bei den Zahlwerten sehen.
Da das Tool nur die Positionen und Längen ändert und alle UUIDs gleich bleiben, wird von QET beim Einfügen des skalierten Elements nicht das neue Element verwendet, sondern das vom "Cache" des Projektes. Wenn Du das skalierte Element einfügen willst, lösche erst die vorhandenen Instanzen des nicht-skalierten Elements aus Deinem Projekt und bereinige es (Projekt -> Projekt bereinigen). Alternativ geht ein neues Projekt natürlich auch.
Nun sollte beim Einfügen des skalierten Elements die neue Größe verwendet werden. Tut es bei mir auf jeden Fall!
Aufgrund der recht überschaubaren Anzahl von Reaktionen auf den Versuch, Regeln für die Erstellung von Front-Ansichten zu etablieren, sollten wir vielleicht zu zweit ein paar einfache Regeln aufstellen und den Entwicklern und Benutzern hier zur Diskussion stellen. Was hältst Du davon?
Nun wechsele ich mal ins Englische, damit auch die anderen Leser was verstehen.
I'll start with some suggestions for simple rules:
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
The rule for y-center is for the situation that the user needs to rotate the element by 180° on the DIN-rail: in this case you do not need to adjust y-position.
Maybe we need to create a rule for x-position, too? That would mean: Center in X-direction = 0
@Andreas: Kein Problem: Habe ja von Mißverständnis gesprochen ... passiert schon mal...
@hovel and everybody:
Of course, from an aesthetic point of view, it looks better if all parts share the same height, but:
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.
What use is it to the planner of a switching-cabinet if the drawing is "just beautiful", but the parts don't fit into the cabinet afterwards, or on the other hand the cabinet could have been chosen one size smaller because the real parts have a different size than the drawing suggests?
So we should also make sure that the elements we draw use the same scale in both directions!
In addition to the scale, this could be a second rule for front views ...
Sorry, but I think, that you misunderstood something, Andreas!
When I asked, nobody could tell me, if there is a scale what we have agreed on and that is noted somewhere as a given "rule".
So I suggested to have a discussion about it. That's all!
Please have a look at the other thread where I collected some examples:
DIN-Rail TS35: 100 mm -> 200.00 px
circuit-breaker: 100 mm -> 222.22 px
IO-Module: 100 mm -> 236.00 px
and the elements in the attached files "different_elements.qet"
We already have a wild mixture of scalings and all I want is to unify the scale for graphical elements (front-views)!
I don't care what scale it is, because we can have decimals for being detailed in the graphics.
But still I think it would be helpful to have a scaling where everybody can calculate the sizes without the need of an electronic calculator or a spreadsheet! So I suggested something like 100 mm <-> 200 px
This thread should result in a survey, what scale we want to use for ALL graphical elements (not for schematic symbols) inside of QET.
To repeat my suggestion of a scale: 100 mm <-> 200px
Please feel free to take part at the discussion, everybody!
Here two links to my postings in the other thread where I explained my motivation for this discussion:
https://qelectrotech.org/forum/viewtopi … 980#p13980
https://qelectrotech.org/forum/viewtopi … 241#p14241
At work: When I question a strange decision from the past, why we are
doing something the way we do, I often hear reasons such as these:
- "we have always done it this way"
- "grown historically"
- "we already have so much of it"
- "compatibility-reasons with ..."
when everyone wants to avoid a task of changing or making a decision.
In my opinion the scaling-factor of "1 : 2.222" (90mm <-> 200px) for some
graphics is such a "historically grown" value.
When we say with "1 : 2" (100mm <-> 200px) we can't be very detailed
in our graphics, why not choose "1 : 5" or "1 : 10"?
The absolute value of the scale is not critical, but I think we should
choose a value that can be used to calculate sizes without a calculator
or spreadsheet!
Everything I want is a decision for the scale and some other basic rules
and that we write them down, so that everyone who searches, can find them!
... and everyone should follow the rules ...
Please have a look at some examples I found and attached here:
https://qelectrotech.org/forum/viewtopi … 983#p13983
In my opinion it is high time that we define a scale:
There are already so many different scales in use and there will
definitely be even more if we don't prescribe it.
I know: Going through the library and adjusting all the elements is
a lot of work, but the sooner we do it, the less work it is.
And automated scalers like my small pascal-programm can help...
And of course:
I suggested to change the scaling of graphics and I will help doing the work!
Otherwise I wouldn't have written the ElementScaler...
QElectroTech → Posts by plc-user
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.026 seconds (40% PHP - 60% DB) with 5 queries