You are not logged in. Please login or register.
QElectroTech → Posts by plc-user
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. 
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.
Great tool, thanks plc-user.
You're welcome, Laurent!
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...
Start reading here:
https://qelectrotech.org/forum/viewtopi … 713#p13713
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
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
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/
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
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!
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!
QElectroTech → Posts by plc-user
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.016 seconds (40% PHP - 60% DB) with 6 queries