IBM INTERNAL USE ONLY - DRAFT ** DO NOT Copy #* 5.5 PROGRAMMING THE PF KEYS The only other problem we have concerning PF commands is that of Progranming then. Certainly we could have these PF keys set from the beginning by CONIPL, unable to be altered by the user. But com- mon sense dictates that we allow sone form of progranmability for these PF keys if they are to be useful. The use of CONPFS makes this task quite easy and we can create a line command that would allow the user to easily program the PF keys for the domain in which he is operating in. An important point to remember is that the PF key de finitions for different domain would not necessarily be the same. Thus, changing the PF keys in the current domain should not effect the PF key definitions in other domains The fact that there are two CONPFS, one in computer memory that is loaded during domain IPL and the other on disk from which the former is loaded from means that we have essentially two ways of defining PF keys. We may change the CONPFS in computer memory which would make our PF key definition change temporary because leaving the do- main would erase the changes which we made. Or we could change both the temporary CONPFS in computer memory and the CONPFS that is per- manently stored on disk. That means that if we change the PF keys in this manner, each time we reenter the domain by reIPL' ing the new PF key definitions will reflect these changes we made earlier. To illustrate this process let us examine the four line commands that allow the user to define the functions associated with each PF key. The four line commands in the CON domain are as follows: PF1 this defines functions for the first PF key PF2 this defines functions for the second PF key PF3. this defines functions for the third PF key PF4 this defines functions for the fourth PF key Although the names of these commands are different, they call the same command execution file which is called CPFDEF. Closer examina- tion of the command directory for the CON domain will reveal this fact. CPFDEF is defined only for the CON editing window for the CON domain. That is when the user is operating the full-screen window in the CON domain an error message will ensue from the message field. Let us take a brief look at CPFDEF, the command execution file for defining PF keys. An examination of its logic will reveal some oth- er important aspects of the CON domain as well: + SUBR; NEW PROCARG(ARGLIST) ; ARG: NEW STRING(7); PENUM: NEW CVTSN(SUBSTR(CMD,3,1)) 5 TK: NEW INT; IMMEDIATE COMMANDS AND PF KEY COMMANDS 57IBM INTERNAL USE ONLY - DRAFT ** DO NOT COPY ** CH: NEW INT; IF (TRMODE EQ 0) OR EDITMODE THEN BEGIN IF EDITMODE ‘THEN MSGOUT('PF KEYS CANNOT BE REDE! *FULL-SCREEN EDITING MODE") INED WHILE IN *| ELSE MSGOUT('THE CURRENT DEFINITION FOR THIS PF KEY IS: * CONPFS (PFNUM, 1)) RETURN; END ELSE IF ARGS(1) EQ <'',' '> THEN ARG = DSE(58,2*PFNUM+9,7) ELSE ARG = ARGS(1); IF TK = NEMBER(ARG,DONCMDS) THEN CONPFS(PFNUM) = ELSE IF MEMBER(ARG,DOMMCL) THEN CONPFS(PFNUM) = TAKE (CVINS (TK) ,8)|'>") "*yraKe (aRG,7)|''!,"] TAKE (CVINS (TK) ,8)|'>")5 ELSE WRITE (CH,', CLOSE (CH) ; MSGOUT('NEW PF KEY DEF IS PERMANENTLY SAVED"); END ELSE MSGOUT('NEW PF KEY DEF IS NOT PERMANENTLY SAVED'); END; 58 RPD: System ManualIBM INTERNAL USE ONLY - DRAFT ** DO NOT COPY ** The first few statements initialize variables and check to see if either trace mode is off or if full-screen editing is operational. ‘The very first statement in the subroutine processes the arguments and creates an aggregate of the argument strings in ARGS. ARGLIST is just a continuous string when passed to PROCCMD which may contain Zero, one, two, or more arguments separated by commas. Just like in PREPROC where we used a command separator ";" to processes individ- ual commands in a command string we use the comma "," as an argument separator. This fact is reflected in ‘the statement PROCARG(ARGLIST) which essentially parses up the ARGLIST string in- to its individual elements according to where the commas are. The first argument to the PF key definition conmand is the either a blank or the name of the command that is to be associated with that PF key. The second argument which is optional determines if the de- finition is to be permanent (in terms of the CONPFS on the disk) or not. If the first argument ARGS(1) is omitted, then a particular process is undertaken. On the window of the CON window there is a field which displays all the current PF key definitions. Therefore, if the first argument is omitted, then it is assumed that the user wishes to, in fact edit this definition right on the window. In this case, a certain routine that allows this form of editing called DSE (for directed screen editing) is called which returns the string that the user input. DSE is reproduced below, but its explanation must be deferred until later. DSE: SUBR(CURSOR,LIN,WIDTH); POINT(O, LIN); DISPLAY (SUBSTR(CONOUT(LIN) ,1,CURSOR-2)); REFILL (SUBSTR(CONOUT (LIN) CURSOR ,81-CURSOR) ) ; RETURN (READ (0, STRING (WIDTH) )) 5 END; Essentially it points the cursor to a pafticular row and column on the screen which is specified in the call to DSE and accepts a char~ acter string of a specified width. After ARG which is equivalent to CMD in PREPROC (the command field) is computed, the rest of the command execution file resembles that of PREPROC. That is CMDTOKEN must be generated according to the re- spective command and macro dictionaries for the domain. ARG (which is equivalent to CMD -- the author wishes that he had, in fact, changed the name to CMD in CPFDEF) and TK (which is equivalent in all respects to CMDTOKEN in PREPROC) are put into CONPFS, reflecting the changes that have been programmed into the PF keys. IMMEDIATE COMMANDS AND PF KEY COMMANDS 59IBM INTERNAL USE ONLY - DRAFT ** DO NOT COPY ** The last portion of the the CPFDEF command execution file takes care of the permanent specification of PF key definitions. If the user so desires, he may make the new PF keys permanent, which entails that the CONPFS file on disk must be opened and the values of ARG and TK written to the appropriate record. Our next discussion will leave the system kernel for a short while. Full-screen command processing, because of the peculiar demands it makes on the system will not involve calls to PROCCMD or PREPROC etc. Instead, there will be miniature version of the system kernel superimposed upon the still resident main system kernel that will handle the vagaries of entering information anywhere on the screen. ‘The next chapter will thus describe some of the implementation de~ tails in full-screen prefix command process ing. 60 PD: System ManualIBM INTERNAL USE ONLY - DRAFT ** DO NOT COPY ** 6.0 FULL-SCREEN COMMAND PROCESSING AND TEXT MANIPULATION 6.1 INTRODUCTION Many of the domains that are used by the robot programmer will in- volve some sort of editing. This is the case with the CON domain in which the programmer edits the robot programs; with the WORKSPACE domain, the progranmer will edit files that contain workspace point definitions; with the macro definition domain, DESIGN/AML programs Will be edited, and in the Debugging Support domain breakpoint ta- bles are edited. Thus text editing is an important part of the sys- tem and takes a considerable amount of development time. If nothing else, the Robot Program Development System is characterized by its multitude of editors all serving a distinct purpose within the pro- gram development scheme. ‘Thus the idea of implementing a generalized full-screen editor for all the domains makes much sense if we are to make great use of these editors. Provisions have to be made for access to all points on the display so that these can be potentially changed, Even more important is the implementation of full-screen commands which take the form of commands entered on the prefix command area of the dis- play. Since we discussed the methods used in preparing and displaying the screen in the chapter on command execution and domain environments, we won't delve into the details of this matter again. 6.2 THE FULL-SCREEN COMMAND LOOP As far as our editor goes, what do we have so far in the way of any code? Basically, all we have is the ability to prepare and display the screen window. This of course is useful for us because it cre- ates an environment in which we can write powerful line commands and macros to do things to that environment. Now that we have displayed the screen, however, what we want to do is perform some sort of full-screen editing on the display that we have created. The way we will do this is to define two PF keys (which we will be henceforth statically defined and not programmable) that will put us in either full-screen mode or command mode. The reason for this is that the way we have described the system kernel gives us no means to enter a full-screen environment without executing some line command that FULL-SCREEN COMMAND PROCESSING AND TEXT MANIPULATION 61IBM INTERNAL USE ONLY - DRAFT ** DO NOT COPY ** would perform this function. To keep things simple then, we will define these two PF keys as FULL and CMD, the former will put us in full-screen mode and the latter in command mode. Both of these PF keys work relatively fast so that switching between the two is quickly done Remember earlier we said that the processing of full-screen com- mands must take some form similar to the system kernel that proc esses most of the other command presented to the system. The main conmand interpretation loop in the system kernel was controlled by a routine that was called START which first loaded the SYSIPL file and then iterated through the basic cycle of READCMD-PREPROC-PROCGMD. What we will do with the full-screen command processor is to load a file containing a similar subroutine. This subroutine will be the one that is invoked when the FULL PF key (which is incidentally PF key #3) is pressed. In addition, another subroutine that is invoked when the CMD PF key (PF key #4) is pressed will also be included. This is what a partial version of that file looks like: 62 RPD: System ManualIBM INTERNAL USE ONLY - DRAFT ** DO NOT COPY ** FULSCR: NEW 15 OF STRING(79); LINEVECT: NEW 15 OF INT; COLPOS: NEW 1; PRXA: NEW INT; FULPROC: SUBR; KEY(<3,4,5,6,7,8>,<'", "CMDMODE" , 'UP_ARROW" , "DOWN_ARROW" , "SCROLL_UP", ‘SCROLL _DOWN'>); PRFXERR: NEW INTs FSCRNUM: NEW 73 MSGOUT('FULL-EDITING CAPABILITY ACTIVE"); CONT: PFXPROC(READLINE) 5 BRANCH (CONT) ; CMDMODE: SUBR; POINT (0 , FSCRNUM+2) ; DISPLAY (FULSCR(FSCRNUM) ,EOL) ; KEY(3, 'FULPROC') 5 PREFILL('') 5 MSGOUT(' COMMAND LINE CAPABILITY ACTIVE"); BRANCH (LOOP) ; END; END; KEY(3, 'FULPROC"); Notice a few things about this file. First of all the SYSIPL proc- ess is explicitly defined within the first part of the file. That is the full-screen command processor is initialized upon simply loading this file which we will call FULPROC. Furthermore, notice that CMDMODE (the subroutine which is invoked upon pressing the CMD key) is defined as a nested subroutine within the subroutine FULPROC (the subroutine that is invoked upon pressing the FULL key). Let us understand how FULPROC (the subroutine) works now because its operation is crucial to the processing of full-screen (prefix) com- mands. The first statement in the subroutine presets all the full-screen PF keys which we said are not programmable while in full-screen mode. In the next statement PRFXERR (the prefix command error flag) is set to the off condition. If a prefix command error does occur PRFKERR will be set on, a condition which we will inves- tigate later in our discussion. FSCRNUM, which is set in the next statement is critical to the full-screen command processor. As we said when describing the oper- ation of FULPREP , the editor window preparation routine, there are 15 lines in the full-screen display. The seventh line is always the current line, while the eighth line is always the scale. Thus, FSCRNUM (an integer ranging from 1 to 15) will indicate what line on FULL-SCREEN COMMAND PROCESSING AND TEXT MANIPULATION 63IBM INTERNAL USE ONLY - DRAFT ** DO NOT COPY ** the screen represents the current cursor position, as far as the ed- itor is concerned. The distinction is different, because the current cursor position can change without the control of the editor under two conditions: 1) the system kernel takes control of the cursor momentarily in order to display messages, refresh the parts of the screen etc. 2) the user uses the hardware cursor positioning keys which are not recognized by the AML implemented editor. In any case, entering will FULPROC will set FSCRNUM to 7 which re- presents the current line. When the editor is ready to receive com- mands, it will POINT the cursor to the value indicated by FSCRNUM + 2 (remember, of course, that the full-screen display window does not include the top two lines on the screen which are take up by the header. ‘The next statement sends a message to the message field indicating that the user is now in full-screen mode. This means of course that we will enter the full-screen command loop which looks as follows: CONT: PFXPROC(READLINE) ; BRANCH (CONT) ; This looks very similar to the READCMD-PREPROC loop that plays a central role in command processing in the system kernel. The ques- tion is how does a command loop that essentially reads commands only on a single line as the system kernel does for the line command in- put line, interpret commands from all over the screen? The question will be answered soon, but we will first examine what this loop does for the line that we are currently on, namely the current line which is, by default, the line which our cursor will be placed on. Conceptually speaking, READLINE does the job of reading the whole line, prefix command line and text line together and analyzing this line for prefix commands and text. PFXPROC then registers any changes in the text line and then processes any prefix commands on that line, First, let us discuss READLINE. 6.3 READING THE PRESENT LINE -- READLINE What are the tasks that READLINE must perform? The first thing is that it must first read the entire line which the cursor is now po- sitioned on. This line, of course, includes both the prefix command area and the text line that is being currently edited. We want to 64 — RPD: System ManualIBM INTERNAL USE ONLY - DRAFT #* DO NOT COPY ** be able the see the line that we are editing at the same time that the line is being read so that READLINE must also prefill the line that is being read with the actual screen display line corresponding to that line. Let us first look at what one of these lines looks like as it was prepared by FULPREP. this is a line of text which is preceded by the prefix command area Alternately, we can have a display line, in which the prefix command area is on the right of the text line, as follows: this is a line of text which is followed by the prefix command area The next job of READLINE, then, would be to split up this line into prefix command area and text line respectively and send these two strings to PFXPROC which will alternately register the changes in the text line and execute the specified full-screen prefix command. Were is READLINE as it is currently implemented: FULL-SCREEN COMMAND PROCESSING AND TEXT MANIPULATION 65IBM INTERNAL USE ONLY - DRAFT ** DO NOT COPY ** READLINE: SUBR; INDINE: NEW STRING(79) ; I: NEW INTs IP PRFXERR THEN IF PRXA THEN PREFILL(SUBSTR (FULSCR(FSCRNUM) ,1,72)|" 22222") ELSE PREFILL('?7???_' | SUBSTR(FULSCR(FSCRNUM) ,7,72)) ELSE PREFILL(FULSGR(FSCRNUM)) ; POINT(0,FSCRNUM#2) 5 READ(O, INLINE); RETURN(), SUBSTR(INLINE, IF PRXA THEN 1 ELSE 7,72)>); END; Remember that READLINE is embedded within the FULPROC subroutine in nested form. The first couple of things that READLINE does here is initialize the input line and a counter that will be used in split- ting up that input line into prefix command area and text line ac- cordingly. Secondly, READLINE prepares the prefill line so that when the system is ready to read that line it will also be displayed so that the us- er can view the editing that he is doing. This process of prefill- ing the input line is similar to the function of the '?' immediate command which we discussed in the last chapter. If there is a pre- fix command error which we said earlier is flagged by PRFXERR, then the prefix command area must be overlayed by a string of question marks ('77277') instead of the usual string of equal signs iG "). In addition this overlay must be done according to whether the prefix command area is on the right or the left of the text line. This configuration is controlled by the variable PRXA. ‘That is, if PRXA is not equal to zero the prefix command area will be on the right of the text line; otherwise it the prefix command area will be on the left of the text line in the case when PRKA is not equal to zero. If there is no prefix command error, then the input line is simply prefilled to the line that was prepared by the last call to FULPREP. READLINE, then points the screen cursor to the line indicated by that all-important pointer FSGRNUM that we discussed earlier. Upon doing this, the system is ready to read the line. When the ENTER key is pressed the line is read, and READLINE sends whatever prefix command was read as well as the text line itself to PPXPROC. The prefix command sent to PFXPROC, is a string of any characters found in the prefix command area which are not equal to any of the 66 PD: System ManualIBM INTERNAL USE ONLY - DRAFT ** DO NOT COPY #* the characters "=","2"," ", the latter being the blank character. This ensures that only prefix commands are sent to PFXPROC and not any of the characters that make up the the prefix command area dis- play. The text line returned is simply that which does not include the prefix command area. The next task will be to understand the job of PFXPROC now that the appropriate values have been sent as pa- rameters for its operation 6.4 INTERPRETING PREFIX COMMANDS, PFXPROC Unlike FULPROC or the system kernel, PFXPROC is not a generalized subroutine. Indeed its overall structure is the same from domain to domain, but its detailed coding depends on the domain environment in which it is operating in. Remember that although some of the com- mands from domain to domain may overlap in syntax and semantics, their implementation from domain to domain may, in fact, be quite different. In addition, there are some prefix commands that may be very useful in some domain but may not even make sense in others Hence the need for a specialized PFXPROC that is slightly different depending on the difference between prefix commands from domain to domain, This means that PFXPROC must be loaded during the IPL process for each domain. The exception being that the full-screen editor forms a different window within the domain. In this case, PFXPROC and FULPROC, for that matter, are loaded when a window context switch ‘The first thing that these prefix command processors must do is up- date the current text line with the changes that were made by the user. The next thing to do is to identify what, if any, prefix com- mand was entered by the user. Then a prefix command execution file must be loaded and executed. If the prefix command is in error, or an error occurs in the attempted processing of the prefix command, then the prefix error flag PRFXERR must be set to 1. Let us examine the PFXPROG file and its associated subroutine for the CON domain Appropriately enough, this file is called CPFXPROC with the inclu- sive subroutine given the name PFXPROC. PEXPROC: SUBR() ; PRFXERR = 03 CLINE: NEW CURLINEs PRFXPOS: NEW INT; PRFXNUM: NEW INT} CHANGE (GETLINE (LINEVECT (FSCRNUM)) ,TEXTLINE) 5 IF PRXA ‘THEN FULSCR(PSCRNUM) = TEXTLINE|" = FULLSCREEN COMMAND PROCESSING AND TEXT MANIPULATION 67IBM INTERNAL USE ONLY - DRAFT ** DO NOT COPY #* ELSE FULSOR(FSCRNUM) IF PREXTOKEN EQ <'''," ‘> THEN BEGIN GETLINE (CLINE) ; BRANCH (CONT) ; END; IP PRFXPOS = LOCSTR('IP_' ,PRFXTOKEN) ‘THEN LOAD( 'CFPINSRT" ) ; IF PRFXPOS = LOGSTR('RP | ,PRFXTOKEN) THEN LOAD('CPPREPL') ; IF PRFXPOS = LOCSTR('I" , PRFXTOKEN) THEN LOAD('CFINSERT" ); IF PRFXPOS = LOCSTR('A" , PRFXTOKEN) THEN LOAD('CFADD'); IF PRFXPOS = LOCSTR('D" , PRFXTOKEN) THEN LOAD('CFDELETE') ; IF PRFXPOS = LOCSTR(’""" , PRFXTOKEN) THEN LOAD('CFREPEAT" ) ; IF PRFXPOS = LOCSTR('/', PRFXTOKEN) ‘THEN LOAD('CFCURLIN’ ) ; IF LOCSTR('T ' ,PRFXTOKEN) THEN LOAD('CETOP") ; IF LOCSTR("B ' , PRFXTOKEN) ‘THEN LOAD(' GFBOTTOM" ) 5 * |TEXTLINEs PERR: PRFXERR = 1; ‘BRANCH (CONT) ; END; The first thing is to save the value of the current line pointer in CLINE, reset the prefix command error flag and to initialize a cou- ple of variables involved in the processing of prefix commands. One of these is PRFKPOS which represents the position on the prefix com- mand area on which the prefix command has been typed in. For in- stance, if the input line looks as follows: this is a line of text the PRFXTOKEN (the prefix conmand paraneter to PFXPROC) would be 'I', TEXTLINE would be ‘this is a line of text' and PRXPOS would be 3 to indicate that the prefix command (in this case the insert line prefix command) is in character position 3 on the prefix command area. This will be important later in the processing of the prefix commands as some of them have arguments which must be separated from the prefix command itself. PRFXNUM is a variable which will eventu- ally hold the value of the prefix conmand argument to be computed. The next step in PFXPROC is to update the text line that was just changed. Remember of course that the current line may be different than the line that the cursor is presently on (which we will call ‘the present line). The present line is determined by the value of 68 RPD: System ManualIBM INTERNAL USE ONLY - DRAFT ** DO NOT COPY ** FSCRNUM and we must generate a new current line from this value in order to change the line to its edited version just inputted by the user. Of course, if the line hasn't been changed then the version sent to PFXPROC by READLINE will be the same as the old version and nothing will essentially be changed with that line. Once that line is changed then, we must process whatever prefix com- mands were inputted on the prefix command line by the user. If no prefix command was inputted, then the value of the PFXPROC parameter PRFXTOKEN will be blank so that in this case we will leave the PEXPROG by restoring the current line back to its original value and branching to CONT. After this, we must search for our prefix conmand by a series of IF statements each one corresponding to the prefix conmand associated with the value of PRFXTOKEN. If PRFXTOKEN has an 'I' within it then this indicates that the insert prefix command was specified ete This means that the prefix commands can be typed over any position of the five-character prefix command area. Also the prefix command argument may be placed anywhere on the prefix command area as well. Each IF statement then loads the appropriate prefix command exe~ cution file mich like the command execution files called by PROCCHD in the system kernel. If, however, no prefix command was trapped then we have an obvious error condition and the prefix command error flag PRFXERR is set. The one difference between the prefix command execution files and the command execution files called by PROCCMD in the system kernel is that the files for the line commands contained a subroutine of the same name that actually performed the execution of that command. In the prefix command execution files, however, we don't have such a subroutine and the file merely executes as it is loaded. ‘Thus, there is no need for an EVAL statement to execute an enclosed sub- routine or no need, as well, for an UNLOAD statement to expunge that subroutine from computer storage ‘To summarize the operation of PFXPROC then, we can say that the text line is updated according to where the current cursor position indi- cates where the present line is and prefix commands are then decoded so that the corresponding prefix command execution files can be loaded and executed. We note again, that PFXPROC is indigenous to each domain and may change according to what prefix commands are re- cognized in each domain. In continuing we will examine what one of those prefix commands is and how it exacts its effects on the editing object and on the FULL-SCREEN COMMAND PROCESSING AND TEXT MANIPULATION 69IBM INTERNAL USE ONLY - DRAFT ** DO NOT COPY #* 6.5 THE DELETE (D) PREFIX COMMAND Prefix Conmands are entered by typing over the five character posi- tion prefix command area either to the left or to the right of the text line. Usually the line on which you indicate the prefix com- mand is significant in that the effects of the command may be deter- mined by the line on which the prefix conmand was entered. This is demonstrated in the D (for Delete) prefix command which is used to delete one line, or @ specified number of lines. To delete one line you type a "D" over the prefix conmand area adjacent to that line. To delete that line and the two lines after it, for instance, you would type a "3" and a "D" in any combination to delete the total of three lines, The cursor will then be placed on the line following the last line deleted. Here would be an example of the use of this this is line number this is line number this is line number this is line number this is line number this is line number ‘The result after pressing the enter key would look as follows: this is line number 1 this is line number 4 this is line number 5 this is line number 6 As we said before PFXPROC will recognize the "D" in the prefix com- mand (which is passed to PFXPROC by READLINE as PRFXTOKEN) and load a file that executes the operations specified by that command. The name of this file is CFDELETE which we will analyze below: IF (PRFXTOKEN = SUBSTR(PRFXTOKEN, 1 ,PRFXPOS-1) | SUBSTR(PRFXTOKEN, PRFXPOS#1, LENGTH (PRFXTOKEN) ~PRFXPOS)) EQ ' ' THEN PRFXNUM = 2 ELSE PRFXNUM = CVTSN(PREXTOKEN,PERR) + 1 WHILE PRFXNUM = PREXNUM - 1 DO BEGIN DELETES TF CURLINE EQ LASTLINE THEN PRFXNUM = 1 ELSE GETLINE(NEXTLINE) 5 END; IF 7 > FSCRNUM THEN GETLINE (CLINE) ELSE GETLINE (CURLINE) ; FULPREPS 70 RPD: System ManualIBM INTERNAL USE ONLY - DRAFT ** DO NOT COPY ** IF FSCRNUM LT 7 ‘THEN BEGIN FULDISP (1, FSCRNUM) ; DOWN_ARROW; END ELSE BEGIN FULDISP (FSCRNUM) ; BRANCH (CONT) ; END; The first IF statement attempts to distill, in a sense, the argument to the Delete prefix command. That is, if there is no explicit ar- gument then PRFXNUM is set to 2 which indicates that one line is to be deleted. Otherwise the command attempts to decode the argument into a number and put that into PRFXNUM. We then enter a WHILE loop that executes PRFXNUM - 1 times which ex- plains why PFRXNUM is 1 greater than the number of lines to be de- leted. The current line is then deleted. Remember that when the prefix command execution file was loaded the current line pointer was not necessarily set to the one above the scale, but rather it Was set at the beginning of PFXPROC to the line on which the cursor was. In any case, the loop will iterate through by the specified number of times unless the current line is the last line which means that there are no more lines that can be deleted. The next step is to refresh the screen to reflect the changes that have been made in the editing object by the deletions. Because of the time it takes to refresh the screen, it is advantageous to re- fresh only certain portions of the screen rather than the screen Wholesale each time a change has been made. The basic idea is that if the line on which the cursor is positioned (this is determined by the value of FSCRNUM...that is, if FSCRNUM is less than 7) then ev- erything from the top of the text to the current line will be displayed and the cursor will be moved down one line. This is was the call to DOWN_ARROW is supposed to mean, but we will discuss this in more detail later. On the other hand if the cursor position is at the current line or below, then everything from the present line (FSCRNUM) to the bottom of the text window will be displayed. This means that as little as i line has be refreshed and not more than 15 lines have to be refreshed, rather than a full 23 lines being re- freshed after each operation. The branch to CONT and DOWN_ARROW reset the system and make it available (through READLINE) for input again. FULL-SCREEN COMMAND PROCESSING AND TEXT MANIPULATION 71IBM INTERNAL USE ONLY - DRAFT ** DO NOT COPY #* 6.6 FULL-SCREEN TEXT MANIPULATION, DOWN ARROW, it will turn out, is an important subroutine nested within FULPROC which will enable the user to enter the prefix com- mands on any line of the screen. Remember that when we enter the full-screen mode, our cursor has been set without our control to line 7 in the text window which is the current line. How will we be able to change the line that we are on, and thus make our editing efforts simpler and our prefix commands more useful. Indeed, if all our prefix commands operated on the current line, or in relation to the current line, then prefix commands would not make much sense if we could do all these operations with line commands. But being able to apply prefix commands to any one of the lines on the screen will help us do things that would be more difficult with line commands. DOWN_ARROW is a subroutine that is invoked by one of the PF keys. It is the software equivalent of the hardware down cursor key, which as we mentioned cannot be recognized by the AML system. DOWN ARROW, then, is an emulation of the down cursor key and does the same things as that key would have done if it were able to be used. DOWN_ARROW works on the following principles: 1) You have to re-display the present line which the cursor is on because you wish the line below it to be high- lighted (available for input) rather than the line on which the cursor is now. 2) You then have to place the cursor on the line below the present line so that the effect of the down arrow can be realized. 3) the unusual cases are when the present line is the current line and when the present line is the last line on the on the display. In the first case, the scale has to be skipped when moving the cursor down. In the latter case, the screen is scrolled down such that the text block below the last line can be viewed. After all this is done PFXPROC will return control back to READLINE such that new input can be received and processed. let us see how this DOWN_ARROW realizes these principles in the following se- lection of code which is nested within FULPROC. DOWN_ARROW: SUBR; IF 15 ~ FSCRNUM THEN IF LINEVECT(FSCRNUM + 1) THEN BEGIN IF (CURLINE EQ LASTLINE) AND (FSCRNUM EQ 7) ‘THEN BEGIN MSGOUT('BOTTOM OF TEXT’); 72 RPD: System ManualIBM INTERNAL USE ONLY - DRAFT #* DO NOT COPY ** BRANCH (CONT) ; END; POINT(O,FSCRNUM + 2); DISPLAY (FULSGR (FSCRNUM) , EOL) 5 IF 7 ~ FSCRNUM THEN FSCRNUM ELSE FSCRNUM END ELSE MSGOUT('BOTTOM OF TEXT’) ELSE IF NEXTLINE(7) EQ LASTLINE THEN MSGOUT('BOTTOM OF TEXT') ELSE BEGIN GETLINE (NEXTLINE) 5 FULPREP; FULDISP; END; FSORNUM + 1 FSCRNUM + 25 BRANCH (CONT) ; END; The first thing that DOWN ARROW does is determine if the cursor is at the bottom of the screen of if it isn't. If the cursor is at the bottom of the text window then FSCRNUM equals 15. Hence the state- ment "IF 15 - FSCRNUM" checks for this contingency. If the cursor is, indeed, at the bottom of the screen, corresponding to the ELSE condition of this "IF" statement, then the subroutine will execute a scroll-down by one line and thus refresh the entire screen. This can only be done if that line which is at the bottom of the subrou- tine is not the last line in the text file. If it is at the last line then a message indicating that it is at the bottom of the sub- routine is displayed on the message field of the screen...the same message field that the system kernel uses to send messages to the If the cursor is not at the very bottom of the screen, then the sub- routine will attempt to move the cursor down one line. We say "at- tempt" because the cursor may indeed be at the bottom of the text without being at the bottom of the screen. A example of this case is when the BOTTOM line command makes the current line equal to the last line of the text file. In this case, if the cursor was on line 7 of the text window (Line 9 of the screen), then we would be at the bottom of the text without being at the bottom of the text window. We check to see if this is the case by testing the value of LINEVECT which, if you recall, was generated in FULPREP during the prepara- tion of the screen. LINEVECT is a 15 element aggregate of integers containing information about the context of each line on the display. In other words if the ith line is a blank meaning that it is above or below the text block (including the scale) then LINEVECT of i (LINEVECT(I)).will be set to 0 whereas if the ith line in the display is actually a text line within the text block, then LINEVECT of i will not be zero. FULL-SCREEN COMMAND PROCESSING AND TEXT MANIPULATION 73IBM INTERNAL USE ONLY - DRAFT ** DO NOT COPY #* Of course, the cursor is already positioned on a valid text line, so that the logical course to follow would be to test the line on which we wish to move the cursor to, Since FSCRNUM indicates the present line then that next line would be characterized by LINEVECT(FSCRNUM +1). Thus if this line should have a corresponding LINEVECT value of zero then it represents an invalid data field for the cursor (in other words, the bottom of the text). In this case an ‘Bottom of text’ message is sent to the message field through MSGOUT. One other case must be taken care of: that is the one in which the current line is equal to the last line and when the present line (the one on which the cursor is currently positioned) is also equal to the current line. This moans that the next line below is the scale which is also considered to be an invalid data field for the cursor and another message sent out. The important point, is that these are not error conditions but rather an attempt by the subrou- tine to determine if the cursor position will be a useful one or not. In other words, the software cursor down key has more intelli- gent capabilities than the hardware cursor down key. We finally consider the case in which the line below the present line represents a feasible position for the cursor. In this case the following code in DOWN_ARROW executes: POINT(O,FSCRNUM + 2); DISPLAY (FULSCR (FSCRNUM) ,EOL) ; IF 7 FSCRNUM ‘THEN FSCRNUM ELSE FSCRNUM 'SCRNUM + 1 'SCRNUM + 25 First the screen refreshes the present line in order the clear the highlighted line. Then it changes the cursor number which is deter- mined by FSCRNUM to the next value. This next value is, of course, dependent on whether the scale is the next line below, or a text line is the next line below. If the scale is this next line then the cursor must skip it; thus the case when FSCRNUM equals 7 and FSCRNUM is incremented by 2. Otherwise, the normal case in which FSCRNUM is incremented by 1 takes place. Of course, if we have a software key emulating the down cursor key, then it is only logical that we have a software key emulating the up cursor key. This function is also coded by a subroutine very simi- lar to DOWN_ARROW and is called appropriately so: UP_ARROW. Its operation is not much different from that of DOWN ARROW so that a discussion of UP_ARROW will be necessarily short. Here is the actu- al code though that is implemented as a nested subroutine to FULPROC: UP_ARROW: SUBI IF 1 - FSCRNUM 74 — RED: System ManualIBM INTERNAL USE ONLY - DRAFT ** DO NOT COPY ** THEN IF LINEVECT(FSCRNUM - 1) THEN BEGIN POINT(O,FSCRNUM + 2); DISPLAY (FULSCR (FSCRNUM) ,EOL) ; IF 9 = FSCRNUM THEN FSCRNUM = FSCRNUM - 1 ELSE FSCRNUM = FSCRNUM - END ELSE MSGOUT('TOP OF TEXT') ELSE IF NEXTLINE(-6) BQ FIRSTLINE THEN MSGOUT('TOP OF TEXT') ELSE BEGIN GETLINE (NEXTLINE (-1)) ; FULPREP; FULDISP; END; BRANCH (CONT) ; END; This subroutine is slightly simpler than that of DOWN_ARROW. This is because of the anomalous case in DOWN_ARROW in which the last line is just above the scale (i.e. CURLINE equals LASTLINE and SCRNUM equals 7) does not occur in UPARROW. Conditions near the top of the text in UP_ARROW will always dictate that the scale will be embedded within the text so that that the only cases that have to be checked are when the the present cursor is at the top of the text window and when the next line up is characterized by a LINEVECT val- ue of zero which means that it is a blank line and not part of the text. Otherwise, code for UP ARROW follows very similar logic to that of DOWN ARROW; and this will appear apparent with a simple com- parison of the two respective coding implementations. 6.7 SOME MORE FULL-SCREEN PREFIX COMMANDS. ‘The following is a command that can be entered on any line, yet it will set the current line to the top line and in so doing refresh the entire screen. Here is an example of the prefix conmand exe- cution file for that command: GETLINE (FIRSTLINE) ; FULPREP; FULDISP; MSGOUT('TOP OF PROGRAM"); FSORNUM = 7; BRANCH (CONT) ; FULL-SCREEN COMMAND PROCESSING AND TEXT MANIPULATION 75IBM INTERNAL USE ONLY - DRAFT ** DO NOT COPY ** To summarize, the first statemont will set up the current line as the first line in the current editing object, while the next two prepare and display the refreshed screen respectively. Next we send a message to the message field indicating that the top of the pro- gram has been reached and since we do so we must set the current cursor position to the top of the text which will be on line 7 of the text window. Subsequently we wrap up the execution of this prefix command by branching back to CONT which resumes the readiness of the full-screen command processor in receiving the commands. One of the reasons, why these prefix conmands are so important is that their usefulness does not necessarily have to be confined to that of editing functions. Nor must their intelligence also be so confined. By modifying PFXPROC (the routine in the full- screen file processor that checks for the proper prefix conmands for a par- ticular domain and loads the appropriate prefix command execution file) one can add more prefix commands that may be tailored to the requirements of the domain for which they are defined. In addition, the use of easily modifiable prefix command execution files means that these prefix conmands can be progranmed to possess more intel- Ligence than presently implemented, especially for the more elaborate commands. I will give a few examples of what some of these potentially very powerful and flexible prefix commands may look like. The examples are entirely exploratory since the system as of now does not support ‘them: Program Execution control should necessarily be under the control of prefix commands. What I mean by this, is that the flexible ar- rangement under line commands in which one can skip lines or go up or down in the program and then execute specified lines can be made much more powerful using prefix conmands. For instance: Instead of saying " SKIP 2 and then DO 3"" so that the program will execute three lines after skipping the two lines after the current line, one can do the following using the full-screen: Go down’ two lines with the cursor and enter "DO 3" in the prefix command area next to the line in which you want program execution to start. In this case the overhead invoived in processing the command to skip twice is eliminated and the user can more directly see what lines are being executed and from where the execution will begin. In other words, there is an improved dialog between the user and the system. Another example of an intelligent prefix command would be used in the workspace definition domain in which points could be defined in a full screen environment. That is, the simple "I" for insert pre- fix command would serve the same function of inserting a line of text (in this case the line of text would be a point declaration for AMLEE) but the scope and intelligence of the command would be vastly increased. The result of invoking the command would be to have the user and the robot together generate the point using the pendant, dynamic sensing and guarded motions. Some of the arguments to this 76 RPD: System ManualIBM INTERNAL USE ONLY - DRAFT ** DO NOT COPY ** prefix command would specify what axes the user wants to control and what axes the robot would control. For example if the user entered "I|#" it would indicate the user wished to control the z-axis "|" and the x and y axes "+" under control of the pendant One final example of a useful prefix command with intelligence would be one that would prove very useful in the Debugging Support Domain. Essentially, the editor in the Debugging Support Domain would look exactly like that of the general program editor except that certain prefix commands would be included that would be able to set break- points and portions in the program to be traced. A prefix command such as "BK" typed in next to a line would enable a breakpoint at that line, while "CL" would clear that line. "TR" would trace that line or trace a number of specified lines. The potentialities of such an interface can be readily recognized, and the implementation is relatively simple. 6.8 SCROLLING IN THE FULL-SCREEN MODE There are two more PF keys that are permanently set in the full-screen command processor. They are the one's that scroll the screen up and down by one text window. In fact their functions are very similar to the CON domain line commands BACKWARD and FORWARD respectively. Their implementation as PF keys while in full-screen mode allows such a function to be invoked without resorting to com- mand mode. The implementation of both of the subroutines associated with these PF keys is simple. They are both nested within the subroutine FUL- PROC; hence the PF keys are only effective for this function while in full-screen mode. Of course, one could set the PF keys (while they are able to be programmed) to the line commands BACK and FORW respectively such that the functions of these PF keys would remain the same without any difference The only thing we have to really account for in scrolling up and down is what is called scroll wrap-around. In the case of scroll-up, if the difference between the current line and the next window is "small" then the current line will be set to the top line in the text. The next time scrolling up is invoked will cause the display to wrap around to the bottom of the text. ‘The same thing occurs with scrolling down except that the display will wrap around to the top of the text. Obviously scrolling up oF down will require a complete refresh of the entire screen. iiere is what the scrolling up subroutine looks Like: FULLSCREEN COMMAND PROCESSING AND TEXT MANIPULATION 77IBM INTERNAL USE ONLY - DRAFT ** DO NOT COPY * SCROLL_UP: SUBR} TF CURLINE EQ FIRSTLINE THEN BEGIN GETLINE (LASTLINE) ; MSGOUT("SCROLL WRAP AROUND' , "BOTTOM OF PROGRAM"); END ELSE GETLINE(NEXTLINE(-13, ATTOP)) 5 DISP: FULPREP; FULDISP; cuDYODE ATTOP: GETLINE(FIRSTLINE) ; MSGOUT('TOP OF PROGRAM") 5 ‘BRANCH (DISP) 5 END; Basically what happens in this subroutine is that if the current line is now the first line, the screen will wrap around, otherwise, the subroutine will attempt to scroll by one screen full leaving the line that was at the very top of the screen now at the very bottom of the new screen. If the subroutine prematurely reaches the top line, which is the case when there is a branch to ATTOP, then the top line becomes the current line. Finally, the subroutine completes exe~ cution by preparing and displaying the entire text window. The subroutine that implements the scroll down function is shown be- low for reference purposes: SCROLL_DOWN: SUBR; IF CURLINE EQ LASTLINE ‘THEN BEGIN GETLINE (FIRSTLINE) ; MSGOUT("SCROLL WRAP AROUND' , "TOP OF PROGRAM"); END ELSE GETLINE (NEXTLINE(13,ATBOT)) ; DISP: FULPREP; FULDISP; CMDMODE; ATBOT: GETLINE (LASTLINE) ; MSGOUT( "BOTTOM OF PROGRAM’); BRANCH (DISP) 5 END; To summarize: we have developed a full-screen command processor that performs two basic functions: 1) it allows the user to edit text anywhere within the 78 RPD: System ManualIBM INTERNAL USE ONLY - DRAFT ** DO NOT COPY ** text window and provides functions such as-up and down cursor keys, and scrolling keys that enhance his ability to address all the lines on the screen. 2) it provides functions for the interpretation and execution of prefix commands which greatly improve the flexibility and power of the basic commands that are used during the course of program development The implementation scheme that we have described for full-screen conmand processing resembles in many ways the operation of the sys~ tem kernel. It has a generalized line reader called READLINE that allows the user to both edit lines and enter prefix commands. Fur- thermore, we have discussed a specialized subroutine for each do- main that allows tailor-made configurations of prefix commands that demonstrate greater relevance and intelligence to the tasks that are performed within the context of that particular domain. Finally, we have discussed what some of these extended prefix com- mand features should look like in the future in order that even greater power be extended to the user who is interested in develop- ing his applications with the utmost facility and ease. FULL-SCREEN COMMAND PROCESSING AND TEXT MANIPULATION 79IBM INTERNAL USE ONLY - DRAFT ** DO NOT COPY ** 80 RPD: System ManualIBM INTERNAL USE ONLY - DRAFT ** DO NOT COPY #** 7.0 PENDANT COMMANDS AND TEACH MODE 7.1 INTRODUCTION Pendant commands are very similar to PF key commands, Essentially, ‘the user presses a button to invoke a command just as the user would do for PF key commands. Indeed, there seems to be no difference be- ‘tween pendant commands whose buttons are located on the pendant teach box (sometimes called the poc-box) and the PF key commands whose buttons are located on the keyboard. However, pendant commands play a special role in robot programming since they are very much involved with the operation of the pendant teach box. One of the most important functions of this teach box is to implemented a low-level teach mode within the context of a low-level robot programming language. As such, pendant commands are very much tailor-made to the vagaries of particular domains and programming languages. 7.2 THE PENDANT INTERFACE FOR THE AMLEE SYSTEM The buttons that activate the functions defined for particular pen- dant keys are on the pendant teach box. The nature and relative po- sition of these buttons and their associated pendant commands may change from domain to domain, For purposes of discussion, we will be examining the nature of the pendant interface within the AMLEE system. In this case, the pendant is going to be used for the edit- ing and execution of robot programs written in the AMLEE language (which is the IBM RS/1 emulation of the IBM 7535 AML/Entry Progran- ming System. Basically, we have three general functions that are performed by the pendant keys for this domain (the domain in question, being the AM- LEE CON edit domain). These functions are listed below: 1) Editing Support 2) Execution Control 3) Teach mode support Editing support is a general set of pendant keys that do important functions that are directly related to supporting the editing of the program as it is in the computer memory. Such keys such as TOP, PENDANT COMMANDS AND TEACH NODE 81.IBM INTERNAL USE ONLY - DRAFT ** DO NOT COPY ** BOTTOM, SKIP +, SKIP -, INSERT, DELETE, and REPLACE are examples of such functions. For instance, pressing the TOP key performs the same thing as typing in and entering 'TOP' as a line command in the CON editing domain, namely the current line pointer will be set to the first line in the program. A key such as SKIP + will skip a line in the program (without executing it) advancing the current line pointer by one. INSERT will prompt the user to teach the robot a particular program statement using the pendant; registering that statement will cause it to be inserted after the current line in the program. Furthermore, DELETE will delete the current line in the program and REPLACE will prompt the user to teach another program statement which will replace the one now at the current line pointer. Teach mode support keys obviously are involved in teaching the robot specific motions which may then be translated into program state~ ments that are to be inserted into the program (by pressing first the INSERT key) or be executed immediately as a test case, for in- stance. A key like UP will enable the user to move the z-axis to a certain position or to a default position that will be at the UP height of the z-axis on the robot arm. Likewise a key like GRASP will control the gripper at the end of the robot arm and PMOVE (or teach point) will allow the user to define a point which may then be translated into a PMOVE statement. Renomber, of course, that the pendant key functions that we are dis- cussing are only applicable to the ANLEE language. Thus, when we speak of translating the motions that we just taught the robot into program statements we mean those statements to be ones that are val~ id AMLEE program statements. Thus a PHOVE invoked through the cor responding pendant key would enable the x and y exes to be controlled (guided) by the user. If an INSERT or REPLACE key were pressed before guiding this motion, then the result of the motion would be translated into the appropriate AMLEE program statement, which would, of course, be a PYOVE statement to the specified coor dinates, and enbedded within the program according to which pendant key was originally pressed. 7.3 PENDANT KEY COMMAND INTERPRETATION How does the system know that a pendant key has been pressed? Well, if we take the example of the PF key command implementation, then we would use the system kernel read loop with @ KEY statement that would associate a particular pendant key handler subroutine with the PF keys that we defined. We did this using PFHAND for PF keys, and indeed, the implementation for pendant keys also takes the same form. Here is the relevant part of READCMD (in the system kernel) that implement this association between pendant key handler and the pendant keys: 82 -RPD: System ManualIBM INTERNAL USE ONLY - DRAFT ** DO NOT COPY #* READOMD: SUBR; KEY (<113, 114>4(116+IOTA(16)) , 'PNDHAND') ; KEY(<4,5,6,7>, "PFHAND') 5 IF IMMGMD EQ <'"", 121,121, tgt> THEN <> ELSE OLDLINE = INLINE; REPEAT BASIC READ LOOP BEGIN | POINT(0,22)5 DISPLAY (DOMTOKEN| '>') ; END UNTIL LENGTH(READ(O, INLINE)) ; KEY(<4,5,6,7,113,114>#(116+IOTA(16)),'") PREFILL(''); I | 1 v etc.. Obviously, then the first couple of KEY statements enable the pen- dant keys so that they can be recognized during the system kernel read loop. ‘The subroutine that is associated with the pendant keys is PNDHAND and it is disabled after exiting the read loop (in the case that an immediate, line or macro command was read) so that no conflicts between pendant commands and these other commands can take place. The most obvious thing we can say now is that PNDHAND is a special- ized subroutine for each domain, just as PFHAND is. Therefore, a new version of PNDHAND has to be reloaded every time a new domain is IPL'ed. The name of the file containing PNDHAND for the CON edit domain (under ANLEE) is called CPNDHAND which is loaded during exe- cution of the CONIPL file. According to our discussion before on PF key implementation, we said ‘that the important thing was that there be some aggregate the forms a correspondence between the PF keys and the functions defined for each of these PF keys. For the PF keys this critical aggregate was called CONPFS, and it held important information about the function-PF key correspondence and the command execution file to- Kens that indicated which files would be loaded to execute the functions invoked by that PF key. For Pendant keys, we will have a simpler correspondence, simply be- cause of the fact that the pendant keys are not programmable and that the execution files for pendant functions are not the same as the execution files for the functions specified by the PF keys. That is, there is no explicit correspondence between a standard line command (for instance) and a pendant key as there is between a PF key and a line command. The functions for pendant keys on the other hand may perform the same things approximately as related line com- PENDANT COMMANDS AND TEACH MODE 83IBM INTERNAL USE ONLY - DRAFT ** DO NOT COPY ** mands but the are unique and not bound to the command execution files that control the execution of Line commands This means that PNDHAND cannot call PROCCMD because that subroutine is designed to support the execution of line commands and macros Instead PNDHAND must have its own execution support code that will directly call the functions that are separately defined in pendant key execution files. Furthermore, the information that PROCCMD, normally needed for for proper execution such as CMDTOKEN, and AR- GLIST are not required in this case. That means that the aggregate which holds the information that establishes the connections be- tween pendant keys and their corresponding functions is simpler than the information that must be held in CONPFS. In fact, this ag- gregate which we will call CONPND (loaded during execution of CONIPL) can be defined simply as an aggregate of strings, each string corresponding to a pendant key execution file that is held on disk. That means that PNDHAND must establish the relation between the pressed pendant key and its pendant key execution file using the CONPND aggregate. ‘The structure of the pendant key execution file is such that it con- tains a subroutine (mich in the manner of the command execution files for line commands) which must be evaluated and then unloaded after the completion of its processing. Let us take a closer look at what the PNDHAND routine specific to the CON edit domain looks like: PNDEAND: SUBR(K); PREFILL('') ; KEY (<113 ,114>#(116+10TA(16)) ,"")5 CLEANUP ($PENDCLN) ; FN: NEW STRING(8) ; IF K - 116 THEN FN ELSE TOAD (EN) 5 EVAL(EN) 3 BRANCH (LOOP) ; ‘CONPND(ABS(K-114)) ‘CONPND(2) ; PENDCLN: SUBR3 UNLOADCEN) 5 END; END; Obviously, then the first step that must be taken in in this subrou- tine is to disable all the pendant keys so that one cannot nest pen- dant key invocations. The pendant key that was just pressed is given by K, by which the IF statement will extract the proper pen- dant key execution file from CONPND and place that string value into 84 -RPD: System ManualIBM INTERNAL USE ONLY - DRAFT ** DO NOT COPY ** FN. Much in the manner of PROCCHD's processing of line commands, this file is first loaded and the enclosed subroutine evaluated. After completion of evaluation the cleanup subroutine will be in- voked unloading the enclosed execution subroutine and clearing it from the computer memory, to make room for the execution of more commands. Control is then returned to the system kernel and the command read loop through the branch to loop. 7.4 PENDANT KEY EXECUTION To solidify the discussion, let us examine the execution file asso- ciated with a simple pendant key command. This command is the SKIP+ key which we mentioned earlier. The command execution file for its execution is predictably quite simple: CPSKIPP: SUBR; IF CURLINE - LASTLINE THEN BEGIN GETLINE (NEXTLINE) ; IF TRMODE THEN IF EDITMODE THEN BEGIN PULPREP; FULDISP; END ELSE BEGIN CONEPREP; CONDISPLAY (2,8); END; END ELSE MSGOUT('BOTTOM OF SUBROUTINE") ; END; ‘The execution logic of this subroutine is very simple. If the current line pointer is at the bottom of the editing object, then tell the user that he can not skip lines any further from the bottom of the editing object. Otherwise, skip to the next line and refresh the screen. Because the CON edit domain has two windows: one called CON edit mode and the other full-screen mode, there are two ways of refreshing the screen. The current window mode is determined by the variable EDITMODE, which is set to zero indicates the line-oriented CON edit mode, and if not, then the full-screen mode is specified Note: CONEPREP and CONDISPLAY are the domain specific routines that correspond to FULPREP and FULDISP respectively in the full-screen editing window. PENDANT COMMANDS AND TEACH MODE 85IBM INTERNAL USE ONLY - DRAFT ** DO NOT COPY ** One important point to note about pendant commands -is that they execute faster than line commands and even faster than PF keys. This is because, the subroutine essentially skips the calls to PREPROC and PROCCMD that are involved with the processing of line commands. This is achieved at the expense of not being able to progran the pendant keys without changing the system kernel, although perhaps an interesting application would be an overlay pendant handling subroutine that may be programmable and supplant the execution of the normal pendant key handling subroutine when the user so specifies. 7.5 TEACH MODE Programming the robot by teaching it the motions that it must execute is an extremely simple and popular way of developing robot applications quickly and easily. It is the method of choice for today's industrial robotics applications. The current editor for the AMLEE system is designed to combine powerful textual programming of robots as well as the simpler teach mode programming of robots. Both techniques may be used interchangeably throughout the development of the application within the context of this domain. Essentially the process of programming the robot would be to enter the motions by teaching the individual axes of freedom, and allowing the system to translate those motions into AMLEE statements which would then be inserted into the program. Since in the CON edit domain, the user can use both text mode, and the pendant keys, then he can almost effortlessly use both in combination. For instance, he could teach a statement and then actually text edit in full-screen mode. Or he could text edit the sensing statements which would be embedded within motion statements that were defined using the teach mode. ‘The most important command for entering program text in the ANLEE teach mode system is the INSERT pendant key comand. This is used as we mentioned to allow the user to specify a program statement and have it translated and inserted by the system into the text program. Lets review what the sequence of operations the user would do to insert his particular line into the program. Firstly, he would press the INSERT key indicating that he wished to actually insert the next taught motion into the program. If he did not press the INSERT key, then the motion would not be inserted but rather executed immediately. In this case, the user could test particular motions that he things may be useful 86 RPD: System ManualIBM INTERNAL USE ONLY - DRAFT ** DO NOT COPY ** without affecting the program in storage. Later he could insert those statements by using the INSERT key. After pressing this key, the system will prompt the user through the message field to press a key in the AMLEE teach block of pendant keys. These keys are of the form UP, DOWN, GRASP, RELEASE, and PMOVE, each one of which correspond to a specific ANLEE program statement. Pressing the UP and DOWN keys will enable the z-axis to be guided by the user, while the GRASP and RELEASE keys will activate the gripper. Finally the PMOVE key will enable the x,y and roll axes for combined teaching. This means that pressing any one of these keys will cause the system to prompt the user again to move the arm about using the pendant guide keys in the lower part of the pendant box. To register the move so that it will be translated and actually inserted into the text requires that the user press the END button. If the END button is pressed without the user moving the arm then the default distances for GRASP, RELEASE, UP and DOWN are taken. Otherwise, the user has the option of aborting the insert operation by pressing the UNTEACH button which will do two things: 1) it will move the arm back to its old position 2) it will return control back to the system kernel without translating and inserting the aborted motion into the program. Thus, the pendant key execution file must perform all of these operations. Here is what it looks like: CPINSERT: SUBR; CLEANUP (CIN) ; FN: NEW STRING(8 KEY (120, "EVACUATE! ); OLDGOAL'= QGOAL; PKI: NEW INT; PK2: NEW INT: INSLEVEL: NEW SUBRLEVEL NSGOUT(" INSERT TEXT WITH PENDANT PLEASE' , 'USE KEYS IN AMLEE BLOCK"); READPEND: REPEAT 1 UNTIL ((PK1 = SENSIO(PKAMLEE1, INT)) OR (PK2 = SENSTO(PKAMERE2,INT))) NE 05 IF (PK1NE 0) AND (PK2 NE 0) THEN BEGIN MSGOUT('MULTIPLE PENDANT KEYS PRESSED', 'TRY AGAIN"); BRANCH (READPEND) ; END; MSGOUT('IF YOU WISH TO ABORT PRESS UNTEACH' , PENDANT COMMANDS AND TEACH MODE 87IBM INTERNAL USE ONLY - DRAFT ** DO NOT COPY ** "TO REGISTER THE ACTION --> PRESS END'); FN = <'CPTECHPT', 'CPGRASP','' , 'CPUP", 'CPRELESE', +111", “CPDOWN'> (S4PKL + PK2); LOAD CEFN) 5 EVAL(FN) ; IF ENTRY NE '' THEN BEGIN INSERT(ENTRY) ; IF TRMODE THEN IF EDITMODE THEN BEGIN FULPREP; FULDISP; END ELSE BEGIN CONEPREP; CONDISPLAY (2,8); END; END; EVACUATE: SUBR; MSGOUT('MOVE ABORTED. ..THE ROBOT IS NOW MOVING '| "BACK TO ITS OLD POSITION"); MOVE(3,8)5 MOVE (<1,2>, OLDGOAL(<1,2>))5 MOVE (ARM, OLDGOAL) ; ENTRY = "5 QUIT CINSLEVEL) ; END; CIN: SUBR; KEY(120,''); UNLOAD (FN) ; MSGOUT; END; END; One important thing about this subroutine is that it loads another file that executes the motions specified by the AMLEE block pendant keys (i.e. GRASP, PMOVE etc.). These keys are monitored by a loop that does a continuous SENSIO on this keys (as they are defined in PKAMLEE -- loaded with SYSAMLBE, the file that initializes the sys- tem as an AMLEE supporting domain). When one of these keys is pressed then the loop is exited, and a check made if a multiple num- ber of keys were pressed. If not, then a file is found corresponding to that motion function which is then loaded, evalu- ated and unloaded. The EVACUATE nested subroutine is invoked whenever the UNTEACH key is pressed, and as you can see it moves the arm back to the old posi- tion by moving it up to the top first so that no objects in the work- 88 PD: System ManualIBM INTERNAL USE ONLY - DRAFT #* DO NOT COPY ** space are smashed. It then sets the insert string variable (ENTRY) to the null string so that nothing is inserted into the program. To round things up let us take a quick look at the function that performs the motion for the PMOVE pendant key motion command: The name of the file that is loaded by CPINSERT is called CPTECHPT and it contains a subroutine of the same name. Here it is: CPTECHPT: SUBR; OLDGOAL = QGOAL; GUIDE(<1,2,4>); ENTRY = ' PMOVE(' |CVTPTS(APPLY($PT,QGOAL(<1,2,4>)))|")5 IF TRNODE AND (EDITMODE EQ 0) ‘THEN BEGIN IF JNODE ‘THEN LOAD('CPOSPREP") ELSE LOAD('CGOLPREP" ) ; LOAD('CONSPREP") ; CONDISPLAY (11,18) ; END; CVTPTS: SUBR(P); RETURN('PT(' |CVINS(P(2,1))|","| GVINS(P(2,2))|",'] GVINS(P(2,3))1")')s END; END; CVIPTS is the subroutine that translates the coordinates that were just taught by the user 7.6 FUTURE PENDANT KEY COMMAND APPLICATIONS. It is envisioned that pendant keys will have uses beyond the simple teaching of low-level robotics language statements. Already the plans are made for the implementation of the pendant to teach points for definition in the workspace definition domain. Certainly the teaching of points in the workspace, would find ample use in high-level robot languages as well. ‘The pendant teach mode could also conceivably be used for the set- ting a clearing of breakpoints that are set at particular points in the workspace. This would greatly facilitate the use of such break- points for object avoidance, etc. PENDANT COMMANDS AND TEACH MODE 89IBM INTERNAL USE ONLY - DRAFT * DO NOT COPY ** Indeed, the use of pendant keys in their almost exclusive use in ro- bot programming could be as important a tool for the development of robot applications as the keyboard and screen are for the develop- ment of regular computer programs. 90 RPD: System Manuali Heading ID's | i id intro introl intro2 File MANUAL MANUAL, MANUAL. E Heading References INTRODUCTION System Structure Command Forms