ok ... added!
For next rework:
Please use the elements from repository!
I added element-names and adjusted some terminal-positions!
You are not logged in. Please login or register.
QElectroTech → Posts by plc-user
ok ... added!
For next rework:
Please use the elements from repository!
I added element-names and adjusted some terminal-positions!
... einen Anhang habe ich noch!
Hallo Luf,
bei QET und SVG sprechen wir in beiden Fällen von Vektor-Grafik! Also prima skalierbar! Deshalb wäre es schlecht, wenn Du Pixel-Bilder im Plan verwenden würdest!
Habe "gerade mal fix" einen QET-Export einer Folio auf 750x560px und nochmal auf 75000x56000px gemacht.
Wenn ich mir die beiden Dateien im Vergleich anschaue, sind dort "nur" andere Faktoren für "transform=matrix(..." angegeben.
O.k. - das sind ziemlich viele, aber die brauchst Du doch nicht händisch ändern: Dafür gibt es Inkscape!
Du exportierst also zunächst die QET-Datei so groß wie möglich und dann öffnest Du die SVG in Inkscape.
In den Dokument-Eignenschaften die Dokument-Größe auf die gewünschten Werte setzen und den Inhalt skalieren.
Ich kenne Deine Datei nicht, aber so wäre meine Vorgehensweise, solange Du die Sourcen von QET nicht selber kompilieren kannst.
EDIT: Hatte die Anhänge vergessen...
Gruß
plc-user
Hallo Luf,
Das sind ja mal große Dinge, die Du vorhast!
Willst Du Dir eine Wandtapete mit QET gestalten?
Einige Vorgaben in QET sind so enthalten, weil sich die Entwickler nicht vorstellen konnten, daß jemand irgendwas anderes (oder wie in diesem Fall) größeres braucht! Ob genau diese Anforderung auch dazugehört oder ob es echte technische Gründe für die Werte gibt, kann ich nicht sagen.
Deine Formulierung suggeriert mir, daß Du die Werte für Deine lokale Installation schon eingetragen und kompiliert hast. Ist das so?
Und: Funktioniert das?
Diese Anforderung macht natürlich neugierig:
In welcher Branche werden (Schalt-) Pläne auf einer einzelnen Seite auf dann auch noch als SVG benötigt oder gefordert?
Gruß
plc-user
Please read the names of attached files again, spotu:
Both files, that are attached have the same name and the same content!
@Pai54svt263:
Remark:
The version of QET_ElementScaler in the download-section of QElectroTech may not be the most recent and may contain errors, that are already fixed in official releases.
I recommend to always use the latest version of QET_ElementScaler available at github:
https://github.com/plc-user/QET_ElementScaler
In the release-section you find the latest binaries I made.
The source code could be even more up-to-date...
To check the version, call QET_ElementScaler from command-line without any parameter.
The version-number is shown within the first few lines.
At the moment Version 0.5.3 is available as compiled binaries.
Salut Laurent !
With the help of that shell script, all occurrences of more than x decimal places (default: 5) are searched for in all elements in the current directory.
This raises questions for me:
- Who knows this script?
- Who uses this script?
- Is it also available for win?
I have extended the call a little to only count the elements in official common collection.
With original setting of 5 or more decimals:
$ ./detect_elements_bad_coordinates.sh | awk -F ":" '{ print $1 }' | sort | uniq | wc -l
1190
$
search for 4 or more decimals:
$ ./detect_elements_bad_coordinates.sh | awk -F ":" '{ print $1 }' | sort | uniq | wc -l
2004
$
If I then know which files are affected: How do I fix them?
Should I really go through the file(s) by hand in a text editor and change the values? Or use the element editor to click on each graphical part to edit?
It would be much more practical if this were done automatically in the background by the software I use to create the graphics!
The decimal places are already limited to two in the element editor, don't we want to be consistent and write only two decimal places to the file?
You can only import dxf for Elements!
So the menu-entry is only available in Element-Editor!
Please replece elements Pilz X3 and PIlz IX1 (topic above) with corrected one in elements library.
Won't be possible, because you added the same file twice!
So I did a quick look, I never quite finished the logic for nested blocks, so that is the problem here. I'll add it to the to do list. Thank you.
At least we don't need to discuss font sizes with this file: All texts are “painted” into the drawing by lines and polygons...
The dxf contains Blocks in Blocks in Blocks in.....
That's currently not supported by dxf2elmt, but developer is working on it!
Use CAD-Software, to "explode" all blocks.
Then dxf2elmt produces beautiful elements!
i made a deeper dive into the source of the plugin
Within the plugin i switched positions with the down button.
(...)
It looks as if the properties of the terminals are switched (ground and standart) and not, like i hoped the positions within the plugin.
the solution is there only someone needs to implement it
The source code of qet_tb_generator has not been changed for four years. How high do you think the chances are that it is being worked on “today”?
The plugin is python code: Can't you perhaps get together with someone who "speaks" Python and see how the problem can be fixed, LievenC and andi11?
You seem to have already found the problematic part...
I found out that if I can redeclare an element in the schematic, e.g. the "50_residual_current_circuit_breaker", to a "master" and then redeclare the "/10_electric/98_graphics/99_assembly_plan/01_thumbnails_mounting_plate/abb/012_abb_rcd_4p.elmt" from "thumbnail" to "slave" and then I can establish a link from schematic to mounting plate.
Is that really the only way to have mouning plate graphics linked to elements in the schematic?
Ja, im Moment ist das leider so!
Und ich glaube, das steht auch nicht ganz oben auf der Prioritätenliste, wenn der Haupt-Entwickler wieder voll einsatzfähig ist.
Es besteht natürlich immer die Möglichkeit, jemanden zu finden, der C++ unter Qt programmieren kann und Spaß daran hat, an QElectroTech mitzuarbeiten! Vielleicht kennst Du jemanden, stefan.123? Oder vielleicht kannst Du selber teilnehmen?
Ich finde es immer sehr schade, wenn hier nach neuen supertollen Funktionen gefragt wird, aber scheinbar niemand bereit ist, sein/ihr Wissen und Können hier im Projekt einzubringen.
Ich bin hier auch ganz langsam angefangen und habe Fragen gestellt und inzwischen traue ich mich daran, bestehende Funktionen zu hinterfragen und bearbeiten! Und einige davon sind bereits in QET eingeflossen...
Das geht nicht gegen Dich, stefan.123!!!
Ich wollte das nur mal loswerden...
Gruß
plc-user
Thanks, plc-user.
You're welcome!
Hello everyone!
What do you think about limiting the numerical values to two decimal places when saving elements with element-editor?
The background to the question.
For example, the elements contain such values (excerpt):
x1="-1.77636e-15" y5="6.91313" x5="-1.77636e-15"
dth="5.4" height="0.64596"/>
dth="5.4" height="0.64596"/>
idth="3" height="3.87576"/>
dth="3" height="3.87576"/>
idth="3.6" height="1.93788"/>
Where do these many decimal places come from?
Several possibilities:
- from a conversion tool
- copy and paste from the clipboard
- ???
I can't edit the third decimal place at the latest in the element editor itself because all input fields are limited to two decimal places.
Using mouse and keyboard, I can only move the individual graphical elements by a minimum of 0.1.
This means I can't change the values in such detail with on-board tools anyway!
How far do I have to zoom in the element editor to see the difference between “0” and “-1.77636e-15”?
So why all these decimal places?
I have included two screenshots in the appendix to show that the differences are hardly noticeable in most cases - not even with the selected (rather small) example element.
It's not like I'm just asking the question here and waiting for someone else to do the work: I've already prepared something and would like to ask your opinion on the topic, whether you think it makes sense too!
Looking forward to your comments!
Best regards
plc-user
@iznobe:
Wir werden das gesamte Programm an elektrischen Geräten der genannten Hersteller gerne veröffentlichen, wenn Du die Elemente erstellt und uns zur Verfügung gestellt hast!
Online-Translation to English:
We will be happy to publish the entire programme of electrical devices from the manufacturers mentioned if you have created the elements and made them available to us!
Online-Translation to French:
Nous publierons volontiers l'ensemble de la gamme d'appareils électriques des fabricants mentionnés si tu as créé les éléments et nous les as mis à disposition!
make -j48
I'm a little envious: I don't have 48 cores!
It seems you have more than one independent "problems":
Cannot read /home/andrew/sources/qt/qelectrotech-source-mirror/SingleApplication/singleapplication.pri: No such file or directory
did you fetch sources of "SingleApplication"?
Project ERROR: sqlite3 development package not found
on my Debian stable VM these "sql"-packages are installed:
ich@deb-devel:~$ dpkg -l | grep sql
ii libqt5sql5:amd64
ii libqt5sql5-sqlite:amd64
ii libqt6sql6:amd64
ii libqt6sql6-sqlite:amd64
ii libsqlite3-0:amd64
ii libsqlite3-dev:amd64
ii libsqlite3-tcl
ii sqlite3
ii sqlite3-tools
ich@deb-devel:~$
Hope it helps
Hello vadoola,
It's good that we agreed on the scaling after all! I knew there was a misunderstanding somewhere... but didn't see
Sometimes I have to read the documentation and comments in the source code several times, too: the language barrier (French, English, German, ...) is sometimes quite high and with sharp edges!
Take your time for the realization!
As we say in German: "Gut Ding braucht Weile!"
‘Good things take time!’
Salut Laurent !
Thanks for the links, but don't get me wrong:
I don't want to compile it, just want to use that plugin!
There are binaries for Linux and Win that run on Debian unstable and win10 that I can use on github: raulroda These binaries work for me.
EDIT (again):
Remark for me: Terminals in project need to be connected! Then the plugin works as expected!
In the meantime I rewrote the code for calling qet_tb_generator from diagram-editor: It looks very tidy now.
I used the existing locations for the various systems and added new path "dataDir()/binary" to search for the plugin. A few lines of additional output to log-file can be removed again, if we want.
If you look at the “imperial” DXF from last week:
Which one matches the original sizes better?
I know that we won't be perfect with text-size, because for elements we have to round to integer numbers, but I think we should be as close to the original as possible!
Hello vadoola,
let's put it this way:
I created a QET-Element just with the use of element-editor.
In the attachment you see, that the texts are the same size as the height of the rectangles.
So in my opinion we do not have to use another factor than 2.0 for the "real world" size in the DXF!
When DXF says circle has a diameter of 10mm then in element it is 20.
If it says 1 inch in the DXF it will be 50.8 in the element whether it is a graphical part or a text!
It does not matter if text or anything else: There is always a "scale" of 1mm = 2px
I checked in all DXFs I have: Fits everywhere!
If you have a DXF where the factor of 2.0 does not fit: Let me see.
Salut Laurent !
Thanks again, Laurent!
The Debian-Version is also working pretty good!
A few questions about "qet_tb_plugin":
As I understand correctly, the plugin may or even can only be started, when a project is loaded, correct?
"qet_tb_plugin" or "qet_tb_plugin.exe" is an executable file, right?
And:
Similar to dxf2elmt or QET_ElementScaler QET only starts the executable from known locations ... QET does not download python or source-code of the plugin, right?
If all three answers are "yes", some of the "spaghetti-code" in qetdiagrameditor.cpp can be simplified and "automated" similar to configDir() or dataDir().
Already making first attempts...
Salut Laurent !
Didn't find any new Debian-Packages on QET-Repo but my local created binary works very well with the latest changes!
The latest "major" changes mainly concern the ReadyToUse version for Windows and it works exactly as I know it from the “old” version ... only with more comprehensible directories for projects, exports, etc.!
The Install-Version for Windows also works as expected.
Best regards,
plc-user
Hello vadoola,
(...) A font point is defined as 1pt = 1/72 inches, which comes out to 1pt = 0.3528mm.
Based on this conversion the values that are being generated are "correct", because text height in mm would be multiplied by a factor of roughly 2.83. instead of the 2 used to convert mm to pixels.
Just to understand you correctly:
You think the calculation of the text size is correct if a text that fits well into a rectangle in the DXF is much bigger and no longer fits into the same rectangle in the converted element? And that's because it says somewhere that a px is not as big as a pt? Seriously?
Attached is another example to clarify what I mean:
A DXF file in which I have inserted an 11 mm high text into a field of about 12 mm. Next to it is the converted element file, where you can see that the text “11 mm” definitely does not fit into the same field. In addition, the element file in which I changed the text “11 mm” to the appropriate size “22” and moved it.
I am explicitly not talking about the text position here, as we both know that this does not yet fit: I'm talking about the text size!
Note:
I used dxf2elmt - sources from last weeks commit c3a5b2a.
QElectroTech → Posts by plc-user
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.027 seconds (77% PHP - 23% DB) with 5 queries