1 Reply by hairy_kiwi

(9 replies, posted in EN : Help, suggestions, discussions, ...)

plc-user wrote:

Hello hairy_kiwi,

there is no need to search the QET-Sourcecode to find the possible text-variables for references!
If an element is declared as coming / going reference the possible choices for the texts are shown in the drop-down.

Hallo plc-user,

I agree there's no need per se, except to make the layout of single-line concatenated text strings a little prettier, as it provides a convenient method to use one Dynamic text field instead of two or more.

For example, I don't think there's a QET-native method for laying out the following:
"%{conductor_color}  %{conductor_section}"
while maintaining two spaces – or some other character(s) – between those variables and keeping that entire string centred about the element insertion point, irrespective of its total character length; hopefully that consistency of text alignment across multiple wires is visible in my examples.

Now, approximately the same layout can be achieved using two Dynamic text fields, setting left-variable field right-aligned and right-variable field left-aligned, but that takes greater effort to configure when creating the element - and in the end the output is not as pretty.

For two-line (or multiline) text, I fully agree the method you show is more convenient.


I may not be using QET for the kind of wiring diagramming for which it was originally conceived, but I appreciate it - and all the work that goes into developing it - because I enjoy its ability to generate aesthetically pleasing output, even if a few workarounds are still required to achieve that; thanks for everything you've been working on for the QET project. nomicons/smile

Go to forum: EN : Help, suggestions, discussions, ...

2 Reply by hairy_kiwi

(18 replies, posted in Code)

scorpio810 wrote:

For me, sqlite help to create BOM, summary pages, ect, but when you change any things the change it's saved in XML of the project.

Hello Laurent and plc-user,

I've also taken an interest in the QET codebase recently. Forgive me intruding on your conversation, however unless I mis-read what Laurent says, what he writes is not my observation from the following tests:

If I open a couple of text editors: Brackets and Visual Studio, while in QET I change a wire number for example from "110" to "110A", I do not see that change reflected in either Brackets or Visual Studio, until I Save the project in QET.

Conversely, if I modify the .qet file in Brackets or Visual Studio (both the formula="110x" and num="110x" values for the wire I'm watching) I immediately see the change reflected in the other text editor, but not in QET until after closing and reopening the project.

Hope it helps - and I've not simply misunderstood or got the wrong end of the stick nomicons/smile


Btw Laurent, as far as fundraising for essential annual project expenditure, I'd be very happy to contribute; and I'm sure no doubt many people would, if fundraising efforts were made more public. I know other opensource projects have similar annual fundraising campaigns and believe devs ought not to be spending their personal money on keeping a mature, widely-appreciated project online when they already contribute their free time. I think you only need decide whether to accept donations directly, or via a payment processing intermediary (searching "online donation platforms" turns up a plethora of providers) - and the money will surely follow.

Thank you both and all the devs for your ongoing work nomicons/smile

Go to forum: Code

3 Reply by hairy_kiwi

(2 replies, posted in EN : Help, suggestions, discussions, ...)

First of all, I find it annoying, to define a set of auto numbering schemes for each project I begin.  It would be more efficient, if you could save those rules as part of your program preferences.

I was wondering similarly recently. I just discovered a great copy-paste solution in the following thread by Laurent.
https://qelectrotech.org/forum/viewtopic.php?id=2571

Basically, you open an existing project in a text editor and copy any settings you need from between the <newdiagrams>...</newdiagrams> tags and paste to a new file saved with .qet extension. Now continue in QET nomicons/smile

Go to forum: EN : Help, suggestions, discussions, ...

4 Reply by hairy_kiwi

(4 replies, posted in EN : Help, suggestions, discussions, ...)

5. In element editor how to group all items together since when I use this element in schematic the texts of that element changing position.

There's no ability to group element components as such, instead, try turning off (unselecting) Maintain visual rotation (see image below) of each text field.

Unselecting Maintain visual rotation causes an element's text fields to remain orientated according to the element's original layout.


Devs, if you read this: I think possibly the wording "Maintain visual rotation" is a little unintuitive (A tick box labelled 'Rotate text with element' - and logic configured in the opposite sense) might be more intuitive. It might also be nice to be able to user-select the default logic for element text in a system wide config file, but just ideas - for another time. nomicons/smile

Go to forum: EN : Help, suggestions, discussions, ...

5 Reply by hairy_kiwi

(9 replies, posted in EN : Help, suggestions, discussions, ...)

Many thanks plc-user and Laurent for the file and inspiration...

Here are five more wire info labels (elmt files in the zip). The objective was to display conductor info either over or alongside the conductor, without a node '•' or call-out box. In the image below, the first wire (140) serves a a QET 'default numbered wire' reference:

https://qelectrotech.org/forum/misc.php?action=pun_attachment&amp;item=3066

The remaining five examples use the following built in (undocumented?) conductor variables I found in the dynamicelementtextitem.cpp code on github:
%{function}
%{tension_protocol}
%{conductor_color}
%{conductor_section}

Other small changes include the following:
- A Composite text source is used to populate each Dynamic text field in the elements. For the single-line variants, a Composite text allows better layout control of a wire info label, so far as horizontal centring concatenated text about the label's reference (insertion) point.

- The (white-filled) radiused boxed style labels require clicking 'Bring to front' to display correctly. They're a bit old school perhaps, but I quite like them.

- All unboxed styles contain a non-outlined (fully transparent) rectangle to make it easier to select and move the entire element after insertion if required, rather than just the text.

- Inserting these wire info labels (Laurent's or plc-user's as well) generates an additional wire - and therefore an additional wire number, however the number (text or formula) is identical to that of the original wire. The workflow to get a visually pleasing result looks something like this:
   + create a wire,
   + edit its properties,
   + add the desired wire-info (report) elmt,
   + delete the original, longer wire (rather than the shorter wire from the label to component terminal) and finally,
   + add-back the missing conductor segment. This step also adds a second wire number/name, which can be left in the default position (wire 141 in my example image above) - or each number moved to each end of the wire.

- That last step is possibly a serendipitous side-effect: IIRC, the numbering of each end of a wire was a feature someone requested not so long ago in another thread. nomicons/smile

Go to forum: EN : Help, suggestions, discussions, ...

6 Reply by hairy_kiwi

(129 replies, posted in Import DXF)

Bonjour Laurent!


On Mac OSX (Montery 12.6.8) I wonder if anyone else experiences the same issue before I submit an issue on github:


The following file works fine:
dxf2elmt (1.8MB uncompressed) from https://download.qelectrotech.org/qet/b … .0/osx_64/
in dxf2elmt.zip dated 2022-07-27 18:09 888K


This file does not function:
dxf2elmt (1.6MB uncompressed) from
https://github.com/antonioaja/dxf2elmt/releases
in dxf2elmt_macos_arm64_v0.3.0.zip 2022-07-20 821 KB


The second, disfunctioning file exhibits the following behaviour:

In Qelectrotech Element Editor, the dxf is not converted.

In Terminal, the dxf is also not converted and the following message is displayed:
-bash: ./dxf2elmt: Bad CPU type in executable


Let me know if best to submit the same report on antonioaja's github, or if this report is sufficient?


Best regards and thank you for all your efforts despite your health.
Wishing you some better health in 2024  nomicons/smile
Hamish

Go to forum: Import DXF

7 Reply by hairy_kiwi

(23 replies, posted in EN : Help, suggestions, discussions, ...)

Hello Laurent,

I did see the DXF converter but just haven't yet had time to check it out.

At significant risk of appearing to jump around and hijack threads (my apologies)...

Looking at QET from the perspective of a relative outsider, I can appreciate all the good effort going into building converters and the terminal block tool – all great progress, however – and as Joshua alludes to himself in this post:
https://qelectrotech.org/forum/viewtopi … 925#p12925

Joshua wrote:

One other things (this is my opinion and not necessary the opinion of the whole QET team) don't draw exactly the same element for each reference of a device series.
...
The element collection is very big and make a lot of time to be loaded (in windows), so no need to bloat it with doubloon.

That suggests there is considerable value in integrating the work of plc-user etc in core code, in order to obviate the need for (mirrored) duplicates of components. But before that it seems the data associated with terminals - and its programatic accessibility to the rest of the drawing - as you seem to suggest here:
https://qelectrotech.org/forum/viewtopi … 925#p12925
has yet to be fully agreed upon?

I feel I've already taken more of your time than I perhaps deserve as a newcomer, but I do so only with a desire to see QET as fine a software as I know it will be; I know it all takes time, but I also see a lot of apparently dead conversations in this forum around some very fundamental aspects of QET.


Sincerely,
Hamish

Go to forum: EN : Help, suggestions, discussions, ...

8 Reply by hairy_kiwi

(23 replies, posted in EN : Help, suggestions, discussions, ...)

Merci Laurent!

Go to forum: EN : Help, suggestions, discussions, ...

9 Reply by hairy_kiwi

(23 replies, posted in EN : Help, suggestions, discussions, ...)

Merci beaucoup Laurent!

There's seems to be a lot of excellent, productive activity happening from time to time or quietly in the background.

Is there a current roadmap for QET publicly available?

Many thanks for all your dedication in managing the project!


Hamish

Go to forum: EN : Help, suggestions, discussions, ...

10 Reply by hairy_kiwi

(23 replies, posted in EN : Help, suggestions, discussions, ...)

Hi Rudy,

What is the current status of this topic and implementation of the 60617-inspired database in QET vs your own version - was any of your work integrated into QET?

I read the IEC documents you linked to and some others, including this one:
https://webstore.iec.ch/preview/info_ie … .0%7Db.pdf
...and it is interesting to read the IEC's copyright notice for the IEC 60617 database (copied below, my bold) on page 2 of that pdf.

Copyright
The structure and content of the IEC databases are copyright of IEC. IEC encourages the
use, referencing or citation of the contents of the databases for the purpose of identifying or
clarifying the meaning of electrotechnical concepts, terms and symbols and their use in
manuals, diagrams and equipment. IEC should be referenced as the source. Duplication of
the databases or the extraction of substantial portions of them for commercial exploitation
or for free sharing is prohibited without the explicit, written approval of the IEC.


So I suppose some differentiation between the IEC 60617 database and anything 'inspired by it' is worth maintaining, if only to ensure this free project respects the spirit of copyright law. C'est la Vie – someone has to pay for IEC delegates to meet up occasionally to discuss line end types. nomicons/wink

Otherwise, I very much like your efforts toward continuous improvement. nomicons/smile


Hamish

Go to forum: EN : Help, suggestions, discussions, ...

11 Reply by hairy_kiwi

(30 replies, posted in Scripts)

plc-user wrote:
galexis wrote:

It's not possible to integreted it directly on QET like it's C++?

There are several new topics for me at once:
For the beginnings in Pascal I only needed to add a little XML to the Pascal knowledge. The change to C++ was then already bigger. But then to integrate that into an existing, grown QT project, that's quite another matter...
For the moment I have put together a small (and from my point of view) usable package. There is no question that in the foreseeable future it will make sense to integrate scaling and mirroring directly into QET's Element-Editor!


Bravo plc-user! QET becomes more and more appealing by the day - many thanks for your great work!


Hamish

Go to forum: Scripts

12 Reply by hairy_kiwi

(6 replies, posted in DE : Hilfe, Vorschläge, Unterhaltungen...)

Hallo Throsten,

Take a look at page 69/226 of the Rev 0.8 pdf manual:
https://download.qelectrotech.org/qet/m … oc-0.8.pdf
- also available via the Manual link at qelectrotech.org

– or search "Folio Size" in that pdf.

As a new-comer to QET, I cannot explain the folio sizing functionality so well, however I have noticed the component (elements) are dimensionless and, as a result if you right click on your page (no doubt by other methods also) it is possible to add columns and/or rows and by so doing you can fit more content on a single folio.

Hope it helps nomicons/smile


Google Translate:

Schauen Sie sich Seite 69/226 des PDF-Handbuchs Rev 0.8 an:
.../qet/manual_0.7/build/_downloads/408498051918f1618a071fe56e737db5/QElectroTechdoc-0.8.pdf
– auch über den Link „Handbuch“ unter qelectrotech.org verfügbar

– oder suchen Sie in diesem PDF nach „Foliogröße“.

Als QET-Neuling kann ich die Folio-Größenanpassungsfunktion nicht so gut erklären. Mir ist jedoch aufgefallen, dass die Komponente(n) dimensionslos sind und daher, wenn Sie mit der rechten Maustaste auf Ihre Seite klicken (zweifellos auch mit anderen Methoden), sie nicht angezeigt werden Es ist möglich, Spalten und/oder Zeilen hinzuzufügen und so mehr Inhalte in ein einzelnes Folio unterzubringen.

Ich hoffe es hilft nomicons/smile

Hamish

Go to forum: DE : Hilfe, Vorschläge, Unterhaltungen...

13 Reply by hairy_kiwi

(13 replies, posted in EN : Help, suggestions, discussions, ...)

After visiting the IEC's page on the production of graphics and figures to IEC 61082-1:
iec.ch/standards-development/graphics-figures

Prepare electrotechnical diagrams using graphical symbols from IEC 60617 and in accordance with IEC 61082-1.

https://www.iec.ch/system/files/inline-images/Figure9%28Diagrams2%29.png


..it's interesting to note some of those components are mirrored rather than simply rotated. So I don't feel any long-time user of QET should feel at odds with the mere mentioning of another softwares capabilities in order to stimulate conversation or enquire about possible future improvements QET, especially when it be for the benefit of all users, long-time and new-comers alike - that is after all, one of the greatest benefits of OSS to all of society.


Sincerely,
Hamish

Go to forum: EN : Help, suggestions, discussions, ...

14 Reply by hairy_kiwi

(13 replies, posted in EN : Help, suggestions, discussions, ...)

bernard_andre wrote:

Mise au point:
Qelectrotech est destiné avant tout pour dessiner des schémas développé selon  IEC 61082-1 ou des schéma unifilaire et les documents attenant.

KiCAD et un logiciel de conception de schémas électroniques et de de circuits imprimés.

Donc à mon avis, KIcad n'a pas sa place dans ce forum!


Bernard writes:
"Focus:
Qelectrotech is primarily intended for drawing diagrams developed according to IEC 61082-1 or single-line diagrams and the accompanying documents.

KiCAD is a software for designing electronic diagrams and printed circuits.

So in my opinion, KIcad has no place in this forum!"


Bonjour, merci pour votre avis Bernard – and forgive me the title of this thread, however my reference to KiCAD (not meant to be in any way disrespectful at all) was simply to highlight:
- my previous experience,
- how I came to discover QET by KiCAD's shortcomings for my particular diagraming requirements, and
- some of the structural improvements KiCAD has adopted itself over the period of its development, for the benefit of it's particular user base.


I do fully agree with you that QET should not try, and does not need to be another KiCAD, yet the later shows a degree of robustness and usefulness at it's direct equivalent to the terminal level, that I believe all QET users could ultimately benefit from.

Finally, after a little more time on this forum, I see I am certainly not the first to enquire or draw comparison between those aspects of KiCAD that show how QET might undergo further relatively straightforward improvement. Improvement that has nothing at all to do with end use (IEC 61082-1 etc) and everything to do with time-saving, error-free diagramming - which has to be desirable by any industry participants using - or investigating using QET - no?


Respectfully,
Hamish nomicons/smile

Go to forum: EN : Help, suggestions, discussions, ...

15 Reply by hairy_kiwi

(13 replies, posted in EN : Help, suggestions, discussions, ...)

Bonjour Laurent!

Many thanks for your replies.

I couldn't find any recently updated roadmap for QET, but I'm beginning to get a feel for where QET development is hopefully going; especially:
https://qelectrotech.org/forum/viewtopi … 337#p18337  uuid of terminals – which leads to both:
https://qelectrotech.org/forum/viewtopi … 024#p13024  terminal names
https://qelectrotech.org/forum/viewtopic.php?id=1743  connection list export


While a native netlist generation feature would be nice to have, I can't help thinking it's of secondary value to a robust yet adaptable .elmt schema for the user being assigning data to terminals, at terminal level and subsequently display (or hide) that data in a diagram.


You suggest in this post:
https://qelectrotech.org/forum/viewtopi … 925#p12925 that:

Terminals informations need  {element type=?}, {terminalblock=X11}, {label name=DIOO} and {pin number=1} Input/Output, Power, etc ... properties, it's time to think about it for the future ...

Which all seem useful additions, however I would suggest another field {pin/terminal function=} would also be useful – with the ability to display any or all those: terminal number, terminal function, terminal label, etc – in order to make QET more flexible, adaptable, robust and especially, less data-entry error prone.

I don't think the degree of flexibility I'm describing is too far removed from some of the flexibility I see already implemented in QET, especially considering the existence of the feature 'Custom properties folio tab' on page 55 of the Rev 0.8 pdf manual.

Applying a similarly degree of flexility to element and terminal nomenclature ought only help grow the appeal of QET to an even wider audience, and thereby potentially attract more potential users - and development funding - over the longer term, no?

By comparison, KiCAD offers such flexibility of data field nomenclature at component level, but I can see similar advantages to extending that philosophy to the terminal level.


Finally, another nice to have feature would be the ability to mirror elements. Looking through QET's vast library, there seems to be a fair amount of asset duplication, due to lack of such a mirror transform. End pieces of terminal blocks especially come to mind, but I imagine for my own diagraming requirements without a mirror transform I will end up creating east and west (maybe even north and south) facing versions of a number of elements, with the potential future maintenance hassle that doing so creates.



I hope the above is taken as constructive feedback; especially as I'm keenly aware how long open source software (rightly) takes to mature.

My development skills are unfortunately quite limited to (slowly and painfully) bashing the odd python script together and perhaps being able to contribute to improving or extending documentation; but I look forward to contributing in what ever small way I can to the progress and wider adoption of QET.

I have already accumulated a small collection of (the composite text) variables that don't appear to be in the on-line or pdf manual. Is there a way to submit document change proposals via the git interface?


Hamish

Go to forum: EN : Help, suggestions, discussions, ...

16 Topic by hairy_kiwi

(13 replies, posted in EN : Help, suggestions, discussions, ...)

Hello QET Community,


First of all – a massive thank you to everyone involved in developing QET over the years - Bravo et merci à tous! nomicons/smile


I have a little in-depth experience using KiCAD – for creating electronic schematics and PCBs (of course) – and more recently for creating wiring diagrams for light aircraft. After discovering all of KiCAD's shortcomings for wiring diagraming, I went hunting and discovered QET.


After the last four days learning and playing, there's a lot to like about QET that makes me want to persevere, support and promote it within the general aviation wiring and avionics community, yet I can't help feeling a little torn between QET and KiCAD – and not just because 'the latter is what I'm most familiar with'.


I've attached a few files to show the kind of diagramming I want to achieve with QET, along with my first attempt at creating a multi-connector, multi-pin (multi-terminal) QET element. I hope they collectively help better understand the somewhat industry specific requirements – and help explain how best I can use QET's features more efficiently, ultimately to generate BOMs (and netlists). If I need to use python to create elements outside of the built-in element editor, for example to convert CSV to QET .elmt format, I'm happy to give that a try too.


I really appreciate the quality of diagrams QET is able to produce for industrial and domestic diagraming requirements and hope that I might just need to rethink my approach so far, so here's a brief summary of my initial experience with QET vs KiCAD:

The single biggest advantage I saw in using QET over KiCAD was in its ability to add data to wires. To do that in KiCAD requires inserting a pseudo-component; it works, but moving wires around a diagram then becomes hugely time-consuming – and every wire becomes two connections in a netlist.

Having created the attached gtx328_transponder.elmt (a light aircraft transponder) I can't help thinking I'm either missing something about QET terminal interconnect philosophy, or there's a lot of potentially error-prone double data entry required in order to name terminals and then separately describe their function in another, otherwise disassociated text box. The other aspect of creating an element in QET (0.100-dev) that I found time consuming is text alignment: the reference point of each text block (x,y) position doesn't appear to update to reflect a change to the 'Alignment' option; the text box location remains referenced by its upper left corner, irrespective of its assigned Alignment option.


There's plenty more to discuss, but I hope the above is a constructive starting point in beginning to understand and adapt my thinking.


Many thanks in advance for any advice, suggestions or questions,


Hamish
Ledbury, UK

Go to forum: EN : Help, suggestions, discussions, ...