Pourquoi la génération de code peut-elle être sûre sortie de CFAO sans requérir les mêmes obligations que la simulation ?

Lors d’une discussion sur la simulation d’usinage autour de l’adéquation entre simulation et réalité j’ai eu un commentaire qui disait « Pour être vraiment "WYSIWYG" (What You See Is What You Get) : Ce que tu vois c’est ce que tu as (CQTVCQTA) lors de la simulation d’usinage, par un logiciel de FAO, il doit te permettre une description complète de la cinématique machine-outil et devrait également te permettre de construire le modèle virtuel du contrôleur CNC de la machine-outil.

Ce commentaire m’a amené à me poser la question de savoir si cette assertion était vraie. Pour ma part je pense que ceci n’est pas exact. La première partie est juste :

Une description complète de la cinématique machine-outil

Effectivement seule une description complète de la cinématique de la machine permet d’assurer une fiabilisation du code généré. Cette description doit couvrir selon les risques potentiels aussi les périphériques machine tel que le changeur d’outil, la mesure embarquée des outils, tous éléments en mouvements susceptible de générer une collision avec eux ou avec l’outil (Figure 1).

Figure 1 Simulation palettisation/ changeur dans FAO

De plus le calcul du code et des trajectoires doit prendre en compte le calcul des axes rotatifs (Figure 2) et des limites machine. La Fao doit bien évidement simuler les phases liées aux mouvements interopérations (mouvements réalisés par la machine entre deux parcours outils) et les déplacements nécessaires aux changements d’outil ou à la mesure des outils.

Construire le modèle virtuel du contrôleur CNC de la machine-outil

La deuxième partie est de mon point de vue fausse. Vérifier un code Iso n’est pas équivalent à générer ce code.

La simulation dans la FAO n’a pas pour objectif d’obtenir une simulation des temps d’usinage très proche de la réalité. Dans ces conditions il est n’est pas nécessaire d’avoir les paramètres d’accélération de la machine ou de contrôle du Jerk. Cet argument employé par certains éditeurs qui mettent en avant l’intégration du Kernel (Noyau) de la CN (notamment en ce qui concerne la CN 840D de siemens : http://www.cgtech.fr/products/about-vericut/vnck/ ) dans leur propre logiciel demande encore à être validé. A ce jour je n’ai encore jamais vu une étude sur un cas industriel démontrant :

1)    La capacité à réellement intégrer la cinématique machine

2)    L’adéquation entre simulation et temps réels. La dynamique ne peut de mon point de vue être uniquement obtenue par les paramètres de réglage de la CN. Ceci peut permettre de maitriser les lois de commande qui régissent le pilotage de la machine. Mais en l’absence de composants réels derrière ces lois de commande le résultat ne peut être totalement conforme à la réalité.

Figure 2 Simulation machine Tebis

La simulation d’un code iso nécessite effectivement de pouvoir prendre en compte tous les cas de figure. Le nombre des instructions disponibles et de combinaison entre eux, dans une CN moderne génèrent une complexité importante de traitement.

Dans le cas de la génération du code on va se limiter à une infime partie du code disponible et des combinaisons possibles (Figure 3). Le logiciel va avant tout simuler son propre code interne. La prochaine étape sera de traduire ce code interne en instructions CN conforme à la simulation FAO. Ceci est possible à partir du moment où le code interne et les coordonnées calculés ne diffère pas du code généré. Autrement dit si votre solution FAO passe encore par un format neutre de type APT où l’orientation outil est donné sous forme vectoriel ou si le postprocesseur est une application externe il peut probable voir impossible que la simulation FAO soit sûre et conforme au résultat machine.

Sinon, les capacités des CNs modernes permettent de remplir cet objectif. Le travail est alors d’écrire en Code G les mouvements calculé et simulé dans la FAO.

Figure 3 Utilisation possibilité d’une CN

Nous ne sommes donc pas dans le schéma « Simulation du code ISO » avec toute sa complexité mais : écriture d’un code connue et limitée. Je ne sous-estime pas le travail à réaliser par l’intégrateur pour la génération d’un code mais ceci ne relève pas d’une complexité mathématique combinatoire tel que l’obtention d’un code fiable reproduisant le comportement CFAO ne soit pas atteignable, l’utilisation d’une méthodologie simple permettra de s’assurer de l’équivalence des comportements.

Prétendre le contraire c’est au mieux, la méconnaissance des capacités des FAO et CN moderne. Au pire c’est une mauvaise fois commerciale justifiant la nécessité ou l’impossibilité de réaliser ce travail.

Exemple de modification d’une instruction : Dans le cas d’une CN Heidenhain l’usinage 3+2 sur machine 5 axes se fait en utilisant une instruction appelé PLANE SPATIAL (Figure 4). Normalement l’instruction devrait s’écrire :

PLANE SPATIAL SPA+0 SPB+0 SPC+0 MOVE SEQ- TABLE ROT 

Le MOVE signifie que la CN va calculer les axes rotatifs et mettre la machine en position. Avec cette écriture il est possible que la CN calcul un angle différent de la FAO et que le mouvement de mise en position diffère là aussi de ce qui est définie dans la FAO. Dans ce cas on préfèrera une écriture sous la forme :

PLANE SPATIAL SPA+0 SPB+0 SPC+0 STAY SEQ- TABLE ROT

L B+Q121 C+Q122 R0 F5000

Le code STAY signifiant que la machine ne doit pas bouger. Les variables Q121 et Q122 stockant le calcul des angles machine par la CN. Au besoin ces angles peuvent être comparés aux angles FAO pour assurer la conformité de la mise en position on pourra alors si nécessaire corriger le calcul en jouant sur le paramètre SEQ-, voire mieux selon le calcul de la FAO utiliser directement une instruction SEQ- ou SEQ+ pour avoir directement le résultat conforme.

On pourra aussi augmenter le contrôle de la CN en ajoutant une instruction M134 qui indique à la CN un Positionnement avec précision.

Dans cette écriture on va activer le plan incliné et la mise en position sera réalisé dans une séquence suivante à une vitesse définit pour éviter les problèmes de gestion des dynamique sur les axes. Dans ce cas la simulation sera conforme entre FAO et comportement machine.

Figure 4 Instruction PLANE SPATIAL d’Heidenhain

On pourrait ainsi multiplier les exemples pour illustrer mon propos.

Par ce fonctionnement on inverse la problématique de simulation par une problématique de pilotage conforme à la FAO. Ce n’est plus la simulation et la FAO qui doivent intégrer les caractéristiques de la CN (donc être capable d’intégrer le modèle virtuel du contrôleur CNC de la machine-outil) mais c’est la CN qui doit exécuter les ordres données. Ce qui est en soit la fonction principale que l’on demande à la machine.