Search options (Page 1 of 2)

Hello Laurent,

Strange, that looks like debugging info I had in there while I was testing, but I just checked the last commit (fb09197) and I had removed it before committing.

Are you sure you grabbed the latest commit?

The other possibility is I screwed something up, the last time I worked on a (non-plc) project as a team was in C++ but probably 12+ years ago now and we were using SVN. All my experience with Git is as a solo developer, and I have a tendency to just work off the main branch. I know it's not best habits and have been trying to learn better git technique, so I was working on these features in a different branch and then merged them. Perhaps I didn't merge them correctly, and you aren't seeing the latest code?

Nice find, I've been wanting to find a bunch of files I could test against.

It looks like the function was renamed at some point from get_is_closed to just is_closed, the source between the 2 is identica.

0.5.0

pub fn get_is_closed(&self) -> bool {
        self.flags & 1 != 0
    }

Master

pub fn is_closed(&self) -> bool {
        self.flags & 1 != 0
    }

I haven't tested it properly, but just replacing all the .get_is_closed() function calls with .is_closed() makes it compile for me

Hello Laurent and plc-user,

I'll add it to the list. It looks like the dxf has a text height property, I'm assuming it would be in the same units are the rest of the dxf, ie it's a height in mm, or inches, etc. I would have to convert that into a font size. It looks like I already need to figure out how to do some font processing. One of the forums posts mentioned text not being in the correct spot. I figure out why and documented it in the Issue https://github.com/Vadoola/dxf2elmt/issues/7. Essentially if the horizontal and vertical alignment on the text are not the default (top left), then you need to calculate the location based on a different set of coordinates, and the font rendering. As part of trying to add that in, I can also try to figure out converting the text size in the dxf into a proper font size.

Ich bin auch ziemlich verwirrt, aber das liegt vielleicht daran, dass mein Deutsch zwar viel besser ist als mein Französisch, aber nicht gut genug, um dies zu verstehen oder zu schreiben, ohne Google Translate zu verwenden.

plc-user, können Sie weitere Informationen dazu bereitstellen, was Sie hier meinen, damit ich versuchen kann, der Sache nachzugehen? Oder ist das etwas, das Sie schon einmal erwähnt haben und das ich bereits in den GitHub-Problemen dokumentiert habe?

Hoffentlich ist diese übersetzte Nachricht verständlich.

Hello Laurent,

One hour is a long time for a user to be waiting for a result, and there should be no need for that. I'm not sure how reasonable it is to assume a user will just look at the log file after a few minutes though either.

One thing on the list is to add some better logging / error handling into dxf2elemt. Right now on most errors it just panics and unwinds the stack printing an error to stderr.

If the program were to return an error code, ie  0 on success any anything else is an error, I assume you could capture that in QET? That way if dxf2elemt fails as it did with the above code pair issue, QET could capture that failure and pop up an alert or something saying "Conversion failed, see log for further information"

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.

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.

Good catch, I'll get that corrected.

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.

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.

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.

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.

Completely agree, I can change the default behavior to round to 2 decimals of precision.

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.