L’échange de données sur les conditions technologiques d'usinage

Ce soir on m’a posé une question via un Email sur l’échange de fichier et la récupération des données de coupe. J’ai répondu avec un courrier assez long qui m‘a aussi amené à commencer à structurer une réponse qui pourrait parfaitement trouver sa place dans ce Blog. Aussi j’ai décidé de reprendre ces points pour ouvrir une nouvelle discussion.

Une des problématiques qui se pose aujourd'hui est la multitude de données et de format déjà utilisé dans les entreprises pour la gestion des outils coupants (CFAO, logiciels de simulation, logiciels de gestion d'outils …) et son utilisation dans les différentes solutions de la chaine numérique.

Quel est l’intérêt de la relecture des formats outils

Avoir un lien avec la ou les fao de l’entreprise est de mon point de vue effectivement un atout pour une solution d’organisation, de méthode, surtout dans le cas d'une petite structure qui a par nature tendance à multiplier les solutions les plus efficaces contrairement à la grosse structure qui pourra s’offrir la solution global ( s’offrir étant le mot qui correspond le mieux à la situation ). Un produit capable d'ébaucher un devis chiffré sur la base d'une gamme, puis de transposer cette gamme vers la FAO pour l'enrichir et par la suite réintégrer ces modifications pour enrichir les données et méthodes aurait de mon point de vue  un atout indéniable. J'ai pas mal bossé la question, commencé quelques maquettes de dev, mais j'ai lâché l'affaire devant la montagne de problème.

Cette vision idéale s'oppose à deux logiques : La première, les solutions que je connais sont surtout dédié à un deviseur ou homme méthode de métier dont c'est le principal travail. Le lien avec la suite n'est dans ce cas pas sa priorité. De même je cherche encore une solution pour établir des gammes qui ne soit pas la solution CFAO elle-même. On le voit donc nous sommes dans un des maillons de la chaine numérique qui n’est pas encore très fournis (Mais y-a-t-il un réel marché ?)

La deuxième, est d'intégrer ces données avec X solutions du marché qui ont toutes leurs spécificités et surtout dont l'ouverture vers l'extérieur n'est là aussi pas leur principale caractéristique.

VisuOutil était à la base une des briques pour ce type de projet. L'objectif est de renseigner la / les FAO de la société à partir d’une même base et de récupérer les données pour les transférer d’un logiciel à l’autre sans recréer le données manuellement, mais  aussi d'administrer et analyser les conditions et outils utilisés dans la société au travers de l'analyse de la base des données existantes de l'entreprise. Sur le point de l'interfaçage géométrique pas de problème, sur le point qui nous intéresse le plus (les conditions d'usinage c'est plus complexe).
 Comme vous pourrez le voir sur une matière prise au hasard dans une base réelle (Le hasard faisant bien les choses j'ai choisi l’aluminium) on voit que les conditions de coupe varies de 12 m/min à 800 m/min et les avance de 0.01 à 0.6 mm (Figure 1). Ceci en fonction de la machine utilisé, des outils, des longueurs sorties, des revêtements, des opérations. Tout ceci fait qu'il est difficile de capitaliser de manière Macro sur l'usinage.

Figure 1 Analyse des conditions pour une matière dans VisuOutil

L'automatisation doit donc passer par une analyse et une capitalisation fine adaptée à chaque situation. 

Avant de traiter les outils, la partie Feature (forme technologique) et NC Job (Opérations) est aussi une source d'information plus intéressante pour capitaliser les savoir-faire de l’entreprise, d'autant que pour certains Logiciel les conditions d'usinage sont généré sur la partie opération et pas dans la partie outil.

Comment aborder la  problématique d'interfaçage,

Comment traiter ces fichiers ? Pour moi j'applique toujours la même méthode en 5 points :

•  Première étape traiter la relecture du format à partir de quelques exemples sur un logiciel que l’on maitrise (Je suis parti dans mon cas de Tebis qui est aussi le format de mon point de vue le plus évolué et complet que j'ai traité), par analogie il ensuite assez facile de traiter un format car globalement ils ont tous les mêmes paramètres, C’est comme pour la FAO, ils font sur le papier tous les mêmes choses de manière plus ou moins simple avec plus ou moins de possibilité et des domaines de prédilection. Passer de l’un à l’autre c’est surtout savoir ce que l’on veut faire et trouver où se situe le bouton.
• Deuxième étape : essayer de trouver d'autres exemples pour consolider la partie Import.
• Troisième étape : pour l'export utiliser la partie Import de son logiciel pour tester une première version Alpha. Si l’on n’est pas capable de relire parfaitement ce que l'on écrit la suite est vouée à l'échec.
• Quatrième point tester la relecture vers le logiciel FAO d'origine. Sur ce point il devient impératif d'avoir une version du logiciel à disposition pour tester la relecture. Ce travail ne peut pas être fait à distance. Mon expérience m'a appris que les formats d'échange sur ce type de données sont peu robustes. Comme il n'y a pas beaucoup d'échange entre logiciel souvent le développeur traite son format en lecture et écriture sans se confronter aux autres. Il suffit donc parfois qu'une virgule change pour que la relecture plante ou ne donne pas de bon résultat. (J'ai l'exemple tous les soirs en ce moment)
• Enfin 5ème point consolider les interfaces en lecture et écriture avec la solution CFAO. Encore une fois cela ne peut se faire qu'avec l'accès libre à la solution pour faire ses tests.

Bien évidemment si l‘on a une documentation sur le format c’est un plus. Mais comme c’est toujours très confidentiel un document de ce type n’est jamais à  disposition du public.

Où vous trouver les informations sur les formats d'échange  ?

Pour les formats des FAOs c'est pour ma part une collecte de plus de 7 ans maintenant sur le net, avec des contacts qui ont bien voulu m'envoyer des exemples.   J'ai aussi été amené ces dernières années à utilisé  6 logiciels de FAO/simulation différents ce qui me fait déjà une bonne base.

Pour ceux qui voudrait se lancer dans le même type de travail je conseillerai d'éviter de partir sur des formats utilisé pour la simulation (Vericut; NCsimul …) ce sont à l'inverse de ce que l'on peut penser au départ les plus pauvres sur la parties données technologique. D'une part ces solutions n'ont pas pour vocation de définir des conditions puisqu’ils sont surtout là pour contrôler, simuler les avances et les trajectoires données par un programme ISO. Donc la notion de conditions d'usinage est assez absente chez eux. De même sur la diversité des outils on reste très basique, un seul type générique de type "Forme libre" permet de redéfinir l'outil pour le simuler, à partir de là les éditeurs n'ont pas besoins de gérer 40 types d'outils différents. Pas besoin non plus de gérer des types complexes  pour les associer à des opérations. Ce ne serait donc pas sur ces formats que je partirai en premier.

Au contraire une solution FAO en pointe sur l’automatisation est plutôt à rechercher car forcément qui dit automatisation dit nécessité d’avoir un maximum d’informations sur les types d’outils, la géométrie, les conditions et les règles à récupérer et à appliquer. De même on peut penser  que la solution qui va vers l’automatisation va poursuivre sa démarche d’intégration totale en liant sont application avec des solutions de mesure d’outil, d’organisation de simulation, etc. Donc va développer ses solutions d’échanges.

Peut-être l’occasion de développer les solutions qui correspondent à ce point dans un futur article.