Search options (Page 14 of 29)

O.k. ... that makes it clear what you mean.

In future versions of QET, such splices will have to be built in to make clear, in which way the cabling has to be done. However, this must be an automatic feature in the software when you make your connections between the terminals.
With the “Splice” or “ThruSomething” elements, you insert non-existent parts into your circuit diagram, which appear as empty lines in the bill of materials.

These “elements” also make my life quite difficult:
For some time now (not full time!) I am trying to develop a software-tool that automatically extracts a cabling plan from the QET schematic file. However, these “elements” are not allowed to appear in a cabling plan because they are not real components!
Not only these parts make it quite difficult to create such a diagram automatically - also the many possibilities to use references in circuit diagrams is quite complex...
But that's another topic!

As I see the "imported elements" - collection:

It is not made to sort or edit the elements you use.
The "imported elements" - collection can be used to choose elements you already use in your project on other folios, without needing to search them in QET- or user-collection again.

see also this thread: https://qelectrotech.org/forum/viewtopic.php?id=2119

If you edit an element in you company- or user-collection, QET will ask, if you want to replace any occurrence in your project, when you pull it onto a folio.

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.

First of all: Use Forum-search!

With the words/phrases "color", "colour" and "to all conductors" I found these threads that should help with your problem:
https://qelectrotech.org/forum/viewtopi … 710#p19710
https://qelectrotech.org/forum/viewtopi … 263#p20263
https://qelectrotech.org/forum/viewtopi … 350#p20350

What do you mean with "can't use it"?

An element with the name 942315m is in the user-collection.
So just pull it onto the schematic!

Can you open the element in Element-Editor by double-clicking?
Then save it before trying to use it in Circuit-Editor.

Maybe the use of dxf2elmt results in a better element?
Give it a try...

Hello wilko67,

create a splice element that is NOT defined as a terminal, then you can use any conductor or colour.
To do this, drag the existing element from the QET collection into the user collection and double-click on it. The element editor opens and you set the desired properties for the element there.

You and the users of the circuit diagram should be aware that this has nothing to do with rule-compliant electrical engineering.

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!

Maybe just look at this post:
https://qelectrotech.org/forum/viewtopi … 299#p20299

The compiler shows no warnings or errors and the result works for my example-files.

In a deep subdirectory, from the compiled result I find the file "entities.rs" with (among other things) this content:

impl LwPolyline {
    pub fn get_is_closed(&self) -> bool {
        self.flags & 1 != 0
    }
    pub fn set_is_closed(&mut self, val: bool) {
        if val {
            self.flags |= 1;
        }
        else {
            self.flags &= !1;
        }
    }
    pub fn get_is_pline_gen(&self) -> bool {
        self.flags & 128 != 0
    }
    pub fn set_is_pline_gen(&mut self, val: bool) {
        if val {
            self.flags |= 128;
        }
        else {
            self.flags &= !128;
        }
    }
}

So the information, if a polyline is closed or not, is already available in the code ... somewhere.
But with NO knowledge of rust and the internals of dxf2elmt it's hard for me ... 

about "closed=true" or "closed=false"

when I look at the dxf-documentation there is a flag with POLYLINEs and LWPOLYLINEs that declares closed or not with groupcode 70:
https://help.autodesk.com/view/OARX/202 … F04D757A50
(sorry, it's German language)

in the dxf-file "Arrows.dxf" (see previous post) from line 2682 I find this:

AcDbPolyline
 90
    5
 70
    1
 43
0
 10
143.090474
 20
250.418834

and similar from line 2724 for the other lwpolyline.

When I change the entries "70  1"  to "70   0" the polygons are shown open in LibreCAD.
I therefore think that it should be possible to be implemented in dxf2elmt... 

Salut Laurent !

try this:

git clone https://github.com/Vadoola/dxf2elmt.git  dxf2elmt_vadoola
cd dxf2elmt_vadoola
rustup update
RUSTFLAGS='-C strip=symbols' cargo build --release

That results in a 2.4MB executable.
But it does not solve the Problem of not outputting to stdout...

The commandline-parameter "-v" that is used in QET-GUI does not produce anything: No elmt and no output to stdout.

EDIT:
What bothers me more about dxf2elmt:
The default behavior for polygons of dxf2elmt seems to be "closed=false", but for QET the default behavior is "closed=true". (see attachments)
Isn't it defined in the dxf or in the dxf-library if a polygon is closed or not?
If there are only a few polygons, this can be fixed quickly, but for complex elements ...