jeudi 17 avril 2014

Calcul G02 ou G03 depuis l'APT

Bonsoir,

Suite à une demande sur ma messagerie de Martin, voici comment je calcul le code ISO pour un cercle à partir de l'APT. Voici donc quelques explications sur l'instruction CIRCLE dans l'APT et un exemple de code VB6 pour calculer la direction de l'arc.

Notation de CIRCLE dans l'APT

La notation la plus courante de l'instruction cercle dans l'APT est CIRCLE . Elle donne le point de centre et la normal ainsi que le rayon. Cette normal permet de spécifier le sens de parcours ( G02 ou G03 par exemple pour Z=1 avec un cercle dans le plan G17 ( XY) on aura une interpolation trigo G03 et G02 si Z=-1.

Syntaxe APT
CIRCLE/ XCentre,YCentre,ZCcentre, XNormal,YNormal,ZNormal, Rayon)
GOTO/ XPointFin,YPointFin,ZPointFin



Exemple :
CIRCLE/508.000,762.000,0.000,0.000,0.000,1.000,137.000
GOTO/645.000,762.000,0.000

Autre notation en utilisant INDRIV

L'autre notation reconnue et utilisée par exemple par les sorties de CATIA utilise le code TLON,GOFWD avec la notation INDIRV qui donne le sens de parcours au premier point du cercle. Le vecteur ainsi défini permet de connaitre le sens de parcours G02 / G03.

Syntaxe APT
INDIRV/ x, y, z
TLON,GOFWD/(CIRCLE/ xcentre,ycentre,zcentre,rayon),ON,(LINE/ xcentre,ycentre,zcentre, xPointFin,yPointFin,zPointFin)

Exemple :
INDIRV/ 0.99503, 0.09957, 0.000
TLON,GOFWD/ (CIRCLE/ 16.933, 12.173, 0.000,4.177),ON,(LINE/ 16.933, 12.173, 0.000,20.325, 14.611, 0.000)

Enfin la même notation est aussi traitée si les codes CIRCLE et LINE sont défini en leur affectant une référence (Lx et Cx ) qui sera utilisée dans le code TLON,GOFWD comme dans l'exemple suivant :
C1=CIRCLE/41.6,-1.0681,14.7351,3
L1=LINE/41.6,-1.0681,14.7351,38.6,-1.0681,14.7351
INDIRV/-1,0,0
TLON,GOFWD/C1,ON,L1

Attention dans ce cas la déclaration des commandes CIRCLE et LINE doit se faire avant l'appel par TLON,GOFWD. Il n'est ainsi pas possible de définir en début de code APT toutes les références CIRCLE & LINE.

Autre syntaxe APT déjà rencontré

INDIRV/ x, y, z TLON,GOFWD/(CIRCLE/ xcentre,ycentre,zcentre,rayon), ON, 2,INTOF,(LINE/ xcentre,ycentre,zcentre, xPointFin,yPointFin,zPointFin)


Où :
xcentre, ycentre, zcentre = coordonnées centre arc
xPointFin, yPointFin, zPointFin = Point fin arc
x, y, z = Vecteur de direction INDIRV



Exemple de code VB6 utilisé pour calculer le code G



Option Explicit
'---------------------------------------------------------------------------------------
' Module    : Calcul_cercle
' DateTime  : 05/12/2006 15:08
' Author    : usinage5axes
' Purpose   : Calcul des informations pour sortie circulaires
'---------------------------------------------------------------------------------------

Type INTERPO_CIRCULAIRE
 Code As String                     ' Code sous forme G02 ou G03
 GCode As Integer                   ' valeur du Code G  02 ou 03
 Centre As Point3                   ' Coordonnées point de centre
 Centre_Relatif As Point3           ' Coordonnées point de centre en relatif depuis point de départ pour certaines notation ISO
 P1 As Point3                       ' Point depart
 P2 As Point3                       ' Point millieu dans le cas de définition par 3 points
 P3 As Point3                       ' Point de fin
 Rayon As Double                    ' Rayon du cercle
 Normal As Point3                   ' Vecteur Normal du cercle utilisé pour calculer par exemple G02 ou G03
 Angle As Double                    ' Angle de l'arc de cercle
 Angle_Machine As PosAngulaire      ' Angle des axes rotatifs machine A/B/C pour sortie avec CN acceptant la notation
End Type

'---------------------------------------------------------------------------------------
' Procedure : Calcul_Info_Cercle
' DateTime  : 05/12/2006 15:10
' Author    : usinage5axes
' Purpose   : Avec les infos relues dans le fichier APT (P1, P3 , Point de centre
'---------------------------------------------------------------------------------------
'

Sub Calcul_Info_Cercle(Cercle_Cur As INTERPO_CIRCULAIRE, Optional INDIRV_Vect As Point3)

Dim VectP1 As Point3  ' Vecteur du point de centre au point 1
Dim VectNP1 As Point3 ' Vecteur normal

Dim Po1 As Point3
Dim Po2 As Point3
Dim Po3 As Point3
Dim Angle As Double
      
        ' Se produit si l'on traite une instruction TLON,GOFWD dans ce cas il n'y a pas de notion de normal défini
        ' mais on utilise le vecteur INDIRV

        If Longueur(Cercle_Cur.Normal) = 0 Then
           ' Normal_Plan_Courant = Variable globale de type point défini selon G17/G18/G19
            Cercle_Cur.Normal = Normal_Plan_Courant
        End If
       
        'P1 Point de départ
        'P3 Point de fin


        Po1 = VecSub(Cercle_Cur.P3, Cercle_Cur.P1)
        Po2 = VecteurUnitaire(VecProd(Po1, Cercle_Cur.Normal))
        Po3 = VecteurUnitaire(PointMilieu(Cercle_Cur.P1, Cercle_Cur.P3))
        VectP1 = VecteurUnitaire(VecSub(Cercle_Cur.P1, Cercle_Cur.Centre))
            ' VectNP1 est le vecteur direction calculé au point de départ. il donne normalement le sens Trigo
            ' Comparé avec INDIRV il servira à déterminer G02 ( horaire ) ou G03 (Trigo)

        VectNP1 = VecProd(Cercle_Cur.Normal, VectP1)
           
        ' Calcul de l'angle
        Cercle_Cur.Angle = Angle3Pt(Cercle_Cur.P1, Cercle_Cur.Centre, Cercle_Cur.P3)

                   
        ' Détermine le sens de l'intero circulaire
        If Longueur(INDIRV_Vect) Then ' INDIRV_Vect :  Détermination du sens avec info INDIRV
            If Dot(VectNP1, INDIRV_Vect) < 0 Then
               Cercle_Cur.Code = PP_ARC_R 'G02 ( horaire )
               Cercle_Cur.GCode = 2
               Cercle_Cur.P2 = VecAdd(Cercle_Cur.Centre, Po2, -Cercle_Cur.Rayon)
            Else
               Cercle_Cur.Code = PP_ARC_L ' G03 (Trigo)
               Cercle_Cur.GCode = 3
               Cercle_Cur.P2 = VecAdd(Cercle_Cur.Centre, Po2, Cercle_Cur.Rayon)
            End If
        Else
            ' Notation CERCLE avec vecteur NORMAL pas d'indication du sens de parcours : utilisation de la normal
            If Dot(Cercle_Cur.Normal, Normal_Plan_Courant) < 0 Then
               Cercle_Cur.Code = PP_ARC_R ' G02 ( horaire )
               Cercle_Cur.GCode = 2
               Cercle_Cur.P2 = VecAdd(Cercle_Cur.Centre, Po2, -Cercle_Cur.Rayon)
            Else
               Cercle_Cur.Code = PP_ARC_L ' G03 (Trigo)
               Cercle_Cur.GCode = 3
               Cercle_Cur.P2 = VecAdd(Cercle_Cur.Centre, Po2, Cercle_Cur.Rayon)
            End If
        End If

        Cercle_Cur.Centre_Relatif = VecSub(Cercle_Cur.Centre, Cercle_Cur.P1)
       
        ' Remise à Zéro du vecteur INDIRV_Vect
        INDIRV_Vect.X = 0
        INDIRV_Vect.Y = 0
        INDIRV_Vect.Z = 0
End Sub

mardi 8 avril 2014

ADVEON / NOVO le jeux des 7 différences ?

Les mêmes besoins conduisent aux mêmes résultats :
Interface AdveonTm / NOVOTm
Toujours en cherchant des infos sur le net, j'ai suivi le lien donnée par Sandvik sur la thèse de gestion des outils : Gestion de l'information relative aux outils coupants (Thèse de doctorat) . On y trouve plusieurs informations intéressantes sur les normes liées à la gestion des outils ou sur l'historique des dévellopements sur ce sujet. Mais une chose m'a interpelé. Elle est écrite dans la section "5.4.1 Tool management systems"

"This type of application will benefit from a standard like ISO 13399. The standard will enable users to integrate information from the suppliers regardless of what system they are using. The capabilities of the information coversmost of the areas addressed by the tool management applications.

The capabilities that are covered are:

  • Tools with nominal values (as described by their manufacturer).
  • Matching of components of tools.
  • Assemblies of tools, complete tools.
  • Measured values of physical tools.
  • Location and state of physical tools.
  • Administrative data associated with the management of cutting tools.
There are of course areas which currently fall outside the scope of ISO 13399, such as:
  • Financial information for purchasing purposes.
  • Stock management
"
On y trouve donc ici décrite la vision de l'utilité de ce type de Norme. Mais à aucun moment il n'est fait mention d'un lien avec une solution CFAO de la gestion des conditions d'usinage. C'est comme si la gestion des outils se limitait à acheter des outils à un fournisseur, les mettre à l'atelier en gérant leur assemblages et référence. Au mieux on pourra les mesurer sur des systèmes fournies toujours par le même fournisseur d'outil . Les conditions d'achat ne sont pas dans le périmètre puisque qu'il serait mal venue de savoir a quel prix sont vendus les outils. Dès fois que l'on découvre que nous ne bénéficions pas des meilleurs remises.

Par contre l'outil ne devrait-il pas à un moment passer par une solution CFAO qui permettrait de gérer elle même l'assemblage en fonction des besoins de l'environnement pièce ? Ne serait-il pas intéressant d'avoir les recommandations du fabricant concernant les conditions d'utilisation pour une matière donnée ? Je ne sais pas si c'est intentionnel mais le fait de mentionner "to integrate information from the suppliers" Le rajout de depuis le fournisseur n'est-il pas totalement restrictif ? Pourquoi seulement depuis un fournisseur, ces données ne pourraient-elles pas être enrichies par les données de l'entreprise pour suivre le chemin de la chaine numérique ?

A la lecture de ces lignes et pour avoir regardé d'un peut plus près le contenu de la norme je dois dire que malheureusement on est très proche des objectifs annoncés . Donc il n'est pas étonnant que la diffusion de cette norme ne soit pas plus active 20 ans plus tard.

Juste mon point de vue.





dimanche 6 avril 2014

ADVEON, NOVO, ISO 13399 les mêmes origines conduisent aux mêmes limites



Sur les 6 derniers mois ce sont donc deux solutions de consultations en ligne qui viennent d’être annoncées par deux fournisseurs d’outils. Les solutions NOVO™ de Kennametal et ADVEON™ de Sandvik.
ADVEON par Sandvik
Il est à noter pour ADVEON™, la première solution CFAO annoncée comme partenaire est EdgeCAM quant à NOVO™ c’est la solution ESPRIT qui est mis en avant.  La solution de SANDVIK se base sur la norme ISO 13399 portée par ce même fournisseur. J’ai d’ailleurs trouvé un article intéressant sur le sujet sur le site machinery.co.uk. On y apprend par exemple qu'aux origines de cette norme existait une collaboration de Kennametal et de Sandvik dans le milieu des années 90.   
Mais 20 ans plus tard on peut donc dire que la généralisation de cette norme n’est pas encore à l’ordre du jour. J’ai pu pour ma part m’intéresser au contenu de la norme ISO 13399 pour le développement de VisuOutil.  Et j'ai été très déçu par le contenu de cette norme en particulier sur 2 points qui de mon points de vue sont très important si l'on veut parler d'échange de données sur les outils coupant.

Les données technologiques d’usinage

Le premier sur les données technologiques d’usinage. Absent de la norme (ou plus exactement très limité : speed, feed et profondeur d'usinage), ces données sont un des points importants de l’échange de données. En effet si l’on désire démocratiser les échanges il est nécessaire que l’utilisateur y voit un réel avantage et cette avantage n’est de mon point de vue pas clairement démontré par les promoteurs de le norme. On nous indique que l’utilisation de ce format d’échange pourrait selon Sandvik amméliorer la productivité de plus de 50% "according to CAM system suppliers, automated input of cutting tool data to CNC systems can increase the productivity of a machining process by as much as 50% . Rien que ça… Mais comment penser que puisque l'on ne peut même pas récupérer ces données, l'utilisateur qui devra de toute façon retraiter les informations outils pour les intégrer dans sa CFAO va massivement généraliser l'utilisation de ces données.
NOVO par Kennametal
Sur ce point des données la solution NOVO est plus en avance et a ma préférence, car elle intègre elle ce type de données en même temps qu’elle est capable de faire le lien avec les données géométrique de l’opération à traiter. Mais là aussi les progrès seront à réaliser  comme par exemple avec l’interface ESPRIT qui bien que mis en avant par chacun des partenaires n’est à ce jour pas capable de traiter les données de coupe puisqu’au niveau d’ESPRIT ces données sont gérées sur les opérations et non  pas au niveau de l’outil. Ceci n'est cependant pas le seul manque.

Profil 2D des portes outils et outils à queue renforcée

Si les conditions de coupe ne sont pas présentes, la géométrie du profil des portes outils ou des outils n'est  pas non plus prévue dans la définition des outils. Que ce soit pour ADVEON ou NOVO l’export des géométries est en effet supporté par le fichier STEP 3D de l’assemblage et de l’outil.  Nous allons le dire et le redire … dans la plupart des systèmes CFAO la géométrie 3D est au mieux utilisée uniquement sur la partie simulation du parcours final. Donc bien après que l’on est déjà utilisé les données outils pour déterminer les conditions technologique d'usinage, la limitation des parcours par sa collision avec son environnement ou le calcul des longueurs sorties, bref quand tout le travail est fait.


 Définition de porte-outil dans NX8 : Croyez vous que l'on utilise la définition 3D pour ces calculs ?
Aujourd’hui dans les systèmes CFAO la définition d’un outil pour le fraisage est réalisée à partir de paramètres, mais ils ne sont pas suffisants pour décrire complètement la géométrie de l’outil. Pour définir complètement les outils de fraisage, les systèmes CFAO utilisent en complément une description par profil 2D (pour les plus évolués, les autres utilisant encore des empilement de cône qui peuvent néanmoins se rapprocher au final d'un profil 2D)  qui définira ensuite un volume de révolution pour le calcul des collisions ou la génération des parcours.
Définition outil dans Tebis
A ma connaissance très peu utilise la définition 3D pour le calcul et ceux qui le font ont des temps de calculs très long. On retrouve certes l’utilisation des géométries 3D sur la partie Simulation ou dans le cas des outils de tournage. Pour le tournage la complexité des géométries et la création de parcours très court si on les compare ou parcours de fraisage rend l’utilisation de la géométrie 3D valide et nécessaire sans que ceci soit un frein sur le calcul des parcours.  
Définition outil 3D dans NCSIMUL
Le fait que la norme ISO 13399 ne propose pas ce genre d’information est donc un frein majeur à son utilisation. En effet non seulement je pense que ceci ne réduit en rien les temps d’industrialisation, mais au contraire les allonges en obligeant les programmeurs à redéfinir un outil pour ses opérations de calcul qui de plus peut différer de celui utilisé dans la partie simulation. Dans l’article machinery.co.uk on nous parle aussi de la norme STEP AP238. Elle pourrait pallier au manque de l’ISO 13399. Certes si la norme STEP AP238 plus connues sous le nom de STEP NC traite des conditions d’usinage, elle ne prévoit pas plus que l’iso 13399 la définition de la géométrie 2D du profil des portes outils ou des outils. Nous sommes donc encore obligé de nous référer à des définitions DXF des outils pour obtenir ces données. Il est à noter que le STEP NC est encore plus ancien que l’ISO 13399 et que l’on peut douter que ceci débouche un jour sur de réelles avancées tant que son développement reste cantonné au mains d’universitaires et que les fabricants de CN n’investissent pas le sujet.
Au final ISO 13399, plus STEP AP238 et DXF ou STEP AP234 pour définir un outil cela commence à faire une vraie usine à gaz et apporte de la complexité là ou l'on recherche au contraire la simplicité.

Donc si un jour plutôt que nous abreuver de message marketing, les fournisseurs pouvaient se poser les vraies questions peut être cela ferait-il avancer les choses.

 Ceci est mon point de vue et si vous avez des avis contraires je serai heureux de pouvoir partager ce sujet avec vous.