Search options (Page 23 of 26)

For 2 weeks, I received a dxf file from my customer and this was generated from Inventor (3D CAD Software) and the dxf/elmt converter worked without any problem.

C'est vrai que parfois, c'est du délire... quand tu vois certains projets et les sommes qu'ils ramassent...

En fait, c'est difficile de le savoir. Il n'y a que les stats de downloads du serveur qui peuvent donner une information sur la popularité de QET.

Au niveau du logiciel, même si on peut très bien se débrouiller avec un peu d'expérience, il y a encore quelques facteurs assez limitatifs :
- la non gestion intégrée des =/+ (quoiqu'on en pense, c'est quand même beaucoup utilisé de part le monde)
- le fait que certains éléments importants en construction électrique, comme les borniers et les câbles, n'aient pas encore de "module dédié" pour faciliter et accélérer leur gestion
- le fait que le panel soit encore relativement rigide dans son focntionnement (pas d'arborescence, numéros des folios fixés par le logiciel)

Et puis il y a d'autres facteurs, indépendants de la qualité du logiciel :
- pas du pub, pas de marketing
- forum quasi exclusivement francophone
- documentation encore incomplète (beaucoup de boulot la doc...)

Bref... les sujets récurrents mis de côté par manque de bras et de temps.

Pour les nouveaux utilisateurs et les curieux, je pense que les premières utilisations de QET ne doivent pas donner un très bon apercu de ce que le logiciel peut faire (il n'existe pas de doc qui synthétise toutes les "features"). Personnellement, il m'avait fallu quelques mois pour comprendre toutes les possibilités du soft, tous les avantages d'un format ouvert en xml et d'un code source également ouvert.
Je comprends que cet investissement en temps ne soit pas à la portée de tous les électriciens/concepteurs dont la première priorité est plutôt de produire du schéma électrique.

Je ne sais pas trop comment vous voyez les choses, mais je pense que la version 1.0 de QET sera vraiment quelque chose digne de ce nom : un logiciel mûr, développé pendant plusieurs années par ses propres utilisateurs et réalisant un très bon compromis entre fonctionalité et complexité.
Il sera alors temps de penser au polissage des aspects marketing, promotion, publicité...

Et oui, je compte aussi refaire des dons. Vraisemblablement à chaque sortie de version .

MSO -->

XMLFox Advance est uniquement disponible en .exe -->
Cependant, sur le papier, l'idée à l'air plutôt bien, faudrait tester mais pour l'instant j'ai pas besoin d'un tel bouzin ("Microsoft Partner" qui plus est...).
Bon... je suis pas un puriste comme Richard Stallman mais j'ai presque les cheveux longs et j'aime bien mettre des sandales en été

Et ce n'est pas vraiment ce que je veux faire avec ma macro LO. Les données en entrée de la macro sont des csv, pas des données xml. Je veux créer du xml à partir du csv.
Il semblerait d'ailleurs que le Basic LO soit plus adapté (plus simple ?) pour accéder/lire/écrire des fichiers que le VBA (assertion de débutant, prière de ne pas m'allumer si je me plante ).

Grosso-modo, la macro devra faire ceci :
- lire la nomenclature csv dans LO Calc
- (éventuellement faire tourner une macro intermédiaire pour ordonner les données en fonction des besoins utilisateur)
- récupérer la config par défaut des folios dans le .conf de QET (largeur et hauteur en pixel)
- créer un fichier elmt par page de nomenclature (la macro écrit les attributs xml des lignes, des colonnes et des textes)
Les fichiers elmt créés ne sont rien d'autre que le tableau de la nomenclature écrit en xml compréhensible par QET.
- enregistrer les fichiers elmt créés dans la collection utilisateur
- retour dans QET : créer à la main les nouveaux folios "nomenclature" et tirer/déposer à la main les tableaux elmt sur les nouveaux folios.

Je pense avoir trouvé une doc plutôt pas mal sur le Basic appliqué à LO (notamment le chapitre "Files and Directories"). Voir la pièce jointe. Et ca me semble un peu moins mystique que le Qt/C++

Bonjour :-)

3 petites choses :

1.
petit retour sur les basic schapes :

la check box "vérouiller la position" ne fonctionne que partiellement.
Si la check box est activée, effectivement, il est impossible de déplacer la basic shape avec la souris.
Par contre, si la check box est activé et que la basic shape est sélectionnée, il est toujours possible de déplacer la shape avec les flèches directionnelles.

Je me sers surtout des basic shapes lignes pour délimiter les localisations sur mes schémas et, souvent, il est bien pratique de pouvoir verrouiller la position de ces lignes quand je déplace un bloc d'éléments avec les flèches directionnelles.

2.
question :
lorsque le nouveau dock aura été testé dans tous les sens et qu'on estimera son fonctionnement sûr et fiable (pour l'instant je ne vois pas de points faibles) est-ce que vous comptez supprimer la fenêtre "widget de l'élément" ?
Personnellement, je ne vois l'utilité de la conserver à part pour désorienter les nouveaux utilisateurs !

3.
question :
quelle sera la config par défaut de la GUI pour la release de la 0.5 ?
Nouveau dock actif/inactif ? À droite, à gauche ? En split-view avec le panel ? En onglet avec le panel ?
Comme déjà dit, j'apprécie particulièrement le split-view avec le panel, super pratique !

Salut Stephan,

lors de mes premiers pas avec QElectroTech, l'ajustement des textes fut également un problème pour moi.
Je voulais quasiment tout aligner à droite.
Maintenant, avec l'habitude, ce n'est vraiment pas le truc qui me dérange. En fait, il y a toujours moyen de déplacer les textes pour qu'ils soient bien lisibles et n'empiètent pas sur un symbole ou autre.
Sur ton schéma, tu peux déplacer les textes très précisément en appuyant sur Ctrl pendant le déplacement avec la souris.

Concernant les textes des attributs des éléments, je ne vois pas trop non plus où tu veux en venir.
Peut-être qu'un coup d'oeil sur le fonctionnement de l'éditeur d'éléments pourra éclairer ta lanterne.
Voir la page pdf 19 (16 de 45) du manuel QElectroTech :
https://download.qelectrotech.org/qet/m … doc-en.pdf

Bonjour,

à ma connaissance ces symboles n'existent pas encore dans la collection officielle.
Tu peux créer tes propres symboles à l'aide de l'éditeur d'élément intégré à QElectroTech.
Voir la page pdf 19 (16 de 45) du manuel QElectroTech :
https://download.qelectrotech.org/qet/m … doc-en.pdf

très pratique !
Merci, ca marche bien.

Je ne continuerai pas le trollage fr/de, je savais d'avance que ce serait stérile , alors que la discussion sur les borniers auto allait bon train

mouais... sur la manip directe du xml, je suis encore un peu sceptique car j'ai peur de créer de graves inconsistances dans le *.qet.
Mais, pour être honnête, j'ai pas vraiment étudié la question de l'édition xml et des filtres xlst.

Pour l'instant je me cantonne au csv car les données sont externes au projet et on peut bidouiller à loisir sans détruire tout ou partie du *.qet. Si je me plante quelque part, elles sont rééditées en 2 clics depuis QET. Donc pas de souci !

Pour créer les listes et tableaux (E/S d'API, listes de câbles, nomenclature, etc...), j'avais aussi pensé faire une macro LO qui écrit les nouveaux folios avec toutes les données dedans directement dans le *.qet en prenant comme base de travail le fichier csv exporté par QET, mais :
- il faudrait d'abord que je rafraîchisse mes connaissances pour écrire des macros (ca fait 10 ans...)
- je sais pas si ca marche
- il me faudrait du temps et là j'en ai pas (mais ca reviendra...)
En gros, faire une macro qui écrit du xml compréhensible par QET.

Cependant, à terme, même si ca marche, c'est pas une bonne solution universelle car cela rend ces fonctions dépendantes de LibreOffice. Donc l'import csv serait mieux car QET ne serait pas lié à un tableur particulier.
Après, tu connais mon niveau en programmation...

Le plus facile à générer en automatique, ce sont les tableaux de borniers (page 1 de mon pdf).
Eplan fait ca depuis au moins 25 ans, justement parce que c'est le plus facile. Dès qu'on veut rajouter des symboles, des conducteurs, etc., ca complique très sérieusement l'affaire.

Donc pour l'instant, je mets les réflexions sur les plans de type page 3 entre parenthèses, on pourra y réfléchir plus tard.

Je tourne et retourne les réflexions dans ma tête et j'arrive toujours à la même conclusion :
il y a un gros travail préalable à faire sur les éléments pour que la partie Data de la génération soit suffisamment alimentée en données (pour que QET sache, par ex., que l'aboutissant amont de la borne -X1:2 est le contacteur -KM1:2 et l'aboutissant aval le moteur -M1:U).

Et ensuite, pourquoi ne pas utiliser l'export csv pour que la partie Data soit réalisée par un tableur ?
L'utilisateur laisse tourner une macro "faire des tableaux de borniers" qui réalise, grossièrement, les opérations suivantes :
- effacer toutes les lignes des éléments qui ne sont pas des bornes (en utilisant la colonne "Désignation qet")
- effacer toutes les colonnes inutiles pour la génération de borniers ("fabricant", "référence fabricant"...)
- classer les bornes selon le champ "localisation"
- à l'intérieur d'une "localisation", classer les bornes suivant le label de bornier (-X1, -X2, -X3...)
- à l'intérieur d'un label de bornier, classer les bornes selon leurs numéros (1, 2, 3...)
- enregistrer le fichier en csv

QET prend alors le relais et lit le fichier csv. Avec une GUI, il demande à l'utilisateur s'il veut importer une nomenclature, une liste de câbles, une liste d'E/S d'API ou un tableau de borniers. Dans ce cas un tableau de borniers, ce qui appelle la réalisation d'une scène préconfigurée pour créer les folios "tableaux de borniers" ainsi que la génération des tableaux (un peu comme la génération du sommaire).

Et on retourne alors au sujet de ce topic :
il faudrait une interface pour réinjecter des données csv dans QET car cela permettrait de créer tous les listages et tableaux usuellement présents dans les documentations électrotechniques.

Tiens, pour sortir du rêve et se coltiner des problèmes bien concrets, je vous ai mis quelques exemples de plans de borniers en pièce jointe. Désolé, c'est en allemand, mais je pense que les électriciens devraient s'y retrouver quand même. Si nécessaire, pour traduire le vocabulaire technique, utiliser www.linguee.de.

Parce que "bornier automatique", c'est bien beau, mais ca veut dire quoi exactement ?
Selon les logiciels, les époques, les savoirs-faire et les pays, il y a différentes facons de dessiner des plans de borniers.

Page 1 :
c'est du Eplan pur jus. Tableau de bornier totalement automatique : tu cliques sur un bouton et c'est fini.
Mais pour en arriver là, vous vous doutez bien que cela nécessite de configurer quelques trucs dans les bornes posées sur les schémas électriques. Ce temps de configuration est inexistant dans QET.
Le tableau est statique et est généré en post-traitement. Une modification dans les schémas ne se répercute pas automatiquement dans le tableau, il faut regénéré le tableau.

Page 2 :
encore du Eplan mais cette fois-ci avec du graphisme (avec symboles). Grosso-modo, c'est pareil que page 1 : totalement automatique, mais il faut configurer encore plus de choses pour en arriver là...
Danc ce cas, le temps de configuration et tellement long que je me demande sérieusement si je n'aurais pas été plus rapide en faisant tout à la main...
Parce que générer des trucs automatiquement, c'est bien, mais générer des trucs automatiquement JUSTE et CORRECTE, c'est une autre histoire...

Page 3 :
logiciel inconnu, peut-être Promis. J'en suis pas sûr mais je pense que le graphisme est généré semi-automatiquement en post-traitement. A vrai dire, je vois pas comment on peut faire proprement ce genre de plans de manière totalement automatique (gérer la position et la taille des symboles, les brins de câbles, le croisement des brins, les textes trop longs...). La gestion des cas particuliers doit être un cauchemar au niveau du code.

Pour construire les armoires électriques, on utilise plutôt les plans de type page 1, puisque tous les raccords des borniers sont explicitement détaillés.
En maintenance, on préferera les plans de type page 3 car ils donnent un meilleur apercu du câblage, les détails étant souvent examinés sur site.

Si vous avez d'autres exemples...

@ Scorpio
ben je sais pas encore combien de folios j'aurais à la fin mais ce sera certainement moins de 150. La machine est petite : 7-8 moteurs, quelques capteurs, quelques vannes...
Fin de la semaine dernière, j'ai appris que c'est une machine pour les USA, donc il faut tout concevoir selon la norme américaine UL508A "industrial control panel"... Le cauchemar... Il faut tout repenser et je suis assez paumé.
Par chance, j'ai réussi à échapper aux symboles ANSI et je peux donc créer les nouveaux éléments selon IEC.

@ Galexis
si tu t'ennuies , y'a la documentation html d'Arun à traduire de l'anglais au francais. Ca commence à devenir un sacré pavé. Je comptais la faire mais là j'ai vraiment pas le temps. En plus, c'est pas toujours facile à traduire et il faut bien écrire pour que ce soit facilement compréhensible.