GPA-774 Robots Industriels II · PDF fileLe département de génie de la production automatisée possède un robot industriel Fanuc M-6i. Ce robot comprend un manipulateur,

Université du Québec

École de technologie supérieure Département de génie de la production automatisée

GPA-774 Robots Industriels II Hiver 2003

Mario Tétreault Version 2.0

Guide d’utilisation du robot M-6i

Guide d’utilisation du robot M-6i : Table des matières. i

Table des matières Liste des figures ............................................................................................................................. ii Liste des tableaux ........................................................................................................................... ii

1 INTRODUCTION.............................................................................................................. 1-1

2 DESCRIPTION GÉNÉRALE........................................................................................... 2-1

2.1 ROBOT M6-I (MANIPULATEUR) ..................................................................................... 2-2 2.2 CONTRÔLEUR ................................................................................................................ 2-4 2.3 PANNEAU DE L’OPÉRATEUR........................................................................................... 2-6 2.4 BOÎTIER DE COMMANDE ................................................................................................ 2-7 2.5 SÉCURITÉ .................................................................................................................... 2-11

3 PRINCIPALES PROCÉDURES D’OPÉRATION......................................................... 3-1

3.1 SUR L’ORDINATEUR PERSONNEL (PC) ........................................................................... 3-1 3.2 SUR LE ROBOT M-6I ...................................................................................................... 3-1

4 PROGRAMMATION DU ROBOT M-6I EN KAREL .................................................. 4-1

4.1 PRINCIPALES ÉVOLUTIONS DE KAREL (RH AU R-J3)..................................................... 4-1 4.2 STRUCTURE GÉNÉRALE D’UN PROGRAMME ................................................................... 4-1 4.3 TYPE STRUCTURE ..................................................................................................... 4-1 4.4 TYPES DE VARIABLES PRÉDÉFINIES ............................................................................... 4-2 4.5 UTILISATION DES OPÉRATEURS ..................................................................................... 4-8 4.6 INSTRUCTIONS DE MOUVEMENT .................................................................................... 4-9 4.7 ÉNONCÉS DE CONTRÔLE ................................................................................................ 4-9 4.8 SIGNAUX D’INTERRUPTION............................................................................................ 4-9 4.9 LECTURE (READ)/ÉCRITURE (WRITE) ........................................................................ 4-9 4.10 SYSTÈME D’ENTRÉES/SORTIES....................................................................................... 4-9

5 DESCRIPTION ET COMPARAISON DES COMMANDES KAREL........................ 5-1

5.1 LANGAGE DE PROGRAMMATION KAREL ........................................................................ 5-1 5.2 VARIABLES DE SYSTÈME ............................................................................................... 5-4

6 ANNEXE – DESCRIPTION DES PRINCIPALES COMMANDES DU LANGAGE KAREL........................................................................................................................................ 6-1

7 RÉFÉRENCES................................................................................................................... 7-1

Guide d’utilisation du robot M-6i : Listes des figures et des tableaux. ii

Liste des tableaux

Tableau 2.1 - Caractéristiques techniques du robot M-6i. ........................................................... 2-2 Tableau 2.2 - Caractéristiques du contrôleur R-J3. ...................................................................... 2-4 Tableau 2.3 - Différents types de mémoire. ................................................................................. 2-5 Tableau 2.4 - Description des principaux éléments du panneau de l'opérateur. .......................... 2-6 Tableau 5.1 - Description et comparaison des commandes Karel (M-6i et S-10). ...................... 5-1 Tableau 5.2 - Comparaison de certaines variables de système entre les robots M-6i et le S-10. 5-4

Liste des figures

Figure 2.1 - Description générale du système-robot. ................................................................... 2-1 Figure 2.2 - Dimension du robot et de son enveloppe de travail. ................................................ 2-3 Figure 2.3 - Panneau de l'opérateur. ............................................................................................. 2-6 Figure 2.4 - Principales composantes du boîtier. ......................................................................... 2-8 Figure 2.5 - Description détaillée des touches du boîtier de commande...................................... 2-9 Figure 2.6 - Menus associés à la touche FCTN.......................................................................... 2-10 Figure 2.7 - QUICK MENUS. ................................................................................................... 2-10 Figure 2.8 - FULL MENUS. ...................................................................................................... 2-11 Figure 6.1 - FRAME Built-In Function. .................................................................................... 6-21

Guide d’utilisation du robot M-6i : Introduction. 1-1

1 INTRODUCTION

Ce guide d’utilisation a pour objectif de faciliter l’utilisation du robot FANUC M-6i du département de génie de la production automatisée. Il fait suite au document intitulé « Guide d’utilisation du robot S-10 ».

Le guide contient cinq (5) autres chapitres :

− Description générale du système robot ; − Principales procédures d’opération ; − Programmation en langage Karel ; − Description et comparaison de la programmation entre les robots S-10 et M-6i ; − Description détaillée des principales commandes du langage Karel.

Le deuxième chapitre explique les composantes du système robot et les principales caractéristiques techniques du robot M-6i. Il présente également une revue des règles de sécurité proposée par le fabricant et celles imposées par le département de génie de la production automatisée.

Le troisième chapitre décrit les principales procédures d’opération du robot M-6i. Il explique comment démarrer une session de travail, effectuer une édition hors-ligne de programme avec le logiciel WinOLPC et transférer des fichiers entre le contrôleur et le PC. Il donne également les étapes pour choisir un programme, enregistrer des positions de travail et exécuter le robot en mode de vérification et en mode automatique. Le quatrième chapitre explique brièvement la programmation avec le langage Karel. Il met l’accent sur les différences et les ajouts par rapport à la version utilisée par le robot S-10.

Le cinquième chapitre présente un index des principales fonctions et commandes utiles à la programmation du robot M-6i et leurs équivalents sur le robot S-10. Finalement, le dernier chapitre donne la description (en anglais) des principales commandes du langage Karel. Ces descriptions proviennent directement du « System R-J3 Controller Karel Reference Manual » de la compagnie FANUC Robotics.

Guide d’utilisation du robot M-6i : Description générale. 2-1

2 DESCRIPTION GÉNÉRALE

Ce chapitre explique le système robot et les principales caractéristiques techniques du robot M-6i de même qu’une revue des règles de sécurité proposées par le fabricant et celles requises par le département de génie de la production automatisée.

Le département de génie de la production automatisée possède un robot industriel Fanuc M-6i. Ce robot comprend un manipulateur, un contrôleur et un logiciel de système (R-J3). Il exécute des tâches industrielles décrites en langage de programmation KAREL ou TPP (Teach Pendant Programming).

La Figure 2.1 illustre une vue d’ensemble du système : le panneau de l’opérateur, le boîtier de commande, le robot M-6i et le contrôleur (le contrôleur peut être intégré à l’arrière du robot ou déporté).

Figure 2.1 - Description générale du système-robot.

L'interaction entre le robot et l'opérateur se fait à l'aide du panneau de contrôle, d'un écran et d'un boîtier de commande. Cette interaction est simplifiée par des menus ou en utilisant directement le langage de commande. Dans notre laboratoire, le contrôleur est aussi relié à un micro-ordinateur pour la programmation hors-ligne et la sauvegarde de programmes. Il


est également relié à un automate (PLC-Programmable Logic Controller), des actionneurs et des capteurs.

2.1 Robot M6-i (manipulateur)

Cette section décrit brièvement les caractéristiques physiques du manipulateur M-6i.

Le robot M-6i a six (6) articulations en rotation telles qu’illustrées sur la Figure 2.1. Chaque articulation est actionnée par des moteurs AC sans balais. Des encodeurs absolus indiquent la position des articulations. Le Tableau 2.1 donne l'intervalle de déplacement et la vitesse maximale de chaque articulation. Des freins mécaniques sont présents à chaque articulation.

A. Dimensions du robot et enveloppe de travail

La Figure 2.2 donne les dimensions du robot et de son enveloppe de travail.

B. Spécifications techniques

Le Tableau 2.1 suivant résume les principales caractéristiques techniques. En plus de ces données, il faut noter que la vitesse cartésienne maximale du robot est de 2 m/s.

Tableau 2.1 - Caractéristiques techniques du robot M-6i.

Items Amplitude Vitesse

Axe 1 330o (360o optionnel) 120o/s Axe 2 210o

120o/s Axe 3 299o

120o/s Axe 4 380o

360o/s Axe 5 280o

360o/s

Amplitude de mouvement et vitesse

Axe 6 640o 450o/s

Axe 4 1,6 kg⋅m Axe 5 1,0 kg⋅m

Moment

Axe 6 0,6 kg⋅m Axe 4 6,40 kg⋅cm⋅s2

Axe 5 2,00 kg⋅cm⋅s2 Axe 6 0,62 kg⋅cm⋅s2 Répétabilité ± 0,1 mm (± 0,004”) Charge maximale au poignet 6 kg (13,2#) Méthode de montage Plancher, plafond ou en angle Freins mécaniques Axes 2 et 3 (axes 1, 4, 5 et 6 en option) Poids du robot


Figure 2.2 - Dimension du robot et de son enveloppe de travail.


2.2 Contrôleur

A. Éléments internes

Le contrôleur (armoire de commande) est relié au robot par un câble (déporté). Il fournit l’alimentation électrique au robot. Il contient :

− Un processeur central double supportant le muti-tâches et permettant un temps d’échantillonnage de quatre (4) ms (scan time) ;

− Six (6) cartes pour l'asservissement des articulations du robot ; − La possibilité d’ajouter des cartes pour l’asservissement d’axes auxiliaires (jusqu’à

dix) ; − De la mémoire vive (DRAM) pour l'exécution de programmes écrits par

l'utilisateur et de la mémoire permanent pour sauvegarder des fichiers ; − Des ports d'entrées/sorties numériques permettant la communication externe avec

des équipements reliés au robot. Des E/S analogiques pourraient être ajoutées ; − Des cartes de communication en réseau (DeviceNet et Ethernet) ; − Un lien RS-422 pour communiquer avec un ordinateur personnel ; − Système de protection contre les collisions (Collision guard).

Le Tableau 2.2 résume les principales caractéristiques du contrôleur R-J3.

Tableau 2.2 - Caractéristiques du contrôleur R-J3.

Items Descriptions Processeur Processeur central double à 32-bit supportant le multi-tâches. Temps d’échantillonnage

Temps de réponse inférieur à 4 ms (scan time).

Axes commandés Commande de seize (16) axes de mouvement incluant les six (6) du robot.

Regroupement d’axes auxiliaires

Jusqu’à trois (3) axes auxiliaires groupés ayant son propre programme et son modèle cinématique.

Mémoire Deux types de mémoire permanente (CMOS RAM et FROM (Flash ROM)) de même que de la mémoire vive DRAM.

Réseaux supportés Remote I/O, Fanuc I/O, Genius I/O, DeviceNet, ControlNet et Profibus-DP.

Communication externe

Carte réseau Ethernet, interface PCMCIA et lien RS-422.

Protection contre les collisions

Sensibilité ajustable lors de la détection des collisions (Collision guard).


B. Équipements externes reliés au contrôleur

Plusieurs équipements peuvent être reliés au contrôleur : − Un panneau de l’opérateur et un panneau de contrôle externe (UOP) pour exécuter

des tâches de base ; − Un boîtier de commande pour le déplacement du robot en mode manuel ; − Un ordinateur personnel pour la programmation hors-ligne et la sauvegarde de

fichier sur disquette.

C. Architecture de la mémoire

Le Tableau 2.3 explique les trois (3) type de mémoire utilisée par le contrôleur R-J3 : CMOS RAM, FROM (Flash ROM) et DRAM. Les mémoires CMOS RAM (Battery-Backed) et FROM sont permanentes tandis que la DRAM représente la mémoire vive du système.

Tableau 2.3 - Différents types de mémoire.

Items Descriptions FROM (FR:) Le système d’exploitation R-J3 s’installe dans la mémoire FROM

qui peut être configurée pour créer l’unité « FR: » servant à sauvegarder des programmes et des données.

CMOS RAM (PERM et RD:)

Cette mémoire est rendue permanente par l’utilisation de batterie et sert de disque rigide pour sauvegarder les programmes avec leurs données. Elle est séparée en deux entités : l’espace pour les programmes en langage TPP et l’espace PERM qui contient les variables de système. Elle contient également une copie du programme Karel et de ses variables « .VR » chargés en mémoire vive (DRAM) qui sont continuellement sauvegardées et mises à jour dans la mémoire CMOS. Cette mémoire peut également contenir certaines variables Karel (IN CMOS dans le langage Karel) utilisées lors de l’exécution (variables mise dans le CMOS au lieu de la mémoire vive DRAM). Cette mémoire peut être configurée pour créer l’unité « RD: » servant à sauvegarder des programmes et des données.

DRAM (MD:) La mémoire vive du système est constituée de DRAM à laquelle l’unité de disque « MD: » est assigné. Lors de l’exécution d’un programme Karel, elle contient ce programme en mémoire et la majorité de ses variables « .VR » qui n’ont pas été mises dans le CMOS.

Mémoire externe

Un ordinateur personnel est relié au contrôleur. Le logiciel WinOLPC peut émuler un disque avec le PC relié au contrôleur. Ce disque est alors vu comme l’unité « FLPY: » sur le contrôleur.


2.3 Panneau de l’opérateur

Le panneau de l’opérateur (Figure 2.3) est utilisé pour effectuer les tâches de base : mise sous tension et hors-tension, lancement du programme en mode automatique (CYCLE START), arrêt d’urgence, réarmement après une faute (FAULT RESET), pause du robot (HOLD) et voyants d’état.

Figure 2.3 - Panneau de l'opérateur.

A. Descriptions des principaux éléments

Le panneau de l’opérateur possède les caractéristiques résumées dans le Tableau 2.4.

Tableau 2.4 - Description des principaux éléments du panneau de l'opérateur.

Items Descriptions Bouton On Met le contrôleur sous tension et allume le voyant On. Bouton Off Met le contrôleur hors tension. Clé REMOTE/ LOCAL

LOCAL - le panneau de l’opérateur est utilisé. REMOTE – le robot est relié à un automate ou à un autre panneau d’opérateur que celui fourni par le fabricant.

Bouton EMERGENCY STOP

Arrêt immédiat du robot : alimentation coupée et freins appliqués sur les six axes. Fait un arrêt dans l'exécution du programme et allume le voyant FAULT. Il a la forme d'un champignon rouge.

Voyant REMOTE

S'allume lorsque la clé est à la position REMOTE.


Items Descriptions Bouton HOLD Effectue une pause sur l'exécution du programme. Le robot

décélère normalement et s'arrête. L'alimentation demeure sur les moteurs.

Bouton CYCLE START

Permet de démarrer le programme courant en mode automatique et de redémarrer un programme interrompu par un HOLD.

Interrupteur d’alimentation principale

Coupe l’alimentation au panneau de l’opérateur et au robot. La Figure 2.3 montre l'emplacement de l'interrupteur principal d'alimentation électrique (Power Disconnect Circuit Breaker). Il est important de connaître son emplacement lors d'une situation d'urgence.

B. Mise en marche du contrôleur

La mise en marche du robot est très simple : a. Vérifier les règles de sécurité décrites à la section 2.5 ; b. Mettre l'interrupteur principal d'alimentation à ON (normalement, il est toujours à

cette position) ; c. Appuyer sur la touche ON du panneau de contrôle. Le voyant ON s'illumine sur le

panneau de l’opérateur et une procédure d'initialisation et de vérification est lancée.

C. Mise hors de tension du contrôleur

La procédure de mise hors de tension du contrôleur est très simple : a. Presser la touche HOLD sur le panneau de contrôle si un programme est en cours

d'exécution ou le robot est en mouvement ; b. Presser l'interrupteur OFF sur le panneau de l’opérateur.

2.4 Boîtier de commande

Le boîtier de commande sert d'interface entre l'opérateur et le robot. Il permet de : − Déplacer le robot en mode manuel ; − Enseigner des positions de travail ; − Vérifier un programme ; − Afficher des messages de l'usager, des messages d'erreurs, des curseurs (prompts) et

des menus ; − Afficher et modifier des données, des variables, des paramètres et des entrées/sorties.


A. Description générale du boîtier

Le boîtier de commande (Figure 2.4) est muni d’un bouton d’arrêt d’urgence (EMERGENCY STOP BUTTON) en forme de champignon rouge. Il possède un interrupteur ON/OFF (ON/OFF Switch) permettant de prendre le contrôle sur le mouvement du robot lorsqu’il est à ON. Un interrupteur d’homme-mort (DEADMAN Switch) de couleur jaune doit être pressé pour être capable d’initier un déplacement du robot lorsque le boîtier a le contrôle sur ce dernier. Des voyants (Indicators) affichent l’état du robot. L’écran LCD (Screen) permet d’afficher des menus et des messages d’erreur. La Figure 2.5 donne une description détaillée des touches du boîtier de commande.

DEADMANSwitch

DEADMANSwitch

Figure 2.4 - Principales composantes du boîtier.

B. Touches FCTN et MENUS

La touche FCTN (Function) permet d’avoir accès à des fonctions globales (Figure 2.6). Plus particulièrement, elle permet de choisir le niveau de détail associé à la touche MENUS (QUICK ou FULL).


Figure 2.5 - Description détaillée des touches du boîtier de commande.


MENUSMENUS

Figure 2.6 - Menus associés à la touche FCTN

a) QUICK MENUS

Par défaut, en pressant sur la touche MENUS du boîtier, le système utilise les QUICK MENUS (Figure 2.7). Le deuxième écran ou page est obtenu en choisissant l’item 0 --NEXT--. Cette page est utilisée pour démarrer une session de travail (Login avec SETUP PASSWORD).

Figure 2.7 - QUICK MENUS.

NOTE : Les numéros et l’ordre des items dans les menus peuvent différer dépendamment des options installées sur le contrôleur.


b) FULL MENUS

La Figure 2.8 montre les FULL MENUS. Ces menus sont utilisés dans la majorité des procédures décrites au chapitre 3.

Figure 2.8 - FULL MENUS.

C. Touches SELECT, EDIT et DATA

Les touches SELECT, EDIT et DATA donnent accès à des menus reliés à l’enseignement (Teach) de positions de travail et de parcours (trajectoires). Ces touches permettent de choisir le programme actif (SELECT), d’enseigner les positions et les parcours (DATA), et de sauvegarder vos données (DATA). La touche EDIT permet l’édition de programmes en langage TPP.

2.5 Sécurité

La sécurité en robotique touchant les opérateurs consiste 1) à remplacer des travailleurs qui oeuvrent dans un milieu nuisible et dangereux, et 2) à les protéger du danger potentiel du robot en mouvement. Cette section s'intéresse à la sécurité de l’opérateur travaillant avec un robot.

L'opérateur est exposé au danger lors de l'installation, les essais, la programmation, la maintenance et la production. Contrairement à ce que l'on peut penser, la majorité des accidents en milieu industriel ne se produisent pas lors de la production, mais bien lors de la programmation (enseignement de positions de travail) des robots et des essais qui requiert la présence de l’opérateur près du robot. Contrairement à une machine à commande numérique par exemple, l'enveloppe de travail du robot n'est pas limitée par la structure de la machine. Un opérateur peut donc facilement entrer dans l'enveloppe de travail du robot. Pour réduire les risque d'accidents, le manufacturier du robot émet des recommandations sur la sécurité. De plus, une norme sur la sécurité en robotique a été écrite.


La norme CAN/CSA-Z434-F94 sur la sécurité en robotique impose plusieurs règles touchant la conception, l'installation, les tests, le démarrage, la maintenance et l'entraînement des travailleurs. Le design du robot M-6i respecte les normes quant à sa conception. Avec l’utilisation de barrières, de portes reliées à un interrupteur à clé captive et un rideau optique, le laboratoire du département satisfait à ces normes canadiennes. L’utilisation d’équipement rencontrant les normes permet d’obtenir un milieu sécuritaire. Toutefois, durant la programmation et les tests, la meilleure protection est un opérateur bien formé et conscient des dangers potentiels du robot. À ce titre, tout utilisateur de robots devrait toujours avoir en tête les règles présentées ci-dessous.

A. Règles de sécurité suggérées par le manufacturier

FANUC Robotics recommande que toute personne ayant à opérer, programmer, réparer ou utiliser le système robotisé doit suivre une formation adéquate pour permettre une opération appropriée du système.

a) Précautions lors de l’opération du robot en mode manuel

Toute personne devant enseigner des positions de travail ou opérer manuellement le robot avec le boîtier de commande doit observer les règles suivantes :

− Ne jamais porter des montres, anneaux, colliers, cravates ou autres vêtements qui peuvent se prendre dans la machinerie en mouvement ;

− Avant d’enseigner des positions, faire une inspection visuelle du robot et de son enveloppe de travail pour s’assurer qu’il n’existe pas de situations dangereuses ;

− L’aire près du robot doit être propre sans huile, eau ou débris. Signaler immédiatement des conditions de travail non-sécuritaires aux personnes responsables (technicien, professeur et directeur) ;

− FANUC Robotics recommande que personne n’entre dans l’enveloppe de travail d’un robot en marche, excepté pour enseigner des positions de travail. Toutefois, si vous devez entrer dans l’espace de travail, soyez certain que toutes les dispositifs de sécurité sont fonctionnels, vérifiez le bon fonctionnement de l’interrupteur d’homme-mort et mettez le boîtier actif. Prenez le boîtier avec vous et soyez prêt à relâcher l’interrupteur d’homme-mort. Seule la personne avec le boîtier de commande devrait être à l’intérieur de l’enveloppe de travail ;

− Connaître les trajets pouvant être utilisés pour éviter un robot en mouvement. S’assurer que ces trajets ne sont jamais obstrués ;

− Isoler le robot de tous signaux externes pouvant produire un mouvement lorsque des positions sont entrain d’être enseignées ;

ATTENTION Ne jamais contourner, attacher ou désactiver d’une autre façon un dispositif de sécurité, tel qu’un interrupteur de limite (limit switch), pour faciliter l’opération du système. La désactivation d’un dispositif de sécurité est reconnue pour avoir causé des blessures graves ou la mort.


− Vérifier un programme exécuté pour la première fois de la façon suivante : 1) utiliser une vitesse réduite pour vérifier le programme étape par étape pour un cycle complet, 2) utiliser une vitesse réduite pour vérifier le programme en continue pour un cycle complet et 3) vérifier le programme en continue à la vitesse programmée ;

− S’assurer qu’il n’y a personne à l’intérieur de l’enveloppe de travail avant de lancer la production.

b) Précautions lors de l’opération du robot en mode automatique

Toute personne devant opérer le robot en mode automatique ou durant la production doit observer les règles suivantes :

− S’assurer que tous les dispositifs de sécurité sont présents et actifs ; − Connaître l’aire de travail complet de la cellule robotisée. La cellule comprend le

robot et son enveloppe de travail de même que tout espace occupé par des dispositifs externe et autres équipements qui interagissent avec le robot ;

− Connaître la tâche complète du robot pour laquelle il est programmé avant d’initier l’opération en mode automatique ;

− S’assurer qu’il n’y a aucune personne à l’intérieur de l’enveloppe de travail avant d’opérer le système robotisé ;

− Ne jamais entrer ou permettre à d’autres personnes d’entrer à l’intérieur de l’enveloppe de travail du robot durant l’opération en mode automatique ;

− Connaître l’emplacement et l’état des interrupteurs, des capteurs et des signaux de contrôle qui peuvent initier le mouvement du robot ;

− Connaître où sont les arrêts d’urgence sur le robot et sur les dispositifs externes. Être prêt à presser ces boutons en cas d’urgence ;

− Ne jamais assumer que le programme est terminé lorsque le robot ne se déplace pas. Le robot peut être en attente d’un signal d’entrée qui va lui permettre de continuer ses activités ;

− Si le robot répète une même séquence de mouvement, n’assumer pas qu’il va continuer à répéter cette même séquence ;

− Ne jamais essayer d’arrêter le robot ou de le faire dévier de sa trajectoire en utilisant son corps. La seule façon d’arrêter immédiatement le mouvement d’un robot est de presser l’arrêt d’urgence sur le panneau de l’opérateur, sur le boîtier de commande ou un autre arrêt d’urgence placé près de la cellule.

ATTENTION Rester à l’extérieur de l’enveloppe de travail du robot lorsque le programme est en exécution (mode automatique). Ne pas le faire peut conduire à des blessures graves ou la mort.


c) Précautions lors de l’inspection du robot

Lors de l’inspection visuelle du robot, mettre hors-tension le contrôleur du robot.

d) Précautions pour garder les dispositifs externes sécuritaires

Certaines mesures sont appropriées pour garder l’effecteur et les autres dispositifs externes sécuritaires. Toute personne devant opérer le robot doit connaître les mesures suivantes :

− Vérifier que les interrupteurs de limite (limit switches) dans la cellule sont fonctionnels ;

− En programmation, implanter des « routines de défaillance » permettant une action appropriée du robot si un dispositif externe ou un autre robot dans la cellule est défaillant ;

− En programmation, utiliser un protocole de communication de type « handshaking » pour synchroniser le robot avec l’opération de dispositifs externes ;

− Programmer le robot pour vérifier l’état des dispositifs externes durant un cycle d’opération ;

− Être certain que la cellule est propre et sans présence d’huile, d’eau ou de débris ; − Utiliser des limites logicielles, des interrupteurs de limite (limit switches) et des

butées mécaniques sur les axes du robot pour prévenir un déplacement non-désiré du robot dans la zone de travail de dispositifs externes.

e) Précautions pour garder le robot sécuritaire

Certaines mesures sont appropriées pour garder le robot en bon état et sécuritaire. Toute personne devant opérer le robot doit connaître les mesures suivantes pour prévenir des dégâts :

− Utiliser une vitesse réduite (override) pour augmenter votre contrôle sur le robot lors du déplacement en mode manuel ;

− Anticiper le mouvement du robot avant de presser une touche de déplacement sur le boîtier de commande ;

− Être certain que l’enveloppe de travail est propre et sans présence d’huile, d’eau ou de débris ;

− En programmation, établir des zones d’interférence pour prévenir des collisions lorsque des robots partagent le même espace de travail ;

− S’assurer que le robot retourne ou est proche de sa position de retrait (home) lorsque le programme prend fin ;

− Être vigilant sur les signaux et les autres opérations qui peuvent engendrer des actions de l’effecteur causant des blessures ou des dégâts sur les équipements.


B. Règles générales de sécurité

Dans son manuel de formation, la compagnie ADEPT énonce les trois (3) principes généraux suivants sur la sécurité :

− Si un robot ne se déplace pas, n'assumez pas qu'il ne bougera pas ; − Si un robot répète une séquence, n'assumez pas qu'il va continuer à le faire ; − Maintenir du respect pour ce qu'est un robot et ce qu'il peut faire.

C. Règles essentielles de sécurité

D. Règles de bonne conduite

Les règles suivantes n’entraînent pas de sanction académique, mais elles ont pour but de réduire les risques d’accident et le dommage aux équipements :

− Afin d'éviter les bris du boîtier de commande, il doit être accroché à l'endroit prévu ou dans vos mains. Même si le boîtier de commande de votre robot est défectueux, il ne faut pas le changer avec celui d'un autre ;

− Inspecter le bon état des équipements avant des utiliser ; − Vérifier le fonctionnement des boutons d'arrêt d'urgence et de l'interrupteur

d'homme-mort ;

ATTENTION Les règles suivantes doivent être suivies sous peine de sanction :

− Seulement les personnes formées peuvent utiliser les robots ; − Obtenir l'approbation écrite du chargé de laboratoire ou du responsable avant

d'utiliser les robots (étudiants dans le premier cours de robotique) ; − Enlever les objets inutiles du périmètre ; − Aucune personne à l'intérieur du périmètre lorsque la porte est fermée ; − Une seule personne dans le périmètre (à l'exception des instructeurs) ; − Avoir le boîtier activé dans le périmètre ; − Exécution à 50% de la vitesse maximale (étudiants dans le premier cours de

robotique) ; − Être près d'un arrêt d'urgence lors de l'exécution du programme en mode

automatique ; − Une personne opérant le robot en état d’ébriété est exclue du cours.

ATTENTION Ne jamais contourner ces règles essentielles de sécurité. La violation de ces règles est reconnue pour avoir causé des blessures graves et la mort.


− Vérifier les limites physiques sur l'axe #1 en déplaçant le robot en mode manuel. D'une session de travail à une autre, ces limites peuvent changer étant donné que les robots sont utilisés par d'autres personnes ;

− Réduire la vitesse (override) à 30 % lors de la 1ère utilisation et entre 30 et 100 % après ;

− Tester vos programmes en vitesse réduite.

Guide d’utilisation du robot M-6i : Principales procédures d’opération. 3-1

3 PRINCIPALES PROCÉDURES D’OPÉRATION

Ce chapitre décrit les principales procédures d’utilisation de l’ordinateur personnel et d’opération du robot M-6i.

3.1 Sur l’ordinateur personnel (PC)

L’ordinateur relié au robot M-6i utilise le logiciel WinOLPC pour effectuer l’édition hors-ligne de programme et transférer des fichiers entre le contrôleur et le PC.

A. Compilation d’un programme en langage Karel

Pour compiler votre programme Karel (en format ASCII avec une extension .KL), il faut :

− Exécuter le logiciel WinOLPC sur le bureau ; − Dans l’onglet Tools, il suffit de choisir Translate KAREL Program ; − Sélectionner le programme désiré.

B. Émulation du PC en unité périphérique

Pour rendre le PC comme une unité de disque (FLPY:) vue par le robot, il faut : − Dans l’onglet Tools, choisir l’option Floppy Emulator ; − Sous l’onglet File, choisir le répertoire par défaut en sélectionnant l’option

Change Directory ; − Choisir Emulate sous l’onglet File.

3.2 Sur le robot M-6i Cette section explique comment démarrer une session de travail sur le robot. Puis, elle décrit les étapes pour choisir un programme, enregistrer des positions de travail et exécuter le robot en mode de vérification et en mode automatique.

A. Démarrage d’une session de travail (Login) sur le robot

La procédure de cette section utilise le QUICK MENUS sur le robot M-6i pour démarrer une session de travail en suivant les étapes suivantes :

− Presser le bouton MENUS ; − Choisir l’option NEXT ; − Choisir l’option SETUP PASSWORDS ; − Appuyer sur la touche F2 – (USERS) ;


− Sélectionner l’usager super ; − Appuyer sur la touche F2 – (LOGIN) ; − Entrer le mot de passe en minuscule (Choisir Lower Case en appuyant une fois la

flèche par en bas pour mettre en minuscule et entrer les caractères).

Note : Pour sélectionner les items dans les menus, il faut déplacer le curseur avec les flèches verticales et appuyer la touche ENTER. Il est également possible d’appuyer directement la touche correspondant au numéro de l’item. Les autres procédures de la section 3.2 utilisent les FULL MENUS. Ainsi, il faut :

− Appuyer sur le bouton FCTN ; − Choisir l’option NEXT ; − Sélectionner l’option QUICK/FULL MENUS.

B. Transfert de fichiers du PC vers le robot et chargement en mémoire du programme

Après avoir mis le PC en mode émulation de disque, le transfert de fichiers du PC vers le robot se fait en suivant les étapes suivantes :

− Appuyer sur le bouton MENUS ; − Sélectionner l’option FILE ; − Choisir l’option UTIL ; − Sélectionner l’option Set Device ; − Choisir l’option Floppy Disk ; − Faire [DIR] en pressant la touche F2 ; − Choisir le fichier désiré « .PC » (transfert du fichier compilé) ; − Appuyer sur la touche F3 – (LOAD).

C. Sélection du programme actif

Le programme actif est sélectionné en faisant : − Appuyer sur le bouton SELECT ; − Sélectionner le programme désiré « .PC » ou « .TPP ».

D. Déplacement du robot en mode manuel

Le déplacement du robot s’effectue en effectuant les étapes suivantes : − Appuyer sur la touche COORD (JOINT, WORLD, TOOL, JGFRM, USER) pour

choisir le type de déplacement ; − Mettre le boîtier actif (tourner l’interrupteur à ON) ; − Presser l’interrupteur d’homme-mort (Deadman Switch) ; − Appuyer simultanément sur les touches SHIFT & touche de déplacement.


E. Édition d’un programme TPP

Pour éditer un programme TPP, il suffit de : − Sélectionner le programme actif (section 3.2C) ; − Appuyer sur le bouton Edit.

F. Entrées/sorties et activation de l’effecteur du robot

Pour accéder aux entrées/sorties ou activer l’effecteur du robot, il faut : − Appuyer sur le bouton I/O ; − Pour changer de type d’entrées/sorties, appuyer la touche F1 – [TYPE] et

sélectionner le type (soit 1 – digital ou 4 – robot) ; − Pour sélectionner les entrées (IN) ou les sorties (OUT), appuyer sur la touche F3 –

(IN/OUT) ; − Pour activer ou désactiver une sortie, choisir la sortie désirée et appuyer la touche

F4 – (ON) ou F5 – (OFF).

G. Enseignement des positions de travail

Pour enseigner des positions de travail, il suffit de : − Appuyer sur le bouton DATA ; − Appuyer sur la touche F1 – [TYPE] ; − Choisir l’option KAREL Posns ; − Sélectionner la variable désirée ; − Pour enregistrer, appuyer simultanément les touches SHIFT & F3 – (RECORD).

À noter qu’il faut choisir le bon référentiel associé à l’effecteur. Pour cela, il faut faire :

− Appuyer sur le bouton MENUS ; − Choisir Setup ; − Presser la touche F1 ([TYPE]) ; − Sélectionner l’option Frames ; − Presser la touche F3 ([OTHER]); − Choisir l’option Tool Frame ; − Choisir un des quatre (4) référentiels disponibles et presser ENTER.

Pour faciliter le changement d’outil, il existe également trois programmes, pince, cup1 et cup2, qui ont été développés pour faire le changement d’effecteur et s’assurer qu’il correspond au $UTOOL du programme Karel. Pour exécuter ces programmes, il suffit de :

− Appuyer sur le bouton SELECT ; − Sélectionner pince, cup1 ou cup2 ;


− Presser le bouton CYCLE START sur le contrôleur (ou activer le boîtier de commande, presser l’interrupteur d’homme-mort et appuyer sur les touches SHIFT & FWD pour exécuter le programme).

H. Enregistrement d’une position à un nœud d’une trajectoire

Les étapes suivantes permettent d’enregistrer une position dans le nœud d’une trajectoire :

− Appuyer sur le bouton DATA ; − Appuyer sur la touche F1 – ([TYPE]) ; − Choisir l’option KAREL Posns ; − Sélectionner le parcours désiré, puis appuyer la touche ENTER ; − Presser la touche F2 (HEADER) pour éditer l’entête du parcours. Choisir le

champs désiré et presser ENTER. Entrer les données ; − Appuyer la touche PREV pour retourner au menu précédent ; − Sélectionner le nœud désiré ; − Pour enregistrer, faire simultanément les touches SHIFT & F3 – (RECORD) ; − Pour modifier les autres champs (données associées) d’un nœud, sélectionner le

nœud et presser la touche ENTER.

Note : Il n’est pas nécessaire de sauvegarder les positions ou les parcours enseignés puisque ces données, en plus d’être présentes dans la mémoire vive (DRAM), sont copiées et mises à jour sur la mémoire CMOS.

I. Déplacement du robot à une position ou à un nœud d’un parcours préalablement enregistré

Le déplacement du robot à une position ou un nœud du parcours déjà enregistré se fait en effectuant les étapes suivantes :

− Appuyer sur le bouton DATA ; − Appuyer sur la touche F1 – ([TYPE]) ; − Choisir l’option KAREL posns ; − Sélectionner la position ou le nœud de la trajectoire désirée ; − Appuyer simultanément sur les touches SHIFT & F4 – (MOVE_ LN) ou SHIFT

& F5 – (MOVE_ JT).

J. Vérification du programme

La vérification d’un programme s’effectue en faisant les étapes suivantes : − Appuyer sur le bouton STEP pour suivre votre programme ligne par ligne

(OBLIGATOIRE POUR LA PREMIÈRE EXÉCUTION) ; − Presser à nouveau le bouton STEP pour remettre le mode de vérification en

continue ;


− Appuyer sur la touche +% ou -% pour augmenter ou réduire la vitesse ; − Appuyer sur les touches SHIFT & FWD pour exécuter le programme ; − Relâcher la touche FWD en maintenant la touche SHIFT enfoncée.

K. Exécution du programme en mode automatique

L’exécution du programme en mode automatique est lancée en faisant : − Tourner l’interrupteur du boîtier à OFF ; − Appuyer sur la touche +% pour mettre la vitesse à 100% sur le boîtier ; − Appuyer sur le bouton CYCLE START sur le panneau de l’opérateur.

L. Arrêt d’un programme lors de la vérification ou de l’exécution en mode automatique

L’arrêt d’un programme en exécution (PAUSED ou RUNNING) est réalisé par les étapes suivantes :

− Appuyer sur le bouton FCNT − Sélectionner l’option ABORT (ALL).

M. Transfert des variables Karel « .VR » sur le PC en émulation

À la fin de la session, pour sauvegarder les variables Karel sur le PC, il faut :

a) Faire correspondre les unites de disque (si ce n’est pas déjà fait)

− Mettre le PC en émulation (voir la section 3.1B) ; − Appuyer sur le bouton MENUS ; − Sélectionner l’option FILE ; − Choisir l’option UTIL ; − Sélectionner l’option Set Device ; − Choisir l’option Floppy Disk.

b) Effectuer les étapes suivantes

− Appuyer sur le bouton DATA ; − Presser la touche F1 – ([TYPE]) ; − Choisir l’option KAREL Posns ; − Appuyer sur le bouton FCTN ; − Choisir l’option NEXT ; − Sélection l’option SAVE.


N. Transfert d’un programme TPP sur le PC

La sauvegarde d’un programme TPP requiert les étapes suivantes : − Effectuer les étapes de la section 3.2M.a) (si nécessaire) ; − Sélectionner le programme actif (section 3.2C) ; − Appuyer sur le bouton FCTN ; − Choisir l’option NEXT ; − Sélectionner l’option SAVE.

O. Effacer des fichiers dans la mémoire du contrôleur

Le programme est effacé du contrôleur en faisant : − Appuyer sur le bouton SELECT ; − Choisir le programme à effacer ; − Sélectionner l’option NEXT ; − Appuyer sur la touche F3 (DELETE).

Le fichier de données « .VR » est effacé du contrôleur en faisant :

− Appuyer sur le bouton MENUS ; − Choisir l’option FILE ; − Presser la touche F5 (UTIL) ; − Sélection l’option Set Device ; − Choisir l’option Mem Device (MD:) ; − Faire [DIR] en pressant la touche F2 ; − Choisir l’option Next Page ; − Sélectionner l’option « *.VR » ; − Choisir votre fichier « .VR » ; − Presser la touche NEXT ; − Presser la touche F1 (DELETE).

Note : Le fichier « .VR » ne peut pas être effacé tant que le programme « .PC » n’a pas

été supprimé.

Guide d’utilisation du robot M-6i : Description et comparaison des commandes Karel. 4-1

4 PROGRAMMATION DU ROBOT M-6I EN KAREL

Le langage Karel permet de programmer des robots FANUC avec un langage de programmation évolué. Ce chapitre explique certaines différences entre les robots S-10 et M-6i au niveau de leur programmation en Karel.

4.1 Principales évolutions de Karel (RH au R-J3)

Les principaux changements apportés au langage Karel sont : − L’ajout de structure de données dans les types de variables ; − L’ajout de nouvelles variables de localisation (positions de travail) ; − Modification du type parcours (PATH) et ajout d’une nouvelle façon basée sur une

structure de variable ; − Utilisation de plusieurs référentiels pour l’effecteur (TCP) avec le boîtier.

4.2 Structure générale d’un programme

La structure générale d’un programme permet maintenant d’ajouter des structures de variables. Elle a la forme suivante :

PROGRAM nom

Directives au compilateur CONST TYPE VAR Déclaration des routines

BEGIN Énoncés exécutables

END nom

4.3 Type STRUCTURE

La déclaration de structure s’effectue de la façon suivante : TYPE

new_type_name = STRUCTURE field_name_1 : type_name_1 field_name_2 : type_name_2 ... ENDSTRUCTURE

Tous les types de variables peuvent être utilisés comme champs à l’exception des suivants :

− PATH, FILE et déclaration de STRUCTURE ; − Des éléments de cette structure.


Exemple :

TYPE job = STRUCTURE job_name : STRING[20] job_number : INTEGER path_to_do : ARRAY[10] OF INTEGER ENDSTRUCTURE VAR jobs : ARRAY[100] OF job BEGIN current_path = jobs[1].job_number

4.4 Types de variables prédéfinies

A. BOOLEAN, INTEGER, REAL, STRING, VECTOR

Aucune modification par rapport au Karel du S-10.

B. ARRAY<[size{,size}]> OF data_type

Dans la nouvelle version du langage Karel, il est possible de faire un tableau de une à trois (3) dimensions d’un même type en excluant les types ARRAY et PATH. Exemple :

VAR code : ARRAY[5,10] OF INTEGER

C. Type CONFIG

Le type CONFIG est maintenant une structure prédéfinie :

CONFIG = STRUCTURE CFG_TURN_NO1 : INTEGER CFG_TURN_NO2 : INTEGER CFG_TURN_NO3 : INTEGER CFG_FLIP : BOOLEAN CFG_LEFT : BOOLEAN CFG_UP : BOOLEAN CFG_FRONT : BOOLEAN ENDSTRUCTURE

Exemple :

flip = pos_var.cfg_flip


D. XYZWPR

Le type XYZWPR remplace le type POSITION qui a maintenant une nouvelle signification. Le type XYZWPR a la structure suivante :

XYZWPR = STRUCTURE X : REAL -- read-write Y : REAL -- read-write Z : REAL -- read-write W : REAL -- read-write P : REAL -- read-write R : REAL -- read-write CONFIG_DATA : CONFIG -- read-write ENDSTRUCTURE

Exemple :

x1 = p1.x

Il existe aussi XYZWPREXT (XYZWPR + 3 axes auxiliaires).

E. POSITION

Le type POSITION est maintenant une matrice formée de quatre (4) vecteurs : trois (3) vecteurs directeurs pour l’orientation et un vecteur pour la translation. Sa structure est la suivante :

POSITION = STRUCTURE NORMAL : VECTOR -- read-only ORIENT : VECTOR -- read-only APPROACH : VECTOR -- read-only LOCATION : VECTOR -- read-write CONFIG_DATA : CONFIG -- read-write ENDSTRUCTURE

Ce type de variable peut être utilisé comme un référentiel.

Exemple :

Vz = pos_var.approach

F. JOINTPOS

Le type JOINTPOS représente une configuration articulaire regroupant la valeur pour chacune des articulations du robot. La syntaxe est la suivante :

VAR var_joint6 : JOINTPOS<n>


où « n » varie de 1 à 9. Une variable de type JOINTPOS6 peut être une position de travail lorsque le robot à six (6) articulations.

Exemple : extraction de la valeur des axes :

CNV_JPOS_REL(var_joint6, real_array, status)

G. PATH (parcours ou trajectoire)

Le type PATH est une structure prédéfinie où chaque nœud est composé d’une position et de paramètres associés :

TYPE PATH = STRUCTURE node_pos : POSITION in group<n> group_data : GROUP_ASSOC in group<n> common_data : COMMON_ASSOC ENDSTUCTURE GROUP_ASSOC = STUCTURE SEGRELSPEED : INTEGER SEGMOTYPE : INTEGER SEGORIENTYPE: INTEGER SEGBREAK : INTEGER ENDSTRUCTURE COMMON_ASSOC = STUCTURE SEGTERMTYPE : INTERGER SEGDECELTOL : INTEGER ENDSTUCTURE

Le type PATH utilise un PATHHEADER et un NODEDATA par défaut dont la structure du contenu peut être redéfinie. Ce type de variable est global seulement.

H. Parcours modifiés par l’usager

Avec l’utilisation du type STRUCTURE, il est possible de créer des parcours modifiables par l’usager.

a) Entête

L’entête est applicable pour tout le parcours. Un exemple de structure d’entête est :

TYPE hdr_struct = STRUCTURE path_number : INTEGER path_name : STRING[20] frame : POSITION ENDSTRUCTURE

b) Nœuds

Les informations d’un nœud sont applicables à ce dernier seulement. Un exemple de structure de nœud est :


TYPE node_struct = STRUCTURE node_posn : XYZWPR numero_outil : INTEGER vitesse : INTEGER segmotype : INTEGER gun : BOOLEAN ENDSTRUCTURE

c) Déclaration

Avec les déclarations précédentes de l’entête et du format d’un nœud, il est maintenant possible de créer un parcours avec la déclaration suivante :

TYPE -- définition de l’entête hdr_struct -- définition du nœud node_struct usr_path = PATH PATHHEADER = hdr_struct, NODEDATA = node_struct VAR path_1 : usr_path BEGIN … WITH $SPEED = path_1[current_node].vitesse, $MOTYPE = LINEAR MOVE TO path_1[current_node]

d) Exemple de parcours en Karel sur le S-10

Voici une routine utilisant un parcours sur un robot S-10 :

--------------------------------------------------------------------------------------------------------------------------------------------- -- Routine permettant de parcourir un parcours --------------------------------------------------------------------------------------------------------------------------------------------- ROUTINE DoParcours(Parcours : PATH) VAR NodeSegMo, NodeSegTerm, NodeRelSpeed, NodeUTool : INTEGER ActPince, ActSuce1, ActSuce2 : BOOLEAN i : INTEGER BEGIN FOR i = 1 TO PATHLEN(Parcours) DO GET_ASSOC(Parcours, i, SEGMOTYPE, NodeSegMo, SEGTERMTYPE, NodeSegTerm, RELSPEED, NodeRelSpeed, NO_TOOL, NodeUTOOL, PINCE, ActPince, SUCE1, ActSuce1, SUCE2, ActSuce2) SELECT NodeUTOOL OF CASE(1) : $UTOOL = UtoolPince CASE(2) : $UTOOL = UtoolSuce1 CASE(3) : $UTOOL = UtoolSuce2 ENDSELECT WITH $SPEED = 12.*NodeRelSpeed, $MOTYPE = NodeSegMo, $TERMTYPE = NodeSegTerm MOVE TO Parcours[i] IF ActPince THEN

CLOSE HAND 1 ELSE OPEN HAND 1 ENDIF IF ActSuce1 THEN OPEN HAND 2 ELSE CLOSE HAND 2 ENDIF


IF ActSuce2 THEN OPEN HAND 3 ELSE CLOSE HAND 3 ENDIF ENDFOR END DoParcours

e) Exemple de parcours en Karel sur le M-6i

L’utilisation des parcours sur le robot M-6i est différente de celle sur le robot S-10. Étant donné l’apparition des structures dans la nouvelle version de Karel sur le robot M-6i, il n’est plus nécessaire d’avoir des données associées comme sur le robot S-10.

Voici maintenant un exemple utilisant les parcours sur le robot M-6i :

PROGRAM test TYPE hdr_struct = STRUCTURE path_number : INTEGER path_name : STRING[20] uframe : XYZWPR ENDSTRUCTURE node_struct = STRUCTURE node_posn : XYZWPR numero_outil : INTEGER vitesse : INTEGER segmotype : STRING[1] deceleration : INTEGER ENDSTRUCTURE user_path = PATH PATHHEADER = hdr_struct, NODEDATA = node_struct VAR path_1 : user_path … BEGIN … WITH $SPEED = path_1[current_node].vitesse, $MOTYPE = LINEAR MOVE TO path_var[current_node]

Pour le reste, il suffit de se référer à l’exemple pour le robot S-10. Cependant, il faut prendre garde à certaines fonctions (index de celles-ci à la section 5) du robot M-6i qui n’ont pas la même appellation que celles du robot S-10.

I. Variables de système

Il n’y a pas de changement significatif dans les variables de système influençant le mouvement : $SPEED, $MOTYPE, etc. Toutefois, il est possible de créer des groupes de mouvement. De plus, les référentiels de l’effecteur et de la cellule sont gérés différemment.


a) Groupes de mouvement ($GROUP[n])

Sur le robot M-6i, il est possible de commander simultanément un ensemble d’axes ; généralement, des axes auxiliaires (axes supplémentaire commandés par le contrôleur du robot). Il peut y avoir jusqu’à trois (3) groupes définis. Le groupe « 1 » est celui du robot. Le maximum d’axes par groupe est de neuf (9). Le contrôleur peut commander seize (16) axes au maximum.

b) Utilisation d’un référentiel de l’effecteur du boîtier dans un programme Karel

La gestion du changement d’effecteur (outil) sur le robot M-6i est différent de celui sur le robot S-10. Sur le robot S-10, pour changer l’effecteur, il suffit de changer la variable $UTOOL qui est utilisée dans le programme Karel et pour l’enseignement de positions de travail avec le boîtier. Ce qui n’est pas le cas pour le robot M-6i qui possède deux systèmes d’effecteur. Il y a celui se trouvant dans la variable $UTOOL qui sert toujours pour les programmes Karel. Cependant, le système d’outils utilisé pour enseigner des positions et servant pour les programmes TPP n’est pas le même que celui dans la variable $UTOOL. Il se trouve dans la variable $MNUTOOLNUM[1].

Sur le robot M-6i, il est possible d’insérer les transformations d’une dizaine d’outils. Donc, le programmeur n’a pas besoin de savoir ces transformations si elles sont définies dans le contrôleur. Cependant, pour changer le référentiel associé à l’effecteur (outil) des programmes Karel, il faut entrer une position de type XYZWPR. Pour la variable $MNUTOOLNUM[1], il suffit d’entrer l’entier à laquelle l’outil appartient (déjà inscrit dans le contrôleur) pour le rendre actif. Pour utiliser un référentiel de l’effecteur défini sur le boîtier de commande dans un programme en Karel, il faut inclure les instructions suivantes dans la partie exécutable du programme :

$MNUTOOLNUM[n] = tool_nb $GROUP[n].$UTOOL = $MNUTOOL[n,tool_nb]

Le numéro « tool_nb » peut prendre quatre (4) valeurs :

1. Poignet du robot (Tool Plate) ; 2. Coupe de succion #1 ; 3. Coupe de succion #2 ; 4. Pince.

Afin de toujours faire correspondre ces deux variables vers le même effecteur, il suffit de faire comme dans l’exemple suivant :

----------------------------------------------------------------------------------------------------------------- -- File Name : pince.kl ----------------------------------------------------------------------------------------------------------------- -- Ce programme fait correspondre l’effecteur (la pince) du contrôleur avec celui du -- programme Karel PROGRAM pince %COMMENT = 'FORCE LE TOOL PINCE'


----------------------------------------------------------------------------------------------------------------- %INCLUDE klevccdf CONST -- constantes identifiant les numéros d'outils sur le robot M-6i face_plate = 1 active_cup1 = 2 active_cup2 = 3 pince_ferme = 4 ----------------------------------------------------------------------------------------------------------------- -- PROGRAMME PRINCIPAL ----------------------------------------------------------------------------------------------------------------- BEGIN -- pince $MNUTOOLNUM[1] = pince_ferme

$UTOOL = $MNUTOOL[1,$MNUTOOLNUM[1]] WRITE TPERROR(CHR(cc_clear_win),'L”outil ',$MNUTOOLNUM[1],' est maintenant actif.’) END pince

c) Utilisation d’un référentiel de la cellule du boîtier dans un programme Karel

Pour utiliser un référentiel de la cellule ($UFRAME) du boîtier dans un programme Karel, il faut inclure l’instruction suivante dans la partie exécutable du programme :

$GROUP[n].$UFRAME = $MNUFRAME[n,$MNUFRAMENUM[n]]

Par défaut, ils sont déjà égaux :

$UFRAME = $GROUP[1].$UFRAME

4.5 Utilisation des opérateurs

A. Affectation

L’affectation (=) permet de mettre une constante, une variable ou le résultat d’un calcul dans une variable. Généralement, il faut éviter le mode mixte pour éviter des problèmes d’arrondis ou des erreurs à la compilation. Donc, il est préférable, par exemple, d’assigner un résultat entier à une variable entière. Le compilateur permet d’assigner des entiers à une variable réelle, mais il n’est pas souhaitable de le faire à l’inverse.

Les variables de localisation XYZWPR, JOINPOS et POSITION peuvent être assignées mutuellement.

B. Opérations

Il n’y a aucun changement dans la nouvelle version de Karel mis à part l’opérateur « : » qui s’applique aux variables de type POSITION seulement.


4.6 Instructions de mouvement

Les instruction de mouvement n’ont pas changé. La syntaxe est :

With … MOVE … NOWAIT, Signaux d’interruption locaux ENDMOVE

Les commandes MOVE ABOUT, MOVE AWAY, MOVE AXIS et MOVE RELATIVE sont utilisées de la même façon. Toutefois, la commande MOVE ALONG s’applique seulement sur des variables de type PATH. La commande MOVE NEAR utilise seulement des variables de type POSITION. La commande MOVE TO s’applique à toutes les variables de localisation : POSITION, XYZWPREXT, XYZWPR, JOINTPOS et path1[node].

4.7 Énoncés de contrôle

Aucun changement.

4.8 Signaux d’interruption

Aucun changement.

4.9 Lecture (READ)/écriture (WRITE)

Aucun changement.

4.10 Système d’entrées/sorties

A. E/S définies par l’usager

Les signaux d’E/S DIN, DOUT, GIN, GOUT, AIN et AOUT ont toujours la même syntaxe. Toutefois, les signaux de l’effecteur (HAND) ne sont pas définis sur le robot.

B. E/S du système

Le système utilise des entrées/sorties déjà définies : RDI, RDO, OPIN, OPOUT, TPIN et TPOUT.


Le robot possède huit (8) entrées et huit (8) sorties dédiées à l’effecteur (RDI/RDO : Robot Digital I/O). Sur le robot M-6i, la commande des effecteurs est définie comme-suit :

− RDO[1] : pince (FALSE ouvre la pince) ; − RDO[2] : coupe de succion #1 (FALSE désactive la succion) ; − RDO[3] : coupe de succion #2 (FALSE désactive la succion).

Aussi, pour activer/désactiver l’outil désiré, avec le robot S-10, il suffisait d’utiliser les commandes OPEN HAND # et CLOSE HAND #. Pour le robot M-6i, il serait encore possible d’utiliser ces commandes, mais, elles n’ont pas été configurées. Il faut donc utiliser les sorties RDO[#]. Les E/S OPIN/OPOUT sont dédiées au panneau de l’opérateur. Les entrées sont les boutons : Fault Reset, Hold, User PB#1, Cycle Start, etc. Les sorties sont les signaux ProgRun, Cycle Start, TpEnbl, etc. Les entrées/sorties TPIN/TPOUT sont reliées au boîtier de commande (Teach Pendant I/O).


5 DESCRIPTION ET COMPARAISON DES COMMANDES KAREL

Ce chapitre compare des fonctions et procédures du langage Karel des robot S-10 et M-6i. Elle compare également des variables systèmes.

5.1 Langage de programmation Karel

Le Tableau 5.1 présente un index des principales fonctions et commandes utiles à la programmation du robot M-6i et leurs équivalents sur le robot S-10. De plus, la description détaillée des commandes Karel du robot M-6i est donnée en annexe. Tableau 5.1 - Description et comparaison des commandes Karel (M-6i et S-10).

Commandes Karel M-6i S-10

Description

APPEND_NODE APNDPATHNODE Ajoute un nœud non initialisé à la fin d’un PATH passé en paramètre.

APPROACH APPROACH Retourne un vecteur unitaire représentant l’axe Z de la variable position passée en paramètre.

AT NODE AT NODE Condition qui est satisfaite lorsque le nœud d’un PATH a été atteint.

ATTACH ATTACH Donne au programme Karel le contrôle du mouvement du robot suite à la commande RELEASE.

BYNAME BYNAME

Permet à un programme Karel de faire passer une variable (où le nom de celle-ci est un STRING) comme paramètre d’une routine Karel. Ce qui veut dire que le programmeur n’a pas à déterminer le nom de la variable lors de la création et de la compilation du programme.

CONDITION … ENDCONDITION

CONDITION … ENDCONDITION

Défini un signal d’interruption (CONDITION HANDLER) global.

CURPOS CURPOS Retourne la position cartésienne courante du TOOL CENTER POINT (TCP) pour le groupe d’axes passé en paramètre.

DELETE_NODE DELPATHNODE Supprime un nœud d’un PATH. DISABLE

CONDITION DISABLE

CONDITION Désactive le signal d’interruption (CONDITION HANDLER) spécifié en paramètre.

ENABLE CONDITION

ENABLE CONDITION

Active le signal d’interruption (CONDITION HANDLER) spécifié en paramètre.

EVENT EVENT Spécifie un numéro d’événement qui va satisfaire une condition d’interruption ; numéro envoyé lors du déclenchement d’un SIGNAL EVENT.



Description

FRAME FRAME Retourne un système de coordonnées de type POSITION représentant la transformation de trois ou quatre positions spécifiées en paramètre.

----------- GET_ASSOC Va chercher les valeurs des données associées et les distribue à des variables données en paramètre.

IN_RANGE INRANGE Retourne un Booléen dont la valeur indique si oui ou non la position spécifiée en paramètre peut être atteinte par le robot.

INSERT_NODE INSPATHNODE Insère un nœud non initialisé dans le PATH spécifié en paramètre avant le nœud spécifié.

INV INV Permet de faire la matrice inverse d’une variable de type POSITION passée en paramètre.

----------- LOC Retourne la composante (x, y, z) d’une position.

MOVE ABOUT MOVE ABOUT Permet de tourner le TCP en rotation autour d’un vecteur spécifié en paramètre à partir de la position courante du TCP.

MOVE ALONG MOVE ALONG Permet de déplacer le TCP le long d’un parcours de type PATH.

MOVE AWAY MOVE AWAY Permet de retirer le TCP selon l’axe Z négatif du TCP de la position courante en utilisant une valeur réelle en millimètre.

MOVE AXIS MOVE AXIS Permet de déplacer un seul axe (articulation) du robot selon une valeur en degré.

MOVE NEAR MOVE NEAR Permet de déplacer le TCP près de la position spécifiée, c’est-à-dire à la position spécifiée décalée selon l’axe Z négatif du TCP.

MOVE RELATIVE MOVE RELATIVE

Permet de déplacer le TCP selon un vecteur défini dans le référentiel de la cellule (UFRAME).

MOVE TO MOVE TO Permet de déplacer le TCP à la position spécifiée.

OPEN FILE OPEN FILE Associe un fichier de données ou un port de communication à une variable.

ORIENT ORIENT Retourne un vecteur unitaire représentant l’axe Y de la position spécifiée en paramètre.

PATH PATH Permet de définir une variable selon le type de données PATH.

PATH_LEN PATHLEN Retourne le nombre de nœuds d’une variable PATH.

----------- PATHPOS Retourne une variable POSITION équivalente à la position du nœud d’un PATH spécifié en paramètre.

POS POS

Retourne une variable XYZWPR (POSITION sur le robot S-10) composé des arguments de localisation (x, y, z), des arguments d’orientation (w, p, r) et de l’argument de configuration (c).



Description

POSITION -----------

Défini une variable, une valeur de retour d’une routine ou un paramètre d’une routine comme le type de données POSITION :

POSITION = STRUCTURE NORMAL : VECTOR -- read-only ORIENT : VECTOR -- read-only APPROACH : VECTOR -- read-only LOCATION : VECTOR -- read-write CONFIG_DATA : CONFIG -- read-write ENDSTRUCTURE

PURGE CONDITION

PURGE CONDITION

Supprime la définition d’un signal d’interruption (CONDITION HANDLER) global.

----------- POSPATH Permet de copier une variable de type POSITION dans un des nœuds d’une variable de type PATH.

RELEASE RELEASE

Relâche tout contrôle du programme Karel sur le mouvement du robot et des axes auxiliaires pour qu’ils puissent être commandés par le boîtier de commande au cours de l’exécution d’un programme Karel.

----------- SET_ASSOC Permet de fixer les différentes valeurs des données associées d’un nœud à l’intérieur d’un PATH.

----------- SHIFT Permet de translater une variable POSITION (sur le S-10) selon un vecteur exprimé par rapport au référentiel de la cellule.

SIGNAL EVENT SIGNAL EVENT

Signale qu’un événement défini par l’usager est survenu (par exemple, un événement qui satisfaisant une condition dans un signal d’interruption (CONDITION HANDLER)).

STRUCTURE ----------- Permet de définir une structure usager.

UNPOS UNPOS Permet d’avoir les différents arguments (x, y, z, w, p, r, c) d’une variable de type XYZWPR (POSITION sur le robot S-10).

----------- UNVEC Permet d’aller chercher les arguments (x, y, z) d’un vecteur passé en paramètre.

----------- VEC Retourne un vecteur selon les arguments (x, y, z) passés en paramètre.

VECTOR VECTOR Défini une variable selon le type VECTOR.

WAIT FOR WAIT FOR Attente du programme tant qu’une ou plusieurs conditions n’est ou ne sont pas satisfaites.

WHEN WHEN Utilisé pour spécifier une condition et une action dans un signal d’interruption (CONDITION HANDLER) (local ou global).

WITH WITH Utilisé avec l’instruction MOVE pour spécifier localement des valeurs à certaines variables de système.



Description

XYZWPR POSITION

Défini une variable de position de type XYZWPR. XYZWPR = STRUCTURE X : REAL Y : REAL Z : REAL W : REAL P : REAL R : REAL CONFIG_DATA : CONFIG ENDSTRUCTURE

5.2 Variables de système

Le Tableau 5.2 compare et explique des variables de système utilisées par les robots M-6i et S-10.

Tableau 5.2 - Comparaison de certaines variables de système entre les robots M-6i et le S-10.

Variables systèmes M-6i S-10

Description

$MOTYPE ($GROUP[1].$MOTYPE) $MOTYPE

Paramètre de mouvement indiquant le type de déplacement (LINEAR, JOINT, CIRCULAR).

$NILP $NILP Position nulle : POS(0,0,0,0,0,0,c).

$MCR_GRP[1].$prgoverride $PRGOVERRIDE Pourcentage de réduction de la vitesse (1 à 100).

$SEGTERMTYPE ($GROUP[1].$SEGTERMTYPE) $SEGTERMTYPE

Paramètre de mouvement indiquant la terminaison (FINE, COARSE, etc.) par défaut à un nœud d’un parcours de type PATH.

$SPEED ($GROUP[1].$SPEED) $SPEED Paramètre de mouvement spécifiant la vitesse cartésienne (de 0 à 2000).

$TERMTYPE ($GROUP[1].$TERMTYPE) $TERMTYPE

Paramètre de mouvement indiquant la terminaison (FINE, COARSE, etc.).

$UFRAME ($GROUP[1].$UFRAME) $UFRAME

Transformation du référentiel de la cellule (UFRAME) par rapport à celui du robot.

$UTOOL ($GROUP[1].$UTOOL) $UTOOL Transformation du référentiel de l’effecteur (TCP) par rapport à celui du poignet du robot (Face Plate).

Guide d’utilisation du robot M-6i : Description détaillée des commandes Karel. 6-1

6 ANNEXE – DESCRIPTION DES PRINCIPALES COMMANDES DU LANGAGE KAREL

ABORT Action

Purpose : Aborts execution of a running or paused task Syntax : ABORT <PROGRAM[n]> Details:

− If task execution is running or paused, the ABORT action will abort task execution;

− The ABORT action can be followed by the clause PROGRAM[n], where n is the task number to be aborted. Use GET_TASK_INFO to get a task number ;

− If PROGRAM[n] is not specified, the current task execution is aborted. See Also : GET_TSK_INFO Built-in Chapter 6, "Condition Handlers" Example : Refer to Section B.6, "Path Variables and Condition Handlers Program

(PTH_MOVE.KL)," for a detailed program example. ABORT Condition

Purpose : Monitors the aborting of task execution Syntax : ABORT <PROGRAM[n]>

Details:

− The ABORT condition is satisfied when the task is aborted. The actions specified by the condition handler will be performed ;

− If PROGRAM [n] is not specified, the current task number is used ; − Actions that are routine calls will not be executed if task execution is aborted ; − The ABORT condition can be followed by the clause PROGRAM[n], where n is

the task number to be monitored. Use GET_TSK_INFO to get a task number. See Also : CONDITION... ENDCONDITION Statement GET_TSK_INFO Built-in Chapter 6, "Condition Handlers" Appendix E, “Syntax Diagrams” for additional syntax information Example : Refer to the following sections for detailed program examples:

− Section B.6, "Path Variables and Condition Handlers Program" (PTH_MOVE.KL).

− Section B.10, "Using Dynamic Display Built-ins" (DYN_DISP.KL). ABORT Statement

Purpose : Terminates task execution and cancels any motion in progress (or pending) Syntax : ABORT <PROGRAM[n]>


Details:

− After an ABORT, the program cannot be resumed. It must be restarted ; − The statement can be followed by the clause PROGRAM[n], where n is the task

number to be aborted. See Also : Appendix E, « Syntax Diagrams », for additional syntax information Example : Refer to the following sections for detailed program examples:

− Section B.2, "Copying Path Variables" (CPY_PTH.KL) ; − Section B.6, "Path Variables and Condition Handlers Program" (PTH_MOVE.KL)

; − Section B.12, "Displaying a List From a Dictionary File" (DCLST_EX.KL) ; − Section B.1, "Setting Up Digital Output Ports for Monitoring" (DOUT_EX.KL).

ABS Built-In Function

Purpose : Returns the absolute value of the argument x, which can be an INTEGER or REAL expression

Syntax : ABS(x) Function Return Type:INTEGER or REAL Input/Output Parameters:

[in] x:INTEGER or REAL expression %ENVIRONMENT Group:SYSTEM Details:

− Returns the absolute value of x, with the same data type as x. Example : Refer to Section B.7, "Listing Files and Programs and Manipulating Strings

(LIST_EX.KL)," for a detailed program example. ACOS Built-In Function

Purpose : Returns the arc cosine (cos-1) in degrees of the specified argument Syntax : ACOS(x) Function Return Type:REAL Input/Output Parameters:

[in] x:REAL %ENVIRONMENT Group:SYSTEM Details:

− x must be between -1.0 and 1.0, otherwise the program will abort with an error. − Returns the arccosine of x.

Example : The following example sets ans_r to the arccosine of -1 and writes this value to the screen. The output for the following example is 180 degrees.

ROUTINE take_acos VAR ans_r : REAL BEGIN ans_r = ACOS(-1.) WRITE ('acos -1 ', ans_r, CR) END take_acos

The second example causes the program to abort since the input value is less than -1 and not within the valid range :


ROUTINE take_acos VAR ans_r : REAL BEGIN ans_r = ACOS (-1.5) -- causes program to abort WRITE ('acos -1.5 ', ans_r, CR) END take_acos APPEND_NODE Built-In Procedure

Purpose : Adds an uninitialized node to the end of the PATH argument Syntax : APPEND_NODE(path_var, status) Input/Output Parameters:

[in] path_ var:PATH [out] stat us:INTEGER %ENVIRONMENT Group:PBCORE

Details: − path_var is the path variable to which the node is appended. − The appended PATH node is uninitialized. The node can be assigned values by

directly referencing its NODEDATA structure. − Status explains the status of the attempted operation. If not equal to 0, then an

error occurred. See Also : DELETE_NODE, INSERT_NODE Built-In Procedures Example : Refer to Section B.2, "Copying Path Variables" (CPY_PTH.KL), for a

detailed program example. APPROACH Built-In Function

Purpose : Returns a unit VECTOR representing the z-axis of a POSITION argument Syntax : APPROACH(posn) Function Return Type:VECTOR Input/Output Parameters:

[in] posn:POSITION %ENVIRONMENT Group:VECTOR Details:

− Returns a VECTOR consisting of the approach vector (positive z-axis) of the argument posn.

Example : This program allows you to move the TCP to a position that is 500 mm away from another position along the z-axis.

PROGRAM p_approach VAR start_pos : POSITION app_vector : VECTOR BEGIN MOVE TO start_pos app_vector = APPROACH (start_pos) -- app_vector equal to the z-axis of start_pos --moves start_pos + 500 mm along z-axis of start_pos start_pos.location = start_pos.location + app_vector *500. WITH $MOTYPE = LINEAR, MOVE TO start_pos END p_approach


NOTE: Approach has been left in for older versions of KAREL. You should now directly access the vectors of a POSITION (i.e., posn. approach.)

ARRAY Data Type

Purpose : Defines a variable, function return type, or routine parameter as ARRAY data type

Syntax : ARRAY<[size{,size}]> OF data_type where:

size : an INTEGER literal or constant data_type : any type except PATH

Details: − size indicates the number of elements in an ARRAY variable. − size must be in the range 1 through 32767 and must be specified in a normal

ARRAY variable declaration. The amount of available memory in your controller might restrict the maximum size of an ARRAY.

− Individual elements are referenced by the ARRAY name and the subscript size. For example, table[1] refers to the first element in the ARRAY table.

− An entire ARRAY can be used only in assignment statements or as an argument in routine calls. In an assignment statement, both ARRAY variables must be of the same size and data_type. If size is different, the program will be translated successfully but will be aborted during execution, with error 12304, "Array Length Mismatch."

− size is not specified when declaring ARRAY routine parameters; an ARRAY of any size can be passed as an ARRAY parameter to a routine.

− size is not used when declaring an ARRAY return type for a function. However, the returned ARRAY must be of the same size as the ARRAY to which it is assigned in the function call.

− Each element is of the same type designated by data_ty pe. − Valid ARRAY operators correspond to the valid operators of the individual

elements in the ARRAY. − Individual elements of an array can be read or written only in the format that

corresponds to the data type of the ARRAY. − Arrays of multiple dimensions can be defined. Refer to Chap. 2 for more info. − Variable-sized arrays can be defined. Refer to Chapter 2 for more information.

See Also : ARRAY_LEN Built-In Function Chapter 5, “Routines”, for information on passing ARRAY variables as

arguments in routine calls. Chapter 7, “File Input/Output Operations” Example : Refer to the following sections for detailed program examples:

− Section B.2, "Copying Path Variables" (CPY_PTH.KL) − Section B.8, "Generating and Moving Along a Hexagon Path" (GEN_HEX.KL) − Section B.9, "Using the File and Device Built-ins" (FILE_EX.KL) − Section B.12, "Displaying a List From a Dictionary File" (DCLST_EX.KL) − Section B.16, "Applying Offsets to a Copied TPP" (CPY_TP.KL)


ARRAY_LEN Built-In Function Purpose : Returns the number of elements contained in the specified array argument Syntax : ARRAY_LEN(ary_var) Function Return Type:INTEGER Input/Output Parameters:

[in] ary_v ar:ARRAY %ENVIRONMENT Group:SYSTEM − The returned value is the number of elements declared for ary_var, not the

number of elements that have been initialized in ary_var. Example : Refer to Section B.7, "Listing Files and Programs and Manipulating Strings"

(LIST_EX.KL), for a detailed program example. ASIN Built-In Function

Purpose : Returns arcsine (sin-1) in degrees of the specified argument Syntax : ASIN(x) Function Return Type:REAL Input/Output Parameters:

[in] x:REAL %ENVIRONMENT Group:SYSTEM Details:

− Returns the arcsine of x. − x must be between -1 and 1, otherwise the program will abort with an error.

Example : The following example sets ans_r to the arcsine of -1 and writes this value to the screen. The output for the following example is -90 degrees.

ROUTINE take_asin VAR ans_r : REAL BEGIN ans_r = ASIN (-1.) WRITE ('asin -1 ', ans_r, CR) END take_asin

The second example causes the program to abort since the input value is less than -1 and not within the valid range.

ROUTINE take_asin VAR ans_r : REAL BEGIN ans_r = ASIN (-1.5) -- causes program to abort WRITE ('asin -1.5 ', ans_r, CR) END take_asin AT NODE Condition

Purpose : Condition is satisfied when a specified PATH node or position has been reached Syntax : AT NODE[n]


where: n : an INTEGER expression or * (asterisk)

Details: − The AT NODE condition can be used only in local condition handlers. − If the move is along a PATH or to a path node, n specifies the path node. If n is a

wildcard (*) or negative one (-1), any node will satisfy the AT NODE condition. − If the move is to a position, n = 1 (node 1) can be used to indicate the destination. − If n is greater than the length of the path (or greater than 1 if the move is to a

position), the condition is never satisfied. − If n is less than zero or greater than 1000, the program is aborted with an error.

See Also : Chapter 6, “Condition Handlers,” for more information on synchronizing local condition handlers with the motion environment. PATH_LEN Built-In Function.

Example : Refer to Section B.1, "Setting Up Digital Output Ports for Monitoring" (DOUT_EX.KL) for a detailed program example.

ATAN2 Built-In Function

Purpose : Returns a REAL angle, measured counterclockwise in degrees, from the positive x-axis to a line connecting the origin and a point whose x- and y- coordinates are specified as the x- and y- arguments

Syntax : ATAN2(x1, y1) Function Return Type:REAL Input/Output Parameters:

[in] x1 : REAL [in] y1 : REAL %ENVIRONMENT Group:SYSTEM

Details: − x1 and y1 specify the x and y coordinates of the point. − If x1 and y1 are both zero, the interpreter will abort the program.

Example : The following example uses the values 100, 200, and 300 respectively for x, y, and z to compute the orientation component direction. The position, p1 is then defined to be a position with direction as its orientation component.

PROGRAM p_atan2 VAR p1 : POSITION x, y, z, direction : REAL BEGIN X = 100. -- use appropriate values for x,y,z on your robot Y = 200. Z = 300. direction = ATAN2(x, y) p1 = POS(x, y, z, 0., 0., direction, 'n') -- r orientation component MOVE TO p1 -- of POS equals angle END p_atan2 -- returned by ATAN2(100.,200.)


ATTACH Statement

Purpose : Gives the KAREL program control of motion for the robot arm and auxiliary and extended axes

Syntax : ATTACH Details:

− Used with the RELEASE statement. If motion control is not currently released from program control, the ATTACH statement has no effect.

− If the teach pendant is still enabled, execution of the KAREL program is delayed until the teach pendant is disabled. The task status will show a hold of "attach done."

− Stopped motions can only be resumed following execution of the ATTACH statement.

See Also : RELEASE Statement Chapter 8, “Motion” for more information on motion control. Appendix E, “Syntax Diagrams,” for additional syntax information Example : Refer to Section B.1, "Setting Up Digital Output Ports for Monitoring"

(DOUT_EX.KL) for a detailed program example. BYNAME Built-In Function

Purpose : Allows a KAREL program to pass a variable, whose name is contained in a STRING, as a parameter to a KAREL routine. This means the programmer does not have to determine the variable name during program creation and translation.

Syntax : BYNAME (prog_name, var_name, entry) Input/Output Parameters:

[in] prog_ name :STRING [in] var_n ame :STRING [in,out] entry :INTEGER %ENVIRONMENT Group:system

Details: − This built-in can be used only to pass a parameter to a KAREL routine. − entry returns the entry number in the variable data table where var_name is

located. This variable does not need to be initialized and should not be modified. − prog_name specifies the name of the program that contains the specified variable.

If prog_name is equal to “ (double quotes), then the routine defaults to the task name being executed.

− var_name must refer to a static, program variable. − If var_name does not contain a valid variable name or if the variable is not of the

type expected as a routine parameter, the program is aborted. − System variables cannot be passed using BYNAME. − The PATH data type cannot be passed using BYNAME. However, a user-defined

type that is a PATH can be used instead. Example : Refer to Section B.2, "Copying Path Variables" (CPY_PTH.KL), for a

detailed program example.


CALL_PROG Built-In Procedure

Purpose : Allows a KAREL program to call an external KAREL or teach pendant program. This means that the programmer does not have to determine the program to be called until run time.

Syntax : CALL_PROG(prog_name, prog_index) Input/Output Parameters:

[in] prog_ name : STRING [in,out] p rog_index : INTEGER %ENVIRONMENT Group:PBCORE

Details: − prog_name is the name of the program to be executed, in the current calling task. − prog_index returns the entry number in the program table where prog_name is

located. This variable does not need to be initialized and should not be modified. − CALL_PROG cannot be used to run internal or external routines.

See Also : CURR_PROG and CALL_PROGLIN Built-In Functions Example : Refer to Section B.2, "Copying Path Variables" (CPY_PTH.KL), for a

detailed program example. CANCEL Action

Purpose : Terminates any motion in progress Syntax : CANCEL <GROUP[n{,n}]> Details:

− Cancels a motion currently in progress or pending (but not stopped) for one or more groups.

− CANCEL does not cancel motions that are already stopped. To cancel a motion that is already stopped, use the CNCL_STP_MTN built-in routine.

− If the group clause is not present, all groups for which the task has control (when the condition is defined) will be canceled. In particular, if the program containing the condition handler definition contains the %NOLOCKGROUP directive, the CANCEL action will not cancel motion in any group.

− If a motion that is canceled and is part of a SIMULTANEOUS or COORDINATED motion with other groups, the motions for all groups are canceled.

− The robot and auxiliary or extended axes decelerate smoothly to a stop. The remainder of the motion is canceled.

− Canceled motions are treated as completed and cannot be resumed. − The CANCEL action in a global condition handler also cancels any pending

motions. − The CANCEL action in a local condition handler cancels only the motion in

progress, permitting any pending motions to start. Example : The following example uses a local condition handler to cancel only the

current motion in progress.


MOVE ALONG some_path, WHEN AT NODE[n] DO CANCEL ENDMOVE CANCEL Statement

Purpose : Terminates any motion in progress. Syntax : CANCEL <GROUP[n{,n}]> Details:

− Cancels a motion currently in progress or pending (but not stopped) for one or more groups.

− CANCEL does not cancel motions that are already stopped. To cancel a motion that is already stopped, use the CNCL_STP_MTN built-in routine.

− If the group clause is not present, all groups for which the task has control will be canceled. In particular, if the program using the CANCEL statement contains the %NOLOCKGROUP directive, the CANCEL statement will not cancel motion in any group.

− If a motion that is canceled is part of a SIMULTANEOUS or COORDINATED motion with other groups, the motions for all groups are canceled.

− The robot and auxiliary axes decelerate smoothly to a stop. The remainder of the motion is canceled.

− Canceled motions are treated as completed and cannot be resumed. − CANCEL does not affect stopped motions. Stopped motions can be resumed. − If an interrupt routine executes a CANCEL statement and the interrupted statement

was a motion statement, when the interrupted program resumes, execution normally resumes with the statement following the motion statement.

− CANCEL may not work as expected if it is used in a routine called by a condition handler. The motion may already be put on the stopped motion queue before the routine is called. Use a CANCEL action directly in the condition handler to be sure the motion is canceled.

− Motion cannot be cancelled for a different task. See Also : Appendix E, “Syntax Diagrams,” for additional syntax information Example : The following example cancels the current motion if DIN[stop] is ON.

MOVE ALONG some_path NOWAIT IF DIN[stop] THEN WRITE ('Motion canceled',CR) CANCEL ENDIF CLOSE FILE Statement

Purpose : Breaks the association between a FILE variable and a data file or communication port

Syntax : CLOSE FILE file_var where:

file_var : a FILE variable


Details: − file_var must be a static variable that was used in the OPEN FILE statement. − Any buffered data associated with the file_var is written to the file or port. − The built-in function IO_STATUS will always return zero.

See Also : IO_STATUS Built-In Function Chapter 7, “File Input/Output Operations” Appendix E, “Syntax Diagrams,” for additional syntax information Example : Refer to Section B.12, "Displaying a List From a Dictionary File"

(DCLST_EX.KL), for a detailed program example. COMMON_ASSOC Data Type

Purpose : Defines a variable or structure field as a COMMON_ASSOC data type Syntax : COMMON_ASSOC Details:

− COMMON_ASSOC consists of a record containing standard associated data common for all motion groups. It contains the following predefined fields, all INTEGERs:

· SEGTERMTYPE:termination type · SEGDECELTOL:deceleration tolerance · SEGRELACCEL:not implemented · SEGTIMESHFT:not implemented

− Variables and fields of structures can be declared as COMMON_ASSOC. − Subfields of this structure can be accessed and set using the usual structure field

notation. − Variables and fields declared COMMON_ASSOC can be:

· Passed as parameters. · Written to and read from unformatted files. · Assigned to one another.

− Each subfield of a COMMON_ASSOC variable or structure field can be passed as a parameter to a routine, but is always passed by value.

See Also : Section 8.4.7, "Path Motion," for default values Section 2.1.6, "Predefined Identifiers" Example : Refer to Section B.2, "Copying Path Variables" (CPY_PTH.KL), for a

detailed program example. CONDITION...ENDCONDITION Statement

Purpose : Defines a global condition handler Syntax : CONDITION[cond_hand_no]: [with_list] WHEN cond_list DO action_list {WHEN cond_list DO action_list} ENDCONDITION


Details: − cond_hand_no specifies the number associated with the condition handler and

must be in the range of 1-1000. The program is aborted with an error if it is outside this range.

− If a condition handler with the specified number already exists, the old one is replaced with the new one.

− The optional [with_list] can be used to specify condition handler qualifiers. See the WITH clause for more information.

− All of the conditions listed in a single WHEN clause must be satisfied simultaneously for the condition handler to be triggered.

− Multiple conditions must all be separated by the AND operator or the OR operator. Mixing of AND and OR is not allowed.

− The actions listed after DO are to be taken when the corresponding conditions of a WHEN clause are satisfied simultaneously.

− Multiple actions are separated by a comma or on a new line. − Calls to function routines are not allowed in a CONDITION statement. − The condition handler is initially disabled and is disabled again whenever it is

triggered. Use the ENABLE statement or action, specifying the condition handler number, to enable it.

− Use the DISABLE statement or action to deactivate a condition handler. − The condition handler remains defined and can subsequently be reactivated by the

ENABLE statement or action. − The PURGE statement can be used to delete the definition of a condition handler. − Condition handlers are known only to the task which defines them. Two different

tasks can use the same cond_hand_no even though they specify different conditions.

See Also : Chapter 6, “Condition Handlers” Appendix E, “Syntax Diagrams,” for additional syntax information Example : Refer to the following sections for detailed program examples: Section B.6, "Path Variables and Condition Handlers Program"

(PTH_MOVE.KL) Section B.1, "Setting Up Digital Output Ports for Monitoring"

(DOUT_EX.KL) CONFIG Data Type

Purpose : Defines a variable or structure field as a CONFIG data type Syntax : CONFIG Details:

− CONFIG defines a variable or structure field as a highly compact structure consisting of fields defining a robot configuration.

− CONFIG contains the following predefined fields: · CFG_TURN_NO1 : INTEGER · CFG_TURN_NO2 : INTEGER · CFG_TURN_NO3 : INTEGER


· CFG_FLIP : BOOLEAN · CFG_LEFT : BOOLEAN · CFG_UP : BOOLEAN · CFG_FRONT : BOOLEAN

− Variables and fields of structures can be declared as CONFIG. − Subfields of CONFIG data type can be accessed and set using the usual structure

field notation. − Variables and fields declared as CONFIG can be

· Assigned to one another. · Passed as parameters. · Written to and read from unformatted files.

− Each subfield of a CONFIG variable or structure field can be passed as a parameter to a routine, but is always passed by value.

− A CONFIG field is part of every POSITION and XYZWPR variable and field. − An attempt to assign a value to a CONFIG subfield that is too large for the field

results in an abort error. Example: The following example shows how subfields of the CONFIG structure can

be accessed and set using the usual structure.field notation. VAR config_var1 config_var2 : CONFIG pos_var : POSITION seam_path : PATH I : INTEGER BEGIN config_var1 = pos_var.config_data config_var2 = config_var1 config_var1.cfg_turn_no1 = 0 IF pos_var.pos_config_data.cfg_flip THEN... FOR i = 1 TO PATH_LEN(seam_path) DO seam_path[i].node_pos.pos_config = config_ar1 ENDFOR

CONNECT TIMER Statement

Purpose : Causes an INTEGER variable to start being updated as a millisecond clock Syntax : CONNECT TIMER TO clock_var

where: clock_var : a static, user-defined INTEGER variable

Details: − clock_var is presently incremented by the value of the system variable

$SCR.$COND_TIME every $SCR.$COND_TIME milliseconds as long as the program is running or paused and continues until the program disconnects the timer, ends, or aborts. For example, if $SCR.$COND_TIM E=32 then clock_var will be incremented by 32 every 32 milliseconds.

− You should initialize clock_var before using the CONNECT TIMER statement to ensure a proper starting value.

− If the variable is uninitialized, it will remain so for a short period of time (up to 32 milliseconds) and then it will be set to a very large negative value (-2.0E31 + 32 milliseconds) and incremented from that value.


− The program can reset the clock_var to any value while it is connected. − A clock_var initialized at zero wraps around from approximately two billion to

approximately minus two billion after about 23 days. − If clock_var is a system variable or a local variable in a routine, the program

cannot be translated. NOTE : If two CONNECT TIMER statements using the same variable, are executed in two different tasks, the timer will advance twice as fast. For example, the timer will be incremented by 2 * $SCR.$COND_TIME every $SCR.$COND_TIME ms. However, this does not occur if two or more CONNECT TIMER statements using the same variable, are executed in the same task.

See Also : Appendix D, “Syntax Diagrams,” for additional syntax information DISCONNECT TIMER Statement Example : Refer to the following sections for detailed program examples: Section B.8, "Generating and Moving Along a Hexagon Path"

(GEN_HEX.KL) Section B.1, "Setting Up Digital Output Ports for Monitoring"

(DOUT_EX.KL)

CONTINUE Action

Purpose : Continues execution of a paused task Syntax : CONTINUE <PROGRAM[n]> Details:

− The CONTINUE action will not resume stopped motions. − If program execution is paused, the CONTINUE action will continue program

execution. − The CONTINUE action can be followed by the clause PROGRAM[n], where n is

the task number to be continued. Use GET_TSK_INFO to get a task number for a specified task name.

− A task can be in an interrupt routine when CONTINUE is executed. However, you should be aware of the following circumstances because CONTINUE only affects the current interrupt level, and interrupt levels of a task might be independently paused or running.

· If the interrupt routine and the task are both paused, CONTINUE will continue the interrupt routine but the task will remain paused.

· If the interrupt routine is running and the task is paused, CONTINUE will appear to have no effect because it will try to continue the running interrupt routine.

· If the interrupt routine is paused and the task is running, CONTINUE will continue the interrupt routine.

Example : Refer to Section B.1, "Setting Up Digital Output Ports for Monitoring" (DOUT_EX.KL) for a detailed program example.


CONTINUE Condition

Purpose : Condition that is satisfied when program execution is continued Syntax : CONTINUE <PROGRAM[n]> Details:

− The CONTINUE condition monitors program execution. − If program execution is paused, the CONTINUE action, issuing CONTINUE from

the CRT/KB or a CYCLE START from the operator panel, will continue program execution and satisfy the CONTINUE condition.

− The CONTINUE condition can be followed by the clause PROGRAM[n], where n is the task number to be continued. Use GET_TSK_INFO to get the task number of a specified task name.

Example : In the following example, program execution is being monitored. When the program is continued, a digital output will be turned on.

CONDITION[stop]: WHEN CONTINUE DO DOUT[conveyor] = OFF ENDCONDITION

COS Built-In Function

Purpose : Returns the REAL cosine of the REAL angle argument, specified in degrees Syntax : COS(angle) Function Return Type:REAL Input/Output Parameters:

[in] angle:REAL expression %ENVIRONMENT Group:SYSTEM Details:

− angle is an angle specified in the range of ± 18000 degrees. Otherwise, the program will be aborted with an error.

Example : Refer to Section B.8, "Generating and Moving Along a Hexagon Path" (GEN_HEX.KL), for a detailed program example.

CURPOS Built-In Function

Purpose : Returns the current Cartesian position of the tool center point (TCP) for the specified group of axes even if one of the axes is in an overtravel

Syntax : CURPOS(axis_limit_mask, ovr_trv_mask <,group_no>) Function Return Type:XYZWPREXT

Input/Output Parameters:

[out] axis _limit_mask : INTEGER [out] ovr_ trv_mask : INTEGER [in] group _no : INTEGER %ENVIRONMENT Group:SYSTEM

Details: − If group_no is omitted, the default group for the program is assumed. − If group_no is specified, it must be in the range of 1 to the total number of groups

defined on the controller.


− The group must be kinematic. − Returns the current position of the tool center point (TCP) relative to the current

value of the system variable $UFRAME for the specified group. − axis_limit_mask specifies which axes are outside the axis limits. − ovr_trv_mask specifies which axes are in overtravel.

NOTE : axis_limit_mask and ovr_trv_mask are not available in this release and will be ignored if set.

See Also : Chapter 8, “Motion” Example : Refer to Section B.5,"Using Register Built-ins," for a detailed program

example. Section B.5,"Using Register Built-ins" (REG_EX.KL). Section B.1, "Setting Up Digital Output Ports for Monitoring"

(DOUT_EX.KL).

DELETE_NODE Built-In Procedure

Purpose : Deletes a path node from a PATH Syntax : DELETE_NODE(path_var, node_num, status) Input/Output Parameters:

[in] path_ var : PATH [in] node_ num : INTEGER [out] stat us : INTEGER %ENVIRONMENT Group:PATHOP

Details: − node_num specifies the node to be deleted from the PATH specified by path_var. − All nodes past the deleted node will be renumbered. − node_num must be in the range from one to PATH_LEN(path_var). If it is outside

this range, the status is returned with an error. − status explains the status of the attempted operation. If not equal to 0, then an error

occurred. See Also : APPEND_NODE, INSERT_NODE Built-In Procedures Example : Refer to Section B.2, "Copying Path Variables" (CPY_PTH.KL), for a

detailed program example. DISABLE CONDITION Action

Purpose : Used within a condition handler to disable the specified condition handler Syntax : DISABLE CONDITION [cond_hand_no]

where: cond_hand_no:an INTEGER expression

Details: − If the condition handler is not defined, DISABLE CONDITION has no effect. − If the condition handler is defined but not currently enabled, DISABLE

CONDITION has no effect.


− When a condition handler is disabled, its conditions are not tested. Thus, if it is activated again, the conditions must be satisfied after the activation.

− Use the ENABLE CONDITION statement or action to reactivate a condition handler that has been disabled.

− cond_hand_no must be in the range of 1-1000. Otherwise, the program will be aborted with an error.

See Also : Chapter 6, “Condition Handlers,” for more information on using DISABLE CONDITION in condition handlers

Example : The following example disables condition handler number “stop” when condition number “start” is triggered.

CONDITION[start]: WHEN EVENT[go] DO DISABLE CONDITION[stop] ENDCONDITION DISABLE CONDITION Statement

Purpose : Disables the specified condition handler Syntax : DISABLE CONDITION [cond_hand_no]

where: cond_hand_no : an INTEGER expression Details:

− If the condition handler is not defined, DISABLE CONDITION has no effect. − If the condition handler is defined but not currently enabled, DISABLE

CONDITION has no effect. − When a condition handler is disabled, its conditions are not tested. Thus, if it is

activated again, the conditions must be satisfied after the activation. − Use the ENABLE CONDITION statement or action to reactivate a condition

handler that has been disabled. − cond_hand_no must be in the range of 1-1000. Otherwise, the program will be

aborted with an error. See Also : Chapter 6, “Condition Handlers,” for more information on using DISABLE

CONDITION in condition handlers Appendix E, “Syntax Diagrams,” for additional syntax information Example : The following example allows the operator to choose whether or not to see

count. PROGRAM p_disable VAR count : INTEGER answer : STRING[1] ROUTINE showcount BEGIN WRITE ('count = ',count::10,CR) END showcount


BEGIN CONDITION[stop] : WHEN EVENT[stop] DO -- Condition[stop] shows count showcount ENABLE CONDITION[stop] ENDCONDITION ENABLE CONDITION[stop] count = 0 WRITE ('do you want to see count?') READ (answer,CR) IF answer = 'n' THEN DISABLE CONDITION[stop] -- Disables condition[stop] ENDIF -- Count will not be shown FOR count = 1 TO 13 DO SIGNAL EVENT[1] ENDFOR END p_disable DISCONNECT TIMER Statement

Purpose : Stops updating a clock variable previously connected as a timer Syntax : DISCONNECT TIMER timer_var

where: timer_var : a static, user-defined INTEGER variable Details:

− If timer_var is not currently connected as a timer, the DISCONNECT TIMER statement has no effect.

− If timer_var is a system or local variable, the program will not be translated. See Also : Appendix E, “Syntax Diagrams,” for additional syntax information CONNECT TIMER Statement Example : The following example moves the TCP to the initial POSITION variable p1,

sets the INTEGER variable timevar to 0 and connects the timer. After moving to the destination position p2, the timer is disconnected.

MOVE TO p1 timevar = 0 CONNECT TIMER TO timevar MOVE TO p2 DISCONNECT TIMER timevar ENABLE CONDITION Action

Purpose : Enables the specified condition handler Syntax : ENABLE CONDITION [cond_hand_no]


− ENABLE CONDITION has no effect when · The condition handler is not defined · The condition handler is defined but is already enabled



− When a condition handler is enabled, its conditions are tested each time the condition handler is scanned. If the conditions are satisfied, the corresponding actions are performed and the condition handler is deactivated. Issue an ENABLE CONDITION statement or action to reactivate it.

− Use the DISABLE CONDITION statement or action to deactivate a condition handler that has been enabled.

− Condition handlers are known only to the task which defines them. One task cannot enable another tasks condition.

See Also : DISABLE CONDITION Action Chapter 6,”Condition Handlers” Example : Refer to Section B.1, "Setting Up Digital Output Ports for Monitoring"

(DOUT_EX.KL) for a detailed program example. ENABLE CONDITION Statement

Purpose : Enables the specified condition handler Syntax : ENABLE CONDITION [cond_hand_no]


− ENABLE CONDITION has no effect when · The condition handler is not defined · The condition handler is defined but is already enabled


− When a condition handler is enabled, its conditions are tested each time the condition handler is scanned. If the conditions are satisfied, the corresponding actions are performed and the condition handler is deactivated. Issue an ENABLE CONDITION statement or action to reactivate it.

− Use the DISABLE CONDITION statement or action to deactivate a condition handler that has been enabled.

− Condition handlers are known only to the task which defines them. One task cannot enable another tasks condition.

See Also : DISABLE CONDITION Statement Chapter 6, “Condition Handlers” Appendix E, “Syntax Diagrams,” for additional syntax information Example : Refer to the following sections for detailed program examples. Section B.6, "Path Variables and Condition Handlers Program"

(PTH_MOV.KL). Section B.1, "Setting Up Digital Output Ports for Monitoring"

(DOUT_EX.KL).


ERROR Condition

Purpose : Specifies an error as a condition Syntax : ERROR[n]

where: n : an INTEGER expression or asterisk (*) Details:

− If n is an INTEGER, it represents an error code number. The condition is satisfied when the specified error occurs.

− If n is an asterisk (*), it represents a wildcard. The condition is satisfied when any error occurs.

− The condition is an event condition, meaning it is satisfied only for the scan performed when the error was detected. The error is not remembered on subsequent scans.

See Also : Chapter 6, “Condition Handlers,” for more information on using conditions. The appropriate application-specific FANUC Robotics SYSTEM R-J3

Controller Setup and Operations Manual for a list of all error codes Example : Refer to Section B.1, "Setting Up Digital Output Ports for Monitoring"

(DOUT_EX.KL) for a detailed program example. EVAL Clause

Purpose : Allows expressions to be evaluated in a condition handler definition Syntax : EVAL(expression)

where: expression : a valid KAREL expression

Details: − expression is evaluated when the condition handler is defined, rather than

dynamically during scanning. − expression can be any valid expression that does not contain a function call.

See Also : Chapter 6, “Condition Handlers”, for more information on using conditions Example : The following example uses a local condition handler to move to the

position far_pos until AIN[force ] is greater than the evaluated expression (10. * f_scale ).

WRITE ('Enter force scale: ') READ (f_scale) MOVE TO far_pos, UNTIL AIN[force] > EVAL(10. * f_scale) ENDMOVE

EVENT Condition

Purpose : Specifies the number of an event that satisfies a condition when a SIGNAL EVENT statement or action with that event number is executed

Syntax : EVENT[event_no]


where: event_no : is an INTEGER expression Details:

− Events can be used as user-defined event codes that become TRUE when signaled. − The SIGNAL EVENT statement or action is used to signal that an event has

occurred. − event_no must be in the range of -32768 to 32767.

See Also : SIGNAL EVENT Action, and CONDITION or SIGNAL EVENT Statement Example : Refer to Section B.1, "Setting Up Digital Output Ports for Monitoring"

(DOUT_EX.KL) for a detailed program example. EXP Built-In Function

Purpose : Returns a REAL value equal to e (approximately 2.71828) raised to the power specified by a REAL argument

Syntax : EXP(x) Function Return Type:REAL Input/Output Parameters:

[in] x : REAL %ENVIRONMENT Group:SYSTEM Details:

− EXP returns e (base of the natural logarithm) raised to the power x. − x must be less than 80. Otherwise, the program will be paused with an error.

Example : The following example uses the EXP Built-In to evaluate the exponent of the expression (-6.44 + timevar/(timevar + 20.)).

WRITE (CR, 'Enter time needed for move:') READ (timevar) distance = timevar * EXP(-6.44 + timevar/(timevar + 20.)) WRITE (CR, CR, 'Distance for move:', distance::10::3) FRAME Built-In Function

Purpose : Returns a frame with a POSITION data type representing the transformation to the coordinate frame specified by three (or four) POSITION arguments.

Syntax : FRAME(pos1, pos2, pos3 <,pos4>) Function Return Type:Position Input/Output Parameters:

[in]pos1: POSITION [in]pos2: POSITION [in]pos3: POSITION [in]pos4: POSITION %ENVIRONMENT Group:system

Details: − The returned value is computed as follows:

· pos1 is assumed to be the origin unless a pos4 argument is supplied. See Figure A-1.

· If pos4 is supplied, the origin is shifted to pos4, and the new coordinate frame retains the same orientation in space as the first coordinate frame. See Figure 6.1.

· The x-axis is parallel to a line from pos1 to pos2.


· The xy-plane is defined to be that plane containing pos1, pos2, and pos3, with pos3 in the positive half of the plane.

· The y-axis is perpendicular to the x-axis and in the xy-plane. · The z-axis is through pos1 and perpendicular to the xy-plane. The positive

direction is determined by the right hand rule. · The configuration of the result is set to that of pos1, or pos4 if it is supplied.

− pos1 and pos2 arguments must be at least 10 millimeters apart and pos3 must be at least 10 millimeters away from the line connecting pos1 and pos2. If either condition is not met, the program is paused with an error.

Figure 6.1 - FRAME Built-In Function.

Example : The following example allows the operator to set a frame to a pallet so that a

palletizing routine will be able to move the TCP along the x, y, z direction in the pallet's coordinate frame.

WRITE('Teach corner_1, corner_2, corner_3',CR) RELEASE -- Allows operator to turn on teach pendant and teach positions ATTACH -- Returns motion control to program $UFRAME = FRAME (corner_1, corner_2, corner_3) GROUP_ASSOC Data Type

Purpose : Declares a variable or structure field as a GROUP_ASSOC data type Syntax : GROUP_ASSOC <IN GROUP[n]> Details:

− GROUP_ASSOC consists of a record containing the standard associated data for a motion group. It contains the following predefined fields, all INTEGERs except for SEGBREAK, which is a BOOLEAN:

· SEGRELSPEED : percentage of nominal speed · SEGMOTYPE : motion type · SEGORIENTYPE : orientation control mode · SEGBREAK : not implemented

− Variables and fields of structures can be declared GROUP_ASSOC. − Subfields of this structure can be accessed and set using the usual structure field

notation. − Variables and fields declared GROUP_ASSOC can be:


· Passed as parameters. · Written to and read from unformatted files. · Assigned to one another.

− Each subfield of a GROUP_ASSOC variable or structure field can be passed as a parameter to a routine, but is always passed by value.

− The keyword GROUP_ASSOC can be followed by a clause IN GROUP[n] to specify the group to which the data applies. If it is not present, it is assumed that the data is to apply to the default group specified by the %DEFGROUP directive.

See Also : Section 8.4.7, "Path Motion," for default values Example : Refer to Section B.2, "Copying Path Variables" (CPY_PTH.KL), for a

detailed program example. HOLD Action

Purpose : Causes the current motion to be held and prevents subsequent motions from starting

Syntax : HOLD <GROUP[n,{,n}]> Details:

− Any motion in progress is held. Robot and auxiliary or extended axes decelerate to a stop.

− An attempted motion after a HOLD is executed is also held. HOLD cannot be overridden by a condition handler which issues a motion.

− HOLD is released using the UNHOLD statement or action. − If the group clause is not present, all groups for which the task has control (when

the condition is defined) will be canceled. − If a motion that is held is part of a SIMULTANEOUS or COORDINATED motion

with other groups, the motions for all groups are held. − Motion cannot be held for a different task.

See Also : Chapter 8, “Motion,” for more information on starting and stopping motions. Example : The following example uses a local condition handler to move along the path

pathvar but stops the motion before node 3 using the HOLD action. MOVE ALONG pathvar, WHEN TIME 200 BEFORE NODE[3] DO HOLD ENDMOVE

HOLD Statement

Purpose : Causes the current motion to be held and prevents subsequent motions from starting

Syntax : HOLD <GROUP[n{,n}]>


Details: − Any motion in progress is held. Robot and auxiliary or extended axes decelerate to

a stop. − An attempted motion after a HOLD is executed is also held. HOLD cannot be

overridden by a condition handler which issues a motion. − HOLD is released using the UNHOLD statement or action. − All held motions are canceled if a RELEASE statement is executed while motion

is held. − If the group clause is not present, all groups for which the task has control will be

canceled. − If a motion that is stopped, resumed, canceled, or held is part of a

SIMULTANEOUS or COORDINATED motion with other groups, the motions for all groups are stopped, resumed, canceled, or held.

− Motion cannot be held for a different task. See Also : Chapter 8, “Motion,” for more information on starting and stopping motions. Appendix E, “Syntax Diagrams,” for additional syntax information Example : The following example initiates a move along the path pathvar but stops the

motion until the F1 key TPIN[1] on the teach pendant is pressed. MOVE ALONG path_var NOWAIT HOLD WRITE ('Press F1 on teach pendant to resume motion') WAIT FOR TPIN[129]+ UNHOLD IN_RANGE Built-In Function

Purpose : Returns a BOOLEAN value indicating whether or not the specified position argument can be reached by a group of axes

Syntax : IN_RANGE(posn) Function Return Type:BOOLEAN Input/Output Parameters:

[in] posn : XYZWPREXT %ENVIRONMENT Group:SYSTEM Details:

− The returned value is TRUE if posn is within the work envelope of the group of axes; otherwise, FALSE is returned.

− The current $UFRAME and $UTOOL are applied to posn. See Also : CHECK_EPROS Built-in procedure. Chapter 8, “Motion” Section 4.1.2, "Group Motion" Example : The following example checks to see if the new position is in the work

envelope before moving the TCP to it. IF IN_RANGE(pallet: part_slot) THEN WITH $UFRAME = pallet MOVE TO part_slot ELSE WRITE('I can't get there!',CR) ENDIF


INSERT_NODE Built-In Procedure

Purpose : Inserts an uninitialized node in the specified PATH argument preceding the specified path node number

Syntax : INSERT_NODE(path_var, node_num, status) Input/Output Parameters:

[in] path_ var : PATH [in] node_ num : INTEGER [out] stat us : INTEGER %ENVIRONMENT Group:PATHOP

Details: − node_num specifies the index number of the path node before which the new

uninitialized node is to be inserted. − The new node can be assigned values by directly referencing its NODEDATA

structure. − All nodes following the inserted node are renumbered. − Valid node_num values are in the range node_num => 1 and node_num <=

PATH_LEN(path_va r ). − If node_num is not a valid node number, status is returned with an error. − If the program does not have enough RAM for an INSERT_NODE request, an

error will occur. − If the program is paused, the INSERT_NODE request is N OT retried.

See Also : DELETE_NODE, APPEND_NODE Built-in Procedures Example : In the following example, the PATH_LEN built-in is used to set the variable

length equal to the number of nodes in path_var. INSERT_NODE inserts a new path node after the last node in path_var.

length = PATH_LEN(path_var) INSERT_NODE(path_var, length, status) INV Built-In Function

Purpose : Used in coordinate frame transformations with the relative position operator (:) to determine the coordinate values of a POSITION in a frame that differs from the frame in which that POSITION was recorded

Syntax : INV(pos) Function Return Type : POSITION Input/Output Parameters:

[in] pos : POSITION %ENVIRONMENT Group:SYSTEM Details:

− The returned value is the inverse of the pos argument. − The configuration of the returned POSITION will be that of the pos argument.

Example : The following example uses the INV built-in to determine the POSITION of part_pos with reference to the coordinate frame that has rack_pos as its origin. Both part_pos and rack_pos were originally taught and recorded in User Frame. The robot is then instructed to move to that position.


PROGRAM p_inv VAR rack_pos, part_pos, p1 : POSITION BEGIN p1 = INV(rack_pos):part_pos MOVE TO p1 END p_inv NOPAUSE Action

Purpose : Resumes program execution if the program was paused, or prevents program execution from pausing

Syntax : NOPAUSE Details:

− The NOPAUSE action usually corresponds to an ERROR[n] or PAUSE condition. − The program will be resumed, even if it was paused before the error. − If the program is paused by itself, the NOPAUSE action will be ignored and

program execution will be paused. Example : The following example uses a global condition handler to test for error

number 12311. If this error occurs, the NOPAUSE action will prevent program execution from being paused and the NOMESSAGE action will suppress the error message normally displayed for error number 12311. This will allow the routine uninit_error to be executed without interruption.

ROUTINE uninit_error BEGIN CONDITION[stop] : WHEN ERROR[12311] DO NOPAUSE, NOMESSAGE, uninit_error ENDCONDITION WRITE ('Uninitialized operand',CR) WRITE ('Use KCL> SET VAR to initialize operand',CR) WRITE ('Press Resume at Test/Run screen to ',cr) WRITE ('continue program',cr) PAUSE -- pauses program (undoes NOPAUSE action) END uninit_error NOWAIT Clause

Purpose : Allows program execution to overlap with motion or a pulse Syntax : NOWAIT Details:

− If NOWAIT is included in a motion statement, the next statement will be executed at the same time motion begins.

− NOWAIT follows the motion specification of a MOVE statement and the VIA clause but precedes any condition handler clauses.

− If NOWAIT is not included, the next statement will be executed when the motion is completed or canceled.

− A NOWAIT motion will be canceled at the time the CANCEL action or statement is executed.


See Also : PULSE Statement MOVE Statements Syntax Diagrams, Appendix E “Syntax Diagrams” Example : In the following example, the NOWAIT clause is used so that all statements

will be executed at the same time. PULSE DOUT[motor] FOR 50 NOWAIT MOVE TO p1 NOWAIT DOUT[clamp] = ON ORIENT Built-In Function

Purpose : Returns a unit VECTOR representing the y-axis (orient vector) of the specified POSITION argument

Syntax : ORIENT(posn) Function Return Type:VECTOR Input/Output Parameters: [in] posn : POSITION %ENVIRONMENT Group:VECTR Details:

− Instead of using this built-in, you can directly access the Orient Vector of a POSITION.

− The returned value is the orient vector of posn. − The orient vector is the positive y-direction in the tool coordinate frame.

Example : The following example initially moves the TCP to the POSITION start_pos. The VECTOR pos_vector is then set to the value of the orient vector for start_pos. The MOVE ABOUT statement moves the TCP about pos_vector by 45°.

MOVE TO start_pos pos_vector = ORIENT (start_pos) MOVE ABOUT pos_vector BY 45. PATH Data Type

Purpose : Defines a variable or routine parameter as PATH data type Syntax : PATH Details:

− A PATH is a varying length list of elements called path nodes, numbered from 1 to the number of nodes in the PATH.

− No valid operators are defined for use with PATH variables. − A PATH variable is indexed (or subscripted) as if it were an ARRAY variable. For

example, tool_track[1] refers to the first node of a PATH called tool_track. − An uninitialized PATH has a length of zero. − PATH variables cannot be declared local to routines and cannot be returned from

functions. − Only PATH expressions can be assigned to PATH variables or passed as

arguments to PATH parameters. − A PATH variable can specify a data structure constituting the data for each path

node.


− A PATH variable can specify a data structure constituting the path header. This can be used to specify the UFRAME and/or UTOOL to be used with recording or moving along the path. It can also specify an axis group whose current position defines a table-top coordinate frame with respect to which the robot data is recorded and moved.

− A PATH can be declared with either, neither, or both of the following clauses following the word PATH:

· NODEDATA = node_struct_name, specifying the data structure constituting a path node.

· PATHHEADER = header_struct_name, specifying the structure constituting the path header.

If both fields are present, they can appear in either order and are separated by a comma and optionally a new line.

− If NODEDATA is not specified, it defaults to the STD_PTH_NODE structure described in Appendix A.

− If PATHHEADER is not specified, there is no (user-accessible ) path header. − An element of the PATHHEADER structure can be referenced with the syntax

path_var_name.header_field_name. − An element of a NODEDATA structure can be referenced with the syntax

path_var_name[node_no].node_field_name. − The path header structure can be copied from one path to another with the

path_var1 = path_var2 statement. − The path node structure can be copied from one node to another with the

path_var[2] = path_var[1] statement. − A path can be passed as an argument to a routine as long as the PATHHEADER

and NODEDATA types match. A path that is passed as an argument to a built-in routine can be of any type.

− A path node can be passed as an argument to a routine as long as the routine parameter is the same type as the NODEDATA structure.

− If the data structure specified for NODEDATA in a path includes more than one position data type for the same group, only the first for that group will be used in move statements specifying the path.

− PATHs provide the ability to specify motion groups to be used for local condition handlers.

− A path can be declared with a NODEDATA structure having no position type elements. This can be a useful way of maintaining a list structure. Such a path cannot be used in a MOVE statement.

See Also : APPEND_NODE, DELETE_NODE, INSERT_NODE Built-In Procedures PATH_LEN, NODE_SIZE Built-In Functions Example : The following example shows different declarations of PATH variables.

TYPE node_struct = STRUCTURE node_posn : XYZWPR IN GROUP[1] node_data : GROUP_ASSOC IN GROUP[1] aux_posn : JOINTPOS IN GROUP[2] common_data : COMMON_ASSOC weld_time : INTEGER weld_current : INTEGER ENDSTRUCTURE


std_pth_node = STRUCTURE -- This type is predefined node_pos : POSITION IN GROUP[1] group_data : GROUP_ASSOC IN GROUP[1] common_data : COMMON_ASSOC ENDSTRUCTURE hdr_struct = STRUCTURE uframe1 : POSITION utool : POSITION speed : REAL ENDSTRUCTURE VAR path_1a : PATH PATHHEADER = hdr_struct, NODEDATA = node_struct path_1b : PATH NODEDATA = node_struct, PATHHEADER = hdr_struct path_2 : PATH NODEDATA = node_struct -- no header path_3 : PATH -- equivalent to PATH NODEDATA = std_pth_node path_4 : PATH PATHHEADER = hdr_struct -- std_pth_node

The following example shows how an element of a NODEDATA structure can be referenced :

-- Using declaration for path_1a : -- Using NODEDATA fields : path_1a[1].node_posn = CURPOS(0, 0) cnt_dn_time = path_1a[node_no].weld_time path_1a[1].node_data.SEGRELSPEED = new_value path_1a[1].common_data.SEGTERMTYPE = new_value -- Using PATHHEADER fields: path_1a.utool = tool_1 WITH $UFRAME = path_1a.uframe, $SPEED = path_1a.speed MOVE ALONG path_1a

Example : Refer to the following sections for detailed program examples: Section B.2, "Copying Path Variables" (CPY_PTH.KL) Section B.6, "Path Variables and Condition Handlers Program"

(PTH_MOVE.KL). PATH_LEN Built-In Function

Purpose : Returns the number of nodes in the PATH argument Syntax : PATH_LEN(path_nam) Function Return Type: INTEGER Input/Output Parameters:

[in] path_ nam : PATH %ENVIRONMENT Group:PBCORE Details:

− The returned value corresponds to the number of nodes in the PATH variable argument.

− Calling PATH_LEN with an uninitialized PATH returns a value of zero. See Also : COPY_PATH Built-in Example : Refer to the following sections for detailed program examples: Section B.2, "Copying Path Variables" (CPY_PTH.KL). Section B.6, "Path Variables and Condition Handlers Program"

(PTH_MOVE.KL).


Section B.1, "Setting Up Digital Output Ports for Monitoring" (DOUT_EX.KL).

PAUSE Action

Purpose : Suspends execution of a running task Syntax : PAUSE <PROGRAM[n]> Details:

− The PAUSE action pauses task execution in the following manner: · Any motion already initiated continues until completed. · Files are left open. · All connected timers continue being incremented. · All PULSE statements in execution continue execution. · Sensing of conditions specified in condition handlers continues. · Any Actions, except routine call actions, are completed. Routine call actions

are performed when the program is resumed. − The PAUSE action can be followed by the clause PROGRAM[n], where n is the

task number to be paused. − Use GET_TSK_INFO to find a task number.

See Also : UNPAUSE Action PAUSE Condition

Purpose : Monitors the pausing of program execution Syntax : PAUSE < PROGRAM [n] > Details:

− The PAUSE condition is satisfied when a program is paused, for example, by an error, a PAUSE Statement, or the PAUSE Action.

− If one of the actions corresponding to a PAUSE condition is a routine call, it is necessary to specify a NOPAUSE action to allow execution of the routine.

− Also, the routine being called needs to include a PAUSE statement so the system can handle completely the cause of the original pause.

− The PAUSE condition can be followed by the clause PROGRAM[n], where n is the task number to be paused.

− Use GET_TSK_INFO to find a task number. Example : The following example scans for the PAUSE condition in a global condition

handler. If this condition is satisfied, DOUT[light] will be turned on. The CONTINUE action continues program execution; ENABLE re-enables the condition handler.

CONDITION[alarm] : WHEN PAUSE DO DOUT[light] = TRUE CONTINUE ENABLE CONDITION[waiting] ENDCONDITION


PAUSE Statement Purpose : Suspends execution of a KAREL program Syntax : PAUSE < PROGRAM [n] > Details:

− The PAUSE statement pauses program execution in the following manner: · Any motion already initiated continues until completed. · Files are left open. · All connected timers continue being incremented. · All PULSE statements in execution continue execution. · Sensing of conditions specified in condition handlers continues. · Any actions, except routine call actions, are completed. Routine call actions

are performed when the program is resumed. − The PAUSE statement can be followed by the clause PROGRAM[n], where n is

the task number to be paused. − Use GET_TSK_INFO to find a task number.

See Also : Appendix E, “Syntax Diagrams,” for more syntax information Example : If DIN[pb1] is TRUE, the following example pauses the KAREL program

using the PAUSE statement. The message, “Program is paused. Press RESUME function key to continue” will be displayed on the CRT/KB screen.

PROGRAM p_pause BEGIN IF DIN[pb1] THEN WRITE ('Program is Paused. ') WRITE ('Press RESUME function key to continue', CR) PAUSE ENDIF END p_pause

POS Built-In Function

Purpose : Returns an XYZWPR composed of the specified location arguments (x,y,z), orientation arguments (w,p,r), and configuration argument (c)

Syntax : POS(x, y, z, w, p, r, c) Function Return Type: XYZWPR Input/Output Parameters:

[in] x, y, z, w, p, and r : REAL [in] c : CONFIG %ENVIRONMENT Group:System

Details: − c must be a valid configuration for the robot attached to the controller.

CNV_STR_CONF can be used to convert a string to a CONFIG variable. − x, y, and z are the Cartesian values of the location (in millimeters). Each argument

must be in the range ± 10000000 mm (± 10 km). Otherwise, the program is paused with an error.

− w, p, and r are the yaw, pitch, and roll values of the orientation (in degrees). Each argument must be in the range ± 180 degrees. Otherwise, the program is paused with an error.


See Also : Chapter 8, “Motion” Example : The following example uses the POS Built-In to designate numerically the

POSITION next_pos and then moves the TCP to that position. CNV_STR_CONF('n', config_var, status) next_pos = POS(100.,-400.25,0.5,10.,-45.,30.,config_var) MOVE TO next_pos POSITION Data Type

Purpose : Defines a variable, function return type, or routine parameter as POSITION data type

Syntax : POSITION <IN GROUP[n]> Details:

− A POSITION consists of a matrix defining the normal, orient, approach, and location vectors and a component specifying a configuration string, for a total of 56 bytes.

− The configuration string indicates the joint placements and multiple turns that describe the configuration of the robot when it is at a particular position.

− A POSITION is always referenced with respect to a specific coordinate frame. − The POSITION data type can be used to represent a frame of reference in which

case the configuration component is ignored. − Coordinate frame transformations can be done using the relative position operator

(:). − A POSITION can be assigned to other positional types. − Valid POSITION operators are the

· Relative position (:) operator. · Approximately equal (>=<) operator.

− A POSITION can be followed by IN GROUP[n], where n indicates the motion group with which the data is to be used. The default is the group specified by the %DEFGROUP directive, or 1.

− Components of POSITION variables can be accessed or set as if they were defined as follows:

POSITION = STRUCTURE NORMA L : VECTOR -- read-only ORIENT : VECTOR -- read-only APPROACH : VECTOR -- read-only LOCATION : VECTOR -- read-write CONFIG_DATA : CONFIG -- read-write ENDSTRUCTURE

See Also : Chapter 8, “Motion” POS, UNPOS Built-In Functions Example : Refer to Section B.1, "Setting Up Digital Output Ports for Monitoring"

(DOUT_EX.KL) for a detailed program example.


PURGE CONDITION Statement

Purpose : Deletes the definition of a condition handler from the system Syntax : PURGE CONDITION[cond_hand_no]


− The statement has no effect if there is no condition handler defined with the specified number.

− The PURGE CONDITION Statement is used only to purge global condition handlers.

− The PURGE CONDITION Statement will purge enabled conditions. − If a condition handler with the specified number was previously defined, it must be

purged before it is replaced with a new one. See Also : ENABLE CONDITION Statement Chapter 6, “Condition Handlers” Appendix E, “Syntax Diagrams” for more syntax information Example : In the following example, if the BOOLEAN variable igno re_cond is TRUE,

the global condition handler, CONDITION[go], will be purged using the PURGE statement; otherwise CONDITION[go] is enabled.

IF ignore_cond THEN PURGE CONDITION[go] ELSE ENABLE CONDITION[go] ENDIF RELEASE Statement

Purpose : Releases all motion control of the robot arm and auxiliary or extended axes from the KAREL program so that they can be controlled by the teach pendant while a KAREL program is running

Syntax : RELEASE Details:

− Motion stopped prior to execution of the RELEASE statement can only be resumed after the execution of the next ATTACH statement.

− If motion is initiated from the program while in a released state, the program is aborted with the following error, “MCTRL Denied because Released.”

− If RELEASE is executed while motion is in progress or in a HOLD condition, the program is aborted with the following error, "Detach request failed."

− All motion control from all KAREL tasks will be released. See Also : Appendix E, “Syntax Diagrams,” for more syntax information Example : Refer to Section B.1, "Setting Up Digital Output Ports for Monitoring"

(DOUT_EX.KL) for a detailed program example.


RESUME Action

Purpose : Restarts the last stopped motion issued by the task Syntax : RESUME <GROUP[n{,n}]> Details:

− A motion set is a group of motions issued but not yet terminated when a STOP statement or action is issued.

− If there are no stopped motion sets, no motion will result from the RESUME. − If more than one motion set has been stopped, RESUME restarts the most recently

stopped, unresumed motion set. Subsequent RESUMEs will start the others in last-in-fi rst-out sequence.

− The motions contained in a stopped motion set are resumed in the same order in which they were originally issued.

− If a motion is in progress when the RESUME action is issued, any resumed motion(s) occur after the current motion is completed.

− If the group clause is not present, all groups for which the task has control (when the condition is defined) will be be resumed.

− If the motion that is stopped, resumed, canceled, or held is part of a SIMULTANEOUS or COORDINATED motion with other groups, the motions for all groups are stopped, resumed, canceled, or held.

− Motion cannot be resumed for a different task. Example : Refer to Section B.1, "Setting Up Digital Output Ports for Monitoring"

(DOUT_EX.KL) for a detailed program example. RESUME Statement

Purpose : Restarts the last stopped motion issued by the task Syntax : RESUME <GROUP[n{,n}]>

− A motion set is a group of motions issued but not yet terminated when a STOP statement or action is issued.

− If there are no stopped motion sets, no motion will result from the RESUME. − If more than one motion set has been stopped, RESUME restarts the most recently

stopped, unresumed motion set. Subsequent RESUMEs will start the others in last-in-fi rst-out sequence.

− Those motions in a stopped motion set are resumed in the same order in which they were originally issued.

− If a motion is in progress when the RESUME statement is issued, any resumed motion(s) occur after the current motion is completed.

− If the group clause is not present, all groups for which the task has control will be be resumed.


− Motion cannot be resumed for a different task. See Also : Appendix E, “Syntax Diagrams” for more syntax information


Example : In the following example, motion is stopped if DIN[low] is ON. It is resumed after F1 is pressed.

MOVE ALONG some_path NOWAIT IF DIN[low] THEN WRITE(' Motion stopped') STOP WRITE(CR, 'Motion and the program will resume') WRITE(CR, ' when F1 of teach pendant is pressed') WAIT FOR TPIN[129] RESUME ENDIF SIGNAL EVENT Action

Purpose : Signals an event that might satisfy a condition handler or release a waiting program

Syntax : SIGNAL EVENT[event_no] where:

event_no : an INTEGER expression Details:

− You can use the SIGNAL EVENT action to indicate a user-defi ned event has occurred.

− event_no occurs when signaled and is not remembered. Thus, if a WHEN clause has the event as its only condition, the associated actions will occur.

− If other conditions are specified that are not met at the time the event is signaled, the actions are not taken, even if the other conditions are met at another time.

− event_no must be in the range of -32768 to 32767. Otherwise, the program is aborted with an error.

See Also : EVENT Condition Example : Refer to Section B.1, "Setting Up Digital Output Ports for Monitoring"

(DOUT_EX.KL) for a detailed program example. SIGNAL EVENT Statement

Purpose : Signals an event that might satisfy a condition handler or release a waiting program

Syntax : SIGNAL EVENT [event_no] where:

event_no : an INTEGER Details:

− You can use the SIGNAL EVENT statement to indicate a user-defined event has occurred.

− event_no occurs when signaled and is not remembered. Thus, if a WHEN clause has the event as its only condition, the associated actions will occur.

− If other conditions are specified that are not met at the time the event is signaled, the actions are not taken, even if the other conditions are met at another time.


− event_no must be in the range of -32768 to 32767. Otherwise, the program is aborted with an error.

See Also : Appendix E, “Syntax Diagrams” for more syntax information EVENT Condition Example : Refer to the DISABLE CONDITION Statement example program.

SIN Built-In Function

Purpose : Returns a REAL value that is the sine of the specified angle argument Syntax : SIN(angle) Function Return Type : REAL Input/Output Parameters :

[in] angle : REAL %ENVIRONMENT Group:SYSTEM Details:

− angle specifies an angle in degrees. − angle must be in the range of ± 18000 degrees. Otherwise, the program will be

aborted with an error. Example : Refer to Section B.8, "Generating and Moving Along a Hexagon Path"

(GEN_HEX.KL), for a detailed program example. SQRT Built-In Function

Purpose : Returns a REAL value that is the positive square root of the specified REAL argument

Syntax : SQRT(x) Function Return Type:REAL Input/Output Parameters:

[in] x : REAL %ENVIRONMENT Group:SYSTEM Details:

− x must not be negative. Otherwise, the program will be aborted with an error. Example : The following example calculates the square root of the expression

(a*a+b*b) and indicates that this is the hypotenuse of a triangle. c = SQRT(a*a+b*b) WRITE ('The hypotenuse of the triangle is ',c::6::2) STOP Action

Purpose : Stops any motion in progress, leaving it in a resumable state Syntax : STOP <GROUP[n{,n}]> Details:

− Any motion in progress is decelerated to a stop. The unfinished motion as well as any pending motions are grouped together in a motion set and placed on a stack.

− More than one motion might be stacked by a single STOP action. − If the KAREL program was waiting for the completion of the motion in progress,

it will continue to wait.


− The stacked motion set can be removed from the stack and restarted with either a RESUME statement or action or by issuing RESUME from the operator interface (CRT/KB).

− If the group clause is not present, all groups for which the task has control (when the condition is defined) will be stopped.


− Motion cannot be stopped for a different task. See Also : Chapter 8, “Motion” RESUME Action RESUME Statement Example : Refer to Section B.1, "Setting Up Digital Output Ports for Monitoring"

(DOUT_EX.KL) for a detailed program example. STOP Statement

Purpose : Stops any motion in progress, leaving it in a resumable state Syntax : STOP <GROUP[n{,n}]> Details:

− Any motion in progress is decelerated to a stop. The unfinished motion as well as any pending motions are grouped together in a motion set and placed on a stack.

− More than one motion might be stacked by a single STOP statement. − If the KAREL program was waiting for the completion of the motion in progress,

it will continue to wait. − The stacked motion set can be removed from the stack and restarted with either a

RESUME statement or action, or by issuing RESUME from the CRT/KB. − If the group clause is not present, all groups for which the task has control will be

stopped. − If the motion that is stopped, resumed, canceled, or held is part of a

SIMULTANEOUS or COORDINATED motion with other groups, the motions for all groups are stopped, resumed, canceled, or held.

− Motion cannot be stopped for a different task. See Also : Chapter 8, “Motion” RESUME Action RESUME Statement Appendix E, “Syntax Diagrams,” for more syntax information Example : The following example stops motion if the digital input is ON.

IF DIN[low] THEN STOP ENDIF


STRUCTURE Data Type

Purpose : Defines a data type as a user-defined structure Syntax : new_type_name = STRUCTURE

field_name_1: type_name_1 field_name_2: type_name_2 ...

ENDSTRUCTURE Details:

− A user-defined structure is a data type consisting of a list of component fields, each of which can be a standard data type or another, previously defined, user data type.

− When a program containing variables of user-defined types is loaded, the definitions of these types is checked against a previously created definition. If this does not exist, it is created.

− The following data types are not permitted as part of a data structure: � STRUCTURE definitions (types that are declared structures are permitted) � PATH types � FILE types � Vision types � Variable length arrays � The data structure itself, or any type that includes it, either directly or

indirectly − A variable may not be defined as a structure, but as a data type previously defined

as a structure See Also : Section 2.4.2 “User-Defined Data Structures” Example : Refer to Section B.2, "Copying Path Variables" (CPY_PTH.KL), for a

detailed program example.

TAN Built-In Function

Purpose : Returns a REAL value that is the tangent of the specified REAL argument Syntax : TAN(angle) Function Return Type:REAL Input/Output Parameters:

[in] angle : REAL %ENVIRONMENT Group:SYSTEM Details:

− The value of angle must be in the range of ± 18000 degrees. Otherwise, the program will be aborted with an error.

Example : The following example uses the TAN Built-In function to specify the tangent of the variable angle. The tangent should be equal to the SIN(angle ) divided by COS(angle ).

WRITE ('enter an angle:') READ (angle,CR) ratio = SIN(angle)/COS(angle) IF ratio = TAN(angle) THEN WRITE ('ratio is correct',CR) ENDIF


TIME Condition Purpose : Monitors the progress of a move to a POSITION or along a PATH Syntax : TIME t ||BEFORE | AFTER|| NODE[n]

where: t : INTEGER expression

n : INTEGER expression Details:

− The TIME conditions can be used only in local condition handlers. − t indicates the time interval in milliseconds BEFORE or AFTER NODE[n ]. − The maximum value for t is 500. − NODE[n ] indicates the node BEFORE which or AFTER which the condition is

satisfied. − If n is a wildcard (*), any node will satisfy the BEFORE or AFTER condition. − Node 0 indicates the start of the move. − If the move is along a PATH or to a path node, n specifies a path node. − If the move is to a POSITION, node 1 can be used to indicate the destination. − If n is greater than the length of the path (or greater than 1 if the move is to a

POSITION), the condition is never satisfied. − If n is less than zero or greater than 1000, the program is aborted with an error.

See Also : Chapter 6, “Condition Handlers” Appendix E, “Syntax Diagrams,” for more syntax information Example : Refer to Section B.1, "Setting Up Digital Output Ports for Monitoring"

(DOUT_EX.KL) for a detailed program example. UNHOLD Action

Purpose : Releases a HOLD of motion Syntax : UNHOLD <GROUP [n{,n}]> Details:

− Any motion that was in progress when the last HOLD was executed is resumed. − If motions are not held, the action has no effect. − Held motions are canceled if a RELEASE statement is executed. − If the group clause is not present, all groups or which the task has control (when

the condition is defined) will be resumed. − Motion cannot be stopped for a different task.

Example : The following example moves the robot along the PATH pathvar and holds the robot motion 200 milliseconds before node[3]. The global condition handler is triggered when TPIN[F1] is pressed. This condition handler then issues a UNHOLD statement to resume robot motion.

CONDITION[F1]: WHEN TPIN[F1]+ DO UNHOLD ENDCONDITION ENABLE CONDITION[F1] MOVE ALONG pathvar, WHEN TIME 200 BEFORE NODE[3] DO HOLD ENDMOVE


UNHOLD Statement

Purpose : Releases a HOLD of motion Syntax : UNHOLD <GROUP [n{,n}]> Details:

− Any motion that was in progress when the last HOLD was executed is resumed. − If motions are not held, the statement has no effect. − Held motions are canceled if a RELEASE statement is executed. − If the group clause is not present, all groups or which the task has control (when

the condition is defined) will be resumed. − Motion cannot be stopped for a different task.

See Also : Appendix E, “Syntax Diagrams,” for more syntax information Example : The following example initiates a move to p1 and HOLDs the motion. If

DIN[ok] is ON, UNHOLD allows the program to resume motion. MOVE TO p1 NOWAIT HOLD IF DIN[ok] THEN UNHOLD ENDIF UNPAUSE Action

Purpose : Resumes program execution long enough for a routine action to be executed Syntax : UNPAUSE Details:

− If a routine is called as an action, but program execution is paused, execution is resumed only for the duration of the routine and then is paused again.

− If more than one routine is called, all of the routines will be executed before execution is paused again.

− The resume and pause caused by UNPAUSE do not satisfy any RESUME and PAUSE conditions.

See Also : RESUME, PAUSE Actions Example : Refer to Section B.1, "Setting Up Digital Output Ports for Monitoring"

(DOUT_EX.KL) for a detailed program example. UNPOS Built-In Procedure

Purpose : Sets the specified REAL variables to the location (x,y,z) and orientation (w,p,r) components of the specified XYZWPR variable and sets the specified CONFIG variable to the configuration component of the XYZWPR

Syntax : UNPOS(posn, x, y, z, w, p, r, c) Input/Output Parameters:

[in] posn : XYZWPR [out] x, y, z : REAL [out] w, p, r : REAL [out] c : CONFIG %ENVIRONMENT Group:SYSTEM


Details: − x, y, z, w, p, and r arguments are set to the x, y, and z location coordinates and

yaw, pitch, and roll orientation angles of posn. − c returns the configuration of posn.

See Also : Chapter 8, “Motion” Example : The following example uses the UNPOS Built-In to add 100 to the x location

argument. UNPOS (CURPOS, x, y, z, w, p, r, config) next_pos = POS (x+100., y, z, w, p, r, config) MOVE TO next_pos VECTOR Data Type

Purpose : Defines a variable, function return type, or routine parameter as VECTOR data type

Syntax : VECTOR Details:

− A VECTOR consists of three REAL values representing a location or direction in three dimensional Cartesian coordinates.

− Only VECTOR expressions can be assigned to VECTOR variables, returned from VECTOR function routines, or passed as arguments to VECTOR parameters.

− Valid VECTOR operators are: � Addition (+) and subtraction (-) mathematical operators. � Equal (=) and the not equal (<>) relational operators. � Cross product (#) and the inner product (@) operators. � Multiplication (* ) and division (\ ) operators. � Relative position (:) operator.

− Component fields of VECTOR variables can be accessed or set as if they were defined as follows:

VECTOR = STRUCTURE X : REAL Y : REAL Z : REAL ENDSTRUCTURE

Note: All fields are read-write. Example : The following example shows VECTOR as variable declarations, as

parameters in a routine, and as a function routine return type. VAR direction, offset : VECTOR ROUTINE calc_offset(offset_vec:VECTOR):VECTOR FROM util_prog

WAIT FOR Statement Purpose : Delays continuation of program execution until some condition(s) are met Syntax : WAIT FOR cond_list

where: cond_list : one or more conditions


Details: − All of the conditions in a single WAIT FOR statement must be satisfied

simultaneously for execution to continue. See Also : Chapter 6, “Condition Handlers” Appendix E, “Syntax Diagrams,” for more syntax information Example : Refer to the following sections for detailed program examples: Section B.6, "Path Variables and Condition Handlers Program"

(PTH_MOVE.KL). Section B.1, "Setting Up Digital Output Ports for Monitoring"

(DOUT_EX.KL). WHEN Clause

Purpose : Used to specify a conditions/actions pair in a local or global condition handler.

Syntax : WHEN cond_list DO action_list where:

cond_list : one or more conditions action_list : one or more conditions

Details: − All of the conditions in the cond_list of a single WHEN clause must be satisfied

simultaneously for the condition handler to be triggered. − The action_list represents a list of actions to be taken when the corresponding

conditions of a WHEN clause are satisfied simultaneously. − Calls to function routines are not allowed in a CONDITION or MOVE statement

and, therefore, cannot be used in a WHEN clause. − CONDITION and MOVE statements can include multiple WHEN clauses.

See Also : Chapter 6, “Condition Handlers” Appendix E, “Syntax Diagrams,” for more syntax information Example : Refer to the following sections for detailed program examples: Section B.6, "Path Variables and Condition Handlers Program"

(PTH_MOVE.KL). Section B.10, "Using Dynamic Display Built-ins" (DYN_DISP.KL). Section B.1, "Setting Up Digital Output Ports for Monitoring"

(DOUT_EX.KL). WITH Clause

Purpose : Used in a MOVE statement to specify temporary values for system variables. Also used in condition handlers to specify condition handler qualifiers

Syntax : WITH param_spec {, param_spec} where:

param_spec is of the form: move_sys_var = value or move_sys_var[n] = value


move_sys_var : one of the system variables available for use in the WITH clause

n : specifies the group number value : an expression of the type corresponding to the type of the

system variable Details:

− The actual system variables specified are not changed. The temporary value is used only by the motion environment while executing the move in which the WITH clause is used.

− The temporary value remains in effect until the next time the system variable is used by the motion environment. At that time, the assigned system variable value is used and the temporary value ceases to exist.

− INTEGER values can be used where REAL values are expected. − Predefined constants are used to specify values for some system variables that can

be used in the WITH clause. For example, $MOTYPE is specified as LINEAR, CIRCULAR, or JOINT.

− $PRIORITY and $SCAN_TIME are condition handler qualifiers that can be used in a WITH clause only when the WITH clause is part of a condition handler statement.

See Also : Chapter 6, “Condition Handlers” Chapter 12, “System Variables,” for a list of the system variables that can be

used in the WITH clause Example : Refer to the following sections for detailed program examples: Section B.6, "Path Variables and Condition Handlers Program"

(PTH_MOVE.KL). Section B.8, "Generating and Moving Along a Hexagon Path"

(GEN_HEX.KL). Section B.1, "Setting Up Digital Output Ports for Monitoring"

(DOUT_EX.KL). XYZWPR Data Type

Purpose : Defines a variable, function return type, or routine parameter as XYZWPR data type.

Syntax : XYZWPR <IN GROUP [n]> Details:

− An XYZWPR consists of three REAL components specifying a Cartesian location (x,y,z), three REAL components specifying an orientation (w,p,r), and a component specifying a CONFIG Data Type, 32 bytes total.


− A position is always referenced with respect to a specific coordinate frame. − Components of XYZWPR variables can be accessed or set as if they were defined

as follows:


XYZWPR = STRUCTURE X : REAL Y : REAL Z : REAL W : REAL P : REAL R : REAL CONFIG_DATA : CONFIG ENDSTRUCTURE

Note: All fields are read-write access. Example : Refer to the following sections for detailed program examples: Section B.2, "Copying Path Variables" (CPY_PTH.KL). Section B.5,"Using Register Built-ins" (REG_EX.KL). Section B.6, "Path Variables and Condition Handlers Program"

(PTH_MOVE.KL). Section B.8, "Generating and Moving Along a Hexagon Path"

(GEN_HEX.KL). Section B.1, "Setting Up Digital Output Ports for Monitoring"

(DOUT_EX.KL). XYZWPREXT Data Type

Purpose : Defines a variable, function return type, or routine parameter as an XYZWPREXT

Syntax : XYZWPREXT <IN GROUP [n]> Details:

− An XYZWPREXT consists of three REAL components specifying a Cartesian location (x,y,z), three REAL components specifying an orientation (w,p,r), and a component specifying a configuration string. It also includes three extended axes, 44 bytes total.


− A position is always referenced with respect to a specific coordinate frame. − Components of XYZWPREXT variables can be accessed or set as if they were

defined as follows: XYZWPRext = STRUCTURE X : REAL Y : REAL Z : REAL W : REAL P : REAL R : REAL CONFIG_DATA : CONFIG EXT1 : REAL EXT2 : REAL EXT3 : REAL ENDSTRUCTURE

Note: All fields are read-write access.

Guide abrégé sur l’utilisation du robot M-6i: Références. 7-1

7 RÉFÉRENCES

FANUC Robotics, SYSTEM R-J3 Controller HandlingTool Setup and Operations Manual (Version 5.20), 1999. FANUC Robotics, SYSTEM R-J3 Controller KAREL Reference Manual (Version MARS3KA5109801E REV. B). Tétreault, M., Guide d’utilisation du robot S-10 (version 2.0c), Automne 2001. Généreux, S., Guide d’utilisation du robot M-6i, Été 2001.

Guide abrégé sur l’utilisation du robot M-6i: Annexe – Description détaillée des commandes Karel. 7-1

Documents

GPA-774 Robots Industriels II · PDF fileLe département de génie de la production automatisée possède un robot industriel Fanuc M-6i. Ce robot comprend un manipulateur,