10 bonnes pratiques pour DriveWorks Pro (partie 1)

Pour progresser dans l’utilisation d’un logiciel, il y a 2 possibilités :

• Apprendre par soi-même : de ses essais ou erreurs quand on s’en est rendu compte
• Apprendre des autres : de leurs essais, erreurs, conseils ou bien sûr par une formation

Nous vous proposons 10 bonnes pratiques (en 2 parties) issues de notre expérience, et indirectement de celle de tous nos clients utilisant la solution DriveWorks depuis plus de 15 ans. Les outils DriveWorks suivent une philosophie très similaire aux produits Dassault Systèmes SOLIDWORKS. Ils sont donc extrêmement souples et laissent à l’utilisateur une très grande liberté.Comme souvent, lorsqu’on est libre, rien ne nous empêche de faire des choix qui peuvent être inadaptés et finalement avoir des inconvénients majeurs qui n’avaient pas été anticipés.

Ces 10 bonnes pratiques vous éviteront de perdre du temps en commettant à votre tour les erreurs que d’autres ont déjà expérimentées et solutionnées pour vous ! Voici les 5 premières bonnes pratiques (la suite vous sera proposée prochainement). 

1. structure de fichiers recommandée

S’il est possible d’organiser librement les fichiers qui composent un groupe DriveWorks, certains choix pourraient être préjudiciables.

Pour commencer, il y a 2 types de groupes : individuels (Individual) et partagés (Shared)

• Un groupe individuel est prévu pour une utilisation par un seul utilisateur ou module à la fois.
• Dès que des actions doivent s’exécuter simultanément ou que plusieurs utilisateurs ou modules doivent pouvoir utiliser les projets (configurateurs) d’un groupe, il est préférable d’utiliser un groupe partagé.
• Il est évidemment possible de convertir un groupe individuel en un groupe partagé à tout moment.
• Dans un groupe individuel, les données du groupe sont stockées dans un fichier unique au format « .drivegroup »
• C’est l’utilisation d’un fichier unique qui limite l’utilisation par plusieurs modules ou utilisateurs.

Pour lever cette limitation, les groupes partagés stockent leurs informations dans une base de données sur un server Microsoft SQL.

En plus de ces données, d’autres fichiers sont nécessaires au fonctionnement des configurateurs.

Tous ces fichiers devront idéalement être stockés et organisés dans le dossier du groupe DriveWorks de la manière suivante :

Le respect de cette structure vous assurera de pouvoir utiliser l’ensemble des outils de gestions de données de DriveWorks (DriveWorks Data Management Tools).

Si vous décidez de modifier cette structure (exemple : sauver vos projets directement dans le dossier du groupe), certains de ces outils pourront ne pas fonctionner correctement.

Les fichiers de production (SOLIDWORKS, Word, Excel, etc.), qui seront générés par DriveWorks lors de l’utilisation des configurateurs, peuvent, bien entendu, être stockés où vous voulez, indépendamment de cette structure si nécessaire. 

Comment utiliser les outils de diagnostic de DriveWorkd Pro ?

2. Le dossier Specifications

Lors de la création d’une nouvelle spécification, DriveWorks stocke systématiquement une copie du projet utilisé ainsi que les données saisies par l’utilisateur. Afin de pouvoir rééditer ou traiter cette spécification par la suite, ces données doivent pouvoir être retrouvées sans risques de perte ou de conflit.

C’est dans le dossier Specifications contenu dans le dossier d’un groupe DriveWorks que seront stockées ces données internes à DriveWorks.

Pour éviter toute perte ou conflit de données, chaque Spécification doit avoir un identifiant unique et doit stocker ces informations dans un sous dossier du dossier Specifications, nommé en utilisant cet identifiant.

Les Child Specifications sont également concernées par cette nécessité de référence unique. Même si elles ne peuvent pas être ouvertes sans leur projet parent, elles sont également nommées avec un identifiant unique. Elles ont la particularité de ne pas générer de fichiers de données car ces informations sont encapsulées dans les fichiers de leur spécification parente.

Par défaut, chaque groupe DriveWorks dispose d’un compteur (SpecificationID). Il est utilisé comme identifiant unique pour toute nouvelle spécification.

S’il est possible de personnaliser le nom (Specification Name) et l’emplacement (Specification Path) de ces fichiers internes à DriveWorks, il faut impérativement s’assurer de l’unicité du nom et de l’emplacement de ces données pour chaque spécification.

Il est donc souvent plus simple de ne pas modifier ces paramètres.

• Pourquoi pourrait-on être tenté de modifier ces paramètres ? Et que risque-t-on ?

Dans un projet, tant que l’on n’aura pas personnalisé les règles par défaut, tous les fichiers que l’on prévoit de générer avec DriveWorks (pièces, assemblages, mises en plan, PDF, Word…) seront stockés en utilisant le nom unique de la spécification ainsi que l’emplacement des données internes de DriveWorks.

Lorsque l’on souhaite générer les fichiers SOLIDWORKS dans un dossier d’affaires sur le serveur de fichiers de l’entreprise, il est donc très tentant de modifier le dossier Specifications du groupe DriveWorks pour qu’il pointe vers ce dossier d’affaire. Ainsi, tous les fichiers générés par DriveWorks seront par défaut sauvés dans cet emplacement. Mais en procédant ainsi, les fichiers internes de DriveWorks le seront aussi.

La seule personnalisation de l’emplacement ne gênera qu’en cas de maintenance (per exemple pour supprimer les spécifications obsolètes).
Cependant, en plaçant les dossiers de spécifications dans un dossier d’affaire, la tentation est encore plus grande d’en profiter pour nommer ces dossiers en reprenant les standards en place dans l’entreprise. Et c’est ce nommage qui ne permet souvent pas l’unicité du nom de la spécification.

Parmi les cas courants, notons :

• Un dossier par client. Plusieurs spécifications peuvent alors se retrouver dans le même dossier. Les fichiers internes de DriveWorks étant nommés par le nom du projet utilisé, la seconde spécification écrasera la précédente.
• Un dossier par affaire, alors qu’une affaire peut nécessiter le lancement de plusieurs configurateurs et donc la création de plusieurs spécifications. Les fichiers internes de DriveWorks étant nommés par le nom du projet utilisé, la seconde spécification écrasera la précédente.
• Le stockage des dossiers d’affaires dans un coffre SOLIDWORKS PDM. Les fichiers internes de DriveWorks ne sont pas prévus pour être stockés dans un coffre SOLIDWORKS PDM. Si cela est techniquement possible, ce n’est pas recommandé en raison des opérations manuelles nécessaires pour que cela fonctionne (voir la section relative aux fichiers Group et Project sur la page relative à SOLIDWORKS PDM dans la documentation de DriveWorks).

En cas de conflit ou perte de ces fichiers internes pour une spécification donnée, ses transitions et opérations deviendront alors indisponibles et la spécification ne sera plus éditable. Il ne faut donc pas procéder de cette façon !

A la place, nous vous conseillons de modifier les règles qui pilotent le nom et l’emplacement des fichiers à générer sans altérer les paramètres de ce dossier Specifications interne à DriveWorks. 

3. les numéros de colonne des tables

S’il est évident qu’il faut nommer correctement une table, on oublie souvent qu’il faut en nommer correctement les colonnes. En effet, si dans DriveWorks on précise une colonne par son numéro d’index dans toutes les fonctions référençant une table, ce n’est pas pour autant une bonne habitude.

La relecture des règles utilisant des numéros de colonnes est complexe :

Qui se rappelle le rôle de la 42^ème colonne d’une table 6 mois après ?

 

De plus, il existe un risque d’erreurs important en cas de réorganisation de la table.
En référençant une colonne par son numéro d’index dans les règles, on court le risque de générer de très nombreuses erreurs dans tout le projet en changeant l’ordre des colonnes d’une table.

Une fonction spécifique existe dans DriveWorks pour éviter ces inconvénients :

• La fonction TableGetColumnIndexByName()
  • Elle permet de retrouver l’index de la colonne d’une table par son nom.
  • Elle peut être utilisée directement dans les fonctions à la place de l’index de la colonne souhaitée.

Cependant, nous vous conseillons une approche plus systématique :

• Nommez toutes les colonnes des tables dans DriveWorks
• Après chaque création de table, créez une catégorie de Variables portant le nom de table (en ajoutant « Table » en préfixe du nom de la catégorie pour clarifier son rôle). Il est également conseillé de regrouper toutes les catégories de ce type dans une catégorie générique « Tables ».
• Créer une règle pour chaque colonne en utilisant la fonction TableGetColumnIndexByName()
  Ces règles seront toutes identiques à l’exception du nom de la table et de celui de la colonne.
  Il serait donc assez simple de les générer dans Excel à partir d’une liste des nom de colonnes.
  Astuce : il est possible de copier une ou plusieurs variables de DriveWorks vers une table Excel (et vis-versa ? )

Si ces opérations peuvent paraître longues à créer par rapport à l’utilisation directe des numéros d’index, ce temps est largement regagné dans la globalité de la vie d’un configurateur.

A chaque relecture d’une règle, il n’y aura plus de confusions ou de temps perdu à retrouver le rôle d’une colonne par son numéro. De plus, puisqu’il permet la réorganisation d’une table sans aucun risque, il participera à rendre vos projets DriveWorks plus robustes.

• Remarque :

En plus de ne pas nommer les colonnes, il ne faut pas placer de valeurs directement à partir de la première ligne d’une table. En effet, la majorité des fonctions relatives aux tables ne liront pas cette ligne puisqu’elle est supposée contenir… les noms de colonnes.

10 fonctions relatives aux textes de DriveWorks Proé

4. Ne jamais réordonner les colonnes d’une table de calcul

Les tables de calculs fonctionnent d’une façon similaire à une feuille de calcul Excel.

Dans la règle de calcul d’une cellule, il est ainsi possible d’utiliser les valeurs des autres cellules de la table en les référençant de manière relative. C’est-à-dire en indiquant la direction et le nombre de cellules séparant la cellule actuelle de celle contenant la valeur voulue.

Exemple de syntaxe d’une référence relative :

• Pour aller chercher la valeur dans la cellule juste à gauche on tapera [1L] (L pour Left).
• Les autres directions seraient « codées » : R=Right, U=Up et D=Down
• Et pour aller chercher la valeur dans la cellule située 3 colonnes plus loin à Droite et 2 cellules plus haut on taperait [3R,2U]

Si cela est très pratique pour créer les règles nécessitant ce type de références, cela peut également se révéler problématique si on envisage de modifier l’ordre des colonnes après l’écriture des règles.

Par exemple, dans une table de trois colonnes : A, B, C et D

• Remarque : La règle de la colonne D s’applique à toute la colonne

Si on réorganise la table pour avoir l’ordre suivant : C, A, B et D

Les valeurs de la colonne D sont alors très différentes

Cela représente un risque d’erreur si on n’est pas conscient de l’existence de cette règle et du danger potentiel de réordonner les colonnes d’une table de calcul.

5. Référencer une table de calcul dans l’une de ses cellules

Dans les tables de calculs, il est possible de référencer une cellule de 2 façons :

• De manière relative : comme nous l’avons évoqué dans le conseil précédent.
• Directement : par le nom de la colonne et le numéro de la ligne

Il y a cependant une différence majeure par rapport à une table Excel qu’il faut connaître !

 

Une cellule de la table de calcul ne peut pas référencer la table en elle-même en dehors des deux types de références citées plus haut.

• Cela exclut donc toutes les fonctions de tables existant dans DriveWorks (vlookup, dwvlookup, listall, etc…).
• Une cellule ou une colonne d’une table de calcul ne peut pas exécuter de fonctions sur cette même table.

Cela s’explique simplement.

• La table de calcul n’existe pas tant que tous les calculs (cellules ou colonnes) ne sont pas terminés.
• Il n’est donc pas possible de demander le contenu de la table pendant qu’elle se calcule.
• Il s’agirait d’une référence cyclique (boucle infinie).

Dans ce cas, il faut simplement utiliser une seconde table de calcul pour interroger la première contenant les données souhaitées.

Il faut cependant garder en tête la complexité de calcul que ces tables peuvent représenter. Si elles contiennent beaucoup de cellules avec des règles complexes, ces tables peuvent assez vite demander beaucoup de ressources. Il convient donc de bien réfléchir à la structure des données pour ne pas multiplier ces règles complexes inutilement (ex : requêtes SQL, imports de fichiers…).

AUTEUR DE L’ARTICLE

Christophe Demuynck, expert technique pour le groupe Visiativ