Utilisation de QET pour schémas PID (Page 1 of 2)

Bonjour Opus,

Je crois que tu n'es pas le premier à faire cela
Pour mon travail, je dessine aussi avec QET des plans pneumatiques et hydrauliques directement intégrés dans la documentation électrotechnique de machines CNC.

Non, un conducteur est un conducteur ! QElectroTech ne fait pas la différence entre un conducteur électrique et un tuyau pneumatique ou une conduite hydraulique.
Mais tu peux changer leur apparence en double-cliquant dessus et en allant dans l'onglet "apparence".

Dans la même fenêtre "propriétés des conducteurs", tu peux aussi détourner les champs "fonction" et "tension/protocole" pour entrer des informations que tu pourras utiliser dans les flèches de revoie.
Voir ici pour la mise en place :
https://www.youtube.com/watch?v=xoRwsC17nlo

Pour l'instant, QET n'a pas encore de fonction intégrée qui réalise cela. Et les électriciens en auraient bien besoin aussi !
Malgré tout, nous savons que la faisabilité technique existe déjà car ces informations sont disponibles dans ton projet *.qet sous format xml.
Pour importer ces infos dans un tableur, il faudrait passer par un filtre XSLT qui convertirait le xml écrit par QET en du xml compréhensible par le tableur.
Si tu as envie de t'y mettre, voir ces quelques adresses :
http://www.w3schools.com/xsl/default.asp
http://www.zvon.org/comp/r/tut-XSLT_1.html
https://help.libreoffice.org/Common/Cre … ML_Filters

Les éléments de bonne qualité réalisés avec soin sont toujours les bienvenus

Super !

T'as utilisé quoi ? Un filtre XSLT ?

C'est une première : à ma connaissance, tu es le premier à réaliser cela, bravo !
Personnellement, j'ai jamais pris le temps, ni eu la patience, de m'intéresser en profondeur au sujet des filtres XSLT.
A l'occasion, est-ce que tu pourras nous montrer les résultats obtenus ? Sur le forum, ou par mail si les données sont sensibles.
Ces filtres ont le gros avantage de permettre d'exploiter plus de données issues de QET. C'est donc un sujet qui pourrait intéresser beaucoup d'utilisateurs.

Je n'ai aucune compétence particulière en filtre XSLT, désolé.
J'ai suivi les liens de Nuri + quelques recherches.
J'ai ouvert un fichier test.qet dans notepad++ (avec le plugin XML tools). Et grâce à un tuto j'ai créer un filtre XSLT que j'ai appliqué au fichier qet.
Rien de compliqué, je le partagerai dès que possible.
Pour l'édition "on the fly" c'est une autre affaire...

@ Opus
oublie l'édition tabulaire "on the fly", aujourd'hui il y a d'autres priorités pour le développement de QET.

Toutefois, la manipulation des filtres XSLT serait un grand plus car cela permettrait de modifier certaines valeurs dans un fichier *.qet de manière très ciblée et avec le confort d'un tableur.
Par exemple pour changer un cartouche dans tout un projet qui fait plus de 100 folios.
Ou alors pour renuméroter toute une série de composants ou des borniers complets...
Bref, pour faire de la manipulation de données à grande échelle.
Je sais qu'on peut aussi faire UNE PARTIE de ces tâches avec un éditeur xml et utilisant "chercher et remplacer" mais le risque d'écrabouiller des valeurs qui n'auraient pas du être changées est beaucoup plus grand. Et là, quand ca arrive, c'est la cata... faut sortir les fichiers sauvegardés de la semaine passée...

D'après ce que j'avais lu, il semblerai que Microsoft et son Excel soit plus avancé là-dedans que l'équipe des GNU/Stallmann avec LibreOffice.
Ca marche aussi avec LibreOffice mais la mise en place est moins "neuneu-compatible", si tu vois ce que je veux dire...

@ Opus

je ne connais pas les raisons pour lesquelles cette information n'existe pas.
Je pense que cette décision a du être prise au tout début du développement de QET.

Tu parles des informations qu'on rentre à la main dans le dock "propriétés des éléments" ?
Ou de la définition des éléments embarqués marquée par la balise <collection> dans le fichier *.qet ?

Personnellement, je trouve très bien que tout soit intégré dans un seul et même fichier car cela rend les projets facilement transportables d'un PC à l'autre sans aucune perte de donnée (ce qui n'est pas forcément le cas avec les alternatives commerciales de QET où il manque parfois la moitié des données quand le projet arrive chez le client ...).

Et peu importe que tu sois sous Windows, Linux ou Mac, ca marche sur tous les systèmes

De plus, un fichier *.qet se compresse très bien, avec souvent des ratios supérieurs à 10, ce qui rend les projets légers et donc facile à envoyer par mail (ce qui n'est pas forcément le cas avec les alternatives commerciales de QET où l'envoi par cloud est quasi indispensable ...)

La seule chose qui peut rendre un fichier *.qet énorme et indigeste, c'est l'intégration d'un grand nombre d'images (jpg, png...) car elles sont codées en base 64 dans le xml, ce qui n'est pas optimal.

après réflexion, je vois pas trop où tu veux en venir avec ta proposition de séparer les info éléments dans un autre fichier ?!?

Normalement, tu devrais pouvoir t'en sortir avec les filtres XSLT aussi bien pour lire que pour écrire. Mais comme j'écrivais déjà plus haut, je n'ai pas d'expérience à partager dans le domaine filtre XSLT.

En fait, tu aimerais écrire toutes les données d'article (fabricant, référence, etc...) dans un tableur puis les réinjecter dans QET, c'est ca ?
Pour ma part, j'ai aussi besoin de faire quelque chose de semblable. L'idée qui me semblait la plus facile est d'écrire directement ces informations dans le nom des éléments (comme décrit dans le tuto dont j'ai déjà fait référence dans un topic en anglais).
Certes la quantité d'information est assez limitée (on écrit toutes les données dans une ligne, séparées par des points-virgules) mais pour l'instant ca me suffit.
Quand j'ai fini mon projet, j'exporte la nomenclature en *.csv puis je la lie avec une macro Basic LibreOffice qui me converti ces données en tableaux *.elmt que je peux alors réinjecter dans mon projet.

Tu peux essayer d'adpater ce système à tes besoins. Il faudra alors vraisemblablement modifier le code de la macro Basic. Niveau difficulté, je pense que c'est comparable au bidouillage avec les filtres XSLT.
C'est-à-dire beaucoup plus facile que d'implémenter une nouvelle fonction en C++ dans les dizaines de milliers de lignes du code source de QET

Par ailleurs, je pense que la gestion des données d'article est un sujet majeur qui intéresse beaucoup de monde et qui propulserait QET définitivement au niveau de certains programmes commerciaux.
Si tu as d'autres idées, d'autres manières de faire (base de données ?) et d'autres points de vue, n'hésite pas à partager car nous manquons encore un peu d'expérience dans ce domaine.
En ligne de mire, il faut garder à l'esprit que ces fonctionnalités doivent être simples et relativement faciles à mettre en oeuvre car y'a pas une équipe de 12 développeurs C++ à temps plein derrière !

Joshua (le développeur principal) avait déjà parlé de mettre les images dans un sous-dossier et de transformer le format *.qet en une archive compressée.
Seulement voilà, c'est pas une modif faite en quelques heures de travail et, pour l'instant, il y a des choses plus importantes à finaliser dans le code source.

Bonjour,
connaissez-vous l'initiative DEXPI ?
C'est une initiative pour améliorer l'interopérabilité entre logiciels d'ingénierie, basé sur des efforts précédents (ISO 15926, XMpLant schema, Proteus schema, ...).
Leur site internet : http://www.dexpi.org/
Je vous laisse découvrir, je cite la partie qui m'intéresse le plus :
"Currently, the focus of the DEXPI initiative is the exchange of Piping and Instrumentation diagrams (P&IDs)."
Ils ont un github, où est présente la spécification
https://github.com/DEXPI/Specification/ … cification
Il y a aussi une partie "Test Cases" qui rassemble les différents cas testés entre logiciels, et les résultats en cours (AutoDesk, Aveva, Hexagon,...)

Je sais que QElectroTech n'est pas prévu pour ça à la base, mais je rêve d'un fork basé sur QElectrotech qui bousculerait ce classement.

Bonjour,

QET s'en sort très bien pour dessiner des schémas PID, ce que nous pouvons faire est d'ajouter de nouveaux champs informations dans l’éditeur de symboles et de schémas comme la capture plus haut, mais il en faudrait un nombre très conséquent d’après ce que j'en ai lu ...
Avec les textes dynamiques de la 0.7 il est possible d'automatiser le dessin et afficher les informations contenues dans le symbole ou dans le widget informations directement dans le schéma.

Par contre pour l'arbre XML et les différents attributs spécifiques ça se complique ...

Bonjour,

tu pourrais établir un cahier des charges sur les changements à effectuer dans le logiciel?
Dans le cas ou la seule solution possible serait de faire un fork, tu penses pouvoir trouver et rassembler une communauté de développeurs pour travailler sur ce projet, voir ajouter des nouveaux modules à QET ?

J'ai déjà utiliser FreeCAD à quelques occasions pour dessiner des pièces pour imprimantes 3D.
Il me semble que FreeCAD est également concu avec le Framework Qt ce qui pourrait faciliter une certaine interopérabilité avec QET.
Mais à moins de trouver une équipe motivée pour créer cette "passerelle", on risque de buter à nouveau sur le manque de ressources humaines...

Et c'est pas facile de rajouter énormément de propriétés aux éléments sans transformer le logiciel en usine à gaz.
On en bave déjà assez avec les propriétés électriques.
Peut-être qu'il serait plus ingénieux de lier QET à un système de base de données pour que chacun puisse rajouter des propriétés comme bon lui semble.
On manque un peu d'utilisateurs capables de faire des cahiers des charges assez développés pour que les développeurs de QET ne partent pas sur des fausses pistes.
Mon expérience personnelle se limite à la réalisation de schémas électriques. Le pneumatique, hydraulique et PID sont pour moi des sujets connexes avec lesquels je ne rentre pas dans le détail.

Clair ! c'est 5 fichiers dans le code qui sont a modifier à chaque fois ne serai-ce que pour ajouter un nouveau champ information...

/trunk/sources/autoNum/assignvariables.cpp   
/trunk/sources/diagramcontext.h   
/trunk/sources/editor/ui/elementpropertieseditorwidget.cpp   
/trunk/sources/nomenclature.cpp   
/trunk/sources/qetapp.cpp

r5059-scorpio810.diff

Modified: trunk/sources/autoNum/assignvariables.cpp
===================================================================
--- trunk/sources/autoNum/assignvariables.cpp    2017-10-02 14:46:26 UTC (rev 5058)
+++ trunk/sources/autoNum/assignvariables.cpp    2017-10-02 16:59:53 UTC (rev 5059)
@@ -167,6 +167,7 @@
         QString str = formula;
         str.replace("%{label}", dc.value("label").toString());
         str.replace("%{comment}", dc.value("comment").toString());
+        str.replace("%{description}", dc.value("description").toString());
         str.replace("%{designation}", dc.value("designation").toString());
         str.replace("%{manufacturer}", dc.value("manufacturer").toString());
         str.replace("%{manufacturer-reference}", dc.value("manufacturer-reference").toString());
 
Modified: trunk/sources/diagramcontext.h
===================================================================
--- trunk/sources/diagramcontext.h    2017-10-02 14:46:26 UTC (rev 5058)
+++ trunk/sources/diagramcontext.h    2017-10-02 16:59:53 UTC (rev 5059)
@@ -34,6 +34,7 @@
  * label                          -> label or identification of element
  * formula                        -> formula used to create the label (formula is make with variable)
  * designation                    -> exhaustive comment used to explain what the element does.
+ * description                    -> exhaustive description used to explain what the element does.
  * comment                        -> a little comment wich can be displayed in the folio
  * manufacturer                   -> the manufacturer of the element
  * manufacturer-reference         -> the manufacturer reference of the element
 
Modified: trunk/sources/editor/ui/elementpropertieseditorwidget.cpp
===================================================================
--- trunk/sources/editor/ui/elementpropertieseditorwidget.cpp    2017-10-02 14:46:26 UTC (rev 5058)
+++ trunk/sources/editor/ui/elementpropertieseditorwidget.cpp    2017-10-02 16:59:53 UTC (rev 5059)
@@ -152,7 +152,7 @@
  */
 void ElementPropertiesEditorWidget::populateTree()
 {
-    QStringList keys{"label", "comment", "designation", "manufacturer", "manufacturer-reference", "machine-manufacturer-reference"};
+    QStringList keys{"label", "comment", "description", "designation", "manufacturer", "manufacturer-reference", "machine-manufacturer-reference"};
 
     for(QString key : keys)
     {
 
Modified: trunk/sources/nomenclature.cpp
===================================================================
--- trunk/sources/nomenclature.cpp    2017-10-02 14:46:26 UTC (rev 5058)
+++ trunk/sources/nomenclature.cpp    2017-10-02 16:59:53 UTC (rev 5059)
@@ -91,6 +91,7 @@
     ""+ QObject::tr("Position") +";"
     ""+ QObject::tr("Label") +";"
     ""+ QObject::tr("Désignation") +";"
+    ""+ QObject::tr("Description") +";"
     ""+ QObject::tr("Commentaire") +";"
     ""+ QObject::tr("Fabricant") +";"
     ""+ QObject::tr("Reference") +";"
@@ -147,6 +148,7 @@
     info += elmt-> diagram()-> convertPosition(elmt -> scenePos()).toString() + ";";
     info += autonum::AssignVariables::formulaToLabel(elmt_info["label"].toString(), elmt->rSequenceStruct(), elmt->diagram(), elmt) + ";";
     info += autonum::AssignVariables::formulaToLabel(elmt_info["designation"].toString(), elmt->rSequenceStruct(), elmt->diagram(), elmt) + ";";
+    info += autonum::AssignVariables::formulaToLabel(elmt_info["description"].toString(), elmt->rSequenceStruct(), elmt->diagram(), elmt) + ";";
     info += autonum::AssignVariables::formulaToLabel(elmt_info["comment"].toString(), elmt->rSequenceStruct(), elmt->diagram(), elmt) + ";";
     info += autonum::AssignVariables::formulaToLabel(elmt_info["manufacturer"].toString(), elmt->rSequenceStruct(), elmt->diagram(), elmt) + ";";
     info += autonum::AssignVariables::formulaToLabel(elmt_info["manufacturer-reference"].toString(), elmt->rSequenceStruct(), elmt->diagram(), elmt) + ";";
 
Modified: trunk/sources/qetapp.cpp
===================================================================
--- trunk/sources/qetapp.cpp    2017-10-02 14:46:26 UTC (rev 5058)
+++ trunk/sources/qetapp.cpp    2017-10-02 16:59:53 UTC (rev 5059)
@@ -284,6 +284,7 @@
     info_list << "formula"
               << "label"
               << "comment"
+              << "description"
               << "designation"
               << "manufacturer"
               << "manufacturer-reference"
@@ -307,6 +308,7 @@
     if (info == "formula") return tr("formule du label");
     else if (info == "label") return tr("Label");
     else if (info == "comment") return tr("Commentaire");
+    else if (info == "descrition") return tr("Descrition");
     else if (info == "designation") return tr("Désignation");
     else if (info == "manufacturer") return tr("Fabricant");
     else if (info == "manufacturer-reference") return tr("Référence fabricant");
@@ -330,6 +332,7 @@
     if (info == "formula")                             return QString("%{formula}");
     else if (info == "label")                          return QString("%{label}");
     else if (info == "comment")                        return QString("%{comment}");
+    else if (info == "description")                    return QString("%{description}");
     else if (info == "designation")                    return QString("%{designation}");
     else if (info == "manufacturer")                   return QString("%{manufacturer}");
     else if (info == "manufacturer-reference")         return QString("%{manufacturer-reference}");

Ce n'est pas très compliqué en soit mais ça peut devenir très chiant s' il faut en rajouter un certain nombre...
Pour moi, la difficulté se trouve du coté de la structure des attributs XML pour être compatible avec DEXPI et être interopérable avec d'autres logiciels, il y a quelques exemples mais pas de listes définies...