Search options (Page 2 of 17)

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 ...

From an electrician's point of view, this is not permitted for safety reasons!
If the 25 mm² cable is appropriately fused and you have a short circuit on the 1.5 mm² cable, the 1.5 mm² cable will burn away!

And:
One terminal = one voltage = one color = one wire-gauge

From thin wire to thick wire may (!) be permitted, but will lead to misunderstandings!

Salut Laurent !

Thank you for the quick reaction! 

I guess it should be enough to have a w64-version on QET-Website:
QET is only available for w64 so there is no need for w32, when it is called by QET.

The w32-Build is mainly meant for educational- and standalone-use.
... and for promotion of the great project "ReactOS" (no, I'm not involved there)

I guess it should work.
But as always with free software:
No guarantee! 

EDIT:

Can you compile and run QET_ElementScaler on your macOS-Systems from commandline?
Then it should also work in combination with QET.

Best regards
  plc-user

Diese Variablen sind für zusammengesetzten Text verfügbar.
Da ist ja einiges Schönes dabei... 

Solange die Funktion nicht in QET vorhanden ist, ...
Und: Ein bisschen rechnen wirst Du können, damit Du nicht auf den "Zufall" angewiesen bist:

Zoomfaktor = (gewünschte Größe) / (aktuelle Größe)

und dann ist der Aufruf des QET_ElementScaler ziemlich einfach:

QET_ElementScaler -F <Zoomfaktor> -f UrprungsElement.elmt

Wobei:
<Zoomfaktor> durch ermittelten Wert (s.o.) ohne Klammern ersetzen

Und wenn für X- und Y-Richtung verschiedene Faktoren nötig sind, ist das auch kein Problem:

QET_ElementScaler -x <FaktorFürX> -y <FaktorFürY> -f UrprungsElement.elmt

Ergänzend zu den Ausführungen von acolomb:
Ich habe es selbst bei kommerzieller CAD-Software erlebt, daß Konstrukteure die für Ihre Firma typischen Symbole und Schaltzeichen selber erstellen, weil die vorhandenen einen anderen Stil verfolgt haben...!