Proposal: a roadmap to make IEC-standard drawings the easy path in QElectroTech

[ispyisail]

Hi all,

Should QElectroTech work towards drawing to the IEC standards by default (IEC 81346 tags, IEC 60617 symbols, IEC 61082 diagram rules), without changing how existing projects open or look?

Below is a short review of where QElectroTech stands today, and a suggested build order. Nothing is built. Before anyone writes code, I'd like to know whether this is the direction you want.

Where QElectroTech stands today

✅ works · ◐ partly / by hand · ✗ missing

Area	Standard	Today
Cross-references, contact tables	IEC 61082-1	✅
Grid zones (columns/rows) on the sheet	IEC 61082-1	✅
Device tags (=plant +location -K1)	IEC 81346-1	◐ plant and location exist; the tag itself is one free-text field, no levels like -A1-K1
Letter codes (K, QA, XD …)	IEC 81346-2	◐ one letter per symbol folder (qet_labels.xml); the standard allows up to three, per symbol
Terminal names (-K1:A1)	IEC 61666 / 60445	◐ the field exists, but 79 % of terminals in the shipped symbols have no name
Wire colours	IEC 60445 / 60757	◐ free text; no BK/GNYE codes; green-yellow is missing from the colour button
Cables and cores	IEC 62491	✗ a cable is just text on the wire
Signal names across sheets	IEC 61175	✗
Paper sizes in mm (A3, A4 …)	ISO 5457	◐ a sheet is "columns × width", not a paper size
Title block fields	ISO 7200	◐ possible with custom variables, not standard
Revision history	ISO 7200	✗ one revision field only
Document type (circuit diagram, terminal diagram …)	IEC 61355	✗
Line widths, text sizes	ISO 128 / 3098	◐ "thin / normal" with no mm values
IEC symbol set	IEC 60617	◐ 937 symbols in 91_en_60617, not tagged as IEC; rest of the library is mixed
"Check my drawing"	—	✗

Keeping old projects safe

Every step would follow these rules:

• A drawing-standard setting per project: As before / IEC / NFPA. Existing projects open as As before and look exactly as they do today.
• Add, never reinterpret. New fields go next to the old ones. An existing field never changes meaning.
• Opening a file never changes it.
• Converting to IEC is a menu command that shows what it will change first, and can be undone.
• Free text stays as the fallback. Old colours or cable names that don't match a code still show and can still be edited.
• Older QElectroTech versions: a project saved by a newer version and then re-saved by an older one may lose the new data. The first step is to check this and warn before saving.
• Projects keep their own copy of each symbol, so fixing symbols in the library never changes an existing project.

Suggested order

Tags come first because cables, wire markers, cross-references and the checker all print a tag.

#	Step	You get	Needs
0	Foundations	The per-project standard setting, test projects, the older-version check. Nothing visible yet	—
1	Device tag structure	=function +location -product with levels, inherited from project → sheet → device	0
2	Letter codes	Up to three letters per symbol, with the 2009 or 2019 letter table chosen per project	1
3	Terminal names	Full -K1:A1 in cross-references and wiring lists; names filled in the library	1
4	Wire colours	IEC colour codes, green-yellow, defaults per standard (e.g. IEC 60204-1 machine colours)	0
5	Cables and cores	Cable as a device with cores (already scoped in #934 / #951)	1, 4
6	Wire markers and signals	Markers showing the far end; signal names across sheets	3
7	Documents	A0–A4 sheets, ISO 7200 title block, document type, revision table	0
8	Symbol library	IEC tag per symbol and a filter; gaps filled; terminal names, line widths	0, in parallel
9	Check drawing	A report per standard: duplicate tags, unnamed terminals, PE not green-yellow …	all above

Step 4 (wire colours) is small and independent, so it could be the first thing users see.

Work that isn't program code

• The symbol library is most of the work. That's 8,838 symbols in the elements repository, and code without symbol data changes nothing users see.
• Users' own symbols won't have the new data. Every feature has to fall back to today's behaviour for them.
• Mixed projects: a project started with old letter codes and extended with new ones has to keep working.
• Exports (PDF, DXF, wiring list, parts list) need to carry the new tags and codes.
• Translations: IEC terms have official translations (IEC 60050 / Electropedia). We should use those.
• Scripting and the AI assistant connection need the new fields too, or generated drawings won't follow the standard.
• Documentation: a wiki page per step, and a short guide on drawing to IEC in QElectroTech.

Not planned

• No certification. No body certifies drawing software as "IEC compliant"; the aim is that the default way of drawing produces IEC-compliant output.
• NFPA / US drawings and national practice stay fully supported — that is why the setting is per project.
• No electrical calculations (cable sizing, voltage drop).

Questions

1. Is this the direction we want for QElectroTech?
2. Is the order right? What would you move?
3. A per-project standard setting: OK, or is there a better way?
4. Which 81346-2 letter table should IEC projects use by default: the older one the library uses today (L, V, Y), or the 2019 one?
5. Who has access to the standards texts? (They are paid; rules should be written from the text, not from memory.)

Earlier discussions this would pull together: #613, #649, #666 (and PR #897).

[ispyisail]

Do we even want to be IEC compliant?

[scorpio810]

Thanks Shane, this is a well-structured proposal, and I like the safety rules (per-project setting, add never reinterpret, opening a file never changes it).

Direction: yes in principle, but with a timing constraint. Please don't start any code on this before 0.200.2 is out. Steps 0 to 3 change the data model, and I don't want that landing next to the first Qt6 stable release. Once 0.200.2 is tagged, step 0 (the per-project standard setting and the older-version warning on save) is the right place to start, for 0.200.3.

Order: step 4 (wire colours, including the missing green-yellow) is small and visible, so it could go earlier if it does not change the file format. Otherwise it follows the same rule as the others.

What I'd commit to for now: steps 0 to 4 only. Steps 5 to 9 (cables, signals across sheets, ISO 7200, check drawing) are each a large piece of work, so let's leave them open and decide after the first steps are merged and used.

Points I'd like to see settled:

1. PR Per-element IEC 81346 designation letter + revive live placeholder #897 (IEC 81346 designation letter) is already waiting for a decision for 0.200.2. Let's settle it first, so we don't end up with two tag models side by side.
2. Standards and copyright. The texts are paid and IEC also protects the 60617 symbol database. I agree rules must be written from the text, not from memory. For the "check drawing" step, I'd want rules expressed generically, without copying standard text, and we should be careful about calling our symbols "IEC 60617" until we know where the current 937 come from.
3. The symbol library is most of the work (8,838 symbols). Without data in the symbols the code changes nothing for users, so we need to know who is willing to do that part before promising it.
4. 81346-2 letter table: keep the one the library uses today as the default (compatibility), and offer the 2019 table as an option per project.
5. Fallback: users' own symbols and mixed projects must keep working exactly as today.

Process: one step per PR, each with tests and a before/after comparison, and please no stacked PRs for this. A project saved by the new version, re-saved by an older one, must be checked and warned about before the first data-model step is merged.

Others, please say what you think, especially about which letter table and who can access the standards texts.

[scorpio810]

One more thing, to be transparent about where I stand.

This standard mainly concerns users and developers in Germany and Eastern European countries, who have used it for a long time. I don't apply IEC 81346 in my own projects yet, so I'm not well placed to steer the details (tag structure, letter tables, terminal naming, what is "normal" practice). I can judge the impact on the codebase, the file format and the release process, but not whether a rule is right for people who draw this way every day.

So I'd really like input from those who do:

• Users and contributors who already draw to IEC 81346 / 61082 / 60445: does the table at the top match your daily practice? What is missing or wrong?
• Which letter table (older or 2019) do your projects actually use?
• Who has access to the standards texts, so rules can be checked against the real text?

Shane, please treat this discussion as the place to collect that feedback, and don't take my earlier replies as a decision on the technical details. My earlier points are about timing and risk to existing projects, not about what the standard says.

[itseogo]

Hi,
regarding compliance with standards, I have access to DIN EN 61082-1 (VDE 0040-1).
Many questions regarding terminal diagrams, connection designations, etc. are covered in 61082.
Here is my feedback on the steps from the perspective of control cabinet and mechanical engineering:

Regarding Step 1 (device tag structure): Working with =Function, +Location and -Product accurately reflects everyday industrial practice. This clearly distinguishes between what is located inside the control cabinet (+Location1) and what is outside it or on the machine. In mechanical engineering, the ‘+’ is also frequently assigned to cycle steps or machine components. Inheritance & Presentation: It is important that components in the drawing do not have to carry the full string as text every time. It is standard practice to define ‘=Function’ and ‘+Location’ at the bottom of the standard sheet / title block as the default for the respective page. If a component is located in a different position on a page, it is usually enclosed in a structure box / location box that specifies the alternative location. The structure should remain flexible and adaptable by the user.

Regarding Step 2 (letter codes / IEC 81346-2): In my day-to-day work, I primarily use IEC 81346-2 (e.g. the 2011 edition). Depending on company or customer standards, either a single letter (e.g. F for fuse) or two or three letters (e.g. FC for overcurrent protection) are used. It is therefore essential to be able to freely select or switch between letter tables on a project-by-project basis.

Regarding Step 3 (Terminal names / connection points): In the terminal diagram or terminal block layout, the exact connection points for the source and destination are typically listed alongside the terminal number (e.g. -K1:A1). This greatly improves clarity during wiring.

Regarding Step 4 (wire colours): The use of international/English colour codes (e.g. BK, BU, GNYE in accordance with IEC 60204-1) is standard practice in industry and highly recommended. Leading ECAD systems such as EPLAN also use these IEC colour codes by default.

Regarding Step 5 (cables and conductors): It is essential to treat cables as independent components with assigned individual conductors. This is the only way to generate clean, automated cable diagrams and cable lists for production and assembly.

Regarding Step 6 (wire markings and signals): Clarification/understanding: Does this refer to layer references (break points) or to potential?

Regarding Step 7 (Documents & Formats): In practice, drawings and designs are almost always produced on DIN A3, but the documentation is then usually scaled down to DIN A4 for use on site. Standard-compliant ISO 7200 text fields and structured cover/revision sheets provide a solid basis for this.

Regarding Step 8 (Symbol library): IEC labelling and maintenance of the libraries is highly recommended. Very useful in practice: support for multiple parallel symbol libraries and – ideally – a function for converting symbols to comply with different standards (e.g. when an existing IEC circuit diagram needs to be converted to NFPA/UL symbols for the North American market) .

Regarding Step 9 (Drawing check / validation run): An automatic check is extremely valuable, but must be fully configurable on a modular basis (check profiles/schemes). Not every check step is relevant for every project or every industry. In professional software, major clients (such as the automotive industry) often provide their own test run templates, whilst for smaller control systems, the aim is simply to catch basic errors (duplicate component codes, open connections, incorrect PE colour).

[ispyisail]

It seams we keep everybody happy with all options....If possiable

[Kellermorph]

Hi, everyone,
I'm currently working on a cable manager. I wanted to set it up so that the cables—including wire colors, number of wires, etc.—are defined in a CSV file. It's similar to the principle of a bill of materials.
This way, anyone could customize it however they want. Then you could create the definitions yourself according to IEC standards. That should work well, right? This would close Point 5.

[arummler]

We had already one created by @ispyisail which got postponed as the architectural decision regarding wires/conductors was deemed needed first. That was edited in QElectrotech and saved in a SQL db. Personally, I also tried to have some GenAI generated including more complex cables (nested, etc. see that discussion), looked quite good.

[arummler]

How does your approach look like? Does it allow multiple shields, twisted pairs, etc.?

[Kellermorph]

Hi.
I'd say I'm about 50% done.
Here’s how it works:
You define the cables in a CSV file
description, number of conductors, and conductor colors
Now, QET has a button—similar to the one in WSCAD—that lets you draw a line. The program automatically counts the intersecting lines. When you left-click again, the GUI appears so you can select the cable. Cables with fewer defined conductors than the number of intersecting lines will be crossed out during selection and cannot be chosen. Then, once you’ve selected the cable, the “Conductor” field is populated with the cable’s name according to the “Cable Name:Wire Color” format. This is extremely important later on for a terminal diagram. Likewise, the wire color—which was previously defined in the CSV file—is then displayed next to each conductor. These can also be moved later.
So far, this works fine.
In the GUI, there’s a second tab for assigned cables. If you haven’t used all the wires, you can draw a new cable and assign it to the existing cable in case the cable spans multiple pages. That works fine, too.
Copy and paste to enter the cable name and wire color—that works fine, too. Likewise, when you move the cable, the entries are deleted and re-entered into the new lines.
So, for example, if you have a CAT7 cable, you can define all 8 wires and they will be displayed. I would implement cable shielding in a second step.

[ispyisail]

Looks good. Three questions:

1. Which field gets Cable:Colour? If it is the wire label, QET copies the label to every wire on the same potential, so a core name spreads through terminals, and it replaces the wire number. The wire's existing cable and colour fields avoid both.
2. Where are the assigned cables saved? If only in the CSV, a project opened on another PC loses them.
3. Could the colours use IEC 60757 codes (BN, BU, GNYE)?

[Kellermorph]

1. Yes, the data is written to the cable panel’s wire, but it is prevented from being passed on to the next wire, even at terminals.
2. The cables are stored in the XML file. The CSV file serves only as a template for creation. This is how the data is written.
   Example:

wh bn bl gn ye

3. The colors are up to the user. They can enter whatever they want into the CSV file. For example, “br” in German for brown or “bn” for the English designation.

[Kellermorph]

1. Yes, the data is written to the cable panel’s wire, but it is prevented from being passed on to the next wire, even at terminals.
2. The cables are stored in the XML file. The CSV file serves only as a template for creation. This is how the data is written.
   Example:

<cable designation="1W1" type="H07V-K 5G1,5" uuid="{5a808172-9172-4d8d-8c64-a5f7955b5997}" cores="5">
    <colors>
        <color>wh</color>
        <color>bn</color>
        <color>bl</color>
        <color>gn</color>
        <color>ye</color>
    </colors>
    <part x1="500.00" y2="220.00" diagram="{4332086f-abb8-4548-9437-a263d90d62ca}" uuid="{bcc2e3d5-a1d3-410c-ae72-5c1958bc3925}" y1="220.00" x2="620.00"/>
    <core part="{bcc2e3d5-a1d3-410c-ae72-5c1958bc3925}" y="220.00" index="0" conductor="{050a8b80-8f1e-4723-8a26-601283826ae7}" x="510.00"/>
    <core part="{bcc2e3d5-a1d3-410c-ae72-5c1958bc3925}" y="220.00" index="1" conductor="{b65fea6b-d2ba-4a96-a77e-12997efbb2ed}" x="530.00"/>
    <core part="{bcc2e3d5-a1d3-410c-ae72-5c1958bc3925}" y="220.00" index="2" conductor="{00476ad7-4ad4-43d7-bd58-1f3f1f5af310}" x="550.00"/>
    <core part="{bcc2e3d5-a1d3-410c-ae72-5c1958bc3925}" y="220.00" index="3" conductor="{2b82d0ff-df81-43f0-8119-b09c306d0357}" x="570.00"/>
    <core part="{bcc2e3d5-a1d3-410c-ae72-5c1958bc3925}" y="220.00" index="4" conductor="{a387946d-8dc2-40b1-9737-93a7d48d2de5}" x="610.00"/>
</cable>

3. The colors are up to the user. They can enter whatever they want into the CSV file. For example, “br” in German for brown or “bn” for the English designation.

[arummler]

As I just wrote in the other thread:
" abstraction conductor / (physical) wire and cable / cable definition (I still believe that at least these three are needed e.g. does a logical conductor have a colour (ideal state) and can the color of the assigned core from the assigned cable type (taken from the cable database) differ? If yes: what is shown? Simple example: a two way switch, at least in Germany afaik you are allowed to mis-use blue for a switched phase even if is not recommended."

Why? If a conductor is a logical object then it might have a recommended colour according to its function and the set standard (which could also be abstracted away to allow you to "switch" at least cable colour standards on the fly, sometimes there are house standard for the lesse common ones). A conductor is realized as a core of one or more physical wires. Those physical wired have a length, etc. And they are realized by being assigned to a really exisiting cable which comes from the cable database. There could be yet another link from the cable database to a vendor / inventory / distributor catalogue. The get also assigned a connector in the end which is a physical object appearing in the BOM. There might also an indirection layer between physical wire (core) and physical cable.

• Even if not doing a (Physical) cable object I would avoid to imprint the cable information directly but saving a directory of used cable types with their properties in the file and reference them by name or UUID. (and in the future in the new file format).
• I would avoid a completely different text file to be hand edited. Both out proposals had a graphical in-built editor.
• Back end (csv, xml, sql) can discussed but I would tend to say that csv is not complex enough to represent what I had sketched.
• What about the other properties field (brand, generic type, jacket colour, jacket material, fire sandard compliance, free defined fields for strange requests like radiation hardness)

[Kellermorph]

Okay, wow, that’s really huge—what you’re planning to do there. I wouldn’t implement all of that in a single pull request. That’s too much.
Let me just finish what I’m working on here. Then I’ll create a pull request. That way, we’ll have a foundation we can use to discuss whether anything should be done differently, etc. I’d view what I’m doing now as a foundation, and then we can gradually build on it—for example, adding information like the jacket color, fire safety standards, etc., later on.
Do you agree with this approach? Right now, we’re mostly talking in theory and don’t have an example to guide us for changes or improvements.

[arummler]

What's your position on breaking data compatibility? If e.g. your cable database cannot be read in anymore in some version as for more complex cables I believe csv is insufficient? Accept that any data has to be manually re-entered, decline the change or try to write a converter if feasible?

[Kellermorph]

How could a CSV file suddenly become unreadable? I’m sorry, I’m not familiar enough with the subject to understand this. The big question is, what kind of data do you want to save that a CSV file can’t handle? Isn’t it all text-based? Forgive my silly questions—I’m not an IT expert.

My personal (layman’s) experience is that we at our company keep running into huge problems with SQL and Access databases. We had these issues with WSCAD, and now we’re seeing them with Eplan as well. When accessing the databases from outside the company, they cause incredibly long load times. WSCAD also regularly crashed pages for us. According to WSCAD support, this is supposedly due to a database access issue, and our hardware is allegedly not designed to handle it. But even now, with completely new hardware, we still have huge problems time and time again.

[arummler]

Can't really comment on your database issues. Sounds a bit fishy regarding the hardware...do they want to sell you a new version? But I take the point that it might be overkill and might introduce unnecessary complexity. To be weighted carefully.

Personally I went with SQL as I built on top what @ispyisail had in #936 (comment)

That's also a link to a comment of mine sketching out what kind of cables (drilled pairs, multiple shields, mixed) one could deal with and how to keep as universal as possible. It is not about csv suddenly stopping to work but if you do not foresee a way how to represent let's say a CAT7 or a triax it likely will require to change the fields (content), basically making a new expected schema which becomes incompatible with the old one. One can naturally try to stay compatible by leaving at least the capability to read the old files and convert them internally into the new data structure or even to keep the old file writer version (optionally) alive. But that needs to be done and should be implemented in tests as potentially one has to check these code paths forever (like e.g. MS office or others can still read file formats from the 90ies afaik; the code responsible for that is likely similarly old as no one wants to touch it).

Admittedly, it might even work with a CSV file to some extent as what I actually have is the structure in form of JSON serialized into a SQL field. I would probably still change that to XML. Regarding the database itself: depends probably a bit on the amount of cables expected maximum in the database. It is probably not strictly necessary and could be done also as a "flat, text based" database.

Just some impressions (all only vibe coded, did not go yet through the code) from the GUI:




(please disregard the usage of a CAT cable for 230V, strictly only for presentation purposes ;) )

There are then our well known conductors:

        <conductor bicolor="false" bus="" cable="CAT-7" cable_run_core_key="0.0.1.0.0" cable_run_id="679e70a9-9af0-46e6-ac75-3456bed472a8" color="#ff8c00" color2="#000000" condsize="1" conductor_color="Orange" conductor_section="0mm<C2><B2>" dash-size="1" displaytext="1" element1="{78d9cb2e-1368-49a0-ab4e-84d35497ebaa}" element1_label="" element1_name="Circuit-breaker" element2="{d0306a94-67cc-45a9-808c-d1055aa67340}" element2_label="" element2_name="Circuit-breaker" formula="CAT-7:0.0.1.0.0  0mm<C2><B2>  Orange" freezeLabel="false" function="" horizontal-alignment="AlignBottom" horizrotatetext="0" num="CAT-7:0.0.1.0.0  0mm<C2><B2>  Orange" numsize="7" onetextperfolio="0" tension_protocol="" terminal1="{d8072852-5298-4e3f-866a-197fbe17dbdb}" terminal2="{778608f0-d679-4627-bdde-a4b0f1f6c541}" terminalname1="OUT.4" terminalname2="IN.3" text_color="#000000" type="multi" uuid="{6cf37cdb-8c51-4deb-8eab-a7c4a9791f89}" vertical-alignment="AlignRight" vertirotatetext="270" x="0" y="0">

but also physical cables

        <cablerun id="679e70a9-9af0-46e6-ac75-3456bed472a8" label="Black_8x0mm<C2><B2>" length_m="0" wire_spec_id="CAT-7">
            <core conductor="{6cf37cdb-8c51-4deb-8eab-a7c4a9791f89}" key="0.0.1.0.0"/>
        </cablerun>

and a copy of the relevant portions of the cable catalogue embedded:

<wirespecs>
    <wire cable_outer_dia_mm="6" color_primary="Black" core_colors="[[]]" core_sections="[0]" cross_section_mm2="0" family_name="" flexible="0" insulation_dia_mm="0.5" manufacturer_name="cheapest bidder" manufacturer_part_no="" notes="" num_cores="1" shield="0" shield_type="" structure_json="[{&quot;children&quot;:[{&quot;children&quot;:[{&quot;children&quot;:[{&quot;children&quot;:[{&quot;colors&quot;:[&quot;Green&quot;],&quot;kind&quot;:&quot;conductor&quot;},{&quot;colors&quot;:[&quot;White&quot;],&quot;kind&quot;:&quot;conductor&quot;}],&quot;kind&quot;:&quot;lay&quot;,&quot;lay_direction&quot;:&quot;S&quot;,&quot;twist_lay_mm&quot;:30}],&quot;kind&quot;:&quot;shield&quot;,&quot;shield_material&quot;:&quot;Feuille&quot;},{&quot;children&quot;:[{&quot;children&quot;:[{&quot;colors&quot;:[&quot;Orange&quot;],&quot;kind&quot;:&quot;conductor&quot;},{&quot;colors&quot;:[&quot;White&quot;],&quot;kind&quot;:&quot;conductor&quot;}],&quot;kind&quot;:&quot;lay&quot;,&quot;lay_direction&quot;:&quot;S&quot;,&quot;twist_lay_mm&quot;:30}],&quot;kind&quot;:&quot;shield&quot;,&quot;shield_material&quot;:&quot;Feuille&quot;},{&quot;children&quot;:[{&quot;children&quot;:[{&quot;colors&quot;:[&quot;Brown&quot;],&quot;kind&quot;:&quot;conductor&quot;},{&quot;colors&quot;:[&quot;White&quot;],&quot;kind&quot;:&quot;conductor&quot;}],&quot;kind&quot;:&quot;lay&quot;,&quot;lay_direction&quot;:&quot;S&quot;,&quot;twist_lay_mm&quot;:30}],&quot;kind&quot;:&quot;shield&quot;,&quot;shield_material&quot;:&quot;Feuille&quot;},{&quot;children&quot;:[{&quot;children&quot;:[{&quot;colors&quot;:[&quot;Blue&quot;],&quot;kind&quot;:&quot;conductor&quot;},{&quot;colors&quot;:[&quot;White&quot;],&quot;kind&quot;:&quot;conductor&quot;}],&quot;kind&quot;:&quot;lay&quot;,&quot;lay_direction&quot;:&quot;S&quot;,&quot;twist_lay_mm&quot;:30}],&quot;kind&quot;:&quot;shield&quot;,&quot;shield_material&quot;:&quot;Feuille&quot;}],&quot;kind&quot;:&quot;lay&quot;,&quot;lay_direction&quot;:&quot;Z&quot;,&quot;twist_lay_mm&quot;:100}],&quot;kind&quot;:&quot;shield&quot;,&quot;shield_material&quot;:&quot;Feuille&quot;}]" supplier_name="" supplier_part_no="" temp_rating_c="0" voltage_rating_v="0" wire_id="CAT-7"/>
</wirespecs>

Just to stress: nothing tested, all to be discussed, naming not satisfactory. That's just a quick prototype.

[Kellermorph]

It’s clear that you don’t have a say in this. I just wanted to explain why I started out using a CSV file. Plus, a CSV file is very easy to edit.

Your GUI and your approach are quite different from what I’ve worked out so far. I did it using a cable line—similar to how it’s done in WSCAD and EPLAN, for example—which detects crossed wires, etc.

Here’s what I suggest:
Let me finish my work. Then I’ll submit a pull request. That way, we’ll have a baseline to discuss whether this is what was intended or not.
Then we might be able to make a change to the CSV. Or this, or that. But this way, we’ll at least have a foundation to build on.

[scorpio810]

Maybe an SQlite database?

[saschbe]

Hello,

I would like to actively participate in this roadmap and help improve Belgian RGIE / AREI support in QElectroTech.
In Belgium, the RGIE is the main electrical regulation. It can be supported independently from IEC 60617, even if some symbols may overlap.

I have already started a small lab branch to test symbol classification by standard, country and usage, without duplicating .elmt files.

My idea is to gradually add a Belgium / RGIE profile with support for single-line diagrams, position plans, protections, earthing, circuits, and other RGIE-related rules.

I would prefer to move step by step, with tests and backward compatibility, and keep the work experimental until the architecture is agreed.

I would be happy to contribute to this work with you.

[scorpio810]

@saschbe you are welcome.
For me RGIE https://download.qelectrotech.org/qet/elements_contrib/71_rgie/index.html

[saschbe]

@scorpio810 Thanks, I see it.
This is useful as an existing RGIE symbol collection, especially for position plans and single-line diagrams.
My idea is a bit broader.
I would like to gradually integrate RGIE as a real Belgian project profile in QElectroTech, with project settings, classification and later RGIE-specific checks and rules.
I would also like to improve the RGIE symbol library itself, with a cleaner and more complete collection, better classification and metadata, and without unnecessary duplication of symbols.
The existing 71_rgie collection could be used as a starting point, but I would like to go further than the current symbol library.

[arummler]

This discussion is still at the point of what "selecting a standard" requires from the program and what capabilities are missing to do that. (It is mixed with some other very fundamental design discussions). In the beginning there was as an attempt to summarize a bit all kind of formal aspects demanded by IEC...

Could you do something like that for RGIE? What is demanded / recommended? E.g. specific sheets / project structure, line sizes, certainly certain symbols as you mentioned, naming conventions devices and cables, what kind of design rules for a DRC (which does not exist yet) etc. Just to know what a function "create REGIE standard project" would need to take care of in general. Very coarse.

[scorpio810]

https://download.qelectrotech.org/qet/elements/10_electric/91_en_60617/index.html

[ispyisail]

I've had a battle with data storage Sheet JSON vs SQL

https://github.com/qelectrotech/qelectrotech-source-mirror/wiki/project_database

I would like to full move to SQL but getting out of sync could be a problem

As I undersatnd it at the moment Sheet JSON is the master and SQL is updated on file load (and lost on close)

I dont like the the CSV idea it that is what is being proposed

[arummler]

You mean the QETs native file format and XML (not JSON), right? I would be careful not to mix up these two discussions. They are imho not really related as long as you do not want to save everything in the same place.

Main purpose of the idea to go long term (either as a replacement or additionally) to a compressed file is to avoid the base64 encoding/decoding. Imitating what e.g. the big office suites do: one or more XML files plus binary files in a zip.

The SQL currently used with QET is used as an index for retrieval only and rebuild from the master XML. If you move to SQL is the master and the GUI only a view of the database if becomes authorative. In the moment we are trying to stay backward compatible mostly by adding fields to the XML which can be disregarded. As you write in §5 and 7 implicitly: if the SQL becomes master you need to take care of database stability versioning and other things.

To a certain extent you also loose some features if you stuff a sql into an archive although it is doable. Also one should consider what it means for using git on project files (solvable with a plugin for diffing; also an issue for archives so no big difference.

There are linked a "vision" and "roadmap" which I only glanced at as I saw them for the first time. Both probably need some human editing and discussion first as some of the points have potentially big implications. I guess many came from old remarks in the forum but what about collecting/writing a few more user stories?

E.g. I would also push back against a "shared database" as a default. But that's also stated in the "vision"... What I would (should?) write into the vision is a configurable back end. An - strictly optional - connector to a PLM which allows the usual functions of check out/in/block/version/retrieve approved devices/... The same could be native git support and others. Likely that would be still on the basis of a standalone file format. In principle one could even support different saving schemes like saving to a central database but that gets quickly complicated to assure data integrity across versions for all options.

Here I see at multiple different feature sets / user stories:

• at least one standalone file format which is self-contained as it was up to now
• support "data bases" or more generally collections like the cable database, element database, etc.
• "local management" of those: starts with folder dialogues we have today and could add additonal tools like git mentioned before
• connection to a PLM which concerns the design files but also data base files like a cable database, device (element) database, etc.
• implementing a rudimentary PLM ourself (which is what the vision basically describes and rules out; that's what the "server application" is that is mentioned); two features mostly depending on this
• merging: something that CAD program of all kind struggle with. Traditional approach: block a file and only one person edits until they release it. Similar to svn. Can be broken down to parts of a project but already starting to be difficult with interdependencies. Really difficult up to unsolved: real merging.
  -a completely different beast which touches a bit the "run in a browser" which was discussed in the forum: cooperative live editing like overleaf for texts.

[ispyisail]

Thanks.

A question: How far can a community-driven project realistically go, and what are achievable goals?

[neitri]

I don't quite see the point of the debate regarding SQL, JSON, XML, or CSV.
As I understand it, when a cable is selected, data about it needs to be saved to the project file; within the project, that data would be in XML format.
Regarding storage, the same approach used for other elements could be applied: a directory structure with subfolders and files containing the descriptions.
As for performance, the same principle used for the project database could be adopted: generating a database from the cable or device library, and then either updating it as needed or rebuilding it entirely when required.
It seems to me that the device and cable libraries should be a single, unified entity—the only difference being that the interface would display only cables when selecting a cable, and only devices when selecting a device.
What I dislike is the "one file per cable" approach. However, if multiple cables are stored in a single file, there is a risk of duplication across different files—meaning the same cable could end up being duplicated in multiple locations.

[saschbe]

Une question se pose : jusqu’où un projet mené par la communauté peut-il raisonnablement aller, et quels sont les objectifs réalisables ?

I think a community-driven project can go quite far, as long as we clearly separate the long-term vision from what is realistically achievable today.

In the short term, I would focus mainly on solid foundations: a clear data model, classifications, terminals, UUIDs, component properties, and manufacturer references.

Then, if enough contributors get involved, the project could gradually move toward a persistent SQLite database, structured manufacturer catalogs, an API, and possibly rule modules such as the Belgian RGIE.

I don’t think we should try to build everything immediately. The most important thing is to choose an architecture now that remains open enough to support these evolutions in the coming years.

In short: stay realistic about what the community can maintain today, while avoiding technical choices that could limit QElectroTech tomorrow.

[ispyisail]

This is the document i base my vision on (unless somebody can come up with a better one)

https://qelectrotech.org/wiki_new/refonte_du_code_de_qelectrotech