Bonjour,

NootNooter wrote:

Cependant je suis curieux, dans quel cas utilisés vous des schémas en A3 ? En 2 ans dans un BE électricité industrielle je n'ai vu que du A4 pour l'instant.

Au  boulot (en agroalimentaire) on a une machine dont les schémas électriques sont imprimés en A3. Mai vu la taille des éléments ça resterais lisible en A4.

J'avais une partie de la réponse sous mes yeux (pour l'utilisation que j'ai de la tempo sus-cité) :
https://zupimages.net/up/21/27/fyxs.png

Par contre la question est toujours ouverte dans le cas général (en utilisant l'entrée de réglage de la durée et la suspension de tempo)

Effectivement, je n’avais pas vu que le nom des éléments de la collection apparait à cet endroit.

Du coup il ne reste que la question de l’ascenseur qui permettra également de décaler l’indentation desdits éléments pour libérer encore plus de place.

(Re)Bonjour,

J'ai une question toute bête mais y a-t-il une façon normalisée de représenter une tempo avec un commande externe ? Par exemple la tempo RE7RM11BU de chez Schneider lorsque l'on utilise des entrées Y1 et X1 ?

Cordialement

Bonjour,

Lorsque l’on travaille sur un petit écran et que l’on se retrouve à «écraser» le panneau des collections pour libérer de la place pour le schéma, le nom des éléments se retrouve partiellement mangé par le bord de la fenêtre. Y a-t-il la possibilité :
1 – De faire un retour à la ligne pour les éléments qui ont un nom à rallonge
2 – D’ajouter ce nom à l’infobulle qui apparaît lorsque l’on passe le curseur sur l’élément
3 – D’ajouter un ascenseur horizontal lorsque le nom ne peut s’afficher entièrement

Cordialement

Bonjour,
À propos du temps de chargement (particulièrement sous Windows): Ne serait-il pas intéressant de mettre les collections de base (élec, logique, hydro...) dans des fichiers zip (ou autre format de stockage) ? Cela permettrait de diminuer drastiquement le nombre de fichiers à ouvrir sur le disque.
Quant au niveau de compression, le mode "stoker" ou "le plus rapide" me semble approprié pour ce type d'utilisation (chargement le plus rapide possible). Après il faut voir le compromis temps de lecture / temps de décompression. Mais, vu l'énorme taux de compression des fichiers texte (et surtout du XML), y compris en mode "le plus rapide", je pense que ce c'est le niveau de compression qu'il faudra retenir.

Bonjour,

Comment faire pour permettre d'utiliser les références croisées avec les disjoncteurs moteur ? Suffit-il d'ajouter link_type="master" à la balise <definition> des fichier *elmt ou y a t-il d'autre manipulations à faire ?

Au passage, j'ai vu que la balise <informations> contient un lien vers une page 404.

<informations>Author: The QElectroTech team
License: see http://qelectrotech.org/wiki/doc/elements_license</informations>

Quelle est la bonne/nouvelle adresse de cette page ? (histoire de le mettre à jour)

Cordialement

Merci. Du coup voici mon premier rapport de bug de l'année : https://qelectrotech.org/bugtracker/view.php?id=179

Bonjour et bonne année,

Dans quelle langue faut-il rédiger les rapports de bugs sur le BugTracker ? On peut le faire en français ou il faut le faire en angliche ?

Bonjour,

I. Contexte
Si j'ai bien compris le message de scorpio810 du 2016-04-23 00:46:40 on peut considérer qu'il y a cinq [s]niveaux[/s] portées de variables :

  1. Variables globales communes à tous les projets. Ce sont des variables qui servent à initialiser les variables des nouveaux projets. Elles sont enregistrées dans les préférences de QET et sont copiées dans les propriétés de chaque nouveau projet.

  2. Variables spécifiques à un projet. Ce sont des variables valide pour l'ensemble des folios du projet (du fichier .qet). Elles correspondent principalement au nom de l'installation, du client, à la date du projet, etc. Elles sont enregistrées dans les propriétés du projet

  3. Variables spécifiques à un ensemble de folios. Ce sont des variables communes à un ensemble de folios regroupé par selon un certain critère (type de folio, fonctionnalité, sous-ensemble de l'installation, etc). Ce "groupe" de folios pouvant très bien n'être composé que d'un seul folio. Ces variables n'ont pas d'emplacement spécifique et sont donc dupliquées dans chaque folio. (J'y reviens plus tard)

  4. Variables spécifiques à un folio. On y retrouve essentiellement les dimensions, le nom et le numéro de chaque folio. Elles sont accessibles dans les propriétés du folio.

  5. Variables spécifiques à un composant du folio. Tout ce qui décrit chaque élément / conducteur. Elles sont accessibles dans le menu "Éditer l'élément" / "Éditer de connecteur"

Pour le fonctionnement de ces différents niveaux, voici ce que je m'imagine (je n'ai pas vérifié le fonctionnement de QET):
Rien n'empêche, à priori, la déclaration d'une même variables dans deux niveaux différents. Cela permet d'avoir (par exemple) une variable commune à tout le projet mais pouvant être redéfinie pour certains folios.
On peut faire ça facilement en cherchant la variable dans les variables du composant puis du folio etc jusque aux variables du projet. Si jamais on ne trouve toujours pas la variable mais qu'elle existe dans les variables globales définies dans les préférences de QET, on peut alors proposer de l'importer dans les propriétés du projet.

II) Ma proposition
Revenons en maintenant aux "Variables spécifiques à un ensemble de folios". Comme précisé plus haut, ces variables n'ont, à ma connaissance, pas d'emplacement spécifiques pour les enregistrer. Pour cela, je pense qu'il pourrait être intéressant de créer ce qui peut s'apparenter à des "dossiers de folios". Chaque "dossier" pouvant (re-)définir ses propres variables. Les variables définies dans un dossier devant être accessibles à tous les folios situés dans ledit dossier.
Les "dossiers" correspondant alors à des sous-ensembles, il serait alors intéressant de pouvoir les imbriquer pour créer des sous-sous-ensembles.

III) Subtilités techniques (part-ce que le diable se cache dans les détails)
Comme on doit pourvoir réorganiser les folios d'un projet, certaines considérations doivent être prises en compte. En effet, changer un folio de "dossier" pourrait avoir des conséquences non voulues.

Postulats pour la suite :

  • Les dossier pouvant être imbriqués les uns dans les autres, on peut considérer le projet dans sa globalité comme étant un dossier englobant tout le reste à la manière de "/" dans les arborescences UNIX et dérivées. Les variables pouvant alors être assimilées aux droits d'accès des fichiers.

  • Lorsque je considère un dossier ayant une valeur (de variable) "différente", j'inclus les dossiers pour lesquels la valeur disponible est différente ET les dossiers dans lesquelles la variable n'est pas disponible.

À chaque changement de dossier il faudra, pour chaque variable utilisée par le folio, vérifier les points suivants :

  • Est-ce que, pour la variable, le dossier de destination possède une valeur différente du dossier source ?

  • Est-ce que, pour la valeur de la variable, le dossier de destination possède une autre variable ayant la même valeur ? (Attention à la casse et aux espaces invisibles)

Si la réponse est "oui" à l'une de ces questions il faudra, selon le cas, demander à l'utilisateur s'il souhaite copier la variable dans le folio, créer/écraser la variable dans le dossier de destination, modifier la variable utilisée ou ne pas toucher aux variables.

Bonjour,
Cette façon de faire à l'air intéressante mais comment cela se passe t-il lorsque on veut faire la connexion d'éléments multifilaires ? Par exemple pour relier plusieurs disjoncteurs en parallèle...