Clone
1
edz_import
ispyisail edited this page 2026-09-12 06:53:01 +12:00

Importing EPLAN parts (.edz)

QET can import a part from the EPLAN Data Portal — the de-facto parts catalogue for electrical CAD (ifm, Phoenix Contact, Siemens, Rittal, Weidmüller, Schneider and others) — directly into an elements collection. Portal parts ship as .edz files; this feature reads the factual data out of one and generates a QET element from it.

This is not a symbol import. The result is a working, correctly labelled element with the right terminals — not a copy of the manufacturer's EPLAN symbol. See §3.

Source: sources/import/edz/ — the module carries its own developer README, which this page is based on.


1. Using it

Right-click a writable collection folder in the elements panel → Import an EPLAN part (.edz)… → choose the file. The generated element is written into that folder and the panel reloads.

Only 7-Zip-format .edz files are supported today. Some EPLAN exports use zip format instead (PK\x03\x04 rather than the 7z magic number); QET detects this and reports it rather than failing silently, but cannot import it yet.


2. What is imported

A .edz is an archive containing a part definition (part.xml), an EPLAN macro (.ema), a product image and metadata. QET reads only the portable part data — the facts, not EPLAN's own symbol geometry:

From the .edz Becomes
Each <functiontemplate> with a physical connection a QET terminal
Pin designation (e.g. 1, PE) the terminal's label
Manufacturer manufacturer element-information field
Order number manufacturer_reference
Description (DESCR1) designation
Comment (DESCR2) comment
<name lang="xx">, one per language the part provides a localized element name, so it appears in whatever language QET's UI is running in

Those four information fields are exactly the ones the BOM/nomenclature already reads — see The project database — so an imported part appears correctly in a parts list with no further setup.

Pins are grouped and sorted by their functional block, then by designation within it: power/terminal connections carrying a terminalNr are grouped by that; others fall back to their functiondefinition.


3. The symbol is generic, on purpose

The importer draws a plain body rectangle with one west-facing terminal per pin — it does not reproduce the EPLAN macro's geometry. The .ema macro is tokenised EPLAN PXF that references EPLAN's own symbol libraries; there is nothing portable in it to draw from.

The generic symbol is enough to wire the part correctly and get it into a BOM immediately. If you want a nicer-looking symbol, open the imported element in the element editor afterward and redraw the graphics — the terminals, labels and information are already correct and do not need to be touched.


4. A note on where the data comes from

.edz files are downloaded from the EPLAN Data Portal (data.eplan.com), operated by EPLAN Software & Service GmbH & Co. KG. The Data Portal's own Terms of Use restrict use of downloaded data to EPLAN products.

QET does not endorse or encourage violating those terms. Whether using a given .edz outside EPLAN products is permitted depends on your agreement with EPLAN and the part's manufacturer — QET has no part in that agreement and cannot answer it for you. If in doubt, ask EPLAN or the manufacturer directly.

What QET's reader itself does: it parses only the portable, factual part data — pin designations, order numbers, manufacturer names — and does not reproduce any EPLAN-proprietary geometry or symbol data. That is a description of what the code does, not legal advice about your specific situation.


5. How it fits together

File Role
edzarchive.* extracts the .edz to a temp directory, locates part.xml
edzsevenzip.* 7-Zip extraction via a bundled, decode-only LZMA SDK — no external 7-Zip install needed
edzpart.* parses part.xml into the portable model in the table above
edzelementbuilder.* builds the .elmt from that model
edzimporter.* orchestrates the above and writes into the chosen collection folder

The non-UI classes are deliberately decoupled from the widget, so the whole pipeline is testable headless — docker compose run --rm qet-edz-fuzz fuzzes EdzImporter::importToDirectory() directly against a corpus of malformed .edz files under AddressSanitizer/UBSan.


See also: Linking elements · The project database