You are not logged in. Please login or register.
QElectroTech → Import DXF → New .dxf to .elmt Conversion Program
I see the problem:
if info {
//prints info
} else if verbose_output {
//print to stdout
}if the info flag is passed (which defaults to true), it never checks if the verbose flag is used.
Looks like this change was made as part of commit 67557ff on 2022-10-15
@vadoola:Do you think it's possible to solve this problem?
https://github.com/antonioaja/dxf2elmt/issues/2
Do we still have to do ‘select all and make explode all’ and save again in a DXF program before using df2elmt?
@vadoola:Do you think it's possible to solve this problem?
https://github.com/antonioaja/dxf2elmt/issues/2Do we still have to do ‘select all and make explode all’ and save again in a DXF program before using df2elmt?
Since I don't really have access to the Antonioaja's issue tracker I started issues on my own.
I created two issues that might be relevant: https://github.com/Vadoola/dxf2elmt/issues/8 and https://github.com/Vadoola/dxf2elmt/issues/4
I started digging into this a little last night just looking at that circle dxf in the initial issue. It looks like it's using an Insert Element which is why it's not working. I'm not an expert on dxf so I don't know if it's this specific dxf or all blocks in dxf that use an Insert Entity.
This is one the things I want to focus on first, as I feel this is a big limitation.
@vadoola:Do you think it's possible to solve this problem?
https://github.com/antonioaja/dxf2elmt/issues/2Do we still have to do ‘select all and make explode all’ and save again in a DXF program before using df2elmt?
Just an FYI I seem to have solved this. I haven't committed it yet, because the code is a bit crude and I want to clean it up first. Hopefully I will get around to it sometime this week.
Nice. 
Macos arm64 dxf2elmt for test.
FYI it's only work in an terminal...
I see the problem:
if info { //prints info } else if verbose_output { //print to stdout }if the info flag is passed (which defaults to true), it never checks if the verbose flag is used.
Looks like this change was made as part of commit 67557ff on 2022-10-15
I think isn't fixed. We can't launch new dxf2elmt directly on QET element editor.
dxf2elmt-macos-arm64.zip 1.03 mb, 27 downloads since 2024-09-08
Hello Vadoola!
Salut Laurent !
Some questions about default settings in dxf2elmt:
In all dxf drawings I had to convert so far, the individual splines were not really long or complex. That's why I'm wondering whether we really need 100 segments in the corresponding polygon for each spline as a default setting for the conversion to QET elements?
I have tried a few files with different numbers of polygon segments and I think that 10 or 12 points should be enough for good results.
Do we really need the full precision of up to 14 decimal places from dxf for use in QET elements?
For all graphical elements in the element editor, a maximum of two decimal places can be entered or edited and the graphical editor only allows changes in the tenths range. Therefore, in my opinion, it is completely sufficient to use a maximum of two decimal places in conversion programs for QET elements.
Both default settings lead to the element files being unnecessarily bloated, which can only be corrected very poorly or not at all with the element editor's on-board tools.
An example is attached:
One of the two elements "weighs" only 292.9 kB, the other "weighs" 3.4 MB! A factor of almost 12 – in this case I would say: Size does matter!
(Remark: In the elements used in the appendix, I have inserted a meaningful definition line by hand so that QET displays the elements correctly.)
I can correct the number of decimal places with QET_ElementScaler, but I can't reduce the number of polygon points of converted splines with it...
In this context:
I also noticed that the converted element file contains polygons with a only one point! QET_ElementScaler filters them out, but should they not be eliminated from the element file in the first place?
Best regards
plc-user
Polygon-Versuche.qet.xz 740.77 kb, 43 downloads since 2024-09-08
Macos arm64 dxf2elmt for test.
FYI it's only work in an terminal...
Hmm, when I initially made my announcement I had only tested the CLI, since I hadn't realized antonioaja had made changes to the argument parsing, I just assumed it had still worked from QET. This time around I acatually tested it in QET and it seemed to work fine on my machine, although maybe I made a mistake. I'm currently testing it on Windows, and I now see that I have a dxf2elmt exe in both C:\Program files\QElectrotech\bin as well as C:\Users\Vadoola\AppData\Roaming\qet\binary. Perhaps I dropped the exe in he wrong place and it was using the old 0.30 release version from antonioaja repository. I'll take another look into this, and do a more thourough testing job this time around.
In all dxf drawings I had to convert so far, the individual splines were not really long or complex. That's why I'm wondering whether we really need 100 segments in the corresponding polygon for each spline as a default setting for the conversion to QET elements?
I have tried a few files with different numbers of polygon segments and I think that 10 or 12 points should be enough for good results.
I agree that 100 does seem like a lot and could make the resulting element unnecessarily large. This should be an easy change, I'll do some testing to see how 10-12 points do, and make sure it still works well.
Do we really need the full precision of up to 14 decimal places from dxf for use in QET elements?
For all graphical elements in the element editor, a maximum of two decimal places can be entered or edited and the graphical editor only allows changes in the tenths range. Therefore, in my opinion, it is completely sufficient to use a maximum of two decimal places in conversion programs for QET elements.
Completely agree, I can change the default behavior to round to 2 decimals of precision.
I also noticed that the converted element file contains polygons with a only one point! QET_ElementScaler filters them out, but should they not be eliminated from the element file in the first place?
While doing some testing this past week on QET element files I found on github, there were a few I found converted with (I believe) the old C++ dxftoelemt that had polygon's with only 2 points. I created an issue (https://github.com/Vadoola/dxf2elmt/issues/120) to try and filter those out and convert them to lines. I could also easily filter out polygons with only 1 point and just not write them out, but I'll take a closer look at the file you attached and try to find out WHY there are single point polygons in the first place. Perhaps removing them isn't the proper way forward and they have a purpose and need to be handled differently (like a point that needs a thickness or something, that is converted to a circle element?)
Antonioaja has also responded to my pull request (https://github.com/antonioaja/dxf2elmt/pull/3). I asked for clarification if he is fine with my fork being the QElectrotech recommended fork, but it sounds like he said the project did what he needed and had no real plans to continue development.
plc-user could you share the original dxf file that created these single point polygons?
Hello Vadoola!
Salut Laurent !
With such conversion tools, we should always consider what the end result should be used for!
As we say in German: "The worm must taste good to the fish, not to the fisherman!"
I have already said this in other forum posts:
QET is primarily a program for electrical (pneumatic, hydraulic, etc.) circuit diagrams with the additional function of also sketching assembly plans.
QET is not a tool for drawing exact scales on a specific paper format. Therefore, in my opinion, we do not need the full precision with 14 decimal places and the 100% precise approximation of polygons to splines from the dxf file.
This is also the reason why I try to reduce the size of polygons in the QET_ElementScaler if, for example, two successive points lie on top of each other, but that's another topic...
My knowledge of DXF is poor, but as I see it, many commercial programs, for example, export single circles as multiple splines, which can never become a space-saving circle or ellipse again when converting. Unless you rework the element in the element editor by hand, which in the end often leads to the realization that you could have drawn the element yourself more easily and, above all, more quickly...
So here, too, we have to find a good compromise between "I recognize the essential features of the element" and the absolute precision of the original drawing. This also includes the polygons with only one point each: The original dxf program must have "thought" of representing some parts as 1-point polygons, but do we need that in the QET element? I didn't find anything missing from the example!
On the contrary:
In the dxf and therefore also in the resulting QET element, there are very often polygons that lie directly on top of each other, but which are not recognizable as individual graphic elements.
Nowadays, this is often due to the fact that devices are no longer made from several 2D drawings, but are created directly as 3D models. A 2D dxf drawing is then made from this, which accordingly also contains many hidden lines that inflate the resulting QET element, but do not provide any additional information.
This is in no way intended to criticize antonioaja's and Vadoola's work: On the contrary!
I really appreciate the work, but we should also think about the purpose of the result.
With this discussion I would like to make the program even better!
dxf-testfile_for_1-point-polygons.dxf 235.18 kb, 39 downloads since 2024-09-09
This also includes the polygons with only one point each: The original dxf program must have "thought" of representing some parts as 1-point polygons, but do we need that in the QET element? I didn't find anything missing from the example!
This is part of why I wanted to see the original dxf that created these single point polygons (thank you for attaching it). I agree that a single point polygon makes no sense, and these could possible be lines that extend out in the direction away/into the viewport, and they are represented as single point polygons in the exported dxf. I just want to make sure that these aren't being created by some bug in dxf2elemt that is dropping points in the dxf that should exist in the resulting element file. If after some testing we can safely say there is no bug and these are represented in the dxf as single point polygons, it would be easy to filter those out simply by looking at the length of the vector holding the points. Similarly if we end up with a polygon with only two points, it's easy to recognize that and convert it to a line.
My knowledge of DXF is poor, but as I see it, many commercial programs, for example, export single circles as multiple splines, which can never become a space-saving circle or ellipse again when converting. Unless you rework the element in the element editor by hand
On the contrary:
In the dxf and therefore also in the resulting QET element, there are very often polygons that lie directly on top of each other, but which are not recognizable as individual graphic elements.
Nowadays, this is often due to the fact that devices are no longer made from several 2D drawings, but are created directly as 3D models. A 2D dxf drawing is then made from this, which accordingly also contains many hidden lines that inflate the resulting QET element, but do not provide any additional information.
I agree, converting multiple splines that form a circle into a circle element within QET would be preferred, as would getting rid of extra polygons that overlap and aren't seen, and polygons with multiple points that form a straight line. All of these are great ideas and something that I can try and work on, however they can get far more complicated than just checking the number of points. With a straight line multi-point polygon I need to do some math on it to determine if it's a line.
With the multiple spline circles, or overlapping polygons I need to look at multiple elements in combination to determine the shape, this gets far more complicated, as now not only am I trying to determine a shape from multiple elements, but I might need to do this processing on multiple combinations of splines withing the dxf. each new object would significantly increase the number of combinations that need to be looked at.
I could try and start with an easier route. After I get clean up and get the block importing finalized I could try and do some shape testing for circles made of splines etc, just within each block. This would reduce the number of combinations that need to be processed.
I think these points that you have brought up are very worth goals, and I'll add them to the issue tracker for the project, but they are quite complicated features, and I'll probably concentrate on some other simpler clean up and fixes before I try and tackle them.
Hello Vadoola!
Hallo plc-user!
Thanks Vadoola for fixing stdout we can use now your dxf2elmt binary on QET element, but FYI build make some warnings:
[13:22:48] laurent@debian:~$ git clone https://github.com/Vadoola/dxf2elmt.git dxf2elmt_vadoola
Clonage dans 'dxf2elmt_vadoola'...
remote: Enumerating objects: 410, done.
remote: Counting objects: 100% (181/181), done.
remote: Compressing objects: 100% (103/103), done.
remote: Total 410 (delta 122), reused 136 (delta 78), pack-reused 229 (from 1)
Réception d'objets: 100% (410/410), 95.90 Kio | 1.88 Mio/s, fait.
Résolution des deltas: 100% (256/256), fait.
[13:23:01] laurent@debian:~$ cd /home/laurent/dxf2elmt_vadoola
[13:23:04] laurent@debian:~/dxf2elmt_vadoola$ cargo build --release
Compiling autocfg v1.3.0
Compiling crossbeam-utils v0.8.20
Compiling cfg-if v1.0.0
Compiling proc-macro2 v1.0.86
Compiling unicode-ident v1.0.12
Compiling rayon-core v1.12.1
Compiling serde v1.0.207
Compiling libc v0.2.155
Compiling either v1.13.0
Compiling adler32 v1.2.0
Compiling bitflags v1.3.2
Compiling syn v1.0.109
Compiling adler v1.0.2
Compiling utf8parse v0.2.2
Compiling weezl v0.1.8
Compiling byteorder v1.5.0
Compiling anstyle-query v1.1.1
Compiling anstyle v1.0.8
Compiling colorchoice v1.0.2
Compiling is_terminal_polyfill v1.70.1
Compiling rustix v0.38.34
Compiling color_quant v1.1.0
Compiling bitflags v2.6.0
Compiling heck v0.5.0
Compiling hashbrown v0.12.3
Compiling iana-time-zone v0.1.60
Compiling bytemuck v1.16.3
Compiling linux-raw-sys v0.4.14
Compiling scoped_threadpool v0.1.9
Compiling anyhow v1.0.86
Compiling strsim v0.11.1
Compiling clap_lex v0.7.2
Compiling fastrand v2.1.0
Compiling once_cell v1.19.0
Compiling wild v2.2.1
Compiling hex_color v3.0.0
Compiling xml-rs v0.7.0
Compiling crc32fast v1.4.2
Compiling encoding_rs v0.8.34
Compiling anstyle-parse v0.2.5
Compiling miniz_oxide v0.3.7
Compiling itertools v0.10.5
Compiling gif v0.11.4
Compiling num-traits v0.2.19
Compiling num-bigint v0.3.3
Compiling num-rational v0.3.2
Compiling miniz_oxide v0.4.4
Compiling indexmap v1.9.3
Compiling deflate v0.8.6
Compiling anstream v0.6.15
Compiling clap_builder v4.5.15
Compiling xmltree v0.8.0
Compiling png v0.16.8
Compiling quote v1.0.36
Compiling dxf v0.5.0
Compiling crossbeam-epoch v0.9.18
Compiling getrandom v0.2.15
Compiling syn v2.0.74
Compiling crossbeam-deque v0.8.5
Compiling simple-xml-builder v1.1.0
Compiling num-integer v0.1.46
Compiling num-complex v0.3.1
Compiling num-traits v0.1.43
Compiling enum_primitive v0.1.1
Compiling num-iter v0.1.45
Compiling rayon v1.10.0
Compiling tempfile v3.12.0
Compiling trait-set v0.2.0
Compiling chrono v0.4.38
Compiling uuid v0.8.2
Compiling uuid v1.10.0
Compiling bspline v1.1.0
Compiling num v0.3.1
Compiling clap_derive v4.5.13
Compiling jpeg-decoder v0.1.22
Compiling tiff v0.6.1
Compiling image v0.23.14
Compiling clap v4.5.15
Compiling dxf2elmt v0.3.4 (/home/laurent/dxf2elmt_vadoola)
warning: unused import: `dxf::Drawing`
--> src/qelmt/mod.rs:8:5
|
8 | use dxf::Drawing;
| ^^^^^^^^^^^^
|
= note: `#[warn(unused_imports)]` on by default
warning: unused variable: `spline`
--> src/qelmt/mod.rs:59:36
|
59 | EntityType::Spline(ref spline) => todo!(),
| ^^^^^^ help: if this is intentional, prefix it with an underscore: `_spline`
|
= note: `#[warn(unused_variables)]` on by default
warning: unused variable: `ellipse`
--> src/qelmt/mod.rs:61:37
|
61 | EntityType::Ellipse(ref ellipse) => todo!(),
| ^^^^^^^ help: if this is intentional, prefix it with an underscore: `_ellipse`
warning: unused variable: `lwpolyline`
--> src/qelmt/mod.rs:63:40
|
63 | EntityType::LwPolyline(ref lwpolyline) => todo!(),
| ^^^^^^^^^^ help: if this is intentional, prefix it with an underscore: `_lwpolyline`
warning: unused variable: `solid`
--> src/qelmt/mod.rs:64:35
|
64 | EntityType::Solid(ref solid) => todo!(),
| ^^^^^ help: if this is intentional, prefix it with an underscore: `_solid`
warning: struct `Definition` is never constructed
--> src/qelmt/mod.rs:25:12
|
25 | pub struct Definition {
| ^^^^^^^^^^
|
= note: `#[warn(dead_code)]` on by default
warning: field `0` is never read
--> src/qelmt/mod.rs:42:9
|
42 | Arc(Arc),
| --- ^^^
| |
| field in this variant
|
help: consider changing the field to be of unit type to suppress this warning while preserving the field numbering, or remove the field
|
42 | Arc(()),
| ~~
warning: field `0` is never read
--> src/qelmt/mod.rs:43:13
|
43 | Ellipse(Ellipse),
| ------- ^^^^^^^
| |
| field in this variant
|
help: consider changing the field to be of unit type to suppress this warning while preserving the field numbering, or remove the field
|
43 | Ellipse(()),
| ~~
warning: field `0` is never read
--> src/qelmt/mod.rs:44:13
|
44 | Polygon(Polygon),
| ------- ^^^^^^^
| |
| field in this variant
|
help: consider changing the field to be of unit type to suppress this warning while preserving the field numbering, or remove the field
|
44 | Polygon(()),
| ~~
warning: field `0` is never read
--> src/qelmt/mod.rs:46:10
|
46 | Text(Text),
| ---- ^^^^
| |
| field in this variant
|
help: consider changing the field to be of unit type to suppress this warning while preserving the field numbering, or remove the field
|
46 | Text(()),
| ~~
warning: field `0` is never read
--> src/qelmt/mod.rs:47:10
|
47 | Line(Line),
| ---- ^^^^
| |
| field in this variant
|
help: consider changing the field to be of unit type to suppress this warning while preserving the field numbering, or remove the field
|
47 | Line(()),
| ~~
warning: variants `DynamicText` and `Terminal` are never constructed
--> src/qelmt/mod.rs:45:5
|
41 | enum Objects {
| ------- variants in this enum
...
45 | DynamicText(DynamicText),
| ^^^^^^^^^^^
...
48 | Terminal(Terminal),
| ^^^^^^^^
warning: struct `Description` is never constructed
--> src/qelmt/mod.rs:74:12
|
74 | pub struct Description {
| ^^^^^^^^^^^
warning: multiple fields are never read
--> src/qelmt/mod.rs:79:5
|
78 | pub struct DynamicText {
| ----------- fields in this struct
79 | text: String,
| ^^^^
80 | info_name: Option<String>,
| ^^^^^^^^^
81 | x: f64,
| ^
82 | y: f64,
| ^
83 | z: i32,
| ^
84 | rotation: f64,
| ^^^^^^^^
85 | uuid: Uuid,
| ^^^^
86 | h_alignment: HAlignment,
| ^^^^^^^^^^^
87 | font: String,
| ^^^^
88 | text_from: String,
| ^^^^^^^^^
89 | v_alignment: VAlignment,
| ^^^^^^^^^^^
90 | frame: bool,
| ^^^^^
91 | text_width: i32,
| ^^^^^^^^^^
92 | keep_visual_rotation: bool,
| ^^^^^^^^^^^^^^^^^^^^
warning: fields `x`, `y`, `uuid`, `name`, and `orientation` are never read
--> src/qelmt/mod.rs:97:5
|
96 | pub struct Terminal {
| -------- fields in this struct
97 | x: f64,
| ^
98 | y: f64,
| ^
99 | uuid: Uuid,
| ^^^^
100 | name: String,
| ^^^^
101 | orientation: TermOrient,
| ^^^^^^^^^^^
warning: struct `Names` is never constructed
--> src/qelmt/mod.rs:109:12
|
109 | pub struct Names {
| ^^^^^
warning: struct `Name` is never constructed
--> src/qelmt/mod.rs:113:12
|
113 | pub struct Name {
| ^^^^
warning: struct `ElmtUuid` is never constructed
--> src/qelmt/mod.rs:118:12
|
118 | pub struct ElmtUuid {
| ^^^^^^^^
warning: enum `ItemType` is never used
--> src/qelmt/mod.rs:123:6
|
123 | enum ItemType {
| ^^^^^^^^
warning: variants `Left`, `Center`, and `Right` are never constructed
--> src/qelmt/mod.rs:138:5
|
137 | enum HAlignment {
| ---------- variants in this enum
138 | Left,
| ^^^^
139 | Center,
| ^^^^^^
140 | Right,
| ^^^^^
warning: variants `Top`, `Center`, and `Bottom` are never constructed
--> src/qelmt/mod.rs:144:5
|
143 | enum VAlignment {
| ---------- variants in this enum
144 | Top,
| ^^^
145 | Center,
| ^^^^^^
146 | Bottom,
| ^^^^^^
warning: variants `SimpleArrow`, `TriangleArrow`, `Circle`, and `Diamond` are never constructed
--> src/qelmt/mod.rs:151:5
|
149 | enum LineEnd {
| ------- variants in this enum
150 | None,
151 | SimpleArrow,
| ^^^^^^^^^^^
152 | TriangleArrow,
| ^^^^^^^^^^^^^
153 | Circle,
| ^^^^^^
154 | Diamond,
| ^^^^^^^
warning: variants `North`, `East`, `South`, and `West` are never constructed
--> src/qelmt/mod.rs:158:5
|
157 | enum TermOrient {
| ---------- variants in this enum
158 | North,
| ^^^^^
159 | East,
| ^^^^
160 | South,
| ^^^^^
161 | West,
| ^^^^
warning: enum `LinkType` is never used
--> src/qelmt/mod.rs:165:6
|
165 | enum LinkType {
| ^^^^^^^^
warning: struct `ElemInfos` is never constructed
--> src/qelmt/mod.rs:175:12
|
175 | pub struct ElemInfos {
| ^^^^^^^^^
warning: struct `ElemInfo` is never constructed
--> src/qelmt/mod.rs:179:12
|
179 | pub struct ElemInfo {
| ^^^^^^^^
warning: multiple fields are never read
--> src/qelmt/arc.rs:4:5
|
3 | pub struct Arc {
| --- fields in this struct
4 | x: f64,
| ^
5 | y: f64,
| ^
6 | width: f64,
| ^^^^^
7 | height: f64,
| ^^^^^^
8 | start: f64,
| ^^^^^
9 | angle: f64,
| ^^^^^
10 | style: String,
| ^^^^^
11 | antialias: bool,
| ^^^^^^^^^
warning: multiple fields are never read
--> src/qelmt/line.rs:5:5
|
4 | pub struct Line {
| ---- fields in this struct
5 | length2: f64,
| ^^^^^^^
6 | end2: LineEnd,
| ^^^^
7 | length1: f64,
| ^^^^^^^
8 | x1: f64,
| ^^
9 | y1: f64,
| ^^
10 | x2: f64,
| ^^
11 | y2: f64,
| ^^
12 | style: String,
| ^^^^^
13 | end1: LineEnd,
| ^^^^
14 | antialias: bool,
| ^^^^^^^^^
warning: fields `rotation`, `value`, `x`, `y`, `font`, and `color` are never read
--> src/qelmt/text.rs:5:5
|
4 | pub struct Text {
| ---- fields in this struct
5 | rotation: f64,
| ^^^^^^^^
6 | value: String,
| ^^^^^
7 | x: f64,
| ^
8 | y: f64,
| ^
9 | font: String,
| ^^^^
10 | color: HexColor,
| ^^^^^
warning: fields `x` and `y` are never read
--> src/qelmt/polygon.rs:4:5
|
3 | struct Coordinate {
| ---------- fields in this struct
4 | x: f64,
| ^
5 | y: f64,
| ^
warning: fields `style`, `antialias`, `coordinates`, and `closed` are never read
--> src/qelmt/polygon.rs:9:5
|
8 | pub struct Polygon {
| ------- fields in this struct
9 | style: String,
| ^^^^^
10 | antialias: bool,
| ^^^^^^^^^
11 | coordinates: Vec<Coordinate>,
| ^^^^^^^^^^^
12 | closed: bool,
| ^^^^^^
warning: fields `height`, `width`, `style`, `x`, `y`, and `antialias` are never read
--> src/qelmt/ellipse.rs:4:5
|
3 | pub struct Ellipse {
| ------- fields in this struct
4 | height: f64,
| ^^^^^^
5 | width: f64,
| ^^^^^
6 | style: String,
| ^^^^^
7 | x: f64,
| ^
8 | y: f64,
| ^
9 | antialias: bool,
| ^^^^^^^^^
warning: `dxf2elmt` (bin "dxf2elmt") generated 32 warnings (run `cargo fix --bin "dxf2elmt"` to apply 1 suggestion)
Finished `release` profile [optimized] target(s) in 23.49s
Hello Laurent
Thanks Vadoola for fixing stdout we can use now your dxf2elmt binary on QET element
You're welcome. I disabled the info printing by default which cleared this up. It occurred to me last night that really a better solution would be to make the info and verbose flags mutually exclusive. The info is on by default if you are running it from the CLI, but passing the -v flag disables the info, it's one or the other. I'll create an issue to document that, but I won't worry about it right away.
but FYI build make some warnings:
Sorry, you checked out my master branch which is in a partially complete state. If you grab commit 03efbd8, that has the stdout fix, but shouldn't generate any warnings.
The master branch commit 8309837 has some partially completed restructuring. I'm adding in some code to read the DXF and store the element information before writing it out to XML. This should make it easier for some entities to reference other parts of the drawing (such as blocks), and I believe creates some better encapsulation. Rust by default warns on dead code, functions and structs that are never used, code that can't be reached etc. None of this new code to store the element information from the DXF is called anywhere, hence the warnings. In the main.rs there is line 42:
mod qelmt;This tells rust the qelmt module (similar to a C++ namespace) exists. If you comment it out, rust won't compile it and all the warning should go away. I had meant to do this before committing, but obviously forgot. All the rest of the code functions as it did before, this last commit is just some of the ground work for refactoring.
Hello Vadoola,
the angles for the graphic element "arc" are available as integers without decimal places in QET.
I have not made a local git-repository of your code, so here only as git-style diff:
--- arc_org.rs 2024-09-11 13:01:30.000000000 +0200
+++ arc.rs 2024-09-15 19:00:49.030338390 +0200
@@ -10,9 +10,9 @@
arc_xml.add_attribute("width", two_dec(self.radius * 2.0));
arc_xml.add_attribute("height", two_dec(self.radius * 2.0));
if self.start_angle < 0.0 {
- arc_xml.add_attribute("start", two_dec(-self.start_angle));
+ arc_xml.add_attribute("start", -self.start_angle.round());
} else {
- arc_xml.add_attribute("start", two_dec(self.start_angle));
+ arc_xml.add_attribute("start", self.start_angle.round());
}
let temp = if self.start_angle > self.end_angle {
@@ -22,9 +22,9 @@
};
if temp < 0.0 {
- arc_xml.add_attribute("angle", two_dec(-temp));
+ arc_xml.add_attribute("angle", -temp.round());
} else {
- arc_xml.add_attribute("angle", two_dec(temp));
+ arc_xml.add_attribute("angle", temp.round());
}
arc_xml.add_attribute("antialias", "false");
if self.thickness > 0.1 {
Hello Vadoola,
the angles for the graphic element "arc" are available as integers without decimal places in QET.
Good catch, I'll get that corrected.
Hello Scorpio810 and plc-user,
Support for blocks has now been added. The most recent commit 53b3b94 has block support.
There was a pretty big overhaul of the way I handled the conversion, and it's possible some regressions have snuck in that I am unaware of. There are 2 regressions that I do know of:
The parameter to pass spline steps is currently being ignored
The parameter to choose between Text and Dynamic Text is also ignored, but it now defaults to Dynamic Text
I intend to clean both of these up, but I thought now would be a good time to get some more people testing it and looking for issues. Then after I fix the 2 issues above, and any other related ones, I'll tag it as a new revision.
Hello Vadoola,
Hallo plc-user
./dxf2elmt 05DI-AD16DIX-10.dxf
Error: Failed to load 05DI-AD16DIX-10...
Make sure the file is a valid .dxf file.
Caused by:
the code pair '[@110865]340/962' was not expected at this time: expected 0/ENDSEC at line/offset 110865
05DI-AD16DIX-10.dxf 968.97 kb, 32 downloads since 2024-09-27
Linux Debian sid 64 bits binary.
dxf2elmt 2.41 mb, 23 downloads since 2024-09-27
Windows 64 binary.
dxf2elmt.zip 1.14 mb, 39 downloads since 2024-09-27
Hello Vadoola,
Hallo plc-user./dxf2elmt 05DI-AD16DIX-10.dxf
Error: Failed to load 05DI-AD16DIX-10...
Make sure the file is a valid .dxf file.Caused by:
the code pair '[@110865]340/962' was not expected at this time: expected 0/ENDSEC at line/offset 110865
A quick look shows this is an old issue, it gives the same error with the last released version from antonioaja. It appears the issue is the dxf crate (Rust term for a library) itself failing to parse the file, and it looks like it's an XRECORD entity that's failing.
The DXF crate unfortunately hasn't had a release in 3 years, although the last commit on github was 6 months ago. I did a quick look around when I forked this code and was updating crates to see if there was a better and or more maintained dxf crate for Rust and didn't find one. I'll have to dig into this more to solve the issue, but it may require pulling the dxf crate direct from the github master branch, or even forking the crate to try and update it myself. Having to maintain my own fork would be unfortunate as I only have so much time, so we will see when I get a chance to dig into it a bit more.
macOS INTEL X86_64 binary
dxf2elmt 2.25 mb, 20 downloads since 2024-09-27
Do dxf files include scaling or dimensioning for the existing values?
When I look at the file Laurent attached in this post (https://qelectrotech.org/forum/viewtopi … 379#p20379), I see a value of 0.7158 for the terminal strip width, for example. That won't be millimetres and inches don't seem to be the unit for the values either. A suitable value might be something like 35 mm, as the terminal spacing (from screw to screw) would then be about 5 mm or 2/10 of an inch.
Since this drawing has to be scaled anyway in order to use it sensibly in QET, it would be very practical if the dimensioning of the values came directly from the dxf file. Then no additional effort would be required to obtain a suitable size of the element.
Bildschirmfoto_Klemmenbreite.png 4.67 kb, 20 downloads since 2024-09-27
Do dxf files include scaling or dimensioning for the existing values?
When I look at the file Laurent attached in this post (https://qelectrotech.org/forum/viewtopi … 379#p20379), I see a value of 0.7158 for the terminal strip width, for example. That won't be millimetres and inches don't seem to be the unit for the values either. A suitable value might be something like 35 mm, as the terminal spacing (from screw to screw) would then be about 5 mm or 2/10 of an inch.
Since this drawing has to be scaled anyway in order to use it sensibly in QET, it would be very practical if the dimensioning of the values came directly from the dxf file. Then no additional effort would be required to obtain a suitable size of the element.
So doing a quick look into it and found: "
AutoCAD 2000 (AC1015) the INSUNITS variable was introduced. This variable defines the drawing units" so it would depend on what version of DXF as to whether or not I could get this information.
If the files doesn't have scaling we might need to come up with a way to pass parameters to the underlying exe. After selecting the dxf QET has a popup with options that could be added, scaling spline steps etc maybe? I could possible add some GUI and a window to dxf2elmt itself but it will increase the size. If the main GUI interaction is from withing QET it would probably make more sense for QET to handle it, as it already brings along Qt, and dxf2elmt doesn't need to bring it along as a dependency.
The idea of scaling came when I looked at the converted element: The screw terminals are no longer round, but jagged!
This is because we want to limit dxf2elmt to two decimal places due to the file size, but the values for the polygons only differ to the third or fourth decimal place at such small scales.
With auxiliary programs such as dxf2elmt (or QET_ElementScaler) we should limit ourselves to the command line with no further interaction with the user! An additional GUI would probably not fit into the "look and feel" of QET and increases dependencies for the executable. And: We do not know in advance which scaling factor we have to apply here. Most users will most likely not have a CAD program with which they can edit dxf to see in advance which factor should be applied. That is the difference to QET_ElementScaler: There, you stay with the workflow in QET.
Therefore:
If we can read a factor from the dxf file, we should apply it, but otherwise not put a lot of effort into having the user enter a factor.
Then we just have to bite the bullet and increase the number of decimal places to four, for example.
Bildschirmfoto_Klemmleiste_elmt.png 3.57 kb, 16 downloads since 2024-09-28
macOS Apple silicon arm64 binary
dxf2elmt.zip 1.06 mb, 19 downloads since 2024-09-28
QElectroTech → Import DXF → New .dxf to .elmt Conversion Program
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.032 seconds (43% PHP - 57% DB) with 11 queries