dwg2qet: DWG/DXF → ready-to-wire QElectroTech elements (terminals on the grid, BOM data, cabinet front views, batch libraries)

[DP5000]

Hi all,

I made a small open-source converter, dwg2qet (MIT, Python 3.9+, standard library only): https://github.com/DP5000/dwg2qet

It complements dxf2elmt. Besides the geometry, it writes elements you can wire straight away and use in a bill of materials:

• reads DXF, and DWG through LibreDWG's dwg2dxf;
• finds the terminals (free leads on the outline, plus labelled leads inside the drawing such as A1/A2 coils) and names them from the drawing's own labels (1, 2, 13, 14, L, N …). Unnamed ones are numbered and repeated names get a prime, so --check-elements passes;
• scales and snaps the terminals to the 10 px grid and adds %{label} / %{comment} fields;
• writes elementInformations (manufacturer, manufacturer_reference, designation, current_rating …) and width / height / depth in mm;
• thumbnail mode: cabinet front view at a fixed px per mm (default 2);
• batch mode: CSV manifest → categorised collection with translated folder names, SVG preview of each element, optional --check-elements.

I tested it on a manufacturer CAD library (AutoCAD blocks, not redistributed): 433 single-line and 492 multi-line symbols plus 3,582 front views gave 16,959 article elements. qelectrotech --check-elements reports 0 failures (0.200.1 r10833, macOS). Contactors (A1/A2 coil, main and auxiliary contacts), RCDs and breakers come out with the right terminal names.

It works well with qet-mcp: an assistant searches the converted collection and places and wires the elements with qet_edit. Thanks @ispyisail for the quick fix in #1451.

Two questions:

1. Would this be useful as an import route next to dxf2elmt (e.g. "Import DWG/DXF as a symbol with terminals" in the element editor), or as a qet-mcp tool?
2. Is there a preferred px-per-mm convention for mounting-plate thumbnails? The shipped Legrand ones are about 2.25 px/mm; I used 2.

Feedback welcome.
David (electrical contractor, Slovenia)

[scorpio810]

Hi David,

wow, you are welcome!
You could share some examples of your symbols?

[DP5000]

Thanks Laurent! Here are some examples.

Symbols I drew for our PV single-line diagrams: a hybrid inverter with GRID / BACK-UP / BAT / BMS terminals, PV generator, battery with BMS, kWh meter, grid supply and EV charger. There are also horizontal IEC 60617 fuse, breaker, switch-disconnector, RCD, terminal and feeder arrow, plus a T junction of terminal type, so that both branches share one potential.

A single-line PV + battery diagram an assistant drew with them through qet-mcp (layout check 100/100):

The .elmt files are in https://github.com/DP5000/dwg2qet/tree/main/examples/solion-symbols. The horizontal IEC ones are derived from the QElectroTech collection (CC-BY 3.0). I can't share the converted manufacturer library, since that's the vendor's CAD data. The converter works on any DWG/DXF symbol library you have the right to use.

If they're useful for the official collection, I'm happy to open a pull request on qelectrotech-elements.

[scorpio810]

Thanks David,

I want to see more complex element like see SEW MOVIDRIVE, or MOVITRAC by example?
Or other manufacturer if you want.

[DP5000]

Hi Laurent,

It's done, you can have a look. Here is SEW from start to finish. Nothing is drawn by hand.

MOVIDRIVE B MDX61B0015-5A3-4-00: 51 terminals in 10 blocks (X1, X2, X3, X4, X10, X11, X12, X13, X16, X17)

MOVITRAC B MC07B0015-5A3-4-00: 31 terminals, wired with QElectroTech's own breaker, motor and switches

How it is made:

• SEW's CAD data (Online Support > CAD data, no login) has a front view (DXF) and a 3D model (STEP), but no schematic symbol.
• The terminals come from SEW's public manuals: the MOVITRAC B system manual (01/2024) and the MOVIDRIVE B compact operating instructions (11/2017). The assistant copies the terminal table into a small JSON file.
• A new script, terminals2qet, draws the symbol from that table:
  • every terminal on the 10 px grid, named as in the manual (X13:1, designation DI00), with its function next to it;
  • blocks framed like terminal strips;
  • the same terminal uuids each time, so a symbol drawn again keeps the wires of existing projects.
• The same run converts SEW's front view into a cabinet element at 2 px = 1 mm (dwg2qet). It reads width, height and depth from the STEP model: MOVITRAC 80 × 286.8 × 160 mm, MOVIDRIVE 105 × 406.1 × 234 mm. A 3D box model of the cabinet folio follows from these dimensions.
• qelectrotech --check-elements: 0 failures.

The MOVIDRIVE also found a bug. dwg2qet measured arcs as full circles, so its box came out 170 × 470 mm. That is fixed now.

The two JSON tables are in examples/terminals. SEW's CAD files are not in the repository, so download them from SEW.

https://github.com/DP5000/dwg2qet

David

[scorpio810]

Good job, David.

[ispyisail]

Im building stuff and i wonder if anybody is even using it or finding it usefull

Posts like this feed the devoloper

[Vadoola]

Interesting project, there are some things you seem to have added that I've been wanting to add to dxf2elmt, but I just haven't had the time to get around to them.

[scorpio810]

@DP5000 If you could create binaries for Linux, macOS and Windows, we should be able to add a new entry such as ‘dxf2elmt’ in the element editor.

[scorpio810]

Hi David,

I had a closer look at the code (commit 640bca6): it’s clean, readable, standard library only, and the 12 tests pass. Using LibreDWG instead of ODA is a good choice too. A few points I noticed:

Random UUIDs in dwg2qet: the element and its terminals get uuid4() (lines 1078 and 1106), while terminals2qet already uses deterministic uuid5. When a collection is regenerated, every UUID changes, which is a problem for elements already used in projects. This is the most important point; could dwg2qet use uuid5 too, built from the source file/block name and the terminal name?
read_pairs() uses splitlines(), which also splits on \x0b, \x1c, \u2028, etc. A DXF text containing one of these characters shifts every following code/value pair. Splitting on \n only would be safer.
ARC inside a block with non-uniform scale (sx ≠ sy): the radius is multiplied by a single scale factor, but the arc should become an elliptical arc.
Frozen/off layer of the INSERT itself: only the layers of the block’s entities are checked, not the layer of the INSERT.
POLYLINE mesh/polyface (flags 16/64): drawn as a regular polyline.
Binary DXF: not supported. It’s rare, but a clear error message would help.
version="0.100.0" in the generated .elmt files: could be bumped to 0.200.

Nothing blocking apart from point 1, which I’d like fixed before integrating it.

About your question on integration: QElectroTech already ships Python for qet-mcp (misc/qet-mcp, and a bundled Python in the Windows installer). Since dwg2qet only needs the standard library and already has -v mimicking dxf2elmt, we could ship it next to qet_mcp.py (as a git submodule), call it from the element editor’s DXF import with a fallback to dxf2elmt, and expose it as an MCP tool as well. What do you think?

Thanks again for this work!

Laurent

[DP5000]

Hi Laurent, thank you for the careful review!

All seven points are fixed in c648309:

1. Deterministic uuid5 for the element, its terminals and its text fields, built from the drawing's file name (not the folder), the mode and the layer filters (in a batch also the row's output path); terminals add their name and occurrence. A regenerated collection keeps its uuids. --ident (or an ident column in the batch manifest) keeps them when a drawing is renamed. terminals2qet's text fields are now deterministic as well.
2. read_pairs() splits on \n only. The new test also showed that a \x0b inside a TEXT ended up in the .elmt and made it invalid XML, so C0 control characters are now removed from texts.
3. CIRCLE/ARC inside a block inserted with sx ≠ sy (or sheared) becomes an ellipse / elliptical arc; uniform scale keeps the circle.
4. A frozen layer of the INSERT itself hides the whole block reference (an off layer still hides only what is drawn on layer 0 inside it).
5. POLYLINE polyface mesh (flag 64) draws its visible face edges, polygon mesh (flag 16) its M × N grid.
6. Binary DXF gives a clear error message and exit code 2.
7. <definition version="0.200">.

9 new tests, 21 in total, all passing. 30 elements converted from manufacturer drawings (Schrack, SEW, Victron) are identical to before apart from the uuids and the version. Version is now 0.2.0.

Yes, I'd be glad to have it shipped next to qet_mcp.py as a submodule, with a fallback to dxf2elmt in the element editor and as an MCP tool. Thanks also to @Vadoola, happy to share anything useful for dxf2elmt.

David

[Vadoola]

Thanks also to @Vadoola, happy to share anything useful for dxf2elmt.

Appreciate it. I really need to find time to finish up the work in my spline_improvements branch and cut another release. Then I probably need to sit down and organize what I'm going to work on next