1 Reply by hairy_kiwi

(56 replies, posted in Import)

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

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

3 Reply by hairy_kiwi

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

Merci Laurent!

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

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

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

6 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

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

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

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

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

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