Éliminer certains éléments de la nomenclature (Page 2 of 3)

Gni?

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

Alors, je traine à répondre car je suis en pleine séance de maçonnerie ! Je répond vite fait. (Je pensais même ouvrir un post séparé pour cela....)
Mais pour moi, mes attente se situe plutôt dans la page 3 de l'exemple.

Je pense presque que tout existe aujourd'hui pour faire des bornes auto ou semie-auto.
Je pense qu'il faut pouvoir cumuler la fonction Xref des renvois et la fonction label des maitres/esclaves.
La borne dans le schéma est une "borne-maitre" dans lequelle on saisie en label le numéro de la borne. Un élément "borne-esclave" inséré à la main dans le folio de bornier en fin de schéma, qu"on lie : le label est appliqué (fonctione maitre/esclave mais sans tableau) et ainsi que la position (fonction renvoie).
J'avais ouvert un post une fois qui était dans ce sens. Pour moi cela ne peut pas être full-auto pour rester personnalisable (sommaire).
http://qelectrotech.org/forum/viewtopic.php?id=555

Snif

  me suis bien marré, c'est clair
J'ai bien conscience que le full-auto n'est pas faisable, moi je voulais juste montrer quelques exemples pour amorcer la discussion sur la v0.6

A la base, je trouve l'idée de Galexis pas mal, je compte d'ailleurs faire quelque chose de semblable pour ma machine CNC.
Je pense que c'est la voie à creuser.

Et comme disait Joshua sur le canal IRC, pour faciliter le travail et minimiser les erreurs, la génération peut se passer en 2 temps :

1. Partie "Data"
QET lit les données des schémas :
- noms des borniers (-X1)
- numéros des bornes (1, 2, 3...)
- positions des bornes (8.C2)
- numéros des fils raccordés aux bornes (001...)
- label des appareils raccordés aux bornes (-F01, -Q22...)
- numéros des bornes des appareils (13, 14, 21, 22...)
Ensuite, ces données sont classées et ordonnées suivant une méthode standard non configurable (sinon on en sort pas...) :
Ainsi, on peut imaginer que les bornes soient classées par odre alphanumérique par défaut, même si c'est pas toujours le cas en pratique.
Si 2 bornes sont adjacentes et sont reliées par un conducteur, alors QET crée par défaut une barrette de jonction.
Bref, on peut définir un algorithme standard. Le but étant, à l'issue de la partie "Data", de montrer à l'utilisateur à quoi ressemblent ses borniers. Vient ensuite la partie 2 :

2. Partie "interaction avec l'utilisateur"
Avec une GUI appropriée (qui devrait ressembler à la page 1 de mon exemple) QET donne à l'utilisateur la possibilité de modifier l'ordre des bornes, la présence de barette de jonction, le sens amont/aval des bornes, etc.
Ensuite, l'utilisateur choisi s'il veut faire des tableaux de borniers (page 1 de mon exemple) ou des plans de raccordement (page 3 de mon exemple).
S'il veut faire des tableaux, la configuration est déjà terminée et la génération des folios "tableaux de bornier" peut commencer.
S'il veut faire des plans de raccordement, l'histoire se corse car il faut encore comment savoir placer les éléments graphiques...
...et donc j'arrête là ma réflexion scabreuse...

Perso,
je me voyais bien faire comme la page 1 et 3 du pdf de Nuri. Après en fonction des demandes ça peut évoluer bien entendue.
Ensuite comme à dit Nuri, il faut bien distingué deux choses.

1° la partie Data.
2° la partie graphique.

(je prend ma casquette de développeur....)
Il me faut avant tout connaître de manière claire (En d'autres mots vos attentes) toute ce qui doit figurer dans la partie data, car c'est le plus important.
Ensuite vient la partie graphique qui  est (j'exagère un peu) juste la mise en page des data, et cela vient après dans le résonnement.

Donc pour faire avancer le truc (même si c'est pas pour tout de suite) mettez à plat tout les choses correspondant à la partie data.

Laurent au sujet du plugin python rêve pas trop .....   faire des plugin C++ pourquoi pas car Qt le permet out of the box (mais faut avoir une base bien clean avec certain prérequis, enfin bref je m'égare la...) en revanche pour le python c'est pas trop le cas et je pense qu'on dépasse mes connaissances....

Cela dit l'idée est très bonnes même si c'est plutôt l'inverse au niveau du résonnement car le coté data Qet le connais donc suffit juste de fournir toutes les info au plugins, par contre le coté graphique peut être fait de plusieurs manière différente surtout au niveau des options (barrette de jonction, ajouté un ou deux bornier de plus ect....).
Et la le plugins peut être sympa car c'est lui qui ferait tout ça et il renvoie juste un pixmap qu'on intègre dans les folios.

Une dernière choses, pour moi je verrais bien les borniers en post traitement, c'est à dire pas de mise à jour lors d'une suppression/modif/déplacement (en gros ce serais juste une image, voir réellement une image).
Pour les raisons suivante.
-Gros truc et usine à gaz à codé (comparé au post traitement)
-fort risque d'erreur, en post traitement les erreurs serais toujours possible (et oui je fournis beaucoup de bug) mais très minimisé étant donné qu'on récupère les data à un moment T, donc si c'elle ci sont bien interprété et mise en page y'a pas de raison.

L’inconveniant c'est qu'il faut refaire le bornier si on touche au schéma, mais en principe on fait ça à la fin donc bon....

A+

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.

C'est exactement ce qui est représenté dans le plan type page 1 (je savais que j'aurais du faire ca en francais ...), sauf que c'est sous forme de tableau.
Bon, à l'occasion, je prendrai un peu de temps pour sortir ces plans en francais

Faut aussi penser aux avantages du csv :
- c'est intersystème (windows, mac, linux)
- ca se travaille facile avec un tableur (Excel, LibreOffice...)
- c'est facile à automatiser
Et franchement, écrire des macros tableur, c'est quand même à la portée de pas mal de monde. Et ces macros peuvent être mises à disposition par la communauté sur le site QET dans la partie "download".

Alors que faire des scripts Python ou C++... -->

Et puis, l'export csv est déjà fonctionnel, autant en profiter !

De ce que je vois à mon travail, les tableaux type page 1 du pdf, ne font pas partis des usages en France. Un câbleur/installateur a besoin d'un schéma simple de bornier représentés sous forme de bornier.
Il me semble en revanche que dans les plans des machines allemandes on les a parfois...

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

Justement tu risques absolument rien si sur les filtres import/export xlst tu ne travailles que sur les attributs des l'elements:  informations: label, commentaire etc.

Hum, tu dois aussi gérer les positions X,Y de chaque élément dans la GraphicScene, mais c'est faisable pour par exemple des borniers.

Alors ça, ça m'en touche une sans faire remuer l'autre, du moment que c'est basé sur du libre et à plus forte raison que c'est aussi un outils gratuit, de plus avec un format pérenne pour l'avenir. On ne peut pas en dire autant de MSO qui est parfois incapable de lire ses propres fichiers si la version diffère!
Les aficionados de MSO trouverons bien le moyen de transposer ces filtres xlst sur leur outils.

Bien sur, suffit d'aller explorer le wiki.