You are not logged in. Please login or register.
QElectroTech → Posts by plc-user
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...
Is it possible to take the Translations from the undelying files "qet_directory"
to name and sort the manufacturers?
This could solve another topic I wanted to ask, when I translated some files:
Sometimes a manufacturer including the products are taken over by another company.
As examples I want to name "Telemecanique" that was included into "Schneider Electric"
and "GE industrial" that was taken over by "ABB".
When we rename the companies in "qet_directory"-files the sorting of manufacturers
stays as before.
What do you suggest, we should do in such cases? Include the renamed company
(and directory) in the other one? Move only the elements and drop the Brand-Name?
So many possibilities...
See this topic for scale : https://qelectrotech.org/forum/viewtopic.php?id=1561
I flipped through the Posts and saw that the scale was discussed but I didn't find the scale itself!
Maybe the online-translator did mess-up everything but it seems that there is no agreement about the scale yet.
If there is an agreement: Please announce it somewhere.
Many of the existing elements have a scale of 90mm <-> 200px but there is no general decision.
In my opinion we should choose a more "simple" scale of 100mm <> 200px so that size-calculations are easyer.
What do you offer, a sub menu in alphabetical order?
I don' quite understand the question, because that is what we have now...
Hallo Andreas,
an der Stelle kann ich noch ein wenig Werbung in eigener Sache machen!
Schau' Dir doch mal meinen QET-Element-Scaler an:
https://qelectrotech.org/forum/viewtopi … 980#p13980
Das ist ein kleines Kommandozeilenprogramm, was zumindest bei mir ziemlich gut funktioniert!
(vgl. Anhang)
Mit einem Skript drumherum kannst Du so viele Elemente in einem Rutsch skalieren.
Anmerkung zum Scaler:
Das Programm beläßt die ganzen uuid in den Elementen, wie sie sind!
Also können das Original und die skalierten Elemente nicht gleichzeitig in einer QET-Datei verwendet werden.
Beim skalierten Element im Anhang habe ich die uuid per Hand modifiziert.
Zu den hochgeladenen Elementen:
Warte noch ein wenig, bis das nächste Install-Paket gebaut ist und sag' dann Bescheid, ob ich dort grobe Schnitzer gemacht habe!
Ich glaube nicht ...
Gruß
plc-user
Hmmm ... as I understood until now, "qelectrotech-element-contrib" is the place for elements that were sorted out from the main-catalogue for some reason. That is why I created a pull-request there for the elements I removed from the now unified parts in the WAGO-directory.
... and that would not make the list of directories inside the QET-catalogue any shorter.
So, I would say: No, keep the current manufacturer-elements where they are.
My mainly used computer runs Debian unstable and it loads QET in less than 3s.
So it is not the loading-time that I wanted to mention, but the long list of manufacturers one has to scroll through to find the one you want.
And the list is getting longer "day-by-day"...
A user-configurable list inside QET-settings would be a comfortable way to keep the list short.
Otherwise it is always necessary to copy only the folders you want to use or delete the others, when a new version of QET is available.
At work I have to use "ReadyToUse"-Versions that I want to keep up-to-date so every now and then the same "work" to choose the folders has to be done.
Aren't we all a little lazy, too?!?
Best regards
plc-user
@Joshua à déplacer certain éléments pour rendre QET plus rapide.
le répertoire Wago contact représente 1272 éléments il serai peut être intéressant de les mettre dans le répertoire "constructeur" pour rendre QET plus rapide.
This leads to another question:
Did you think about the possibility for the user to select which sub-directories he wants to use and which not?
Some sort of a "blacklist" in the user-settings:
Like in my case I do not use many of the electric manufacturer-articles and the pneumatic and hydraulic-parts.
I think it would help, if I could choose that QET does not load them.
@plc user: Tu as fait un bon travail
just created the pull-request!
Best regards
plc-user
@S.DEFFAUX:
Do you mean to copy the removed elements to the other repository?
Will do that later today!
Oh boy, the online-translators "French-German" sometimes produce strange results!!! 
Hallo Andreas!
Wow - da hast Du ja so richtig Arbeit reingesteckt!
Was die Skalierung und sonstigen Vorgaben zu Elementen angeht,
versuche ich die Diskussion in dem anderen Thread gerade wieder
aufleben zu lassen...
Damit wir auf Dauer (jetzt auch schon teilweise vorhanden) nicht noch
mehr Wildwuchs bei den Elementen bekommen, möchte ich Dich
ermutigen, dich auch an der Diskussion zu beteiligen!
Ich kenne die Komponenten von MDT nicht, aber es sieht so aus, dass
Du (zumindest für die Höhe) einen Maßstab von etwa 100mm <-> 200px
verwendest?
Den finde ich passend, ist aber von den Entwicklern (noch) nicht als
Vorgabe definiert...
Wenn Du einverstanden bist, würde ich für "Deine" Elemente von meinem
Account einen Pull-Request starten?
EDIT:
Nun ist kein Einspruch mehr möglich: Habe die Elemente hochgeladen.
Habe dafür ein Element umbenannt (aks24 -> aks-2416.03) und ein paar
doppelt vorhandene Elemente weggelassen...
Gruß
plc-user
scorpio810 wrote:Ready-to-use versions are PORTABLE versions: they don't need to be installed!
Unzip the *.7z archive to a removable media (for example: USB stick) and run the file "Lancer QET.bat".That's what I use at work, on WIN7 and it works perfectly.
Same for me on win10 (64bit): Works perfectly with all available elements since years!
@S.DEFFAUX:
I'm not sure, what you mean:
Where do you want to move or copy what elements?
All Symbols and Graphics are in the manufacturer's directory...
@Joshua:
The suggestions I made for additional features inside the elements are meant "for future use"!
I know that it is a great amount of work to implement such features! EDIT: Especially for doing it on top of the regular work!
But still I think we need some rules for the creation of symbols and graphics:
- separate elements for symbols and graphics
- structure and language of filenames
- language of static texts inside of elements
- maximum number of terminals per schematic-symbol
- splitting of symbols with more than xx terminals
- size / scale of graphics
- (...)
Best regards
plc-user
Another thought for schematic- and graphical symbols:
Do we cover the possibility that a real part can have more than one
schematic symbol?
For example:
Like the already available elements for "Johnson Controls" "DX9100",
a complex control-unit may have many digital and analog I/O and extra
communication-ports that meaningfully should be separated in extra
elements to achieve folios that show "readable" and not overloaded
schematics.
There should be the possibility to link these schematic-parts together
and additionally it should be possible to link to a graphic symbol.
This leads to a "master"-part (not a coil) and more than one
"slave"-parts that aren't contacts...
This leads to another idea for schematic symbols:
Do we have the possibility to define a predecessor and successor of a part?
Many (electronic) systems like PLCs are plugged together in a user-defined
order so it should be possible to define such a sequence.
On the other hand a generic part like a switch can contain more than
one real part (real switch, extensions, lever, etc.) that it should
be linked to for graphics and/or part-list.
And even a switch can have auxiliary contacts that can be mounted
together and that leads to slave-contacts of a contact...
Best regards and: Merry Christmas!
plc-user
QElectroTech → Posts by plc-user
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.034 seconds (42% PHP - 58% DB) with 5 queries