Simulation

Pour être efficace une simulation doit pouvoir reprendre les éléments nécessaires à la simulation :

• La parcours,
• La géométrie de la machine,
• L'assemblage de l'outil et l'outil,
• Les bridages,
• Les cycles machines.

Image Vericut

Si l'on prend des logiciels comme NcSimul ou Vericut qui sont avant tout des logiciels de simulation. Ils permettent de valider un code ISO. Mais pour cela il faut aussi pouvoir reproduire les conditions les plus proches de la réalité pour être vraiment efficace.  Donc avoir la configuration de sa machine, la bibliothèque des porte-outils , la position de la pièce sur la machine, les éléments de bridage.   Si vous avez une interface directe entre le logiciel de FAO et le logiciel de simulation cela permet de transmettre des infos sans avoir à tout configurer manuellement l'environnement machine.
Mais pour être efficace cela veux dire que l'organisation de l'atelier doit être maitrisée. Et Si ces aspects le sont alors les besoins dans une solution de simulation sont moins nécessaire avec les améliorations apportés au solutions de simulation machine dans le logiciel de CFAO.  Le point important reste le point  du postprocesseur de sa fiabilité.
Dans des cas plus complexes que la simulation d'un simple environnement machine la solution de simulation peut être intéressante. Dans un cas d'utilisation simple (parcours 3 axes, bridage en étau ou par plateau magnétique ...) L'évolution des logiciels de CFAO a par l'intégration de ces éléments directement au niveau de la simulation rendu ces outils moins intéressant.

Dans tous les cas ce que je conseil c'est la disponibilité d'une interface directe entre la CFAO et la simulation.

APT comme inadAPTé

  J'ai souvent eu l'occasion de dire tout le mal que je pensais des solutions utilisant le code APT comme interface de sortie des parcours outils. La norme APT est un vieux système que nous ne retrouvons que sur des systèmes Catia, NX, ProE. Les nouvelles génération de système CFAO ont leur propre postprocesseur. Il n'y a donc plus d'utilisation d'un autre système complémentaire. De même aujourd'hui sur les FAO les plus en pointe : PowerMill, Tebis , TopSolid, WorKNC ... L’intégration de la machine est maintenant la base du processus de calcul des parcours. Le calcul des parcours est donc directement lié à la machine. Ainsi en choisissant une machine on a directement la géométrie des outils, les conditions de coupe définis pour la machine la gestion des numéros outils, des outils frère, etc. http://www.tebis.com/cms/index.php?id=45&L=3 

Machine Simulateur (Image Tebis)

La FAO calcul aussi directement les cordonnées XYZ et les angles A/C B/C. Ceci permet d'avoir une simulation assez proche de la réalité ce qui élimine le recours à des solutions de vérification. L'on peut aussi gérer les limites angulaires de la machine dans la FAO. Comme on peut le voir par exemple avec la solution de Tebis : http://www.youtube.com/watch?v=cL9QzQNy6Uw 

 L'on peut aussi améliorer la qualité des parcours 5 axes en gérant la variation angulaire sur les axes rotatifs et pas uniquement sur la notion de variation du vectoriel. Ceci permet par exemple le calcul comme la Redistribution de points angulaires. La redistribution de points angulaires permet à l’utilisateur de contrôler l’angle maximum toléré par l’outil entre deux points. Bénéfices : 

• Idéale pour les changements rapide d’angle sur les courtes distances.
• Améliore l’état de surface pour une meilleure qualité de pièce.
• Lissage des avances machines afin d’augmenter la durée de vie.

Cette évolution permet d'apporter de nouvelle stratégie comme par exemple le polar Milling : http://www.delcam.tv/pm2012/lz/fr/videos/video-Polar.html 

 Si cette stratégie existait dans un système utilisant une notation APT, le code donnerait toujours une sortie X,Y,Z, 0,0,1 pour le vecteur outil. Difficile avec ces infos de convertir en une sortie calculant l'axe C. Autre limite de l'APT. Dans certains système il est possible d'activer le calcul de la normal de contact (PowerMill) ainsi le logiciel permet d'utiliser des fonctions de compensation 3D pour gérer par exemple une correction d'usure d'outil. Pour cela je dois avoir les informations sur U,V,W de la normal de contact qui n'existe pas dans l'APT. L'avenir est donc résolument de mon point de vue à l'intégration du contexte machine est d'un lien de plus en plus fort avec le contexte machine pour le calcul de parcours. Les derniers développement de l'éditeur Delcam avec son concept de machine ADN : http://www.vortexmachining.com/machinedna/index.asp.

Machine DNA (Image DELCAM) 

Les derniers communiqués de presse de MORI SEIKI/DMG concernant la solution de post-processeur Manufacturing Suite de DMG MORI SEIKI. http://www.moriseiki.fr/2013/07/le-post-processeur-manufacturing-suite-de-dmg-mori-seiki-rend-superflues-les-solutions-definies-par-lutilisateur/ 

 MORI-APT (Image Mori Seiki/ DMG)

Cette solution me semble donc aller à contre-courant. En effet pour les différentes raisons indiqués précédemment, je pense que la sortie APT est une limitation à l'évolution des solutions de programmation. Comme autre argument je reprendrai aussi une demande récurrente des industriels aujourd'hui qui est de pouvoir gérer les modifications apportées à la programmation au travers de la chaine numérique. Un des principaux problèmes est de pouvoir remonter les modifications intervenues lors de la programmation des pièces. Il est commun que le régleur soit obligé de modifier un programme pour adapter les conditions théoriques à la réalité de l'atelier. Ces modifications réalisées sur la machine sont difficile à remonter dans la partie FAO pour assurer la traçabilité des modifications et garantir la validité des parcours dans les futurs évolutions des produits. En rajoutant un maillon à la chaine on rique encore de complexifier ce travail.

 Et vous quel est votre avis sur ce sujet ?

Code Siemens840D avancée utilisation d'une MACRO personnalisée

Voici un petit exemple de code pour CN Siemens sur l'utilisation des variables et de macros.  Le code de cet article permet d’illustrer la relecture et la modification de variables concernant les longueurs de l’outil. Le code permet aussi d’illustrer l’appel de MACRO avec passage de paramètre et la déclaration de variable. Rajouter le code suivant dans un fichier Test.mpf

T=”Boule10” D1

M6

G00 G90 G17 G94

G54

CORRECTEUR(-0.02) ;MACRO PERSO

M30

...

Dans un fichier CORRECTEUR.SPF stocké dans le repertoire des sous-programmes de la cn rajoutez le code suivant :

PROC CORRECTEUR(REAL PARAM1)

DEF REAL PARAM2

PARAM2=$P_TOOLNO ; Recuperation numero d’outil actif

$TC_DP3[PARAM2,1]=$TC_DP3[PARAM2,1]+PARAM1

IF $TC_DP3[PARAM2,1]<=0 GOTOF ALARM1

GOTOF END

ALARM1:MSG("LONGUEUR OUTIL NULLE")

STOPRE

M00

GOTOB ALARM1

END:

M17

On utilise dans l'exemple ci-dessus la variable  :

$ TC_DP3[PARAM2,1]=Variables liées à la longueur de l’outil actif pour le correcteur 1.

Si la longueur de l’outil est inférieure à zéro le sous-programme affiche un message lié à l’erreur.

Code Siemens utilisation des variables d'origine

Voici un petit exemple de code pour CN Siemens sur l'utilisation des variables.  Le code de cet article permet d’illustrer la relecture et la modification de variables concernant les origines. Rajouter le code suivant dans un fichier Test.mpf

G54

MSG("Origine :"<<$P_UIFRNUM) ; 1=G54 ,2=G55 etc

M00

;COPIE DEC G54 DANS G55

$P_UIFR[2,Z,TR]=$P_UIFR[1,Z,TR]

$P_UIFR[2,C,TR]=$P_UIFR[1,C,TR]

;MISE A ZERO G55 X Y

$P_UIFR[2,X,TR]=0

$P_UIFR[2,Y,TR]=0

M02

On utilise dans l'exemple ci-dessus les variables  :

$P_UIFR[2,Z,TR] =Variables liées à l'origine G55 (2=G55)

$P_UIFRNUM = Origine active avec comme retour  1=G54 ,2=G55 etc

Le programme affiche via la fonction MSG l’origine active, la deuxième partie du code copie des valeurs de l’origine G54 dans l’origine G55. Enfin les dernières lignes mettent la valeur des décalages de X et Y pour G55 à Zéro.

Code Siemens 840D

Voici un petit exemple de code pour CN Siemens sur l'utilisation des variables.  Le code de cet article permet d’illustrer la relecture et la modification de variables concernant les outils. Rajouter le code suivant dans un fichier Test.mpf

MSG("Nom Outil :"<<$TC_TP2[1])
M00
MSG("Longueur outil :"<<$TC_DP3[1,1])  ; Longueur outil
M00
$TC_DP3[1,1]=66 ; Modification de la longueur
MSG("Longueur outil :"<<$TC_DP3[1,1]) ; Relecture de la longueur outil
M00
MSG("Rayon outil :"<<$TC_DP6[1,1]) ; Rayon outil
M00
M02

Sur l'exemple ci dessus les variables  :


$TC_TP2[1] = Nom de l'outil N°1
$TC_DP3[1,1]= Longueur de l'outil 1 pour le correcteur D1
$TC_DP6[1,1]= Rayon de l'outil 1 pour le correcteur D1


Le programme affiche via la fonction MSG des informations récupérées dans l'IHM du pupitre.