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.
