AIM Customizer`s Reference Guide

Transcription

AIM Customizer’s
Reference Guide
AIM
Version 3.0
Part Number 00713-00000, Rev. A
April 1996
AIM Customizer’s
Reference Guide
AIM
Version 3.0
Part Number 00713-00000, Rev. A
April 1996
! "# !$$
%%!&!%
$ '
%() *
( +$ "# +$ ,- . / .-) "
/00/0/ "# /0 00/
! 1 23
4-%)! 5- --!6 ! 7 /! "# /! The information contained herein is the property of Adept Technology, Inc. and shall not
be reproduced in whole or in part without prior written approval of Adept Technology,
Inc. The information herein is subject to change without notice and should not be construed as a commitment by Adept Technology, Inc. This manual is periodically reviewed
and revised.
Adept Technology, Inc. assumes no responsibility for any errors or omissions in this document. Critical evaluation of this manual by the user is welcomed. Your comments assist
us in preparation of future documentation. A form is provided at the back of the book for
submitting your comments.
Copyright  1992, 1996 by Adept Technology, Inc. All rights reserved.
The Adept logo is a registered trademark of Adept Technology, Inc.
Adept, AdeptOne, AdeptOne-MV, AdeptThree, AdeptThree-MV, PackOne, PackOne-MV,
HyperDrive, Adept 550, Adept 550 CleanRoom, Adept 1850, Adept 1850XP,
A-Series, S-Series, Adept MC, Adept CC, Adept IC, Adept OC, Adept MV,
AdeptVision, AIM, VisionWare, AdeptMotion, MotionWare, PalletWare,
AdeptNet, AdeptFTP, AdeptNFS, AdeptTCP/IP, AdeptForce, AdeptModules,
and V+ are trademarks of Adept Technology, Inc.
Any trademarks from other companies used in this publication
are the property of those respective companies.
Printed in the United States of America
Table Of Contents
Chapter 1.
1.1
1.2
1.3
1.4
1.5
Introduction
..............................................................................
1
Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Related Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Overview of the AIM System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Programming Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Overview of This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1
2
3
4
Chapter 2.
AIM Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1
2.2
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
AIM Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Fixed, Loadable, and Disk-Resident Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
System Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Application Module Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
User Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
User Modifiable Base System Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
The AIM Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Overview of Statement Creation and Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Overview of AIM Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Customizing AIM: An Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
The AIM Modular Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
The AIM “Loader” File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
AIM File Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Additional Customizing Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Using the Initialization Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Custom Statement and Error Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Menu Page Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Autostarting AIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Autostarting AIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Autostarting a Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3
2.4
2.5
2.6
2.7
2.8
2.9
Chapter 3.
3.1
AIM Database Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Database Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Database Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Disk-Resident and Memory-Resident Databases . . . . . . . . . . . . . . . . . . . . . . . . . . .
Database Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logical and Physical Record Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AIM Customizer’s Reference Guide, Rev. A
17
17
17
17
18
18
18
19
iii
Table of Contents
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
Logical Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Physical Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Current Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How It All Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Displaying Database Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Database Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Standard Database Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Databases in AIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Titles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Field Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Record Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Record Update Dates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Menu Page Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Field Attribute Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Database Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Temporary Disk Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adding Databases to AIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Making a Database Memory Resident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Database Titles and the Resource Module . . . . . . . . . . . . . . . . . . . . . . . . . .
.RFD Files and Menu Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a New Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
New Database .RFD File Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Individual Field Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Field Definition Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a Database From a Definition File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modifying an Existing Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compressing Database Disk Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Additional Database Manager Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
19
19
19
20
20
20
21
21
21
21
21
22
22
22
22
23
24
24
25
25
25
26
27
28
29
31
31
31
32
Chapter 4.
System Database Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1
4.2
4.3
4.4
4.5
33
35
36
37
38
38
41
41
42
43
44
46
50
52
54
58
Database Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Accounts Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Backup Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Error Message Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Help Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Associating a Help Database With a Menu Database . . . . . . . . . . . .
4.6 Initialization Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Initialization Database Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7 Customizing Initialization Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Initialization Database Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Initialization Database Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.8 Menu Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.9 Module Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.10 Sequence Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.11 Statement Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.12 Variable Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iv
Table of Contents
Chapter 5.
5.1
5.2
5.3
5.4
Chapter 6.
6.1
6.2
6.3
Runtime System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
General Concepts and Database Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Runtime Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Database Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Control Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The ai.ctl[ ] and $ai.ctl[ ] Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The rn.ctl[,] and $rn.ctl[,] Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Operator Error Response Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Communications Between The Operator and the Runtime . . . . . . . . . . . . .
Error Display and Operator Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Runtime Status Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pausing and Single-Stepping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Control Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Walk-Thru Training Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sequence Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Runtime Module and Sequence Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Global Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Start and Stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pausing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sequence Execution Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
REACTE Routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Low-level Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Operator Interface Low-level Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Informative and Trace Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Error messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Database Access Low-level Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Special Routines for Accessing the Variable Database . . . . . . . . . . .
Creating Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Guidelines for Writing AIM Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
System Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Walk-Thru Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sample Walk-Thru Training Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AIM Keyword Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a Keyword List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Keyword Lists and the Sequence Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Keyword Lists and the Menu Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The AIM Statement
62
62
62
62
62
62
62
63
64
65
65
65
66
67
68
68
69
69
69
70
70
71
71
71
72
72
72
74
74
75
75
75
76
78
79
79
79
80
..................................................................
83
What Is a Statement? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How Do Statements Work? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Statement Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Statements and the AIM Runtime System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Statement Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a New Statement Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Statement Definition Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
83
83
84
84
86
87
v
Table of Contents
6.4
6.5
Chapter 7.
7.1
Chapter 8.
8.1
8.2
8.3
8.4
8.5
8.6
8.7
8.8
8.9
vi
Example Statement Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Writing a Statement Routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Statement Routine Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Statement Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Standard AIM Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Statement Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How Does AIM Know Which V+ Program to Execute? . . . . . . . . . . . . . . . . . .
How Does the Linker Know Which Database or
Keyword List to Use? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How Does the Linker Know Which Record Number to Return? . . . . . .
How Does the Statement Routine Know Which
Database to Access? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Record to Access? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Field to Access? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How Does the Statement Routine Access a String Argument? . . . . . . . . .
90
90
90
91
92
97
98
98
98
98
98
98
99
Linking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Linking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Definition of Linking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verification Operations Performed by the Linker . . . . . . . . . . . . . . . . . . . . . . . . .
User-Defined Linking Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Customizing the Linking Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Routine for Defining Linking Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Linking Rule Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
101
101
102
102
104
104
105
Creating AIM Menu Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Control Values (ai.ctl[ ] Arrays) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Menu Page Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Sample Menu Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Primary Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Specifying Menu Page and Menu File Names in the
Primary Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Entering and Exiting Menu Editing Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Moving and Sizing a Menu Item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Item Coordinates Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Selected Item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Common Menu Item Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conditional Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Redraw vs. Refresh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The AIM Reference Manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Menu Page Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page Header Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating Menu Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
107
108
109
109
110
110
111
111
111
111
112
112
113
113
113
113
114
114
116
Table of Contents
8.10
8.11
8.12
8.13
8.14
8.15
8.16
8.17
8.18
8.19
8.20
8.21
Chapter 9.
9.1
9.2
9.3
9.4
9.5
Menu Button Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Accessing a Database, V+ Variable, or ai.ctl[ ] Numeric Value . . . . . . . . . . . .
Numeric Value Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Accessing a Database, V+ Variable, or $ai.ctl[ ] String Value . . . . . . . . . . . . . .
String Value Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating Static Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Static Item Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Menu Item Drawing Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Accessing a Location or Date/Time Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Location and Date/Time Value Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a Conditional Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Menu Conditional Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a Scrolling Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Scrolling Windows Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
V+ Scrolling Window Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Accessing Digital I/O Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Custom On-line Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Related Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Help Menu Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Help Record Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AIM Menu Page Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Multiple Language Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Loading Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
116
118
119
122
123
124
125
125
126
126
128
129
130
131
132
133
134
135
136
137
138
139
140
Menu Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
I/O Communications Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
General Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Window Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Menu Commands Without Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Commands for Displaying a Menu Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Commands for Executing a Spawn Routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Menu Spawn Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Button Spawn Routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Value-Check Spawn Routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conditional-Record Spawn Routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page Spawn Routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Panel Spawn Routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Scrolling-Text-Window Spawn Routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Executing The Menu Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pull-Down Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Menu Driver Application Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I/O Communications Buffer Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using of the I/O Communications Buffer in
AIM Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 1: Extracting Qualifier Data From The Buffer . . . . . . . .
Example 2: Forcing a Menu Page Redraw from a
Spawn Routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 3: Sending Error Information Back to
The Menu Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
141
141
142
143
145
147
149
150
150
151
151
152
152
152
153
155
155
157
158
159
159
vii
Table of Contents
Chapter 10.
...................................................................
161
10.1 Operator Control Panels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Control Interface Routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
External Control Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2 Teach Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3 Saving Incremental Edits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.4 Support of Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.5 Utilization of I/O Logical Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
161
161
161
162
162
162
163
163
Chapter 11.
Operator Interface
The V+ Developer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
11.1 Accessing the V+ Developer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
V+ Developer Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
+
11.2 V Developer Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Chapter 12.
AIM Customization Example
....................................................
173
The Example Application Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Basic Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Create the Pin Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Create an Editing Page for the Pin Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modify AIM to Use the New Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Create the New Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Create the New Statement Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Create the GET.PIN Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Create the Definition for INSERT.PIN in the
Statement Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Create the Definition for REJECT.PIN in the
Statement Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Create the Definition for INSPECT.PIN in the
Statement Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.9 Create the V+ Code for the New Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The GET.PIN Statement Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The INSERT.PIN Statement Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The REJECT.PIN Statement Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The INSPECT.PIN Statement Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Final Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
174
175
176
177
179
181
181
182
12.1
12.2
12.3
12.4
12.5
12.6
12.7
12.8
Chapter 13.
Error Messages and the Error Message Database
..........................
182
183
183
184
184
185
186
187
191
193
13.1 Special System Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
13.2 Adding New Error Messages to the System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
13.3 Error-Code Conversion Routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Chapter 14.
Database Management Library Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
14.1 Standard Library Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
14.2 Summary Of Library Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
viii
Table of Contents
Summary of AIM Runtime Routines That Access Databases . . . . . . . . . . 202
14.3 Descriptions Of Library Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Chapter 15.
Database Manager Global Variables
..........................................
279
15.1 Status Values Returned By Database Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
15.2 Symbolic Names For Database Data-type Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
15.3 Miscellaneous Global Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Chapter 16.
Descriptions of Routines in the AIM Base Package . . . . . . . . . . . . . . . . . . . . . . . 283
Chapter 17.
Descriptions of Menu Spawn Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Appendix A. Baseline Menu Bars and Quick Keys
A.1
A.2
..........................................
483
Database Manager Utility Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
The Menu Editor Menus and Quick Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
Menu Editing Quick Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
Appendix B. Disk Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Appendix C. AIM Messages
C.1
C.2
Index
........................................................................
495
Alphabetical List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Numerical List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
.........................................................................................................
Index of Programs
.......................................................................................
609
619
Index of Global Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
ix
Table of Contents
List of Figures
Figure 2-1
AIM Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Figure 2-2
AIM Runtime Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Figure 3-1
Database Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Figure 3-2
Creating a New Record Format Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figure 3-3
Defining an Individual Database Field. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figure 4-1
AIM Initialization Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Figure 6-1
The AIM Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Figure 6-2
Statement Definition Menu Page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Figure 7-1
Indirect Referencing Link Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Figure 8-1
Creating Menu Page Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Figure 8-2
Creating a Menu Button . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Figure 8-3
Accessing Numeric Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Figure 8-4
String Menu Item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Figure 8-5
Creating Static Text or Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Figure 8-6
Transformations and Date/Time Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Figure 8-7
Creating a Conditional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Figure 8-8
Scrolling Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Figure 8-9
Creating a Help Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Figure 9-1
I/O Buffer Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Figure 11-1
V+ Developer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Figure 12-1
Pin Database Record-Field Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Figure 12-2
Pin Menu Page Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Figure 12-3
Pin Menu Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Figure 12-4
GET.PIN Statement Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Figure 12-5
INSERT.PIN Statement Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Figure 12-6
REJECT.PIN Statement Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Figure 12-7
INSPECT.PIN Statement Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
x
Table of Contents
List of Tables
Table 2-1
System Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Table 2-2
Base System Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Table 2-3
AIM File Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Table 3-1
Field-Bit Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Table 4-1
Standard Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Table 4-2
Record Definition for the Accounts Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Table 4-3
Standard Job Categories for Log-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Table 4-4
Record Definition for the Backup Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Table 4-5
Record Definition for the Error Message Database . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Table 4-6
Record Definition for the Help Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Table 4-7
Initialization Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Table 4-8
Record Definition for the Initialization Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Table 4-9
Record Definition for the Menu Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Table 4-10
Menu Item Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Table 4-11
Record Definition for the Module Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Table 4-12
Record Definition for the Sequence Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Table 4-13
Record Definition for the Statement Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Table 4-14
Statement Argument Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Table 4-15
Record Definition for the Variable Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Table 5-1
Indexes for rn.ctl[,] and ai.ctl[ ] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Table 5-2
Indexes for $rn.ctl[,] and $ai.ctl[ ] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Table 5-3
Operator Error Response Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Table 5-4
Argument Type Field Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Table 5-5
Keyword List Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Table 6-1
Statement Argument Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Table 6-2
Baseline Standard Routine Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Table 8-1
ai.ctl[ ] Reserved Ranges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Table 8-2
AIM Menu Page Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Table 9-1
Format of I/O Communications Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Table 9-2
I/O Buffer Qualifiers for Window Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Table 9-3
Format of I/O Buffer Data Field for Window Events . . . . . . . . . . . . . . . . . . . . . . . . 143
Table 9-4
I/O Buffer Qualifiers for Menu Commands Without Parameters . . . . . . . . . . . . . . 143
Table 9-5
I/O Buffer Qualifiers for Menu Commands to Display Menu Pages . . . . . . . . . . . 145
Table 9-6
Format of I/O Buffer Data Field for Page-Display Commands . . . . . . . . . . . . . . . . 146
xi
Table of Contents
Table 9-7
I/O Buffer Qualifiers for Menu Commands to Execute
Spawn Routines / Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Table 9-8
Format of I/O Buffer Data Field for Spawn Commands . . . . . . . . . . . . . . . . . . . . . . 148
Table 13-1
Error Code Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Table 14-1
Routines That Open/Close Records or Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Table 14-2
Routines That Create/Delete Records or Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Table 14-3
Routines That Read Non-Array Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Table 14-4
Routines That Read Array Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Table 14-5
Routines That Write Non-Array Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Table 14-6
Routines That Write Array Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Table 14-7
Routines That Perform Data Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Table 14-8
Routines That Search Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Table 14-9
Routines That Return Database Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Table 14-10 Miscellaneous Database Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Table 14-11 Routines That Support Runtime Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Table 15-1
Status Values Returned by Database Library Routines . . . . . . . . . . . . . . . . . . . . . . . 279
Table 15-2
Symbolic Names for Database Data-Type Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Table A-1
Menu Editing Quick Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
Table B-1
Extensions for AIM Program File Names. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Table B-2
AIM V+ Program Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Table B-3
Extensions for AIM Data Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Table B-4
AIM Database Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Table B-5
AIM Error Message Database Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
xii
Chapter 1
Introduction
This manual presents a detailed description of the Adept Assembly and Information Management
(AIM) Base System software. This manual covers strategies for customizing the AIM system. This
manual covers the internal organization of the software, the data structures, and standard
databases.
This manual is specifically designed for system customizers. If you will only be running a
completed AIM application module, such as VisionWare or MotionWare, you do not need to read
this manual.
1.1
Compatibility
This manual is for use with Adept AIM systems version 3.0 or later operating in conjunction with
the V+ operating system version 11.2 or later. Contact Adept if you need manuals for earlier
versions of AIM.
In addition to the version compatibility requirement:
• The controller must be an A-Series controller (the hardware must include a VGB module)
• If you are using the vision module, the AdeptVision VME option must be installed.
1.2
Related Publications
The AIM system has a complete set of user and reference guides. The user guides detail running
the completed AIM application modules such as VisionWare and MotionWare. The reference
guides detail the internal structure of AIM and describe how to make modifications to the system.
As you learn to customize the AIM system, you will need to be familiar with material in the
following manuals before you can take full advantage of this manual:
• AIM application module users guides
These manuals describe the organization, operation, and philosophy of AIM from a user’s
perspective. Before you can begin modifying an AIM system, you must know what it does
and how it does it. The user guides are:
MotionWare User’s Guide
VisionWare User’s Guide
• AIM application module reference guides
The AIM system by itself provides little useful functionality. It is only when application
specific databases, statements, and runtime code have been added that an AIM system can
perform useful work. Each application module supplied by Adept has a reference guide that
describes the structures, databases, and menu pages used by the application. The current
application reference guides are:
1
Chapter 1 - Introduction
AIM Vision/VisionWare Module Reference Guide
AIM Motion/MotionWare Reference Guide
• AIM add-on modules have a combined user guide and reference guide. These guides must be
used in conjunction with the primary MotionWare or VisionWare module manuals. The one
current add-on module is:
AIM PCB User’s Guide
The AIM runtime routines are all written in the V+ programming language. In order to modify
existing routines or to create new ones, you must be familiar with V+ programming and the V+
operating system. The following manuals cover the V+ operating system:
V+ Operating System Reference Guide
V+ Operating System User’s Guide
The following manual describes the operating system that drives the Adept controller.
V+ Language User’s Guide
The following manuals describe the V+ programming language elements and structures as well as
the SEE editor used to create and modify programs.
V+ Language Reference Guide
If you are modifying the AIM vision module, you will need the following manuals that detail the
AdeptVision VME enhancements to the V+ programming language:
AdeptVision VME User’s Guide
AdeptVision Reference Guide
1.3
Overview of the AIM System
A typical AIM system consists of a Base System (the “baseline”), combined with functional
modules and application modules. The Base System is required for all installations. It contains the
common software and data elements that are required by all systems.
The functional and application modules are optional packages that provide software and data that
are specific to a functional requirement or an application area. For example, there are functional
and application modules for robot control, visual inspection, assembly of printed circuit boards,
and importing and exporting of CAD data. Documentation for each of these optional modules is
provided in user’s guides and separate reference guides.
In this manual, information is presented that allows customizers to modify elements of the AIM
Base System. The major elements of the AIM Base System are:
1. Operator Interface
This subsystem displays information and responds to commands from the operator. This
software is normally executed in V+ task #3. An optional interface task dedicated for custom
installations runs in task #6. The major components of this subsystem are the menu driver,
sequence editor, linker, resource manager, database utility, and error message facility. The
elements of this subsystem that can be modified are described in this manual.
2
Programming Restrictions
2. Database Management (DBM) Library
This subsystem implements a formalized, real-time, database management facility. This
library of routines can be executed in any V+ task. It provides a uniform means for storing,
retrieving, validating, and modifying information.
3. Runtime System
The runtime system executes sequences that perform the actual application. There are two
types of runtime tasks; server tasks and tasks that actually execute a sequence. Server tasks
run independently of other tasks and are idle until another task requests information from
the server task.
Since the runtime reflects the application to be performed, most of the information for the
runtime system is presented in the documentation for each application module. Only the
common elements of the runtime system are presented in this manual.
4. Databases
Most of the data that drives the AIM system is contained in databases. General database
conventions are presented in this manual, as well as information on the specific field
definitions for the databases contained in the Base System.
Some of the databases store and organize the information that is referenced by the sequence
statements. Some databases store the sequences themselves, and additional databases contain
the information that defines the format of the sequence statements. Additional databases are
used to define the operator displays, provide help information, provide explanations of error
messages, and control log-on authorization.
Databases that are specific to functional or application modules are described in the
documentation for the respective modules. Creating custom databases is described in
Chapter 3.
1.4
Programming Restrictions
The following restrictions apply to all software that is to be integrated with the AIM system:
1. The names of all the programs (except statement routines) supplied with AIM, and all the
global variables defined by the system, consist of a two-letter prefix followed by a period (“.”)
and additional characters. For example, all of the primary Database Manager routines have
names starting with “db.”. To avoid conflicts with system software, the names of global
variables and programs defined by system customizers should never start with two
characters followed by a period.
2. For tasks that are running menu drivers, the logical unit referenced with the variable io.lun
and the logical unit referenced with io.lun2 are used by the menu driver to access the current
menu window and the main menu window, respectively. When a spawn routine wishes to
access the menu window, it can do so by directing its read and write operations to io.lun.
However, user routines should never alter which window is opened on this logical unit (that
is, such routines should never perform FCLOSE or FOPEN operations on this logical unit).
Furthermore, user routines should not access the main menu-window logical unit (io.lun2)
under any circumstances.
3
Chapter 1 - Introduction
1.5
Overview of This Manual
The following chapters describe the details of the AIM Base System. The emphasis is on
customizing AIM for specific applications or classes of applications. After reading this manual,
you should have a good feel for how the (baseline) AIM software is structured and a detailed
understanding of those segments of the system that can be customized. The following paragraphs
describe each of the chapters of the manual.
Chapter 2 provides a basic overview of the system, its components, the terminology used to
describe the system, and basic concepts used in a data driven programming environment.
Chapter 3 describes the AIM database manager. You use the database manager to create new data
bases, alter existing databases, and perform other operations such as merging, compressing, and
exporting databases.
Chapter 4 provides an detailed description of the types of databases used by AIM and the way
they are used. There are several databases that are common to all AIM applications (baseline
databases). The structure of these databases is provided.
Chapter 5 describes the runtime system. It includes details on runtime task definition and global
data structures. It also describes communication with the operator interface—including error
handling, operator responses, pausing, and walk-thru training. The routines for the sequence
scheduler are described, along with the data structures used. Finally, an overview of the general
low-level primitive routines is presented, including guidelines for using them and guidelines for
creating new routines.
Chapter 6 describes AIM statements. This section is of particular interest to a system customizer,
since it describes how the AIM syntax can be extended to handle user-defined, task-level assembly
operations. This chapter tells how to add new statements, and how adding whole new classes of
data (arguments) affects the rest of the system.
Chapters 8, 9 and 10 deal with the operator interface for the system, which includes the following:
the programming aspects of the AIM menu driver, the operation of the routines for managing
loadable databases, teach mode, and other user-interface topics.
Chapter 13 describes how errors are dealt with by AIM. Because AIM is such a large software
system, it assigns numbers to errors and divides them into classes depending on when they may
occur, how serious they are, etc. For each error number there is a predefined error message string.
Chapters 14, 16 and 17 contain “dictionary pages” for many of the routines provided with the AIM
Base System. Chapter 17 describes user-written spawn routines used by the menu driver. Chapters
14 and 16 contain descriptions of other routines that are used by the AIM system, and that can be
called by routines written by system customizers. These descriptions can be used for reference
when writing new routines to customize the AIM system for a specific application.
There are a number of appendices at the end of this manual. They include:
• Summaries of the disk files for the AIM Base System.
• Descriptions of all the AIM error messages.
• An index of AIM global variables.
• An index of AIM program names.
4
Chapter 2
AIM Overview
2.1
Introduction
AIM is a database management system designed for use in the V+ operating environment. It is
specifically designed and optimized for use with motion control and machine-vision operations.
AIM is intended for two primary groups. The first group is custom applications developers who
want to create complex, data-driven, generalized applications that are easy to use at the operator
level. The second group is end users running the AIM application modules. The AIM application
modules are application specific software packages that allow a user to build complex custom
workcell implementations with little or no programming. Machine vision inspection and printed
circuit board assembly are two example application modules.
The AIM system is composed of:
Databases
The basic unit of the AIM system. Databases store all the necessary
information to execute and coordinate an application.
Editors
Used for entering and editing the information in the different databases.
V+ programs
Information stored in the databases is used as parameters to V+ programs
that actually issue instructions to the workcell devices.
Linker
Rather than perform a complete database search each time a value is
required, AIM searches the required records prior to execution and sets
pointers to those records. Then, during execution, the required values are
immediately available, and cycle time is minimized.
5
Chapter 2 - AIM Overview
2.2
AIM Databases
Figure 2-1 shows the different databases you will be working with in AIM.
Base System
Databases
Record:
Record:
Record:
Accounts
Record:
Record:
Record:
Module
Directory
Record:
Record:
Record:
Backup
Record:
Record:
Record:
Attach
User Modifiable
System
Databases
Record:
Record:
Record:
Statement
Record:
Record:
Record:
Help
Record:
Record:
Record:
Init
Application
Module
Databases
Record:
Record:
Record:
Vision
Record:
Record:
Record:
Location
User
Databases
Record:
Record:
Record:
User_1
Record:
Record:
Record:
User_2
Record:
Record:
Record:
Sequence
.
.
.
.
.
Record:
Record:
Record:
Error
Messages
Record:
Record:
Record:
.
Menu
Record:
Record:
Record:
Variable
Record:
Record:
Record:
Other
Option DBs
Record:
Record:
Record:
User_n
Figure 2-1
AIM Databases
Fixed, Loadable, and Disk-Resident Databases
Depending on how it is used, a database will be either fixed, loadable, or disk resident.
Fixed databases are loaded to system memory at AIM startup and remain in memory for the
duration of the AIM session. Loading database to memory allows rapid access to data so timecritical workcell operations do not have to wait on disk accesses for database values. Any
databases used by an executing sequence must be a fixed database.
Loadable databases are also RAM resident. However, these database may be loaded and unloaded
during a single AIM session.
Disk resident databases are ones that reside only on disk. Information is brought into system
memory only when it is requested. Databases that are not critical to a workcell implementation are
normally left disk resident. The Accounts database is an example of a disk resident database. (Of
course, a copy of all fixed and loadable databases is kept on disk and updated each time a save is
performed or AIM is exited.)
6
AIM Databases
System Databases
System databases support system level, front end, and housekeeping tasks. As such, their access
time is not critical, and they are loaded to system memory only as necessary. Table 2-1 gives a brief
description of the special databases. The structure of these databases is detailed in Chapter 4.
Table 2-1
System Databases
Database
Use
Accounts
Keeps track of the system users and their access levels.
Attach
This database stores the copy buffer for the sequence editor. Statements
cut or copied from a sequence are stored in this buffer until they are
pasted to a sequence.
Resource Module
Store the names of the various databases that comprise a resource
module.
Application Module Databases
AIM application modules such as MotionWare and VisionWare have their own databases. The use
of these databases is described in the user guides that come with the module. The structure of the
databases is described in the reference material supplied with the module.
User Databases
In addition to the databases provided with your AIM system, you can create your own custom
databases. Database creation is described in Chapter 3.
User Modifiable Base System Databases
There are several base system databases that the user might copy or modify when customizing an
AIM system. Table 2-2 gives a brief description of the databases. The structure of these databases is
detailed in Chapter 4.
Table 2-2
Base System Databases
Database
Use
Error Messages
Stores the text for the error codes returned by the system.
Menu
Stores information to draw and support menu pages. AIM contains a
powerful menu page editor for creating custom user interfaces. The use
of the menu database is described in Chapter 4. Menu databases have the
file extension .MNU.
Help
Every field in an AIM menu page can have a help string associated with
it. The messages associated with help strings are stored in help databases.
Help databases have the file extension .HLP.
Initialization
Store preference-type information used when AIM is started up.
7
Table 2-2
Base System Databases (Continued)
Database
Use
Sequence
Each sequence created is a complete database, with the statements in the
sequence forming the records for the database. When you create a new
sequence, you are actually creating a new database. Sequence databases
are stored with a name that is determined by the resource module that
they are part of.
Statement
The text, syntax, and argument source used by each statement is stored in
a statement database (see Chapter 6).
Variable
Stores user defined “variable” data.
2.3
The AIM Statement
The core of the AIM system is the statement. A statement is a generalized task-level instruction
that generates a high-level action by the system. The MOVE statement is an example of a
generalized task-level statement. This statement can access all the necessary databases and
execute the necessary V+ programs to implement a sophisticated robot move.
The AIM customizer can create task-specific statements that allow operators to create complete
workcell implementations in a menu-driven environment. Creating custom statements is covered
in Chapter 6.
2.4
Overview of Statement Creation and Execution
A statement is a task level description of a common procedure that takes place in a robotic or
vision workcell. The purpose of a statement is to create an “instruction” that defines a common or
repetitive task, and allow a user to create sequences made up of these common tasks. This allows a
user to define the work to be done by a robot or vision cell without worrying about all the minute
details or the code needed to actually perform the work. A statement by itself will not perform a
useful task because it is a very general description of what must be done. In order to make a
statement useful, an operator combines a statement with specific data from an AIM database. This
combination of general task description, combined with specific data, allows an operator to
concentrate on a given task and ignore the programming that controls the execution of the task.
There are three stages of development for a statement:
• The first stage is creating a record in a statement database that defines the format of the
statement, text that describes the action the statement will take, the source for the information
used by a statement, and what information is required and what is optional.
• The second stage is writing a V+ routine that actually access the databases and performs the
necessary work to implement the statement.
• The third stage is actually selecting a statement, completing the arguments in the statement,
and then running and debugging the statement operation.
8
Overview of AIM Runtime
2.5
Overview of AIM Runtime
Figure 2-2 on page 10 shows the information flow when an AIM sequence is executed. The gray
lines indicate activities that take place before execution begins (linking). The black lines indicate
the information flow during execution of a sequence. The steps shown in Figure 2-2 are:
1. A new sequence is selected at the control panel (or executed by a control sequence).
2. The statement names and definitions are retrieved from the statement database.
3. The database names stored in the sequence statements are converted to pointers to the
records within the appropriate databases.
4. Any linking rules defined in the initialization files are evaluated, and indirectly referenced
records (source records) have their record pointers stored in the referencing database.1
5. Runtime begins.
6. The scheduler accesses the sequence database to retrieve the next statement. The name of the
routine to execute (the statement name) and the list of record pointers (or other argument
values) to pass to the routine are retrieved.
7. The statement routine and its argument list is executed with a CALLP instruction. The routine
may call other V+ subroutines (statement primitives).
8. During execution of the statement routine, the pointer values passed to the routine are used
to access the needed values from the AIM databases (or, in certain cases, the values are used
directly).
9. If walk-thru training is selected, the sequence pauses and allows updating of records called
by the statement.
10. The next statement in the sequence is processed (or execution terminates).
1.
During linking, the symbol tables for the CALLP instruction are created.
9
Workcell
RUNTIME
V+
5
Control Panel
6 10
1
Record:
Record:
Record:
Resource
Module
10:30
Th ehh ehh wke kjtjek
10:30
Th ehh e
10:30
10:30
Th ehh eh
10:30
10:30
The
S
C
H
E
D
U
L
E
R
Statement
Routines
7
Statement
Primitives
9
8
Record:
Record:
Record:
Record:
Record:
Record:
Record:
Record:
Record:
Record:
Record:
Record:
2
Sequence
Database
Statement
Database
Application
Module
Databases
3
4
3
Linker
Figure 2-2
AIM Runtime Overview
10
User
Databases
Customizing AIM: An Overview
2.6
Customizing AIM: An Overview
Customizing AIM can take place at several levels of complexity, and at several points in the AIM
code. The levels of customizing are:
1. Menu Page Modifications
This level of customization involves changing the content and appearance of existing menu
pages and possibly creating new menu pages. You would perform these modifications to
make an existing AIM module more closely reflect the way you would like information
presented to your operators. You might hide some information, re-arrange how the
information is presented, or move certain information to another menu page. This level of
customization requires no new V+ code or structural changes in the way AIM operates.
2. Statement Creation
This level involves creating a new statement and the associated structures to support the
statement. The structures you might create or modify are: V+ code, databases, and menu
pages.
3. AIM Application Module Creation
This level involves all aspects of AIM customization: new databases, new pull-down menus,
new statements, new runtime code, and new menu pages.
The following list identifies where you would look for information about the various options
available to AIM customizers.
Action
Reference
Modify the existing menu pages of AIM or its application
modules to suit your specific needs.
Chapter 8
Modify an existing AIM statement (from one of the
application modules) to more easily or effectively carry out
the task you are using AIM for.
Chapter 6
Create new AIM statements.
Chapter 6
Create new AIM databases and menu pages to support
modified or newly created statements.
Chapter 3
Define linking relationships between databases.
Chapter 7
Modify the AIM runtime system (e.g., change the scheduler)
to suit your particular needs.
All chapters
Create/modify V+ code using the V+ Developer.
Chapter 11
If you are modifying an existing AIM module, see the module’s reference guide for additional
information.
11
2.7
The AIM Modular Approach
AIM is designed so custom applications can be built in a modular fashion. This approach stresses:
• The ability to modify existing application modules to suit the customizer’s needs.
• The isolation of custom code and databases from Adept supplied routines and databases.
• The efficient use of system memory.
• The use of Adept supplied routines for low-level operations.
The AIM customization operations described in this manual cover operations that are performed
with the base AIM package. They are common to all AIM application modules. If your system
includes one or more of the AIM application modules, your documentation will include reference
material on the databases, menu pages, and customizable code that is particular to those
applications.
The AIM “Loader” File
All AIM application modules have a special file containing programs to load the proper runtime
files and initialize system startup. For example, in MotionWare the file is LMOW.V2. This file
contains several important programs:
lmow
Monitor command program that loads all program files that will reside in
system memory for an entire AIM session. This program can be modified to
load custom program files. See the next section for recommended options to
modifying this file.
ai.module.init
Program to set the initial status of AIM. This program is user modifiable.
(See the next section for recommended options to modifying this file.)
rn.sched
The AIM runtime scheduler. This program retrieves and executes sequence
statements. This program can be modified.
AIM File Types
Adept uses the filename conventions listed in Table 2-3 to help identify the different types of files
used. With the exception of the loader file, all files follow these conventions.
Table 2-3
AIM File Types
File Ext.
File Use
.SQU
Program files that are loaded at AIM startup and stay memory resident for an
entire AIM session. The programs have been squeezed with the Adept utility
program SQUEEZE.V2 and have all comments and blank lines removed from them.
Programs are squeezed so they take up less space in system memory. All user
modifiable .squ files are delivered with a corresponding file containing fully
commented programs. The commented files have a .V2 extension.
.V2
The user modifiable .SQU files are delivered with a .V2 file of the same name. .V2
files are not loaded, but provide system customizers with commented code to use
for modifications. After modifying a .V2 file, delete (or rename) the corresponding
.SQU file and squeeze the modified .V2 file to produce a new file for use by AIM.
12
Additional Customizing Guidelines
Table 2-3
AIM File Types (Continued)
File Ext.
File Use
.OVR
Program files that are loaded and unloaded from system memory as they are
needed. .OVR files that are user modifiable have a corresponding unsqueezed file
with a .OV2 extension.
.OV2
The user modifiable .OVR files are delivered with a .OVR file of the same name.
.OV2 files are not actually loaded, but provide system customizers with
commented code to use for modifications. After modifying a .OV2 file, delete (or
rename) the corresponding .OVR file and squeeze the modified .OV2 file to produce
a new file for use by AIM.
.DB
Databases that are used by the AIM system or AIM applications to store data for
specific workcell implementations. These are your data files and should be backed
up whenever changes are made to the databases. (The backup/restore utility is
handy for backing up files.)
.DBD
Reserved for the “Default Database” file (a disk file containing default records).
When the module utility creates a new module component, it attempts to make a
copy of a file with the base file name for this type, using the extension .DBD. If no
such file exists, the extension .RFD is used. The base file name is defined by the call
to ai.db.define( ).
.RFD
Field definition files used to create databases (see Chapter 8).
.MNU
Databases that store menu page records. Every menu page will have a record in a
.MNU database. Most of the .MNU databases can be modified, except for base menu
pages that are used for all AIM applications. If you attempt to modify a protected
database, you will be advised that the database is read only.
.HLP
Databases that contain the on-line help. .HLP databases are automatically tied to
.MNU databases (see section 4.5).
.DAT
Icon files (see “Icon Editing Utility” in the Instructions for Adept Utility Programs).
2.8
An important guideline for any AIM customization should be to isolate, as much as possible, the
changes that you make from the Adept supplied functionality. This will make it much easier to
upgrade to new versions of AIM. The following sections discuss some of the options available for
segregating custom modifications from Adept supplied functionality.
Using the Initialization Databases
There are several records in the base initialization database (BASEINI) dedicated to helping AIM
customizers produce independent functionality. When used correctly, they allow you to simply
13
move your custom files to a new installation of AIM and then change the initialization records to
use your custom files. The records are:
Record Name
Use
File
error/message log queue
size
error/message log queue
task
These records support a user defined logging task
for queuing and responding to any user or error
messages generated during AIM runtime.
BASEINI
master control panel file
name
master control panel page
name
These records specify which menu page to display
when the Execute ➡ Master Control Panel
option is selected.
MOWINI/
VWINI
example - custom camera
model
By adding a new record of this type, you can
create custom camera models for cameras you use
that do not fit the standard Adept camera
definitions.
VISINI
example - custom
convolution
example - custom morph
pattern
By adding new records of these types you can
define custom convolution and morphology
operations.
error, database
This record allows you to specify a database that
contains custom error messages. This file is
loaded before the standard error database and if a
duplicate number is found it is ignored. Thus you
can redefine as well as add error messages.
Additional error databases can be loaded by
adding a new record of this type.
USERINI
overlay, additional
This record allows you to specify an overlay file
that will be loaded and a program from that file
executed during AIM initialization. This allows
you to place all your initialization code in your
own file and not have to modify the AIM
initialization routines. Additional overlay files
can be loaded by adding a new record of this type.
USERINI
statements, additional
You can specify the name of a statement database
you create and your custom statement definitions
along with the Adept supplied statements.
Additional statement databases can be loaded by
adding a new record of this type.
USERINI
There are several other initialization records that determine characteristics of the system when it is
first started. These records are described in the user guide for the appropriate module.
See “Customizing Initialization Databases” on page 42 for additional details on using
initialization databases.
14
Custom Statement and Error Databases
When AIM is first started, the system processes all the STAT∗.DB files found in the initialization
database and a pick list of statements is built for use by the sequence editor. These statements are
sorted into groups based the value specified in the “group” field of the statement records. By
creating your own statement databases and loading them with an initialization record, you can
move custom statements to new versions of AIM by simply copying the database and related
statement routine files to the new system and making any needed changes to the initialization
database.
Similarly, you can create and move your own error databases. In the case of error databases, the
various databases are read in the order they appear in the initialization database and the standard
error database is read last. In the case of duplicate records, the first record found is the one that is
used. Thus, you can modify existing error message by creating a new record with the same
number in your custom database. This record will take precedence over any Adept supplied error
with the same number.
Menu Page Files
When you create new menu pages, you should add them to your own files and not mix them with
Adept supplied menu page files. Pull downs for displaying various pages can be added in your
initialization file. If you create new databases that you want to be accessible directly from the
sequence editor, the editing page must be in a file with specific naming conventions. See
ai.db.define( ) on page 288 for details.
15
2.9
Autostarting AIM
There are two levels to autostarting AIM: autostart of AIM when the controller is turned on and
autostart of a sequence when AIM is started. These two levels can be used together or alone.
Autostarting AIM
There are autostart files delivered with each AIM module (MOWAUTO.V2, VWAUTO.V2,
PCBAUTO.V2 and MOWAUTO2.V2, VWAUTO2.V2, PCBAUTO2.V2). The first set is for a system
without V+ Extensions and the second set (with a “2”) is for systems with V+ Extensions and dual
robots. The appropriate autostart file must be copied to the root directory1 and renamed AUTO.V2.
The autostart option must be selected on the SIO module (see the Adept MV Controller User's
Guide).
When these changes have been made, AIM will automatically be started when the controller is
turned on. See the next section for details on autostarting a sequence when AIM is started.
Autostarting a Sequence
There are two records in the BASEINI initialization database that control Autostarting a sequence:
The first is “autostart module name”, which specifies the module that contains the autostart
sequence; and “autostart sequence name”, which specifies the sequence to execute.
Simply adding appropriate values to these two records will enable autostarting of a sequence
when AIM is started.
1. Or
16
the default directory if it has been changed in the system configuration file.
Chapter 3
AIM Database Manager
3.1
Database Concepts
Before presenting the details of the Adept database management system, you should be familiar
with the following general concepts.
Database Files
There is a disk file associated with each database. The disk file permanently stores the information
contained within the database. The database manager allows you to create, format, access update,
and maintain database disk files.
Before information in a database can be accessed, the database must be “opened” by calling a
routine in the DBM library.
Disk-Resident and Memory-Resident Databases
How a database is accessed depends on its size. For moderate-sized databases, the entire database
may be resident in system memory. Such “memory-resident” databases can be accessed very
quickly. Once a database has been opened as memory-resident by any V+ task, all V+ tasks can
simultaneously use the database. Also, memory-resident databases access the disk only when the
file is initially opened, when the file is updated, or when the database is “closed”.
If the database is large, it may not be possible to fit the entire database in the available memory at
one time. In this case, the database can be opened as “disk-resident”. For disk-resident databases,
the database management system automatically reads in portions of the database as they are
needed and writes out any changed portions that are no longer required. Disk-resident databases
are slower to access and require the database file to be open the entire time the database is open.
Unlike memory-resident databases, a disk-resident database can be accessed only by the V+ task
that opened the database. With this one exception, the difference between utilizing a memoryresident or disk-resident database is hidden within the database system, and software can be
written that will access either type of database.
Up to 255 databases can be simultaneously open, using any combination of memory-resident and
disk-resident databases (subject to constraints of disk access and available memory).
Database Records
Figure 3-1 shows the basic parts of an AIM database.
17
Chapter 3 - AIM Database Manager
Record:
Record:
Record:
Field
Data
Name: John Blimp
Address: Mail Stop 1342
Phone: 408-555-1800
Company: Adept Tech.
Database
Record
Figure 3-1
Database Structure
Database
A database is a collection of records. Records can be added to a database until memory constraints
are reached, or until the allowed maximum of 32,768 records exist in the database.
Records
Records contain information about a single instance of the “entity” the database is keeping track
of. The entities can be persons, parts, statistical data on a process, or most any other entity that is
amenable to categorization based on its attributes. Each record in a database contains all the fields
defined for the database.
Fields
Fields hold data. When you define a field you tell AIM:
• The name of the field.
• What type of data (string, number, transformation, etc.) the field is going to contain.
• How large the field should be (some data types have default sizes that cannot be changed).
• If the field is to contain an array of values rather than a single value (the number of array
elements allowed is also specified).
• If the database should be sorted based on values in the field.
• Default values (if any) that should be placed in each new record created.
The data within a database is logically organized in a series of database records. Each record is
made up of one or more fields, where each field contains either a single data value (such as a real
number, a string value, or a robot location), or an array of several values (all of the same type). All
the records in a given database contain the same arrangement of fields.
After a database has been opened, each V+ task that needs to access a database record must
“open” the record. Opening a record selects it for use and, in the case of disk-resident databases,
automatically copies the record from the disk file to system memory. At any given time, each V+
task can have only one record open for each database. However, the system automatically keeps
18
Database Concepts
track of which records have been opened by each task, so different tasks can have different records
simultaneously open within the same database.
Logical and Physical Record Numbers
All access to AIM loadable databases is by record number. Before specific field data can be
accessed, the desired record must be “opened”. When you open a record you merely set a pointer
to the specific record and all subsequent reads and writes of information are directed at the open
record. There are two different sets of numbers maintained for each loaded database, logical
numbers and physical numbers. The following sections describe the ramifications of this number
scheme.
Logical Numbers
The first series of numbers is the logical numbers. A logical number is simply the sequential
number of each record as it occurs in the database. A database with 5 records will have those
records numbered from 1 to 5 with the first record in the database being number 1 and the last
record being number 5. These numbers are subject to change during normal database operations
such as deleting and sorting. For example, if you add 2 records to the end of the database, you will
now have 7 logical record numbers. If you now sort the database, you will still have 7 contiguous
logical record numbers, but they may no longer refer to the same physical record. Thus, if you
open a record based using a logical number and then add, delete, or sort the database, you can no
longer assume that you will access the correct record. You also cannot assume that if you use the
same logical number to reopen a record that the same record will be opened.
Physical Numbers
Each time a record is added to a loadable database it is given a unique number and this number
will always be associated with a given record regardless of its position in the database. Thus, if
you start with 5 records, you will have 5 unique physical record numbers. If you then add 3 new
records, you will have 8 unique physical record numbers. If you then delete 4 records, you will no
longer have contiguous physical record numbers—all the physical numbers associated with the
deleted records will be gone. Thus, if you reopen a record using a physical record number, you
will always get the same record (as long as the record has not been removed from the database).
The Current Record
When you open a database record using either a physical or logical number, that record becomes
the current record. A current record pointer is maintained for each task that accesses a loadable
database. Therefore, multiple tasks can access the same database without worrying about who has
the current record pointer. Some problems will arise, however, under certain deleting and sorting
operations. This section will discuss some of the possible problems.
How It All Works
1. When a loadable database is loaded into memory it is in sorted order and the physical record
numbers and logical record numbers are contiguous and identical. The first record is logical
record number 1 and physical record number 1, the second record is logical record number 2
and physical record number 2, and so on.
2. The current record (for the task that opened the record only) will be the first record. (Unless
the database is empty, in which case there is no current record.)
3. If records are appended (and no records deleted or the database sorted), the logical and
physical records will still be contiguous and identical. If records are inserted, logical record
numbers for all records after the inserted record will change. The physical record numbers
will still refer to the same record names.
19
4. If a database that is not in sorted order is sorted, the logical records will be contiguous and
represent the current order of the database. The physical record numbers will still be
associated with the same physical record as before the sort was performed. Thus, the physical
records will no longer be contiguous and will not match the logical record numbers.
5. These numbers are meaningful only as long as a database is in memory. When AIM is shut
down and restarted, the database will again be in the state described in step 1.
6. Any number of tasks can access a database and each task will maintain its own pointer to its
current record.
7. When a database is sorted, the current record for the task performing the sort becomes the
first record (logical record 1).
8. When a record is deleted, it is not actually removed from the database, but is marked for
deletion. You can still open this record and you can, in fact, undelete the record.
9. When a database is sorted, all deleted records are removed and the empty space left by those
records is available for use by any newly added records. The only way to remove this space is
to close and reopen the database.
Displaying Database Records
While the routines within the database management library can be used to develop specialpurpose programs for displaying database values, the AIM menu driver provides a flexible and
powerful means for displaying database information. Using the AIM menu driver, operator
interfaces can be developed to display all the database field types in a variety of formats (for
example, numerical fields, slide bars, YES/NO, ON/OFF, icons). These database field values can
also be combined on the same screen with graphics, menu buttons, static icons, text, status of
digital I/O, and values of global variables. In addition, the menu driver can provide data
validation and range checking during data entry. See Chapter 9 for details on creating menu
pages.
Database Header
In addition to data records, each database file contains a header with the following information:
1. A title string (with 1 to 80 characters)
2. A definition of the fields for each record
3. The date the database was created, and the date it was last updated
4. Strings that the programmer may use for information associated with the database
The database header information is accessed by the DBM Utility, and by various routines in the
database management program library.
Standard Database Files
Standard database files are normally created with the file extension “.DB” or the database type
code (see Table 4-1). These files contain all of the header information (described in the previous
section) together with a set of records that holds the database information. In principal, a complete
application could be developed using only .DB files.
20
Databases in AIM
In practice, it is convenient to maintain a secondary set of database files that are identical to the
primary .DB files, but do not contain any data.1 These record format definition files (which are
usually assigned the file extension “.RFD”) are templates for creating new .DB files. The .RFD files
contain a duplicate copy of the record field descriptions, the database title, and the default record.
Since .RFD files do not contain any data, if any field definition must be modified, the definitions in
the .RFD file can be safely modified without concern for accidentally losing or corrupting any data.
After the .RFD file has been suitably modified, the DBM Utility can be used to convert the data
within the corresponding .DB file to the new field format.
NOTE: As a safety precaution, the DBM Utility looks at the extension of a
database file, and restricts some functions to operate only on empty
databases whose file extensions are .RFD.
3.2
Databases in AIM
This section describes AIM database conventions that are used in multiple databases. In order for
your databases to operate correctly within the AIM system, follow these conventions when
changing or adding databases.
Headers
Each database file contains a header area, which is used to store data common to the entire file.
AIM uses this area to keep track of database update information, etc. The database header area
should not be modified by any routines written by system customizers.
Titles
The titles of databases are used in various sections of AIM to construct output messages to the
operator and to reference databases during database editing. For example, when Utilities
Save All DBs is selected, the title from each of the open databases is extracted and displayed along
with the database modification status. The title is also used when displaying an operator message
that refers to a database.
➡
The title for each database should be kept to a single word, should be in lowercase letters, and
should not include the word database. Some sample titles are: part, parttype, and path. The title in
the .RFD will be used as the default name of the database when added to a resource module.
The files names must not be changed, or the Resource Module will not be able to locate the correct
files.
Field Names
The database field names are used in various sections of AIM to construct output messages to the
operator and to reference databases during database editing. For example, when an error occurs,
the field name is often displayed to indicate the value in question.
Record Names
Databases that are referenced by AIM statements, or that are linked to other databases by name,
always have their first field defined as a 15-character name. This name is used as the record name
and is set to be the primary sort field. For most databases, the name is also specified to be unique,
which means that each record has a unique name. Sorting by this name field speeds linking and
searching for a specific record, and alphabetizes database index displays.
1.
This type of file is required for any new databases used by a resource module.
21
A record’s name is displayed by the sequence editor, the tree display utility, in database-related
error messages, and in database index pop-ups.
Record Update Dates
Whenever a record in a database is edited while AIM is running, and the second field of the
database is a date field named “update date”, the value of that field is set to the current date and
time. This provides a convenient, automatic method for keeping track of when data values have
been altered.
This field is required for any database that will be linked. The linker uses this field to determine if
the database needs to be re-linked.
Devices
For those databases that can contain information for more than one device, the third database field
is defined as an integer data type with the field name “device”. The values in the device field
correspond to the devices in the device keyword list. This keyword list is built by successive calls
to the program ai.dev.define( ). See ai.module.init( ) in the application loader files (lvw, lmow,
etc.) for examples of defining device types.
This field is used by teach routines to know which devices to record a position from.
Menu Page Names
When a database is accessed via the menu driver and the menu page name is unspecified, if the
fourth database field is a string value with the field name “menu page name”, the value of the
field is used as the menu page name. This allows databases to be created whose records are
displayed using a number of different menu page formats. In addition, if the menu file name is not
specified and the “menu page name” field is an array with at least two elements, the value of the
second array element is used for the file name.
Field Attribute Bits
The definition for each record field has a 16-bit attribute word associated with it. The value of this
word is set during database definition, but is otherwise ignored by the database software. The
attribute value is used by the AIM system to indicate attributes of the field in addition to the
normal database value type.
Table 3-1 summarizes the field attribute bits and lists the V+ variables used to reference them. The
interpretations of the bits are described in detail below.
22
Databases in AIM
Table 3-1
Field-Bit Attributes
Symbolic Name
Mask
Value
Interpretation
ai.attr.loc
^H1
Basis location for robot motion block
ai.attr.mve
^H4
Field in motion block, not first
ai.attr.mve.st
^H5
First field of motion block, no approach
ai.attr.mve.app
^H7
First field of motion block with approach
ai.attr.opt
^H8
Field is optional at run time
ai.attr.edit
^H10
Field is edited if defined during walk-thru training
ai.attr.upd.fld
^H80
Mark database as updated if this value changed
The low-order three bits (bits #1, #2, and #3) of attribute values are set for parameters associated
with locations that are teachable by a robot device. These three bits should be set to zero for all
fields that are not robot-related locations or motion parameters. For additional details on robot
motion blocks, see the Databases chapter in the AIM MotionWare Reference Guide.
Attribute value bit #4 (with mask value 8) indicates whether a location field is optional at runtime.
If this bit is set, and the runtime system detects that there is no data defined for this field, then no
error is displayed and the associated robot motion is skipped.
Attribute value bit #5 (with mask value 16) indicates whether a field should be edited during
walk-thru training “Edit All” mode. In this mode, the system will pause for editing if this bit is set,
even if the field already contains valid data. To avoid flooding the operator with edit requests, this
bit is normally set only for locations to which the robot moves.
Attribute value bit #8 (with mask value 128) indicates whether the database should be marked
updated whenever the corresponding field value is modified. If a database has been updated, it
must be relinked before the next sequence can be executed. Update fields are normally those fields
that contain either the name of the record or the name of a record in another database.
Database Numbers
When you add a memory resident database to AIM, you must give it a unique number that allows
AIM to initialize its data structures for keeping track of the various database. This number is used
only once in the call to ai.db.define( ) when the database is first loaded. After this initial loading,
you will use the database type code and AIM data structure as described below.
When you access a memory resident database in AIM, you use a number that is supplied by the
system. The database number is based on a type that is given when the database is initialized at
start-up, and the current task that is accessing the database. The routine ai.db.define( ) specifies
the database type, and it sets up the data structure used by statement routines when accessing the
database. For example, when the MotionWare path database is initialized, it is given a type of
“ph”. AIM initialization creates an array of values that are used to access the various copies of the
path database. The form of the array is:
ph.db[TASK()]
23
The values in the array automatically take care of whether there is a local copy of the database or
the global copy is being used. Thus, if you have a routine that needs to access the path database
used by any executing sequence, you would get the number by:
ph.db[TASK()]
The two letter prefix that identifies a database is provided in the documentation for that database.
If you create any new memory-resident databases, you will supply the two letter prefix in the call
to ai.db.define that initializes the database. See the program mw.rob.init( ) in MWMOD.OVR or
vw.mod.init( ) in VWMOD.OVR for examples.
Temporary Disk Files
The database management library creates temporary files to hold intermediate results when
sorting disk-resident databases. The following names are used for the temporary files (where *
represents any series of characters):
DBMSORT.T∗
DBMSORT.N∗
These auxiliary files are automatically deleted if the database operation is completed successfully.
However, the intermediate files may not be deleted automatically if some type of fatal error occurs
during the operation. In that case, the user should delete the file manually with a V+ FDELETE
monitor command.
3.3
Adding Databases to AIM
Three operations are required to create a usable custom database in your AIM system:
1. Create a record format definition (.RFD) file.
2. Create a database file based on the record format definition file.
3. Alter the AIM system to use the new database. The system may be altered to use the new
database in one or more of the following ways:
• Place the new database in system memory at start-up.
• Create menu pages to edit/view the database records.
• Create runtime code to access the database records.
• Create links between the new database and other databases.
This chapter covers creating a record format definition file, and a database file based on the
definition file.
See the routine ai.db.define( ) in Chapter 16 for details on making new databases memory
resident database. See the program mw.mod.init( ) in MOWMOD.OVR/OV2 or vw.mod.init( ) in
VWMOD.OVR/OV2 for examples.
See Chapter 8 for details on creating menu pages to edit/view databases.
See section 7.1 for details on establishing links between database files.
The AIM application module reference guides (AIM MotionWare Reference Guide and AIM
VisionWare Reference Guide) detail the databases used in the completed applications supplied by
Adept. Consult these manuals if you are modifying existing databases supplied with the
application modules.
24
Adding Databases to AIM
Making a Database Memory Resident
Before custom databases can be used, they must be opened1 and assigned a number. The number
assigned will be used by AIM to manage the multiple copies of databases that may be open at one
time. The numbers 1 − 127 are used to reference memory-resident database types. Adept uses the
lower numbers for system and application module databases. To avoid conflicts with future
updates, custom databases should be assigned numbers starting with 127 and working down.
Databases are open by a call to ai.db.define( ). This call specifies all the information needed by
AIM to manage the database and incorporate it into statement definitions. See the description in
Chapter 16 for details.
Database Titles and the Resource Module
The title in the .RFD file is used as the default database name when the Resource Module creates a
runtime database. Therefore, the title must conform to the file name conventions.
.RFD Files and Menu Pages
When a statement argument is double-clicked in the sequence editor, the system will attempt to
open a menu page from a .MNU file with the same name as the .RFD file that was used to create
runtime database. If a .MNU file with the appropriate name does not exist, you will not be able to
edit a record by double clicking on its name in the sequence editor.
The actual page displayed will be taken from the “Menu page name” field. If this field is blank, the
system will attempt to display a page with the name “main”. If the “Menu page name” field is
blank and there is not a page named “main”, you will not be able to edit a record by double
clicking on its name in the sequence editor.
1.
Custom databases must be opened as memory-resident databases. This is due to the limitation of disk logical units available and the limitation that disk-resident databases can be
accessed only by the task that opened them.
25
3.4
Creating a New Database
There are two steps to creating a new database. The first is creating a record format definition file
that specifies the database’s fields and the field’s characteristics. The second step is creating a
database from the record format definition file.
To create a new record format definition:
Utilities ➡ DBM Utilities
Press Cancel on the pop-up window that is displayed
New ➡ Create RFD File ➡ enter file name1 ↵ ➡ Create
➊
➋
➌
➍
➎
➏
➐
➑
Figure 3-2
Creating a New Record Format Definition
1.
26
Unless otherwise specified, the file will be created with the default extension .RFD.
Creating a New Database
New Database .RFD File Options
➊
➋
Enter a title for the databases to be created from this record format definition file. If this
database is to be a member of a resource module, the title must be a standard AIM name.
The “Number of allocated records” information box shows the total number of records in the
database.
The “Number of deleted records” information box shows the number of records marked for
deletion. These records will be permanently removed when the file compression utility is run
(see “Compressing Database Disk Files” on page 31).
(These two information boxes will be blank for the .RFD file.)
The “Default record allocation” information box indicates whether default values have been
specified for new records added to the database. The default values are specified in the
individual field definitions when a new field is added (see section 3.5).
The “Record size in bytes” information box shows how many bytes each record in the data
base will require.
➌
➍
➎
➏
➐
➑
The individual fields and their characteristics are displayed in this area. Section 3.5 describes
field creation.
Press this button to edit the highlighted field. (A highlighted field is marked with a light blue
bar.)
Press this button to add a new field to the end of the file.
Press this button to insert a new field above the currently highlighted field.
Press this button to delete the highlighted field.
Press this button to edit the raw data in the database. This option allows you to edit a
database on a field by field basis. This option is useful when you are debugging statements
that use new databases. It may also allow you to correct data in a database that has become
corrupted.
Items ➎, ➏, ➐ are available only when editing .RFD files. Item ➑ is available only when editing
an actual database file.
27
3.5
Individual Field Definitions
When the Edit , Append , or Insert buttons are pressed during database editing, the menu
shown in Figure 3-3 will be displayed. The selections made to this screen will determine the
characteristics of the individual fields in the database.
➊
➋
➌
➏
➎
➐
➍
➑
Figure 3-3
Defining an Individual Database Field
28
Individual Field Definitions
Field Definition Options
➊
➋
➌
➍
Enter the name of the individual field.
Enter the sort order for this field. “0” indicates that the database will not be sorted on this
field. Any number of fields can have a sort order of 0. A sort order of 1 indicates this is the
primary sort field. A sort order of 2 indicates this is the secondary sort field (used to sort
records having identical values in the field with sort order 1 or –1). A sort order of 3 indicates
this is the tertiary sort field, and so on. Sort orders other than zero can be assigned to only one
field. A sort order of –1 indicates that a field is the primary sort field and that the values in the
field must be unique (two records cannot have the same value in this field).
Select the data field type. The standard AIM field types are:
Binary
The value in this field will be interpreted as a binary value (1s and 0s). The
range is 32,767 to 32,767 and requires two bytes of storage.
Boolean
This field will be interpreted as a Boolean value (yes/no, true/false, on/off).
The range is –1 or 0 and requires one byte of storage.
Byte
This field must contain an eight bit value. The individual bits in this field can be
read or updated. The range is 0 to 254.
Date/Time
This field must contain a date/time value in the standard AIM format:
dd-mmm-yy hh:mm:ss. Requires four bytes of storage.
Integer
This field will accept only the integer portion of a real value. The range is
32,767 to 32,767 and requires two bytes of storage.
Name
This is a string field that contains a name that adheres to V+ variable name
conventions. For compatibility with existing AIM functionality, field 0 should
be a name field that contains the name of each individual record. Requires one
byte for each character stored (maximum of 128).
Prec. Point
Precision points are not currently supported by AIM.
Real
This field must contain a numeric value. The value can have a whole and
fractional part. The full range of single-precision floating point numeric values
can be stored. This value is subject to normal rounding errors associated with
four-byte numeric representation.
String
This field must contain a string value. Requires one byte for each character
stored (maximum of 128).
Transform
This field must contain a transformation (location) value. Requires 48 bytes of
storage.
If this field is to contain an array of values rather than a single value, indicate the number of
array elements that can be accessed. When a value greater than 0 is placed in the data box, the
array index data box and scroll arrows will be displayed in the “Default Values” group.
If this field is a string field, indicate the number of characters that will be allowed in the field.
(Displayed only when a name or string data type has been selected.)
➎
User attributes are stored in a bit field. This number represents the hexadecimal number
created by setting the various options from the “User Attributes” group.
29
➏
If this field is a transformation value, a check box will be displayed in this area. The check box
will allow you to indicate whether the transformation can be edited during walk-thru
training.
If this field is a real, integer, or byte data type, a check box will be displayed that allows you
to specify that the value is part of a motion block. Select ✔ Motion Parameter and this area
will have the following options:
Start of APP/DEP indicates that this field is the start of a motion parameter block for an
approach or depart.
Start of LOC indicates that this is the start of a motion parameter block for a move to the
basis location (no approach or offset).
Not start of block indicates this field is part of a motion parameter, but is not the first
field in the block.
See the AIM MotionWare Reference Guide for details on how these blocks of fields are used.
➐
Select ✔ Mark DB as “updated” if changed if you want this database marked for updating
whenever a value in this field is changed. A field marked for update will cause the “update
date” field (see “Record Update Dates” on page 22) to be set to the current time whenever a
change to the field is made. If the update time of a database is later than the time of the last
link operation, any sequence using the record must be relinked before it can be executed.
Thus, any fields that have this option selected cannot be updated during walk-thru training.
This option is primarily for source fields that are accessed during the linking process.
Select ✔ Value optional at runtime if this field does not require a value. Any routines that
access a field having this option must be able to execute successfully if the field is found to
contain a zero or NULL value.
Select ✔ Edit during walk-thru training if AIM should pause and allow this field to be
edited during walk-thru training.
➑
30
If you want all the new records in this database to have a default value, enter that value here.
If an array value has been entered into option ➍, the “Array index” data box will be
displayed and you can enter default values for each array index. The arrows will move you
through the different array elements. These arrays start at element 0.
Creating a Database From a Definition File
3.6
Creating a Database From a Definition File
Once a record format definition file has been completed, you can create databases from the
definition file. To create a database:
1. Load the record format definition file:
Utilities ➡ DBM Utilities ➡ enter the definition file name ➡ Goto
2. Create the database:
File ➡ Create DB from RFD file
A pop-up window will be displayed requesting a name for the new database. Enter a name,
press Create , and AIM will create a file with the name you entered. The new database will
be stored on the default drive. See sections 3.1 and 3.2 for the database file name conventions
used by Adept.
After a database has been created, the following actions may be necessary to make it useful:
• Modify the AIM runtime code to make the database memory resident (see ai.db.define( ) in
Chapter 16). User created databases used by a statement must be memory resident before
they can be used.
• Modify existing statement routines or create a new statement routine to access the values in
the database (see Chapter 6).
• Create a new menu page to edit records in the database (see Chapter 8).
When Adept creates a new database, we declare constants for each field number. Routines that
access database fields use these constants rather than the absolute values of the field numbers.
This isolates routines from changes in the database structure.
3.7
Modifying an Existing Database
To alter an existing database, you add new fields to, or delete existing fields from, the existing
record format definition file. You then use the File ➡ Convert DB option to modify the field
structure of the exiting database.
The Convert DB option works in the following way:
1. When a database is converted, data is transferred to the new structure based on field names.
2. If the new definition file contains fields of the same name, type, and length as the existing
database, no data will be lost when the conversion is made.
3. If string fields are shortened or the maximum number of array elements in a field is lowered,
data will be truncated.
4. If field names were deleted from the definition file, all data in those fields will be lost.
Since database fields are accessed by number, any routines accessing fields in a database with a
modified structure must be updated to account for new field numbers. (Unless you were wise and
declared constants for all field numbers, then you merely have to update the values of the
constants.)
3.8
Compressing Database Disk Files
As you use databases, new records will be added and old ones deleted. Remember that when a
“record is deleted” it is not removed from the database file but is merely marked as deleted. A
record marked as deleted cannot be seen or edited, but it is taking up space in the database disk
31
file. To truly delete and remove a record from the database file, the database must be compressed.
When File ➡ Compress File is selected from the DBM Utilities menu, the selected database is
searched for records marked as deleted, the records are removed from disk, and the space is
recovered. This is true of all databases including the Error, Menu (.MNU) and Help (.HLP)
databases.
3.9
Additional Database Manager Options
To switch from one database or .RFD file to another:
File ➡ Switch File ➡ enter the file name ➡ Goto
To export a database in ASCII format:
File ➡ Export DB File ➡ enter the file name ➡ Create
The ASCII files will contain all the field names and the contents of each record in the database.
When exporting a database, you can specify the range of record numbers to export.
To export a database in ASCII format:
File ➡ Export RFD File ➡ enter the file name ➡ Create
The ASCII files will contain all the format information contained in the .RFD file
32
Chapter 4
System Database Descriptions
This chapter describes the databases found in the AIM baseline. It presents general concepts and
conventions, and describes the format of each standard database.
For information on other databases used by your AIM system, refer to the reference guides for the
AIM option modules or application modules included with your system.
For details on creating and modifying databases, see Chapter 3.
4.1
Database Descriptions
This section describes the standard databases used by the AIM baseline. These databases are
included with all AIM systems. (Additional databases may be included with AIM option modules
or application modules.) The standard databases are:
Table 4-1
Standard Databases
Database
Use
Type Code
Accounts
Stores access information for users of the system
NA
Backup
Stores information for creating backup/restore files.
NA
Error messages
Stores the error codes and corresponding text messages
used by AIM
NA
Help
Stores context sensitive help text
hp
Initialization
Stores preference information on user defined start-up
options
NA
Menu
Stores descriptions of the various AIM menu pages.
mu
Module
Stores the description of an AIM resource module.
md
Sequence
Stores the statements and arguments that define a specific
workcell implementation
sq
Statement
Stores the format and syntax information for defined
statements
st
Variable
Stores user defined AIM variables
va
33
Chapter 4 - System Database Descriptions
For each database, the record format is presented, with a description of the contents of each field
in the record. The following information is shown for each field:
• Field number and global variable
Custom AIM routines require you to access data from individual fields in a record. Adept has
defined global variables for each field number. Using the global variables instead of the
physical numbers will help insulate your custom programs from future changes. If a field
number must be changed, the global variables will be changed to reference the same logical
field. The global variables are loaded at system startup and are always available to your
programs.
• Name and sort order
This is the name used to refer to the field. If the field has a sort order, it is shown in
parentheses below the name.
NOTE: Fields with names enclosed in brackets (“[...]”) are used internally
by AIM and may be modified during linking or by runtime routines.
Thus, those fields should not be modified by system customizers.
• Data type
This is the database type of the field.
• Description
A short description of the way AIM uses the contents of the field.
• Size
The number of bytes taken by the field. If this is an array field, the size is for one element
only. If the field is an array, the number of defined elements is shown in square brackets ([ ])
below the size.
34
Accounts Database
4.2
Accounts Database
The Accounts database defines the names of the authorized system users, their passwords, and
their highest authorized access levels. The user access level is used to control access to restricted
menu items and system features. Each record in this database contains data for a single user.
This database is referenced only in connection with logging onto the system.
All the record fields are listed below, in the order in which they occur within a record. The fields
are summarized in Table 4-2. The data in an Accounts record can be accessed from an application
program by using the V+ variable names shown in column one.
Table 4-2
Record Definition for the Accounts Database
Field #
Global Var
Field Name
(Sort Order)
Data Type
Array
0
cc.name
user
(–1)
name
A standard name that is the name of the
authorized user. Each user name in the
Accounts database must be unique.
15
1
cc.update
update date
date
The date when this record was last
modified. This field is automatically set to
the current date when the record is
edited.
4
2
ac.password
password
name
A standard name, except that it is only 6
characters long. The value is a password
that is verified during the log-on process
to ensure that only authorized users are
permitted access to the system.
6
3
ac.level
access level
byte
Highest access level that can be granted to
the specified user. The most restricted
access level is 7 and the least restricted
level is 0. The standard access levels for
the various job categories are shown in
Table 4-3.
1
4
ac.logon
logon date
date
Last date that the specified user logged
onto the system. This field is
automatically updated by the user log-on
procedure.
4
Description
Size
Table 4-3
Standard Job Categories for Log-on
Access Level
Job Category
Access Level
Job Category
0
Access for everyone
3
Manufacturing engineer
1
System operator
4
System customizer
2
Hardware maintenance
5–7
Read/ write only item
35
4.3
Backup Database
The backup database stores information for the AIM backup/restore utility. AIM manages the
backup database and you should not need to be concerned with its internal structure.
All the record fields in the Backup database are listed below, in the order in which they occur
within a record. The fields are summarized in Table 4-4. The data in a record can be accessed from
an application program by using the V+ variable names shown in column one.
Table 4-4
Record Definition for the Backup Database
Field #
Global Var
Field Name
(Sort Order)
Data Type
Array
0
cc.name
Name
(1)
string
Name of the backup (displayed on the
“Backup Selection”, “List of Backup
Definitions” and backup specification
menu pages). Database flagged as
“updated” if this field is modified.
15
1
cc.update
Update
date*
date/time
Date/time this backup specification was
created or changed Database flagged as
“updated” if this field is modified.
4
2
Flags
byte
Configuration flags defining the scope and
operation of the backup
1
3
Index
(2)
integer
Sequential index number of the record
within a backup definition
2
4
Saveset
name*
byte
Code for type of name that will be used for
the backup saveset files:
1 = Current date
2 = Auto generated
3 = User supplied
1
5
Device*
byte
Code for the output device:
1 = Drive A
2 = Drive C
3 = Kermit
4 = NFS
1
6
Choice*
byte
Number of the selection position assigned
to this backup on the “Backup Selection”
menu page
1
7
Last used
date*
date/time
Date the backup definition was last used to
create a backup
4
8
Comment/
Path/
Definition
string
Index = 1:
Saveset description (bytes 1-20)
NFS mount (bytes 40-55)
Index = 2:
Output directory
Index > 2:
A backup specification
80
Description
* Indicates that the field is used only when “Index” is zero.
36
Size
Error Message Database
4.4
Error Message Database
The Error Message database defines the message strings associated with the system error codes. In
addition, this database contains a detailed description of each error and a suggested corrective
action. Each record in the database defines a single error message. See Chapter 13 for more
information on error messages and the Error Message database.
All the record fields are listed below, in the order in which they occur within a record. The fields
are summarized in Table 4-5. The data in an Error Message record can be accessed from an
application program by using the V+ variable names shown in column one.
Table 4-5
Record Definition for the Error Message Database
Field #
Global Var
Field Name
(Sort Order)
Data Type
Array
0
cc.name
error
message
string
[17]
A terse phrase that indicates the nature of
the error. This is not a standard AIM item
name since it can contain special
characters and space characters. If the
error message is to be bounded by
asterisks (“∗”), the asterisks must be
included in the error message. The error
message is the string that is returned
when an error code is converted to an
error message string. Database is marked
updated when this field is changed.
64
1
er.code
error code
(1)
integer
A number that is used to represent the
error message. A unique number must be
assigned to each error message. The value
of the error code indicates the type of
error. When new error codes are assigned,
they should be consistent with the
categories shown in the table. (See
Chapter 5 for more information on the
categories of errors.) Database is marked
updated when this field is changed.
2
2
er.explan
explanation
string
[7]
An array of seven strings that is used to
store a detailed explanation of the error.
This is not used by AIM, but is provided
as an aid to the operator.
72
3
er.action
action
string
[7]
An array of seven strings that is used to
store a suggested action to clear the error.
This is not used by AIM, but is provided
as an aid to the operator.
72
Description
Size
37
4.5
Help Database
Help may be defined for any AIM menu page, and for any item on a menu page. To display help
for the current menu page, press Shift+F1 or select:
Help
➡ Page Information1
The help database will be searched for entries matching the help string in the menu page header. If
a match is found, the record is displayed. Otherwise, a “no help available” message is displayed.
See section 8.18 for details on specifying a help string in the menu page header.
To display help for the currently selected or highlighted menu item, press the HELP key (F1) or
perform:
Help
➡ Field Information
The help database will be searched for matching entries in the help database. Several searches may
be made before a “no help available” message is displayed:
1. First the search string in the record for the particular item is checked for matches.
2. If the menu item help string field is empty or a match is not found, AIM looks to see if the
item is enclosed in a static rectangle. The search string in the record for the static rectangle is
checked for matches.
3. If the static rectangle help string field is empty, a match is not found, or the menu item is not
within a static rectangle, the search string in the menu page header is checked for matches. If
a match is found, the “no help available” message is displayed.
See Chapter 8 for details on creating menu items and specifying help search strings for the items.
See section 4.5 for details on creating and using help files.
Associating a Help Database With a Menu Database
The Help database that is searched when help is called for from a menu page or item in a Menu
database is based on a simple name correspondence. Menu databases have the extension .MNU.
The corresponding Help database must have the same name as the menu database, but have the
extension .HLP. For example, help for the menu page file VISGEN.MNU should be in the file
VISGEN.HLP.
1.
The menu selections can be made only from windows that have a menu bar; the menu bar
contains the help pull-down options. The help options are on the standard menu bar.
38
Help Database
The Help database fields are summarized in Table 4-6.
Table 4-6
Record Definition for the Help Database
Field #
Global Var
Field Name
(Sort Order)
Data Type
Array
0
cc.name
keyword
(1)
string
One or more words that serve as the
index into the Help database. When a
menu page is being displayed and help is
requested, the record in the matching
Help database with a keyword that
matches the keyword specified in the
appropriate Menu database record is
retrieved and displayed on the screen.
There can be multiple records in the Help
database with the same keyword. The
page field (see below) is used to order
records with duplicate keyword fields.
Database is marked updated when this
field is changed.
15
1
cc.update
update date
date
edited. Database is marked updated
when this field is changed.
4
2
hp.page
page
(2)
byte
When multiple Help records provide
information for the same keyword, this
number is used to sort the records into the
order in which they are to be presented.
1
3
cc.page.
name
menu page
name
name
[2]
The names of the menu page and menu
file that are used to display this help
record. Both of these values must be
specified. If the standard help scrolling
window is to be used to display the text
contained in the information field, the
menu page and menu file should be
specified as “standard_help” and
HELP.MNU, respectively.
15
4
hp.user.arg
user
argument
integer
This is an optional value that can be used
by custom menu pages that display help
information. For example, the value can
be used to determine which help record is
being accessed. This value is not utilized
by the menu page “standard_help”.
2
Description
Size
39
Table 4-6
Record Definition for the Help Database (Continued)
Field #
Global Var
Field Name
(Sort Order)
Data Type
Array
5
hp.info
information
string
[15]
This array of strings contains the help
information for the specified keyword. If
the standard_help menu page is used to
display the help information, the text in
this field is displayed in a scrolling
window.
50
6
hp.topic
topic
string
An optional value that is used to create
related topics text links in other help
records.
16
40
Description
Size
Initialization Databases
4.6
Initialization databases describe data that is used to initialize various aspects of AIM at startup.
Each record in the database contains a single V+ command line that is executed using a V+ DOS
instruction. The initialization database processing routine performs a simple macro-like
substitution of arguments, so that data items from fields in the record can be used in the V+
statement as it is executed.
The data in these databases supersedes data defined in ai.public.init( ) the file PUBLIC.OVR/OV2.
Notations in this file indicate exactly which data items are redefined in the initialization databases.
They must not be deleted.
Initialization Database Files
When AIM starts up, each major module calls the initialization loader routine ai.load.init( ),
passing the name of the initialization file to be loaded. In AIM 3.0, the initialization files, listed in
Table 4-7, are loaded (if they exist and the corresponding module is loaded).
Table 4-7
Module
Baseline
MotionWare
AIM PCB
VisionWare
File Name
Description
BASEINI.DB
General system-wide data
USERINI.DB
User-defined data, including additional
error databases
MOWINI.DB
Special MotionWare data
MOWRTINI.DB
Enables/disables the different records
types in the vision module
HPSINI.DB
High Precision System data
ROBINI.DB
General robot-dependent data
PCBINI.DB
Special AIM PCB data
PCBRTINI.DB
VWINI.DB
Special VisionWare data
VWRTINI.DB
41
4.7
Customizing Initialization Databases
To customize an initialization database, select:
Special ➡ Edit Init Data ➡ dbl clk on desired init database ➡ Select
(If the file you want to edit is not shown, type it into the file name data box.)
The following menu page will be displayed:
➊
➋
➌
➍
➎
➏
➐
➑
Figure 4-1
AIM Initialization Database
42
Initialization Database Options
This menu page allows you to enter a V+ command line that will be executed during initialization,
and to specify variable values to be used in the command line. A user will be able to select:
Setup ➡ Initialization Data
and edit the variable data, thus completing the command line.
➊
➋
➌
Enter a title for this record. This title will be shown in the scrolling pick lists presented when
a user edits the record used to complete the variable portions of the command line.
You must create a menu page (or use one of the standard pages described below) to be
displayed when a user specifies values for the variable portion of the command line.
(Initialization data is not usually entered at this menu page.) Specify the menu page name
and menu file that should be displayed to edit data from this initialization record. Creating a
separate menu page allows you to control how much information is presented to the user. We
recommend you create your own menu page file for custom pages used with the
initialization process. The menu page file INI.MNU contains the following general purpose
pages you may use:
integer
Displays a simple integer value from argument #A. In addition, arguments
#B and #C are interpreted and displayed as optional minimum and
maximum values. If #B or #C is left blank, then the corresponding limit
check is not performed. You cannot use #B or #C for any other purpose if
specifying this menu page.
real
Identical to integer, except for use with real values.
string
Displays a single string value from argument #$A.
on_off
Displays an integer value from argument #A as a Boolean. Value 0
corresponds to FALSE, value –1 corresponds to TRUE. The value is
displayed as a pair of radio buttons.
Enter a description of the purpose of this initialization record. This field can be placed on the
menu page specified in item ➋ to provide instructions and guidance to the user editing the
initialization data.
➍
If item ➑ is selected, the user will be able to press this button to update the initialization data
at any time. If item ➑ is not selected, a warning will replace this button indicating that
operation can be performed only at AIM startup.
➎
Enter the actual V+ instruction to be executed (using a DOS instruction). Use the titles in the
“Numeric Values” and “String Group” to identify which fields should be used along with the
command line. For example, if the command line contains the string:
ai.ctl[cv.speed]=#A
and the contents of the first numeric field is “100”, then V+ is passed the instruction:
ai.ctl[cv.speed]=100
String data is substituted in a similar manner. If the command line is:
$sample.string="#$A"
and #$A contains “This is a test”, then V + receives the command:
$sample.string="This is a test"
43
NOTE: Quote marks may be required around the string argument in the
command line, depending on the syntax of the statement being executed.
Arbitrary V+ statements may be placed in the command line, but the most common are
assignments and subroutine calls. For subroutine calls, the variables okay and halt may be
used as output variables. If the subroutine sets halt to a nonzero value, then processing of the
initialization database stops immediately, and the halt output variable of ai.load.init( ) is set
to TRUE, causing AIM to halt. If okay is set to FALSE, processing continues, but the okay
output variable of ai.load.init( ) is set to FALSE when the routine exits.
➏
➐
➑
This area shows the 12 numeric fields that are available in the initialization database.
This area shows the 2 string fields that are available in the initialization database.
If selected, the operator will be able to press the “Press to make changes NOW” button and
execute the initialization string. The setting of this field will depend on the structures the
initialization data is used in, and whether they can be updated at any time or just during
system initialization.
Initialization Database Structure
The record format for all initialization databases is shown in Table 4-8. This format is defined in
the file INI.RFD.
Table 4-8
Record Definition for the Initialization Database
Field #
Global Var
Field Name
(Sort Order)
Data Type
Array
0
cc.name
name
(1)
string
A string that must uniquely describe the
initialization record. The name strings are
displayed in a scrolling window to create
an index for the operator to choose the
initialization data record to edit. It should
be as descriptive as possible, keeping in
mind that it will be displayed in
alphabetical order with other name
strings. Database marked updated when
this field is changed.
30
1
cc.update
update date
date
The date this record was last modified.
This field is automatically set to the
current date when the record is edited.
4
2
in.desc
description
string
[4]
(4 items, 60 characters each) An array of
four strings which contain a description
of the data item contained in this record
as well as brief instructions about how to
set this data item. These strings are
displayed to the operator as a block of
text.
60
44
Description
Size
Table 4-8
Record Definition for the Initialization Database (Continued)
Field #
Global Var
Field Name
(Sort Order)
Data Type
Array
3
cc.page.name
menu page
name
(2)
name
(2 items, 15 characters) The first element
contains the name of a menu page and the
second contains a menu file name
containing the menu page. This menu
page is used to display the data in this
record. Different menu pages are used to
display each different type of data.
15
4
in.flags
flags
integer
A number of bit flags used internally.
They should not be modified by the user.
2
5
in.command
command
line
string
A string that contains the V+ statement to
be executed after substituting arguments
of the form #x and #$y for the
corresponding data items from the realvalue and string-value arrays.
60
6
in.rvalue
real value
real
[12]
Each item in this array contains a real
value to be substituted into the
command-line string. The first item
contains the value for argument #A, the
second for #B, etc. If an argument appears
in command line and is blank (undefined)
in the array, an error is generated when
the record is processed.
4
7
in.svalue
string value
string
[2]
Each item in this array contains a string
value to be substituted into the
command-line string. The first item
contains the value for argument #$A, the
second for #$B, etc. If an argument
appears in command line and is blank
(undefined) in the array, no error is
generated when the record is processed.
Instead, a null string is substituted for the
argument.
30
Description
Size
Three additional variables are defined for the initialization database:
in.desc.num
Number of array elements in field 2 (description).
in.rvalue.num
Number of array elements in field 6 (real value)
in.svalue.num
Number of array elements in field 7 (string value).
45
4.8
Menu Database
This database defines the menu pages that are accessed by the menu driver. Each record in this
database defines a single menu item. The item may be a page header, a menu button, a panel, a
number-access item, a conditional format, etc. The fields in a record define where the item is to be
placed on the screen, how it is to be displayed, and how it can be modified. Multiple records are
grouped (by menu page name) to generate a complete menu page.
In most cases, you should not need to be familiar with the internal organization of the Menu
database, since the creation, modification, and management of these databases can be performed
interactively with the AIM menu editor. The information presented here is provided primarily for
completeness (see Chapter 3 for more details).
All the record fields in the Menu database are summarized in Table 4-9, in the order in which they
occur within a record. The data in a record can be accessed from an application program by using
the V+ variable names shown in column one. Since many of the fields are employed for different
purposes by the different types of menu items, the field names and descriptions reflect only their
general use, and may not be accurate for a given type of menu item.
Table 4-9
Record Definition for the Menu Database
Field #
Global Var
Field Name
(Sort Order)
Data Type
Array
0
cc.name
menu page
name
(1)
name
The name of the menu page that displays
the data specified in this record.
15
1
mu.pg.sect
page section
(2)
byte
Number of the conditional section and
sub-section in which the item is placed.
The conditional sections group items
subject to the same criteria whether or not
the items are to be displayed. Subsections
within conditionals arrange item types
according to the order in which they are
to be displayed, which establishes the
items that appear on top of other items.
1
2
mu.type
item type
byte
A value that defines the type of menu
item the record describes. The acceptable
values and their meanings are listed in
Table 4-10.
1
3
mu.rect.x
rectangle x
integer
2
4
mu.rect.y
rectangle y
integer
5
mu.rect.dx
rectangle dx
integer
Position and size of the primary rectangle
for the menu item. For most types of
menu item, this is the location and size of
the box that is dragged around to position
the item during the process of creating the
menu page. These values are in units of
screen pixels.
6
mu.rect.dy
rectangle dy
integer
46
Description
Size
2
2
2
Menu Database
Table 4-9
Record Definition for the Menu Database (Continued)
Field #
Global Var
Field Name
(Sort Order)
Data Type
Array
7
mu.lbl.dx
label dx
integer
8
mu.lbl.dy
label dy
integer
9
mu.lbl.font
label font
10
mu.mde.bits
Description
Size
Position of the item label relative to its
primary rectangle. These values are in
units of screen pixels.
2
integer
Number of the font for drawing the label
and any text. Currently, only fonts 1 - 6
are defined.
2
mode bits
integer
Qualifier bits for the item type, which
indicate special drawing and
interpretation modes.
2
11
mu.label
label
string
Text string used to label the item on the
screen.
72
12
mu.format
format
byte
For variable-format items, this contains a
value that indicates which format is to be
utilized. For example, for numeric items,
this field indicates which V+ output
format to use (for example, /F, /D, etc.).
1
13
mu.vdig
value digits
byte
The number of decimal digits to be
displayed for real numbers.
1
14
mu.icon
icon name
name
Name of the icon to display. (This is used
for the static-icon item, buttons displayed
as icons, and value items that can employ
icons.)
15
15
mu.wacc
write access
level
byte
The operator access level required in
order for write access to a variable to be
allowed. Zero indicates that write access
is always allowed.
1
16
mu.racc
read access
level
byte
The operator access level required in
order for the following to be allowed: a
menu selection, a subroutine spawn, or
read access to a variable. Zero indicates
that access is always allowed.
1
17
mu.gacc
group access
byte
Radio group number for numeric items.
1
18
mu.acc.bit
accessed bit
byte
Number of the bit accessed for a numeric
field that is treated as a bit field.
1
2
47
Table 4-9
Record Definition for the Menu Database (Continued)
Field #
Global Var
Field Name
(Sort Order)
Data Type
Array
19
mu.acc.db
accessed db
byte
20
mu.acc.fld
accessed
field
byte
21
mu.acc.idx
accessed
index
byte
22
mu.low.lim
low limit
real
23
mu.high.lim
high limit
real
24
mu.val
value
integer
Value accessed by the menu item. For a
numeric (or string) item that references a
value in the array ai.ctl[ ] (or $ai.ctl[ ]),
this is the index of the array element to
access.
2
25
mu.next
next name
name
Name of the spawn routine or menu page
associated with the menu item.
15
26
mu.arg
next
argument
integer
Value of the argument parameter that is
passed to the spawn routine to help
identify the menu item that is being
processed.
2
27
mu.file
file
name
Name of the file that contains the spawn
routine or the menu page specified in the
field next name.
12
28
mu.help
help
keyword
string
Value to be matched with the keyword
field in the Help database to determine
the help record that will be displayed
when help is requested for this menu
item.
15
48
Description
Database and field numbers, and array
index value, for an item that references a
database value.
Size
1
1
1
Low and high limits allowed for the new
value of a numeric field.
4
4
Menu Database
Table 4-10 lists the acceptable item types used in field 2 of the menu database.
Table 4-10
Menu Item Types
Item #
Menu Item Type
Item #
Menu Item Type
1
Page Header
9
Transformation display
2
Static text
10
Not used
3
Menu selection
11
Not used
4
Subroutine spawn
12
Static panel
5
Scrolling window
13
Conditional item
6
Digital-signal display
14
Static icon
7
Numeric display
15
Static rectangle
8
String display
16
Sequence spawn
49
4.9
Module Database
The module database keeps track of all the individual components that comprise an AIM Module.
In general, AIM takes care of managing the module database and you should not need to be
concerned with its internal structure.
All the record fields in the Module database are listed below, in the order in which they occur
within a record. The fields are summarized in Table 4-11. The data in a record can be accessed from
an application program by using the V+ variable names shown in column one. Since many of the
fields are employed for different purposes by the different types of menu items, the field names
and descriptions reflect only their general use, and may not be accurate for a given type of menu
item.
Table 4-11
Record Definition for the Module Database
Field #
Global Var
Field Name
(Sort Order)
Data Type
Array
0
cc.name
name
(1)
name
The name of this module. Database is
marked updated if this field is changed.
8
1
cc.update
update
date
date/time
modified. This field is automatically set
to the current date when the record is
edited. Database is marked updated if
this field is changed.
4
2
md.c.date
creation
date
date/time
Not currently used
4
3
md.rec.type
record
type
(2)
integer
A code which indicates the type of this
record. Also the secondary sort field. The
codes are one of the following:
md.rec.hdr = 0
Record is the module header
md.rec.desc = 1
Record is the module description
md.rec.comp = 2
Record describes a module database
component other than a sequence.
md.rec.seq = 3
Record describes a module sequence
component
2
4
md.string
string
(3)
string
A string value whose meaning depends
on the “record type” field.
“record type”
md.string value
md.rec.hdr Module directory path
md.rec.desc Module description string
md.rec.comp Component database
name
md.rec.seq
Sequence database name
72
50
Description
Size
Module Database
Table 4-11
Record Definition for the Module Database (Continued)
Field #
Global Var
Field Name
(Sort Order)
Data Type
Array
5
md.flags
flags
integer
Bit flags whose meaning depends on the
“record type” field.
“record type”
Flag bits
md.rec.hdr
md.flg.md.load = 1
If set, load on startup
md.flg.modify = 2
If set, module was
modified
md.rec.comp md.flg.vis.2 = 1
If set, use vision #2,
else use vision #1.
Only used if
md.comp.type
contains vi.ty.
md.rec.seq
md.flg.ctl.seq = 2
If set, is a control
sequence
2
6
md.rwmode
read-write
mode
integer
An integer value whose depends on the
md.rec.hdr
The default device associated with
this module.
md.rec.comp
The read-write mode for this module
component database, as follows:
0 - full read-write mode file access
mode
1 - modify memory-only mode: no
changes written to disk
2 - full read-only mode: no changes
allowed
2
7
md.comp.type
component
type
integer
The meaning depends on the value of the
md.rec.hdr
Contains zero if the module is not
loaded. Contains the module ID if
the module is loaded.
md.rec.comp
Contains the type code for the
component database.
md.rec.seq
Contains the sequence number from
which the sequence file name is
derived.
2
Description
Size
51
4.10 Sequence Database
Each record in a Sequence database contains an AIM statement. The series of statements contained
in these records forms an AIM sequence. A typical AIM installation will contain multiple
Sequence databases, each one containing a separate sequence. The Sequence database file names
are determined by the resource module to which they belong,
Typically, there is no need for a user or system customizer to directly examine the records of a
Sequence database. The AIM sequence editor provides a much more convenient method of
viewing and altering this data. (See the application module users guides for a description of the
AIM sequence editor.) You can also use the ASCII option when exporting databases to create a
copy that can be opened and printed by a word processor.
All the fields in a Sequence record are summarized in Table 4-12, in the order in which they occur
within a record. The data in each record is accessed by the AIM sequence editor and other internal
routines using the V+ variable names shown in column one.
NOTE: In almost all applications, the system customizer would never
need to access the data in this database directly. However, the “Special/
Edit Raw Sequence” pull-down selection can be used to examine or
modify a Sequence record while debugging a new statement.
Table 4-12
Record Definition for the Sequence Database
Field #
Global Var
Field Name
(Sort Order)
Data Type
Array
0
sq.flags
flags
binary
Contains bit-flag values that indicate the
statement status.
sq.disable (^H1)
Set if the statement is disabled
sq.comment (^H2)
Set for comment statements
sq.label (^H4)
Set for label statement
For example, if the bit defined by the bit
mask sq.disable is set, the statement is
disabled and should be ignored by the
runtime scheduler task. This bit flag
corresponds to setting the disable “∗” on
a statement with the sequence editor. No
bit flags other than those shown are
currently used, but they are reserved for
future use.
2
1
cc.update
update date
date
edited.
4
52
Description
Size
Sequence Database
Table 4-12
Record Definition for the Sequence Database (Continued)
Field #
Global Var
Field Name
(Sort Order)
Data Type
Array
2
sq.linecnt
line count
byte
This field is reserved for use by the
sequence editor. The editor stores in this
field the number of lines required to
display the statement. This field is not
used by the runtime.
1
3
sq.cnt
argument
count
integer
The number of arguments in this
sequence record, that is, the number of
arguments defined for this sequence
statement.
2
4
sq.strs
argument
string
string
[17]
The elements of this field contain the
argument strings for the sequence
statement. Tokens strings are not
included. The first string in this field is
always the name of the statement.
Subsequent strings define the statement
arguments. (Note: The arguments defined
in this field must correctly match the
statement syntax, as defined in the
Statement database.)
15
5
sq.args
[argument
ptr]
integer
[17]
For each of the elements of the “argument
string” field, there is an element in this
array field. The value of each “[argument
ptr]” element is the record number in the
appropriate database for the
corresponding argument in the
“argument string” field. The values of
these pointers are computed by the AIM
linking routines just prior to execution of
the sequence. This linking permits the
runtime routines to quickly access the
database records for each argument of a
statement.
2
Description
Size
53
4.11 Statement Database
Each record in this database defines a single AIM statement template (that is, the syntax of the
statement). This definition is used by the sequence editor to parse statements that are entered by
the operator. The fields in a record define the statement name, the number and types of
arguments, token strings, and any optional clauses in the statement. See section 6.3 for details on
creating or editing a statement definition.
All the record fields in the Statement database are summarized in Table 4-13, in the order in which
they occur within a record. The data in a record can be accessed from an application program by
using the V+ variable names shown in column one. The global variable for referencing the
statement database is st.db. The global variable st.max.args specifies the maximum number of
arguments that will be used.
Table 4-13
Record Definition for the Statement Database
Field #
Global Var
Field Name
(Sort Order)
Data Type
Array
0
cc.name
name
(2)
name
This field contains the name of the
statement. This is the actual string that
will be seen with the sequence editor
when the statement is used in a sequence.
This name also identifies the V+ statement
routine that defines the operations
associated with this statement. Database
marked updated if field is changed.
15
1
cc.update
update date
date
edited.
4
2
st.c.date
creation date
date
The date and time when the record was
created.
4
3
st.cnt
argument
count
integer
The number of arguments contained in
the statement syntax. Database marked
updated if field is changed.
2
54
Description
Size
Statement Database
Table 4-13
Record Definition for the Statement Database (Continued)
Field #
Global Var
Field Name
(Sort Order)
Data Type
Array
4
st.typs
argument
type
integer
[17]
This field defines the type of argument for
each of the arguments of the statement.
The elements of this field are arranged in
the order in which the arguments appear
in the argument list for the statement.
The argument type is a number that
usually specifies the database number for
the database associated with the
argument. Positive numbers specify a
database number. For example, if an
argument is a “path”, this field would
contain the internal AIM database
number for the Path database. (See the
reference guide for your application
module for a list of the database numbers
available for your particular application.)
Negative numbers indicate special
arguments (usually from a keyword list).
See Table 4-14 for the defined types.
Database is marked updated if field is
changed.
2
5
st.strs
token string
string
[17]
This field contains the strings associated
with the token arguments of the
statement. There is a one-to-one
correspondence between the elements of
this field and the elements of the
“argument type” field. Each statement
argument has a token string associated
with it (even if the string is blank). Token
strings are used to make the statement
more readable when it is displayed by the
sequence editor.
The text contained in this string is the
actual text that will appear for the token
when the statement is displayed by the
sequence editor. Adept conventions use
all capital letters for these strings.
15
Description
Size
55
Table 4-13
Record Definition for the Statement Database (Continued)
Field #
Global Var
Field Name
(Sort Order)
Data Type
Array
6
st.clause.start
clause start
byte
[17]
7
st.clause.end
clause end
byte
[17]
8
statement
type
(1)
string
This field is the primary sort field for the
statement databases. When all statement
databases are loaded, they are sorted
according to this field and a solid bar is
placed between statement groups having
different values in this field.
3
9
flags
integer
A bit flag field which defines how
statement can or cannot be used.
Variable Mask
st.fl.no.run ^H1
If set cannot be used runtime task.
st.fl.no.opr
^H2
If set cannot be used by an operator
interface.
st.fl.move
^H4
If set the statement may cause robot
motion.
st.fl.vis
^H8
If set the statement may use vision.
st.fl.io
^H10
If set the statement may set or clear
I/O.
2
56
Description
Each statement argument can begin and/
or end one or more optional clauses. The
“clause start” field indicates how many
optional clauses start with the current
token-string and argument pair. The
“clause end” field indicates how many
optional clauses end with the current pair.
Proper setting of these values allows for
different types of nested clauses. If braces
(”{...}”) are used to denote the nesting of
clauses in a syntax definition, then the
value in “clause start” is the number of
open braces (”{”) that precede the tokenstring and argument pair, and the value in
“clause end” is the number of close braces
(”}”) that follow the pair. See Chapter 6
for details.
Size
1
1
Statement Database
The following table lists the negative type codes for the Statement database “argument type” field.
Table 4-14
Statement Argument Types
Place Holder
Type Code
--component--
–19
--constant--
–1
--device--
–11
--event--
–32
--input--
–2
--mode--
–21
--opr--
–18
--output--
–3
--o_variable--
–6
--response--
–33
--segment--
–20
--sequence--
–9
--string--
–4
--task--
–10
--uopr--
–17
--variable--
–5
--yes/no--
–15
57
4.12 Variable Database
The variable database stores the constant or variable numeric values. The value displayed on the
Variable database menu page is the actual value. The value stored in the database and passed to a
statement routine is an encoded value that contains not only the value but information on its data
type. The routines rn.get.va.num( ) and rn.put.va.num( ) manipulate this coded value. See
“Special Routines for Accessing the Variable Database” on page 74 for details on accessing the
variable database.
This database is a complicated database with significant built-in support for access by statements
and sequences. This support can easily be damaged if improper modifications are made to this
database.
Table 4-15
Record Definition for the Variable Database
Field #
Global Var
Field Name
(Sort Order)
Data Type
Array
0
cc.name
name
3
string
The name of this record. Database is
marked updated if this field is changed.
15
1
cc.update
update date
date/time
the current date when the record is edited.
4
2
va.group
group
1
name
The primary sort field which may be used
to group variables into user-defined
categories. Otherwise ignored by AIM.
15
3
cc.page.name
menu page
name
name
[2]
The name of the menu page (in the file
VAR.MNU) used to display this record. If
this name is blank, the page named “main”
is used by default.
15
4
va.desc
description
string
[4]
Array field for describing the record.
72
5
va.seqname
sequence
name
string
If the variable database is a module
component, and the variable is local to a
sequence, this field contains the name of
that sequence. Otherwise not used.
30
6
va.string
string
string
If the variable references a V+ global
variable, this field contains the name of that
variable.
15
7
va.scope
data scope
byte
[2]
A code which defines the scope of the
variable. If 0, the variable is local to the
sequence specified by field “string”. If 1, the
variable is local to the current module.
1
58
Description
Size
Variable Database
Table 4-15
Record Definition for the Variable Database (Continued)
Field #
Global Var
Field Name
(Sort Order)
Data Type
Array
8
va.type
data type
byte
A code which indicates the type of the
variable defined by this record.
Variable Value Description
va.typ.cint
0 Named integer
constant
va.typ.cdio 1 Named digital output
constant
va.typ.cdout 2 Named digital output
constant
va.typ.creal 3 Named real constant
va.typ.avar 4 AIM variable
va.typ.vvar 5 V+ variable
va.typ.aictl 6 ai.ctl[ ] variable
va.typ.nreal 7 Numeric real constant
1
9
va.value
value
real
A real value whose meaning depends on
the “data type” field:
“data type” Description
va.typ.cint
The constant value
va.typ.cdio The signal number
va.typ.cdout The signal number
va.typ.creal The constant value
va.typ.avar The variable value
va.typ.vvar Not used
va.typ.aictl The ai.ctl[ ] index
4
Description
Size
59
Chapter 5
Runtime System
The AIM runtime system (the “runtime”) is a set of software routines that are responsible for
translating database and process information into actions that perform sequences. Depending on
the application, these actions may operate cell hardware, move a robot, or operate a vision system.
The runtime system executes in one or more V+ program tasks, which cooperate with each other to
run an application.
The top-level routine of each task that executes a sequence is the sequence scheduler and executer
(“the scheduler”). The scheduler is responsible for determining which statement routines are
called and in what order. The scheduler extracts individual statements from the Sequence
database and calls the appropriate routines to execute the statement.
The statement routines make up the next layer of software in the scheduler. These are the V+
routines that are called by a scheduler to execute individual AIM sequence statements. There is
one statement routine for each defined AIM statement. Each statement routine performs a a
dedicated function and is passed a predetermined set of parameters. In theory, a statement routine
could be implemented entirely with unique software that is referenced only by that one statement.
In fact, most statement routines rely heavily upon a library of “statement primitives”, which
implement many common high-level actions.
The statement primitives form the next layer of software. This library of routines is called by the
statement routines to perform common actions, such as using the robot to acquire a part from a
feeder, or locating an object using vision. Each statement primitive may combine several
operations, and possibly even sensory feedback to perform a fairly high-level action.
The lowest-level runtime routines are the low-level primitives. The low-level primitives are called
by the statement primitives (or directly by the statement routines) to perform individual robot
motions, error handling, database accesses, etc.
In addition to tasks that execute a scheduler, there are tasks that are server tasks. The top-level
routine of each task that executes a server is determined by the call to ai.task.define( ). Server
tasks do not execute a sequence but are initialized to a wait state until another executing task
requests information from the server task. The vision task and conveyor tasks in MotionWare are
examples of server tasks. These tasks are idle until another task requests that they perform some
work on behalf of the requesting task.
All the runtime software layers are described in detail in this chapter (except for the statement
routines, which are discussed in Chapter 6). Detailed information concerning the standard AIM
routines is presented, together with descriptions of how new custom routines can be added to the
runtime software module.
61
Chapter 5 - Runtime System
5.1
General Concepts and Database Structures
This section presents some general concepts that are used throughout the runtime software, and
describes the data structures that are employed in the implementation of these concepts.
Runtime Tasks
The runtime tasks execute either a sequence or a server task.
Definition
Runtime tasks are defined during system initialization by calling the routine ai.task.define( ). This
routine notifies AIM that a particular V+ task is a runtime task, sets up the data structures required
for communications with the operator interface, specifies which robot device (if any) is associated
with this task, and whether the task will run a sequence or be a server task.
Database Numbers
Runtime databases have an array of numbers that keep track of which database is active for each
task that supports a scheduler. The number of runtime databases present in a particular AIM
system depend on which options are loaded. See “Database Numbers” on page 23 for details.
Control Variables
One method of communication between the operator interface and the runtime tasks is via a
global array of real values. Actually, there are two arrays that track each other: ai.ctl[ ] and
rn.ctl[ , ]. The control variables are used to control sequence execution and pausing, and also pass
other values depending on the application.
The ai.ctl[ ] and $ai.ctl[ ] Arrays
The array ai.ctl[ ] is used by the operator interface to display data on various menu pages. The
operator interface may freely read the values in ai.ctl[ ], but must use the communications routine
ai.set.ctl( ) to write the values. The runtime task must never directly access the values in ai.ctl[ ].
However, it may be written to by calling the routine rn.status.num( ). The indexes for this array
are defined in the public routine ai.cv.define( ) in the file PUBLIC.OVR. System customizers may
add index values to this array using the routine cu.cv.define( ) in the file CUSTOM.SQU. The file
PUBLIC.OVR should not be changed except in unusual circumstances.
The $ai.ctl[ ] array is similar to ai.ctl[ ], however, the operator interface may freely read and write
to $ai.ctl[ ]. Runtime tasks should use the routine rn.status.str( ) to write to $ai.ctl[ ]. The indexes
for this array are defined in the public routine ai.cs.define( ) in file PUBLIC.OVR. System
customizers may add assign index values to this array using the routine cu.cs.define( ) in the file
CUSTOM.SQU. The file PUBLIC.OVR should not be changed except in unusual circumstances.
The rn.ctl[,] and $rn.ctl[,] Arrays
The array rn.ctl[,] is associated with the runtime tasks and is modified by runtime routines. The
left-hand index of this array represents the V+ task numbers. The runtime interface may freely
read and write the values in rn.ctl[,].The operator interface should never directly access the values
in rn.ctl[,]. Instead, it should use the routines ai.cpy.rn.ctl( ), ai.get.rn.ctl( ), and ai.set.rn.ctl( ). The
right-hand indexes for rn.ctl[,] are shown in the table below. Many of these indexes have a
62
corresponding ai.ctl[ ] index, as shown. The index variables are defined in the file PUBLIC.OV2, so
that additional indexes can be defined by a system customizer.
Table 5-1
Indexes for rn.ctl[,] and ai.ctl[ ]
rn.ctl[,] RH Index
Value
ai.ctl[ ] Index
Description
rn.ctl.c.step
1
cv.c.step
Currently executing step
rn.ctl.f.step
2
cv.f.step
Final step to execute
rn.ctl.complete
3
cv.completed
Number of loops completed
rn.ctl.loop.cnt
4
cv.loop.cnt
Number of loops required
rn.ctl.seqnum
5
Current sequence number
rn.ctl.stk.num
5
Maximum stacked index
rn.ctl.walk
6
cv.walk.thru
Enable walk-thru training
rn.ctl.edit.all
7
cv.edit.all
Edit all data during walk-thru training
rn.ctl.pause
8
cv.pause
Pause bit mask
rn.ctl.speed
9
cv.speed
Speed
rn.ctl.mfilter
10
rn.ctl.ins.suc
11
rn.message filter flags
cv.ins.success
Current insertion success
If the operator interface calls ai.set.ctl( ) for one of the ai.ctl[ ] index values shown in the third
column, the corresponding rn.ctl[,] value is changed for the task corresponding to the task index
specified by the global variable ex.ti, which contains the task index for the last task displayed by
the task or master control panels.
The $rn.ctl[,] array is similar to rn.ctl[,] except that it contains string values. The left-hand index of
this array is the V+ task number of the current task. A runtime task may freely read and write the
information for its column of the array. Only the right-hand index is shown in the following table:
Table 5-2
Indexes for $rn.ctl[,] and $ai.ctl[ ]
$rn.ctl[,] RH Index
Value
$ai.ctl[ ] Index
Description
rn.ctl.mod
0
cs.module
Name of the module for this runtime task
Operator Error Response Codes
Each primitive routine in the runtime system returns an error response code indicating whether or
not the operation succeeded. If the operation did not succeed, the error response code indicates
what action the calling routine should take. The codes returned by the operator control panel are
the same as the operator responses to error conditions.
In most situations, only certain error responses by the operator are allowed. AIM permits the
allowed responses to be specified to the routine rn.error( ) as a bit mask composed of global
variables that each contain a single bit. The bit mask is composed by using the V+bit operators. If a
certain response bit is set, then the operator may select the corresponding response.
63
Table 5-3 lists the symbols defining the operator error response codes, and the symbols defining
the corresponding bit mask. The interpretations of the codes are described in more detail in the
section “Error Handling” on page 70.
Table 5-3
Operator Error Response Codes
Variable Name
Bit Mask
Interpretation
rn.opr.abort
er.abo
Unlock Sequence (stop scheduler)
rn.opr.fail
N/A
Operation failed (used internally)
rn.opr.next
er.nxt
Skip Statement
rn.opr.reject
er.rej
Skip Sequence (breaks all nested CALLs)
rn.opr.restart
er.res
Retry Statement
rn.opr.retry
er.ret
Retry Action
rn.opr.return
N/A
Force a RETURN on the current sequence
rn.opr.skip
er.skp
Skip Action (ignore any error)
rn.opr.success
er.pro
Proceed (operation successful)
N/A
er.no.abo
If this bit is set and any other bit is set, abort is
not allowed
N/A
er.all
All responses are allowed
Note that the success code rn.opr.success has the value FALSE, and all the other response codes
are interpreted as having the logical value true. Therefore, the code can be checked efficiently
using the V+ IF instruction.
The response rn.opr.abort is always allowed unless er.no.abo is set. Therefore, the value zero is
the same as er.abo. For convenience, the symbol er.all may be used if all responses are allowed.
The V+ COM operator may be used to eliminate responses. For example,
COM er.pro
indicates all responses except “Proceed”.
Communications Between The Operator and the Runtime
Within AIM, communication with the operator is normally channeled through the operator
interface, which runs as V+ program task #3. Messages are passed to one of the operator controlpanel windows, which are accessed from the Execute pull-down on the AIM status line at the top
of the screen. In addition to the main operator interface, a second operator interface dedicated to
custom operator interface requirements is defined for V+ program task #6.
The standard communications interface between the runtime and the operator is implemented
using the control variable arrays rn.ctl[,] and ai.ctl[ ], or the message-passing routines
rn.message( ) and rn.error( ). This communications interface is handled entirely by standard
system routines, which need not be altered by system customizers. Within the runtime, this
interface can be used by almost any new routines that are written.
64
A runtime task may create its own V+ windows and perform I/O directly to those windows.
However, such communications may not work for future AIM systems, which may support
remote operator interfaces.
The standard communications interface is described in this section, from the perspective of the
runtime.
Error Display and Operator Responses
The runtime execution routines communicate with the operator-interface task by using the system
routines rn.message( ) and rn.error( ) to send messages to the operator. Each message has a
unique error code that is passed to these routines. The code specifies the type of message and the
message text. See Chapter 13 for details on error codes.
The routine rn.message( ) handles informative and trace messages as follows:
• In normal execution mode, trace messages are suppressed.
• In walk-thru training mode, all messages are sent to the operator control panel.
The routine rn.error( ) handles error messages, edit requests, and pause messages. All such
messages are displayed at the operator terminal, and the runtime enters “operator wait” mode. If
multiple error messages are received, they are queued and handled in the order in which they
arrive. The error value returned by rn.error( ) indicates the operator response. The operator error
response code variables are shown in Table 5-3.
See Chapter 16 on low-level primitives for more details on the routines rn.error( ) and
rn.message( ).
You can also control the text associated with the push buttons on the Task Control Panel. The text
is taken from an error database and can be dynamically controlled to present the operator with
information that is specific to the current workcell state. The routines rn.resp.save( ),
rn.resp.rest( ), and rn.error.resp( ) control the text displayed with these push buttons.
Runtime Status Display
The status of the runtime is indicated by a mode display on the operator control-panel window.
The modes and their interpretations are described below:
Idle
All runtime tasks are idle and ready for a start or select command from
the operator control panel.
Running
All runtime tasks are actively executing a sequence.
Operator Attention
The runtime is waiting for an operator response to be entered at the
task control panel.
Waiting
The operator control task is waiting for the runtime task to perform an
action. For example, the operator has invoked a teach routine from the
operator control panel. The runtime is executing the teach routine.
The program cu.set.mode( ) (CUSTOM.V2) is called anytime the status changes for any runtime
task. Use it for any custom code related to this function.
Pausing and Single-Stepping
Sequence execution ends automatically whenever the last statement is executed and the ✔ Repeat
option is not selected. Execution also ends when a RETURN statement is processed. To stop
execution at any other time, the operator must use one of the AIM pause modes (see below) or
65
execute a control sequence that pauses the appropriate task. Pause modes suspend execution and
wait for the operator to enter a standard response. If the Proceed operator response is selected,
execution continues just as if the pause did not happen.
From the Master Control Panel, the Pause check boxes select the desired “Pause after” option. The
Proceed push-button clears the pause condition.
From the Task Control Panel, pause mode is entered by turning on one of the “Pause After” menu
selections. Pause modes do not automatically clear themselves, but must be explicitly reset by the
operator. Single-stepping is performed by leaving one or more pause modes set, and selecting
Proceed each time the pause occurs. Otherwise, the operator must reset the pause mode(s) before
proceeding.
The operation of pause buttons on a particular control-panel window may be modified by a
system customizer to suit the particular needs of an application. Pausing may be specified to occur
in the following situations:
• Pause at the end of the current cycle.
Execution stops when the main sequence is completed, but before starting on another
iteration. This mode is used for orderly shutdown in normal production. This mode is
handled by the scheduler. See the description of the sequence scheduler (in this chapter) for
implementation details.
• Pause at the end of the current statement.
Execution stops when the current statement is completed, possibly in the middle of a
sequence. This mode is used for setup, debugging, and error recovery. This mode is handled
by the scheduler. See the description of the sequence scheduler (in this chapter) for details of
implementation.
• Pause at the end of the current action.
Execution stops when the current action is completed, possibly in the middle of a statement.
This mode is used for setup, debugging, and error recovery. This mode is handled by the
primitive routines. See the section (in this chapter) on primitives for implementation details.
(The definition of an action depends upon the primitives being called.)
• Pause at the end of the current operation.
Execution stops when the current operation is completed. For systems with a robot option,
for example, an “operation” corresponds to a single robot motion. This mode is used for
setup, debugging, and error recovery. This mode is handled transparently by the low-level
motion primitive routines and need not concern the system customizer.
The control array elements, ai.ctl[cv.pause] and rn.ctl[TASK( ),rn.ctl.pause], control the runtime
pause mode. Pause for each runtime task is independent of all other tasks. If these control
variables are nonzero, a runtime pause request is pending. Pause requests are processed by calling
the routine rn.check.pause( ). This routine is called whenever a certain pause condition is to be
checked by a runtime routine. See the description of this routine in Chapter 16 for more details.
Control Sequences
The base AIM system includes a series of statements that can be run in special sequences known as
“control sequences”. These sequences allow operations such a starting, pausing, proceeding, and
stopping a sequence to be performed by a sequence running in one of the front-end tasks. See the
individual statement routine descriptions in Chapter 16 for details on the control statements.
66
Walk-Thru Training Interface
In walk-thru training mode, AIM traces each action as it is performed while executing the
statements of a sequence. Also during walk-thru training, selected values are edited interactively.
This training is handled automatically by the AIM primitive routines. See the section on primitives
for details.
To use this automatic training, the system customizer must properly set up the field attributes of
any database records that are added or modified. Those attributes specify whether or not a field is
optional or editable, and also whether or not it is part of a motion parameter group. See the AIM
MotionWare Reference Guide for details.
Walk-thru training mode, with editing only of undefined values, is entered from the Task Control
Panel by selecting ✔ Walk Thru and deselecting ✔ Edit All.
The system pauses under the following conditions when in this mode:
• A pause occurs due to one of the pause conditions being set, as described in the previous
section.
• An AIM runtime error occurs. If the error involved a database, the Edit button is active, and
pressing it will invoke the database editor.
• An undefined, required data field is encountered. Edit is active, and pressing it will invoke
the database editor. The operator can proceed with the current action after defining the value.
Walk-thru training mode, with editing of all values, is entered from the Task Control Panel by
selecting ✔ Walk Thru and ✔ Edit All.
When in this mode of execution, AIM pauses under all the same conditions as in normal walk-thru
mode, and also pauses under the following conditions:
• An optional data field is encountered with no data defined. The operator has the option of
defining the data value.
• A data field with the edit-data attribute is encountered (even if valid data is already defined).
The operator has the option of modifying or deleting the data value, or proceeding without
changes.
When not in walk-thru training, AIM will generate an error if any required data is not defined. In
general, the operator will not be able to proceed from such an error and will have to abort
execution of the sequence.
The system customizer may want to test for walk-thru training mode within a user-written
routine. Use the global array rn.sw.walk[ ] for this purpose.
rn.sw.walk[ ]
Real array that indicates whether or not a given task is executing in walkthru training mode (the task number is the array index). Its value is TRUE
when the system is in walk-thru mode. Otherwise, it is FALSE.
Walk-Thru and Edit All training modes are independent for each task.
67
5.2
Sequence Scheduler
The top-level routine of each task that executes a sequence is rn.sched( ). Scheduler tasks must
have names corresponding to the names found in the calls to ai.task.define( ) and ai.task.start( ) in
the application initialization routine ai.module.init( ).
The scheduler determines which sequence to run and whether it should be run in repeat mode.
The scheduler calls the routine rn.seq.exec( ) to execute the sequence. The operator error-response
code values returned from the statement routines are used to modify the normal order of sequence
execution when appropriate. Operator requests to pause at the end of the sequence, or at the end
of each statement, are recognized and processed.
Starting and stopping of the scheduler is performed by the operator interface or by one of the
sequence control statements. With the default control panels, the operator interface also selects the
sequence to be executed and sets the control parameters. However, a system customizer may
change the scheduler to perform its own sequence selection and to reset the control parameters.
An entirely different scheduling algorithm may be implemented to perform error recovery or
handle multiple workstations.
Each scheduler task that executes a sequence must have a main program that consists of a simple
outer loop as described below:
1. Call the routine rn.wait.idle( ) to wait for the operator interface task to begin execution.
2. Execute whatever runtime code is appropriate to process a sequence.
3. If global variable ai.stop.prog is FALSE, loop to item 1.
4. If global variable ai.stop.prog is TRUE, exit from this routine.
The operator interface task starts runtime execution by calling the routine ex.control( ). That
routine sends a message to the routine rn.wait.idle( ).
Runtime Module and Sequence Assignment
Each scheduler task is responsible for assigning modules and sequences to itself. The operator
control panel writes the name of the desired module into $rn.ctl[TASK( ), rn.ctl.mod] and the
desired sequence into rn.ctl[TASK( ), rn.ctl.seqnum]. The standard scheduler routine, rn.sched( ),
reads these values and assigns the modules and sequences based on them.
In general, a scheduler task can assign a module by performing the following steps, given that it
knows the name of the module and sequence:
1. Call ld.asn.mod( ) to assign the module to the current task and load it if not already loaded.
2. Call ld.lookup( ) to find the sequence number associated with the named sequence. This step
may be skipped if the sequence number is already known.
3. Call lk.link.mod( ) to link the module. This step may be skipped it the module is already
known to be linked, as is the case for sequences started from a standard control panel.
4. Call rn.seq.exec( ) to execute the sequence.
5. Call ld.dea.mod( ) to de-assign the module from the current task.
6. Call ld.unload.mod( ) to unload the module, if it is no longer needed. Skip this step if the
module will be used again soon and should remain in memory.
68
Sequence Scheduler
Once a module and sequence have been assigned, the various databases may be accessed as
xx.db[TASK( )], where “xx” is the database type prefix. The assigned sequence database is
accessed as sq.db[TASK( )].
Global Variables
The sequences currently selected are determined by the global array sq.db[TASK( )], which
contains the database number of the current sequence. This variable is normally set up by calling
the routine ex.control( ) from within a menu spawn routine referenced by the operator control
panel. However, the scheduler itself can call ld.asn.mod( ) to select a different sequence while the
runtime is active. This feature may be used to select a sequence based upon some sensor, such as a
bar code reader. The special AIM sequence control statements can also select sequences for
execution.
The databases associated with the current sequence is determined by the global arrays
xx.db[TASK( )], which contains the database number of the associated databases. If there is no
associated database, this variable has the value zero. The runtime system makes use of these
variables when accessing the runtime databases. The prefix for this array of variables is setup by
calling the routine ai.db.define( ).
The following array variable is used to keep track of when the scheduler started sequence
execution.
rn.start.time[ ]
Double array that contains the times when the schedulers were last started.
The respective task numbers are used for index of the array. The time is
recorded as a value returned by the V + real-valued function TIMER(-3).
Start and Stop
The scheduler calls the routine rn.wait.idle( ) to wait for the operator interface task to begin
runtime execution. If walk-thru training mode is enabled, the scheduler pauses immediately and
waits for the operator to proceed or abort execution.
After executing a sequence, the routine rn.check.pause( ) is called to check if ✔ Pause After Cycle
has been selected by the operator.
The scheduler remains in control until one of the following conditions occurs:
• An abort execution operator response is received from a call to the operator error-reporting
routine, rn.error( ).
• An abort execution error response is returned from a call to an AIM primitive routine.
• An abort execution error response is returned from a call to the routine rn.check.pause( ).
• The sequence has completed and ✔ Repeat is not selected.
• The Execute
➡ *Stop all tasks* menu option is selected.
• A STOP_TASK control statement is processed for the executing task.
When the scheduler starts and stops, it sends informative messages to the operator during walkthru training.
Pausing
The scheduler handles the Pause After Statement and Pause After Cycle operator functions. After
each statement routine is called, if there is no operator error response indicated, the scheduler calls
the routine rn.check.pause( ) with the argument ai.pause.statem. If the pause condition is true, the
69
operator is notified and the operator response is treated as if it were the error response returned
from the statement routine.
After each sequence cycle is completed, the scheduler calls the routine rn.check.pause( ) with the
argument ai.pause.sequen. The operator is notified if the pause condition is true.
Error Handling
Operator error-response values from statement primitive routines and other control routines must
all be handled by the scheduler. This error handling is not difficult, but it can be somewhat tedious
since every possible error must be handled in every situation. Some general guidelines are listed
below.
The following global variables are given constant values to indicate the conditions described:
rn.opr.success
Proceed (Operation Successful). This is the normal non-error case.
Execution can proceed normally.
rn.opr.retry
Retry Action. This response should normally not be returned from
statement primitives or control routines that are expected to process their
own retries.
rn.opr.skip
Skip Action. This response should normally not be returned from statement
primitives or control routines that are expected to handle skip-action
requests. This value is treated by the scheduler as a Proceed response.
rn.opr.restart
Restart Statement. The current or previous statement is executed again if
this value is returned by a statement primitive routine or a pause at the end
of a statement.
rn.opr.next
Skip Statement. This is treated the same as a Proceed.
rn.opr.reject
Skip Sequence (and reject assembly). This causes the current assembly to be
rejected by calling the assembly reject routine. The scheduler then starts at
the beginning of the sequence with a new assembly.
rn.opr.abort
Unlock Sequence and Stop Scheduler. This causes the scheduler routine to
branch to the bottom of its loop, check the value of ai.stop.prog, and loop
back to rn.wait.idle( ) if ai.stop.prog is false.
rn.opr.fail
The current operation failed without explicit operator intervention. The
statement can be restarted or skipped as desired.
Sequence Execution Control
Operation of the scheduler is determined by a number of control variables that are set up by the
task control panel. The scheduler accesses the control variables as described below:
rn.ctl[TASK( ),rn.ctl.c.step]
rn.ctl[TASK( ),rn.ctl.f.step]
70
Real array element that contains the number of the current
statement being executed by the scheduler. This is set by
the operator interface to the number of the first statement
to be executed.
Real array element that contains the number of the final
statement to be executed. A sequence is considered
complete whenever the current statement number is equal
to this value.
Low-level Primitives
rn.ctl[TASK( ),rn.ctl.complete]
Real array element that contains the total number of
sequences that have been executed.
rn.ctl[TASK( ),rn.ctl.loop.cnt]
Real array element that contains the total number of
sequence cycles to be executed. The scheduler exits when
the number of cycles completed is equal to the total
number scheduled. If this value is set to zero, an infinite
number of cycles are executed.
REACTE Routine
You can write your own routines to handle unexpected errors. The program cu.reacte( ) in the
CUSTOM.V2 file is used for custom error handling routines. Before writing a custom error handling
program, you should be familiar with the REACTE instruction (see the V+ Language Reference
Guide).
5.3
This section describes the low-level primitives that perform single operations, such as reading
data from a database or sending a message to the operator.
As with the higher-level AIM primitives, it should be kept in mind that the low-level primitives
are not fundamentally required for the implementation of new statements. The low-level
primitives are simply general-purpose V+ routines that perform fundamental functions that are
used often. Unlike the high-level primitives, however, the low-level primitives are treated as black
boxes, which cannot be altered by system customizers.
NOTE: Unless otherwise noted as a Usage Consideration on the
dictionary page (in Chapter 16) for a routine, all the rn. routines should be
executed only from a runtime task.
Operator Interface Low-level Primitives
All the runtime routines communicate with the operator-interface task by using the primitive
routines rn.message( ) and rn.error( ). These routines conditionally send messages to the operator.
In addition, rn.error( ) waits for an operator response. See the runtime dictionary in Chapter 16 for
the calling sequences of the above routines.
Each AIM message has a unique message code, which is passed to these routines. The code
specifies the general type of the message and the specific message text. See Table 13-1 for details
on message codes.
Since many messages deal with databases, the operator-interface primitives can optionally be
passed information specifying a database, a record within that database, and a field within that
record. If that information is passed to the routines, a string describing the database access is
appended to the output message. For example, the trace message for accessing a feeder can be sent
to the operator with the instruction:
CALL rn.message(ec.acc.feed, , fd.db[TASK()], 0)
where
ec.acc.feed
Is a real variable that contains the message code number for the “accessing
feeder” trace message.
fd.db[TASK( )]
Is a real variable that specifies the Feeder database is being accessed.
0
Specifies that the current Feeder record is being accessed.
71
The empty second argument (“, ,”) indicates that no secondary message string is specified. The
fact that the field and index arguments are omitted (after the “0” argument) implies that the field
within the record is not significant for this message.
The call to rn.message( ) shown above will result in the following trace message:
Accessing: feeder: feedtube1
where “Accessing:” is the trace message, feeder is the name of the Feeder database, and
“feedtube1” is the name of the current Feeder record.
Informative and Trace Messages
Informative and trace messages are both handled by the routine rn.message( ). During walk-thru
training, both types of messages are sent to the Task Control Panel. Trace messages are suppressed
during normal execution.
Error messages
The routine rn.error( ) handles error messages and edit requests. In addition to displaying a
message, this routine waits for an operator response to be entered. The response is returned as the
error value from the routine. See the description of operator error response codes in the section
“General Concepts and Database Structures” on page 62.
The operator-response parameter allows the runtime routine to restrict operator responses to
certain values. This restriction eliminates the need to filter out undesired responses in the runtime
program. This parameter is a bit mask in which each bit corresponds to a particular response. See
Chapter 15 for a list of the global variables that are used to compose this parameter. Note that an
abort response is always allowed (unless explicitly suppressed), regardless of the value of the
response parameter.
The database information passed to rn.error( ) determines the data that is to be edited if a database
number is specified and the operator presses Edit on the Task Control Panel. The Edit button
has no function if no database number is specified.
Database Access Low-level Primitives
Data values are often read from databases during runtime execution. These values fall into two
classes: values that must be defined and cannot be taught during walk-thru training, and values
that may be undefined and can be taught or assigned a new value during walk-thru training.
Examples of values that must be defined are link pointers (which should have been filled in by the
linker), the names of strategy routines, reference frames, and tool transformations. If one of these
values is undefined at runtime, an error must be signaled and normal execution cannot continue.
Database Manager library routines should be called directly to fetch these values. If a value is
undefined, these routines return an error.
Examples of values that may be undefined are motion destinations, approach and depart heights,
etc. When these values are undefined at runtime, and walk-thru training is enabled, the system
prompts the operator to define the value and then proceeds with normal sequence execution.
Because this situation occurs so frequently, several AIM primitives are supplied to handle the case
of undefined data that are allowed to be defined or edited during walk-thru modes. These
routines automatically prompt the operator and then return the operator response as their status.
These routines are listed below. See the dictionary of AIM primitive routines in Chapter 16 for
details on the calling sequences.
72
rn.get.a.num( )
Primitive routine that reads a numeric array field and returns the values in
an array. (This routine corresponds to the database library routines
db.get.a.num( ).)
rn.get.a.nums( ) Primitive routine that reads a number of successive numeric fields and
returns them in a real array. (This routine corresponds to the database
routine db.get.a.nums( ).)
rn.get.a.str( )
Primitive routine that reads an array of string values from a database and
returns them in a string array. (This routine corresponds to the database
routine db.get.a.str( ).)
rn.get.num( )
Primitive routine that reads a single numeric value from a database. (This
routine corresponds to the database library routine db.get.num( ).)
rn.get.str( )
Primitive routine that reads a single string value from a database. (This
routine corresponds to the database library routine db.get.str( ).)
rn.get.trans( )
Primitive routine that reads a single transformation value from a database.
(This routine corresponds to the database library routine db.get.trans( ).)
rn.open.p.rec( ) Primitive routine that opens a database record given its physical record
number. (This routine corresponds to the database library routine
db.open.p.rec( ).)
rn.open.rec( )
Primitive routine that opens a database record given its logical record
number. (This routine corresponds to the database library routine
db.open.rec( ).)
rn.put.trans( )
Primitive routine that stores a single transformation value into a database.
(This routine corresponds to the database library routine db.put.trans( ).)
73
Special Routines for Accessing the Variable Database
The value that is used to access the Variable database is actually an encoded value the contains the
numeric value as well as the data type of the variable.1 For any statements that reference the
Variable database, the args[ ] array returns this coded version of the actual database value (not a
record number as is the case for all other databases). The routine rn.get.va.num( ) will extract the
actual value from the code value returned in the args[ ] array. (Note that this routine will also work
for a value retrieved from a field which is linked to the variable database with a linking rule.)
Since the value returned in the args[ ] array is encoded, the normal check for an undefined
argument (args[x] == 0) cannot be made. The global constant va.undef.var should be used to
check for an undefined value:
IF args[x] == va.undef.var THEN
The routine rn.put.va.num( ) will put a value into the Variable database with the proper encoding.
When you read or write a value from the Variable database, you must indicate what type of
variable you are reading or writing. If the argument type is less than zero, then it must be the
value of one of the ed.type.∗ global variables which define constants and variable database
references.
Table 5-4
Argument Type Field Description
Variable
Value
Argument
Description
ed.type.const
–1
--constant--
Integer constant.(*)
ed.type.signal
–2
--input--
Input signal constant, or output signal
being read back as an input.(*)
ed.type.outsig
–3
--output--
Output signal constant.(*)
ed.type.string
–4
--string--
15-character string constant.
ed.type.var
–5
--variable--
Constant, signal or general variable
defined in the Variable database.
ed.type.lhvar
–6
--o_variable--
Output signal or writeable general
variable defined in the Variable database.
ed.type.seq
–9
--sequence--
Name of a sequence in the current
module.
(*) These values may also be used as the “srch.ty” argument value in the lk.define( )
routine to associate a named signal or constant with an integer field which receives
the actual constant or signal value.
Creating Primitives
Primitives are simply V+ routines that perform runtime operations that are commonly used.
Therefore, primitives have no standard calling sequence, and the passed parameters are
determined by the specific function performed by the primitive.
1.
74
Digital signal numbers are passed directly in the args[ ] array.
In the following sections we discuss the guidelines that should be followed in writing new
primitives. We also describe the global variables that are used for interacting with the operator
interface.
Guidelines for Writing AIM Primitives
The guidelines listed below should be followed when writing new primitive routines. In addition,
see section 1.4 for a list of restrictions that apply to all subroutines added to AIM.
• Runtime routines should not perform input or output (I/O) directly to the monitor or
operator control-panel windows. All I/O should be performed using the library routines
rn.error( ) and rn.message( ).
• Runtime routines may open their own windows and perform I/O to them using standard V+
instructions.
• Disk-resident (as opposed to memory-resident) databases keep their associated disk files
open for read or write and must follow standard rules for file access. If any task has a diskresident database open for write, then no other task can open or read that database.
• All routines should check the exit status codes from any routines they call. A return status of
rn.opr.retry or rn.opr.fail can be handled locally within the routine. All other nonsuccess
status values should be passed back to the caller for handling by the scheduler.
Actions
The definition of an action is somewhat arbitrary. It is a series of operations that are logically
grouped for execution, retrying, or skipping. The intent is to give the operator a level of coarseness
for single-stepping—somewhere between Pause After Operation and Pause After Statement.
Pause After Action is checked by the routine rn.check.pause( ), using the argument
ai.pause.action. Pausing should occur only if there is no other pending operator error response.
Also the new operator response should be processed as if it were the current status. For efficiency,
a program such as the following should be used:
CALL any.routine(..., error)
IF NOT error THEN
CALL rn.check.pause(ai.pause.action, error)
END
IF error THEN
.
.
; Handle error
.
END
The high-level AIM primitives check for Pause After Action after they have completed their
operation, but before they exit.
System Constants
To aid program readability and help isolate Adept system upgrades from your custom code,
Adept has defined an extensive list of system constants. When Adept modifies code, we will
modify any system constants so they refer to the same thing regardless of their new absolute
value. For example, if fields are added to a standard database, the defined constants will be
changed to refer to the same logical field.
75
System constants have been defined for:
• database numbers
• field numbers for all databases
• menu bar numbers
• common system messages
• standard control values
Declared constants for databases are listed in the reference manuals. The values for system
constants can be seen by looking at the programs in the PUBLIC.OV2, TEXT.OV2, and the various
xxxMOD.OV2 files. The V+ Developer provides a convenient tool for viewing global constants and
their related modules.
Many of the standard control values have an associated initialization record that allows you
specify their startup value. Some examples are:
• The default user access level (as delivered by Adept, the access level when AIM is started
defaults to 4—complete access)
• The maximum robot speed that can be set by the user
• The robot approach and depart minimums
Walk-Thru Training
Walk-thru training mode is indicated by the runtime global array rn.sw.walk[ ] having the value
TRUE. This switch is set for each task according to the Walk Thru check box on the Task Control
Panel. When this switch is set, the runtime generates trace messages on the status display and
allows interactive training of selected data.
Trace messages are generated by calling the message routine with a trace message code. See the
code at the end of this section and the description of rn.message( ), inChapter 16 for more detail.
Trace messages normally indicate the start of a new action. They should be used sparingly to
avoid flooding the operator with messages. The trace call should be conditioned on
rn.sw.walk[TASK( )] as shown in this sample feeder trace message:
IF rn.sw.walk[TASK()] THEN
CALL rn.message(ec.acc.feed, "", fd.db[TASK()], 0, -1)
END
All interactive walk-thru training code should be conditioned on the values of rn.sw.walk[ ]. If the
switch is not set, the program should be as efficient as possible. This means that many error
conditions will result in failure of the statement rather than a user-friendly prompt message. If the
switch is set, execution is assumed to not be time-critical, and the extra code required to recover
from errors in a user-friendly manner is permitted.
For most applications, the system customizer can merely call AIM low-level primitives, which
already handle walk-thru training. The sample walk-thru training program following this section
outlines the general algorithm to be used if walk-thru training must be serviced directly. This
example is the low-level primitive to fetch numeric data from a database with training. The
routine executes as described below.
1. The desired operation is attempted, and the status returned is saved. In the example, the
operation is reading a number from a database.
76
2. If in walk-thru mode, or an error status is returned, special code is executed. The IF statement
is written to be most efficient during the most common case: non-walk-thru mode with no
errors.
3. If in walk-thru mode, call the walk-thru training routine to report the error. If there is no
error, or the error is “no data defined”, this routine prompts the operator to train the data and
waits for a response. See the description of rn.walk.train( ) for details.
4. If not in walk-thru mode, report the error and return any operator response code other than
“Proceed”.
5. Perform the operation again to obtain the desired data.
6. Continue this process until the operator either defines the data or responds with a command
other than “Proceed”.
77
Sample Walk-Thru Training Program
.PROGRAM rn.get.num(db, field, index, num, error)
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
ABSTRACT: Get a single number from an array in the record currently
open in the specified database.
Handle walk-thru training if enabled.
This routine does not handle optional data values.
INPUT PARM:
db = Number of the database.
field = Field number of array.
index = Optional index into array. First element is 0.
If not defined, 0 is assumed.
OUTPUT PARM:
If no error,
error rn.opr.success
num = Real variable received from database.
else if error,
error = Standard “operator error response code”.
Copyright (c) 1986, 1988, 1989 by Adept Technology, Inc.
AUTO st
error rn.opr.success
;Assume success
IF NOT DEFINED(index) THEN
index = 0
END
CALL db.get.num(db, field, index, num, st)
; Handle errors or walk-thru.
IF rn.sw.walk[TASK()] OR st THEN
DO
IF rn.sw.walk[TASK()] THEN
CALL rn.walk.train(db, field, index, st, error)
ELSE
CALL rn.error(error, er.all, st, "", db, 0, field,
index)
END
IF error GOTO 100
;Exit if error
CALL db.get.num(db, field, index, num, st)
UNTIL NOT st
END
100 RETURN
.END
78
AIM Keyword Lists
5.4
AIM Keyword Lists
AIM has a special facility for defining information sources that act essentially as single field
databases. This facility is useful for situations where you want to present operators with listed
data but do not want to define a formal database. See Table 6-1 on page 88 for details on how
keyword lists are used in a statement definition. These “keyword” lists can be accessed by the
sequence editor or by menu pages. See the description of Keyword on page 121 for details on
adding keyword lists to menu pages.
Chapter 16 contains the description of the following routines that implement the keyword facility:
Table 5-5
Keyword List Routines
Routine
Use
ai.key.new( )
Create a new keyword list
ai.key.add( )
Add a keyword to an existing list
ai.key.info( )
Returns information about a keyword list.
ai.key.get( )
Get a value from a keyword list (similar to the “db.get.∗”
routines for accessing database values)
ai.key.find( )
Searches a keyword list for a value
ai.key.find.num( )
ai.key.sort( )
Sort a keyword list
ai.key.sort.num( )
Creating a Keyword List
Keyword lists are created in a string array. Each keyword has an associated data value. Keyword
lists may be constructed using any 1 or 2-dimensional global string array. The string array
$ai.arg[,] has special meaning to the sequence editor (see the next section).
The number and string menu items allow you to display keyword lists. The field, ai.ctl[ ], or V+
variable that is associated with the keyword may then take its value from the keyword list. Lists
may be displayed as either a single keyword or as a scrolling window showing possible keywords.
Keyword Lists and the Sequence Editor
The special global string $ai.arg[,] array contains keyword lists which may be accessed by the
sequence editor in addition to the menu pages. At link time, the value associated with a keyword
is packed into the sequence argument array. The string array $ai.arg[,]is defined in TEXT.OVR/V2.
The value of the left-hand index of the $ai.arg[,] array may be used as an argument type in
sequence statement definitions. The negative of the left-hand index is used as the argument type.
For example, the following code from ai.system.mes( ) in TEXT.OVR/OV2 creates statement
argument type –19:
79
; Define the statement argument place holder
CALL ai.key.add($ai.arg[ai.arg.st.arg,], "--component--", -19)
; Create a new keyword list for "component" (type -19)
CALL ai.key.new($ai.arg[19,])
; Add the elements to the keyword list
CALL
CALL
CALL
CALL
ai.key.add($ai.arg[19,],
"none", 0)
"X", 1)
"Y", 2)
"Z", 3)
These statements define a keyword list in the string array $ai.arg[19,] with the following elements:
Index
String
Value
1
none
0
2
X
1
3
Y
2
4
Z
3
If the negative of the left-hand index for $ai.arg[,] is specified as the argument type in a statement
definition, then the keyword list string values are used as values for the statement argument. The
linker packs the keyword numeric value corresponding to the keyword string into the args[ ] array
which is passed to the statement execution array.
The elements in $ai.arg[ai.arg.st.arg,] have a special meaning to the sequence editor. These
elements define the default strings for statement arguments using keyword lists. The numeric
value associated with each of these default strings is the negative of the left-hand index into
$ai.arg[,] for the possible keyword values for that argument. For example, a partial list of
$ai.arg[1,] is:
String
Value
"--task--"
–10
"--device--"
–11
"--yes/no--"
–15
"--component--"
–19
This list is used on the statement definition page to select the Argument Type. Selecting
“--component--” writes a value of -19 into the argument type field of the statement definition. The
sequence editor then uses $ai.arg[19,] as the keyword list to select values for argument
“--component--”.
Keyword Lists and the Menu Driver
To use a keyword for a single item numeric fields; specify “keyword” as the format, in the List:
data box, specify the name of the string array (without the “$”), and in the Idx: data box, specify
the left-hand index of the string array.
80
AIM Keyword Lists
For example, using the above example, enter “ai.arg” for List: and “19” for Idx:. If X is selected, the
data item will have a value of 2 and the string “Y” will be displayed. If the data does not match
any keyword value, “?” is displayed. For input, you must enter one of the keyword strings and
the corresponding numeric value is stored as the numeric data.
The low/high limits on the format page refer to index values. If these limits are specified,
keywords with indices outside these limits are ignored. For example, if you specify limits as 2 and
3, then only strings X and Y will be considered.
To use a keyword list for a numeric item, specify the keyword list format and a scrolling window
will be displayed showing all the keywords within the low/high limits range. When you click on
a keyword, the corresponding value is stored as the numeric data. The scrolling line
corresponding to the numeric value is highlighted.
For string fields, the setup is identical to numeric items except the numeric value is ignored and
the actual keyword is stored.
81
Chapter 6
The AIM Statement
6.1
What Is a Statement?
The AIM statement is the central element of AIM operation. It specifies the V+ routine that is to be
executed, and provides the arguments for that routine. AIM statements are combined into
sequences that execute your particular workcell implementation. Statements are supplied with
each optional AIM module (for example, VisionWare or MotionWare). Custom statements may be
added by the engineers who installed your AIM system, or you may write your own custom
statements. This chapter covers the steps to build a custom AIM statement.
How Do Statements Work?
An AIM statement consists of a statement name followed by a series of arguments. Individual
arguments can be required or optional. When a completed statement is run, AIM will execute a V+
routine having the same name as the statement (statement routine). The individual arguments to
the statement are names of database records, elements from keyword lists, or integer values.
Before a sequence is executed, AIM calculates the record number for each database and value for
each keyword list accessed in the sequence. This process is called linking. When a statement is
executed, the record numbers, keyword elements, or integer values are passed to the statement
routine. This allows the statement routine to access values in the specified records or keyword lists
without having to search each database for the correct record or keyword list for the correct
element. The statement routine merely opens the database record and extracts a field value, or
retrieves a keyword. The AIM library routines that allow you to access the various databases and
keywords are summarized in Table 6-2. The actual routines are described in Chapter 14.
In addition to the database records directly specified in an AIM statement, additional records may
be indirectly specified. For example, in MotionWare there is a location database and each location
may have an associated reference frame. This reference frame is specified in the Frame database.
Thus, if a location is specified in an AIM statement, its frame record is also indirectly specified. If
your custom statement requires this indirect relationship, special linking relationships will have to
be created so the correct database values can be extracted. Section 6.5 covers creating these special
linking relationships.
Statement Databases
Each statement has a formal definition that is stored in a special AIM database known as the
Statement database. Creating these formal definitions is covered in section 6.3.
The base AIM package and all application modules have their own statement databases. If you are
adding custom statements, you should create a new statement database, either by copying an
existing statement database and deleting existing records, or using the STAT.RFD definition file to
create a new database (see Chapter 3 for details on creating new databases).
The statement databases that are used during AIM execution are loaded during AIM initialization
and are specified in special initialization records. Thus, if you create your own statements, you
will need to add a new initialization record to load your custom statement definitions.
83
Chapter 6 - The AIM Statement
Statements and the AIM Runtime System
Statements are only one part of the overall AIM runtime system. In order to correctly write and
modify statements, you must know how statement execution relates to the overall runtime
operation. Chapter 5 and Chapter 9 provide details on other pieces of the AIM runtime system.
Figure 6-1 shows where statements are used in the overall AIM world.
6.2
Statement Overview
Figure 6-1 shows the life of an AIM statement. A statement’s life can be grouped into the following
categories and steps (the step numbers correspond to the numbers in Figure 6-1):
Developing a Custom Statement:
1. The statement record that defines the syntax of a statement is created in the statement editor.
See “Creating a New Statement Definition” on page 86.
2. The SEE editor is used to write the supporting code for the statement. See the V+ Language
User’s Guide and V+ Language Reference Guide. The V+ Developer is a useful tool for creating
statement routines.
Generating Data:
3. The sequence editor is used to select individual statements from the statement databases. See
the descriptions of creating sequences in the individual application user’s guides.
4. Record names, keyword names or constant values are selected as arguments to the individual
statements.
5. The statements and their record names, keyword names and/or constant values are stored in
the sequence database (one statement and its arguments per record).
Pre-runtime Operations:
6. A sequence is selected for execution from one of the control panels or with a SELECT
statement in a control sequence.
7. The pointers1 corresponding to the statement arguments are calculated and stored in the
sequence database. If the statement arguments are constant values, those values are stored.
Any special linking is performed and the appropriate databases updated. See “Linking” on
page 101 for more information.
Runtime Operations:
8. The scheduler begins extracting the individual statements and the pointers and values
associated with the statement. A V+ program with the same name as the statement is
CALLPed. The values generated by the linker and stored in the sequence database are passed
in the args[ ] array to the CALLPed routine. See “The Statement Arguments” on page 91 for
more information.
1.
84
From this point on, when a value in the args[ ] array is a record number or an element in a
keyword list, we will refer to the value as a pointer.
Statement Overview
Statement
Routines
Control Panel
2
SEE Editor
7
Linker
6
8
Record:
Record:
Record:
Record:
Record:
Record:
Sequence
Database
Record:
Record:
Record:
Option
Databases
Statement
Database
Record:
Record:
Record:
User
Databases
1
5
3
Sequence Editor
4
Database Editor
Figure 6-1
The AIM Statement
85
6.3
Creating a New Statement Definition
The following steps will create an AIM statement:
1. Create a new statement database:
a.
Use the DBM Utilities to create a new statement database from the
STAT.RFD file (see Chapter 3, section 3.6).
b.
Change the “statements, additional” record in the USERINI initialization
database to reflect the name of your new statement database (or create an
entire new initialization record).
2. Create the form and syntax of the statement, and specify the source of information for each
argument in the statement (detailed in this section).
3. Write the V+ code that uses the database information to perform operations in the workcell.
The requirements for statement routines are covered in section 6.4. V+ programming is not
covered in this manual, and we assume you are proficient in V+ programming. See the V+
Language Reference Guide and the V+ Language User’s Guide . Additional programming
restrictions are listed in “Programming Restrictions” on page 3, and programming guidelines
are listed in “Guidelines for Writing AIM Primitives” on page 75.
4. Store the statement routine and any subroutines created to support the main routine. (The
standard AIM library routines are always loaded when AIM is started up, so the library
routines your statement routine uses do not have to be stored with your custom routines.)
86
An AIM statement (but not the V+ code that supports it) is created as follows:
To enter statement editing mode:
Special ➡ Edit Statements ➡ highlight statement database ➡ Select
To create a new statement record:
Edit ➡ New Record
The following figure shows a typical statement definition:
➊
➋
➌
➍
➎
✔
✔
➏
➐
➑
✔
➒
Figure 6-2
Statement Definition Menu Page
Statement Definition Options
➊
Enter the name for the new statement. When this statement is executed, a V+ routine with the
identical name will be called.
The statement name must begin with a letter, followed by any combination of letters,
numbers, periods and underline (“_”) characters. Statement names can have up to 15
87
characters. Since statement names are also used as the names of V+ routines, statement names
must be unique among the names for all the V+ subroutines used in the AIM installation.
➋
➌
➍
➎
➏
➐
➑
➒
This entry is the primary sort field for all statements (from all statement databases) loaded
during start-up. All statements that have the same value in this field will be grouped together
in the statement pick list. A solid bar will separate the different groups of statements.
Enter the total number of arguments that will be used for this statement (normally this
number is the same as the number of arguments defined in item ➐ but can be less than the
total number).
There are two types of sequences, runtime and control. Runtime sequences normally run
motion devices and evaluate vision records. Control sequences perform activities such as
loading, starting, and stopping sequences. These check boxes allow you to limit a statement
to the desired type of sequence.
These check boxes allow you to limit the statement to systems that are equipped with vision
or motion.
Indicate how many optional arguments should be opened. See the example in the next
section for a description of how the optional argument brackets are used.
Enter a string that will appear as the constant text in each clause of the statement.
Double click on the “Argument Type” data boxes and a pick list of defined argument place
holder strings will be displayed. These place holders indicate the source of information for
this particular argument. The standard options are shown in Table 6-1. The available options
will depend on the currently loaded AIM application modules. You can also define additional
database and keyword lists,1 so this list may show additional custom options.
Enter the number of optional arguments that should be closed. This number should not
exceed the number opened by option ➏. The number of open brackets must equal the
number of close brackets.
Table 6-1
Statement Argument Sources
Place Holder
Source
--component--
Keyword from the list of Cartesian components (X, Y, Z).
--constant--
Record from the variable database specifying an Integer constant.
An integer value entered from the keyboard.
--conveyor--
Record from the conveyor database.
--device--
Keyword from the list of devices.
1.
88
Database placeholders are specified with the $undef parameter in the call to
ai.db.define( ) that initializes runtime databases. See the program ai.system.mes( ) in the
file TEXT.OVR/OV2 for details on defining place holders for keyword lists.
Table 6-1
Statement Argument Sources (Continued)
Place Holder
Source
--event--
Keyword from list of “pause after” keywords.
--force--
Record from the force database.
--frame--
Record from the frame database.
--input--
Record from the variable database specifying an Input signal.
Valid input signal entered from the keyboard (can be preceded by optional
“@”).
--location--
Record from the location database.
--module--
Module name from list of defined modules.
Module name entered from the keyboard.
--opr--
Keyword from the list of arithmetic and relational operators.
Legal operator entered from the keyboard.
--output--
Record from the variable database specifying an Output signal.
Valid output signal entered from the keyboard (can be preceded by optional
“@”).
--o_variable--
Record from the variable database that specifies an Output signal, V+
variable, or ai.ctl[ ] value.
Valid output signal entered from the keyboard (can be preceded by optional
“@”).
--path--
Record from the path database.
--response--
Keyword from list of operator responses to paused sequence.
--segment--
Keyword from the list of robot move segments (approach, depart, location).
--sequence--
Sequence from the list of sequences in the currently selected module.
Sequence name entered from the keyboard.
--string--
Character data entered from the keyboard.
--task--
Keyword from list of task keywords.
--tool--
Record from the tool database.
89
Table 6-1
Statement Argument Sources (Continued)
Place Holder
Source
--uopr--
Keyword from the list of unary operators.
Valid unary operator entered from the keyboard.
--variable--
Record from the variable database.
Numeric value (integer or real) entered from the keyboard.
Digital signal (preceded by “@”).
--vision--
Record from the vision database.
--yes/no--
Keyword from “yes/no” keywords, default is “--no--” if omitted.
Example Statement Definition
The example statement shown below is the WAIT_UNTIL_ROBOT statement from the MotionWare
module. When this statement is first displayed in the sequence editor, it looks like:
WAIT_UNTL_ROBOT {DEVICE --device--} {STOPPED --yes/no-{SETTLE --constant--}} {< --constant-- {FROM --location--}
{ALONG --component--}} {> --constant-- FROM --location-{ALONG --component--}} {%_COMPLETE --constant--}
{TIME_LEFT --constant--} {TIMEOUT --constant-{TIMEOUT_STATUS --o_variable--}}
The first argument DEVICE is completed with a keyword from the --device-- list of keywords. The
second argument STOPPED is completed with a keyword from the --yes/no-- list of keywords. The
third argument FROM is completed with a record from the location database. The fourth argument
SETTLE is completed with a constant entered from the keyboard. The remaining arguments expect
database records, keywords, or constant values.
Note that one condition section was opened before the DEVICE argument, and one argument was
closed after the DEVICE argument. Thus, DEVICE becomes an optional argument with no
dependencies. In the case of STOPPED and SETTLE, there is one optional argument opened before
STOPPED, one optional argument opened before SETTLE, and two optional arguments closed after
SETTLE. This makes STOPPED an optional argument with no dependencies and SETTLE an optional
argument that is dependent on the STOPPED argument being used.
6.4
Writing a Statement Routine
Once a statement definition has been created, the supporting V+ code must be written.
Statement Routine Format
Every statement routine must have the following form:
NAME(args[ ], error)
The “NAME” of the routine must be the same as the name given the statement when it was created
(item ➊ from Figure 6-2).
90
The Statement Arguments
“args[ ]” is an array holding either the pointers generated during sequence linking, a constant
value, or an element from a keyword list. If an optional argument is unspecified, a 0 is placed in
the corresponding args[ ] element.1
The record number, constant value, or keyword pointers passed to the statement routine are
mapped into the args[ ] array based on the order of the arguments in the statement definition. In
the example from Figure 6-2, args[1] would contain the keyword pointer for DEVICE, args[2] the
keyword pointer for STOPPED, args[3] and args[4] would contain the values entered at the
keyboard, args[5] the record pointer from the location database for FROM, and so on. The
statement routine uses the value in args[1] to access the correct keyword, the value in args[5] to
open the corresponding record in the location database, on so on.
To access the required database, record, and field, the statement routine must first open the proper
database record, and then get the value from the correct field in that record. The routines
summarized in the following tables are used to open records and retrieve field values. The
routines used to extract the relevant keywords are also listed.
Fields and databases are referenced by their numbers. The reference manuals list defined
constants for database and field numbers. Using these defined constants will help isolate your
program code from any changes to database numbers or field structure and to make the code more
readable (see Chapter 4).
“error” returns 0 if the statement executed successfully. If a value other than zero is returned, it is
the number of an operator error response generated during execution of the statement. These
values correspond to the global variables described in Table 5-3.
1.
See “Special Routines for Accessing the Variable Database” on page 74 for details on the
Variable database.
91
Standard AIM Routines
The AIM baseline and application modules come with a complete set of callable subroutines that
can be used in your custom applications. These subroutines support the error- handling capacity
built into AIM. Using these routines wherever possible will improve the robustness of your
custom routines.
The AIM database management library routines are detailed in Chapter 14.
The baseline runtime library contains routines for controlling various Adept hardware and
performing many frequently executed tasks. In addition, each application module will have its
own library of subroutines. See the application module reference guides for details. The following
table gives a brief description of the routines detailed in Chapter 16.).
Table 6-2
Baseline Standard Routine Summary
Routine
Description
ai.add.opt.name
This routine packs a string of module ID names into control variables for
subsequent display by the ID pop-up.
ai.attach.dlun
Attach a disk logical unit.
ai.attach.dlun2
This routine attaches the first available disk LUN for a specific type of
device and returns the number of the LUN. If no LUN’s are available, an
error code is returned.
ai.cpy.rn.ctl
Copy a real-valued control variable value from the a runtime task rn.ct[,]
array to the ai.ctl[ ] array for use by the operator interface.
ai.db.define
Define a database type for use by fixed, shared, and loadable databases. It
associates a type code with various data structures which describe the type
and allow access by graphic routines, editors, menu pages, and modules.
ai.dev.define
Define and initialize a robot device.
ai.find.device
Return information about the task that is assigned to the current device.
ai.get.rn.ctl
Return a real-valued control variable value from the a runtime task.
ai.key.add
Add a keyword string and its associated data value to a keyword list.
ai.key.find
Find a keyword in a keyword list.
ai.key.find.num
Find an entry in a keyword list based on the data value.
ai.key.get
Returns a keyword from a keyword list
ai.key.info
This routine returns information about a keyword list.
ai.key.new
This routine begins the definition of a new keyword list.
ai.key.sort
This routine sorts a keyword list in ascending order by keyword name.
ai.key.sort.num
This routine sorts a keyword list in ascending order by data value.
ai.load.icon
Load graphic icons into memory from a disk file.
ai.load.init
This routine processes the AIM initialization files.
92
Table 6-2
Baseline Standard Routine Summary (Continued)
Routine
Description
ai.load.opt
Load a V+ program file into memory; or load, execute, and delete a
program overlay file.
ai.log.get
Extract the next element from the message log queue. Don’t wait for the
queue to be available. If no data logging is enabled, always returns
“empty”.
ai.set.ctl
Operator interface routine to change the value of the AIM control variables
ai.ctl[ ] and rn.ctl[,].
ai.set.rn.ctl
Set a real-valued control variable for a runtime task.
ai.task.define
Define and initialize a runtime task data structure.
ai.task.info
Return information about a given task index.
ai.task.prior
Return an array of task priorities for use by ai.task.start( ).
ai.task.start
Start an AIM task.
ai.task.teach
Perform a teaching function by a runtime task.
cu.cv.define
Defines how elements of the global control array ai.ctl[ ] are allocated.
cu.define.dbs
Customizable routine that loads application module databases.
cu.error.notify
Customizable routine for responding to AIM runtime errors.
cu.initialize
Initialize global variables and define constants to customize AIM for a
specific application.
cu.initialize2
Initialize global definitions of database field numbers.
cu.module.init
Perform custom module initialization.
cu.mu.reacte
Customizable routine called when a REACTE condition occurs in a runtime
task.
cu.reacte
Provide access to the processing of error conditions.
cu.sched.start
Performs custom runtime initialization when a runtime scheduler is
started.
cu.set.mode
Customizable routine that can be used to respond to changes in system
modes.
cu.shutdown
Customizable routine that can be used to perform any required custom
shutdown procedures.
cu.sig.define
Initializes the variables for the internal soft panic signal and for pendant
control of the robot tool.
cu.startup
Customizable routine that can be used to perform any required custom
startup procedures.
93
Table 6-2
Routine
Description
cu.task.init
Calls custom initialization when a task is defined during system
initialization.
dv.cli.abort
Abort the outstanding request or reply for the specified message ID.
dv.cli.connect
Connect the current client task to a server task and test if it is ready.
dv.cli.init
Initialize the current task as a client task and initialize the reply FIFO (firstin, first-out) queue.
dv.cli.reply
Read a reply for a request that was previously sent with dv.cli.send( ). If
the reply is present, it is returned, otherwise this routine indicates that the
request is “not complete”.
dv.cli.send
Send a request from a client task to a runtime server task.
dv.srv.connect
Connect the current task to receive server requests, however, the receive
FIFO queue is left disabled and must be enabled by calling dv.srv.enable( ).
dv.srv.disable
Disable the receiver FIFO queue and aborts any requests which may have
been pending.
dv.srv.enable
Enables the receiver FIFO queue for the current task.
dv.srv.recv
Receive the next message for this task, if any are present.
dv.srv.reply
Send a reply to a client task. The client task address is read from the $msg
input buffer.
er.error
Return the terse error message string for a specified error code.
ex.control
General interface routine for execution and control.
ex.mu.status
A menu page user routine called each time the status and control page is
drawn or refreshed.
ex.panel.sig
Called during system initialization to associate a digital I/O signal with an
operator control function.
ex.stat.assign
Map AIM errors to the ai.ctl[ ] or $ai.ctl[ ] global arrays.
io.post.cmd
Queues an I/O command buffer for a specified task.
io.pul.dwn.evt
Add a new entry, which is equivalent to a key press or window input
event, to a pull-down menu list.
io.pul.dwn.sfg
Set the flags-word values used to control special features of pull-down
menus.
io.pul.dwn.spw
Add a new entry, which displays a menu page or executes a spawn routine,
to a pull-down menu list.
io.working
This routine displays a “Working...” message in the center of the current
window. Optionally, in order to leave the current window unmodified, this
routine will allocate a new window, which is positioned in the center of the
current window, and write the message in an allocated window.
94
Table 6-2
Routine
Description
ld.asn.mod
Assign a module to the local task.
ld.asn.seq
Assign a sequence to the local task.
ld.asn.seqn
This program assigns a sequence to the local task. If a different sequence is
already assigned, it is de-assigned. If the new sequence is not loaded, it is
first loaded.
ld.dea.mod
This routine de-assigns a module from the local task.
ld.dea.seq
This routine de-assigns a sequence from the current task.
ld.get.mod.name
Get the name of a module, given its ID. Preserve any currently open record.
ld.get.modid
Get the module id assigned to a specified task.
ld.get.mod.seq
Get assigned module and sequence name for the current task.
ld.get.seqinfo
Return the name of the sequence with the specified sequence number.
ld.load.mod
Load a module into memory and open all relevant databases. Handle all
required interlocking.
ld.lookup
Return the module ID and sequence database number for a named module
and sequence.
ld.lookup.type
This finds a module component given its type and optionally its name. It
leaves the module database pointing at the record for that module
component. If type is zero, the module header record for that module is
opened.
ld.mod.member
Test if a database is a member of a module.
ld.unload.mod
Unload a module and related databases from memory.
lk.define
Store a linking rule into the lk.dbs[ ] array for use by the linking routines.
After this routine has been called for each of the linking rules,
lk.init.linls[ ] must be executed to validate the rules and build the
equivalent link trees.
lk.link.1.field
Routine to check if the specified field is linkable and if so, update this link.
lk.link.1.rec
Update the links of the currently open record of a database.
lk.link.mod
Performs ALL of the linking operations that are required to prepare a
module for execution.
mu.get.vname
Routine that gets the V+ variable name associated with the current menu
record.
mu.menu
Display a menu page.
mu.popup.error
Display the error pop-up window.
mu.set.goto
Build a command buffer for a menu or subroutine spawn “goto” operation.
95
Table 6-2
Routine
Description
mu.set.rtrv
Fill in the retrieve parameters in an I/O command buffer.
pe.attach
Attach the manual control pendant to the current execution task for use by
teaching routines.
pe.disp.msg
Display the text associated with an error on the manual control pendant
and beep the pendant.
rn.check
Runtime low-level routine to check for any robot or programming errors.
rn.check.pause
Runtime low-level routine to check for any requested pauses.
rn.cli.connect
Connect the current client task to a server task and tests if it is ready.
rn.cli.reply
Checks for a reply to a request previously sent by a call to rn.cli.send( ).
rn.cli.send
Send a message to a server from a runtime client task and optionally wait
for a reply.
rn.error
Send a message to the operator and wait for a response. (Handles error and
pause messages and allows an optional database to be edited.)
rn.error.resp
Set the response codes that are used by rn.error( ).
rn.exp.eval
Evaluate a set of arguments from one of the conditional statements.
rn.get.a.num
Runtime routine that returns an array of real values from an array field of
the current record in a database, and handles walk-thru training.
rn.get.a.nums
Runtime routine that returns values from consecutive numeric fields in the
current database record, and handles walk-thru training.
rn.get.a.str
Runtime routine that returns an array of string or name values from an
array field of the current record in a database, and handles walk-thru
training.
rn.get.num
Runtime routine that returns the numeric value from a field of the current
record in a database, and handles walk-thru training.
rn.get.str
Runtime routine that returns the string value from a field of the current
record in a database and handles walk-thru training.
rn.get.trans
Runtime routine that returns a transformation value from a field of the
current record in a database, and handles walk-thru training.
rn.get.va.num
Get a single value described by a variable argument returned in the args[ ]
array that references the Variable database
rn.message
Send an informative message or a trace message to the Task Control Panel.
rn.open.p.rec
Runtime routine to open a physical record in a database.
rn.open.rec
Runtime routine to open a logical record in a database.
rn.put.trans
Runtime routine to modify the value of a transformation field in the
current record in a database and handle any errors.
96
Statement Summary
Table 6-2
Routine
Description
rn.put.va.num
Write a single value described by a variable argument. The argument is an
encoded value describing a constant, signal, ai.ctl[ ] value, or database
record.
rn.resp.rest
Restores the response codes that were previously saved by the routine
rn.resp.save( ).
rn.resp.save
This routine saves the response codes that are currently in effect for
rn.error( ). The codes may be restored by calling the routine rn.resp.rest( ).
rn.sched.init
Initialize data structures when starting up the AIM scheduler.
rn.sched.start
This routine performs application-dependent initialization when a runtime
scheduler is started.
rn.send.menu
Send a request to the operator interface menu driver.
rn.seq.exec
Main runtime sequence execution routine.
rn.signal.out
Runtime routine to change or pulse a digital output signal, checking for
validity.
rn.signal.test
Runtime routine to test the state of a digital input signal, checking for
validity.
rn.signal.wait
Runtime routine to wait for a digital input signal to become TRUE (FALSE
when the logic is inverted), checking for validity.
rn.srv.reply
Send a reply to a client task. The client task address is read from the $msg
input buffer.
rn.status.num
Set ai.ctl[ ] variable values for use by the operator interface.
rn.status.str
Set an $ai.ctl[ ] value for the operator interface.
rn.wait.idle
Runtime routine to handle teaching and other runtime functions while the
task is idle.
rn.wait.time
Runtime routine to cause the current runtime task to wait for a specified
time.
rn.walk.train
Runtime routine to train a value in a database record during walk-thru
training mode.
6.5
Statement Summary
A complete example of creating statements, statement routines, databases, and menu pages is
provided in Chapter 12.
When you are first learning to create custom AIM statements, the information flow can be
somewhat confusing. This section summarizes where AIM gets each piece of information to
complete a statement routine.
97
How Does AIM Know Which V+ Program to Execute?
When an individual statement is executed, AIM will CALLP a program with the exact name as the
name of the statement. The CALLPed program will be passed two parameters, a real array
containing argument pointers (and/or constant values), and a real value to return the number of
any operator response generated.
How Does the Linker Know Which Database or Keyword List to Use?
When a statement record is originally created, each statement argument is assigned a
corresponding database or keyword name.
How Does the Linker Know Which Record Number to Return?
When a statement is added to a sequence, each of the statement arguments is filled with a
database record name or keyword list name. When the completed sequence is processed by the
linker, the database or keyword list associated with each statement argument is searched for a
matching name. When a match is found, the number of the record or keyword is stored in the
sequence database. (If a constant argument is indicated, the constant value is stored.)
How Does the Statement Routine Know Which Database to Access?
The programmer must keep track of which database or keyword list is associated with each
argument. (For example, if the first argument of a statement specifies the path database, the record
number passed to the statement in args[1] must be used to access a record in the path database.)
How Does the Statement Routine Know Which Record to Access?
When each statement in a sequence is executed, the record and keyword pointers generated
during linking are placed in the args[ ] array. The pointer associated with the first statement
argument is stored in args[1], the pointer associated with the second argument is stored in args[2],
and so on. The routine uses these pointers to access the appropriate information source. Bear in
mind that the information source associated with these record numbers is set when the statement
is created and must be kept track of by the programmer. (Records always start from 1 to n.) The
programmer must also keep track of any arguments that return a constant value instead of a
pointer.
How Does the Statement Routine Know Which Field to Access?
The programmer is responsible for specifying the correct field number in the open record (the
linking process only generates record numbers, not the correct field within that record).
Remember:
• The information source is specified when the statement definition is created.
• The record or keyword names are specified when a statement is added to a sequence and its
arguments completed.
• The pointers (based on the record and keyword names) are generated during linking.
• The pointers for the arguments in an individual statement are placed in the args[ ] array
when an individual statement is executed. The statement routine is responsible for accessing
the correct information source.
• For database pointers, the field to access in the current record must be supplied by the
statement routine.
• For indirectly referenced records, the program must first get the record pointer in the
referencing database and then use it to open the correct record in the referenced database.
98
Statement Summary
• The array fields always start from 0 to n.
How Does the Statement Routine Access a String Argument?
Some statement routine arguments are string values. These arguments include --task--,
--module--, --sequence--, and --string--. The associated string values are not passed to the
statement routine, so the routine must read the value from the sequence database.
Assume that argument 5 contains a string value. The following V+ code example reads the value
from the sequence database.
AUTO $string
LOCAL string.arg
string.arg = 5
; Open the sequence database record which corresponds to the current step.
CALL rn.open.rec(sq.db[TASK()], rn.ctl[TASK(),rn.ctl.c.step], error)
IF error GOTO 100
; Read the string value from the sequence database.
CALL rn.get.str(sq.db[TASK()], sq.strs, string.arg, $string, error)
IF error GOTO 100
99
Chapter 7
Linking
7.1
Linking
This section describes the AIM linker. The first two sections explain the operations performed by
the linker and why they are needed. The next section describes how the linker is directed to
perform its required functions. The final section explains how the directives to the linker can be
modified and augmented for customized systems.
Definition of Linking
Linking relates data items in the AIM databases so they can be accessed efficiently by the AIM
runtime system.
To understand the AIM linker, you must first understand how AIM databases may be interrelated.
The data in the AIM system is divided into a number of separate databases. Many of these
databases are related to each other. For example, with MotionWare, each record in the Location
database may be assigned a frame from the Frame database. A string field in the Location
database stores the name of the reference frame. Thus, each record of the Location database may
“point” to a record in the Frame database. A string field identifies the related record and does not
indicate its position in the database. Use of string field simplifies the task of generating data, since
users do not need to be concerned with the record number of a particular record within a
database—a number that will change as new records are created and unwanted records are
deleted.
However, the AIM system must eventually know the record number of the related record so it can
be accessed. To find this record, AIM could search the database for a matching record name.
Searching databases is, however, slow.
To speed execution, AIM determines the actual record numbers corresponding to selected string
pointers before execution of a sequence begins. This process of “linking” related databases is
performed by the AIM linker. For each string that identifies a record in another database, a
“hidden” link field in each database record is allocated. This link field is filled in by the linker with
the record number of the record referenced by the string.
At pre-runtime linking, the linker fetches the strings that identify related (indirectly referenced)
records, searches the corresponding database, and stores the record number of the matching
record into the link field. When a sequence step is executed, the runtime routines (which need to
access the record pointed to by the string) do not have to search to locate the record. Instead, they
can use the link stored with the string to directly access the appropriate record in the referenced
database.
From a system customizer’s point of view, there are basically three types of linking that are
performed:
1. Linking the directly referenced records that are used as statement arguments to the
corresponding databases—generating record numbers for record names and storing them in
101
Chapter 7 - Linking
the sequence database (where they are eventually passed to a statement routine in the args[ ]
array). If you create a custom statement, this linking is performed automatically, based on the
database, numbers specified in the statement record. No additional linking rules need be
defined.
2. Linking indirectly referenced records to records that are directly referenced—generating
record numbers for record names and storing them in the referencing database. If your
custom statement uses this type of indirect referencing, the linking data must be updated to
define the new relationship. The procedure for updating the linking data is presented later in
this chapter.
3. Variable database references are resolved and a constant value or encoded argument is
packed in a statement argument or in a referencing database field. If the referencing field is of
a constant type, the actual value is placed in that field. This value may be accessed directly. If
the referencing field is a variable type, an encoded value which specifies a constant or
database record is placed in the field. In this case, the routines rn.get.va.num( ) or
rn.put.va.num( ) must be used to decode the value.
The routine lk.link.mod( ) performs all the linking operations that are required to prepare a
sequence for execution. See lk.link.mod( ) on page 387.
Verification Operations Performed by the Linker
In addition to performing the basic linking operation, the AIM linker is also responsible for
verifying that specific database fields have defined values that are valid. The two types of
verification operations that can be performed are:
1. For a string field that contains the name of a V + strategy routine, the strategy routine can be
tested to ensure that it is loaded into memory and that it is executable. For example, a
Location record in MotionWare must contain the name of a routine to execute when the
location is reached.
2. For a string field that should contain a value, the value of the string can be tested to ensure
that it is not an empty string.
As with the basic linking operation, AIM could be designed to operate properly even if these
verification operations were not performed by the linker. However, by having the linker perform
these functions, the user is provided with early feedback concerning the validity of the databases.
Also, the runtime can execute efficiently, since it knows it has been passed valid information.
Since only selected fields required validation, the linker must be told which fields are to be tested.
The procedure for specifying fields to be verified is presented in the next section.
User-Defined Linking Rules
Your custom code must define formal linking relationships (linking “rules”) for the following
operations:
1. Linking indirectly referenced records to directly reference records. (Multiple indirect
references can be made, but a direct reference must eventually be made.)
2. Verifying that strategy routines, whose names are contained within database fields, are
loaded in memory and are executable.
3. Verifying that specified string fields within databases have defined, nonempty values.
For the first type of rule (linking two databases together), the rule definition requires:
• The type code of the database containing the search name (the pointer) and the computed
record number
102
Linking
• The number of the field containing the search name
• The number of the field in which the indirectly referenced record number is stored (the record
number computed by the linker will be stored in the same record that contains the search
name)
• The type code of the database that is to be searched for a matching name
• The number of the field containing the name to be matched
• A flag indicating if the linking operation is optional
If the rule is flagged as optional, no error will be generated during the linking operation if the
search string is empty or unspecified.
For the second type of rule (verifying strategy routines) the rule definition requires:
• The type code of the database containing the strategy routine name
• The number of the field containing the name
• A flag indicating if the verification operation is optional
If the rule is flagged as optional, no error will be generated during the linking operation if the
field containing the name is unspecified or contains an empty string.
For the final type of rule (verifying nonempty string values), the rule definition requires:
• The type code of the database containing the string field
• The number of the field containing the string
In this instance, no flag indicating if the rule is optional is needed, since an undefined or empty
string always indicates that the rule has been violated.
Each time a sequence step is linked, all the appropriate linking rules are automatically applied by
the linker to each of the database records that is referenced by the step. If the linking rules result in
additional records being referenced, all the appropriate linking rules are applied to the additional
records. This process is repeated until all the records referenced by the step, either directly or
indirectly, have their appropriate linking rules fully applied.
There is no limit on the depth to which a linking relationship can be chained. However, because of
the recursive nature of the linking rule tests, circular linking relationships are not permitted. That
is, it is invalid to define a linking rule that might result in a record already referenced by a series of
linking rules to be referenced a second time by that same series of rules.
103
Chapter 7 - Linking
Customizing the Linking Rules
All of the rules that drive the linker are accessible to system customizers. These rules may be
modified or augmented as needed. Due to the modular nature of AIM, the linking rules are
distributed among the initialization files for the various AIM software modules (that is, in the files
ROBMOD.OV2, VISMOD.OV2, etc.).
When a new rule is created, remember that the linker was primarily designed to provide early
feedback to the user regarding the validity of database entries, and to optimize the execution of
the runtime as it accesses the runtime databases. As such, the linker is primarily restricted to
operate only on opened runtime databases. For example, the following databases cannot be
referenced in a linking rule: nonruntime databases (Help, Menu, Error Message, and Statement)
and closed databases.
NOTE: The fixed, runtime databases are opened by calls to
ai.db.define( ) when the AIM system starts executing. Custom databases
should be loaded in the customizer’s initialization files. See
cu.define.dbs( ) for examples of how to load databases.
Routine for Defining Linking Rules
Each rule is defined by a single call to the V+ routine lk.define( ). This routine interprets and
screens the rule definitions and stores the rules in an internal format for use by the linker.
Depending upon the type of rule to be defined (database-to-database link, strategy routine
verification, or nonempty string verification), the parameters passed to lk.define( ) vary slightly
in their interpretation.
To add a new rule to AIM, simply add a new call to lk.define( ) within a user application overlay
routine or from the routine cu.initialize2( ) contained in the file CUSTOM.V2. The routine
cu.initialize2( ) is executed once each time AIM is started. Thus, any changes to the rules will take
effect only after AIM is restarted (and the linker is invoked). Each call to lk.define( ) defines a
single linking rule (of any type). The order in which the rules are defined is not important. See
lk.define( ) on page 383.
104
Linking
Linking Rule Example
Figure 7-1 shows the call to create an indirect linking relationship between the location database
and the frame database.
The routine call uses the following defined constants:
lc.ty = location database type number
mw.loc.frame = frame field in location database
mw.loc.frm.rec = linking field for reference frame in location database
fr.ty = frame database type number
cc.name = name field in frame database
In the case shown in Figure 7-1, the string “good.frame” is extracted from record 4 in the location
database, the frame database is searched for a matching record name, and the record number of
the matching record (#3) is stored in the linking field in the location database.
Location: Rec# 4
Name: loc.1
Ref Frame: good.frame
Frame Rec Num: 3
Strat Routine: e.z.pick
Frame: Rec# 3
Name: good.frame
X: 534.456
Y: 655.567
Z: 455.443
lk.define(lc.ty, mw.loc.frame, mw.loc.frm.rec, 0, fr.ty, cc.name, TRUE)
Figure 7-1
Indirect Referencing Link Rule
105
Chapter 8
Creating AIM Menu Pages
8.1
Introduction
This chapter describes using the menu editor to create your own menu pages, and to modify
existing pages.
The general classes of tasks that you can perform with the menu editor are:
• Create and delete files of menu pages. Menu pages are grouped into files.
• Create buttons that will call up other menu pages, spawn V+ routines, or execute sequences.
For example, a button on a menu page might call up the menu page that allows updating of
parts in the part database, and then a button in the part database menu page would return
the user to the calling menu page. An example of a routine spawn button would be a button
that updates the status of a part delivery system.
• Create information boxes and data boxes that access values in database fields, global V+
variables, keyword lists, or the ai.ctl[ ] arrays. Read only fields are displayed as an
information box. Read/write fields are displayed as data boxes. The AIM menu driver takes
care of selecting the correct display format. All V+ data types (except precision points) can be
accessed. User access levels can be specified to control which personnel have read or write
privileges. Routines can be specified to perform data validation on field entries.
• Create scroll bars and windows. Scroll bars change numeric database or ai.ctl[ ] values based
on the position of the scroll handle in the scroll bar. Scroll windows display the values of a
single field in a database, or text supplied by a user written routine. You can write user
routines that turn scroll windows into scrolling pick lists.
• Create conditional groups that control which menu items are displayed when a menu page is
drawn. The conditional statements are based on values found in specified database fields,
global V+ variables, or the ai.ctl[ ] arrays. Multiple conditional statements can be grouped
together so complex conditional statements can be created.
• Create graphics and text on the menu page. You can place informational text, graphical
panels, and icons on your menus. These items are referred to as static items and, like all menu
items, can be displayed under control of a conditional group.
The menu options and quick keys that are available during menu editing are summarized in
Appendix A.
107
Chapter 8 - Creating AIM Menu Pages
8.2
Control Values (ai.ctl[ ] Arrays)
AIM provides two arrays that can be used to store global values, or as temporary storage during
AIM execution. The array for numeric values is ai.ctl[ ]. The array for string values is $ai.ctl[ ]. The
following control values are reserved and should not be changed by system customizers:
Table 8-1
ai.ctl[ ] Reserved Ranges
Array Elements
Dedicated Use
ai.ctl[0] - ai.ctl[3]
reserved for the menu driver
reserved for system state variables
reserved for vision
reserved for backup/restore utility
ai.ctl[53]
reserved for V+ Developer
ai.ctl[54] - ai.ctl[111] and ai.ctl[128]
- ai.ctl[199]
reserved for future use by Adept
reserved for menu page scratch variables
reserved for operator control panels
Each array reserves the values from index 112 to 127 for use when an individual menu page is
displayed. Customizers can use these values but should assume the values are not usable once the
menu page has been closed.
Control values at indexes higher than 255 are available for customizers’ use. Since arrays are
dynamically allocated in V+, memory restrictions are the only constraint on the number of control
values available.
Global variables for the system state control indexes are initialized by the programs ai.cv.define( )
and ai.cs.define( ) in the PUBLIC.OV2 file. You can use these values in your custom programs, but
do not change their values.
If you alter a numeric control value from a user written program, the ai.ctl[ ] value should not be
changed directly but through a call to:
ai.set.ctl()
See Chapter 16 for the calling requirements.
The programs cu.cs.define( ) and cu.cv.define( ) in the file CUSTOM.V2 are called during AIM
initialization. You may edit these files (which have no Adept definitions) to define additional
control values and index variables.
108
Menu Page Files
8.3
Menu Page Files
Menu pages are stored in files, allowing you to isolate functional groups of menu pages into
individual files. A menu button can call any page in any file, as long as the files are in the same
sub-directory. To create a new menu page file:
Utilities ➡ Edit Menu (a menu page must be displayed)
File ➡ Create File
From the pop-up window that is displayed, enter a name for the menu file. File names must
follow Adept file name conventions. The default extension of a menu page file is .MNU.
Press Create to create the file.
To switch menu files while editing menus, perform:
File ➡ Switch Files ➡ enter file name ➡ Goto
To display a pick list of the menu pages in the current page file, along with the current file name:
Go ➡ Menu Pages
To create a new menu page in the current file, press the “New” key (F2) or:
File ➡ Create Page
When a menu page is first created, the “Page Header” menu item will be displayed for editing.
Section 8.8 details editing the page header.
There are two strong reasons for creating new files for any menu pages you create:
• Your menu pages will be isolated from Adept supplied files. If Adept (or other system
integrator) supplies a new menu page with a system upgrade, the new file can replace the
existing one without disturbing your custom files.
• Help files are keyed to menu page files, so your custom help files will also be isolated from
general system upgrades.
• If you create editing pages for new databases, these database can be automatically accessed
from the sequence editor if they are properly set up; the menu page file name should be the
same as the name of the .RFD for the database and the primary editing page should be named
“main”. The link between the menu page file and the database is made in the call to
ai.db.define( ).
The Sample Menu Page
A sample menu page is provided for you to “muck up” when you are first learning to use the
menu editor. It contains samples of different menu items and conditional sections. The sample
menu is displayed by selecting:
Special ➡ Sample Menu
109
8.4
The Primary Database
Menu items that display or allow updating of database fields need to know which database to
access. When databases are defined by ai.db.define( ), they are assigned a type code. The menu
pages and items use this type to determine which database to access. See Table 4-1 for the type
codes for databases in the baseline system. See the reference manuals for any additional modules
you may have for the standard type codes for those modules.
The database type a menu item accesses can be specified in four ways:
1. When a pull-down option is created to open a menu page, the default type for the menu page
and that menu page’s children1 can be specified. This is the preferred method as it requires
fewer changes if database types are altered, and eliminates confusion as to which database is
being accessed by child pages. It also allows you to use the same menu page to access
different databases (as long as the number and type of the database fields accessed by the
menu page are the same). The routine io.pul.dwn.spw( ) creates pull-down menu options.
See mw.mod.init( ) in MOWMOD.OVR/OV2 or vw.mod.init( ) in VWMOD.OVR/OV2 for
examples.
2. When a menu button calls another menu page, the button can specify a database type to use
as the primary database for the new page.
3. A primary database type can be specified in the page header of each menu page (see section
8.8). This database will override the default database.
4. Individual menu items can specify a database type to access. This option should be used
carefully and only when the other options are inappropriate. Its primary use is to display a
read only value from a database other than the one that is being actively edited.
Specifying Menu Page and Menu File Names in the Primary Database
If field 3 of the primary database is a string array field named “menu page name”, a menu button
can extract the menu page name and file from this field in the primary database. To use this field:
If the page name and the file name data boxes are blank; the menu page name will be
extracted from the first element of the string array field (if this element is blank, the page
name will be set to “main”), and the menu file name will be extracted from the second
element of the array.
If no record is open in the primary database, the page name and file name are read from the
default record for this database.
If the primary database does not contain a menu page name field, or the page name is blank,
it will be set to “main”.
1.
110
When a button on a menu page opens another menu page, that page is considered a
“child” of the page it was opened from. The child will “inherit” the default database number from its parent.
Entering and Exiting Menu Editing Mode
8.5
Entering and Exiting Menu Editing Mode
To enter menu editing from any non-protected menu page:
Utilities ➡ Edit Menu
As you complete menu editing tasks, you must close the menu item window (File ➡ Exit and
Save, click on the close icon, or press the “Exit” key [F4]). If you select a different window without
closing a menu-item editing window, the menu item window may be hidden behind the newly
selected window and AIM will behave as if it can no longer accept input. Before further input will
be accepted, you will have to redisplay the menu item window. The window can be redisplayed
by:
• Clicking on any visible part of the window, or if the window is completely hidden,
• Pulling down the menu under the adept logo and selecting the last window.
8.6
Moving and Sizing a Menu Item
1. Enter menu editing mode:
(Utilities ➡ Edit Menu).
2. Click anywhere on the desired menu item and drag it to a different location. The item label
will move with the item. Dragging with the right button instead of the left button will
constrain the menu item to move only vertically or horizontally.
3. Resize the item by clicking on the small box on the lower right corner of the item area and
dragging the box until the desired item size is reached.
4. Move the item label by first clicking on the menu item, then clicking on the label and
dragging it to the desired location.
5. Items can be moved and sized using the cursor keys (←, →, ↑, ↓). To move a menu item, click
anywhere in the item boundary and then use the cursor keys to move the item up, down, or
sideways. To move the item label, first click on the item and then click on the label. The cursor
movement keys will now move the label. To size an item, click on the item and then click on
the size box on the lower right corner of the item boundary. The cursor keys will now size the
menu item. To toggle between fine (two pixels) and coarse (four pixels) moves made using
the arrow keys:
Item ➡ Fine Moves
6. Whenever an item has been moved, only the outline of the item will be displayed at the new
location until the mouse button is released and another mouse click or key stroke is entered.
The Item Coordinates Window
When you use any of the menu page item creation screens described in the remainder of this
section, a window will display at the upper right corner of the screen. This window shows you the
location and size of the menu item you are editing. When you drag menu items around using the
mouse, this screen is dynamically updated so you always know the location and size of the menu
item you are working on.
The Selected Item
When an item is selected during menu editing, a red dotted line outlines the menu item. Menu
items can be selected by clicking on an unselected item, or by using the Tab and cursor keys (see
111
Appendix A). To select an item that is surrounded by another selected item, you must first deselect the item (click outside the item) and then click directly on the surrounded item.
8.7
Common Menu Item Features
When a menu item displays a field, global V+ variable, or ai.ctl[ ] value, the menu item will have
the following characteristics:
• The appearance of the menu item is taken care of by the AIM menu driver. Whenever the
user access level or conditional status dictates that a field be read only, it will be displayed as
an information box. Otherwise, it will be displayed as a data box.
• If a numeric value will not fit entirely within the menu item width, the menu item will be
filled with asterisks (∗). Strings and keywords that are longer than the menu item width will
be truncated to fit.
• For menu items that access a digital I/O signal number and display/update the status of that
I/O signal:
If the digital I/O hardware is not installed, the field will be filled with question marks (?).
If write access is specified for a digital input signal, the field will be filled with question
marks (?).
• Date/Time fields can be sized to display the date, the date and time without seconds, or the
date and time with seconds. Seconds will not be partially truncated and you cannot display
hours without minutes. If the menu item size will not allow at least the full date, the menu
item will be filled with asterisks (∗).
• Menu items that display values as yes/no, pass/fail, or on/off can be reduced to a single
character.
• If the field specified has not been defined, or there are no records in the database, or an
incorrect format is specified (e.g., a numeric menu item attempts to access a string field), the
field will be filled with question marks (?).
• Changes made to fields in memory resident databases are not saved to the disk copy of the
database until an explicit save is performed (Utilities ➡ Save all DBs), or AIM is properly
shut down (Special ➡ System Shutdown).1
Conditional Sections
All menu items can be made members of a conditional section. A conditional menu item evaluates
a Boolean statement. Based on the results of the evaluation, menu items that are members of the
conditional section will have their display status altered.
Three possible display states are:
• Displayed and active
• Displayed and inactive
• Hidden
Conditional sections are covered in section 8.14.
1.
112
Only databases that have the disk read/write option selected will be saved. See the
description of modules in the application user’s guides.
Common Menu Item Features
Help
AIM comes with a complete context sensitive help system. Every menu page and every menu item
(except conditionals) can have a help record associated with it. When you create a menu item, one
of the options will be a help search string. When a user selects a menu item and requests on-line
help, the search string will be extracted and the appropriate help database will be searched for a
record with the corresponding name. If a matching record is found, the help specified in that
record will be displayed. See section 8.17 for details on creating and modifying help records.
Redraw vs. Refresh
Two different types of updates are performed on the current menu page. A refresh updates any
numeric or string values that are tagged as ✔ Auto Refresh. Items with ✔ Auto Redraw will force
the reevaluation of all conditional sections, and draw all menu items with the correct status.
A special case of redraw/refresh exists for Digital I/O menu items. See section 8.16 for details.
The AIM Reference Manuals
Several options detailed in the rest of this chapter require you to know the structure of the
different AIM databases. This information can be found in the database sections of the manuals.
There are many places at which you can write custom code for the menu system. Adept provides
libraries of pre-written sub-routines that can be used to simplify your programming efforts. The
routine names and calling requirements are also listed in the reference manuals.
You should have a reference manual for the base AIM system, and a manual (or section of a
manual) for each application module your system has.
Fonts
See the Appendix on character sets in the V+ Language User’s Guide for details on the defined fonts.
To enter characters for fonts that do not have English keyboard equivalents (such as Katakana)
you need to find the English character with the same ASCII value and type that character.
To type characters in the extended character sets with ASCII values greater than 127, you must
first type the special key sequence Alt+Shift+! and then type the character that would make up the
difference between 128 and the extended character you want to display. For example, to display
the plus/minus symbol (±), type Alt+Shift+! and then “1” (which has an ASCII value of 49).
113
8.8
The Menu Page Header
Every menu page has a page header. This menu item sets the menu page title, initial position of
the menu, and page operation defaults. The page header menu item must be completed before
you can create any other menu items.
To create a new page and page header:
Utilities ➡ Edit Menu ➡ File ➡ Create Page ➡ enter page name
↵
➡ Create
To edit an existing page header, display the menu page you want to edit and:
Utilities ➡ Edit Menu ➡ Go ➡ Edit Page Header
➋
➊
➌
➍
➎
➏
➐
➑
➒
➓
Figure 8-1
Creating Menu Page Header
Page Header Options
➊
➋
➌
➍
114
Shows the name of the menu page you are editing.
Enter the Help search string associated with this menu page. See section 8.18.
Set the maximum size and initial position of the menu when it is first opened. The position
will be relative to the selection made in item ➎. Make sure the coordinates do not set the
menu page off the display screen. (If the page is displayed off the screen; press F5, select the
page header, and edit the location values.)
Indicate whether a title bar should be displayed, and what text should be in the title.
The Menu Page Header
Select ✔ Menu bar if you want a menu bar to be displayed on the menu page. The menu
bars that can be selected are (see mw.mod.int( ) in the file MOWMOD.OV2 for an example of
creating own menu bars):
0
1
2
3
4
5
➎
the record editing menu bar
the main menu bar
the menu bar displayed during menu page editing
the menu bar displayed in the sequence editor
the menu bar displayed in the vision window
the menu bar displayed with the database utilities
Under Window is child of, select
previous window to make the window position
relative to the last displayed window. Select
specified window to make the window
position relative to a specified window (a data box will be displayed requesting the name of a
window). When this page is displayed, it will be displayed relative to the location of the
named window.
The Position rel to options determine the relative point for the upper left-hand corner of the
window.
Press Center to calculate the coordinates of the window based on its size and the other
and
. Store the coordinates in item ➌.
specifications in
➍
➎
Press Cascade to calculate the coordinates of the window so that its upper left-hand corner
is a standard distance below and to the right of the parent window.
➏
Select ✔ Move cursor to button if you want the first button on the page highlighted when
the page is displayed. Normally the first selectable menu item is highlighted.
Select ✔ Flush type-ahead if you want all mouse clicks and key presses flushed from the
event buffer when the page is first displayed or redrawn.
➐
Enter the number of the database type that will be edited from this menu page. Enter 0 to use
the default database specified when the pull-down option calling this menu page (or its
parent) was called (see section 8.4).
Enter the refresh rate for this page. All auto-refresh items will be reevaluated and redrawn at
this rate (a value of 100 = one second).
➑
➒
➓
Select this option to allow operations from the “Edit” pull-down menu to be performed from
this page. If this option is not selected, you will not be able to create or delete records from
this menu page.
Enter a V+ routine to be run at various times when this page is active (see menu.pag.spawn( )
on page 474 for details). The Argument value will be passed to the indicated routine.
Select the color for the background of this menu page.
115
8.9
Creating Menu Buttons
Menu buttons can either cause another menu page to be displayed or initiate execution of a V+
routine or AIM sequence.
To create a new button, display the menu page you want to create a button for and:
Utilities ➡ Edit Menu ➡ New ➡ Menu Button or Spawn Rtn Button or Sequence Button
To edit an existing button, display the menu page the button is on and:
Utilities ➡ Edit Menu ➡ double click on button
➊
➌
➋
➍
➎
➓
➏
➐
➑
➒
Figure 8-2
Creating a Menu Button
Menu Button Options
➊
➋
➌
➍
➎
116
Select the font number for the label on the button.
Indicate the conditional section you want associated with this button. Conditional sections
are discussed in section 8.14.
The upper left corner of the button is specified in the first two boxes. The width and height of
the button are specified in the second two boxes.
Enter the help search string associated with this item. When this item is selected and the F1
key is pressed, the help database associated with the menu page file will be searched for a
record with this name. If a matching record is found, it will be displayed in the help window
(see section 8.17).
Enter the label you want to display with the button. In the “Relative position” data boxes,
enter the position for this label relative to the upper left corner of the button. Double click on
Creating Menu Buttons
Aa|Aa (next to Text color) to display a pop-up menu showing you the text and background
color options. If ✔ Opaque is selected, the label will look like the left “Aa”, otherwise it will
look like the right “Aa”.
➏
If
Menu Button is selected, the menu page specified in “Page” from the file specified in
“File” will be displayed. See section 8.14 for details on the primary database.
Spawn Rtn Button is selected, the routine entered into Routine will be executed when
If
the button is pressed. The argument specified in “Arg” will be passed to the routine (see
Table 8-2). See menu.but.spawn( ) on page 465 for details on creating subroutine spawns.
If a disk file name is specified in “File”, it will be treated as an overlay subroutine and the
disk file will be loaded before the program is called. The overlay file must follow the
convention of having a header program with the same name as the disk file. For example,
NEWPROG.OVR is the name of the header program for the disk file NEWPROG.OVR.
Sequence is selected, the sequence entered in Sequence and Module will be executed.
If
This must be a control sequence.
➐
➑
Depending on which option is selected in item ➏, these data boxes will request information
on the menu page to be displayed, the routine to be executed, or the sequence to be executed.
If ✔ Sequence idle is selected, this button will be disabled when any runtime task is
executing. (When this button is pressed during debug operation, a message indicating the
operation is illegal will be displayed.)
If ✔ Disable if remote is selected, this button will be disabled when a remote front panel is
enabled.
➒
Access level indicates the user access level required before this button will be active. See
MotionWare User’s Guide or VisionWare User’s Guide for details on assigning user access levels.
If ✔ Top Level is selected, the menu page displayed by this button will be a top level
window, all other windows will be closed before this window is displayed.
➓
If
Icon is selected, the icon specified in “Icon name” will be displayed at the coordinates
specified in item ➌. The icon name must be one of the standard Adept icons, or one you have
created using the EDITICON utility. Custom icons must be loaded to system memory before
they are usable. (See the Instructions for Adept Utility Programs for details on creating custom
icons. See the ai.load.icon( ) on page 301 for details on loading icon files.) The icon size is not
affected by the dx, dy values (item ➌). Icons are always displayed the same size as when
they were created. The dx dy values do determine the area of the screen where mouse clicks
will be interpreted as being aimed at the button.
If
Panel is selected, the “Icon name” data box will disappear and the button will be
displayed as the standard AIM menu button with the size and location specified in item ➌.
If
Transparent is selected, the button will be invisible. This allows you to generate your
own graphics for a button.
117
8.10 Accessing a Database, V+ Variable, or ai.ctl[ ] Numeric
Value
A number menu item allows displaying or updating of a database field value, V+ variable, or an
ai.ctl[ ] value.
To create a new number menu item, display the menu page you want to create a menu item for
and:
Utilities ➡ Edit Menu ➡ New ➡ Number
To edit an existing number, display the menu page the number menu item is on and:
Utilities ➡ Edit Menu ➡ double click on item to be edited
➊
➌
➋
➍
➒
➎
➏
➐
➓
➑
Figure 8-3
Accessing Numeric Values
118
Accessing a Database, V+ Variable, or ai.ctl[ ] Numeric Value
Numeric Value Options
➊
➋
➌
Select the font number for the label and the displayed value.
Indicate the conditional section you want associated with this item. Conditional sections are
discussed in section 8.14.
The upper left corner of the item is specified in the first two boxes. The width and height of
the item are specified in the second two boxes.
(see section 8.17).
➍
Enter the label you want to display with the field. In the “Relative position” data boxes, enter
the position for this label relative to the upper left corner of the field.
Double click on Aa|Aa (next to Text color) to display a pop-up menu showing you the text
and background color options. If ✔ Opaque is selected, the label will look like the left “Aa”,
otherwise it will look like the right “Aa”.
➎
If
DB value is specified, data boxes will be displayed requesting a database type number,
field number, and array index. This menu item will access a value in the specified database
and field. If the field is an array field, specify the array element to access. To access the
primary database, leave the database number blank.
If
V+ variable is selected, a databox requesting the name of a global V+ variable will be
displayed and this menu item will access the value of this variable.
If
ai.ctl[ ] value is selected, this menu item will access the value of the ai.ctl array cell
indicated in “ai.ctl index”.
➏
➐
The characteristics specified in this section are:
Sequence Idle
Indicates that this field will not be editable when a runtime task is
executing. (When this field is accessed during debug operation, a message
indicating the field cannot be changed will be displayed.)
Auto refresh
When selected, the display of this number will be updated at the rate
specified in the menu page header, or whenever any value is entered on this
page.
Auto redraw
When selected, conditionals will be evaluated and the page redrawn each
time this value is altered.
Required
When selected, the field accessed by this item will be a required field. (The
user will not be allowed to exit the menu page unless a valid entry is made.)
The characteristics specified in this section are:
Read access
Specify the required user access level before the value will be displayed.
Write access
Specify the required access level before the value can be modified.
Bit number
If a value other than 0 is entered, the field will be interpreted as a bit field
and the specified bit will be accessed. Bit 1 is the LSB.
119
Radio group
➑
Force this item to work in a radio group. Icons such as push buttons, radio
buttons, and check boxes are the items most commonly used with radio
groups. When one item from the group is selected, the value will be set to
the “On” value, and all other members of the group will set their values to
their “Off” values (item ➓). The “Input/Output Format” group on this
menu page is an example of a radio group.
In “Chk. Rtn”, specify a routine that will be run to perform data validation on the value
entered (see menu.chk.spawn( ) on page 467). The value in “Arg” will be passed to the “Chk
Rtn”.
If ✔ Check before display is selected, the check routine will also be run before the value is
displayed.
➒
This section specifies the formatting characteristics of the displayed value.
Icon On/Off
Icons such as “check_box”, “radio_button”, and “push_button” are used
primarily as icons with number menu items. These icons can be displayed
in different states depending on whether they are on or off. To define an
icon for use with this option, use an icon array with the first four elements
having the following meanings:
[0]
[1]
[2]
[3]
Off, not selected
Off, selected
On, not selected
On, selected
When an icon is on, the value will be set to the value in the first “On/Off”
value data box. When the icon is off, the value in the second data box will
be used.
Icon Array
When this option is selected, the specified value cannot be edited, it merely
specifies an index into an icon array. This gives you a simple way to display
different icons.
F format
When F format is selected, specify the justification, limits, and decimal
precision for a formatted decimal number.
D format
Specify the justification and limits for a number to be displayed in the
default decimal format.
Hexadecimal
Specify the justification and limits for a number to be displayed as a
hexadecimal value.
Integer
Specify the justification and limits for a number to be displayed after being
truncated to an integer.
Octal
Specify the justification and limits for a number to be displayed in octal
format.
The following characteristics are not shown in item 9. These can be displayed using the scroll
down arrow.
120
On/Off
The value will be displayed as On (any non-zero number) or Off (zero).
Yes/No
The value will be displayed as Yes (any non-zero number) or No (zero).
This menu item can be sized to display only Y or N.
Accessing a Database, V+ Variable, or ai.ctl[ ] Numeric Value
Pass/Fail
The value will be displayed as Pass (any non-zero number) or Fail (zero).
This menu item can be sized to display only T or F.
Keyword
The keyword and keyword list options work in conjunction with the
Keyword options described in section 5.4. When one of these options is
selected, data boxes for Keyword list and Idx will be displayed. These
values are taken from the values specified in the routine ai.key.new( ) that
sets up a new keyword list. For example, if you wanted to access the list
created with:
ai.key.new($my.keyword[2,])
you would specify “my.keyword” for the Keyword list and 2 for the Idx.1
➎
The actual numeric source specified in item
will contain the number of
the element in the keyword list as set up by ai.key.add( ). For example, if:
ai.ctl[ ] value is selected
ai.ctl[ ] index: = 200
ai.ctl[200] = 5
and you have added the following keywords:
ai.key.add($my.keyword[2,], "stuff", 5)
ai.key.add($my.keyword[2,], "junk", 6)
then “stuff” will be displayed as the keyword item. If “junk” is entered for
the item value, ai.ctl[200] will receive the value 6. If an undefined array
element is specified, question marks will be displayed.
The limits specify which elements will be considered. If 5 and 6 are entered
for the limits, only elements 5 and 6 may be displayed or specified.
Keyword list
As in a keyword, the Keyword list and Idx data boxes specify the source for
the keyword scrolling list. The numeric value source will contain the
number of the highlighted element. Clicking on an element in the list will
update the value of the numeric source to the number of the element. The
limits specify the limits of the elements that will be displayed in the
scrolling window.
Hor. Slide
If either of these options is selected, data boxes will be displayed asking you
to specify the upper and lower limits and the slide arrow increment value.
This menu item will create a slide bar that will alter the database field, V+
variable, or ai.ctl[ ] value. The value corresponds to the position of the
handle in the slide bar. However, the value will not be displayed. An
additional menu item must be created to display the value.
Ver. Slide
1.
If a one-dimensional array is used, leave the “Idx” data box blank.
121
8.11 Accessing a Database, V+ Variable, or $ai.ctl[ ] String Value
A string menu item allows displaying or updating of a database field value, V+ string variable, or
an $ai.ctl[ ] value.
To create a new string menu item, display the menu page you want to create a menu item for and:
Utilities ➡ Edit Menu ➡ New ➡ String
To edit an existing menu item, display the menu page the string menu item is on and:
Utilities ➡ Edit Menu ➡ double click on item to be edited
➊
➌
➋
➍
➒
➎
➏
➐
➓
➑
Figure 8-4
String Menu Item
122
Accessing a Database, V+ Variable, or $ai.ctl[ ] String Value
String Value Options
Items ➊, ➋, ➌, ➍, ➎,
the following exceptions:
➏, ➐, and ➑
are the same as for accessing numeric values, with
• When accessing a database, the field you access must be a string field.
• When accessing a V+ variable, you will be accessing a string variable.
• When accessing an ai.ctl[ ] value, you will be accessing the string array $ai.ctl[ ] instead of
the numeric array ai.ctl[ ].
➒
This section gives you the additional option of displaying a sequence name or a V+ program
name.
If
Standard is selected, the string value is simply displayed.
If
V+ Program is selected, the string is interpreted as a V+ program name. If a user doubleclicks on the string field, the V+ developer utility will be invoked to edit that program.
If
AIM Sequence is selected, the string is interpreted as an AIM sequence name within the
current module. If a user double-clicks on the string field when it is empty (or if the Display
function key is pressed), a pick list of sequences in the current module is displayed. If a user
double-clicks on the string field when it is not empty (or if the Goto function key is pressed),
the AIM sequence editor is invoked to edit the program.
If
Single keyword is selected, the string value entered must match one of the keywords in
a keyword list.
If
Keyword list is selected, a scrolling window of possible keyword strings from a
keyword list is displayed.
For keywords, the actual value of the selected keyword is used, not the index of the keyword.
➓
Specify the justification of the displayed string. If ✔ Opaque background is selected, the
background for the menu item will be gray. If ✔ Box value is selected, a black rectangle will
be drawn around the item.
123
8.12 Creating Static Items
Static menu items place graphical elements on a menu page. This section covers static text and
icons, the next section covers static panels. To create a new static text or icon, display the menu
page you want to create static text for, and:
Special ➡ Edit Menu ➡ New ➡ Static Text or Static Icon
To edit an existing static text or icon, display the menu page the static text is on, and:
Special ➡ Edit Menu ➡ dbl clk on item
➊
➌
➋
➍
➎
➐
➏
Figure 8-5
Creating Static Text or Icons
124
Creating Static Items
Static Item Options
➊
➋
➌
Select the font number for the label for this static item.
Indicate the conditional section you want associated with this static item. Conditional
sections are discussed in section 8.14.
The upper left corner of the static item is specified in the first two boxes. The width and
height of the static item are specified in the second two boxes.
(see section 8.17).
➍
Enter the label you want to display with the static item. In the “Relative position” data boxes,
enter the position for this label relative to the upper left corner of the static item.
and background color options. If ✔ Opaque is selected, the text will look like the left “Aa”,
For static icons:
Specify the icon name. The icon name must either be a standard Adept icon or a custom icon
you have created with the EDITICON utility and loaded with a call to ai.load.icon( ). If the
icons are stored in an array, specify the array index.
For static panels:
➎
➏
➐
For static panels and rectangles, specify the appearance of the panel.
In Rtn:, specify a routine that will be run when this item is displayed (see menu.pnl.spawn( )
on page 478). The value in “Arg” will be passed to the “Rtn”. When a routine name is entered
here, a V+ routine will be called that allows the customizer to take control of a section of the
menu page. The routine is notified of the size and position of the panel as well as all events
that take place within the panel, thus allowing the customizer to program this area as if it
were a window. “Arg” is passed to the panel routine.
Specify the colors of the item (displayed only when an appropriate item from ➎ is selected).
Menu Item Drawing Order
Menu items are drawn in the following order:
1. Starting with conditional section 0, all menu items in a single conditional section are drawn.
When two menu items overlap, the item in the higher conditional section will overlay the
item from the lower conditional section.
2. Within a single conditional section:
a. Static panels are drawn first. Multiple panels in a single section are drawn in the order
they were created.
b. The remaining items within the section are drawn in the order they were created.
3. When a button, scroll bar, data box, or scroll window is selected, it is brought to the front
until the next redraw is executed.
125
8.13 Accessing a Location or Date/Time Value
The screens for accessing transformations and date/time fields are similar. You simply have to
select the one that accesses the correct data type.
To create a new location or date/time menu item, display the menu page you want to create a
menu item for and:
Special ➡ Edit Menu ➡ New ➡ Transform or Date/Time
To edit an existing location or date/time menu item, display the page the menu item is on and:
Special ➡ Edit Menu ➡ double clk on item
➊
➌
➋
➍
➎
➐
➑
➏
Figure 8-6
Transformations and Date/Time Fields
Location and Date/Time Value Options
➊
➋
➌
Select the font number for the label on the location or value.
Indicate the conditional section you want associated with this location or value. Conditional
The upper left corner of the location or value is specified in the first two boxes. The width and
height of the location or value are specified in the second two boxes.
(see section 8.17).
126
Accessing a Location or Date/Time Value
➍
Enter the label you want to display with the location or value. In the “Relative position” data
boxes, enter the position for this label relative to the upper left corner of the location or value.
➎
➏
Date/time items must be from a database. Transformations can be from a database or a V+
variable. The other characteristics specified in this section are:
Sequence Idle
Indicates that this field will not be editable when a runtime task is
executing. (When this field is accessed during debug operation, a message
indicating the field cannot be changed will be displayed.).
Auto refresh
When selected, the value will be updated at the rate specified in the menu
page header.
Auto redraw
When selected, conditionals will be evaluated and the page redrawn each
time the value is changed.
Required
Selecting this item will make this a required field. (The user will not be
allowed to exit the menu page unless a valid entry is made.)
Read access:
Specify the required user access level before the value will be displayed.
Write access:
Specify the required access level before users can modify this field.
In Chk. Rtn:, specify a routine that will be run to perform data validation on the value
entered (see menu.chk.spawn( ) on page 467). The value in “Arg” will be passed to the “Chk
Rtn”.
If ✔ Check before display is selected, the check routine will also be run before the value is
displayed.
➐
➑
This is reserved for transformations only. Select
Standard to display the transformation in
Select Elements and a series of check boxes will be
standard XYZypr format. Select
displayed that allow you to select only the elements of the transformation that you want
displayed (for example, you may want to display only the XY values for a two axes linear
mechanism). You will be able to specify the number of digits displayed for the selected
elements.
This section specifies the formatting characteristics of the displayed value. Specify the
justification for the value, whether to use an opaque background, and whether to draw a
boundary around the value.
127
8.14 Creating a Conditional Section
Conditional groups determine whether menu items associated with the conditional group will be
displayed or active when the item’s menu page is drawn or redrawn.
To create a new conditional, display the menu page you want to create a conditional for and:
Special ➡ Edit Menu ➡ New ➡ Conditional
To edit an existing conditional, display the menu page you want to edit a conditional for and:
Special ➡ Edit Menu ➡ Go ➡ Edit Items ➡ highlight conditional to edit ➡ Edit
➊
➋
➌
➍
➐
➎
➏
➑
Figure 8-7
Creating a Conditional
128
Creating a Conditional Section
Menu Conditional Options
➊
➋
➌
➍
Shows the menu page this conditional is associated with.
Specify the number of this conditional group. Any menu items that specify this conditional
group will be displayed based on the state of this conditional.
Save yourself and those who come after you a lot of grief: enter a decent description of this
conditional.
Select
Evaluate condition to activate the evaluation criteria specified in item ➐.
Force condition ON to make the conditional section true regardless of the outcome
Select
of the evaluation criteria.
Select
Force condition OFF to set the conditional section false. The second two options are
used primarily for development.
➎
➏
The “Scope” group allows you to ‘nest’ conditional sections. The nesting is based on the
sequential ordering of the conditional sections. If conditional 1 is a primary section, and
conditional 2 is a secondary section, both sections 1 and 2 will have to evaluate to true before
section 2 would be true. If conditional 3 is a tertiary section, sections 1, 2, and 3 would have to
be true for section 3 to be true. If conditional 4 is a tertiary section, sections 1, 2, and 4 would
have to be true for section 4 to be true. If conditional 4 is a primary section, sections 1 and 2
will not affect sections 4 or higher.
Select
Numerical comparison if the condition is based on a numeric database field, global
V+ variable, or the ai.ctl[ ] array.
String comparison if the condition is based on a string (character) database field,
Select
global V+ string variable or the $ai.ctl[ ] array.
Select
V+ Routine response if you want a V+ routine called to evaluate the conditional.
If a database value is selected, you must specify the database number, field, and index.
If an ai.ctl[ ]/$ai.ctl[ ] value is specified you must specify the index.
If a V+ routine is selected, you must specify the name of the V+ routine and an argument to
pass to that routine. The calling sequence for a V+ conditional routine is described in Chapter
17 (see menu.cnd.spawn( ) on page 472).
➐
If a database, ai.ctl[ ], or V+ variable is selected, the conditional will compare the source value
with the value entered in “value”. The comparison will be made according to the selection
made under “ON if”. If the comparison is being made to a bit in a bit field, the bit to be
evaluated is specified in “Bit number” (LSB is bit 1).
If a V+ routine response is selected, the routine will return the state of the conditional section.
➑
If this option is selected, the menu items associated with this conditional group will not be
displayed when the conditional evaluates to false. If this option is not selected, the items will
be dimmed and will not be active when the conditional section evaluates to false.
129
8.15 Creating a Scrolling Window
A scrolling window creates a “pick list” that accesses the values in a single field of all the records
in a specified database, or displays lines of text provided by a user written V+ routine.
To create a new scrolling window, display the menu page you want to create a scrolling window
for and:
Special ➡ Edit Menu ➡ New ➡ Scrolling Window
To edit an existing scrolling window, display the menu page the scrolling window is on and:
Special ➡ Edit Menu➡ double click on scroll window
➊
➋
➌
➍
➎
➏
Figure 8-8
Scrolling Windows
130
Creating a Scrolling Window
Scrolling Windows Options
➊
➋
➌
Select the font number for the label on the scroll window.
Indicate the conditional section you want associated with this scroll window. Conditional
The upper left corner of the scroll window is specified in the first two boxes. The width and
height of the scroll window are specified in the second two boxes.
(see section 8.17).
➍
Enter the label you want to display with the scroll window. In the “Relative position” data
boxes, enter the position for this label relative to the upper left corner of the scroll window.
If ✔ Opaque is selected, the background of the label will be gray.
➎
The source for the scrolling window text can be a database or a V+ routine.
If
DB index is selected, enter the database type number (enter 0 to use the default primary
database), the field number to access in the database, and the array index (if any) within the
field. The field values of the records in the specified database will be displayed in the
scrolling window. When a line in the scrolling window is clicked, the V+ routine specified in
Routine: will execute. The number of the double clicked line will be passed to the routine.
If ✔ Sequence idle is selected, this scroll window will not be active during runtime task
execution.
Access level: specifies the user level required before this menu item will be active.
If ✔ Only show records with unique text is selected, multiple instances of the same value in
successive records will be suppressed.
V+ Routine is selected, enter a V+ routine to be run. The V+ routine must supply the
If
lines of text for the scrolling window, and indicate what should be done when a line is double
clicked on. The calling requirements for a scrolling window routine are described below.
Routine: specifies a V+ routine to run when an item in the “pick list” is double clicked on.
The value in “Arg” will be passed to that routine (see menu.scr.spawn( ) on page 480).
➏
Indicate whether you want a vertical slide bar on the scrolling window and whether you
want the selected item in the scrolling window to be highlighted.
131
V+ Scrolling Window Routines
The scrolling window routine performs the following functions:
1. When the scrolling window is first drawn, the menu driver calls the routine. The routine
should return the total number of lines of text that will be supplied.
2. When the scrolling window is first drawn, and each time the window is scrolled, the routine
should supply the lines of text. The routine will be called once for each line of text.
3. Each time a line of text is highlighted in the scrolling window, this routine will be notified of
the selected line.
4. When the user double clicks on a line of text, or a Go ➡ Goto menu selection is made, the
routine will be notified and should take appropriate action.
The calling sequence for the routine is detailed in Chapter 17 (see Table 8-2).
132
Accessing Digital I/O Signals
8.16 Accessing Digital I/O Signals
A digital I/O menu item displays the state of a digital input signal, and can display and/or set the
state of input and soft signals. The signal to be set or displayed is taken from a database field, an
ai.ctl[ ] value, or a signal number specified explicitly in the digital I/O item menu page.
Remember, when using the digital I/O menu item, you are not displaying or updating the value in
the database or ai.ctl[ ] value. The database field or ai.ctl[ ] value merely provides a signal
number. The menu driver gets the signal number, reads the state of that numbered signal, and
displays the signal state. If an output or soft signal is being accessed, the menu driver can change
the state of the signal.
The screen for creating a digital I/O menu item looks just like the number item menu page. The
one exception is that in addition to extracting the I/O signal number from a database field or
ai.ctl[ ] value, the I/O number can be explicitly specified. If an output or soft signal number is
specified, the state of the signal can be set by the menu item. The “radio_button” and
“push_button” icons are well suited for use with digital output and soft signals. Since input
signals cannot be set, menu items that read input signals must be read-only items. Menu items are
made read-only by setting their write access to a value greater than 4. See the controller user’s
guide for details on digital I/O.
For efficiency with auto-refresh values, the number of the digital signal is read from the database
only when the menu page is first drawn or redrawn. From then on, the specified digital signal will
be sampled as necessary to update its status. However, the signal number is not updated at the
refresh rate, so if the database field or ai.ctl[ ] index that provided the signal number is changed,
the menu page will not be notified until it is drawn or redrawn. For example, if ai.ctl[300] is
accessed and returns the number 2200, the digital I/O menu item will report the state of soft signal
2200. If an AIM routine executing concurrently with the displayed menu page changes the value
in ai.ctl[ ] to 2500, the menu driver will continue to display the state of signal 2200 until the menu
page is drawn or redrawn. The “Redraw” key (Shift+F6) forces a redraw of the menu page.
133
8.17 Custom On-line Help
Custom on-line help can be defined for any menu item on any page, and for any page in any menu
page file. The steps to creating help are:
1. When menu pages and items are created, enter a search string in the help data box of each
menu item. The search string for an entire page is specified in the page header.
2. Create a new help database with the same name as the menu page file, only with the
extension .HLP. For example, the help file for the menu page file ROBOT.MNU should be
ROBOT.HLP.
3. Use the search strings entered into the .MNU file as record names for records in the .HLP file.
When page help is requested (by pressing Shift+F1 or performing Help ➡ Page Information) the
following events occur:
1. The search string for the menu page is extracted from the page header.
2. AIM attempts to open a .HLP file with the same name as the current page’s .MNU file.
3. If the file is successfully opened, the name field in the .HLP file is searched for the extracted
string. If a help file does not exist or the search string is not located, the message “No help
available” is displayed.
4. If a matching record is found:
a. The menu page specified in the help record is displayed.
b. If the standard help page and file are specified, the text in the help file record is displayed.
Otherwise, the specified menu page from the specified file is displayed.
When field help is requested (by pressing the “Help” key [F2] or performing Help ➡ Field
Information) the following events occur:
1. The search string for the menu item is extracted.
2. AIM attempts to open a .HLP file with the same name as the current page’s .MNU file.
3. If the file is successfully opened, up to three searches are made:
The request is first handled by the menu item that was selected when help was requested. If
the menu item has a help search string, the help database is searched for a matching record
name.
If the menu item does not have a search string or the search fails, the request is handled by
any static panel that encloses the menu item. This allows you to create a single help record for
a “group” of menu items.
If the menu item is not part of a group (enclosed by a static panel), the static panel does not
specify a help search string, or the search fails, the request is handled by the menu page
header. If the menu page header does not specify a help search string or a matching record is
not found, a “no help available” message is displayed.
4. If a matching record is found:
a. The menu page specified in the help record is displayed.
b. If the standard help page and file are specified, the text in the help file record is displayed.
Otherwise, the specified menu page in the specified file is displayed.
134
Custom On-line Help
Related Topics
A help record can have “related topic” references. When a related topic is double clicked on, the
help database is searched for a record corresponding to the related topic. To create a relative
reference:
1. Make the first non-blank character on the line the character:
2. Follow the triangle with the descriptive text for the related topic.
3. Follow the descriptive text with the record name for the topic (the record name must be
surrounded by parenthesis and there must be no other parenthesis on the line).
For example, if the topic “Access level” was covered in the help record “usr.lvl”, the following line
would create a related reference:
Access level
(usr.lvl)
To enter the right facing triangle character, type Alt+Shift+! and then type Ctrl+G. (The ASCII
value of the triangle character is 135.)
135
8.18 The Help Menu Page
Before you can create a new help file, an existing help file must have already been opened. The
simplest way to make sure a help file is open is to display the sample menu page and press the F1
key. To create a new help file:
Special ➡ Edit Help File ➡ New File
Enter a file name that is the same as the file name of the menu page file (excluding the extension),
and press Create .
To edit an existing help file:
Special ➡ Edit Help File
If a help file is already open, it will be displayed. If a file is not open or you want to edit a different
file, press Switch . Enter the name of the help file to edit and press Goto .
➊
➋
➌
➍
➎
➏
➐
➑
➒
➓
Figure 8-9
Creating a Help Record
136
The Help Menu Page
Help Record Options
➊
➋
Shows the name of the help file you are editing. This name should match the name of the
menu file (excluding the extension) you are editing a help file for.
Shows the name of this record. This name should match the search string of the page or menu
item this help record is for.
The numbers indicate the number of this record and the total numbers of records in the
database. The date is the date of the last update to the database
➌
Help for a single topic can span more than one record (a single record can hold 15 strings of
50 characters). If more text is needed, create another record with the same name and place the
next higher number in this field. The standard_help page will display all help text without
interruption.
User parameter is provided for customizers and is not used by the standard AIM help page.
➍
Shows the menu page (and the menu file) that will displayed when this record is found to
match a help search string. The standard_help page in the help.mnu file is designed to work
with the help text. If you use a different page, you will have to write the routine to use the
help strings (or not use them at all).
The value entered into the Topic data box will be displayed at the top of the standard help
menu page. The topic will also appear in a pick list of help records that allows users to
randomly access the help database.
➎
➏
➐
➑
➒
➓
Enter up to 15 strings of 50 characters each. Clicking in this area will highlight a string to be
edited.
This is where the text for the help item is displayed.
Press this button to display the previous record in the database.
Press this button to create a new help file.
Press this button to switch help files.
Press this button to go to the next record in the database.
137
8.19 AIM Menu Page Routines
There are several points at which custom V+ routines can be automatically called by the menu
driver. These routines are summarized in Table 8-2. The first column indicates when the routine is
run and where it is specified. The second column lists the general functions the routine is intended
to perform. The third column lists the reference name used by the routine. Chapter 17 details the
parameter requirements of the routine.
Table 8-2
AIM Menu Page Routines
When called/where specified
Function
Reference name
When a new page is drawn,
updated, or closed. Routine
specified in the page header of a
menu page.
General housekeeping, set the preconditions for the window display
menu.pag.spawn
(page 474)
When a new value is entered into a
database field. Routine specified in
the menu item (number, string,
etc.). Optionally called before a
value is displayed or before a new
input is parsed.
Data validation, custom
formatting of output, custom
parsing of input
menu.chk.spawn
(page 467)
When a page is first displayed or
redrawn. Routine specified in the
conditional item.
Execute a more complicated
conditional evaluation than
possible with an AIM conditional
menu item
menu.cnd.spawn
(page 472)
When a routine spawn button is
pressed. Routine specified in the
button item.
Run a general purpose V+ program
menu.but.spawn
(page 465)
When a scrolling window is
displayed, or activity takes place
within the window. Routine
specified in the scrolling window
item.
Provide the text for a scrolling
window and monitor user input to
the scroll window
menu.scr.spawn
(page 480)
When a page is first drawn and
whenever events take place within
a static panel. Routine specified in
the static panel item.
Execute a V+ routine that takes
control of a section of a menu page
menu.pnl.spawn
(page 478)
138
Multiple Language Support
8.20 Multiple Language Support
You can add support for multiple languages to any menu page file. To add the language support
you must modify the menu database structure so the “label” field is an array field with the total
number of elements equal to the number of languages you want to support. You then add the
different language translations to the modified menu database and then set the language
initialization records to reflect the number and currently selected language.
To add support for additional languages:
1. Make a backup copy of the MENU.RFD file and then alter MENU.RFD to make the “Label”
field an array field. If you will use three languages, make the field an array field with 3
elements:
Utilities ➡ DBM Utilities ➡ enter “menu.rfd” ➡
change array size to 3 ➡ press F4
Goto ➡ dbl clk on field 11, “label” ➡
2. Convert any existing menu databases that require multiple language support to the new
record/field definition. For example, to convert the PATH.MNU file:
File ➡ Convert DB ➡ enter “path.mnu” ➡
Convert
3. Copy the existing Language Definition record in the initialization file and edit it to match the
new language. The language string defined here will be used in pick lists to select different
languages in menu editing. The array number must correspond the array element that you
intend to use for the specified language.
Special ➡ Edit Init Data ➡ dbl clk on baseini.db ➡ Seek ➡ Index ➡ dbl clk on “language
definition, English” ➡ press F9 ➡ press F10 ➡ enter a name for the new record and in the
“String Values” group the name of the language ➡ enter 2 for “Numeric Value” #A
4. Change the Language Selection record in the initialization file to correspond to the language
you want displayed.
Setup ➡ Initialization Data ➡ dbl clk on baseini.db ➡ Seek ➡ Index ➡ dbl clk on “language
selection ➡ enter 2 for “Value:”
5. Shut down AIM and then restart it.
When you enter menu editing, you will notice the following changes:
1. There will be a new pull-down menu (Language). The items under this pull-down menu
specify which element of the “Label” field will be displayed (the options in this list are
created from the Language Definition initialization records).
2. If the array element for the language you have selected is blank, the text in element 1
(normally English) will be displayed between brackets.
During normal operations you will see the following:
1. If the Language Selection record specifies an element that has not been defined for a
particular menu database, the first elements will be used. This allows you to change only the
menu databases you want displayed in multiple languages.
2. The menu page may redraw slightly slower since the records are larger. (Menu page files are
disk resident so there will be no adverse affects on RAM usage.)
139
8.21 Loading Icons
You can create your own icons using the Adept utility EDITICON.V2 (see the Instructions for Adept
Utility Programs). Icons are loaded during system initialization by a CALL to the routine
ai.load.icon( ) (see page 301).
Some points to remember about icons:
• If a menu item specifies an icon that is not loaded, a red question mark will be displayed as
the item’s icon.
• Icons are stored in files that should have the default extension .dat. Icons can be stored
individually within a file, or placed in arrays.
Array icons have a special meaning to menu buttons and to numbers displayed as icons. AIM uses
an array of icons to control the different states of buttons (on, off, selected). The array index that
will be displayed depends on the following conditions:
Condition
Index
button off, not selected
index[0]
button off, selected
index[1]
button on, not selected
index[2]
button on, selected
index[3]
“Radio_button” and “push_button” are examples of AIM buttons that use the four different states.
The state displayed is automatically selected by AIM. If you create this style of button, you should
follow the Adept convention of turning the background of a selected (highlighted) button blue.
140
Chapter 9
Menu Driver
Chapter 8 describes menu interface options that can be performed without custom programming.
The following advanced features of the menu driver are described in this chapter:
• How command and status information is passed between a V+ program and the menu driver.
• How the operation of menu pages can be augmented by the inclusion of special menu spawn
routines.
• How the menu driver can be initiated from a V+ program.
• How entries in the pull-down menus can be modified, and how new entries can be added.
Material in this chapter assumes you are familiar with creation and modification of AIM menu
pages (described in Chapter 8). Also, since most of the advance menu features require that V+
programs be modified or developed, this chapter assumes you are familiar with the V+
programming language.
9.1
I/O Communications Buffers
For uniformity, throughout the AIM user interface, a standard data format is employed to pass
input, command, and status information. That is, this data format, which is called an I/O
communications buffer, is used to represent the following:
• Key-press commands received from the operator.
• Commands generated as a result of selecting a pull-down menu item.
• Commands generated by spawn routines to pass new instructions back to the menu driver.
• Status information returned at the completion of the menu driver and other operatorinterface routines.
General Format
I/O communications buffers are implemented as V+ strings, the contents of which are organized
into a series of fields. The first fields contain (header) data that are stored in a fixed format (see
below). These fields define the destination system, source system, function, and qualifier. The
source and destination fields (which are currently unused) are for use during network operations.
The function code specifies that the buffer contains a user-interface message, and the qualifier
defines the type of message.
The header section is followed by a variable-format data section. The format of the data section is
a function of the type of message. For simple messages, the data section is unused. For more
complicated messages, the data section may contain any combination of numeric and text
information.
There are two general types of formats for I/O buffers: command, and status information. All
commands contain a positive value for the qualifier, and have a variable-format data section. All
status messages have a zero or negative qualifier, and contain a single variable-length text string in
141
Chapter 9 - Menu Driver
the data field. For error messages, the negative qualifier corresponds to a V+ or AIM error code,
and the text string contains an optional message that further defines the source or cause of the
error. A zero qualifier value for a status message indicates success.
The general format of the fields in an I/O buffer is described in Table 9-1. The first column of the
table lists the V+ variables that can be used to specify the offset to the start of each field. The
second column indicates the type of data stored in each field (for example, 16-bit integer number
[$INTB], 8-bit byte [$CHR], or ASCII text). The last column describes the contents of the fields.
Table 9-1
Format of I/O Communications Buffer
V+ Variable for
Field Offset
Data Type
Data Field Contents
io.hdr.dsa (1)
$INTB
Destination system address (normally 0)
io.hdr.did (3)
$CHR
Destination queue ID (normally 0)
io.hdr.ssa (4)
$INTB
Source system address (normally 0)
io.hdr.sid (6)
$CHR
Source queue ID (normally 0)
io.fun (7)
$INTB
Function code (1 for menu messages)
io.qal (9)
$INTB
Function qualifier
io.dat (11)
ASCII
Optional variable-format data section (maximum
length of 118 bytes)
As a convenience for defining I/O buffer values, the following string constants are defined by
AIM:
$io.cmd.hdr = $INTB(0)+$CHR(0)+$INTB(0)+$CHR(0)+$INTB(1)
$io.cmd.nop = $INTB(0)+$CHR(0)+$INTB(0)+$CHR(0)+$INTB(1)+$INTB(0)
In the following sections, each of the command messages is described, along with the format for
its variable-data field. For each command, the name of the V + variable (ky.∗) whose value
corresponds to the I/O buffer qualifier is presented, followed by a brief description of the
command. In certain instances, additional I/O buffer offset variables (io.∗) are defined to simplify
the creation and decoding of the I/O buffer data field.
Window Events
Table 9-2 lists the window events that are fielded by the menu driver and passed in I/O buffers.
Each of these commands corresponds to an input event that can be generated by V +. (These
commands are not normally generated by user routines.) You can refer to the V+ Operating System
Reference Guide for more information on the interpretation of these events and their parameters.
Table 9-2
I/O Buffer Qualifiers for Window Events
I/O Buffer Qualifier
Window Event
ky.but.down
Mouse button-down event
ky.but.up
Mouse button-up event
142
Table 9-2
I/O Buffer Qualifiers for Window Events (Continued)
Window Event
ky.dbl.clk
Mouse button double click
ky.but.move
Mouse move with button down
ky.win.sel
Window selected
ky.win.nsel
Window deselected
ky.sld.str
Slide-bar start event
ky.sld.mve
Slide-bar move event
ky.sld.end
Slide-bar up event
ky.pull.down
Pull-down menu event
ky.cls.win
Window-closed event
For the commands listed in Table 9-2, the data field of the I/O buffer contains the parameters
returned by the V+ GETEVENT instruction. These parameters are formatted as shown in Table 9-3.
Table 9-3
Format of I/O Buffer Data Field for Window Events
V+ Variable for
Field Offset
Data Type
Data Field Contents
io.int1 (11)
$INTB
Window event: first integer argument
io.int2 (13)
$INTB
Window event: second integer argument
io.int3 (15)
$INTB
Window event: third integer argument
Menu Commands Without Parameters
The commands listed in Table 9-4 do not utilize the variable data field of the I/O buffer. In general,
these commands can be generated from any source.
Table 9-4
I/O Buffer Qualifiers for Menu Commands Without Parameters
Action of Menu Driver
ky.right
Move cursor right in field
ky.left
Move cursor left in field
ky.up
Move cursor up in field
ky.down
Move cursor down in field
ky.f.right
Move right to next active field
ky.f.left
Move left to next active field
143
Table 9-4
I/O Buffer Qualifiers for Menu Commands Without Parameters (Continued)
ky.f.up
Move up to next active field
ky.f.down
Move down to next active field
ky.tab
Move to next active field
ky.b.tab
Move to previous active field
ky.previous
Go to previous record of primary database
ky.next
Go to next record of primary database
ky.first
Go to first record of primary database
ky.last
Go to last record of primary database
ky.undo
Undo changes to field
ky.insert
Insert a new line
ky.delete
Delete a character
ky.delete.l
Delete a line or field
ky.search
Initiate search operation
ky.change
Initiate change operation
ky.repeat
Repeat last search operation
ky.s.repeat
Repeat last change operation
ky.new
Create a new record
ky.copy.rec
Copy displayed record
ky.cut.rec
Cut displayed record
ky.paste.rec
Paste record
ky.paste.all
Paste all records
ky.goto
Display database record pointed to by field
ky.back
Return to previous database
ky.retrieve
Return record name to previous record
ky.display
Display index of possible record names
ky.index
Display record index of the current database
ky.teach
Initiate teaching of field value
ky.redraw
Redraw current menu page
ky.refresh
Update all auto-refresh fields
ky.exit
Exit current menu
144
Table 9-4
I/O Buffer Qualifiers for Menu Commands Without Parameters (Continued)
ky.exit.2
ky.exit.3
ky.exit.4
ky.no
ky.do.it
ky.okay
ky.yes
These commands, which are all interpreted the same as
“ky.exit” by the menu driver, are used to distinguish
between different exit conditions.
ky.s.exit
Exit all nested menus
ky.help
Display help for current field
ky.s.help
Display help for current page
ky.save
Save all changed database values
ky.halt
Halt current operation
ky.shutdown
Shutdown AIM system
Commands for Displaying a Menu Page
The commands listed in Table 9-5 display a new menu page. Although these commands can be
returned by a button spawn routine to initiate the display of a new menu, displaying a menu page
is normally performed by directly executing the menu driver from the spawn routine. These
command formats are utilized by the pull-down menus to invoke menu display commands.
Table 9-5
I/O Buffer Qualifiers for Menu Commands to Display Menu Pages
ky.menu
Create a new window whose parent is the window currently
displayed, and display the specified menu page in the new
window. When the new menu page terminates execution,
control returns to the menu page previously displayed.
ky.m.menu
Perform the equivalent of SHIFT + EXIT (SHIFT+F4): terminate
processing of any current menus, create a new window, and
display the contents of the menu page in the new “main”
window.
For the commands listed in Table 9-5, the data section of the I/O buffer contains the information
listed in Table 9-6.
145
Table 9-6
Format of I/O Buffer Data Field for Page-Display Commands
V+ Variable for
Field Offset
Data
Type
io.ms.mode
$CHR
Data Field Contents
Mode of operation. All modes perform the basic
operation of displaying a specified menu page. In
addition, the mode indicates that one of the following
actions is to be taken:
MODE INTERPRETATION
0
This is the standard menu command.
1
This menu command is generated as a result of
a GOTO command. When the menu driver
receives this command, it saves away
information so that a subsequent BACK or
RETRIEVE command can return to the menu
page that generated the GOTO.
2
This command is generated by the menu driver
when it receives a BACK command and the
previous operation was a GOTO menu
operation. The menu driver generates this
command to restart execution of the menu page
that processed the GOTO.
3
This command is generated by the menu driver
when it receives a RETRIEVE command and the
previous operation was a GOTO menu
operation. The menu driver generates this
command to restart execution of the menu page
that processed the GOTO and to pass back the
name of the record that was RETRIEVED.
4
This is like mode 1 except a new record is
created.
io.ms.name
ASCII
15-character string that specifies the name of the menu
page to be displayed. If the name is shorter than 15
characters, it must be padded with trailing NUL [i.e.,
$CHR(0)] characters.
io.ms.file
ASCII
12-character string that specifies the name of the menu
file that contains the required menu page. If the name
has less than 15 characters, it must be padded with
trailing NUL characters.
io.ms.db.ty
$INTB
Type of the primary database associated with the menu
page. If <0, the absolute value is the type of a global
database.
io.ms.rec
$INTB
Number of the first record of the primary database to be
displayed, or 0 if the record currently opened is to be
displayed.
146
Table 9-6
Format of I/O Buffer Data Field for Page-Display Commands (Continued)
V+ Variable for
Field Offset
Data
Type
io.ms.acc
$CHR
Required user access level for displaying the menu page
(0 to 7).
io.ms.norun
$CHR
Non-zero if the menu page cannot be displayed while a
sequence if running.
io.ms.r.ty
$CHR
For mode 1, 2, 3, or 4: Type of the database that contains
the value to be filled in if a RETRIEVE is performed. If <0,
the absolute value is the type of a global database.
io.ms.r.rec
$INTB
For mode 1, 2, 3, or 4: Number of the record that contains
the value to be filled in if a RETRIEVE is performed.
io.ms.r.fld
$CHR
For mode 1, 2, 3, or 4: Number of the field to be filled in
by the RETRIEVE operation.
io.ms.r.idx
$CHR
For mode 1, 2, 3, or 4: Number of the index of the field to
be filled in by RETRIEVE.
io.ms.r.val
ASCII
For mode 3: 15-character string that contains the name of
the record that is being RETRIEVED. If the name is
shorter than 15 characters, it must be padded with
Data Field Contents
Commands for Executing a Spawn Routine
The commands listed in Table 9-7 execute a user spawn routine. These commands are generated
almost exclusively by the pull-down menu routines.
Table 9-7
I/O Buffer Qualifiers for Menu Commands to Execute Spawn Routines / Sequences
ky.spawn
Suspend execution of the current menu page and execute the
specified spawn routine. When the spawn routine terminates
execution, control returns to the suspended menu page (subject
to any new command returned by the spawn routine).
ky.m.spawn
processing of any current menus, and then begin execution of
the specified “main” spawn routine.
ky.seq
Suspend execution of the current menu page and call a control
sequence. When the control sequence terminates execution,
control returns to the suspended menu page.
ky.m.seq
processing of any current menus, and then begin execution of
the specified “main” control sequence.
147
For the commands listed in Table 9-7, the data section of the I/O buffer contains the information
listed in Table 9-8.
Table 9-8
Format of I/O Buffer Data Field for Spawn Commands
V+ Variable for
Field Offset
Data
Type
io.ms.mode
$CHR
Mode of operation. All modes perform the basic
operation of executing a specified spawn routine. In
addition, the mode indicates that one of the following
actions is to be taken:
MODE INTERPRETATION
0
This is the standard menu command.
1
This spawn command is generated as a result
of a GOTO command. When the menu driver
receives this command, it saves information so
that a subsequent BACK or RETRIEVE
command can return to the menu page that
generated the GOTO.
2
This command is generated by the menu
driver when it receives a BACK command and
the previous operation was a GOTO. The menu
driver generates this command to restart
execution of the spawn routine that processed
the GOTO.
3
This command is generated by the menu
driver when it receives a RETRIEVE command
and the previous operation was a GOTO. The
menu driver generates this command to
restart execution of the spawn routine that
processed the GOTO and to pass back the
name of the record that was RETRIEVED.
4
This is like mode 1 except a new record is
created.
io.ms.name
ASCII
15-character string that specifies the name of the V+
routine or sequence to be executed. If the name is
trailing NUL [i.e., $CHR(0)] characters.
io.ms.file
ASCII
12-character string that contains the optional name of
an “overlay” file or resource module that contains the
spawn routine. The overlay file or resource module is
automatically loaded into memory (if required), before
the spawn routine is executed. The overlay file or
resource module will be deleted from memory when
the memory space is later required by another spawn
routine. If the name is shorter than 15 characters, it
must be padded with trailing NUL characters.
io.ms.db.p
$INTB
Type of the primary database that is passed to the
spawn routine. If <0, the absolute value is the type of a
global database.
148
Data Field Contents
Menu Spawn Routines
Table 9-8
Format of I/O Buffer Data Field for Spawn Commands (Continued)
V+ Variable for
Field Offset
Data
Type
io.ms.rec
$INTB
Value of the “spawn routine argument” that is passed
to the spawn routine.
io.ms.acc
$CHR
Required user access level for displaying the menu
page (0 to 7).
io.ms.norun
$CHR
Nonzero if the menu page cannot be displayed while a
sequence if running.
io.ms.r.ty
$CHR
For mode 1, 2, 3, or 4: Type of the database that contains
the value to be filled in if a RETRIEVE is performed. If
<0, the absolute value is the type of a global database.
io.ms.r.rec
$INTB
For mode 1, 2,3, or 4: Number of the record that
contains the value to be filled in if a RETRIEVE is
performed.
io.ms.r.fld
$CHR
For mode 1, 2, 3, or 4: Number of the field to be filled in
by the RETRIEVE operation.
io.ms.r.idx
$CHR
For mode 1, 2, 3, or 4: Number of the index of the field
to be filled in by RETRIEVE.
io.ms.r.val
ASCII
For mode 3: 15-character string that contains the name
of the record that is being RETRIEVED. If the name is
9.2
Data Field Contents
Menu Spawn Routines
As mentioned previously, many menu pages can be developed utilizing only the interactive
menu-editing facilities provided with AIM. However, for complicated operator-interface
functions, specialized V+ programs must be developed and integrated with the menu pages. The
operation of these V+ “menu spawn routines” is described in this section.
There are six types of menu spawn routines. Each type of spawn routine conforms to a calling
sequence established by the menu driver. In an AIM system, there can be many or no V+ programs
for a given type of menu spawn routine. Spawn routines are associated with specific menu pages
and menu items by specifying the name of the spawn routine in a menu-page field (see Chapter
17).
The six types of spawn routines are summarized briefly below. (The names in parentheses are the
corresponding routine names used in Chapter 17.)
1. Button Spawn Routine (menu.but.spawn)
This type of routine is called when a menu spawn-routine button is activated.
2. Value-Check Spawn Routine (menu.chk.spawn)
This type of routine is called to verify that the value of a data field can be modified, or it is
called to perform custom formatting.
149
3. Conditional-Record Spawn Routine (menu.cnd.spawn)
This type of routine is called when the menu driver processes a conditional record, the state
of which is a function of a menu spawn routine.
4. Page Spawn Routine (menu.pag.spawn)
This type of routine is called when a menu page is drawn, and when various page or record
operations are performed.
5. Panel Spawn Routine (menu.pnl.spawn)
This type of routine is called when a rectangle or panel is drawn, and when a mouse event is
detected within a rectangle or panel.
6. Scrolling-Text-Window Spawn Routine (menu.scr.spawn)
This type of routine is called to generate the text for, and to respond to events for, a scrollingtext-window menu item.
In the following sections, the intended uses of the menu spawn routines are described in greater
detail. Refer to Chapter 17 for descriptions of the calling sequences for all the types of menu
spawn routines.
NOTE: When a spawn routine needs to access the menu window, it can
do so by directing its read and write operations to logical unit number
io.lun. However, user routines should never alter which window is open
on this logical unit (that is, such routines should never perform FCLOSE
or FOPEN operations on this logical unit). Furthermore, user routines
should never access the logical unit (io.lun2) used by the menu driver for
the main menu window.
Button Spawn Routine
This type of spawn routine is called by the menu driver when the operator activates a menu
spawn-routine button. These spawn routines can be utilized to implement special functions that
are not supported by the menu driver.
The other types of spawn routines are expected to execute very quickly and immediately return
control to the menu driver. However, button spawn routines can assume complete control of the
user interface for whatever period of time is required.
A button spawn routine, occasionally, will perform a simple function without generating output
to the operator and quickly return control to the menu driver. For instance, a button can be used to
transmit a short message or to signal an external device. At other times, these spawn routines
provide a means for major software packages to take over full control of the operator interface. In
this situation, a button spawn routine will often recursively call the menu driver to display menu
pages that serve as its operator interface (see the next section for how to invoke the menu driver).
For example, a spawn routine may execute the menu driver to display a menu page that contains a
data entry field and a “Go” button.
When a spawn routine exits, it may return an error condition or the next menu command to be
executed.
Value-Check Spawn Routine
This type of spawn routine is associated with a data field that allows write access to a database
value, a global control value, or a digital output signal. This type of routine can be used to perform
150
Menu Spawn Routines
special value checking, or to initiate some secondary action associated with changing the value or
signal.
For example, the output value of a digital-to-analog converter (DAC) could be controlled by
storing the DAC value in an ai.ctl[ ] control variable and having a check routine transmit the new
value over a serial line each time the ai.ctl[ ] variable is changed.
This type of spawn routine is called whenever the associated data field is selected and a doubleclick event, a GOTO (F3) key press, or a display-selection key press is received. This allows the
spawn routine to intercept the event and perform an alternate operation if desired.
If ✔ Check before display is specified on the field definition page, the value check routine is
called at two additional times:
• Before the item is displayed, this routine is called in mode 3 to allow it to generate a custom
output string based upon the new output data. This custom string is displayed instead of the
normal output string.
• Immediately after a new value is entered into the field, this routine is called in mode 2 and
passed the unprocessed input string. The routine may replace this string with a different
string which is then passed to the normal input parser.
Conditional-Record Spawn Routine
This type of spawn routine is called by the menu driver when a conditional menu record is
encountered, the state of which is dependent upon the result returned by a spawn routine. This
type of spawn routine can be utilized to evaluate conditional display requirements that are more
complicated than the simple equality tests that the menu driver can perform automatically.
Page Spawn Routine
This type of routine is specified in the header record for a menu page and is called in response to
actions that apply to the entire menu page. Specifically, this spawn routine is called under the
following circumstances:
1. Just before the page is fully drawn or redrawn.
This mode can be used to initialize values that are referenced by the menu page, or to save
temporary values that may be altered by the menu page.
2. Just before the auto-refresh values of the page are updated.
This allows the spawn routine to perform any required periodic or polled operations. The
spawn routine can modify values that are auto-refreshed, or it can issue a new menu
command based upon sampled information.
3. If input is received on an auxiliary logical unit.
This feature of the spawn routine allows you to specify additional graphic-window or serialline input sources that are to be monitored by the menu driver. Whenever data is received on
one of the auxiliary logical units, the page routine is called. For example, this facility is
utilized in the vision module to detect mouse clicks in the vision window while editing the
Vision database menu page.
NOTE: The menu driver utilizes logical unit 20 (io.lun) for all of its
window operations and logical unit 21 (io.lun2) for the main pull-down
window. Therefore, these logical units should never be specified as
auxiliary logical units.
151
4. Just before a record operation is to be performed (for example, delete record, create record,
next record, etc.).
This allows the page routine to intercept all commands that will affect the displayed record,
and to alter the interpretation of the command. For example, selected operations can be
inhibited, and other operations can be changed to perform functions specific to the database
being displayed.
5. Just before and just after a child menu page is displayed, or a spawn routine is executed.
This allows the page routine to suspend any operations while control is temporarily passed
to another menu page or button spawn routine.
6. When processing of the menu page is being terminated.
This allows the spawn routine to perform any required clean-up or restoring operations.
Panel Spawn Routine
This type of spawn routine is associated with a menu record that draws a panel (or a rectangle). It
permits application software to detect where a panel (or rectangle) is positioned and sized, and to
intercept all mouse events that occur within the panel (or rectangle).
By detecting the location and size of a panel (or rectangle), application software that directly
draws to the screen can make use of the interactive AIM menu editor to position the drawing. In
more sophisticated applications, this feature can be employed to create custom interactive panels
within a standard menu page. For example, the statement tree-drawing facilities in AIM use this
mechanism to position the tree and detect when elements of the tree are clicked on.
Scrolling-Text-Window Spawn Routine
This type of spawn routine is called by the menu driver in connection with a scrolling-textwindow menu record. This feature allows scrolling-text windows to display arbitrary lines of text.
This spawn routine is called to produce the text lines and respond to selection, double-click, GOTO
(F3), and display events. This feature allows applications to easily display lists of items, while
leaving to the menu driver the tasks of creating the display, scrolling, and highlighting.
9.3
Executing The Menu Driver
When a menu spawn routine is executed by the menu driver, it is often necessary for the spawn
routine to output information to the operator, and to receive responses. While it is possible to
write V+ programs for this purpose, it is more convenient and consistent for spawn routines to
execute the menu driver to perform the required communication.
To assist in these situations, the following V+ routines are provided. (For detailed descriptions of
these routines, please refer to the dictionary pages in Chapter 16.)
mu.menu( )
This routine displays and processes a menu page in a specified menu file.
The menu page is executed in the same manner as a menu page invoked by
a menu-page button. There are no special restrictions on the menu page,
and the menu page can invoke other menu pages and spawn routines.
At the completion of the menu page, the termination command is returned to the calling program.
This termination command normally contains the qualifier ky.exit. However, other commands are
possible—that is, different termination conditions can be indicated.
152
Pull-Down Menus
As an example, the following sequence of V+ instructions can be executed to display the standard
prompting window “Are you sure?”.
CALL mu.menu("are_you_sure", "system.mnu", 0, $cmd)
answer = INTB($cmd, io.qal)
;Extract response
IF answer == ky.exit GOTO 90
;Cancelled, return NOP
IF answer <> ky.yes GOTO 100
;Unexpected response
:
;Confirmed
mu.popup.error( ) This routine displays an error message using the standard system errormessage pop-up window. Information defining the error message is
passed to this routine in an I/O buffer. Both the error message
corresponding to the error code and the optional text message contained
in the data section of the I/O buffer are displayed.
io.working( )
This routine creates a small window and displays a message (such as
“Working...”) to indicate that the system is busy performing some
operation. This routine is also used to delete a window created by a
previous call of this routine.
These routines can be executed recursively any number of times, subject to available stack space.
However, these routines can be executed only in those V+ tasks that are configured for the menu
driver. Normally, only task 3 and 6 are configured to execute these routines.
9.4
Pull-Down Menus
Within AIM, pull-down menus are able to produce the same effect as activating a menu button,
activating a spawn routine button, generating a window event, or pressing a key on the keyboard.
Pull-down menus are created by defining a set of data that describes all the menu entries. All the
entries in the pull-down menus must be generated when the AIM system is initialized, but the
data definitions can be distributed among different modules. The standard pull-down menu
definitions can be found in the file BASMOD.OV2, and in the module overlay files (for example,
ROBMOD.OV2, VISMOD.OV2, etc.).
The standard pull-down menus can be modified for different languages by changing the text for
the list titles and the list-entry labels. In addition, new pull-down lists and list entries can be added
as required.
When a new list is added to a pull-down menu bar, it will appear to the right of any previously
defined lists when the menu is displayed. When a new entry is added to a list, it will be placed
below the latest entry added.
Pull-down menus are organized by menu bar number, list title, and list entry.
The following information is associated with each pull-down entry:
• The menu bar number (0 to n) with which the entry is associated
• The title of the list with which the entry is associated
• The text to be used for the entry label
• The operation that is to be generated when the entry is selected
• The user access level required to activate the entry
• A flag indicating whether or not the entry can be activated when a sequence is running
153
• An (optional) index to a series of pull-down menus flags words associated with the entry
The pull-down menu flags words, and thus, provides a mechanism that allows V+ application
programs to dynamically modify some of the attributes of selected pull-down entries. Each time a
pull-down entry is displayed, the menu driver verifies that the entry has an associated flag word.
If so, the flag word is referenced, and any special processing indicated by the value of the flags
word is performed. Currently, flag words can be used to dynamically control whether or not an
associated entry is forced to be unselectable and whether or not its label should be preceded by a
check mark.
To allow pull-down menus to be utilized simultaneously by multiple tasks, a different set of flag
words is maintained for each menu and each task. If a new pull-down menu entry is created that
requires a new flag word to control its special attributes, any unused flag words can be utilized.
(For more information on flags words, see the dictionary page in Chapter 16 for the routine
io.pul.dwn.sfg( ).)
The following routines are provided to simplify the creation and control of pull-down menu
entries:
io.pul.dwn.spw( ) This routine adds a new entry to a pull-down menu list. When the entry is
selected, it displays a menu page or executes a spawn routine.
io.pul.dwn.evt( )
This routine adds a new entry to a pull-down menu list. When the entry is
selected, it is equivalent to a key-press or window-input event.
io.pul.dwn.sfg ( ) This routine sets flags-word values used to control special features of
pull-down entries.
For detailed descriptions of these routines, please refer to the respective dictionary pages in
Chapter 16.
io.pul.dwn.spw( ) and io.pul.dwn.evt( ) specify a text string to use for the top-level option and a
text string to use for the individual pull-down selection. Pull-down menu options are added in the
following way:
If the top-level text string has not been used for the current window, a new top-level option is
added to the right of any existing options and the pull-down selection is made the first
option.
If the top-level text string has already been used, the pull-down selection is added to the
bottom of the existing options.
Additional parameters to the pull-down menu item routines allow you to:
• Specify the default primary database type to be used with a displayed menu page.
• Specify a record number to be opened when a menu page is displayed.
• Specify a user access level for the option.
• Control the appearance of the option. For example, the option can be dimmed or a check
mark can be specified for the option.
• Place the menu option in a standard menu bar (see below).
154
Menu Driver Application Notes
9.5
I/O Communications Buffer Format
The I/O Communications Buffers are implemented as V+ strings, the contents of which are
organized into a series of data fields. As noted, the fields are broken down to header data and
variable data. The header data is stored in a fixed format, which contains essentially system
addressing, and function codes (see Table 9-1).
The format of the data section is a function of the type of message or command that the menu
driver is supposed to interpret. For simple status messages, the variable data fields are unused,
however for complex commands, the data section may contain a combination of numeric and text
information.
There are two general types of formats for the I/O buffers: command and status information. All
commands contain a positive value for the “qualifier” field, and make use of the variable data
section. All messages contain a zero or negative “qualifier” field and contain one variable length
text string in the data field. By extracting the numeric code in the “qualifier field” the menu driver
can determine if the remaining data in the buffer refers to a message or a command.
The general format of the fields in an I/O buffer is described in Table 9-1. The first column of the
table lists the V+ variables that can be used to specify the offset to the start of each field. The
second column specifies the type of data stored in each field, and the last column describes the
contents of the fields. NOTE: $INTB( ) data types are 16 bit integer numbers, and $CHR( ) data types
are 8 bit bytes. The number in parenthesis next to each V+ Variable name in Table 1, represents the
byte number at which the data specified begins.
Dest.
System
Address
1 2
Dest. Source
Queue System
ID
Address
3
4 5
Source
Queue Function
Code
ID
6
7 8
Function
Qualifier
9 10
ASCII Data Section
11
129
Each block represents 1 byte of data.
Figure 9-1
I/O Buffer Layout
Figure 9-1 illustrates the layout of the fields in the buffer. Each block represents 1 byte of data.
The fields that contain $INTB( ) data types, for example, take up two bytes in the buffer, since the
$INTB( ) function returns a 2-byte string containing the binary representation of a 16 bit integer.
The I/O communications buffer is built using V+ string commands keeping in mind the data type
for each field. For example, as a convenience for defining I/O buffer values, there are two string
constants that are defined in AIM: $io.cmd.hdr and $io.cmd.nop.
The string $io.cmd.hdr stands for “I/O Command Header”. It is a standard string that defines all
the necessary header information for the menu driver. It is built using the standard V+ string
commands in the following manner:
$io.cmd.hdr = $INTB(0) + $CHR(0) + $INTB(0) + $CHR(0) + $INTB(1)
which translates to:
$io.cmd.hdr = "Destination System Address" + "Destination queue
ID"+"Source System Address" + " Source Queue ID" + "Function Code"
155
In Table 9-1, notice that the numeric values for the $INTB( ) and $CHR( ) functions in the
$io.cmd.hdr definition above correspond to the values described in the Description portion of the
table. This HEADER string MUST be included in ALL command and message strings passed to the
menu driver!
Similarly, the string $io.cmd.nop, which stands for “I/O Command No Operation”, is constructed
in the same fashion:
$io.cmd.nop = $INTB(0) + $CHR(0) + $INTB(0) + $CHR(0) + $INTB(1) +
$INTB(0)
which translates to:
$io.cmd.hdr = "Destination System Address" + "Destination queue
ID"+"Source System Address" + " Source Queue ID" + "Function Code" +
"Function Qualifier"
This string is a special string, in that since the function qualifier field is equal to zero, it informs the
menu driver to do nothing, or “perform no operation”. Notice that the first five fields contain
exactly the same information as the $io.cmd.hdr string, so the following string definition would
be true:
$io.cmd.nop=$io.cmd.hdr + $INTB(0)
The commands listed in Table 9-4 do not utilize the variable data field of the I/O Communications
Buffer. They are used to pass simple keyboard type commands to the menu driver via software,
instead of actually waiting for keyboard input.
The most commonly used of the commands in Table 9-4 is the ky.redraw command, which forces
the current menu page to be redrawn. When a menu page is redrawn, all conditional sections are
evaluated. Since “Conditional Sections” are only evaluated when the menu page is first drawn or
each time the page is redrawn, sending a menu command that tells the menu driver to redraw the
menu page is an efficient way to get all the conditional sections reevaluated at the customizer’s
discretion.
Each of the commands listed in Table 9-4 will fill the “Function Qualifier” field in the buffer. For
example, to send a redraw command back to the menu driver the following string would be
defined in a spawn routine:
$cmd = $io.cmd.hdr + $INTB(ky.redraw)
The string variable $io.cmd.hdr in the above string definition contains all the necessary header
data for the buffer up to the qualifier field. The qualifier data field is formatted as a 16 bit integer.
Therefore, the $INTB( ) command is used to convert the 16 bit integer value into a 2 byte string
containing the binary representation of the 16 bit integer.
Likewise, the V+ INTB( ) function can be used to extract the integer value from the string
representation.
There are four buffer “qualifiers” that are used to perform more complex commands and require
the use of the variable data section of the buffer. They are described in Table 9-5 and Table 9-7.
To make use of the these commands, the variable data section of the buffer must contain the data
necessary to allow the menu driver to complete the requested command. The order of the data is
critical for the success of the command. See Table 9-6 and Table 9-8.
156
For example, if you want to display a new menu page called USER from the menu file
USERMENU.MNU, the following command string, returned from a spawn routine, will
accomplish this task:
1
2
3
4
5
6
7
8
func = ky.menu
mode = 0
$page = "user"
$file = "usermenu.mnu"
type = 0
rec = 0
access.lvl = 3
norun = 0
9
CALL mu.set.goto(func, mode, $page, $file, type, rec,
access.lvl, norun, $cmd)
The following is a line by line breakdown of the $CMD string:
Line 1
Requested command, ky.menu.
Line 2
The required MODE.
Line 3
ASCII text, page name.
Line 4
ASCII text, menu file name.
Line 5
Primary database number.
Line 6
First record.
Line 7
User access level.
Line 8
Sequence running flag.
Line 9
mu.set.goto( ) builds the command header and returns it in $cmd. It takes
care of adding required spaces and ensuring that the command header is in
the proper format. The input items to mu.set.goto( ) correspond to the
command plus the first seven items in Table 9-6.
There is a second program, mu.set.rtrv( ) that adds the command header items specified in the
next four item in Table 9-6. For example, assume you have already built the first part of a
command header using mu.set.goto( ) and you want to retrieve information from field 4 of record
2 of the path database. The following code will complete the $cmd header (note that $cmd is both
an input and output parameter):
CALL mu.set.rtrv(ph.db[TASK()], 2, 4, 0, $cmd)
The menu driver is configured to take care of the above commands when a new Menu Button is
created. When you create a new menu button, fill in the menu file name and page in the Button
Access section on the “Menu Button” data editing menu page, along with the primary database,
user access level and sequence idle flag. Notice that these data values correspond to fields in the
data section of the buffer defined above. The menu driver then takes care of assembling the data
to display the menu page the user desires.
Using of the I/O Communications Buffer in AIM Customization
The following examples show how to make use of the I/O communications buffer for more
effective AIM customization.
157
Example 1: Extracting Qualifier Data From The Buffer
This example shows how to determine the way a menu page was closed. Assume that the menu
page named DATA in the menu file TEMP.MNU has three spawn routine buttons on it labeled
DONE, YES, and NO. The spawn “Routine Name” data field on the button definition menu page
contains the following for each button:
BUTTON
“Routine Name” Data Field
DONE
ky.exit
YES
ky.yes
NO
ky.no
.PROGRAM button.spawn.rtn(arg, db.p, $cmd)
; Your custom code goes here
:
:
:
CASE arg of
VALUE 1:
;This call will execute the specified menu page. Program
;execution will suspend here until the menu page is
;closed. The $cmd string contains data in the qualifier
;that will tell the calling routine why the page
;terminated.
CALL mu.menu("DATA", "TEMP.MNU", 0, $cmd)
;Get the qualifier data from the buffer when the menu page
;terminates.
answer = INTB($cmd, io.qal)
CASE answer of:
VALUE ky.exit:
;Respond to "ky.exit"
VALUE ky.yes:
;Respond to "ky.yes"
VALUE ky.no:
;Respond to "ky.no"
In the above example, using the V+ INTB( ) function with the appropriate OFFSET into the $cmd
string (which is in the I/O Communications Buffer format), the ky.* variable that was encoded
into this string by the menu driver is extracted and evaluated to determine which button was
pressed by the operator. The offset io.qal is defined in Table 9-1.
158
Example 2: Forcing a Menu Page Redraw from a Spawn Routine
This example will show how to force a menu page to be re-drawn at the end of a spawn routine.
Remember, conditional sections get evaluated only when the menu page is drawn or re-drawn:
.PROGRAM
spawn.routine(arg, db.p, $cmd)
; Your custom code goes here
:
:
:
;Force redraw of current menu page.
$cmd = $io.cmd.hdr + $INTB(ky.redraw)
RETURN
.END
Example 3: Sending Error Information Back to The Menu Driver
This example shows how to send error information from a spawn routine back to the menu driver
for display on the standard error menu page (the red/white menu page that has the error code
and string on it).
.PROGRAM
;
;
;
;
;
spawn.routine(arg, db.p, $cmd)
Your custom code for button spawn arguments goes here
As an example, suppose this spawn routine was going to access
a record in the vision database. Now suppose the record does
not exist, and a database search for the record failed. The
code to determine this will be as follows:
$record.name = "inspect.part"
CALL db.search.str(vi.db, cc.name, 0, $record.name, record, status)
IF status < 0 then
$cmd = $io.cmd.hdr + $INTB(status) + $record.name
GOTO 100
END
; Other processing to deal with the database access goes here.
:
:
:
$cmd = $io.cmd.nop
100 RETURN
The above call to db.search.str( )will search the name field in the current vision database for a
record that has the name defined in the string $record.name. The output argument status will
contain either a zero if successful, or a V+ error code that will indicate the failure of the search
operation.
Notice that there are two $cmd string definitions in the above code. The second one will be
encountered if all goes well with the processing of the spawn routine (i.e., no errors). This
definition informs the menu driver to do nothing, or perform no operation. The first $cmd
159
definition will only be executed in the event of an error. If the status output argument from
db.search.str( ) is less than zero, which indicates an error occurred, then execution jumps to label
100. If the error code is placed into the “Function Qualifier” field in the I/O Communications
Buffer, the menu driver will automatically display the red/white error menu page with this code
and its text displayed.
160
Chapter 10
Operator Interface
In the previous chapter, the advanced programming features of the AIM menu driver were
described. In this chapter, a number of additional features of the AIM operator interface are
presented. Specifically, the following topics are discussed:
• Operator control panels
• Management of loadable databases
• Teach mode
• Saving incremental edits
• Support of icons
• Utilization of I/O ports
• The default command
10.1 Operator Control Panels
Operator control panels interact with the runtime tasks to start and stop the actual application, to
provide interactive parameters to the application, and to display status and error information to
the operator.
This section describes the implementation of the standard operator control panels, and discusses
how they may be modified by system customizers. It also describes how user-written tasks may
directly perform control-panel operations such as selecting, starting, and stopping sequence
execution.
Display
The operator control panels are standard AIM menu pages that make use of menu spawn routines
and user page routines to interact with the various runtime tasks. Many of these routines are
supplied in the AIM file EXEUSR.V2 as an example to system customizers. Many of these routines
call the control-interface routine ex.control( ), which is described below. The best way to create a
custom operator control page is to copy one of the existing pages and then modify it as necessary.
When an operator control panel is displayed, the page routine ex.mu.status( ) is called
periodically to service the message queues to and from the runtime tasks. These message queues
pass control information as well as error and informative message requests. The messages are
used to update the operator control-panel display. When no operator control panel is displayed, or
when a pop-up is on top of an operator control panel, the AIM status task (V+ task 2) handles the
message queues while the main operator-interface task displays other menu pages.
Control Interface Routine
All the standard operator control functions are implemented by the control-interface routine
ex.control( ). This routine is called by the standard operator control-panel screen routines to select,
start, stop, and pause sequences. A function code passed to this routine determines which
161
Chapter 10 - Operator Interface
operator control function is performed. This routine also returns status information, such as the
runtime mode or the message code for the last error. It may be called by user routines running
from the operator-interface task to control the runtime. (For more details, see the dictionary page
in Chapter 16 for the routine ex.control( ).)
External Control Panel
For applications in which a screen-oriented control panel is not desired, AIM supports an external
control panel. This feature is implemented by the public routines ex.panel.ext( ), ex.panel.sig( ),
and ex.panel.update( ). These routines interact with digital I/O signals and call the controlinterface routine ex.control( ), allowing the operator control functions to be performed by a
control panel connected to digital I/O signals.
The routine ex.panel.sig( ) should be called during system initialization to associate digital I/O
signals with specific control or status functions. These calls should be placed in the user
initialization routine or in CUSTOM. V2. The external control function may be enabled or disabled
by calling the routine ex.panel.ext( ), or by performing Execute ➡ External Control Panel from
the main menu. When external control is enabled, all the buttons on the regular AIM operator
control panel are ignored. The global variable ex.panel.ext( ) is set to true when the external panel
is enabled, and is checked by the standard execution-control spawn routines. This variable should
not be modified directly, but should be changed only by calling the routine ex.panel.ext( ).
When the external control panel is enabled, the routine ex.panel.update( ) is called periodically to
update status outputs and scan for any input control functions.
10.2 Teach Mode
Whenever the runtime tasks are idle or paused, the operator interface task can request that
routines be executed in teach mode. The routines are executed by the runtime task, and they have
full access to all the resources that are attached by that task (for example, a robot device).
Teach mode is requested by the operator interface task by calling the routine ai.task.teach( ). This
routine specifies the name of a teach routine to execute, as well as which task is to execute the
teach routine. It also allows a number of data values to be passed to the teach routine, and accepts
a return value from the teach routine.
The routine ai.task.teach( ) is normally called from a menu-button spawn routine in response to a
button press. The operator interface sends a request to the appropriate runtime task, and waits for
a response. The operator interface task waits indefinitely for the teaching routine to complete and
send a reply. Thus, if the teaching routine hangs, the entire AIM system will hang.
Details on specific teaching routines may be found in the documentation for the appropriate AIM
module.
10.3 Saving Incremental Edits
When an application is being developed, the operator frequently moves between the sequence
editor, the menu driver, and special teaching routines to create sequences and define the process
data. During these operations, all the information being edited is stored in the memory-resident
databases. Normally, changes to those databases are written to the disk for permanent storage
when the SAVE key (SHIFT+F2) on the system keyboard is pressed, Utilities ➡ Save all DBs is
selected, or a normal AIM shut down is performed.
At times, it is desirable to have changes to the databases written to the disk automatically. AIM
provides a software switch that, when set, causes any modified database automatically to be
written to the disk as soon as editing of the database is completed. When this option is selected,
162
Support of Icons
the response of the system is somewhat slower than normal, since disk activity is performed more
frequently. However, the delays are usually short.
To select automatic saving of databases, use the database “autosave” option in the BASEINI
initialization file.
When this option is selected, the SAVE key (SHIFT+F2) can still be used to save the contents of
databases that are in the process of being edited.
10.4 Support of Icons
Icons are utilized extensively throughout the operator interface to graphically represent data items
and operator options. These icons are statically loaded into system memory during the AIM
initialization process. Once an icon has been loaded, it can be referenced by name from any menu
page.
The standard AIM icons were created using the Adept Graphics Icon Editing Utility (in the file
EDITICON.V2 on the Adept Utility Disk). The icons are stored in files named in the format
“∗∗∗ICON.DAT” (for example, SYSICON.DAT, VISICON.DAT, PCBICON.DAT). These icon files are
loaded by the routine ai.load.icon( ). Documentation for this routine can be found in Chapter 16.
Due to the modular nature of AIM, the calls to this routine can be found in the initialization files
for several modules (for example, CUSTOM.V2, ROBMOD.OV2, VISMOD.OV2, etc.).
System customizers can add new icons to AIM by utilizing the Graphic Icon Editing Utility to
create the icons. Either the icons can be stored in the standard icon files or new files can be created.
If a new icon file is created, a call to ai.load.icon( ) should be added to the routine cu.initialize2( )
in the CUSTOM files.
NOTE: Changes should be made to the file CUSTOM.V2. Then the
modified file should be processed with the SQUEEZE program (on the
Adept Utility Disk) to create a new edition of the file CUSTOM.SQU, which
is used by AIM.
10.5 Utilization of I/O Logical Units
When writing software for use in the operator interface, you should be aware of how AIM
allocates and utilizes logical units (LUNs) for graphic-window and disk input and output.
The window LUNs referenced by io.lun and io.lun2 are used by the menu driver to access the
current menu window and the main menu window, respectively. When a user routine wishes to
access the menu window currently open, it can do so by directing its input and output operations
to io.lun. However, user routines should never alter which window is open on this LUN (that is,
user routines should never perform FCLOSE or FOPEN operations on this LUN). Furthermore, user
routines should not access the main menu window LUN (io.lun2) under any circumstances, since
this may interfere with the operation of the menu driver.
With regard to disk I/O, user-written routines should call ai.attach.dlun( ) to obtain the next
available disk LUN. This routine attaches the LUN and returns the LUN number. If too many LUNs
have been allocated, an error will be generated. By calling this routine, the user program can avoid
conflicts with system software. The documentation for this routine is provided in Chapter 16.
163
Chapter 11
The V+ Developer
The V+ Developer is an AIM tool that will help you manage your custom program files. It
provides an environment to keep track of what files and programs you have altered, identify
which programs CALL other programs, review global variable usage and in general manage your
program files.
This utility makes extensive use of the “program module” concept in V+. If you are not familiar
with this concept, see the V+ Operating System User’s Guide. Also see the descriptions of MODULE,
STOREM, and DELETEM in the V+ Operating System Reference Guide.
165
Chapter 11 - The V+ Developer
11.1 Accessing the V+ Developer
To open the V+ Developer:
Utilities ➡ V+ Developer
➋
➊
➍
➌
➎
➏
➐
➑
➒
➓
Figure 11-1
V+ Developer
166
Accessing the V+ Developer
V+ Developer Options
➊
➋
➌
➍
This area shows the history of the programs and program modules that you have accessed.
Each time you display a program for editing or display information about a program module,
that program or program module is added to the history list. This list is maintained after you
close the V+ Developer (but not after you shutdown AIM). You can double-click on a
program name in the history list and that program will be opened in the SEE editor window.
The information presented in this pick list will vary depending on the selections you make
from the various radio-buttons on the lower half of the window. It will show either V+
modules, a list of V+ programs, or a list of global variables.
The current selection shows either the module name or the program name for which
information is being displayed. In Figure 11-1, the current selection is the wild card (“∗”) and
All is selected from the “Module List:” group. This results in all loaded modules being
displayed in item ➋. If the current selection is changed to “a.m∗”, only the program modules
that begin with “a.m” will be displayed. Clicking on a program or module name in one of the
pick lists will make that item the current selection.
Press Edit and the program in the Current Selection databox will be opened in the SEE
editor. Once the SEE editor is open, all commands and options normally available to the SEE
editor are in place. See the V+ Language User’s Guide for details.
Press Wild and the current select will be made the wildcard (“∗”).
Press Prev and the previous program in the history buffer will be opened in the SEE editor.
➎
Select ✔ Edit read-write and all programs opened in the SEE editor from the V+ Developer
will be in read-write mode. Otherwise, programs will be opened in read-only mode.
➏
This section presents the various V+ Developer options for programs. The options are:
All
Display, in item ➋, all loaded programs which match the selection in
➌.
Calling current
Display all loaded programs that CALL the program in the Current Selection databox.
Called by current
Display all loaded programs that are CALLed by the program in the Current Selection
databox.
Changed
Display all loaded programs that have been changed and not saved. Changed programs are
marked by an “M” in the pick lists.
Unprotected
Display all loaded programs that are not protected. Protected programs are followed by a “P”
in the pick lists.
Module members
Display all loaded programs that belong the module shown in the Current Selection databox.
Not executable
Display all loaded programs that are not executable. Programs are marked as non-executable
when they contain a programming or logic error that prevents their correct logical execution
167
(they may still contain errors that cause them to not execute the way you would expect). Nonexecutable programs are followed by a “?” in the pick lists.
Accessing global
Display all loaded programs that access the global variable shown in the Current Selection
databox.
➐
This section presents the various V+ Developer options for program modules. The options
are:
All
Display, in item ➋, all loaded modules which match the selection in
➌.
Program owner
Display the module that is the owner of the program in the Current Selection databox.
Changed
Display all loaded modules that contain programs that have been changed and not saved
Changed modules are marked by an “M” in the pick lists.
Unprotected
Display all loaded modules that are not protected. Protected modules are followed by a “P”
in the pick lists.
➑
This section selects which global variables to display. The options are:
Program
Display all global variables accessed by the program in the Current Selection databox.
Module
Display all global variables accessed by the module in the Current Selection databox.
➒
➓
168
This option allows you to display the program stack for the various tasks. The program stack
shows the main program and all the programs that have been CALLed and are still on the
program stack. This is the information that is returned by the V+ STATUS command. Select
Task: and enter the desired task number in databox.
Press Save Module to make a backup copy of the module in the Current Selection databox.
This module must have been LOADed, modules that have been created but not previously
saved and LOADed cannot be saved with these options. Press Save All Changed to make
backup copies of all changed modules. The backup copies will have the same name as the
originally loaded file, except the last two characters of the file extension will be “Bx” where
“x” is the sequential number of the backup. For example, if the module “good.stuff” is loaded
from the file STUFF.V2, the first backup will be in the file STUFF.VB1, the second in the file
STUFF.VB2, etc.
V+ Developer Examples
11.2 V+ Developer Examples
This example shows the list of programs that CALL the routine rn.exp.eval( ). To display this
window:
Select
All from the “V+ Program List:” group and all loaded programs will be
displayed in the “Program List” window. Use the scroll bars to find rn.exp.eval( ) and
highlight the program. This will make rn.exp.eval( ) the current selection. Select
Calling current from the “V+ Program List:” group and the following window will be
displayed showing all the programs that CALL rn.exp.eval( ).
169
This example shows a list of all loaded program modules. This list is displayed by simply selecting
All from the “V+ Module List:” group. Clicking on a module makes it the current selection.
Note that the module “a.custom” has an “M” next to it. This means that at least one program in
this module has been edited and the changes have not been saved. Also note that “a.custom” has
been selected so it is added to the bottom of the history list and is the current selection.
170
V+ Developer Examples
In this example, all the global variables used by the module “a.custom” are displayed. This
display is created by making the module “a.custom” the current selection (either by clicking on
“a.custom” or by typing it into the Current Selection databox) and then selecting
Module from
the “Global Variable List:” group.
171
Chapter 12
AIM Customization Example
This chapter presents an example that covers many of the basic customization options available to
AIM. In this example (which builds on the MotionWare application module) we will:
• Create a user statement definition file
• Create several new statements
• Create a new database
• Create a menu page to edit and view the contents of the new database
• Load the database
• Create a menu pull-down option for displaying the database editing menu page
The example is based on a requirement to pick up a part (in this case a pin), inspect the dimensions
of this part, insert the pin if it passes the inspections, reject the pin if the inspection fails, and keep
track of the dimensions of all failed pins.
This example will demonstrate one of the most important features of AIM: the ability to modify
AIM to look like it was created expressly for a particular application. Just as developers using
standard databases can create inventory, point-of-sale, and similar applications, we will explore
modifying AIM to create application specific software.
One of the more important principles to understand when performing these types of
modifications is to look at the process and produce structures that will be familiar to the
individuals involved in the process. Process and plant engineers should be able to easily modify
their processes without knowing the intricate inner-working of AIM; maintenance personnel need
to be able to work through a process to find and correct problems; operators should be able to
easily work with the process operations that they are responsible for.
One of the things that you will notice we do is to create new statements that simply call existing
statements. The advantage of doing this is that we can make statements with names that relate to
the actual process and include only the arguments required for that process.
If you look carefully, you will see that everything we do in this example customization could
actually be done with the base MotionWare system. However, when we are finished we will have
demonstrated all the basic AIM customization options and have created an application specific
piece of software.
173
Chapter 12 - AIM Customization Example
12.1 The Example Application Requirements
This application is fairly simple, but it is a flexible cell. The basic part is similar but there are
several different versions of the part and the dimensions of this part change frequently. The parts
are delivered in pallets that may be of different sizes. These are graded parts, so different
production runs will have different tolerances for the part dimensions. The cell must be designed
so that these frequent changes in the part and part requirements can be handled easily by the
personnel on site. The basic part looks like this:
The parts will be delivered standing up, and the robot will grip the part at one end. The standard
MotionWare location database will handle all the location and pallet specification requirements
without modification.
After acquiring a part, the robot will move the part over an upward mounted camera for
inspection. Three inspections must be made on the part: the outer radius, the width of the groove
running along the center of the part, and the location of the small indent in the bottom of the part.
Records must be maintained of all parts that fail inspection. We will create a new database that
will hold both the specifications the parts must meet and the actual dimensions of parts that fail
inspection.
Based on the results of the inspections, the part is either inserted or move to a reject bin.
174
The Basic Operations
12.2 The Basic Operations
The operations we will perform in this example are:
• Create a new database
• Create a new menu page to edit the database
• Modify the AIM runtime code to load and use the new database and menu page
• Create a new statement database and new statements
• Create a series of new statements
• Write the V+ code to support the new statements
When we have completed this example, the user will be able to create a simple sequence such as:
GET.PIN APPROACH pick.appro LOCATION pin.pal.3
INSPECT.PIN APPROACH insp.appro PIN_INSPECT insp.loc
INSPECT_RADIUS radius INSPECT_GROOVE groove INSPECT_CENTER
center TOLERANCE 0.01 RESULT result GOOD_PIN maater.pin
IF result <> 0
REJECT.PIN APPROACH reject.path LOCATION reject.bin DEPART
reject.path
ELSE
INSERT.PIN APPROACH place.appro LOCATION pin.place
END
175
12.3 Create the Pin Database
This database will have fields to store the dimensions of the pin and information about failed
inspections. This database will be used both to hold the design dimensions and the dimensions of
any failed inspections. For failed inspections, there will be fields that store the time the failure
occurred and the cycle count of the failed part. Finally, there will be comment fields where you can
describe the part definitions and enter comments on failed parts. To create the new database:
1. Create a new .RFD file:
a.
Utilities ➡ DBM Utilities ➡ Cancel
b.
New ➡ Create RFD file ➡ enter “pin.rfd” ➡ Create
c.
Edit the database to have the following fields:
Figure 12-1
Pin Database Record-Field Definition
2. Create a new database from the .RFD file:
New ➡ Create DB from RFD ➡ enter “pin.db” ➡ Create
176
Create an Editing Page for the Pin Database
12.4 Create an Editing Page for the Pin Database
Now that we have a new database, me must create a menu page that allows us to enter new pin
specifications and to view the results of failed inspections. We will use the menu editor to create a
new menu page and menu page file:
1. Special ➡ Sample Menu
2. Utilities ➡ Edit Menu
3. File ➡ Create File ➡ enter “pin” ➡ Create
4. File ➡ Create Page ➡ enter “main” ➡ Create
5. Create a page with the following characteristics:
Figure 12-2
Pin Menu Page Header
177
6. Create the following items on the main page:
Figure 12-3
Pin Menu Page
The “Name:” item displays field 0 from the Pin database (string item). When a new part definition
record is created, the name of the part is entered here. When INSPECT.PIN creates a new record for
a failed part, a random value will be entered for the name.
The “Recorded:” item displays field 1 from the Pin database (date/time item). This field is
automatically completed when AIM creates a new record for a failed part.
The “Pin Dimensions” group displays the three elements of field 3 from the Pin database (number
item). It also displays field 2—the cycle count (number item). When a new part definition record is
created, the nominal values for the pin dimensions are entered here. When INSPECT.PIN creates a
record for a failed part, the actual dimensions of the failed part are entered along with the cycle
count.
The “Comments” group displays the three elements of field 4 from the Pin database (string item).
178
Modify AIM to Use the New Database
12.5 Modify AIM to Use the New Database
We now have a new database and a menu page for editing/viewing the database. We must now
create a program that: defines a pull-down menu option for accessing the database; loads the
database and allows us to access the database from the statement editor and the sequence editor;
and loads the custom statement code we will create later in the example.
1. The V+ Developer provides a convenient place to modify AIM programs:
a.
Utilities ➡ V+ Developer
2. Using the SEE editor, create a new program called usermod.ovr( ):
.PROGRAM usermod.ovr()
;
;
;
;
;
;
;
;
;
;
ABSTRACT: This program is the header routine for the
custom initialization file
INPUT PARM:
none
OUTPUT PARM:
none
SIDE EFFECTS: None
Copyright (c) 1995 by Adept Technology, Inc.
halt = FALSE
3. Exit the SEE editor and create a new program module and file:
MODULE usermod.ovr = usermod.ovr
STOREM usermod.ov2 = usermod.ovr
4. Create the program user.initialize( ) in the SEE editor, enter the appropriate header
information and then add the lines:
CALL ai.db.define(127, "pn", "Pin", 0, "pin.db", TRUE, "Pin", "
--pin--", "pin", halt)
IF halt GOTO 100
This line makes the Pin database a runtime database and creates all the data structures
AIM needs to keep track of the database. The arguments to ai.db.define( ) have the
following meaning:
127
database number, must be unique and is used only by low-level AIM
system software
“pn”
assigns “pn” as the pin database type and sets up the data structures for
keeping track of the pin database numbers. Used to create pn.ty and
pin.db[TASK( )].
“Pin”
name of the icon (used in the statement tree)
0
icon array index
“pin.db”
database name
TRUE
this is a runtime database
“Pin”
used by the module utility when selecting a Pin database to add to a
module
179
“--pin--”
displayed in the sequence editor for undefined arguments, also displayed
in the statement editor when selecting an argument type
“pin”
name of the .RFD file to use when creating new copies of the database
“halt”
output parameter indicating success of database definition
CALL io.pul.dwn.spw(ai.pmu, "Edit", "Pin", ky.m.menu, "main",
"pin.mnu", pn.ty, 0, 3)
This line creates the pull-down menu for accessing the Pin database. The arguments to
io.pul.dwn.spw( ) have the following meaning:
ai.pmu
places the new pull-down option in the standard AIM top-level pulldown group
“Edit”
places the new pull-down option under the Edit pull-down
“Pin”
gives the new pull-down option the name Pin
ky.m.menu forces all other open menu pages to close when this option is selected
“main”
name of the menu page to display
“pin.mnu” name of the menu page file to search for “main”
pn.ty
the database type code for the pin database
0
record number
3
defaults user access level
CALL ai.load.opt(0, "custrun.squ", "", TRUE, okay, halt)
IF halt OR (NOT okay) GOTO 90
The above lines of code will load the file of statement routines that we will create in
section 12.9.
CALL ai.add.opt.name("Pin")
The above line of code will add the Pin database name to the initialization window
when AIM is first started.
pin.name = 0
pin.date = 1
pin.cycle = 2
pin.dim = 3
pin.ix.rad = 0
pin.ix.grv = 1
pin.ix.ctr = 2
;Database name
;Date/time field
;Cycle count field
;Pin dimensions
;Pin radius index
;Pin groove index
;Pin center index
The above lines of code set up the global variables we will use to access the fields in
the Pin database.
5. Add the program user.initialize( ) to the usermod.ovr( ) module and save the changes to the
file USERMOD.OV2.
6. Create a squeezed version of USERMOD.OV2 with the name USERMOD.OVR.
The basic AIM system includes an initialization record that will look to see if the file
USERMOD.OVR is present. If the file is found, it is loaded and the program user.initialize( ) is run.
This allows us to load and initialize all of our custom code without modifying any standard AIM
files.
180
Create the New Statements
12.6 Create the New Statements
AIM can load many different statement databases. As these databases are loaded, the statements
are sorted according to the type code, and a pick list is created from which users select statements
when they are using the sequence editor. There is an initialization record delivered with each
system that will look for the statement database “statuser.db” and load any statement definitions
found in that database. So the first thing we will do is create a new statement database with this
name.
1. The record-field definition file for the statement database is STAT.RFD. Start the database
manager utilities and open this .RFD file:
Utilities ➡ DBM Utilities ➡ enter “stat.rfd” ➡ Goto
2. We can now create a new database from the .RFD file:
New ➡ Create DB from RFD ➡ enter “statuser.db” ➡ Create
3. Restart AIM (the new statement database can only be loaded at start-up).
12.7 Create the New Statement Definitions
We will be creating four new statements: GET.PIN, INSERT.PIN, INSPECT.PIN, and REJECT.PIN. the
V+ code that supports these statements definitions will be created in section 12.9.
181
12.8 Create the GET.PIN Statement
The GET.PIN statement will simply be a modified version of the move( ) statement that uses only
the approach and location arguments.
1. Open the statement database editor and select the STATMOW.DB file:
Special ➡ Edit Statements ➡ highlight “statmow.db” ➡ Select
2. Copy the move( ) statement definition and paste it into the new statement database:
a.
Open the move( ) statement and copy it
b.
Switch files to the STATUSER.DB file:
Special ➡ Edit Statements ➡ highlight “statuser.db” ➡ Select
c.
Paste the copied record and name it GET.PIN
3. Edit GET.PIN as follows:
Figure 12-4
GET.PIN Statement Definition
Create the Definition for INSERT.PIN in the Statement Database
This statement is also a modified version of the move( ) statement. We will create this statement so
the user can easily define a series of actions that will acquire, inspect, and insert the pin.
1. Copy the definition of GET.PIN
2. Paste the copied statement and rename it INSERT.PIN.
3. Edit as follows:
182
Create the GET.PIN Statement
Figure 12-5
INSERT.PIN Statement Definition
Create the Definition for REJECT.PIN in the Statement Database.
This statement is also a modified version of the move( ) statement. We will create this statement so
the user can easily define an option when the pin inspection fails.
1. Copy the definition of GET.PIN
2. Paste the copied statement and rename it INSERT.PIN.
3. Edit as follows:
Figure 12-6
REJECT.PIN Statement Definition
Create the Definition for INSPECT.PIN in the Statement Database
This statement is more complicated than the previous statements. It will move the robot to a
picture taking location, make three inspections of the pin, post a result, and create an entry in the
183
new database with the dimensions of the pin that failed inspection. Open a new statement record
and edit as follows:
Figure 12-7
INSPECT.PIN Statement Definition
12.9 Create the V+ Code for the New Statements
Now that we have the statement definitions, we must create the V+ code that supports these
statements. Before we create the statement code we should create a new module and header file
for the module:
1. Using the SEE editor, create a new program called “z.custrun”:
.PROGRAM z.custrun()
;
;
;
;
;
;
;
;
;
;
ABSTRACT: This program is the header routine for the file of custom
user statement routines.
INPUT PARM:
none
OUTPUT PARM:
none
SIDE EFFECTS: None
2. Exit the SEE editor and create a new program module and file:
MODULE z.custrun = z.custrun
STOREM custrun.v2 = z.custrun
The GET.PIN Statement Code
The GET.PIN statement simply re-maps the args[ ] array and calls the existing move( ) statement
code. This strategy allows us to very easily create a custom statement specific to an application
184
Create the V+ Code for the New Statements
while still using all the code the already exists for the move( ) statement. The statement code of
GET.PIN is:
.PROGRAM get.pin(args[], error)
; ABSTRACT: This program is the statement routine for the GET.PIN routine.
;
This routine simply calls the MOVE statement routine after completing
;
the unused args[] values with null values. The format for the statement
;
is:
;
GET.PIN APPROACH --path-- PIN_PICKUP --location-;
;
Argument
Type or Database
Misc
formal parameter name
;
---------------------------------------------;
approach path
PATH
required
args[1]
;
pin pick loc
LOCATION
required
args[2]
;
;
;
;
;
;
;
INPUT PARM:
args[]
Array of arguments (record numbers or constants)
OUTPUT PARM:
error
Standard operator error response code.
SIDE EFFECTS: None
AUTO REAL m.args[11]
; Complete the m.args[] array with null values
FOR ii = 1 TO 11
m.args[ii] = 0
END
; Map the GET.PIN arguments to the MOVE arguments
m.args[3] = args[1]
m.args[4] = args[2]
; Call the move statement routine
CALL move(m.args[], error)
RETURN
.END
The INSERT.PIN Statement Code
The code for INSERT.PIN is identical to the code we created for GET.PIN. Remember, the reason we
are creating these custom statements is so the site personnel can easily create and modify
sequences that represent their process. Notice that we are using only the arguments that are
needed for our specific needs and that in some cases these are optional, not required, arguments in
the move( ) statement.
.PROGRAM insert.pin(args[], error)
; ABSTRACT: This program is the statement routine for the INSERT.PIN routine.
185
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
is:
INSERT.PIN APPROACH --path-- PIN_PICKUP --location-Argument
-------approach path
pin insert loc
Type or Database
---------------PATH
LOCATION
Misc
---required
required
--------------------args[1]
args[2]
INPUT PARM:
args[]
OUTPUT PARM:
error
SIDE EFFECTS: None
FOR ii = 1 TO 11
m.args[ii] = 0
END
m.args[3] = args[1]
m.args[4] = args[2]
RETURN
The REJECT.PIN Statement Code
The code for INSERT.PIN is identical to the code we created for GET.PIN except we add the
additional path argument for use when departing the reject location.
.PROGRAM reject.pin(args[], error)
; ABSTRACT: This program is the statement routine for the REJECT.PIN routine.
;
;
;
is:
;
REJECT.PIN APPROACH --path-- REJECT_BIN --location-;
DEPART --path-;
;
Argument
Type or Database
Misc
;
---------------------------------------------;
approach path
PATH
required
args[1]
;
pin reject loc LOCATION
required
args[2]
;
depart path
PATH
required
args[3]
186
;
;
;
;
;
;
;
INPUT PARM:
args[]
OUTPUT PARM:
error
SIDE EFFECTS: None
FOR ii = 1 TO 11
m.args[ii] = 0
END
m.args[3] = args[1]
m.args[4] = args[2]
m.args[5] = args[3]
RETURN
The INSPECT.PIN Statement Code
This code is considerably more complicated than the previous examples. It, however, also uses a
standard MotionWare statement routine inspect( ). Since this statement routine is more complex,
additional descriptions have been added to the code to describe what the code is doing.
The code starts off with a header in the standard AIM format.
.PROGRAM inspect.pin(args[], error)
; ABSTRACT: This program is the statement routine for the INSPECT.PIN
;
statement. It makes three inspections of the pin and compares them
;
with known dimensions. It performs the following actions:
;
;
1. Move along the inspect location path to the inspect location.
;
2. Make three inspections of the pin
;
Check the diameter
;
Check the groove width
;
Check the center point location
;
3. Depart along the depart path
;
4. If the pin is good, the result is set to TRUE, and the robot
;
enters the depart path.
;
5. If the pin is bad the result is set to FALSE and a new record is
;
added to the pin database. The robot enters the depart path.
;
The results codes posted to the variable database record are:
;
0 = passed
;
1 = radius inspection failed
;
2 = groove inspection failed
;
3 = center inspection failed
;
The result represents the last failed inspection.
;
The format for the statement is:
187
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
INSPECT.PIN
Argument type definitions:
Argument
-------appro path
pin insert loc
radius inspect
groove inspect
center inspect
pin tolerance
result code
pin specs
Type or Database
---------------Path
Location
Vision
Vision
Vision
Variable
Variable
Pin
Misc
----
--------------------args[1]
args[2]
args[3]
args[4]
args[5]
args[6]
args[7]
args[8]
INPUT PARM:
args[]
OUTPUT PARM:
error
SIDE EFFECTS: None
AUTO
AUTO
AUTO
AUTO
REAL m.args[11], pin.specs[3], pin.results[3]
ii, pn.db, error, va.db, vi.db
low, nom, high, insp1, insp2, insp3, tol
a.appro, a.loc, a.rad, a.grv, a.ctr, a.tol, a.rslt, a.pin
The next three lines of code set up variables for the two database we will access in this statement.
You will recall that when we loaded the Pin database we gave it a type code of “pn” (see section
12.5).
pn.db = pn.db[TASK()]
va.db = va.db[TASK()]
vi.db = vi.db[TASK()]
These are variables that we will use to refer to the various element of the args[ ] array.
; args[] access variables
a.appro = 1
a.loc = 2
a.rad = 3
a.grv = 4
a.ctr = 5
a.tol = 6
a.rslt = 7
a.pin = 8
; These variables hold the status of the three inspections
insp[pin.ix.rad] = TRUE;Assume inspections are successful
insp[pin.ix.grv] = TRUE
insp[pin.ix.ctr] = TRUE
We first set up to move to the inspection location. The first and second arguments of INSPECT.PIN
are mapped to the third and fourth arguments of move( ).
188
; Map the INSPECT.PIN args to the MOVE args
FOR ii = 1 TO 11
m.args[ii] = 0
END
m.args[3] = args[a.appro]
m.args[4] = args[a.loc]
; Move to the inspection location
IF error <> 0 GOTO 100
The user has given us a record name in the Pin database from which to retrieve the appropriate
values for the pin dimensions. The following lines retrieve this information.
; Get the part dimensions and tolerance
CALL rn.open.rec(pn.db, args[a.pin], error)
CALL rn.get.a.nums(pn.db, pin.dim, pin.ix.rad, 3, pin.ix.rad, pin.specs[],
error)
They have also given us a tolerance value (either as a specific value or as a record name in the
variable database). The following lines retrieve this information regardless of how the value was
specified.
CALL rn.get.va.num(args[a.tol], FALSE, tol, error)
Now we set up to call the INSPECT statement routine three times, with each successive call
mapping one of the vision arguments from INSPECT.PIN to the first argument of the INSPECT
statement routine. If the inspection fails, we post the failure information to the results record in the
variable database. (Note that we could have called the three inspections in a FOR loop.)
; Make the inspections
FOR ii = 1 TO 11
m.args[ii] = 0
END
; Call the first inspection
m.args[1] = args[a.rad]
CALL inspect(m.args[], error)
pin.results[pin.ix.rad] = vw.res[vi.db,m.args[1],vw.r.value]
low = pin.specs[pin.ix.rad]-(pin.specs[pin.ix.rad]*tol)
high = pin.specs[pin.ix.rad]+(pin.specs[pin.ix.rad]*tol)
IF OUTSIDE(low,pin.results[pin.ix.rad],high) THEN;If inspection fails
insp[pin.ix.rad] = FALSE
CALL rn.put.va.num(args[a.rslt], FALSE, 1, error)
END
189
; Call the second inspection
m.args[1] = args[a.grv]
pin.results[pin.ix.grv] = vw.res[vi.db,m.args[1],vw.r.value]
low = pin.specs[pin.ix.grv]-(pin.specs[pin.ix.grv]*tol)
high = pin.specs[pin.ix.grv]+(pin.specs[pin.ix.grv]*tol)
IF OUTSIDE(low,pin.results[pin.ix.grv],high) THEN;If inspection fails
insp[pin.ix.grv] = FALSE
END
; Call the third inspection
m.args[1] = args[a.ctr]
pin.results[pin.ix.ctr] = vw.res[vi.db,m.args[1],vw.r.value]
low = pin.specs[pin.ix.ctr]-(pin.specs[pin.ix.ctr]*tol)
high = pin.specs[pin.ix.ctr]+(pin.specs[pin.ix.ctr]*tol)
IF OUTSIDE(low,pin.results[pin.ix.ctr],high) THEN;If inspection fails
insp[pin.ix.ctr] = FALSE
END
Finally, we check all three inspections. If all inspections passed, we post the success to the results
record. If any inspection failed, we create a new record in the Pin database and store the actual
results of the inspection, the cycle count, and the current time.
; Post the results
;
If all inspections pass
IF insp[pin.ix.rad] AND insp[pin.ix.grv] AND insp[pin.ix.ctr] THEN
ELSE
; Create record with failed inspection data
CALL db.append.rec(pin.db, 1, TRUE, error)
CALL db.put.str(pin.db, 0, 0, "F"+$ENCODE(/I7,INT(RANDOM*1E+07)), error)
CALL db.put.date(pin.db, 1, 0, TIME(,1), TIME(,2), error)
CALL db.put.a.nums(pin.db, pin.dim, pin.ix.rad, 3, pin.ix.rad,
pin.results[])
CALL db.put.num(pin.db, pin.cycle, 0, rn.ctl[TASK(),rn.ctl.complete]+1,
error)
END
100;Errors
RETURN
190
The Final Details
We have a few final tasks to perform:
1. Store the statement code:
FDELETE z.custrun.v2
MODULE z.custrun = inspect.pin,get.pin,reject.pin,insert.pin
STOREM custrun.v2 = a.custrun
NOTE: You can also perform these operations with the V+ Developer.
2. Create a squeezed version of CUSTRUN.V2 named CUSTRUN.SQU.
3. Add a command to user.initialize( ) to load CUSTRUN.SQU.
191
Chapter 13
Error Messages and the Error Message Database
This chapter describes the format in which AIM error messages are stored, how error messages are
accessed, and how new error messages can be added to the system.
For uniformity and to allow error messages to be generated in a foreign language, most AIM error
conditions are represented by an error code (that is, an integer number) rather than a text message.
The use of a code also permits errors to be grouped in ranges (for example, –2000 to –2999, 3000 to
3999). This allows errors of a similar severity and requiring a similar response to be distinguished
easily.
In order to convert error codes to error message strings, the Error Message database and an errorcode conversion routine (er.error( )) are provided with the system. Each record of the Error
Message database contains the information for a single error code. Whenever an error code is
generated, it is automatically converted to the corresponding error message contained in the Error
Message database for output to the system operator. If desired, system customizers can edit the
error messages in this database to translate the error messages to another language.
In addition to the error code and its corresponding error message, each record in the Error
Message database contains a detailed explanation of the error and a suggested corrective action.
This detailed explanation and suggested action are not used by the system, but are provided as an
aid to the system operator. When an error is detected by the AIM runtime, the operator is
presented with a menu button that will automatically retrieve the appropriate detailed
explanation and suggested action. In addition, whenever the Error Message database is accessed
via the “Help” pull-down on the status line, the database is automatically opened at the record
corresponding to the last error code converted by the routine er.error( ).
Since many of the errors that can occur are generated by V+, the Error Message database contains
information concerning all the V+ error messages in addition to the AIM error messages. See
Appendix C of this manual, and the V+ Language Reference Guide, for lists of the error messages.
The Error Message database is accessed as a disk-resident database, since it contains hundreds of
large records. Also, since it is accessed only intermittently, and there are a limited number of disk
logical units (LUNs), the database is normally closed and is opened only briefly as required.
Having the Error Message database disk-resident and closed minimizes its impact on available
system memory and LUN resources.
However, this organization could cause a problem at certain times, because it is sometimes
necessary to convert error codes very quickly to error message strings. This is the case during
walk-thru training, when trace messages and warning messages are generated at a fast rate.
To address this need, the routine that converts an error code to an error message string (er.error( ))
scans the Error Message database at system startup (and whenever the database is edited) and
densely packs the error message strings into a string array in memory. To minimize memory
requirements, the error message strings that can be obtained from V+ are excluded from the string
array. The error-code conversion routine can thus be called by any task, and the error code can be
converted to its message string very quickly without accessing the disk.
193
Chapter 13 - Error Messages and the Error Message Database
13.1 Special System Messages
While it is generally true that error and informational messages are directly extracted from the
Error Message database, there are two exceptions to this rule.
First, during system startup, a few messages are output that cannot be contained in the Error
Message database. These text strings cannot be extracted from the database because either: (1) the
messages must be output before the Error Message database is first scanned, or (2) it is important
that the error message be displayed even if the Error Message database cannot be accessed for
some reason.
And secondly, there are some special text strings that are used by utility programs or system
routines to construct special messages or qualifiers to regular error messages. For example, “Db:”
and “File:” are special text strings that are output in connection with error messages to qualify
which database or file is associated with the error.
In general, these additional text strings are defined in the program ai.system.mes( ) (which is
contained in the file TEXT.OV2), or they are defined in the initialization routines for the various
AIM modules (that is, in the files ROBMOD.OV2, VISMOD.OV2, etc.). As with text contained in the
Error Message database, these special text strings can be translated to another language as
necessary.
13.2 Adding New Error Messages to the System
AIM allows multiple error databases. In general, you will want to create a new error database for
user defined errors rather than adding errors to the existing error database. Also, if you want to
alter existing error messages (for example, translating error messages to a foreign language) you
should add new messages to your own error database rather than altering the Adept supplied
database. All user error database are loaded before the Adept error database and any records with
a duplicate number are ignored, thus user defined errors will take precedence over any Adept
error with the same number.
Use the ERROR.RFD to create new error databases. You will also need to edit the “error database,
additional” record in the USERINI initialization database to load your custom error databases.
Remember: if error numbers are defined in both custom and standard error databases, the custom
database errors will take precedence. Thus, if you merely want to change the description of an
existing error, you would still add a new record to your custom error database. Using additional
error databases in this fashion makes it much easier to transfer your new and edited error
messages to other systems and to system upgrades.
NOTE: You must always restart the system after editing the USERINI
initialization database.
To add a new error code and message to the system, select Special ➡ Edit Error Messages. As
soon as you terminate editing, the packed data for the routine er.error( ) will be computed and
AIM will know about the new error message. You can then write new runtime routines that
generate the new error code and the code will be properly converted to its error message string as
required.
To facilitate the interpretation of error codes, the error code numbers have been divided into
groups. In general, error codes can range in value from –32767 to 32767. As with V+, negative
values are interpreted to represent error conditions and positive error-code values represent
194
Adding New Error Messages to the System
informative messages. If a new error message and code are added to the Error Message database,
the categories listed in Table 13-1 should be kept in mind when selecting the value of the error
code.
Table 13-1
Error Code Assignment
Error Codes
Assigned Usage
–7000 to –7999
Runtime error codes for use by system customizers.
Error codes in this range indicate that a hard error has occurred and
sequence execution must be stopped to allow the error to be
corrected manually. This type of message is automatically passed
from the runtime to both the operator interface and the data logger.
–6000 to –6999
Reserved for Adept AIM runtime errors.
–5000 to –5999
Pause codes for use by system customizers.
These errors indicate that sequence execution must be stopped to
allow manual intervention. However, the halt is caused by a planned
event, not by an unexpected system failure. These messages are
passed from the runtime to the operator interface--they are not
passed to the data logger.
–4000 to –4999
Reserved for Adept AIM runtime pause codes.
–3000 to –3999
Operator errors for use by system customizers.
These errors are typically generated by the operator interface and
indicate that an invalid manual command sequence has been entered
or a failure has occurred in response to a direct operator command.
Since these errors are not generated by the runtime, they do not
normally affect sequence execution and they are not logged.
–2100 to –2999
Reserved for Adept AIM operator errors.
–2000 to –2099
Reserved for Adept Database Manager errors.
–1 to –1999
Reserved for Adept V+ error messages.
1 to 1999
Reserved for Adept V+ informative messages and warnings.
2000 to 2999
Reserved for Adept AIM informative messages.
3000 to 3999
Informative messages for use by system customizers.
These message are typically generated by the operator interface and
do not effect the execution of the runtime or the operator interface.
Used for labels on the operator response choices on the control
panels.
4000 to 4999
Reserved for Adept AIM trace messages.
5000 to 5999
Trace messages for use by system customizers. These messages are
generated by the runtime during walk-thru training mode to
indicate the activity that will be performed next. These messages are
passed from the runtime to the operator but do not affect sequence
execution, and they are not logged.
195
Chapter 13 - Error Messages and the Error Message Database
13.3 Error-Code Conversion Routine
The AIM routine er.error( ) is provided for use by system customizers to simplify displaying the
error message associated with a given error code. Details of the routine, including its calling
sequence, are presented in Chapter 16. The MESSAGE statement allows you to display error
messages on the Task Control Panel.
196
Chapter 14
Database Management Library Programs
14.1 Standard Library Routines
The Adept Database Management Library is a collection of runtime routines that can be called
from an application program to create, access and modify databases. These routines allow an
application program to open a database, search for records with a field matching some value,
delete records, etc.
All the routines in the Database Management Library have names beginning with “db.”. Each
routine is listed in the next section, grouped by function, and is described in detail later in this
chapter.
See Chapter 3 for details on how AIM databases are used. This information is critical to being able
to effectively use the routines described in this chapter.
14.2 Summary Of Library Routines
The following tables briefly describe each of the user-callable routines within the library. The
routines are grouped by function. Complete descriptions of each routine follow the tables.
Table 14-1
Routines That Open/Close Records or Files
Routine
Action
db.close.file
Close the specified database, write changes to disk and sort the database.
db.close.rec
Close the current record in the indicated database.
db.open.file
Open a database and make the first record the current record.
db.open.p.rec
Make a specified physical record the current record.
db.open.rec
Make the specified logical record the current record.
db.default.rec
Make the default record the current record.
db.first.rec
Make the first record the current record.
db.last.rec
Make the last record the current record.
db.next.rec
Make the next record (relative to the current record) the current record.
db.previous.rec
Make the previous record (relative to the current record) the current record.
db.test.open
Search open database(s) for a disk file name matching a specified disk file
name. If found, the database number, status and owning task are returned.
197
Chapter 14 - Database Management Library Programs
Table 14-2
Routines That Create/Delete Records or Files
Routine
Action
db.append.rec
Add new record(s) to the end of the database. Make the first new record the
current record.
db.create.file
Create a new database file using the field structure of an existing database.
db.delete.rec
Mark the current record of a specified database for deletion.
db.delete.value
Delete the value in a specified field in the current record of a specified
database.
db.insert.rec
Insert new record(s) before or after the current record in a specified
database.
db.undelete.rec
Remove the deletion marker from the current record of a specified database.
Table 14-3
Routines That Read Non-Array Values
Routine
Action
db.get.date
Get a date/time value from a specified field in the current record in a specified
database.
db.get.num
Get a numeric value from a specified field in the current record in a specified
database.
db.get.str
Get a string from a specified field in the current record in a specified database.
db.get.trans
Get a transformation (location) value from a specified field in the current record
in a specified database.
Table 14-4
Routines That Read Array Values
Routine
Action
db.get.a.date
Get date/time value(s) from a specified range of array indexes in a specified
field in the current record of a specified database.
db.get.a.num
Get numeric value(s) from a specified range of array indexes in a specified
field in the current record of a specified database.
db.get.a.nums
Get numeric value(s) from a specified range of array indexes in specified
contiguous fields in the current record of a specified database.
db.get.a.str
Get string value(s) from a specified range of array indexes in a specified field
in the current record of a specified database.
198
Summary Of Library Routines
Table 14-4
Routines That Read Array Values (Continued)
Routine
Action
db.get.a.trans
Get transformation (location) value(s) from a specified range of array indexes
in a specified field in the current record of a specified database.
Table 14-5
Routines That Write Non-Array Values
Routine
Action
db.put.date
Place a date/time value in a field of the current record of a specified
database.
db.put.num
Place a numeric value in a field of the current record of a specified
database.
db.put.num.tst
Place a numeric value in a field of the current record of a specified
database. If new value matches the current value, it is not written.
db.put.str
Place a string value in a field of the current record of a specified database.
db.put.trans
Place a transformation value in a field of the current record of a specified
database.
Table 14-6
Routines That Write Array Values
Routine
Action
db.put.a.date
Place date/time value(s) in a range of array values in a field of the current
record of a specified database.
db.put.a.num
Place numeric value(s) in a range of array values in a field of the current
db.put.a.nums
Place numeric value(s) in a range of array values in contiguous fields in a
field of the current record of a specified database.
db.put.a.str
Place string value(s) in a range of array values in a field of the current
db.put.a.trans
Place transformation value(s) in a range of array values in a field of the
current record of a specified database.
199
Table 14-7
Routines That Perform Data Validation
Routine
Action
db.check.name
Check a string to see if it conforms to V+ variable and program naming
conventions.
db.valid.ref
Check the validity of a specified database number, specified field number
and specified array index.
Table 14-8
Routines That Search Databases
Routine
Action
db.search.date
Search a field in a database for a specified date/time string.
db.search.num
Search a field in a database for a specified numeric value.
db.search.str
Search a field in a database for a specified string.
db.search.trans
Search a field in a database for a specified transformation value.
Table 14-9
Routines That Return Database Status
Routine
Action
db.get.attr
Get the user-attributes of a field of a specified database.
db.get.attr.or
Return the OR of the user attributes for all fields of a specified database
and the number of defined fields.
db.get.db.stat
Return the total number of records, the number of records marked for
deletion, and an indication of whether the database has been modified,
needs sorting, or contains duplicate entries in the primary sort field.
db.get.lrec.num
Return the logical record number corresponding to a physical number in a
specified database.
db.get.modified
Return the modification date and time for a specified database.
db.get.rec.stat
Return the logical and physical numbers of the current record in a
specified database, and whether the record has been modified or deleted.
db.get.title
Read the title string for a specified database.
db.get.update
Return the date and time of the last updating of the current database.
db.get.user.str
Return one of the three information strings stored for each database.
200
Summary Of Library Routines
Table 14-9
Routines That Return Database Status (Continued)
Routine
Action
db.lookup.field
Return the field number of a record field with a specified name in a
specified database.
db.lookup.name
Return the field name of the record field with a specified field number in a
specified database.
Table 14-10
Miscellaneous Database Routines
Routine
Action
db.get.c.rec
Copy the current record in a specified database to a string variable.
db.get.file
Return the disk and file name specification of a specified database.
db.get.rec
Copy the current record in a specified memory resident database to a string
variable.
db.initialize
Initialize the global variables for the database system.
db.put.c.rec
Paste the record copied with db.get.c.rec( ) or db.get.rec( ) to the currently
open record in the specified database.
db.put.rec
Paste the record copied with db.get.c.rec( ) or db.get.rec( ) to the specified
memory resident database.
db.put.title
Change the title string of a database.
db.put.user.str
Change one of the three information strings in a specified database.
db.set.update
Set the date and time indicating when a database was updated.
db.sort.file
Sort the database and remove any records marked for deletion. (Changes
are not written to disk for memory resident databases.)
db.update.file
Sort the database, remove any records marked for deletion, and store
changes to disk.
201
Summary of AIM Runtime Routines That Access Databases
In addition to the basic database access routines, the AIM runtime system includes database access
routines that incorporate the walk-thru training feature of AIM and ensure that detected errors
are correctly handled. If you are writing statement routines that access databases, you will
generally want to use the following routines to access databases. See Chapter 16 for details.
Table 14-11
Routines That Support Runtime Execution
Routine
Action
rn.get.a.num
Runtime routine that returns an array of real values from an array field of
the current record in a database, and handles walk-thru training.
rn.get.a.nums
Runtime routine that returns a number of consecutive numeric fields from
the current database record, and handles walk-thru training.
rn.get.a.str
Runtime routine that returns an array of string or name values from an
array field of the current record in a database, and handles walk-thru
training.
rn.get.num
Runtime routine that returns the numeric value from a field of the current
rn.get.trans
Runtime routine that returns a transformation value from a field in the
current record in a database, and handles walk-thru training.
rn.open.p.rec
rn.open.rec
rn.put.trans
Runtime routine to modify the value of a transformation field in the current
record in a database, and handle any errors.
rn.walk.train
Runtime routine to train a value in a database record during walk-thru
training mode.
202
Descriptions Of Library Routines
14.3 Descriptions Of Library Routines
The routines for the Database Management Library are distributed in the disk file DBMLIB.SQU.
All the user-callable runtime routines are described in this section.
Each routine is presented on a separate page. The dictionary page for each routine contains the
following sections, as applicable.
Calling Sequence
The format of a V+ CALL instruction for the routine is shown.
NOTE: The variable names used for the routine parameters are for
explanation purposes only. Your application program can use any
variable names you want when calling the routine.
Function
This is a brief statement of the function of the routine.
Usage Considerations
This section is used to point out any special considerations associated with use of the routine.
Input Parameters
Each of the input parameters in the calling sequence is described in detail. For parameters that
have a restriction on their acceptable values, the restriction is specified.
Output Parameters
Each of the output parameters in the calling sequence is described in detail.
Details
A complete description of the routine and its use is given.
Related Routines
Other routines, which are related to the function of the current routine, are listed.
203
db.append.rec
Calling Sequence
CALL db.append.rec (db, records, set.def, status)
Function
Append a number of new records to a database.
Input Parameters
db
Real value specifying the number of the database to access. The value
must be greater than zero.
records
Real value specifying the number of new records to add. (If the value is
negative or zero, one new record will be added.)
set.def
Real value (interpreted as TRUE or FALSE) that specifies whether or not
the fields of created records are to be set to their default values. If set.def
is TRUE, all field values are set to the values stored in the default record. If
set.def is FALSE, the field values are all set to undefined.
Output Parameter
status
Real variable that receives a value indicating whether or not the operation
was successful. See Chapter 15 for the values that can be returned.
Details
This routine appends a given number of new records at the end of the specified database.
Depending on the value of the set.def parameter, the field values of the new records will either be
“undefined”, or they will be set equal to the values stored in the default record.
The first of the new records is left open for subsequent access.
Related Routines
db.insert.rec
db.default.rec
204
db.check.name
Calling Sequence
CALL db.check.name ($string, status)
Function
Check if the input string is a valid V+ name.
Input Parameter
$string
String variable specifying the string to be tested.
NOTE: Because this parameter is also used for output, it cannot be
specified in the calling program as a constant value or an expression if the
output value is desired.
Output Parameter
$string
String variable that receives a copy of the input string. If the input string
is a valid name, any uppercase letters in the name are converted to
lowercase, and all leading and trailing space and tab characters are
omitted.
If the input string is not a valid name, the string is returned unchanged.
status
Real variable that receives a TRUE value if the string is a valid V+ name, or
a FALSE value if it is not a valid name.
Details
This routine checks whether or not the given string is a valid V+ name. That is, whether or not the
string starts with a letter and consists of only letters, numbers, and the characters “.” and “_”.
If the string is a valid name, any uppercase letters in it are converted to lowercase, and all space
and tab characters are removed.
205
db.close.file
Calling Sequence
CALL db.close.file (db, status)
Function
Close a database file.
Input Parameter
db
Output Parameter
status
Real variable that receives a value indicating whether or not the file was
successfully closed. See Chapter 15 for the values that can be returned.
Details
This routine must be called when the application program is done with a database. Any changes
that have been made are written out to the database file and, if necessary, the file is sorted.
Related Routine
db.open.file
206
db.close.rec
Calling Sequence
CALL db.close.rec (db, status)
Function
Close the current record in the indicated database. The current task is left with no database record
open.
Input Parameter
db
Database number of record to close.
Output Parameter
status
Standard AIM status variable.
207
db.create.file
Calling Sequence
CALL db.create.file (db, $def.file, $db.file, records, status)
Function
Create a new database file using the record field descriptions and default values from an existing
database.
Any existing database file with the same name will be deleted.
Input Parameters
db
Real value specifying the number to use when referring to this database.
The value must be greater than zero.
$def.file
String value, variable, or expression specifying the name of the existing
database from which the field definitions and default values are
extracted. Normally, this will be a .RFD file, although a .DB file can also
be utilized.
The disk device and directory containing the file must be included in the
file specification if the file is not at the default disk location (see
$db.def.disk).
$db.file
String value, variable, or expression specifying the name of the database
file to be created. The disk device and directory containing the file must
be included in the file specification if the file is not at the default disk
location (see $db.def.disk).
records
Real variable specifying the maximum number of records to keep in
memory at one time. See the description of the routine db.open.file( ) for
complete details.
Output Parameter
status
successfully opened. See Chapter 15 for the values that can be returned.
Details
This routine creates a new database file that contains the same record field definitions and default
values as an existing file. Normally, this routine is used to create a standard database (that is, a .DB
file) given a database file that contains a template of the desired field definitions and default
values (that is, a .RFD file). However, this routine can also be called to create a database file given
a standard .DB file.
This routine always creates a database file that includes a “default” record. The default record
contains default values for all of the record fields. These default values can be used to initialize
any data records that are subsequently added to the database. See the routine db.default.rec( ) for
information on how the defaults can be changed.
At the conclusion of this routine, the newly created database is left opened.
208
db.default.rec
Calling Sequence
CALL db.default.rec (db, status)
Function
Open the default record in a database for reading and modification.
Input Parameter
db
Output Parameter
status
Details
This routine opens the “default” record in the specified database for reading and/or modifying.
The default record contains default values for all of the record fields. These default values can be
used to initialize any data records that are added to the database. Once the default record is
opened, its field values can be read and altered using the standard routines db.get.∗( ) and
db.put.∗( ), respectively.
Normally, the default values are accessed and edited via the DBM Utility.
Related Routines
db.append.rec
db.create.file
db.insert.rec
209
db.delete.rec
Calling Sequence
CALL db.delete.rec (db, status)
Function
Delete the current record in a database.
Input Parameter
db
Output Parameter
status
Real variable that receives a value indicating whether or not the record
was successfully deleted. See Chapter 15 for the values that can be
returned.
Details
This routine deletes the record that is currently open in the indicated database. Note, however,
that the record is not immediately deleted, but rather it is marked for later deletion. The actual
deletion is done the next time the file is sorted or updated. (The deletion mark can be removed
with the routine db.undelete.rec( ).)
The next record is opened for reading/modifying after the deletion.
Related Routine
db.undelete.rec
210
db.delete.value
Calling Sequence
CALL db.delete.value (db, field, index, status)
Function
Delete the value of a specified field in an open record.
This routine accesses the record opened by the task calling the routine.
Input Parameters
db
field
Real value specifying the number of the field whose value is to be
deleted. The value of this parameter must be greater than or equal to zero.
index
Real value specifying the number of the element to delete from an array
field. This parameter must be set to 0 if the field does not contain an
array.
Output Parameter
status
Details
This routine deletes the value of the specified field in the record currently open in the indicated
database. Any subsequent attempts to read the field will result in the error “No valid data in d.b.
field”.
211
db.first.rec
Calling Sequence
CALL db.first.rec (db, status)
Function
Select the first record of a database for access.
This routine affects which record is open only for the task that executes the routine.
Input Parameter
db
Output Parameter
status
Details
This routine can be used to change the record open for reading or modifying to be the first record
in the specified database.
NOTE: This routine ignores any records that have been marked for
deletion.
If any error occurs, the record currently open will remain open. That is, no change of record
occurs.
Related Routines
db.last.rec
db.next.rec
db.open.rec
db.previous.rec
212
db.get.a.date
Calling Sequence
CALL db.get.a.date (db, field, first, count, index, date[],
time[], status)
Function
Return arrays of date and time values from an array field of the current record in a database.
Input Parameters
db
field
Real value specifying the number of the field whose values are to be
returned. The value of this parameter must be greater than or equal to
zero.
first
Real value specifying the index number of the first element in the array
field to be returned. (The first element of an array has index 0.)
count
Real variable specifying the number of array elements to be returned.
index
Real value specifying the index number of the first element of the output
arrays to receive a value. (The first element of an array has the index 0.)
Output Parameters
count
Real variable that receives the number of array elements actually
returned by the routine, which may be less than the number requested.
date[ ]
Real array that receives the date values returned. The first value is
returned in date[index]. If an element in the database is undefined, the
corresponding element of date[ ] is set to 0.
time[ ]
Real array that receives the time values returned. The first value is
returned in time[index]. If an element in the database is undefined, the
corresponding element of time[ ] is set to 0.
status
NOTE: If any of the requested array elements do not contain valid data,
the error value for “No valid data in d.b. field” (db.no.data) will be
returned. In that case, any elements that do contain valid data will still
have their values returned.
213
db.get.a.date
Details
This low-level routine returns arrays of date and time values from the specified (array) field of the
current record in the indicated database.
Related Routines
db.get.date
db.put.a.date
214
db.get.a.num
Calling Sequence
CALL db.get.a.num (db, field, first, count, index, number[],
status)
Function
Return an array of real values from an array field of the current record in a database.
Input Parameters
db
field
zero.
first
count
index
array to receive a value. (The first element of an array has the index 0.)
Output Parameters
count
Real variable that receives the number of array elements actually
returned by the routine, which may be less than the number requested.
Note that this includes fields that exist, but do not contain valid data.
number[ ]
Real array that receives the real values returned. The first value is
returned in number[index]. If an element in the database is undefined,
the corresponding element of number[ ] is set to 0.
status
215
db.get.a.num
Details
This low-level routine returns an array of real values from the specified (array) field of the current
record in the indicated database.
Related Routines
db.get.a.nums
db.get.num
db.put.a.num
216
db.get.a.nums
Calling Sequence
CALL db.get.a.nums (db, field, first, count, index, number[],
status)
Function
Return a number of consecutive numeric fields from the current record in a database.
Input Parameters
db
field
Real value specifying the number of the (first) field whose value is to be
returned. This parameter must be greater than or equal to zero.
first
Real value specifying the number of the first element to return from an
array field. This parameter must be set to 0 if the specified field does not
contain an array.
count
Real variable specifying the number of field elements to be returned.
index
Output Parameters
count
Real variable that receives the number of field elements actually returned
by the routine, which may be less than the number requested. Note that
this includes fields that exist, but do not contain valid data.
number[ ]
status
NOTE: If any of the requested field elements do not contain valid data,
Details
This routine returns a specified number of consecutive numeric fields from the current record in
the specified database. The returned values start with the given array element of the indicated
field.
217
db.get.a.nums
All the fields accessed must be numeric (for example, Boolean, integer, real, etc.). However, the
fields accessed do not need to have the same numeric type.
Related Routines
db.get.a.num
db.get.num
db.put.a.nums
218
db.get.a.str
Calling Sequence
CALL db.get.a.str (db, field, first, count, index, $string[],
status)
Function
Return an array of string or name values from an array field of the current record in a database.
Input Parameters
db
field
zero.
first
count
index
Output Parameters
count
by the routine, which may be less than the number requested.
$string[ ]
String array that receives the strings or names returned. The first value is
returned in the element $string[index]. If an array element in the
database is undefined, the corresponding element of $string[ ] is set to an
empty string (“”).
status
219
db.get.a.str
Details
This low-level routine returns an array of string or name values from the specified (array) field of
the current record in the indicated database.
Related Routines
db.get.str
db.put.a.str
220
db.get.a.trans
Calling Sequence
CALL db.get.a.trans (db, field, first, count, index, trans[],
status)
Function
Return an array of transformation values from an array field of the current record in a database.
Input Parameters
db
field
zero.
first
count
index
Output Parameters
count
by the routine, which may be less than the number requested.
trans[ ]
Transformation array that receives the location values returned. The first
value is returned in the element trans[index]. If an array element in the
database is undefined, the corresponding element of trans[ ] is set to
NULL.
status
221
db.get.a.trans
Details
This low-level routine returns an array of transformation values from the specified (array) field of
the current record in the indicated database.
Related Routines
db.get.trans
db.put.a.trans
222
db.get.attr
Calling Sequence
CALL db.get.attr (db, field, attributes, status)
Function
Get the user-attribute value associated with a database field.
Input Parameters
db
field
Real value specifying the number of the field to access. The value must be
greater than or equal to zero.
Output Parameters
attributes
Real variable that receives the user-attribute value associated with the
field. If an error occurs, this variable is set to 0.
status
Details
Each database field can have an arbitrary value associated with it. The value can be used, for
example, to assign to the field attributes that are specific to the current application. The value of
the attributes for a specific database field can be altered using the DBM Utility.
NOTE: Some AIM modules supplied by Adept define the interpretations
of specific attribute bits. See Chapter 3 for the interpretations defined for
attribute bits.
This routine can be used to determine the user-attribute value for the specified field in the
specified database.
223
db.get.c.rec
Calling Sequence
CALL db.get.c.rec (db, offset, $string[], status)
Function
Copy into a string array the entire contents of an open record.
Input Parameters
db
offset
Real variable that specifies the character offset in the string array to the
point at which the record contents are to be copied.
Output Parameters
offset
Real variable that receives the offset in the string array to the character
position immediately following the data from the record.
$string[ ]
String array that receives the record contents.
status
Details
This routine copies into a string array the internal representation of the current record in the
indicated database. This is useful for copying a record to another database—with the routines
db.put.c.rec( ) or db.put.rec( ) used to deposit the record in the second database. For example, this
facility permits a record to be transmitted from one Adept system to another.
Related Routines
db.get.rec
db.put.c.rec
db.put.rec
224
db.get.attr.or
Calling Sequence
CALL db.get.attr.or (db, fields, attr, status)
Function
Return the OR of the user attribute values for all fields of a specified database and the number of
defined fields.
Input Parameter
db
Number of the database that will have its attribute fields searched.
Output Parameters
fields
Number of fields defined for the specified database. The record fields are
numbered from 0 to fields –1.
attr
OR of user attributes for all fields of the database.
status
indicates if the lookup was successful.
225
db.get.date
Calling Sequence
CALL db.get.date (db, field, index, date, time, status)
Function
Return the date and time values from a field of the current record in a database.
Input Parameters
db
field
zero.
index
Real value specifying the number of the element to return from an array
array.
Output Parameters
date
Real variable that receives the date value returned. If an error occurs, this
variable is set to 0.
time
Real variable that receives the time value returned. If an error occurs, this
status
Details
This low-level routine returns the date and time values in the specified field of the current record
in the indicated database.
Related Routines
db.get.a.date
db.put.date
226
db.get.db.stat
Calling Sequence
CALL db.get.db.stat (db, records, del.records, status)
Function
Return information about the status of a database.
Input Parameter
db
Output Parameters
records
Real variable that receives the number of records currently in the
database (including any deleted records). If an error occurs, this variable
is set to 0.
del.records
Real variable that receives the number of records in the database that
have been marked for deletion. If an error occurs, this variable is set to 0.
status
was successful. If the operation was successful, the returned value is a
positive number whose bits indicate whether or not the database has
been modified, if it needs to be sorted, or if non-unique primary sort field
values have been detected (see Details).
Details
This routine returns the following information about the status of the indicated database:
1. The total number of records currently defined in the database.
2. The number of records that are marked for deletion.
3. A “status” bit mask indicating the following conditions:
Value
Meaning
Global Variable
^H1
The database has been modified.
db.modified
^H4
The database needs to be sorted.
db.sort
^H10
The database contains two or more records that
have identical values for the primary sort field, and
the primary sort field is flagged as being unique.
db.dup.entry
^H20
The database is read-only.
db.readonly
227
db.get.file
Calling Sequence
CALL db.get.file (db, $disk, $file, status)
Function
Return the disk and file name specification for an open database.
Input Parameter
db
Output Parameters
$disk
String variable that receives the disk specification for the referenced
database. If an error occurs, this variable is set to an empty string (“”).
$file
String variable that receives the file specification for the referenced
database. If an error occurs, this variable is set to an empty string (“”).
status
Details
This routine returns the full disk and file specifications that were used to open the specified
database. The disk and file specifications returned include the explicit specifications used,
together with the default information extracted from the DBM default disk specification (see
$db.db.disk).
The disk specification consists of an optional disk unit followed by an optional subdirectory
specification. The disk specification may consist of an empty string. The file specification contains
the name and the extension for the database file. The file specification is never empty.
228
db.get.lrec.num
Calling Sequence
CALL db.get.lrec.num (db, p.record, record, status)
Function
Return the logical record number equivalent to a physical record number.
Input Parameters
db
p.record
Real value that specifies the physical record number to be converted.
Output Parameters
record
Real variable that receives the logical record number that is equivalent to
the specified physical record number. If an error occurs, this variable is
set to 0.
status
Details
This routine returns the logical record number that is equivalent to a specified physical record
number for the database of interest. This routine does not require that a record be currently open,
and it does not alter which record is open.
Related Routine
db.get.prec.num
229
db.get.modified
Calling Sequence
CALL db.get.modified (db, date, time, status)
Function
Return the modification date and time for a database.
Input Parameter
db
Output Parameters
date
Real variable that receives the date value returned. If an error occurs, this
time
Real variable that receives the time value returned. If an error occurs, this
status
Details
Each database file has associated with it the date and time it was last modified--that is, the last
time any changes were made to the file. This is not the same as when the database file was last
“updated” (see the routine db.get.update( )).
This routine returns the modification date and time for the indicated database.
Related Routine
db.get.update
230
db.get.num
Calling Sequence
CALL db.get.num (db, field, index, number, status)
Function
Return the real value in a field of the current record in a database.
Input Parameters
db
field
zero.
index
array.
Output Parameters
number
Real variable that receives the real value returned. If an error occurs, this
status
Details
This low-level routine returns the real value in the specified field of the current record in the
indicated database.
Related Routines
db.get.a.num
db.put.num
231
db.get.prec.num
Calling Sequence
CALL db.get.prec.num (db, record, p.record, status)
Function
Return the physical record number equivalent to a logical record number.
Input Parameters
db
record
Real value that specifies the logical record number to be converted.
Output Parameters
p.record
Real variable that receives the physical record number that is equivalent
to the specified logical record number. If an error occurs, this variable is
set to 0.
status
Details
This routine returns the physical record number that is equivalent to a specified logical record
number for the database of interest. This routine does not require that a record be currently open,
and it does not alter which record is open.
Related Routine
db.get.lrec.num
232
db.get.rec
Calling Sequence
CALL db.get.rec (db, record, offset, $string[], status)
Function
Copy into a string array an entire record of a memory-resident database.
Input Parameters
db
Real value specifying the number of the (memory-resident) database to
access. The value must be greater than zero.
record
Real value that specifies the number of the (logical) record to access.
offset
point at which the record contents are to be copied.
Output Parameters
offset
Real variable that receives the offset in the string array to the character
position immediately following the data from the record.
$string[ ]
String array that receives the record contents.
status
Details
This routine copies into a string array the internal representation of the current record in the
indicated (memory-resident) database. This is useful for copying a record to another database-with the routines db.put.c.rec( ) or db.put.rec( ) used to deposit the record in the second database.
For example, this facility permits a record to be transmitted to another Adept system.
Related Routines
db.get.c.rec
db.put.c.rec
db.put.rec
233
db.get.rec.stat
Calling Sequence
CALL db.get.rec.stat (db, record, p.record, status)
Function
Return status information for the current record of a database.
Input Parameter
db
Output Parameters
record
Real variable that receives the logical record number of the record
currently open. If an error occurs, this variable is set to 0.
p.record
Real variable that receives the physical record number of the record
currently open. If an error occurs, this variable is set to 0.
status
was successful. If successful, the returned value is a positive number
whose bits indicate whether or not the record has been modified or
deleted (see below). See Chapter 15 for the values that can be returned.
Details
This routine returns the logical and physical record numbers, and the status, of the record
currently open in the specified database. If the record has been modified or deleted, the returned
status is set to db.modified or db.del, respectively.
234
db.get.str
Calling Sequence
CALL db.get.str (db, field, index, $string, status)
Function
Return the string or name value from a field of the current record in a database.
Input Parameters
db
field
zero.
index
field. This parameter must be set to 0 if the field does not contain an array.
Output Parameters
$string
String variable that receives the string or name returned. If an error
occurs, this variable is set to an empty string (“”).
status
Details
This low-level routine returns the string or name value in the specified field of the current record
Related Routines
db.get.a.str
db.put.str
235
db.get.title
Calling Sequence
CALL db.get.title (db, $string, status)
Function
Read the title string of a database.
Input Parameter
db
Output Parameters
$string
String variable that receives the title of the database. If an error occurs,
this variable is set to an empty string (“”).
status
Details
Each database file has associated with it a text string that can be used to describe the contents of
the database. This routine provides a means to read that title from the indicated database.
Related Routine
db.put.title
236
db.get.trans
Calling Sequence
CALL db.get.trans (db, field, index, trans, status)
Function
Return the transformation value from a field of the current record in a database.
Input Parameters
db
field
zero.
index
array.
Output Parameters
trans
Transformation variable that receives the location value returned. If an
error occurs, this variable is set to the value NULL.
status
Details
This low-level routine returns the transformation value in the specified field of the current record
Related Routines
db.get.a.trans
db.put.trans
237
db.get.update
Calling Sequence
CALL db.get.update (db, date, time, status)
Function
Return the date and time a database was last updated.
Input Parameter
db
Output Parameters
date
Real variable that receives the value representing the date the database
was last updated. If an error occurs, this variable is set to 0.
time
Real variable that receives the value representing the time the database
was last updated. If an error occurs, this variable is set to 0.
status
Details
Each database file has associated with it the date and time it was last updated. This is not the same
as when the database file was last modified or written, but rather indicates the date and time
when a (specially marked) field of a record was last changed via a menu page, or when a program
last called the routine db.set.update( ).1
This routine returns the date and time for the last update of the indicated database.
Related Routines
db.set.update
db.get.modified
1.
238
Chapter 3 describes how to define which fields are associated with modification of the update
date and time.
db.get.user.str
Calling Sequence
CALL db.get.user.str (db, index, $string, status)
Function
Read one of the user scratch strings associated with a database. Read the user scratch string
associated with a database.
Input Parameters
db
index
Real value specifying the number of the user scratch string to access. The
value of this parameter must be 0.
Output Parameters
$string
String variable that receives the scratch string from the database. If an
error occurs, this variable is set to an empty string (””).
status
Details
Each database file has associated with it a maximum of three text strings that can be used to store
general information associated with the database. Presently, only one such text string is allocated
and it is utilized by the system to store miscellaneous information, such as when the database was
last linked and which reference frames are associated with the database.
This routine provides a means to read any of the allocated text strings from the indicated database.
Related Routine
db.put.user.str
239
db.initialize
Calling Sequence
CALL db.initialize ()
Function
Initialize global variables for the database system.
This routine is not reentrant.
Input Parameter
None.
Output Parameter
None.
Details
This routine must be called before any other database routines are called. It defines constants for
the various status values that are returned from the database routines listed below.
See Chapter 15 for information on the variables defined by this initialization routine.
240
db.insert.rec
Calling Sequence
CALL db.insert.rec (db, records, put.before, set.def, status)
Function
Insert a number of new records in a database.
Input Parameters
db
records
Real value specifying the number of new records to add. (If the value is
negative or zero, one new record will be added.)
put.before
Real value (interpreted as TRUE or FALSE) that specifies whether the new
records are to be inserted before (TRUE value) or after (FALSE value) the
current record.
set.def
Real value (interpreted as TRUE or FALSE) that specifies whether or not
the fields of created records are to be set to their default values. If set.def
is TRUE, all field values are set to the values stored in the default record. If
set.def is FALSE, the field values are all set to “undefined”.
Output Parameter
status
Details
This routine inserts a given number of new records in the specified database. The new records are
inserted either before or following the record currently open, depending on the value of the
put.before parameter. Depending on the value of the set.def parameter, the field values of the new
records will either be “undefined”, or they will be set equal to the values stored in the default
record.
The first of the new records is left open for subsequent access.
Related Routines
db.append.rec
db.default.rec
241
db.last.rec
Calling Sequence
CALL db.last.rec (db, status)
Function
Select the last record of a database for access.
Input Parameter
db
Output Parameter
status
Details
This routine can be used to change the record currently open for reading or modifying to be the
last record of the indicated database.
deletion.
occurs.
Related Routines
db.first.rec
db.next.rec
db.open.rec
db.previous.rec
242
db.lookup.field
Calling Sequence
CALL db.lookup.field (db, $field.name, field, status)
Function
Return the field number of the record field with a given name.
Input Parameters
db
$field.name
String value specifying the name of the field to lookup.
Output Parameters
field
Real variable that receives the field number. If an error occurs, this
variable is set to –1.
status
Details
This routine returns the field number of the field with the specified name. That number can then
be used to refer to the field for other operations.
Related Routine
db.lookup.name
243
db.lookup.name
Calling Sequence
CALL db.lookup.name (db, field, $field.name, status)
Function
Return the name of the record field with a given number.
Input Parameters
db
field
Real value specifying the number of the field to lookup. The value must
be greater than or equal to zero.
Output Parameters
$field.name
String variable that receives the field name. If an error occurs, this
variable is set to an empty string (“”).
status
Details
This routine returns the name of the record field with the specified field number.
Related Routine
db.lookup.field
244
db.next.rec
Calling Sequence
CALL db.next.rec (db, status)
Function
Select the next record of a database for access.
Input Parameter
db
Output Parameter
status
Details
This routine can be used to change the record currently open for reading/modifying to be the next
record of the indicated database.
deletion.
occurs.
Related Routines
db.first.rec
db.last.rec
db.open.rec
db.previous.rec
245
db.open.file
Calling Sequence
CALL db.open.file (db, $db.file, rw.mode, records, status)
Function
Open an existing database file for subsequent access.
Input Parameters
db
Real value specifying the number to use when referring to this database.
$db.file
String value, variable, or expression specifying the name of the database
file to be accessed. The disk device containing the file should be included
in the file specification if the file is not on the default disk device (see
$db.db.disk).
rw.mode
Real value that specifies the manner in which the database file can be
modified, if at all. The possible values and their meanings are:
0 Full read-write mode
1 Modify-memory-only mode: any changes made are not written to the
disk
2 or 3 Read-only mode: no changes allowed
records
Real variable specifying the maximum number of records to keep in
memory at one time. If the value is zero, the database will be memory
resident. That is, all the records of the database will be read into the
system memory when the database file is opened.
If a non-zero value is provided, the database will be disk resident and the
magnitude of records specifies the maximum number of records to keep
in memory at any time. If the value is negative, any modifications to the
database will be immediately written out to the disk. Otherwise an
explicit call to the routines to sort, update, and close the database must be
made to insure that all changes have been written out to the disk file.
Output Parameter
status
successfully opened. See Chapter 15 for the values that can be returned.
Details
This is a top-level routine to access records in a database file. This routine opens the indicated
database file for subsequent use.
If the database file is successfully opened, then the first record will be open for reading or
modification.
246
db.open.p.rec
Calling Sequence
CALL db.open.p.rec (db, p.record, status)
Function
Open a specified physical record for reading and modifying.
Input Parameters
db
p.record
Real value that specifies the number of the physical record to open.
Output Parameter
status
Details
This routine opens the specified physical record for reading/modifying.
Logical and physical record numbers provide alternative methods for referring to records within
a database. In most instances, referring to a record by its logical record number is most
convenient. However, in certain circumstances, it is more convenient to refer to a record by its
physical record number. See Chapter 1 for an explanation of the difference between logical and
physical record numbers.
For disk-resident databases, the physical number of a record is always the same as its logical
number, since records are always stored on the disk according to their logical sort order. Therefore,
physical record numbers are not useful when referring to a disk-resident database.
Related Routine
db.open.rec
247
db.open.rec
Calling Sequence
CALL db.open.rec (db, record, status)
Function
Open a specified logical record for reading and modifying.
Input Parameters
db
record
Real value that specifies the number of the logical record to open.
Output Parameter
status
Details
This routine opens the specified logical record for reading/modifying.
Logical and physical record numbers provide alternative methods for referring to records within
a database. In most instances, referring to a record by its logical record number is most
convenient. See “Logical and Physical Record Numbers” on page 19 for an explanation of the
difference between logical and physical record numbers.
Related Routines
db.first.rec
db.last.rec
db.next.rec
db.open.p.rec
db.previous.rec
248
db.previous.rec
Calling Sequence
CALL db.previous.rec (db, status)
Function
Select the previous record of a database for access.
Input Parameter
db
Output Parameter
status
Details
This routine can be used to change the record currently open for reading or modifying to be the
preceding record of the indicated database.
deletion.
occurs.
Related Routines
db.first.rec
db.last.rec
db.next.rec
db.open.rec
249
db.put.a.date
Calling Sequence
CALL db.put.a.date (db, field, first, count, index, date[],
time[], status)
Function
Modify the values of a date-and-time array field in the current record of a database.
Input Parameters
db
field
changed. The value of this parameter must be greater than or equal to
zero.
first
Real value specifying the index number of the first array element to be
changed in the field.
count
Real value specifying the number of array elements to be changed. See
the note under status below.
index
Real value specifying the index number of the first element to access in
the input arrays. (The first element of an array has index 0.)
date[ ]
Real array that specifies the date values to be placed in the record. The
element date[index] contains the first value to be written.
time[ ]
Real array that specifies the time values to be placed in the record. The
element time[index] contains the first value to be written.
Output Parameter
status
NOTE: If an attempt is made to store to a nonexistent array element, the
error value for “invalid d.b. array index” (db.inv.index) will be returned.
In that case, any earlier, valid array elements will have been modified.
Details
This low-level routine modifies the values of the specified date-and-time array field of the current
Related Routines
db.get.a.date
db.put.date
250
db.put.a.num
Calling Sequence
CALL db.put.a.num (db, field, first, count, index, number[],
status)
Function
Modify the values of a numeric array field in the current record in a database.
Input Parameters
db
field
zero.
first
count
index
the input array. (The first element of an array has index 0.)
number[ ]
Real array specifying the new values to be placed in the record. The
element number[index] contains the first value to be written.
Output Parameter
status
Details
This low-level routine modifies the values of the specified real array field of the current record in
the indicated database.
Related Routines
db.get.a.num
db.put.a.nums
db.put.num
251
db.put.a.nums
Calling Sequence
CALL db.put.a.nums (db, field, first, count, index, number[],
status)
Function
Modify the values of consecutive numeric fields of the current record in a database.
Input Parameters
db
field
Real value specifying the number of the (first) field whose values are to
be changed. This parameter must be greater than or equal to zero.
first
Real value specifying the number of the first element to modify in an
array field. This parameter must be set to 0 if the specified field does not
contain an array.
count
Real value specifying the number of field elements to be changed. See the
note under status below.
index
number[ ]
Real array specifying the new values to be placed in the record. The
element number[index] contains the first value to be written.
Output Parameter
status
Details
This routine modifies a specified number of consecutive numeric fields of the current record in the
specified database. The values modified start with the given array element of the indicated field.
Related Routines
db.get.a.nums
db.put.a.num
db.put.num
252
db.put.a.str
Calling Sequence
CALL db.put.a.str (db, field, first, count, index, $string[],
status)
Function
Modify the values of a string or name array field in the current record in a database.
Input Parameters
db
field
zero.
first
count
index
$string[ ]
String array specifying the new string or name values to be placed in the
record. The element $string[index] contains the first value to be written.
Output Parameter
status
Details
This low-level routine modifies the values of the specified string or name array field of the current
record in the indicated database. For name fields, this routine converts input letters to lowercase
and omits any leading and trailing space and tab characters. Also, input names are validated, and
an error is reported if a name is invalid.
Related Routines
db.get.a.str
db.put.str
253
db.put.a.trans
Calling Sequence
CALL db.put.a.trans (db, field, first, count, index, trans[],
status)
Function
Modify the values of a transformation array field in the current record in a database.
Input Parameters
db
field
zero.
first
count
index
trans[ ]
Transformation array specifying the new location values to be placed in
the record. The element trans[index] contains the first value to be written.
Output Parameter
status
Details
This low-level routine modifies the values of the specified transformation array field of the current
Related Routines
db.get.a.trans
db.put.trans
254
db.put.c.rec
Calling Sequence
CALL db.put.c.rec (db, offset, $string[], status)
Function
Overwrite the entire current record of a database with data from a string array.
An error will result if the length of the record information in the string array does not match the
length of the database record currently open.
This routine does not check to make sure that the record information in the string array matches
the field structure of the database record. Thus, care must be taken to ensure that the database
record contains meaningful data.
Any previous field values in the record are lost when the information from the string array is
copied to the record.
Input Parameters
db
offset
point from which the record contents are to be copied.
$string[ ]
String array that contains the new record contents.
Output Parameters
offset
Real variable that receives the character offset in the string array to the
character position immediately following the data defining the record.
status
Details
This routine copies the internal representation of a database record from a string array into the
current open record in the indicated database. This is useful for copying a record from one
database to another—with the routines db.get.rec( ) or db.get.c.rec( ) used to extract the record
contents from the first database. For example, this facility permits a record to be transmitted from
one Adept system to another.
Related Routines
db.get.c.rec
db.get.rec
db.put.rec
255
db.put.date
Calling Sequence
CALL db.put.date (db, field, index, date, time, status)
Function
Modify the value of a date-and-time field in the current record in a database.
Input Parameters
db
field
zero.
index
Real value specifying the number of the element to replace in an array
array.
date
Real value that specifies the date value to be placed in the record.
time
Real value that specifies the time value to be placed in the record.
Output Parameter
status
Details
This low-level routine modifies the value of the specified date-and-time field of the current record
Related Routines
db.get.date
db.put.a.date
256
db.put.num
Calling Sequence
CALL db.put.num (db, field, index, number, status)
Function
Modify the value of a real-value field in the current record of a database.
Input Parameters
db
field
zero.
index
array.
number
Real value specifying the new value to be placed in the record.
Output Parameter
status
Details
This low-level routine modifies the value of the specified real-value field of the current record in
the indicated database.
Related Routines
db.get.num
db.put.a.num
257
db.put.num.tst
Calling Sequence
CALL db.put.num.tst (db, field, index, num, status)
Function
Store a number into the given field of the currently open record.
Input Parameters
db
Number of database to edit.
field
Number of the desired field.
index
Index of array element to store.
num
Number to store in the specified field.
Output Parameter
status
Standard AIM status code.
Details
This routine is identical to db.put.num( ) except that it first reads the current value to see if it is
different from the new value. If there is no difference, the new value is not written which avoids
having the database marked as modified.
Related Routine
db.put.num
258
db.put.rec
Calling Sequence
CALL db.put.rec (db, record, offset, $string[], status)
Function
Copy an entire (memory-resident) database record from a string array.
An error will result if the length of the record information in the string array does not match the
length of the database record to be defined.
This routine does not check to make sure that the record information in the string array matches
the field structure of the database record. Thus, care must be taken to ensure that the database
record contains meaningful data.
Any previous field values in the record are lost when the information from the string array is
copied to the record.
The number of records in the database will be increased if the value of record is larger than the
record number of the last record currently defined.
The database must be memory resident.
Input Parameters
db
Real value specifying the number of the memory-resident database to
access. The value must be greater than zero.
record
Real value that specifies the number of the logical record to access.
offset
point from which the record contents are to be copied.
$string[ ]
String array that contains the new record contents.
Output Parameters
offset
Real variable that receives the character offset in the string array to the
character position immediately following the data defining the record.
status
259
db.put.rec
Details
This routine copies the internal representation of a database record from a string array. This is
useful for copying a record from one database to another—with the routines db.get.rec( ) or
db.get.c.rec( ) used to extract the record contents from the first database. For example, this permits
a record to be transmitted to another Adept system.
Related Routines
db.get.c.rec
db.get.rec
db.put.c.rec
260
db.put.str
Calling Sequence
CALL db.put.str (db, field, index, $string, status)
Function
Modify the value of a string or name field in the current record in a database.
Input Parameters
db
field
zero.
index
array.
$string
String value specifying the new string or name value to be placed in the
record.
Output Parameter
status
Details
This low-level routine modifies the value of the specified string or name field of the current record
in the indicated database. For name fields, this routine converts input letters to lowercase and
omits any leading and trailing space and tab characters. Also, input names are validated, and an
error is reported if the name is invalid.
Related Routines
db.get.str
db.put.a.str
261
db.put.title
Calling Sequence
CALL db.put.title (db, $string, status)
Function
Change the title string of a database.
Input Parameters
db
$string
String value, variable, or expression specifying the new title to assign to
the database.
Output Parameter
status
Details
Each database file has associated with it a text string that can be used to describe the contents of
the database. This routine provides a means to change that title for the indicated database.
Related Routine
db.get.title
262
db.put.trans
Calling Sequence
CALL db.put.trans (db, field, index, trans, status)
Function
Modify the value of a transformation field in the current record in a database.
Input Parameters
db
field
zero.
index
array.
trans
Transformation variable, function, or compound transformation
specifying the new location value to be placed in the record.
Output Parameter
status
Details
This low-level routine modifies the value of the specified transformation field of the current record
Related Routines
db.get.trans
db.put.a.trans
263
db.put.user.str
Calling Sequence
CALL db.put.user.str (db, index, $string, status)
Function
Change one of the user scratch strings for a database. Change the user scratch string for a
database.
Input Parameters
db
index
Real value specifying the number of the user scratch string to access. The
value of this parameter must be 0.
$string
String value, variable, or expression specifying the new scratch string to
assign to the database. (If the string provided is shorter than 128
characters, the selected scratch string is padded with ASCII NUL
characters.)
Output Parameter
status
Details
Each database file has associated with it a maximum of three text strings that can be used to store
general information associated with the database. Presently, only one such text string is allocated
and it is utilized by the system to store miscellaneous information, such as when the database was
last linked and which reference frames are associated with the database.
This routine provides a means to change any of the allocated text strings for the indicated
database.
Related Routine
db.get.user.str
264
db.search.date
Calling Sequence
CALL db.search.date (db, field, index, date, time, match, record,
status)
Function
Search a database for the first record that matches a date-and-time goal.
Input Parameters
db
field
Real value that specifies the number of the field in the record to be used in
the search operation. The value must be greater than or equal to zero.
index
Real value specifying the number of the field array element to be used in
the search operation. This parameter must be set to 0 if the field does not
contain an array.
date
Real value specifying the date value to search for.
time
Real value specifying the time value to search for.
match
Real value specifying the search criterion to use. The value will be
interpreted as follows:
<0
0
>0
record
Before or equal to
Equal to
Equal to or after
Real variable specifying the number of the record to start searching from.
If the value is zero, the search starts from the record following the current
one.
Output Parameters
record
Real variable that receives, if the search is successful, the number of the
record matching the search goal. If there is no match, this parameter will
contain the number of the record open before the search was started.
status
Real variable that receives a value indicating whether or not the search
265
db.search.date
Details
This routine can be used to search the indicated database for the first record in which the specified
field matches the given date-and-time value, considering the criterion set by the match parameter.
If the search is successful, the record found is opened for access.
NOTE: A binary search algorithm is used when searching the primary
sort field of a database that is currently marked as having been sorted,
and when the search criterion calls for finding a date that is equal to or
after the target date. In all other cases, a linear search is performed.
266
db.search.num
Calling Sequence
CALL db.search.num (db, field, index, number, tol, record, status)
Function
Search a database for the first record that matches a real-value goal.
Input Parameters
db
field
index
contain an array.
number
Real value specifying the real value to search for.
tol
Real value specifying the tolerance allowed when matching real values.
That is, any value in the range from (number – tol) to (number + tol) will
be considered a match with number.
record
one.
Output Parameters
record
record matching the search value. If there is no match, this parameter will
contain the number of the record open before the search was started.
status
267
db.search.num
Details
field matches the given real-value value. A tolerance can be specified to set a range of values that
is acceptable. For real values, the tolerance is simply a range of values.
sort field of a database that is currently marked as having been sorted. In
all other cases, a linear search is performed.
268
db.search.str
Calling Sequence
CALL db.search.str (db, field, index, $string, record, status)
Function
Search a database for the first record that matches a string or name goal.
Input Parameters
db
field
index
contain an array.
$string
String value that specifies the string or name to search for.
If there is an asterisk (“∗”) at the end of the string, any string or name that
begins with the characters before the asterisk will be considered as
matching the goal string. For example, if the goal string is foo∗, food and
foot will be considered matches.
If there is an asterisk (“∗”) at the beginning and at the end of the string,
any string or name that contains the characters between the asterisks will
be considered as matching the goal string. For example, if the goal string
is ∗au∗, then auto, taught and tau (and any string containing those
words) will be considered matches. In this case, the search is always done
with a linear-search algorithm (see the note below).
record
one.
Output Parameters
record
record that matches the search string. If there is no match, this parameter
will contain the number of the record open before the search was started.
status
269
db.search.str
Details
field matches the given string value.
sort field of a database that is currently marked as having been sorted. A
linear search is performed in all other cases.
270
db.search.trans
Calling Sequence
CALL db.search.trans (db, field, index, trans, dist, record,
status)
Function
Search a database for the first record that matches a transformation goal.
Input Parameters
db
field
index
contain an array.
trans
Transformation variable, function, or compound transformation,
specifying the location value to search for.
dist
Real value specifying the distance error allowed when matching
transformation locations.
record
one.
Output Parameters
record
record that matches the search goal. If there is no match, this parameter
will contain the number of the record open before the search was started.
status
271
db.search.trans
Details
field matches the given transformation value.
A tolerance can be specified to set a range of values that is acceptable. For transformation values,
the tolerance is a distance (in millimeters, in any direction) from the specified goal value.
NOTE: A linear search algorithm is always employed by this routine.
272
db.set.update
Calling Sequence
CALL db.set.update (db, status)
Function
Set the date and time indicating a database was updated.
Input Parameter
db
Output Parameter
status
Details
Each database file has associated with it the date and time it was last updated. This is not the same
as when the database file was last modified or written, but rather indicates the date and time
when a (specially marked) field of a record was last changed via a menu page or when a program
last called the routine db.set.update( ).1
This routine sets the last-update date and time for the indicated database to be the current date
and time.
Related Routine
db.get.update
1.
Chapter 3 describes how to define which fields are associated with modification of the update
date and time.
273
db.sort.file
Calling Sequence
CALL db.sort.file (db, status)
Function
Sort the records of a database.
Input Parameter
db
Output Parameter
status
Details
This routine forces the file to be sorted and any deleted records to be removed.1 At the conclusion
of the sort operation, the first record of the file will be open for access. For disk-resident databases,
this routine is equivalent to the routine db.update.file( ). For memory-resident databases
db.sort.file( ) affects only the memory copy of the database, while db.update.file( ) causes the
actual disk file to be updated as well. Two auxiliary files (DBMSORT.T∗ and DBMSORT.N∗) are
created when sorting a disk-resident database. The files are deleted when the sort operation is
successfully completed.
Related Routine
db.update.file
1.
274
For memory resident databases, the space occupied by deleted records is recovered for use by
any new records but is not actually returned to free memory.
db.test.open
Calling Sequence
CALL db.test.open ($ifile, db, owner, status)
Function
Search all of the opened databases for a database whose disk file name matches the specified disk
file name. If the database is found, the database number is returned. The owning task of this
database, and the database status are also returned.
Input Parameter
$ifile
Name of the disk file for the database to be located. It is assumed that the
file extension is specified and does not need to be defaulted.
Output Parameters
db
Number of the database in which the file is opened, or –1 if the file in not
open as a database.
owner
Number of the task which owns this database, or –1 if memory resident.
This value is not meaningful if db returns –1.
status
>= 0
<0
Database status flags.
275
db.undelete.rec
Calling Sequence
CALL db.undelete.rec (db, status)
Function
Undelete the current record of a database.
Input Parameter
db
Output Parameter
status
Details
This routine can be used to remove a deletion mark previously placed with the routine
db.delete.rec( ). Recall that records marked for deletion are not actually deleted until the database
is sorted or updated. If this routine is successful, the record will no longer be marked for deletion.
Also, the indicated database will be marked as updated.
Related Routine
db.delete.rec
276
db.update.file
Calling Sequence
CALL db.update.file (db, status)
Function
Sort a database and update its database disk file.
Input Parameter
db
Output Parameter
status
Details
This routine forces the disk file for the indicated database to be sorted, and any deleted records are
removed.1 At the conclusion of the sort operation, the first record of the file will be open for access.
For disk-resident databases, this routine is equivalent to the routine db.sort.file( ). For memoryresident databases db.sort.file( ) affects only the memory copy of the database, while
db.update.file( ) causes the actual disk file to be updated as well.
Related Routine
db.sort.file
1.
For memory resident databases, the space occupied by deleted records is recovered for use by
any new records but is not actually returned to free memory.
277
db.valid.ref
Calling Sequence
CALL db.valid.ref (db, field, index, rec.open, status)
Function
Check the validity of a database number, a field number and array index, and optionally
determine if a record is currently open.
Input Parameters
db
field
Real value specifying the number of the field to be checked.
index
Real value specifying the number of the array element to be checked. This
parameter must be set to 0 if the field does not contain an array.
rec.open
Real value that determines whether or not the routine will check if a
record is currently open. The check will be done if the value of this
parameter is TRUE.
Output Parameter
status
Real variable that receives a value indicating the result of the validity
checks. See Chapter 15 for the values that can be returned.
Details
This routine checks that the requested database number is a legal value, that the database is
currently open, that the requested field is legal for that database, and that the array index is within
bounds.
The checks are performed in that order, and the status parameter is set to the status value that
indicates the first check to fail. The status parameter will be set to db.ok if all the checks are
successful.
If requested with the rec.open parameter, the routine checks if a record is currently open. In that
case, the status parameter will be set to db.no.open.rec if there is no record currently open.
278
Chapter 15
Database Manager Global Variables
The routines in the Database Management Library make use of a number of global variables
during normal operations. All of these globals begin with the prefix db. to avoid any conflict with
global variables defined in other application programs. The global variables used by the database
library programs are defined by the routine db.initialize( ).
You may wish to access some of these global variables in your application programs. Those of
potential interest are listed below.
NOTE: APPLICATION PROGRAMS MUST NOT CHANGE THE
VALUES ASSIGNED TO THE VARIABLES LISTED BELOW (or to any
other db. variables used by the database system).
The actual values associated with the variables described below may
change in future versions of the database system, but the names will
retain their logical significance. Thus, application programs should use
symbolic names in place of explicit constant values to ensure
compatibility with future versions of the database system.
15.1 Status Values Returned By Database Routines
Almost all the database library programs return a status value to indicate the outcome of the
program processing. Table 15-1 lists the values that can be returned, along with their
interpretation and the name of the global variables used to refer to the respective values.
Table 15-1
Status Values Returned by Database Library Routines
Variable
Interpretation
db.ok
General success response
Value
0
Database status bit masks
db.modified
Record or database has been modified
+1
db.del
Record has been deleted (used only by
db.get.rec.stat( ))
+2
db.sort
Database needs to be sorted (used only by
db.get.db.stat( ))
+4
db.upd
Record or database has been updated
+8
db.dup.entry
Duplicate primary sort fields (see below)
+16
db.readonly
Database is read only
+32
279
Chapter 15 - Database Manager Global Variables
Table 15-1
Status Values Returned by Database Library Routines (Continued)
Variable
Interpretation
Value
Error values (values < 0)
db.inv.db.num
Invalid database number (must be > 0)
–2001
db.not.open
Database not open
–2002
db.no.db.file
Database file not found
–2003
db.no.lun
No available logical unit numbers
–2005
db.already.open
Another database is already open using specified
database number
–2006
db.bad.version
Incompatible database version
–2007
db.not.mem.res
Database not memory resident
–2008
db.read.only
Database is read-only
–2009
db.no.field
No such field name
–2010
db.inv.fnum
Invalid field number
–2011
db.bad.type
Field of wrong data type for get or put operation
–2012
db.no.data
No valid data in field
–2013
db.bad.range
Numeric value not in required range
–2014
db.inv.index
Invalid array index
–2015
db.bad.rec.size
Incompatible record size
–2016
db.no.such.rec
No such record
–2020
db.no.match
Search failed to find match
–2021
db.no.open.rec
No record currently open
–2022
db.no.memory
Not enough memory available/allocated
–2040
db.no.more.recs
No more records allowed
–2041
db.inv.name
Invalid name
–2042
Standard V+ error message
<–2000
The status values are grouped into three categories: success, warning and error. As indicated in
Table 15-1, the sign of the status value indicates the category of the condition.
The warning status db.dup.entry requires some additional explanation. This status warns that the
primary sort field of the database has duplicate values although the user has specified that the
primary sort field values should be unique (by setting the sort order of the field to –1 instead of 1).
This warning results whenever the database is sorted if duplicate values are encountered. This
warning status value is also returned by db.get.db.stat( ) when duplicate primary sort field values
280
Symbolic Names For Database Data-type Codes
have been detected previously. (The warning is reset after the duplicate entries are eliminated and
the file is again sorted.)
15.2 Symbolic Names For Database Data-type Codes
The variables listed in Table 15-2 are defined by db.initialize( ) to refer to database data-type code
numbers. These symbolic names may be useful when writing application programs.
Table 15-2
Symbolic Names for Database Data-Type Codes
Symbolic Name
Data Type Represented
db.binary
Binary
db.boolean
Boolean
db.byte
Byte
db.date
Date/time
db.integer
Integer
db.name
Name
db.real
Real
db.string
String
db.trans
Transformation
15.3 Miscellaneous Global Variables
The following global variables are used for the purposes described.
$db.db.disk
This variable is used to specify the default disk drives for database .DB files. The variable is
set to a null string (“”) in the routine db.initialize( ) and can be set by the user program to
indicate the desired default drives.
If a disk drive is specified, the string must contain the drive designation letter and a colon (for
example, “A:”).
When db.create.file( ) is used to create a database, the drive specified in $db.db.disk is used
if no explicit disk drive is specified for the .DB and .RFD files.
Likewise, for db.open.file( ), the drive specified in $db.db.disk is used for the .DB file if no
drive is explicitly specified.
When sorting a disk-resident database, any temporary files created will be stored on the same
disk used by the database.
db.max.blks.srt
Maximum number of disk blocks to read into memory at any time when sorting a diskresident database.
This variable is set to 250 in the routine db.initialize( ). If more memory is available,
increasing this value will result in faster sorting. If the message “Not enough storage area”
281
Chapter 15 - Database Manager Global Variables
occurs, this value must be decreased by your application program after db.initialize( ) is
called.
db.max.db.num
The maximum number of databases allowed, as well as the highest database number that can
be used when opening a database.
282
Chapter 16
Descriptions of Routines in the AIM Base Package
This chapter describes the functions and calling sequences of routines contained in the AIM Base
Package. These routines may be called by application software written by a system customizer.
The routines used by the database manager are detailed in Chapter 14.
Each routine is presented on a separate page, in alphabetical order. The “dictionary page” for each
routine contains the following sections, as applicable:
Calling Sequence
The format of a V+ CALL instruction for the routine is shown.
NOTE: The variable names used for the routine parameters are for
explanation purposes only. Your application program can use any
variable names you want when calling the routine.
NOTE: Some calling sequences will not fit on a single line and are shown
on two lines. However, all calling sequences must be entered on a single
line in V+programs.
Function
This section is used to point out any special considerations associated with use of the routine.
Input Parameters
Each of the input parameters in the calling sequence is described in detail. For parameters that
have a restriction on their acceptable values, the restriction is specified.
Output Parameters
Each of the output parameters in the calling sequence is described in detail.
Global Variables
Global variables accessed by the routine are described.
Details
A complete description of the routine and its use is given.
Related Routines
Other AIM routines, which are related to the function of the current routine, are listed.
283
ai.add.opt.name
Calling Sequence
CALL ai.add.opt.name
($name)
Function
This routine packs a string of module ID names into control variables for subsequent display by
the ID pop-up.
Input Parameter
$name
A string containing the option name.
Output Parameter
None
284
ai.attach.dlun
Calling Sequence
CALL ai.attach.dlun (lun, $dev)
Function
Attach a disk logical unit.
It is the responsibility of the calling routine to DETACH the logical unit when it no longer needs to
be accessed.
Input Parameter
$dev
Optional parameter as to the type of device to be attached. For upward
compatibility, this can be left undefined or “”.
Output Parameter
lun
Real variable that receives the logical unit number used to access the disk.
Details
This routine attaches the first available disk logical unit and returns the logical unit number (LUN)
attached.
It is important that routines that attach logical units detach them as soon as possible, so that the
logical units become available to other routines.
An error message is displayed if no disk logical units are available. In that case, a PAUSE
instruction is executed, suspending execution of the AIM system.
If no LUN’s are available, an error message is printed and a HALT instruction is executed.
See the description of ATTACH( ) in theV+ Language Reference Guide for full details.
285
ai.attach.dlun2
Calling Sequence
CALL ai.attach.dlun2 (lun, $dev, stt)
Function
This routine attaches the first available disk LUN for a specific type of device and returns the
number of the LUN. If no LUN’s are available, an error code is returned.
Input Parameter
$dev
Type of device to be attached (e.g., “NFS”, “DISK”). If no device is
specified (“”), the default device is attached
Output Parameters
286
lun
Number of the attached disk lun.
stt
>=0 if no error occurs. Otherwise, returns error code.
ai.cpy.rn.ctl
Calling Sequence
CALL ai.cpy.rn.ctl (ti, rn.index, ai.index)
Function
Copy a real-valued control variable value from the a runtime task rn.ct[,] array to the ai.ctl[ ] array
for use by the operator interface.
Input Parameters
ti
Task index for the runtime task.
rn.index
rn.ctl[,] control variable right-hand index.
ai.index
ai.ctl[ ] control variable index.
Output Parameter
None.
Details
This program will copy a specified rn.ctl[,] control variable value to a specified ai.ctl[ ] control
variable. See Table 5-1 on page 63 for more information.
Related Routines
ai.set.ctl
ai.set.rn.ctl
287
ai.db.define
Calling Sequence
CALL ai.db.define (type, $px, $icon, icon, $file, run, $type,
$undef, $bname, halt)
Function
Define a database type for use by fixed, shared, and loadable databases. It associates a type code
with various data structures which describe the type and allow access by graphic routines, editors,
menu pages, and modules.
Defines global data structures and global V+ variables. May open a database file.
Input Parameters
288
type
Type code for this database. A number from 1 to 127. User-defined
databases should start at 127 (and work down to 64) so they do not
conflict with Adept defined databases (see Details).
$px
Prefix code used for defining the type and database variables and
extension for the module component file names. May be a 2 or 3 character
(byte) value for runtime databases. (Adept uses exclusively 2-byte values
for this prefix. A 3-byte prefix is recommended for custom databases to
avoid conflicts with existing or future additions from Adept. This code
will be used for the extension on the resource module databases of this
type, therefore, it is important to avoid any conflicts with existing file
extensions.) May be omitted for non runtime databases.
$icon
Name of icon or icon array for this type. This will be used when a
statement tree referencing this database is displayed.
icon
Icon index if $icon is an array name.
$file
Name of fixed (global) database to open for this type. If null, no global
database is opened. If $file is set to “∗”, no database is opened, but a
database number is assigned.
run
TRUE if this is a runtime database, else FALSE.
$type
Name displayed to operator for type selection. Used only if run=TRUE.
This string will be the one displayed for the user when adding a new type
of resource database to a resource module. The first letter should be
capitalized and followed by lowercase letters (for example, “Path”, or
“Frame”).
$undef
Name displayed by sequence editor when argument is undefined. This
string will be used as the argument placeholder for this database in a
blank statement. Should be all lowercase letters proceeded and followed
by two dashes (for example, “--path--” or “--frame--”).
$bname
Base name of .RFD, .DBD, and .MNU files for this type. This string will be
used as the file name for the .RFD, .MNU and .DBD disk files. Therefore, no
extension should be specified. This value is used by the Resource module
when creating new module members, and by the menu driver when
looking for a menu page.
ai.db.define
Output Parameter
halt
TRUE if an error occurred and the operator requested that execution be
terminated.
Details
This routine associates a type code with the following variables and system items:
1. The symbol used to describe the type, which consists of a 2 or 3 byte prefix, followed by a .ty.
For example, xx.ty. See the documentation for any modules you will be using to ensure that
you do not specify a duplicate type code.
2. The symbol used to access the database of that type within a task. This symbol consists of a
2or 3 byte prefix followed by .db. This symbol is a single-dimensioned array, indexed by the
task number. For example, xx.db[TASK( )]. This value is used extensively by statement
routines for accessing the correct database.
3. The name and array index of an icon, used when displaying this database in a tree structure
or on menu pages during editing.
4. The name of this type as displayed to the user when adding a new database of this type to a
resource module.
5. The string used by the sequence editor as a placeholder when prompting for an argument of
this type.
6. The name of the .RFD file used to create new files when a loadable file of this type is added to
a module.
This routine also specifies whether or not databases of this type are runtime databases. A runtime
database can be used by the runtime tasks, as a module component, and linked to other databases.
Any database type which is flagged as runtime can be added to a module via the module
management utilities. If a database type is added to a module, the module’s version of that
database supersedes the global database whenever that module is selected.
When a database is created by the Resource Module, it is automatically assigned a name based on
the arguments to ai.db.define( ).
This routine also allows a file to be opened as a globally accessible fixed database.
Databases 20 to 63 are reserved for Adept fixed databases and database type codes. Databases 64
to 127 are reserved for user-defined fixed databases and database types. Databases 128 to 255 are
allocated dynamically as modules are loaded into memory.
289
ai.dev.define
Calling Sequence
CALL ai.dev.define (device, $name, incpu, robot, halt)
Function
Define and initialize a robot device.
A new element is defined in the device data structure.
Input Parameters
device
Number of the device to be defined.
$name
Name of the device for the operator interface.
incpu
CPU number where the robot is located. If zero, use local CPU. (For AIM
3.0 this must always be 0 or omitted.)
robot
Number of robot on that CPU, 0 if none.
Output Parameter
halt
FALSE if no error, else TRUE if error or the operator requested that
execution be terminated.
Details
This routine will add a new device to the list of devices known by the system. It is called from the
interface task. The routine associates a device name and number with a robot on a particular CPU.
This routine must be called at system initialization.
Related Routine
ai.find.device
290
ai.find.device
Calling Sequence
CALL ai.find.device (device, ti, task, robot, status)
Function
Return information about the task that is assigned to the current device.
Input Parameter
device
ID of device to return information about.
Output Parameters
ti
Task index within runtime data structures for the task with this device.
task
Task number for this device.
robot
Robot number assigned to this task.
status
Standard AIM success/error code.
Details
Output variables are not meaningful if status returns an error.
Related Routine
ai.dev.define
291
ai.get.rn.ctl
Calling Sequence
CALL ai.get.rn.ctl (ti, index, value)
Function
Return a real-valued control variable value from the a runtime task.
Input Parameters
ti
Index for the runtime task (determines the left-hand index for rn.ctl[,]).
index
rn.ctl[,] control variable index (right-hand index).
Output Parameter
value
Real value from the control variable.
Details
This routine will return a value from the rn.ctl[,] control variable array corresponding to the
specified task index (not task) and right-hand index. See Table 5-1 on page 63 for more
information.
Related Routines
ai.copy.rn.ctl
ai.set.ctl
ai.set.rn.ctl
292
ai.key.add
Calling Sequence
CALL ai.key.add ($key[],$str,data)
Function
Add a keyword string and its associated data value to a keyword list.
Input Parameters
$key[ ]
A keyword list data structure.
$str
The keyword string to be added.
data
The associated data value.
Output Parameter
None.
Details
See the program ai.system.mes( ) in TEXT.OV2 for details on creating a keyword list. Keyword lists
can be accessed from menu pages and the sequence editor.
Related Routines
ai.key.new
ai.key.add
ai.key.info
ai.key.get
ai.key.find
ai.key.find.num
ai.key.sort
ai.key.sort.num
293
ai.key.find
Calling Sequence
CALL ai.key.find ($key[], $str, lower, upper, data, index)
Function
Find a keyword in a keyword list.
Input Parameters
$key
$str
A keyword to be found in the list.
lower
Optional lower limit of the index values to search. Clipped at 1.
upper
Optional upper limit of the index value to search. Clipped at max list size.
Output Parameters
data
A real variable which receives the numeric value corresponding to the
keyword found (0 if the keyword is not found).
index
The keyword index, from 1 to n (0 if keyword is not found).
Details
Related Routines
ai.key.new
ai.key.add
ai.key.info
ai.key.get
ai.key find
ai.key.find.num
ai.key.sort
ai.key.sort.num
294
ai.key.find.num
Calling Sequence
CALL ai.key.find.num ($key[], value, lower, upper, $str, index)
Function
Find an entry in a keyword list based on the data value.
Input Parameters
$key[ ]
value
The data value to be found.
lower
Optional lower unit of the index values to search. Clipped at 1.
upper
Optional upper of the index values to search. Clipped at max list size.
Output Parameters
$str
Keyword string (returns NULL if keyword is not found).
index
The keyword index, from 1 to n (returns 0 if keyword is not found).
Details
Related Routines
ai.key.new
ai.key.add
ai.key.info
ai.key.get
ai.key.find
ai.key.find.num:
ai.key.sort
ai.key.sort.num
295
ai.key.get
Calling Sequence
CALL ai.key.get ($key[], index, $str, data)
Function
Returns a keyword from a keyword list
Input Parameters
$key[ ]
index
The index into the keyword list for the keyword to be returned. (1 to n.)
Output Parameters
$str
The keyword string (returns NULL string if index is not valid).
data
The associated data value (returns 0 if index is not valid).
Details
Related Routines
ai.key.new
ai.key.add
ai.key.info
ai.key.get
ai.key.find
ai.key.find.num
ai.key.sort
ai.key.sort.num
296
ai.key.info
Calling Sequence
CALL ai.key.info ($key[], num, last)
Function
This routine returns information about a keyword list.
Input Parameter
$key [ ]
Output Parameters
num
The number of items in this list.
last
Index of the last string used in $key[ ]. If the list is not defined, last = –1.
Details
Related Routines
ai.key.new
ai.key.add
ai.key.info
ai.key.get
ai.key find
ai.key.find.num
ai.key.sort
ai.key.sort.num
297
ai.key.new
Calling Sequence
CALL ai.key.new ($key[])
Function
This routine begins the definition of a new keyword list.
Input Parameter
$key[ ]
A string array to be initialized.
Output Parameter
$key[ ]
An empty, initialized keyword list.
Details
Keyword lists are used by the sequence editor and control panels to display and select items from
a fixed list. These lists can include any common group of elements that you may wish to present to
a user.
Related Routines
ai.key.new
ai.key.add
ai.key.info
ai.key.get
ai.key.find
ai.key.find.num
ai.key.sort
ai.key.sort.num
298
ai.key.sort
Calling Sequence
CALL ai.key.sort ($key[])
Function
This routine sorts a keyword list in ascending order by keyword name.
Input Parameter
$key[ ]
Output Parameter
$key[ ]
Sorted list.
Details
Related Routines
ai.key.new
ai.key.add
ai.key.info
ai.key.get
ai.key.find
ai.key.find.num
ai.key.sort
ai.key.sort.num
299
ai.key.sort.num
Calling Sequence
CALL ai.key.sort.num ($key[])
Function
This routine sorts a keyword list in ascending order by data value.
Input Parameter
$key[ ]
Output Parameter
$key[ ]
Sorted list.
Details
Related Routines
ai.key.new
ai.key.add
ai.key.info
ai.key.get
ai.key.find
ai.key.find.num
ai.key.sort
ai.key.sort.num
300
ai.load.icon
Calling Sequence
CALL ai.load.icon ($file, halt)
Function
Load graphic icons into memory from a disk file.
This routine can be called only during system initialization.
Graphic icons developed by Adept are loaded by the initialization routines for the respective AIM
modules (for example, the Robot Module, Vision Module, etc.). System customizers should add
any new calls of this routine in their own initialization routines.
This routine uses logical units 5 and io.lun2. Both of these logical units are correctly set up during
the AIM initialization process, and they are left in the proper state by this routine. Customizers
should not alter the status of either of these logical units.
Input Parameter
$file
String value that specifies the name of the icon file to load. If no disk unit
is specified, the default data disk unit is assumed.
Output Parameter
halt
Real variable that receives the value TRUE if an error occurred and the
operator has requested that execution be terminated, or FALSE if
processing is to continue.
Details
This routine loads the contents of a graphic-icon disk file that was generated by the Adept Icon
Editing Utility (on the Adept Utility Disk in the file EDITICON.V2). Once the user-developed icons
are loaded, they can be referenced from menu pages in the same fashion as the standard system
icons.
If an error occurs during loading, this routine outputs the error condition and prompts the
operator to determine if system initialization should be continued. The response to that prompt is
returned in the halt parameter.
301
ai.load.init
Calling Sequence
CALL ai.load.init ($file, optional, okay, halt)
Function
This routine processes the AIM initialization files.
This routine should not be used in the command line of an initialization database record to process
another initialization database.
This routine is documented to enhance the customizer’s understanding of the system, but existing
calls to this routine should not be altered.
Input Parameters
$file
String value that specifies the name of the file to be loaded and processed.
optional
Real value that should pass the value TRUE if the file is optional and no
error is to be reported to the operator if the file cannot be found. The
value FALSE should be passed if all processing errors are to be reported.
Output Parameters
okay
Real variable that receives the value TRUE if the file was successfully
processed. Otherwise, the value FALSE is returned.
halt
Real variable that receives the value TRUE if a processing error occurred
and the operator has requested that execution be terminated, or FALSE if
Details
This routine drives through the database files built on the initialization database format defined in
the file INI.RFD. It loads and processes the file name specified by $file input parameter.
If an error occurs during loading or processing and the file is not optional (as indicated by the
optional input parameter), this routine outputs the error condition and prompts the operator to
determine if system initialization should be continued. The response to that prompt is returned in
the halt parameter.
302
ai.load.opt
Calling Sequence
CALL ai.load.opt (mode, $file, $routine, optional, okay, halt)
Function
Load a V+ program file into memory; or load, execute, and delete a program overlay file.
This routine is documented to enhance customizers’ understanding of the system, but existing
calls to this routine should not be altered.
This routine uses logical unit 5. This logical unit is correctly set up during the AIM initialization
process, and it is left in the proper state by this routine. Customizers should not alter the status of
this logical unit.
Input Parameters
mode
Real value that should pass the value 0 if a V+ program file is to be
loaded; or pass the value 1 if a program overlay file is to be loaded,
executed, and deleted.
$file
String value that specifies the name of the file to be loaded. The file name
should include the file extension (for example, .SQU or .OVR).
$routine
String value that specifies the name of a routine within the specified file.
The use of the routine name depends on the “mode” parameter.
If mode is 0, indicating that an overlay file is not being read, $routine
should specify the name of the first program in the file to be loaded. As
an efficiency, if this program already exists in memory, ai.load.opt( ) skips
the loading process and returns a success indication.
If mode is 1, indicating that an overlay file is being read, $routine should
specify the name of the routine within the overlay file that is to be
executed. The calling sequence used for this routine is:
CALLS $routine(halt)
optional
Real value that should pass the value TRUE if the file is optional and no
error is to be reported to the operator if the file cannot be found. The
value FALSE should be passed if all loading errors are to be reported.
Output Parameters
okay
Real variable that receives the value TRUE if the file was successfully
loaded (and the overlay program was successfully executed). Otherwise,
the value FALSE is returned.
halt
Real variable that receives the value TRUE if an error occurred and the
operator has requested that execution be terminated, or FALSE if
303
ai.load.opt
Details
This routine simply loads a program file into memory during the initialization process. Or the
routine loads, executes, and deletes an overlay file. If the file is for an overlay, it must conform to
the following standards:
1. The file must be named with the extension .OVR.
2. The first program in the file must have the same name as the file (including .OVR).
If an error occurs during loading and the file is not optional (as indicated by the optional
parameter), this routine outputs the error condition and prompts the operator to determine if
system initialization should be continued. The response to that prompt is returned in the halt
parameter.
304
ai.log.get
Calling Sequence
CALL ai.log.get (msg[], $msg, status)
Function
Extract the next element from the message log queue. Don’t wait for the queue to be available. If
no data logging is enabled, always returns “empty”.
Data is removed from the logger queue.
Input Parameter
None.
Output Parameters
msg[ ]
If status returns 0:
Error and database information from the message:
msg [0]
msg [1]
msg [2]
msg [3]
msg [4]
msg [5]
msg [6]
msg [7]
msg [8]
msg [9]
msg [10]
$msg
status
Source system address
Source task number
Database number, else 0
Database record number, else –1
Database field number, else –1
Database field array index, else 0
Error/message code
Error/message code extension
Timestamp date
Timestamp time
Timestamp extension
String data from the message
0
1
–1
if message retrieved
if the queue was empty
if the queue was busy
305
ai.mul.add
Calling Sequence
CALL ai.mul.add (type, $file, order, optional, okay, halt)
Function
This routine adds a file to a multiple-database group. The system accesses the group as if it was a
single database.
This routine is normally called from an initialization database record.
Input Parameters
type
The database type code used for this group.
Type code “sd.ty” should be used to add a statement definition database.
Type code “er.ty” should be used to add an error database.
No other type code values should be used.
$file
The name of a .DB file to be added to the group.
This parameter tests to make sure the named file exists.
order
An integer between 1 and 10000 which indicates the order in which
databases are searched. Lower numbers are searched first.
optional
If TRUE, no error is generated if the file is not found, but the file is not
added to the group.
Output Parameters
306
okay
TRUE if this routine executed successfully.
halt
TRUE if this routine failed and the operator requested a system halt.
ai.set.ctl
Calling Sequence
CALL ai.set.ctl (index, value)
Function
Operator interface routine to change the value of the AIM control variables ai.ctl[ ] and rn.ctl[,].
This routine should be called only from the operator interface task.
Input Parameters
index
Real value specifying the control variable to be changed. Normally this is
one of the standard global control variables named cv.∗, which are
defined in the routine ai.cu.define( ) or in the custom routine
cu.cv.define( ).
value
Real value specifying the new value to be placed in the control variable.
Output Parameter
None.
Global Variables
ai.ctl[ ]
Real array that is accessed by the operator control task to interface with
the runtime tasks. This array is indexed by the standard global control
variables named cv.∗.
rn.ctl[,]
Real array that is accessed by the runtime task to interface with the
operator control task. This array tracks the values of some elements in
ai.ctl[ ]. The left hand rn.ctl[,] index value is determined by the task index
in the global variable ex.ti which is set by the operator control panel
routines when a task is selected.
Details
This routine should be called to modify the values of elements in the array ai.ctl[ ], and to update
the corresponding elements in the array rn.ctl[,], if necessary. See Table 5-1 on page 63 for further
information.
NOTE: The operator interface task may freely read the values in the array
ai.ctl[ ], but the interface should never modify the values directly. The
operator interface task should never access the array rn.ctl[,].
Related Routine
ai.get.rn.ctl
307
ai.set.rn.ctl
Calling Sequence
CALL ai.set.rn.ctl (ti, index, value)
Function
Set a real-valued control variable for a runtime task.
Input Parameters
ti
Task index for the runtime task.
index
rn.ctl[,] control variable right-hand index.
value
Real value to be placed in that control variable.
Output Parameter
None.
Details
This routine is called by a runtime task to set a value in the rn.ctl[,] control variable array.
Related Routines
ai.get.rn.ctl
ai.set.ctl
308
ai.task.define
Calling Sequence
CALL ai.task.define (opcpu, task, $name, $device, sched, ti, halt)
Function
Define and initialize a runtime task data structure.
This routine must be called at system initialization.
Input Parameters
opcpu
CPU number where the task will reside. If zero, use local CPU. (In AIM
3.0, this must always be zero or omitted.)
task
Task number (from 0 to n) on that CPU.
$name
Name of the tasks for the operator interface.
$device
Name of the device associated with this task, or null if none.
sched
If TRUE, this task will execute a sequence. If FALSE, this will be a server or
other non-scheduler task.
Output Parameters
ti
If halt is FALSE, this is the task index for the new task. The task index is
used as an input to other routines. If halt is TRUE, returns 0.
halt
If TRUE, an error has occurred and the operator has requested that AIM
execution be halted.
Details
This routine is called from the interface task to create the data structures for a runtime task. This
task can be started from the Task Control Panel or with a START statement. The task can be a
server task or a normal task that executes a sequence.
Related Routines
ai.task.info
ai.task.start
309
ai.task.info
Calling Sequence
CALL ai.task.info (ti, info[], status)
Function
Return information about a given task index.
Input Parameter
ti
Task index of interest (as defined in a call to ai.task.define( )).
Output Parameters
info[ ]
Array containing information about the task index (see Details).
status
A standard AIM status code, or 0 if information is valid.
Details
This routine returns information about a given task index (not a task). The information returned is:
info[0] = mode for this task index
0 = running
1 = teaching
2 = attention
3 = idle
info[1] = cpu for this task index
info[2] = task number for this task index
info[3] = device for this task index
info[4] = robot for this task
info[5] = vision system for this task
Related Routines
ai.task.define
ai.task.start
310
ai.task.prior
Calling Sequence
CALL ai.task.prior (s0, s1, s2, s3, s4, s5, s6, s7, s8, s9, s10,
s11 ,s12, s13, s14, s15, p[])
Function
Return an array of task priorities for use by ai.task.start( ).
Input Parameters
s0 to s15
A priority value for each of the sixteen 1ms time slices.
NOTE: These parameters are required. Use a value of 0 for time slices with no
priority.
Output Parameter
p[ ]
An array of priorities that can be used by ai.task.start( ).
Details
This routine simply returns an array in the correct format for use by ai.task.start( ). See the
description of the EXECUTE program instruction in the V+ Language Reference Guide for
further information on V+ task priorities.
Related Routines
ai.task.define
ai.task.info
ai.task.start
311
ai.task.start
Calling Sequence
CALL ai.task.start (ti, task.num, $routine, prior[], halt, $cmd)
Function
Start an AIM task.
Input Parameters
ti
Task index of the task to start:
–1
use task.num
0
do nothing and exit without error
>0
start the indicated runtime task (returned from ai.task.define( )).
task.num
Task number used only if ti =–1.
$routine
Name of the routine which is executed as the main routine in this task.
prior[ ]
Optional real array of priority values for the task execution.
Output Parameters
halt
TRUE if the operator requested that execution be terminated.
$cmd
I/O command buffer. INTB($cmd,io.qal) will return 0 if no error occurs.
Details
This routine must be called during system initialization from the controlling system. See the
routine ai.module.init( ) in LMOW, LPCB, or LVW for examples of defining and starting a task.
If the task is already active, it is aborted and restarted.
If ti > 0, the corresponding task defined by ai.task.define( ) is started and routine rn.runtime( ) is
called to start the user-supplied $routine.
If ti equals 0, this routine does nothing and exits without error.
If ti equals –1, the user-supplied $routine is started as the main routine in the task indicated by
task.num.
The user-supplied $routine must set the variable ai.task.start=FALSE at the beginning of the
routine. Otherwise, AIM will report an error during initialization.
Related Routines
ai.task.define
ai.task.info
ai.task.prior
312
ai.task.teach
Calling Sequence
CALL ai.task.teach (ti, $rtn, db, record, field, index,
$args, $reply status)
Function
Perform a teaching function by a runtime task.
Input Parameters
ti
The index of the runtime task.
$rtn
Name of the teach routine to be spawned.
db
The number of the database that contains the field to be taught (or zero if
none).
record
The number of the record to be taught.
field
The number of the field being taught.
index
The array index within the field. Zero if not an array.
$arg
String containing additional arguments.
Output Parameters
$reply
Data returned by spawned task, if any.
status
A standard AIM success/error code.
Details
This routine initiates a teach routine in the runtime task indicated by ti. The routine waits until the
teaching function is complete.
See the program mu.teach( ) (ROBUSR.V2) for the format of a spawn routine calling
ai.task.teach( ).
See the program rn.teach.robot( ) (ROBOT.OV2) for an example of a teach routine.
313
call
Calling Sequence
CALL call (args[], error)
Function
Runtime routine for the CALL statement.
Input Parameter
args[ ]
Output Parameter
error
Syntax:
CALL sequence
Details
Argument
sequence
File:
Type or Database
sequence name
Misc.
optional
Formal parameter name
args[1]
CNDRUN.V2
Statement DB: STATBASE.DB
Related Routine
return
314
case
Calling Sequence
CALL case (args[], error)
Function
This routine is called from the runtime scheduler when it encounters a CASE statement.
Input Parameter
args[ ]
Output Parameter
error
Syntax:
CASE {uopr} var1 {opr1 var2 {opr2 var3 ... }...} OF
Details
Argument
Type or Database
Misc.
optional
Formal Parameter Name
uopr
Unary operator
args[1]
var1
variable
opr1
Binary operator
optional
args[3]
var2
variable
optional
args[4]
...
...
...
...
opr5
Binary operator
optional
args[11]
var6
variable
optional
args[12]
args[2]
null
args[13]
next
[statement number]
from linker
args[15]
end
[statement number]
from linker
args[16]
315
cu.cs.define
Calling Sequence
CALL cu.cs.define ()
Function
This routine defines how the elements of the global control string array $ai.ctl[ ] are allocated.
$ai.ctl[ ] is used to store string variables including those accessed by the menu pages.
This routine is executed once when the system is started.
cs.free is the first available element.
Input Parameter
None.
Output Parameter
None.
Details
The standard AIM elements are defined in the routine ai.cs.define( ) in the file PUBLIC.OV2. They
should not be modified.
New elements of $ai.ctl[ ] can be freely added to customize the system, starting with the value of
the global variable cs.free. For clarity, the names of the indices of the $ai.ctl[ ] array all begin with
“cs.”.
Related Routine
ai.cs.define
316
cu.cv.define
Calling Sequence
CALL cu.cv.define ()
Function
This routine defines how elements of the global control array ai.ctl[ ] are allocated. ai.ctl[ ] is used
to store key system variables including those that are accessed by the menu pages.
This routine is executed once when the system is started.
cv.free is the first available element.
Input Parameter
None.
Output Parameter
None.
Details
The standard AIM elements are defined in the routine ai.cv.define( ) in the file PUBLIC.OV2. They
should not be modified.
New elements of ai.ctl[ ] can be freely added to customize the system, starting with the value of
the global variable cv.free. For clarity, the names of the indices of the ai.ctl[ ] array all begin with
“cv.”.
Related Routine
ai.cv.define
317
cu.define.dbs
Calling Sequence
CALL cu.define.dbs (halt)
Function
Customizable routine that defines and optionally loads application databases.
Input Parameter
None.
Output Parameter
halt
terminated.
Details
This routine is called at system startup to open global databases and to define database types
which may be parts of modules.
To add another database type, add another call to the routine ai.db.define( ). Note that database
types are also defined in the overlays for options and applications.
See the routine ai.db.define( ) for details.
Related Routine
ai.db.define
318
cu.error.notify
Calling Sequence
CALL cu.error.notify (ti, level, error.number, error.qualifier,
$message)
Function
Customizable routine for responding to AIM runtime errors.
This routine should not be called from user programs—it is automatically called by AIM when
appropriate. The following documentation is provided for customizers who want to tailor this
routine to their applications.
Input Parameters
ti
The task index from 1 to n of a runtime task whose mode is changing to
“attention”. This value is returned by ai.task.define( ) when runtime
tasks are defined (normally in ai.module.init( )). When a value of zero is
received, the error is generated directly by the primary operator interface
task. This routine is not called for any secondary operator interface tasks.
level
A real variable which contains the current nesting level for this error.
Starts at zero and increases for nested errors. The level numbers for each
ti value are independent. Some levels may be skipped for the operator
interface task.
error.number
A real variable that contains the error number or zero. If zero, the error
condition for this task has been cleared.
error.qualifier
A real variable that contains the error qualifier associated with
error.number, if the error was a variable format message. Equivalent to
system function ERROR(–1,1).
$message
An optional message string associated with this error.
Output Parameter
None.
Details
This routine is called from the status and control task whenever an error pop-up or runtime error
is processed.
If error.number is negative, it contains a standard AIM error code for the error being processed. If
error.number parameter is zero, the error condition is being cleared.
It may be used to set global variables or output signals as desired to reflect the status of any tasks.
This routine must execute quickly so that status and control messages are not slowed down.
Related Routine
ai.task.info
319
cu.initialize
Calling Sequence
CALL cu.initialize ()
Function
Initialize global variables and define constants to customize AIM for specific applications.
This routine is executed early in the AIM startup sequence. No input or output via the I/O
routines (io.∗( )) or menu window is permitted.
Input Parameter
None.
Output Parameter
None.
Details
The following value defines the disk unit from which all data files (.DAT, .DB, .HLP, .MNU, .RFD,
.VS) are read.
$cu.dat.disk = ""
;Default disk unit
If the value is equal to null, the corresponding files are read from the default disk. If not null (e.g.,
“A:”, “B:”), the files are read from the specified unit. The value can include both a disk unit and a
subdirectory specification. Overlay files are always read from the default disk.
$cu.dat.disk cannot be placed in an initialization database because:
1. Several databases must be opened (e.g., the error database) before the initialization database
is processed.
2. $cu.dat.disk is used to find the initialization database.
320
cu.initialize2
Calling Sequence
CALL cu.initialize2 (halt)
Function
Initialize global definitions of database field numbers (same as cu.initialize( )).
Input Parameter
None.
Output Parameter
halt
terminated.
Details
This routine is executed once after all of the databases have been opened, all tasks have been
defined, and all application software modules have been loaded. The menu routine may be called
from this routine.
321
cu.module.init
Calling Sequence
CALL cu.module.init (halt)
Function
Perform custom module initialization.
The standard menu routines can be called as desired.
Input Parameter
None.
Output Parameter
halt
terminated.
Details
This routine is called once from the ai.module.init( ) routine after all AIM modules have been
loaded, the standard devices and tasks have been defined, but before the tasks are started.
This routine may load additional routines, define additional devices and tasks, and startup
additional tasks.
I/O to lun io.lun appears in the startup initialization window.
Related Routine
ai.module.init
322
cu.mu.reacte
Calling Sequence
CALL cu.mu.reacte (error.number, error.qualifier, $cmd)
Function
Customizable routine called when a REACTE condition occurs in a runtime task.
Input Parameters
error.number
A real variable that contains the error number that caused the REACTE.
Equivalent to system function ERROR(–1) when the reaction is entered.
This is also an output parameter.
error.qualifier
A real variable that contains the error qualifier associated with
error.number, if the error was a variable format message. Equivalent to
system function ERROR(–1,1) when the reaction is entered. This is also an
output parameter.
Output Parameters
error.number
The error number value to be processed within the system error reaction
routine. If 0, this error is ignored. Only V+ error numbers can be returned.
error.qualifier
The error qualifier value associated with error.number.
$cmd
Standard I/O command buffer. If not NULL, this command is issued to
the menu driver for execution.
Details
This routine allows system customizers to service errors from the operator interface task. It is
called from the operator interface REACTE error servicing routine whenever an error occurs.
The user can take whatever action he desires and return a command to be executed by the
operator interface task.
No menu routines should be called from within this task. Use the $cmd output to request menu
routine service.
Related Routine
cu.reacte
323
cu.reacte
Calling Sequence
CALL cu.reacte (error.number, error.qualifier, error.type)
Function
Provide access to the processing of error conditions.
Care must be exercised when modifying information associated with motion and vision errors to
prevent the internal AIM handling of the error from being disabled.
Each of the input parameters is also an output parameter. Thus, each parameter must be specified
as a variable if the output result is desired.
Input Parameters
error.number
Real variable specifying the error code for the error that caused the
REACTE to be triggered. (The value passed was obtained with the V+
function ERROR(–1) when the error reaction occurred.)
error.qualifier
Real variable specifying a qualifier associated with the error defined by
error.number if that error has a variable-format message. (The value
passed was obtained with the V+ function ERROR(–1,1) when the error
reaction occurred.)
error.type
Real variable specifying the type of the error defined by error.number.
This may have one of three values:
Value
Interpretation
0
Unexpected programming error
1
Robot motion error
2
Vision operation error
Output Parameters
324
error.number
Real variable that receives the error number to be subsequently processed
by the AIM system error-reaction routine. The error is ignored if the value
returned by this parameter is zero. The value returned must be a valid V+
error number.
error.qualifier
Real variable that receives the error qualifier associated with the error
number returned by error.number.
error.type
Real variable that receives the type code for the error defined by
error.number. It must be one of the values listed in the table above.
cu.reacte
Details
This routine allows system customizers to service errors from any AIM runtime task. This routine
is called from the AIM system REACTE error-servicing routine whenever an error occurs. See the
description of the REACTE instruction in the V+ Language Reference Guide for more information on
servicing errors. Use TASK( ) to determine which runtime task is calling cu.reacte( )
This routine can examine the error number and take whatever action is appropriate. If the error
number is modified by this routine, the AIM REACTE routine uses the new number during its
processing.
If the error number is modified, the proper error type must be returned. The error type determines
whether an error is reported as a crash to the operator, or if it is handled by the robot or vision
system.
If error information related to a motion or vision error is modified, the internal AIM handling of
the error condition may be disabled. Thus, you should be careful when processing such errors.
Do not attempt to re-arm the REACTE by issuing the V+ REACTE instruction within this routine.
The AIM REACTE routine will manage that process.
Related Routine
cu.mu.reacte
325
cu.set.mode
Calling Sequence
CALL cu.set.mode (ti, mode)
Function
Customizable routine that can be used to respond to changes in system modes.
Input Parameters
ti
The task index from 1 to n of a runtime task whose mode is changing.
This value is returned from ai.task.define( ) when a runtime task is
defined. When a value of zero is received, the global AIM cell mode is
being changed.
mode
The new mode for the indicated runtime task or the entire AIM cell. The
possible modes and their global variables are:
Variable name
Mode
rn.mode.exec
Running
rn.mode.teach
Teach mode
rn.mode.owait
Operator attention
rn.mode.iwait
Idle wait
Output Parameter
None.
Details
This routine is called from the status and control task whenever the mode of a runtime task
changes.
It may be used to set global variables or output signals as desired to reflect the status of any task.
This routine must execute quickly so that status and control messages are not slowed down.
Related Routine
ai.task.info
326
cu.sched.start
Calling Sequence
CALL cu.sched.start (error)
Function
Performs custom runtime initialization when a runtime scheduler is started.
Input Parameter
None.
Output Parameter
error
Details
cu.sched.start( ) is called from the AIM routine rn.sched.start( ) which is in turn called from the
standard AIM scheduler routine rn.sched( ). This routine should be used instead of modifying
rn.sched( ) when there is a need to perform custom operations at the time the runtime scheduler
begins operation.
Related Routine
rn.sched.start
327
cu.set.mode
Calling Sequence
CALL cu.set.mode (ti, mode)
Function
This routine is called form the status and control task whenever the mode of a runtime task
changes.
This routine may be used to set global variables or output signals, as desired, to reflect the status
of any tasks.
Input Parameter
ti
The task index from 1 to n of a runtime task whose mode is changing.
This value may be obtained as an output parameter from the call to
ai.task.define( ) in your ai.module.init( ) routine. A value of 0 indicates
the global AIM cell mode is being changed.
mode
The new mode for the indicated runtime task or the entire AIM cell, as
indicated by the ti input parameter. Possible values are:
Variable
Description
rn.mode.exec
Running
rn.mode.teach
Teach mode
rn.mode.owait
Operator attention
rn.mode.iwait
Idle wait
Output Parameter
None.
Details
cu.set.mode( ) is called from the status and control task whenever the mode of a runtime task
changes. It may take any action that is appropriate for the mode change. For example, it may be
used to set output signals that are connected to lights on an external status control panel.
Related Routine
cu.error.notify
328
cu.shutdown
Calling Sequence
CALL cu.shutdown ()
Function
Customizable routine that can be used to perform any required custom shutdown procedures.
Input Parameter
None.
Output Parameter
None.
Details
This routine is executed after the operator has confirmed that the system is to halt execution. After
this routine is executed, all changed databases will be written to their disk files, any vision
prototype or OCR data will be stored on the disk, the system LUNs and windows will be
deallocated, and all tasks will terminate execution.
Related Routine
cu.startup
329
cu.sig.define
Calling Sequence
CALL cu.sig.define ()
Function
This routine initializes the variables for the internal soft panic signal and for pendant control of the
robot tool.
Input Parameter
None.
Output Parameter
None.
Details
This routine defines pendant display signals and labels. The $ai.pendant.sig[ ] array contains
packed 13-character string labels. Corresponding to each label, the $ai.pendant.srtn[ ] contains a
15-character string that is the name of an optional routine that is called before the signals are
altered.
In addition, the ai.pendant.sig[0,_] variable contains the number of the signal that is turned on
when the label is read as a TRUE condition. The ai.pendant.sig[1,_] variable contains the number
of the signal that is turned off. The signal states are reversed for a FALSE condition.
Related Routine
rn.pe.signal
330
cu.startup
Calling Sequence
CALL cu.startup ($cmd)
Function
Customizable routine that can be used to perform any required custom startup procedures.
May select and start sequence execution.
Input Parameters
None.
Output Parameter
$cmd
Must be set to a standard menu command string. This string is the first
menu command executed after initialization.
Details
This routine is called from the operator control task after all system initialization has been
completed.
It may be customized as necessary for special application.
The default action is described below:
• If no autostart sequence is present, the “system_id” menu page from the SYSTEM.MNU file is
displayed.
• If any autostart sequence is specified, then it is loaded and executed started.
The control strings $ai.ctl[cs.auto.mod] and $ai.ctl[cs.auto.seq] contain the names of the module
and sequence to be executed in the operator control task when execution begins. If either string is
null, no autostart is executed. It is assumed that the autostart sequence will load modules and
sequences and then execute runtime tasks as necessary.
This routine always closes the “AIM Initialization” window.
A system customer can disable automatic AIM startup during debugging, as follows:
• If the global variable cu.ask.start is set to TRUE before starting AIM, a popup is displayed at
startup asking if the user wants to continue with normal startup.
• If Continue is selected, AIM continues normally.
• If Cancel is selected, AIM bypasses calling the routine cu.startup( ) and any automatic
startup it may specify.
Related Routine
cu.shutdown
331
cu.task.init
Calling Sequence
CALL cu.task.init (task, gad, robot, device)
Function
Performs custom initialization when a task is defined during system initialization.
Input Parameters
task
Task number from 0 to n. (This is not the task index.)
gad
Address of the controlling system for this group.
robot
Number of robot device, 0 if none.
device
Optional system-wide device identification (ID) for the robot. If omitted,
this is the same as the robot value.
Output Parameter
None.
Details
cu.task.init( ) is called indirectly from ai.task.define( ) whenever a runtime task is defined. This
routine may set up custom data structures on a per-task basis during system initialization.
Related Routine
ai.task.define
332
dv.cli.abort
Calling Sequence
CALL dv.cli.abort (dv.id, msg.id, status)
Function
Abort the outstanding request or reply for the specified message ID.
Input Parameters
dv.id
ID of the FIFO queue to which the request was sent. The ID is obtained by
calling dv.cli.connect( ).
msg.id
ID supplied by a previous call to dv.cli.send( ).
Output Parameter
status
Details
This routine is called by the client task when it wants to abort a request that it has made to a server
task. If successful, this routine will cancel any pending requests and remove the reply from the
queue.
Related Routines
dv.cli.abort
dv.cli.connect
dv.cli.send
dv.cli.init
dv.cli.reply
dv.srv.connect
dv.srv.disable
dv.srv.enable
dv.srv.recv
dv.srv.reply
333
dv.cli.connect
Calling Sequence
CALL dv.cli.connect (ti, dv.id, status)
Function
Connect the current client task to a server task and test if it is ready.
The routine dv.cli.init( ) must be called before this routine.
Input Parameter
ti
Task ID of the server task to which we are connecting.
Output Parameters
dv.id
If status equals 0, the queue ID number for sending to this server,
otherwise 0.
If status equals ec.srv.nena (–2401) the server task is not ready to accept
connections. Wait briefly, and then try again.
status
Details
If this routine is successful, the client task may use the returned queue ID to interact with the
server task.
Related Routines
dv.cli.abort
dv.cli.send
dv.cli.init
dv.cli.reply
dv.srv.connect
dv.srv.disable
dv.srv.enable
dv.srv.recv
dv.srv.reply
rn.cli.connect
334
dv.cli.init
Calling Sequence
CALL dv.cli.init (reply.num)
Function
Initialize the current task as a client task and initialize the reply FIFO (first-in, first-out) queue.
It must be called before any other client task routine.
Input Parameter
reply.num
Number of outstanding replies which are expected by this task. Set to the
number of expected server connections, plus one.
Output Parameter
None.
Details
This routine will create a new queue if one does not exist and will clear the queue if it already
exists. This is the basic data structure for exchanging requests with server tasks.
Related Routines
dv.cli.connect
dv.cli.abort
dv.cli.send
dv.cli.reply
dv.srv.connect
dv.srv.disable
dv.srv.enable
dv.srv.recv
dv.srv.reply
335
dv.cli.reply
Calling Sequence
CALL dv.cli.reply (dv.id, msg.id, $reply, status)
Function
Read a reply for a request that was previously sent with dv.cli.send( ). If the reply is present, it is
returned, otherwise this routine indicates that the request is “not complete”.
The system does not keep track of all outstanding requests, therefore, if this routine is called with
a non-existent message ID, it will return “not complete” and not report an error.
Input Parameters
dv.id
ID of the FIFO queue to which the original request was sent, returned by a
call to dv.cli.connect( ).
msg.id
ID returned by a previous call to dv.cli.send( ). This ID is used to
determine which request this is a reply to.
Output Parameters
$reply
If status returns success, this parameter contains the reply data.
status
Details
This routine is called by the client task after a request is made by a call to dv.cli.send( ). When
status returns success, the requested data is returned in $reply.
Related Routines
dv.cli.connect
dv.cli.abort
dv.cli.send
dv.cli.init
dv.srv.connect
dv.srv.disable
dv.srv.enable
dv.srv.recv
dv.srv.reply
rn.cli.reply
336
dv.cli.send
Calling Sequence
CALL dv.cli.send (dv.id, func, qual, $data, msg.id, status)
Function
Send a request from a client task to a server task.
Input Parameters
dv.id
ID of the FIFO queue to which the requests are sent. This ID is returned by
a call to dv.cli.connect( ).
func
Function code. Used by the driver task to determine the nature of this
request.
qual
Function code qualifier. Used by the driver task to determine the nature
of this request.
$data
A string of up to 112 bytes sent as data for this request
Output Parameters
msg.id
If status returns success, an ID code that identifies this request. This ID
will be passed to dv.cli.reply( ) to identify this request.
status
Details
The valid function code and qualifier values are determined by the particular server task.
Related Routines
dv.cli.connect
dv.cli.abort
dv.cli.reply
dv.cli.init
dv.srv.connect
dv.srv.disable
dv.srv.enable
dv.srv.recv
dv.srv.reply
rn.cli.send
337
dv.srv.connect
Calling Sequence
CALL dv.srv.connect (req.num, status)
Function
Connect the current task to receive server requests, however, the receive FIFO queue is left
disabled and must be enabled by calling dv.srv.enable( ).
Input Parameter
req.num
Number of outstanding requests that are expected by this task.
Output Parameter
status
Standard AIM status code
Details
This routine is called when a server task is first started to initialize the data structures for
exchanging information with a client task. If the receive FIFO queue does not exist, it is created. If it
does exist, it is cleared.
Related Routines
dv.cli.abort
dv.cli.connect
dv.cli.send
dv.cli.init
dv.cli.reply
dv.srv.connect
dv.srv.disable
dv.srv.enable
dv.srv.recv
dv.srv.reply
338
dv.srv.disable
Calling Sequence
CALL dv.srv.disable (status)
Function
Disable the receiver FIFO queue and aborts any requests which may have been pending.
Input Parameter
None.
Output Parameter
status
Details
This routine is called from a server task to disable access to the queues used to exchange data with
client tasks. Before the queues can be used again, the server task must call dv.srv.enable( ).
Related Routines
dv.cli.abort
dv.cli.connect
dv.cli.send
dv.cli.init
dv.cli.reply
dv.srv.connect
dv.srv.enable
dv.srv.recv
dv.srv.reply
339
dv.srv.enable
Calling Sequence
CALL dv.srv.enable (status)
Function
Enables the receiver FIFO queue for the current task.
Input Parameter
None.
Output Parameter
status
Details
This routine is called from a server task to enable the queues for exchanging data with client tasks.
This called must have been preceded by a call to dv.srv.connect( ).
Related Routines
dv.cli.abort
dv.cli.connect
dv.cli.send
dv.cli.init
dv.cli.reply
dv.srv.connect
dv.srv.disable
dv.srv.recv
dv.srv.reply
340
dv.srv.recv
Calling Sequence
CALL dv.srv.recv ($msg, func, qual, $data, status)
Function
Receive the next message for this task, if any are present.
It returns an error code if there are no messages. It is called from a server task.
Input Parameters
None.
Output Parameters
$msg
If status = success, returns the entire message (including the header), else
NULL.
func
If status = success, function code from message (sent by client in original
request), else 0.
qual
If status = success, qualifier code from message (sent by client in original
request), else 0.
$data
If status = success, data section of message, else NULL.
status
0 success
1 no message received
<0 if an error occurred, standard AIM status code
Details
This routine is called from a server task to see if any messages have been posted to the queue by a
client task. Normally, the server task would process the request and return the data in a call to
dv.srv.reply( ).
Related Routines
dv.cli.abort
dv.cli.connect
dv.cli.send
dv.cli.init
dv.cli.reply
dv.srv.connect
dv.srv.disable
dv.srv.enable
dv.srv.reply
341
dv.srv.reply
Calling Sequence
CALL dv.srv.reply ($msg, $data, status)
Function
Send a reply to a client task. The client task address is read from the $msg input buffer.
Input Parameters
$msg
Original input buffer from dv.cli.recv( )
$data
Data to be sent as reply
Output Parameter
status
Standard AIM status code. If 0, the reply succeeded. If ec.iebsy, the
request failed because the client queue is full.
Details
This routine is called by a server task to return information in response to a request from a client
task. This routine will not wait if the specified queue is full.
Related Routines
dv.cli.abort
dv.cli.connect
dv.cli.send
dv.cli.init
dv.cli.reply
dv.srv.connect
dv.srv.disable
dv.srv.enable
dv.srv.recv
rn.srv.reply
342
else
Calling Sequence
CALL else (args[], error)
Function
This routine is called from the runtime scheduler when it encounters an ELSE statement.
Input Parameter
args[ ]
Output Parameter
error
Syntax:
ELSE {IF {uopr} var1 {opr1 var2 {opr2 var3...} }}
Details
Argument
Type or Database
Misc.
uopr
Unary operator
optional
args[1]
var1
variable
optional
args[2]
opr1
Binary operator
optional
args[3]
var2
variable
optional
args[4]
...
...
...
...
opr5
Binary operator
optional
args[11]
var6
variable
optional
args[12]
truth
[value index]
from linker
args[14]
next
[statement number]
from linker
args[16]
File:
CNDRUN.V2
343
end
Calling Sequence
CALL end (args[], error)
Function
This routine is called from the runtime scheduler when it encounters an END statement.
Input Parameter
args[ ]
Output Parameter
error
Syntax:
END
Details
Argument
loop
Type or Database
[value index]
Misc.
from linker
args[14]
(loop used by REPEAT...END and FOR...END only)
type
[conditional token]
from linker
args[15]
next
[statement number]
from linker
args[16]
File:
CNDRUN.V2
344
er.error
Calling Sequence
CALL er.error (error, vcode, index, color, $err)
Function
Return the terse error message string for a specified error code.
Input Parameters
error
Error code to be converted.
vcode
Variable part of the error code. For V + bit-encoded values, this is the
number of the MSB+1. Ignored if error code is out of the V + variable error
range.
Output Parameters
index
Group index number for the database containing this error, or zero if no
database.
color
Unused, always set to zero.
$err
String describing the error.
Details
The error code is written into the global variable, er.last.error. The index is written into the global
variable er.last.index. These values are used by other routines to display the last error processed
by the system.
If the error code corresponds to a user-defined error, the message for the user error is returned. If
no error is defined, the V+ error message is returned. If no V+ error message exists, the number of
the error code is returned.
er.load( ) must have been called previously to extract the user error messages from the error
database.
345
ex.control
Calling Sequence
CALL ex.control (ti, display, function, arg1, arg2, $str, status)
Function
General interface routine for execution and control.
May change global variables and the runtime state.
Input Parameters
ti
The index of the runtime task to be affected. Can be obtained from
ai.task.info( ), or ai.task.define( ).
display
If TRUE, allow error or informational pop-ups to appear. If FALSE,
suppress all screen output.
function
Function code. Must have one of the values described in Details.
arg1
Optional real value, use depends on function code.
arg2
Optional real value, use depends on function code.
$str
Optional string value, use depends on function code.
Output Parameter
status
If function equals ex.ctl.get.err:
Standard AIM status value corresponding to the last error received from
the runtime. Zero if no last error, or AIM is not in the correct state to
display the error.
If function equals ex.ctl.get.stat:
<0
Standard AIM error code, else
0
Executing
1
Teach mode
2
Operator attention
3
Idle
All other values of function, standard AIM status value indicating if the
function was performed correctly. Zero if no error.
Details
This routine performs various functions to interact with the runtime tasks. It is called from menu
routines referenced by the operator control panel and from other routines that implement the
hardware control panel.
The function code determines the action of this routine. It must be one of the global variables
described below:
ex.ctl.check
346
Check if runtime is idle and select/start is OK.
No input arguments.
status returns 0 if OK, else error code
ex.control
ex.ctl.select
Select sequence for execution
$str
new sequence name.
status returns 0 if OK, else error code.
ex.ctl.module
Select module for execution
$str
new module name.
ex.ctl.start
Start sequence execution
No input arguments.
ex.ctl.response Send operator response
arg1
operator response code:
0
Proceed runtime execution.
1
Retry action
2
Skip to next action
3
Retry statement
4
Skip to next statement
5
Skip to next sequence
6
Stop scheduler
ex.ctl.pause
Set pause condition
arg1
Pause type:
1
Pause at end of operation
2
Pause at end of action
3
Pause at end of statement
4
Pause at end of cycle
5
Pause immediately
arg2
0
1
2
3
status
Change code:
Clear all pause flags (ignore arg1)
Set the pause
Clear the pause
Toggle the pause
returns 0 if OK, else error code.
ex.ctl.stop
Set stop condition
arg1
Stop type:
1
Stop at end of operation
2
Stop at end of action
3
Stop at end of statement
4
Stop at end of cycle
5
Stop immediately
ex.ctl.edit
Edit database
No input arguments.
347
ex.control
ex.ctl.get.err
Returns last saved error or response code in status
arg1
Error type
−2
–1
0
1
2
3
4
5
6
status
ex.ctl.get.stat
348
Last saved message code
Last saved error code
Proceed message
Retry action message
Skip to next action message
Retry statement message
Skip to next statement message
Skip to next sequence message
Stop scheduler message
returns 0 if no error, else last error code.
Returns current task status.
No input arguments.
status returned as follows:
0
Executing
1
Teach mode
2
Operator attention
3
Idle
exit_loop
Calling Sequence
CALL exit_loop (args[], error)
Function
This routine is called from the runtime scheduler when it encounters an EXIT_LOOP statement.
Input Parameter
args[ ]
Output Parameter
error
Syntax:
EXIT_LOOP {constant}
Details
Argument
Type or Database
Misc.
count
Constant
Optional
args[1]
next
[statement number]
from linker
args[16]
File:
CNDRUN.V2
349
ex.mu.status
Calling Sequence
CALL ex.mu.status (arg, mode, db.p, lun, luns[], $cmd)
Function
A menu page user routine called each time the status and control page is drawn or refreshed.
Input Parameters
arg
This is the contents of the “routine argument”
The low byte of the value is interpreted as follows:
0 No menu page being displayed, routine called from external polling
routine.
1 Same as 2, plus force redraw on status change.
2 Short status page without scrolling window or current statement.
3 Long status page with current statement.
Bit ^H100 enables auto select of runtime task based on any pending error
messages.
The low byte of the argument is interpreted as follows:
If arg BAND ^HFF==0
No output performed to any menu page.
Global variable ex.ti must be set up by the polling routine.
If arg BAND ^HFF==1
Any change in the runtime status forces a ky.redraw request.
If arg BAND ^HFF==1 or 2 or 3
Error messages also are displayed in the “last error” box, replacing any
previous error. The runtime status, the current sequence name, step, and
cycle are displayed in the status area. The operator response buttons are
maintained.
If arg BAND ^HFF==3
The current statement is also displayed.
If arg BAND ^H100 is set
This page automatically selects the runtime task with the oldest error
message if the current task is not in error state.
mode
350
Indicates the current menu processing state. Only the following modes
are recognized (see menu.pag.spawn( ) on page 474 for descriptions):
mu.rf.first
mu.rf.exit
mu.rf.redraw
mu.rf.refresh
mu.rf.nxt.menu
mu.rf.spw.str
mu.rf.spw.end
mu.rf.rec.opn
ex.mu.status
db.p
Not used.
lun
Not used.
$cmd
Not used.
Output Parameters
luns[ ]
Not used.
$cmd
If mode equals mu.rf.redraw, returns ky.nop
If mode equals mu.rf.refresh, returns ky.nop, ky.redraw, or ky.exit,
depending upon the current runtime state.
Details
Each time that it is called, this routine tests the input message queue from the runtime and
updates internal data structures that contain the current error message and runtime mode.
351
ex.panel.sig
Calling Sequence
CALL ex.panel.sig (signal, function, arg, halt)
Function
Called during system initialization to associate a digital I/O signal with an operator control
function.
Changes global variables associated with the hardware panel.
Input Parameters
signal
V+ digital signal number. No operation (NOP) if zero.
function
Control function code for input or output (see Details).
arg
Optional real value associated with function. Default is zero.
Output Parameter
halt
TRUE if AIM should be halted, otherwise FALSE.
Details
The following values can be used for function to define an input operation:
ex.ctl.select
Select sequence for execution
arg
1 to n, corresponding to $ai.ctl[cs.seq.sel.1] to $ai.ctl[cs.seq.sel.n]
ex.ctl.start
Start sequence execution
No input arguments.
ex.ctl.response Send operator response
arg
Operator response code.
0
Proceed runtime execution
1
Retry action
2
Skip to next action
3
Retry statement
4
5
6
Stop scheduler
ex.ctl.pause
352
Toggle pause condition
arg
Pause type
1
2
Pause at end of action}
3
4
ex.panel.sig
The following values can be used for function to define an output operation:
ex.out.enable
Signal set when hardware panel is active.
ex.out.mode
Signal set to indicate runtime mode
arg
runtime mode
0
Executing
1
Teach mode
1
Operator attention
3
Idle
ex.out.response Signal set to indicate allowed operator responses.
arg
operator response code.
0
Proceed runtime execution
1
Retry action
2
Skip to next action
3
Retry statement
4
5
6
Stop Scheduler
ex.out.pause
Signal set to indicate current operator pause modes.
arg
Pause type
1
2
Pause at end of action
3
4
353
ex.stat.assign
Calling Sequence
CALL ex.stat.assign (ti, func, qual, index, filter, status)
Function
Map AIM errors to the ai.ctl[ ] or $ai.ctl[ ] global arrays.
Input Parameters
ti
Task index for runtime task.
func
Function code (see Details).
qual
Function qualifier (see Details).
index
Index into the ai.ctl[ ] or $ai.ctl[ ] array for output.
filter
Filter bit mask for errors (negative error codes) or messages. Bit masks
apply as follows (see Details for the appropriate range):
Bit
1
2
n
Error range
–1 to –1999
–2000 to –2999
–n∗1000 to –n∗1000−999
Bit
1
2
n
Message range
1 to 1999
2000 to 2999
n∗1000 to n∗1000+999
Output Parameter
status
Details
This routine sets up a mapping between AIM error numbers and the ai.ctl[ ] or $ai.ctl[ ] global
arrays. Whenever an error that has been mapped is generated, that error number and string are
assigned to the specified control variables. These variables can then be displayed on a standard
menu page.
The func argument determines the operation of this routine. The allowed values are:
ex.sta.err
354
Specifies that error message text is to be copied to a block of four $ai.ctl[ ]
string variables. The other input parameters have the following
meanings:
qual
Maximum width of the text.
index
Index of the first of four consecutive $ai.ct[ ] variables.
filter
A bit mask which selects the numeric range of errors to be
copied.
ex.stat.assign
ex.sta.msg
ex.sta.resp
ex.sta.mode
Specifies that informative message text is to be copied to a block of four
$ai.ctl[ ] string variables. The other input parameters have the following
meanings:
qual
Maximum width of the text.
index
Index of the first of four consecutive $ai.ct[ ] variables.
filter
A bit mask which selects the numeric range of messages to be
copied.
Specifies that an error response prompt string is to be copied to an
$ai.ctl[ ] string variable. The actual records used from the error database
are set by the routine rn.error.resp( ). The other input parameters have
the following meanings:
qual
A standard operator error response code indicating which
response is being processed. For example, rn.opr.abort means
the text associated with the “abort” button on the Task Control
Panel should be copied.
index
Index of the destination $ai.ct[ ] variable.
Specifies that the runtime mode for this task is to be copied into an
ai.ctl[ ] variable.
index
Index of the destination ai.ctl[ ] variable.
355
for
Calling Sequence
CALL for (args[], error)
Function
This routine is called from the runtime scheduler when it encounters a FOR statement.
Input Parameter
args[ ]
Output Parameter
error
Syntax:
FOR loop_var = {uopr1} var1 {opr1 var2}
TO {uopr2} var3 {opr2 var4}
{STEP step}
Details
Argument
Type or Database
Misc.
loop_var
variable
args[1]
dummy
none
args[2]
uopr1
Unary operator
var1
variable
opr1
Binary operator
optional
args[5]
var2
variable
optional
args[6]
dummy
none
TO
args[7]
uopr2
Unary operator
optional
args[8]
var3
variable
opr3
Binary operator
optional
args[10]
var4
variable
optional
args[11]
step
constant
optional
args[12]
loop
[value index]
from linker
args[14]
next
[statement number]
from linker
args[16]
File:
CNDRUN.V2
optional
args[3]
args[4]
args[9]
356
if
Calling Sequence
CALL if (args[], error)
Function
This routine is called from the runtime scheduler when it encounters an IF statement.
Input Parameter
args[ ]
Output Parameter
error
Syntax:
IF {uopr} var1{opr1 var2{opr2 var3...}...}
Details
Argument
Type or Database
Misc.
optional
uopr
Unary operator
args[1]
var1
variable
opr1
Binary operator
optional
args[3]
var2
variable
optional
args[4]
...
...
...
...
opr5
Binary operator
optional
args[1]
var6
variable
optional
args[11]
truth
[value index]
from linker
args[14]
next
[statement number]
from linker
args[16]
File:
CNDRUN.V2
args[2]
357
io
Calling Sequence
CALL io (args[], error)
Function
This routine is called from the runtime scheduler when it encounters an I/O statement.
Input Parameter
args[ ]
Output Parameter
error
Details
This statement is essentially identical to the WAIT_FOR statement, so the routine for that is simply
called.
Syntax:
Argument
IO {WAIT_FOR sig1} OUTPUT sig2 {PULSE time}
Type or Database
sig1
output signal
sig2
output signal
time
constant
File:
CNDRUN.V2
Misc.
optional
args[1]
args[2]
optional
args[3]
358
io_list
Calling Sequence
CALL io_list (args[], error)
Function
This routine is called from the runtime scheduler when it encounters an IO_LIST statement.
Input Parameter
args[ ]
Array of arguments (record numbers or constants).
Output Parameter
error
Details
This statement asserts from 1 to 12 digital outputs.
Syntax:
IO_LIST sig1 {sig2 {sig3...sig12}}}}}}}}}}}
Argument
Type or Database
Misc.
sig1
output signal
args[1]
sig2
output signal
optional
args[2]
...
...
...
...
sig12
output signal
optional
args[12]
File:
CNDRUN.V2
359
io.post.cmd
Calling Sequence
CALL io.post.cmd (task, $cmd)
Function
Queues an I/O command buffer for a specified task.
Input Parameters
task
Task that will receive the command. The global variable mu.pri.task is
normally used to specify the primary operator interface task.
$cmd
IO command buffer to be received.
Output Parameter
None.
Details
This routine can be called to execute a command as if it has been received from a normal AIM
menu operation.
The next time the specified task is waiting for input, the low-level input routine io.get.chr.sub( ),
will return the next item from this buffer as though it were received from the system.
This routine appends the command to the end of the queue. Previously queued commands will be
executed first.
Related Routines
mu.set.goto
mu.set.rtrv
360
io.pul.dwn.evt
Calling Sequence
CALL io.pul.dwn.evt (menu, $list, $entry, key, int1, int2, int3,
acc, norun, index)
Function
Add a new entry, which is equivalent to a key press or window input event, to a pull-down menu
list.
This routine can be called only during the system initialization process. Pull-down menu
definitions developed by Adept are contained in the module initialization routines (BASMOD.OV2,
VISMOD.OV2, etc.). System customizers should add new calls to this routine in their own
initialization routines.
Input Parameters
menu
Real value (interpreted as an integer) that specifies the number of the
pull-down menu to which the new entry is to be added. See the
description of io.pul.dwn.spw( ).
$list
String value that specifies the title of the menu list to which the new entry
is added. Each list is referenced by its title. Specifying an unknown title
for a pull-down menu automatically creates a new list. If the title of a list
is changed, the list titles for each of the entries in the list must be updated.
$entry
String value that specifies the label for the new pull-down entry.
Specifying an empty label for an unknown list creates a new list with no
entries. The number of entries within a list is limited to 30.
key
Real value (interpreted as an integer) that specifies the key press or event
that is to be generated when the pull-down list entry is selected. This
value is normally set to one of the constants “ky.∗” (see Table 9-2).
int1
int2
int3
Optional real values (interpreted as 16-bit integers) that specify three
values that are passed as parameters for the event. For all key presses,
and most events, these integer values are ignored and can be undefined.
acc
Optional real value (interpreted as an integer) that specifies the operator
access level required for enabling this pull-down menu entry. Access
levels range from 0 to 7. If this value is undefined, it defaults to 1.
norun
Optional real value that should be set to TRUE if the entry is disabled
when a sequence is running, or set FALSE if the entry is independent of
sequence execution. If this value is undefined, it defaults to FALSE.
index
Optional real value (interpreted as an integer) that specifies an index into
a flags-word array. The bits in the referenced flags-word array element
control special attributes of the pull-down entry. The special attributes
include forcing any associated entries to be disabled, and drawing a
check mark in the first column of the label for all associated entries. See
the description of io.pul.dwn.sfg( ).
361
io.pul.dwn.evt
The settings of the flags words can be altered by calling the routine
io.pul.dwn.sfg( ). Each time an entry is displayed, its flags word is
referenced and any special processing that is indicated is performed.
The flags-word array index can range from 0 to 63. If the index is 0 or
unspecified, no flags word is associated with this entry. The same
flags-word array element can be referenced by multiple entries.
Output Parameter
None.
Details
This routine creates a pull-down menu entry that, when activated, generates an action that is
equivalent to a key press or system event. This routine can be called only during the system
initialization process, and must be executed once for each pull-down menu entry of this type.
Once a pull-down menu entry is defined, it stays in effect until the AIM system is stopped and
restarted.
If this routine specifies a pull-down menu or pull-down list that does not exist, the menu and/or
list is created as necessary. Within each menu and list, the order of appearance of each list or entry
is dictated by the order in which calls to this routine and io.pul.dwn.spw( ) are executed. Within a
pull-down menu, when a new list is created, it is placed to the right of all existing lists. Within
each pull-down list, when a new entry is specified, it is placed below the existing entries.
NOTE: V+ version 11.2 has a limit of nine pull-downs. V+ version 11.3
and later has a limit of 20 pull-downs.
Related Routines
io.pul.dwn.sfg
io.pul.dwn.spw
362
io.pul.dwn.sfg
Calling Sequence
CALL io.pul.dwn.sfg (menu, index, flags)
Function
Set flags-word values used to control special features of pull-down menus.
Input Parameters
menu
pull-down menu that is affected by the flags word. Menu numbers must
be greater than or equal to zero. See the description of io.pul.dwn.spw( ).
index
Real value (interpreted as an integer) that specifies the index of the flags
word to be modified. For each menu, the flags words are stored in an
array and referenced by index number. The index for the flags-word array
ranges from 1 to 63.
flags
Real value (interpreted as an integer) that specifies the new value of the
flags word. The bits within each flags word are defined as follows:
Bits
Interpretation
1 to 8
If any of these bits are set, any entry that references
this flags word cannot be selected
9
If this bit is set, a check mark is displayed in the first
column of the entry label
Output Parameter
None.
Details
This routine sets the value of the flags word for a specified pull-down menu. These flags words
allow application programs to dynamically alter special attributes of pull-down menu entries. The
special pull-down menu attributes include forcing entries to be unselectable, and drawing a check
mark in the first column of the label for an entry.
Each time a pull-down menu entry is displayed, the menu driver checks if the entry has a flags
word specified. If so, the flags word is referenced and any special processing indicated by the
value of the flags word is performed. By executing this routine, an application program can alter
the settings of the flags referenced by an entry or group of entries.
NOTE: To allow pull-down menus to be simultaneously utilized by
multiple tasks, a different set of flags words is maintained for each menu
and each task.
If a new pull-down menu entry is created, which requires a new flags word to control its special
attributes, any unused flags word can be utilized.
363
io.pul.dwn.sfg
Related Routines
io.pul.dwn.evt
io.pul.dwn.spw
364
io.pul.dwn.spw
Calling Sequence
CALL io.pul.dwn.spw (menu, $list, $entry, key, $name, $file,
idbty, irec, iacc, inorun, index)
Function
Add a new entry, which displays a menu page, calls a spawn routine, or calls a control sequence,
to a pull-down menu list.
This routine can be called only during the system initialization process. Pull-down menu
definitions developed by Adept are contained in the module initialization routines (BASMOD.OV2,
VISMOD.OV2, etc.). System customizers should add new calls to this routine in their own
initialization routines.
Input Parameters
menu
pull-down menu to which the new entry is to be added. Menu numbers
must be greater than or equal to zero. Number of menu group that this
pull-down will be added to. The default menu groups are:
0
1
2
3
4
5
6
∗none∗
ai.pmu
mu.pmu
ed.pmu
vw.pmu
du.pmu
vc.pmu
Standard windows
Top of screen
Menu editor
Sequence editor
Vision window
DBM utilities
Restricted to use by the vision window
You may also define your own pull-down menu groups.
$list
Name of the top-level pull-down item. If this name has not been used
previously in the menu group, a new top-level item is created.
$entry
Name of an individual item in the pull-down defined by $list. A
maximum of 30 items can be created for each list.
key
Key-press command that is generated when the pull-down entry is
selected. This parameter must be set to ky.m.menu, ky.menu,
ky.m.spawn, ky.spawn, ky.seq, or ky.m.seq.
The values ky.menu, ky.spawn, and ky.seq are used for generating a
menu page, spawn routine, or control sequence that supersedes the
current activity. For example, if a menu page is being displayed and a
pull-down entry is selected that has ky.menu specified, a new “pop-up”
menu page will be generated on top of the existing menu page.
The values ky.m.menu, ky.m.spawn, and ky.m.seq are equivalent to
executing a Shift+Exit (Shift+F4) followed by a ky.menu, ky.spawn, or
ky.seq command, respectively. These commands terminate any executing
activity and then display a new menu page, call a new spawn routine, or
call a new control sequence.
365
io.pul.dwn.spw
$name
Name of the menu page, spawn routine or control sequence to be invoked
(must be 15 characters or less). This name (which can be an empty string)
cannot be longer than 15 characters. If a menu page is to be displayed and
$name is not specified, the page name is extracted from the first array
element of the “menu page name” field of the record currently opened in
the primary database (see below). If no page is specified and the primary
database does not contain a “menu page name” field, the page name
“main” is assumed.
$file
Optional menu file name, overlay file name, or resource module name.
This name (which can be an empty string) cannot be longer than 12
characters.
If a menu page is to be displayed and both $name and $file contain
empty strings, the file name will be extracted from the second array
element of the “menu page name” field of the primary database (see
below).
If a spawn routine is to be executed, a file name should be specified only
if the program is contained in an overlay (that is, the program is not
memory-resident).
If a control sequence is to be executed and the resource module is left
undefined, then that control sequence must be a part of the default
module as specified on the “control sequence module” record of either
the MOWINI.DB or VWINI.DB initialization databases.
idbty
Optional primary database type for menu command and spawn routines.
Default is 0. See Chapter 4 for further details.
irec
Optional record number or subroutine “arg”. For menu commands, this is
the number of the record in the primary database that is to be opened for
editing, zero to edit the currently opened record. For spawn routines, the
is the value of the spawn routine “arg”. Defaults is 0.
iacc
Optional operator access level required for invoking this entry (0 to 7).
Default is 1.
inorun
Optional flag that indicates if the item is unselectable if a sequence is
running. A non-zero value indicates the item cannot be selected during
execution.
index
Optional index for any associated flags word. The index can range from 0
to 63. If the index is 0 or unspecified, no flags word is referenced. The bits
in the referenced flags-word array element control special attributes of
the pull-down entry. The special attributes include forcing any associated
entries to be disabled, and drawing a check mark in the first column of
the label for all associated entries. See the description of
io.pul.dwn.sfg( ).
The settings of the flags words can be altered by calling the routine
io.pul.dwn.sfg( ). Each time an entry is displayed, its flags word is
referenced and any special processing that is indicated is performed.
The same flags-word array element can be referenced by multiple entries.
366
io.pul.dwn.spw
Output Parameter
None.
Details
This routine creates a pull-down menu entry that, when activated, either displays a new menu
page or executes a spawn routine or a control sequence. This type of pull-down entry produces
exactly the same effect as a menu or spawn-routine button or a sequence button on a menu page.
This routine can be called only during the system initialization process, and must be executed
once for each pull-down menu entry of this type. Once a pull-down menu entry is defined, it stays
in effect until the AIM system is stopped and restarted.
If this routine specifies a pull-down menu or pull-down list that does not exist, the menu and/or
list is created as necessary. Within each menu and list, the order of appearance of each list or entry
is dictated by the order in which calls to this routine and io.pul.dwn.evt( ) are executed. Within a
pull-down menu, when a new list is created, it is placed to the right of all existing lists. Within
each pull-down list, when a new entry is specified, it is placed below the existing entries.
NOTE: V+ version 11.2 has a limit of nine pull-downs. V+ version 11.3
and later has a limit of 20 pull-downs.
This routine constructs the appropriate command IO buffer qualifier and data section given the
following information:
1. The key-press command (“ky.__ ”) that is generated when the pull-down menu item is
selected.
2. The name of the menu page, spawn routine or control sequence that is invoked if a new menu
page is to be brought up or control is to be passed to a menu spawn routine or control
sequence.
3. The name of the disk file that contains the menu page or the optional name of the overlay file
that contains the spawn routine or the resource module for the control sequence.
4. Optional operator access level required to invoke this pull-down item.
5. Optional flag that indicates if the item is unselectable when a sequence is running.
6. Optional index for a flags word that can be used to control special attributes of the pull-down
item (e.g., turn on check mark, force unselectable).
Related Routines
io.pul.dwn.evt
io.pul.dwn.sfg
367
io.working
Calling Sequence
CALL io.working (mode, mess)
Function
This routine displays a “Working...” message in the center of the current window. Optionally, in
order to leave the current window unmodified, this routine will allocate a new window, which is
positioned in the center of the current window, and write the message in an allocated window.
Input Parameters
mode
0
1
2
write the message into the current window.
allocate a new window to write the message into.
delete the window allocated by the last call to this routine. A
call with mode 2 must always be associated with a call with
mode 1.
mess
0
1
2
3
4
5
6
7
display “Working...” message.
display “Linking...” message.
display “Sorting...” message.
display “Planning...” message.
display “Creating ERROR.DAT...” message.
display “Teach Mode...” message.
display “Waiting for signal...” message.
display “Moving robot...” message.
Output Parameter
None.
368
ld.asn.mod
Calling Sequence
CALL ld.asn.mod ($name, status)
Function
Assign a module to the current task.
Module data structures are modified. Modules may be loaded as necessary. A different module
database record may be opened.
Input Parameter
$name
Module name. If null, this routine does nothing.
Output Parameter
status
Details
This routine assigns a module to the current task. If a different module is already assigned, it is
deassigned. If the new module is not loaded, it is first loaded.
Normally, the AIM runtime takes care of assigning/de-assigning modules and users do not need
to be concerned with assigning/de-assigning modules.
Related Routines
ld.asn.seq
ld.asn.seqn
ld.dea.mod
ld.dea.seq
ld.load.mod
ld.unload.mod
369
ld.asn.seq
Calling Sequence
CALL ld.asn.seq ($name, status)
Function
Assign a sequence to the current task.
Module data structures are modified. Sequences may be loaded as necessary. A different module
Input Parameter
$name
Sequence name. If null, this routine does nothing.
Output Parameter
status
Details
This routine assigns a sequence to the current task. The sequence must already be loaded. If a
different sequence is already assigned, it is deassigned.
Normally, the AIM runtime takes care of assigning/de-assigning sequences, and users do not
need to be concerned with assigning/de-assigning sequences.
Related Routines
ld.asn.mod
ld.asn.seqn
ld.dea.mod
ld.dea.seq
ld.load.mod
ld.unload.mod
370
ld.asn.seqn
Calling Sequence
CALL ld.asn.seqn (seqnum, status)
Function
This program assigns a sequence to the current task. If a different sequence is already assigned, it
is deassigned. If the new sequence is not loaded, it is first loaded.
Module data structures are modified. Sequences may be loaded as necessary. A different module
Input Parameter
seqnum
New sequence number. If zero, this routine does nothing.
Output Parameter
status
Details
This routine assigns a sequence to the current task. The sequence must already be loaded. If a
different sequence is already assigned, it is deassigned.
Normally, the AIM runtime takes care of assigning/de-assigning sequences and users do not need
to be concerned with assigning/de-assigning sequences.
Related Routines
ld.asn.mod
ld.asn.seq
ld.dea.mod
ld.dea.seq
ld.load.mod
ld.unload.mod
371
ld.dea.mod
Calling Sequence
CALL ld.dea.mod (status)
Function
This routine de-assigns a module from the current task.
Module data structures are modified. A different module database record may be opened.
Input Parameter
None.
Output Parameter
status
Details
Normally, the AIM runtime takes care of assigning/de-assigning modules and users do not need
to be concerned with assigning/de-assigning modules.
Related Routines
ld.asn.mod
ld.asn.seq
ld.asn.seqn
ld.dea.seq
ld.load.mod
ld.unload.mod
372
ld.dea.seq
Calling Sequence
CALL ld.dea.seq (status)
Function
This routine de-assigns a sequence from the current task.
Module data structures are modified. A different module database record may be opened.
Input Parameter
None.
Output Parameter
status
Details
Normally, the AIM runtime takes care of assigning/de-assigning sequences and users do not need
to be concerned with assigning/de-assigning sequences.
Related Routines
ld.asn.mod
ld.asn.seq
ld.asn.seqn
ld.dea.mod
ld.load.mod
ld.unload.mod
373
ld.get.mod.name
Calling Sequence
CALL ld.get.mod.name (mod, $modname)
Function
Get the name of a module, given its ID. Preserve any currently open record.
Input Parameter
mod
Module ID.
Output Parameter
$modname
374
Name of corresponding module or null if none.
ld.get.modid
Calling Sequence
CALL ld.get.modid (cpu, task, mod)
Function
Get the module id assigned to a specified task.
Input Parameters
cpu
Optional CPU number. If omitted, use local CPU.
task
Optional task number. If omitted, use current.
Output Parameter
mod
Module ID or zero if no module assigned.
375
ld.get.mod.seq
Calling Sequence
CALL ld.get.mod.seq ($modname, $seqname)
Function
Get assigned module and sequence name for the current task.
Input Parameter
None.
Output Parameters
$modname
Name of assigned module or null if none.
$seqname
Name of assigned sequence or null if none.
Related Routine
ld.get.seqinfo
376
ld.get.seqinfo
Calling Sequence
CALL ld.get.seqinfo (modid, seqnum, $seq, seqdb, status)
Function
Return the name of the sequence with the specified sequence number.
The current module database record is changed.
Input Parameters
modid
The ID of the module to be referenced. If zero, the module currently
assigned to this task is used.
seqnum
The number of the sequence being referenced.
Output Parameters
$seq
If successful, the name of the sequence, else an empty string.
seqdb
If successful, the database number for this sequence, else 0.
status
Related Routine
ld.get.mod.seq
377
ld.load.mod
Calling Sequence
CALL ld.load.mod ($name, mod, status)
Function
Load a module into memory and open all relevant databases. Handle all required interlocking.
The current resource module record is updated.
Input Parameter
$name
Name of module to load
Output Parameters
mod
Module ID if status returns success.
status
Details
The resource module data structures are updated. Databases associated with the module are
loaded and available for access.
Related Routine
ld.unload.mod
378
ld.lookup
Calling Sequence
CALL ld.lookup ($modname, $seqname, mod, seqnum, seqdb, status)
Function
Return the module ID and sequence database number for a named module and sequence.
The current resource module database record is updated.
Input Parameters
$modname
Name of the module to lookup
$seqname
Name of the sequence within that module. If null, no error is returned.
Output Parameters
mod
Module ID if status returns success.
seqnum
If status returns success: Sequence number or 0 if $seqname was null. 0 if
status returns error.
seqdb
If status returns success: Database number for this sequence, or 0 if
$seqname was null or sequence was not loaded. 0 if status returns error.
status
Details
If the sequence name is null, no error is returned and the sequence database number is returned as
zero.
Related Routine
ld.mod.member
379
ld.lookup.type
Calling Sequence
CALL ld.lookup.type ($modname, type, $name, db, $path,
$file, status)
Function
This finds a module component given its type and optionally its name. It leaves the module
database pointing at the record for that module component. If type is zero, the module header
record for that module is opened.
Input Parameters
$modname
Name of the module to lookup.
type
Type code for the component to find. If zero, return module db.
$name
Name of the component to find. Only required for sequences. If non-null
for non-sequences, it is verified.
Output Parameters
380
status
0 if no error. Else, returns a standard AIM status code.
db
Number of the database assigned to this component, or 0 if not loaded.
$path
Directory for component.
$file
File for component.
ld.mod.member
Calling Sequence
CALL ld.mod.member (db, mod)
Function
Test if a database is a member of a module.
Input Parameter
db
A database number.
Output Parameter
mod
The module ID if the database is a member of a module, otherwise 0.
Related Routine
ld.lookup
381
ld.unload.mod
Calling Sequence
CALL ld.unload.mod (opmod, status)
Function
Unload a module and related databases from memory.
The resource module data structures are updated.
Input Parameter
opmod
(Optional) Resource module ID to unload. If zero or not defined, use the
assigned module for this task.
Output Parameter
status
Details
If a module ID is specified, the routine attempts to unload that module. If the ID is zero or omitted,
the resource module assigned to the currently executing task is unloaded. All related databases
are unloaded.
If any sequences in this module are currently active, this routine returns an error and does not
unload the module.
Related Routines
ld.asn.mod
ld.asn.seq
ld.asn.seqn
ld.dea.mod
ld.dea.seq
ld.load.mod
382
lk.define
Calling Sequence
CALL lk.define (lnk.ty, lnk.n.f, lnk.l.f, lnk.f.i, srch.ty,
srch.f, req, ebit)
Function
Define linking rules for use by the linking routines.
Input Parameters
lnk.ty
The type of the database into which the link is stored. The key string is
taken from this database.
lnk.n.f
The number of the string field which contains the search key.
lnk.l.f
If srch.ty <> 0, the number of the integer field in which the link is stored.
lnk.f.i
Index into the lnk.n.f[ ] and lnk.l.f[ ] arrays. (0 if lnk.n.f[ ] and lnk.l.f[ ]
are not arrays).
srch.ty
The type code for this link:
>0
The type of the database containing the record that is being
linked to.
0
This rule defines a V+ routine.
<0
One of the ed.type.∗ values that define special data types such as
AIM variable or AIM sequence names.
Variable
Value
Argument
Description
ed.type.const
–1
--constant--
Integer constant.
ed.type.signal
–2
--input--
Input signal constant, or output
signal being read back as an
input.
ed.type.outsig
–3
--output--
Output signal constant.
srch.f
If srch.ty > 0, the number of the field in the searched database that
contains the string which is matched to the key.
If srch.ty <= 0, the number of the numeric field which contains the rule
enable bit. If the bit is deasserted, no linking or link checking is
performed.
req
For database to database links or strategy routines, this value must be set
to TRUE if the link or routine is required, else FALSE if they are optional. If
they are required, an error is generated by the linker if the string field
defined by lnk.n.f is empty. For non-null string fields, this value must be
set to 1.
383
lk.define
ebit
Optional. Default is 0.
If srch.ty <= 0 and srch.f <> 0, the number of the bit within the field
indicated by srch.f to check. If positive, the bit must be set, for this rule to
apply. If negative, the bit must be clear for the rule to apply.
Output Parameter
None.
Details
This routine must be called once at initialization for each linking rule you want to establish. See
Chapter 6 for details on linking
Related Routines
lk.link.1.rec
lk.link.1.field
lk.link.mod
384
lk.link.1.field
Calling Sequence
CALL lk.link.1.field (db, key.fld, index, status)
Function
Routine to check if the specified field is linkable and if so, update this link.
Input Parameters
db
The number of the database containing the record to be linked. It is
assumed that this database is already open and positioned at the proper
record.
key.fld
The number of the string field which contains the key.
index
Index into the key.fld (and the target link field).
Output Parameter
status
0 if successful. Otherwise, a standard AIM error code. The matching link
field is set to zero.
Details
This routine uses the predefined linking rules to link this record to the various fixed databases.
This routine is intended to be used for incremental linking during editing and teaching. It is
somewhat inefficient and not suitable for general linking. No errors are generated if the link
operation fails. Instead, the link field is set to zero if any error occurs.
It is assumed that the record of the specified database is currently open. It is also assumed that all
fixed databases are open. At the completion of this routine, all databases are left open at their
original records.
Related Routines
lk.define
lk.link.1.rec
lk.link.mod
385
lk.link.1.rec
Calling Sequence
CALL lk.link.1.rec (db, status)
Function
Update the links of the currently open record of a database.
The record of the specified database must be open. All referenced databases must also be open. At
the completion of this routine, all databases are left open at their original records.
Input Parameter
db
The number of the database containing the record to be linked. This
database must be open and positioned at the proper record.
Output Parameter
status
0: Success. All links were updated based on matching records.
1: At least one key field was blank or not found. This link is set to zero.
Details
This routine uses the predefined linking rules to link this record to the various fixed databases.
This routine is intended to be used for incremental linking during editing and teaching. It is
somewhat inefficient and not suitable for general linking.
No errors are generated if the link operation fails. Instead, the link field is set to zero if any error
occurs.
Related Routines
lk.define
lk.link.mod
386
lk.link.mod
Calling Sequence
CALL lk.link.mod ($modname, mes, warning, error, abort)
Function
Performs ALL of the linking operations that are required to prepare a module for execution.
The link fields of the databases may be altered.
Input Parameters
$modname
The name of the module to be linked. The module is loaded
automatically.
mes
TRUE if messages are to be output to the terminal, FALSE if all messages
are to be suppressed. Message should only be enabled if this routine is
called from within a task that is running a menu driver. If any linking is
performed and mes is TRUE, a “Linking...” message will be written in the
center of the current window.
Output Parameters
warning
TRUE if a warning condition was detected. A warning condition indicates
that an abnormal situation has been detected that does not affect the
validity of the linking operation.
error
TRUE if a linking error was detected, else FALSE. If a linking error has
been detected, the sequence should not be executed.
abort
TRUE if the operator responded to an error by pressing the “abort” key,
else FALSE.
Details
This operation is normally performed by the AIM runtime and users should not have to call this
routine. The module is assigned to the calling task, then all runtime databases and all sequences in
the module are linked.
Related Routines
lk.define
lk.link.1.field
lk.link.1.rec
387
load
Calling Sequence
CALL load (args[], error)
Function
Statement execution routine for the LOAD statement.
Input Parameter
args[ ]
Not used.
Output Parameter
error
Details
The specified module is loaded and any associated sequences can be executed.
Syntax:
Argument
LOAD MODULE module
Type or Database
module
Module name
File:
CTLRUN.V2
Misc.
optional
$sq.args[1]
388
message
Calling Sequence
CALL message (args[], error)
Function
Statement execution routine for the MESSAGE statement.
Input Parameter
args[ ]
Output Parameter
error
Details
The text corresponding to the message code is output on the operator control panel, subject to any
filters which may be in place.
In general, negative message codes are always output, and positive message codes are only output
in walk-thru training mode. A zero code is ignored.
An optional 15-character text string may be appended to the message text.
If any of the response codes (0 through 6) are specified and non-zero, the runtime waits for an
operator response. Response codes 0 through 6 correspond to the seven standard runtime operator
error response codes. The value specified for the response code may be:
0
Indicates the response is not valid.
−1
Indicates that the default AIM response message should be used for this
response.
>0
Indicates that the AIM error database entry with this value should be
used for this response.
The text and explanation information for a response is read from an AIM error database.
If there is no RESPONSE variable, AIM handles the operator response in the normal way. If there is
a RESPONSE variable specified, the value indicated by the operator's response (0 through 6) is
returned in that variable for further processing. The sequence must handle the response value
appropriately.
If there is no non-zero response argument, AIM does not attempt to obtain a response. In this case,
the optional RESPONSE variable is always set to zero.
Syntax:
MESSAGE msg.code {TEXT string} {0: resp0} {1: resp1}
{2: resp2} {3: resp3} {4: resp4} {5: resp5} {6: resp6}
{RESPONSE variable}
389
message
Argument
Type or Database
Misc.
msg.code
variable
args[1]
Text
string
optional
args[2]
0:
constant
optional
args[3]
1:
constant
optional
args[4]
2:
constant
optional
args[5]
3:
constant
optional
args[6]
4:
constant
optional
args[7]
5:
constant
optional
args[8]
6:
constant
optional
args[9]
Response
lh_variable
optional
args[10]
Related Routine
set_response
390
mu.get.vname
Calling Sequence
CALL mu.get.vname (m.db, $name)
Function
Routine that gets the V+ variable name associated with the current menu record.
Input Parameter
m.db
Number of the menu database to access.
Output Parameter
$name
Name of the variable, or null.
391
mu.menu
Calling Sequence
CALL mu.menu ($page, $file, db.p, $cmd)
Function
Display a menu page.
This routine can be called only from a task that is running a menu driver (normally, only task 3 is
configured to run a menu driver).
Input Parameters
$page
String value that specifies the name of the menu page to display. This
name cannot be longer than 15 characters. If no page is specified, the page
name is extracted from the first array element of the “menu page name”
field of the record currently opened in the primary database (see below).
If no record is open, the default record is checked. If no page is specified
and the primary database does not contain a “menu page name” field, the
page name “main” is assumed.
$file
String value that specifies the name of the file that contains the menu
page. This name cannot be longer than 12 characters. If $page and $file
are both unspecified, the file name will be extracted from the second
array element of the “menu page name” field of the primary database.
db.p
Optional real value (interpreted as an integer) that specifies the default
primary database number. If this parameter is not specified, its value
defaults to 0.
If no primary database is specified in the header of the menu page, this
will be the primary database number. (If either $page or $file is not
specified, db.p must be specified.) All record-oriented operations (for
example, delete record and append record) are directed to the primary
database. Also, any menu items that reference a database, but have no
database specified, use the number of the primary database.
NOTE: This parameter is an actual database number, not a type code.
Output Parameter
$cmd
String variable, the value of which indicates the command that
terminated display of the menu page. The value is in the standard format
for I/O communications buffers (see Chapter 9).
If the menu page was successfully displayed, the buffer qualifier will be a
positive number that corresponds to a key-press code. If the page could
not be displayed, the buffer qualifier will contain a negative error code.
If a display error occurs, it is reported to the operator before this routine
exits. Error codes are passed back to the calling routine only to indicate
that the operation did not complete successfully.
392
mu.menu
Details
This routine can be called recursively by any task that is running a menu driver to display a new
menu page. For example, this routine can be called by a spawn routine that was invoked from a
menu page that was itself generated by a previous call to mu.menu( ).
The routine mu.menu( ) begins by locating and opening the specified Menu database and page.
(The menu driver automatically opens and closes Menu database files as necessary, so it is
unnecessary to explicitly open any referenced menu file.) The routine then displays the page and
loops, fielding commands from the operator, including commands to modify values and to
display other menu pages. This routine returns to its caller whenever a command is received to
exit from the top-level menu page.
Related Routine
mu.popup.error
393
mu.popup.error
Calling Sequence
CALL mu.popup.error ($err, sev, $cmd)
Function
Display the error pop-up window.
Databases may be accessed, opened, and closed. This routine should be called only from the main
or secondary operator interface tasks.
Input Parameters
$err
I/O buffer containing an error code (in the qualifier) and any related text
(in the data section).
sev
The type of menu page to be displayed (see Details).
Output Parameter
$cmd
I/O buffer containing the operator’s response to the error pop-up (see
Chapter 9). The following are the only qualifiers that can be returned:
ky.exit, ky.s.exit, ky.halt (if halt is TRUE)
ky.m.spawn, ky.m.menu, ky.spawn, ky.menu, ky.m.seq, ky.seq.
Details
This is a top-level routine for displaying an error pop-up display from within the main aim
operator interface task or from the secondary menu interface. This routine converts the error IO
buffer to text, writes the text into appropriate scratch strings, and then displays the text using an
appropriate menu page.
The error pop-up displays two lines of text. The top line contains the error message corresponding
to the error code contained in the qualifier of the $cmd buffer. The second line contains any text
packed into the data section of the $cmd buffer.
The severity specifies the type of menu page displayed, and the buttons which are displayed on
the menu. Each menu page has different user options and is of a different color. Red is error and
yellow is warning. There are options for continue, abort, retry, and halt. The variable shown in
parenthesis in the following table, below the button name, is returned as the $cmd qualifier when
the corresponding button is pressed. The value ky.exit is returned if the pop-up menu close box is
selected.
394
mu.popup.error
Variable
Description
Button 1 Name
(Variable)
Button 2 Name
(Variable)
er.sev.ectht
Hard Error
Continue
(ky.exit)
Halt
(ky.halt)
er.sev.ect
Error / Continue
Continue
(ky.exit)
er.sev.ertab
Retry / Abort
Retry
(ky.exit)
Abort
(ky.halt)
er.sev.wctab
Warning
Continue
(ky.exit)
Abort
(ky.halt)
er.sev.wab
Warn / Abort
Abort
(ky.halt)
er.sev.wct
Warn / Continue
Continue
(ky.exit)
It is assumed that io.lun is attached to a window LUN when this routine is called. At the
completion of this routine, the originally opened window is left unchanged. The scratch control
variables are also left unchanged.
Related Routines
cu.error.notify
er.error
395
mu.set.goto
Calling Sequence
CALL mu.set.goto (func, mode, $page, $file, type, rec, acc, norun,
$cmd)
Function
Build a command buffer for a menu display, a subroutine spawn, or a sequence execution
operation.
Input Parameters
func
Function code, one of the following:
ky.menu, ky.m.menu, ky.spawn, ky.m.spawn, ky.seq, ky.m.seq
mode
0
1
2
3
4
$page
For ky.menu or ky.m.menu, this is the menu page name. May be null. For
ky.spawn or ky.m.spawn, this is the overlay routine name. May be null.
For ky.seq or ky.m.seq, this is the sequence name.
$file
For ky.menu or ky.m.menu, this is the menu file name. If null, the menu
file name is the base name for the specified type. For ky.spawn or
ky.m.spawn, this is the overlay file name. If null, no overlay is loaded. For
ky.seq or ky.m.seq, this is the module name.
type
Type of database to be passed for this GOTO as the primary database.
Used to determine menu file name if $file is null. May be zero if no
database is to be passed. If <0, the global database of type ABS(type) is
passed.
rec
If ky.menu or ky.m.menu, this is the record number to be opened in the
primary database. For ky.spawn or ky.m.spawn, this is the “arg”
parameter passed to the spawned routine.
acc
Access code required for this operation to take place.
norun
Non zero if this operation cannot occur if any runtime task is active.
for standard operation.
if this is a GOTO that expects a BACK or RETRIEVE reply.
if this is a BACK reply.
if this is a RETRIEVE reply.
like mode 1 with the addition that a new record is created in the
target database
Output Parameter
$cmd
396
Standard I/O buffer containing GOTO command generated from the data
or some error code if an error was detected.
mu.set.goto
Details
This routine is provided to build a command header. See Chapter 9 for details on the structure of
the command header.
This routine sets the “retrieve” parameters of the buffer to zero (null) values. The routine
mu.set.rtrv( ) should be called after this routine to set non zero retrieve parameters.
This routine is useful for building a command header for use with the io.post.cmd( ) routine.
Related Routines
io.post.cmd
mu.set.rtrv
397
mu.set.rtrv
Calling Sequence
CALL mu.set.rtrv (type, rec, field, index, $cmd)
Function
Fill in the retrieve parameters in an I/O command buffer.
The routine mu.set.goto( ) must be called first.
Input Parameters
type
Type of the database that contains the value to be filled in if RETRIEVE is
performed. If negative, a global database is filled in. Used for GOTO
modes 1,2,3,4.
rec
Number of the record to be filled in if RETRIEVE is performed. Used for
GOTO modes 1,2,3,4.
field
Number of the field to be filled in if RETRIEVE is performed. Used for
GOTO modes 1,2,3,4.
index
Number of the field index to be filled in if RETRIEVE is performed. Used
for GOTO modes 1,2,3,4.
$cmd
Standard I/O command buffer. May have GOTO data fields filled in
already. Also an output parameter.
Output Parameter
$cmd
Standard I/O command buffer. Contains input $cmd data with retrieve
parameters overwritten by the input parameter values.
Details
This routine is provided as a convenience in creating the menu page command header. See
Chapter 9 for details. It is normally called after calling the routine mu.set.goto( ) to set up the
GOTO parameter section.
The io.ms.r.val string is not filled in by this routine.
Related Routines
io.post.cmd
mu.set.goto
398
next_loop
Calling Sequence
CALL next_loop (args[],error)
Function
This routine is called from the runtime scheduler when it encounters an NEXT_LOOP statement.
Input Parameter
args[ ]
Output Parameter
error
Syntax:
NEXT_LOOP {constant}
Details
Argument
Type or Database
Misc.
count
Constant
Optional
args[1]
next
[statement number]
from linker
args[16]
File:
CNDRUN.V2
399
pause_task
Calling Sequence
CALL pause_task (args[],error)
Function
Statement execution routine for the PAUSE_TASK statement.
Input Parameter
args[ ]
Output Parameter
error
Details
The specified runtime task is paused. If the event is not specified, an immediate pause is
requested.
If the task is not found, no error is reported.
Syntax:
Argument
PAUSE_TASK task {AFTER event}
Type or Database
task
Task name
event
constant
File:
CTLRUN.V2
Misc.
$sq.args[1]
optional
args[2]
400
pe.attach
Calling Sequence
CALL pe.attach (status)
Function
Attach the manual control pendant to the current execution task for use by teaching routines.
Only one task can have the manual control pendant attached at any one time.
When it is done using the manual control pendant, the calling task must detach the pendant by
executing the V+ instruction DETACH (1).
Input Parameter
None.
Output Parameter
status
was successful. See the standard AIM status values.
Details
This routine must be called before a V+ task attempts to read from, or write to, the manual control
pendant. The routine tests if the pendant is connected to the controller, and whether it is already
attached by a different task.
If this routine succeeds, the manual control pendant is attached for exclusive use by the requesting
task, and auto-repeat mode is disabled for the pendant “+” and “–” keys. The user program may
change key modes as desired.
Once the user program is done with the manual control pendant, the program should execute the
V+ instruction DETACH (1) to free the pendant for use by other tasks. This detach operation must
be done regardless of the success or failure of the teaching operation(s).
Related Routine
pe.disp.msg
401
pe.disp.msg
Calling Sequence
CALL pe.disp.msg (code)
Function
Display the text associated with an error on the manual control pendant and beep the pendant.
This routine should be called only when the pendant has been attached with the routine
pe.attach( ).
Input Parameter
code
Real value that specifies the standard AIM status code corresponding to
the error text that is to be displayed.
Output Parameter
None.
Details
This routine displays on the manual control pendant the text associated with an AIM error code.
When the message is displayed, the pendant is beeped and the message blinks. The routine
returns immediately with the message still displayed. (All the AIM error codes are listed in
Appendix C, both with the alphabetical presentation of all the error messages and in a numerical
list of all the error codes.)
If code is 0, the display is blanked.
Related Routine
pe.attach
402
repeat
Calling Sequence
CALL repeat (args[], error)
Function
This routine is called from the runtime scheduler when it encounters a REPEAT statement.
Input Parameter
args[ ]
Output Parameter
error
Syntax:
REPEAT {uopr} var1{opr1 var2 {opr2 var3...}...}
Details
Argument
Type or Database
Misc.
optional
uopr
Unary operator
args[1]
var1
variable
opr1
Binary operator
optional
args[3]
var2
variable
optional
args[4]
...
...
...
...
opr5
Binary operator
optional
args[11]
var6
variable
optional
args[12]
loop
[value index]
from linker
args[14]
next
[statement number]
from linker
args[16]
File:
CNDRUN.V2
args[2]
403
resume_task
Calling Sequence
CALL resume_task (args[], error)
Function
Statement execution routine for the RESUME_TASK statement.
Input Parameter
args[ ]
Output Parameter
error
Details
The specified runtime task is sent a resume message.
If the response is omitted, a simple proceed is sent. Otherwise, the indicated response is sent.
Syntax:
Argument
RESUME_TASK task {RESPONSE response}
Type or Database
task
task name
response
constant
File:
CTLRUN.V2
Misc.
$sq.args[1]
optional
args[2]
404
return
Calling Sequence
CALL return (args[], error)
Function
This routine is called from the runtime scheduler when it encounters a RETURN statement.
Input Parameter
args[ ]
Array of arguments (record numbers or constants). Not used.
Output Parameter
error
Details
This routine exits from the current sequence to the calling sequence or program. Any WHILE or
FOR loops are terminated and sequence execution behaves as if the end of a sequence has been
reached. If a RETURN is executed in the main sequence, and the “repeat” option has been selected,
the next execution loop of the main sequence will begin.
Syntax:
RETURN
File:
CTLRUN.V2
Related Routine
call
405
rn.check
Calling Sequence
CALL rn.check (response, error)
Function
Runtime low-level routine to check for any robot or programming errors.
This routine should be called only from an AIM runtime task.
Errors related to vision are not detected by this routine.
Input Parameter
response
Real value (interpreted as a binary bit mask) that specifies the allowed
operator responses if an error is detected. The “abort” error response is
always allowed. See Table 5-3 for the standard operator error response
bit-mask values.
Output Parameter
error
was successful, and what action should be taken by the calling routine.
See Table 5-3 for the standard AIM operator error response values.
Details
Within the AIM runtime system, robot-related and programming errors are normally detected
whenever a robot-motion primitive routine is called. Therefore, robot errors are not detected by a
statement that performs no robot motion. This low-level routine can be used to check for any such
errors, and report them to the operator. The routine returns the operator response.
If no errors have occurred, this routine returns zero. Otherwise, the operator response is returned.
Note that it is not possible to distinguish between no robot error and an operator response of
“proceed”.
406
rn.check.pause
Calling Sequence
CALL rn.check.pause (resp, type, error)
Function
Runtime low-level routine to check for any requested pauses.
Input Parameters
resp
Bit mask describing acceptable operator responses. If 0, only abort is
accepted. See the Bit Mask column of Table 5-3 for details.
type
Type of pause condition to check for.
Variable name
Condition
ai.pause.action
action
ai.pause.any
all selected
ai.pause.imm
immediate
ai.pause.opr
operation
ai.pause.sequen
cycle
ai.pause.statem
statement
If zero, only pause immediate or stop immediate conditions are
recognized.
Output Parameter
error
Standard error response code. See the Variable Name column of Table 5-3
for details.
Details
This routine checks the runtime pause variable rn.ctl[TASK( ),rn.ctl.pause]. If any flags are set, the
proper pause message is sent to the operator.
The pause immediate flag is always checked.
This routine is often used in a wait loop to exit the loop if a *stop all task* or pause after immediate
is checked. For example:
DO
WAIT
CALL rn.check.pause (0, 0, error)
IF error GOTO 100
UNTIL <condition>
Any wait loops should call this so they do not hang if the condition does not evaluate as TRUE.
407
rn.cli.connect
Calling Sequence
CALL rn.cli.connect (ti, tmo, optional, dv.id, error)
Function
Connect the current client task to a server task and tests if it is ready.
Input Parameters
ti
Task ID of the server task to which we are connecting.
tmo
Time-out value, in seconds. If zero, this routine does not wait at all.
optional
If TRUE, then no error is generated if the connection fails.
Output Parameters
dv.id
If error returns success, queue ID number for sending to this server. If
optional is set to TRUE, a value of 0 indicates that a queue is not ready.
error
If optional is TRUE, always returns 0. Otherwise, returns standard AIM
operator response.
Details
This routine is called during runtime by a client task to connect to a server task. If successful, the
client may use the returned queue ID for exchanging data with the sever task. The response “retry
action” is handled internally by this routine.
This routine calls dv.cli.connect( ), and it handles certain errors.
Related Routines
dv.cli.connect
rn.cli.reply
rn.cli.send
408
rn.cli.reply
Calling Sequence
CALL rn.cli.reply (dv.id, msg.id, mode, $reply, error)
Function
Checks for a reply to a request previously sent by a call to rn.cli.send( ).
Input Parameters
dv.id
ID of the FIFO queue to which the request was sent. Returned by a
previous call to rn.cli.connect( ).
msg.id
ID returned by a previous call to rn.cli.send( ).
mode
This is a bit field specifying:
bit 1 if set, wait for reply, otherwise no wait.
bit 2 if set, suppress error message output.
Output Parameters
$reply
If error returns success (0), this parameter contains the reply data. If an
error occurs, a NULL string is returned.
error
If request is successful, returns 0. If the request is not complete, but an
error is not generated, error returns rn.opr.fail. Otherwise, a standard
operator response code is returned.
Details
This routine is called during runtime by a client task to retrieve data in response to a previous
request from rn.cli.send( ). If the reply is present, it is returned. Otherwise, bit 1 of the mode
parameter specifies whether or not this routine waits until the reply is received.
The system does not keep track of all outstanding requests. Therefore, if this routine is called with
a non-existent message ID, it will wait forever.
This routine calls dv.cli.reply( ), handles certain errors, and optionally waits for the reply.
Related Routines
dv.cli.reply
rn.cli.connect
rn.cli.send
409
rn.cli.send
Calling Sequence
CALL rn.cli.send (dv.id, func, qual, $data, mode, msg.id, $reply,
error)
Function
Send a message to a server from a runtime client task and optionally wait for a reply.
Input Parameters
dv.id
ID of the FIFO queue to which the requests are sent. Returned by a
previous call to rn.cli.connect( ).
func
Function code. Valid codes differ for each driver task.
qual
Function code qualifier. Valid values differ for each function code.
$data
A string of up to 112 bytes which is sent as data for this request.
mode
This is a bit field specifying:
bit 1
if set, wait for reply, otherwise no wait.
bit 2
if set, suppress error message output.
Output Parameters
msg.id
If mode bit 1 is clear and an error is not returned, the message ID to be
used for the call to rn.cli.reply( ).
$reply
If mode bit 1 is clear, a NULL string is returned. If mode bit 1 is set and an
error is not returned, contains the reply data.
error
Success or standard AIM status code.
Details
This routine is called by a client task during runtime to send a request to a server task. The routine
can optionally wait for the reply data from the sever task or return an ID to be used by a
subsequent call to rn.cli.reply( ).
The func and qual parameters must correspond to the values expected by the server tasks
handling the requests.
This routine calls dv.cli.send( ), handles certain errors, and optionally calls dv.cli.reply( ).
Related Routines
dv.cli.send
rn.cli.connect
rn.cli.reply
410
rn.error
Calling Sequence
CALL rn.error (error, response, code, $suffix, database, record,
field, index)
Function
Send a message to the operator and wait for a response. (Handles error and pause messages and
allows an optional database to be edited.)
This routine should only be called from an AIM runtime or operator interface task.
Error messages stop the robot program until the operator control panel is selected and an operator
response is entered.
Unlike standard AIM routines, the output parameter appears before the input parameters.
Input Parameters
response
Real value (interpreted as a binary bit mask) that specifies the allowed
operator responses if an error is detected. The “abort” error response is
always allowed. See the standard operator error response bit-mask
values. See Table 5-3 on page 64 for more information.
code
Real value specifying the error or pause message to be displayed. (See the
discussion of standard error codes in Appendix C.) Normally, only
negative error codes are handled by this routine.
For error codes from –1000 to –1199, the fractional part of this value is
taken to be the variable portion of the V+ error code, divided by 512.
$suffix
Optional string value specifying a string to be output with the error string
generated from the error code above. This string is inserted between the
error string and any database description. If this parameter is omitted, no
additional string is included. (Only the first 60 characters of this string are
displayed.)
database
Optional real value specifying the number of a database. If this parameter
is zero or omitted, no database is associated with this error and all the
subsequent input parameters are ignored. If this parameter is nonzero,
the name of the corresponding database is appended to the message
string, and this database is edited if the operator selects “Edit” on the
operator control panel.
record
Optional real value specifying the number of a record in the database
specified above. (This value is ignored if database is omitted or is zero.) If
this value is zero, the record currently open for the specified database is
assumed.
The name field (specified by offset cc.name) from the selected record is
appended to the message string, and this record is edited if the operator
selects “Edit” on the operator control panel. No name is displayed if the
value of this parameter is less than zero or is omitted.
411
rn.error
field
Optional real value that specifies a field number within the selected
record. If this parameter is greater than or equal to zero, the name of the
field corresponding to this field number is appended to the message
string. No field name is displayed if this parameter is less than zero or is
omitted.
index
Optional real value that specifies an index within the field specified
above. If this parameter is greater than zero and the field number is
specified, the index number is appended to the message string. No index
number is displayed if this parameter is less than or equal to zero or is
omitted.
Output Parameter
error
Real variable that receives a value indicating the operator response to the
message. The response is a standard operator error response value, and it
corresponds to a selection on the operator control panel. Only responses
that are allowed by the response input parameter are returned. See the
standard operator error response values.
Details
This routine handles error messages and pause messages. After displaying a message, this routine
waits for an operator response to be entered. The response is returned as the error value.
NOTE: The output parameter appears first in the parameter list to make
programs that omit input parameters more readable.
The response input parameter restricts the operator to certain responses. The abort response is
always valid, regardless of the value of the response parameter. The operator response returned is
always either abort, or one of the responses explicitly allowed, so the calling program does not
need to handle other responses.
If a database number is specified, the database information determines what data will be edited if
the operator selects “Edit” on the operator control panel. The “Edit” button has no function if no
database number is specified.
If a robot error has occurred but has not yet been reported, rn.error( ) reports that error and waits
for an operator response before reporting the new error specified by the code parameter.
Example
The following subroutine call reports that no feeders are ready for a particular part.
CALL rn.error(error, er.all. ec.no.feeder, , pa.db, 0)
This call generates the message:
*No feeders ready*: part: ic8085
where: the error string “∗No feeders ready∗” is specified by the error code ec.no.feeder; the
$suffix parameter is omitted; “part:” is specified by the Part database number “pa.db”; the
name (”ic8085”) of the current record is shown because the record parameter is 0; and the
field name is suppressed because the field parameter is omitted. (The index parameter is also
omitted.)
All operator responses are allowed, as indicated by the variable er.all.
412
rn.error
Related Routines
rn.error.resp
rn.message
413
rn.error.resp
Calling Sequence
CALL rn.error.resp (proc, retry, skip, retry.stmt, skip.stmt,
skip.seq, abort)
Function
Set the response codes that are used by rn.error( ).
Input Parameters
proc
Optional message code for “Proceed”.
retry
Optional message code for “Retry action”.
skip
Optional message code for “Skip action”.
retry.stmt
Optional message code for “Retry statement”.
skip.stmt
Optional message code for “Skip statement”.
skip.seq
Optional message code for “Skip sequence”.
abort
Optional message code for “Abort runtime”.
Output Parameter
None.
Details
The labels associated with the operator push-buttons on the Task Control Panel can be
dynamically assigned using this routine. This gives the programmer a chance to provide
application specific labels for these push-buttons. The codes are error numbers from the error
database. The label associated with the specified error number will be displayed. The operator will
be able to click on the label field of each push-button to display the full error database record.
This routine sets the response codes which are used in subsequent calls to rn.error( ). The message
strings that correspond to these codes are stored in a set of $ai.ctl[ ] variables that may be
displayed on an operator control panel.
All input parameters are optional. If a response code is omitted from the parameter list, or a value
of zero is passed, the default message for this response is displayed.
Related Routines
rn.error
rn.resp.save
rn.resp.rest
414
rn.exp.eval
Calling Sequence
CALL rn.exp.eval (args[], arg1, argn, value, error)
Function
Evaluate a set of arguments from one of the conditional statements.
Input Parameters
args[ ]
Real array containing the operators and variables for the expression.
arg1
Index into args[ ] for the first element in the expression.
argn
Index into args[ ] for the last element in the expression.
Output Parameters
value
If successful, real value of this expression, else 0.
error
Standard operator response code.
Details
Most of the conditional statements have a common series of arguments that define Boolean or
arithmetic operations to be performed on a set of variables and/or constants. This routine
evaluates these groups of arguments.
This routine evaluates an expression that is packed in the args[ ] array. The first element of the
expression is found in args[arg1]. The last element should be zero and is used as the
end-of-expression operator. The result is a real value.
The argument list contains the expression as a series of operators and variables as follows:
Offset
Data in args[arg+offset]
0
Optional unary operator code
1
Variable #1
2
Optional binary operator #1
3
Optional variable #2
...
n
n+1
Optional binary operator #n/2
Optional variable #(n−1)/2
...
x
Zero operator value, marks end of
expression
415
rn.get.a.num
Calling Sequence
CALL rn.get.a.num (db, field, first, count, index, number[ ],
error)
Function
Runtime routine that returns an array of real values from an array field of the current record in a
database, and handles walk-thru training.
The database must be memory-resident and must have been opened before this routine is called.
Any error message generated is automatically sent to the operator and the operator error response
is read.
Optional values should not be extracted by this routine, since any undefined value is treated as an
error condition.
Input Parameters
db
field
first
Optional real value specifying the index number of the first element to be
returned from the array field. Assumed to be zero if omitted. (The first
element of an array has index 0.)
count
Real value specifying the number of array elements to be returned.
index
Output Parameters
number[ ]
error
Real variable that receives a standard operator error response code that
indicates whether or not the operation was successful. See the standard
operator error response values.
NOTE: An operator error is generated if any of the requested field
elements do not contain valid data.
416
rn.get.a.num
Details
This routine performs the same operation as db.get.a.num( ) (see Chapter 14), except that this
routine does not use the count parameter for output. Also, if an error occurs reading a value, or
walk-thru edit-all mode is enabled for the field, a message is sent to the operator and the runtime
waits for an operator response before continuing. This response is returned in the error output
variable.
Walk-thru edit-all mode requires that “Edit All” be selected in the Task Control Panel, and that the
edit-all flag be set for the field in the database definition.
Related Routines
db.get.a.num
db.get.a.nums
db.get.num
rn.get.a.nums
rn.get.num
417
rn.get.a.nums
Calling Sequence
CALL rn.get.a.nums (db, field, first, count, index, number[ ],
error)
Function
Runtime routine that returns values from consecutive numeric fields in the current database
record, and handles walk-thru training.
is read.
error condition.
Input Parameters
db
field
Real value specifying the number of the first field whose value is to be
first
returned if the specified field contains an array. Zero is assumed if this
parameter is omitted. (The first element of an array has index 0.)
This parameter must be set to 0 (or omitted) if the specified field does not
contain an array.
count
Real value specifying the number of field elements to be returned.
index
Output Parameters
418
number[ ]
returned in number[index]. If a field or element in the database is
undefined, the corresponding element of number[ ] is set to 0.
error
rn.get.a.nums
Details
This routine performs the same operation as db.get.a.nums( ) (see Chapter 14), except that this
walk-thru edit-all mode is enabled for any of the fields, a message is sent to the operator and the
runtime waits for an operator response before continuing. This response is returned in the error
output variable.
edit-all flag be set for the desired fields in the database definition.
Related Routines
db.get.a.num
db.get.a.nums
db.get.num
rn.get.a.num
rn.get.num
419
rn.get.a.str
Calling Sequence
CALL rn.get.a.str (db, field, first, count, index, $string[ ],
error)
Function
Runtime routine that returns an array of string or name values from an array field of the current
is read.
error condition.
Input Parameters
db
must be greater than or equal to zero.
field
first
contain an array.
count
index
Output Parameters
$string[ ]
String array that receives the string or name values returned. The first
value is returned in the element $string[index]. If an array element in the
database is undefined, the corresponding element of $string[ ] is set to an
empty string (“”).
error
NOTE: An operator error is generated if any of the requested field
elements does not contain valid data.
420
rn.get.a.str
Details
This routine performs the same operation as db.get.a.str( ) (see Chapter 14), except that this
walk-thru edit-all mode is enabled for the field, a message is sent to the operator and the runtime
waits for an operator response before continuing. This response is returned in the “error” output
variable.
Related Routines
db.get.a.str
db.get.str
rn.get.str
421
rn.get.num
Calling Sequence
CALL rn.get.num (db, field, index, number, error)
Function
Runtime routine that returns the numeric value from a field of the current record in a database,
and handles walk-thru training.
is read.
error condition.
Input Parameters
db
field
index
Optional real value specifying the index number of the element to be
contain an array.
Output Parameters
number
Real variable that receives the numeric value returned. The value zero is
returned if the field value is not defined.
error
Details
This routine performs the same operation as db.get.num( ) (see Chapter 14), except that if an error
occurs reading the value, or walk-thru edit-all mode is enabled for the field, a message is sent to
the operator and the runtime waits for an operator response before continuing. This response is
returned in the error output variable.
422
rn.get.num
Related Routines
db.get.a.num
db.get.a.nums
db.get.num
rn.get.a.num
rn.get.a.nums
423
rn.get.str
Calling Sequence
CALL rn.get.str (db, field, index, $string, error)
Function
Runtime routine that returns the string value from a field of the current record in a database and
handles walk-thru training.
is read.
Optional values should not be extracted by this routine, since all undefined values are treated as
an error condition.
Input Parameters
db
field
index
contain an array.
Output Parameters
$string
String variable that receives the string value returned. If the field value is
undefined, an empty string (“”) is returned.
error
Details
This routine performs the same operation as db.get.str( ) (see Chapter 14), except that if an error
424
rn.get.str
Related Routines
db.get.a.str
db.get.str
rn.get.a.str
425
rn.get.trans
Calling Sequence
CALL rn.get.trans (db, field, index, trans, error)
Function
Runtime routine that returns a transformation value from a field of the current record in a
database, and handles walk-thru training.
is read.
error condition.
Input Parameters
db
field
index
contain an array.
Output Parameters
trans
Transformation variable that receives the location value returned. If an
error occurs, this variable is set to the value NULL.
error
Details
This routine performs the same operation as db.get.trans( ) (see Chapter 14), except that if an error
426
rn.get.trans
In a robot system, the field can be defined using teach mode if the “teachable location” field
attribute bit is set in the database definition for the specified field. See “Field Attribute Bits” on
page 22.
Related Routines
db.get.a.trans
db.get.trans
rn.put.trans
427
rn.get.va.num
Calling Sequence
CALL rn.get.va.num (arg, optional, value, error)
Function
Get a single value described by a variable argument returned in the args[ ] array that references
the Variable database
Input Parameters
arg
Encoded argument describing the data item.
optional
If TRUE and arg is not specified, then return zero in value with no error.
Output Parameters
value
If error returns success, real variable which receives the value of the
indicated data item. If error is non-zero, value returns 0.
error
Standard AIM operator response.
Details
Normally, when the scheduler returns database arguments in the args[ ] array, they are the
numbers of the records of interest. In the case of the Variable database, an encoded value that
represents the actual value along with a code that specifies the variable type (signal, ai.ctl[ ], etc.).
This routine will decode this special value and return that actual value.
Note that if a signal is entered on the statement line, the signal value (TRUE or FALSE) is returned.
This routine should be used only when a --variable-- or --o_variable-- is specified in the statement
definition.
Unlike most sequence arguments, a value of zero does not mean that the argument is undefined. A
special global variable va.undef.var is provided to allow testing of this case. For example:
IF args[out.arg] == va.undef.var THEN
;If variable not defined
...
END
Related Routine
rn.put.va.num
428
rn.message
Calling Sequence
CALL rn.message (code, $suffix, database, record, field, index)
Function
Send an informative message or a trace message to the Task Control Panel.
If the Task Control Page is not being displayed, the messages are not seen.
Trace messages are sent only during walk-thru training.
Input Parameters
code
Real value specifying the code for the informative or trace message to be
displayed. Normally, positive error codes are passed to this routine. See
the discussion of standard error codes in Appendix C.
For error codes from –1000 to –1199, the fractional part of this value is the
variable part of the V+ error code divided by 512.
$suffix
Optional string value that is appended to the message string that is
generated from the message code above. If specified, this string is
inserted between the message string and any database description. (Only
the first 60 characters of this string are displayed.) No suffix string is
appended if this parameter is omitted.
database
Optional real value specifying the number of a database. If this parameter
is omitted or zero, no database is associated with this message, and all the
remaining parameters are ignored. If non-zero, the name of the
corresponding database is appended to the message string.
record
Optional real value specifying the number of a record in the database
specified above. If the value is zero, the record currently open for that
database is assumed. Then the name field (specified by offset cc.name)
from the record is appended to the message string. No name is appended
if the value is less than zero, or this parameter is omitted.
field
Optional real value that specifies a field number within the selected
record. If the value is greater than or equal to zero, the name of the field
corresponding to this field number is appended to the message string. If
this parameter is omitted, or it has a value less than zero, no field name is
appended.
index
Optional real value specifying the index within the field specified above.
If the value is greater than zero and a field number is specified, the index
number is appended to the message string. If this parameter is omitted,
or it has a value less than or equal to zero, no index number is appended.
Output Parameter
None.
429
rn.message
Details
This routine sends both informative messages and trace messages to the Task Control Panel.
However, trace messages are sent only during walk-thru training.
Example
The following example call to this routine generates a trace message when accessing a feeder
during walk-thru training:
CALL rn.message(ac.acc.feed, , fd.db[TASK()], 0)
The following message results:
Accessing: feeder: feedtube1
where
• The trace string “Accessing:” results from the message code “ec.acc.feed”.
• No suffix string is output in this example, because the $suffix parameter is omitted in the
CALL.
• The string “feeder:” is the database name specified by the Feeder database number
“fd.db[TASK( )]”.
• The current record (“record” = 0) has the name “feedtube1”.
• No field name results in this example, because the field parameter is omitted in the CALL.
Related Routine
rn.error
430
rn.open.p.rec
Calling Sequence
CALL rn.open.p.rec (db, record, error)
Function
Physical record numbers should be used only in special circumstances (see Details).
When a database is closed and reopened, its physical record numbers may change.
A new record will be opened in the database.
is read.
If an error occurs, rn.opr.abort is the only operator response that is allowed.
Input Parameters
db
record
Real value specifying the number of the physical record to be opened.
Output Parameter
error
Real variable that receives a standard operator error response code. The
value is 0 if the open was successful. Otherwise, the value is rn.opr.abort.
Details
This routine performs the same operation as the routine db.open.p.rec( ) (see Chapter 14). In
addition, if an error occurs, the error condition is transmitted to the operator interface. Thus, this
routine should be called instead of db.open.p.rec( ) if you want error conditions to be handled by
the operator interface.
Physical record numbers should be used only in special circumstances where a program must
keep track of individual records across database operations that change the logical record
numbers. These operations include inserting, deleting, renaming, and sorting records. Physical
record numbers may be used when memory-resident data structures must track database record
numbers across these operations.
Note, however, that when a database is closed and re-opened, such as when AIM is shut down
and then restarted, the physical record numbers may be modified. The logical record numbers are
not modified in this case.
431
rn.open.p.rec
Related Routines
db.open.p.rec
db.open.rec
rn.open.rec
432
rn.open.rec
Calling Sequence
CALL rn.open.rec (db, record, error)
Function
A new record will be opened in the database.
is read.
If an error occurs, rn.opr.abort is the only operator response that is allowed.
Input Parameters
db
record
Real value specifying the number of the (logical) record to be opened. The
value must be greater than zero.
Output Parameter
error
Real variable that receives a standard operator error response code. The
value is 0 if the open was successful. Otherwise, the value is rn.opr.abort.
Details
This routine performs the same operation as the routine db.open.rec( ) (see Chapter 14). In
addition, if an error occurs, the error condition is transmitted to the operator interface. Thus, this
routine should be called instead of db.open.rec( ) if you want error conditions to be handled by
the operator interface.
Related Routines
db.open.p.rec
db.open.rec
rn.open.p.rec
433
rn.put.trans
Calling Sequence
CALL rn.put.trans (db, field, index, trans, error)
Function
Runtime routine to modify the value of a transformation field in the current record in a database
and handle any errors.
is read.
Input Parameters
db
field
changed. This parameter must be greater than or equal to zero.
index
modified if the specified field contains an array. Zero is assumed if this
contain an array.
trans
Transformation variable, function, or compound transformation
specifying the new location value to be placed in the record.
Output Parameter
error
Details
This routine performs the same operation as db.put.trans( ) (see Chapter 14), except that if an
error occurs, a message is sent to the operator and the runtime waits for an operator response
before continuing. This response is returned in the error output variable.
Related Routines
db.put.a.trans
db.put.trans
rn.get.trans
434
rn.put.va.num
Calling Sequence
CALL rn.put.va.num (arg, optional, value, error)
Function
Write a single value described by a variable argument. The argument is an encoded value
describing a constant, signal, ai.ctl[ ] value, or database record.
Input Parameters
arg
Encoded argument describing the data item.
optional
If TRUE and arg is not specified then write nothing, with no error.
value
Value to be written.
Output Parameter
error
Standard AIM operator response.
Details
For most databases, when you want to write a value, you simply use one of the db. routines to
place a value in the desired field. In the case of the Variable database, you may want to write a
value that reflects that variable type of the record. For example, for a record that is of type ai.ctl[ ],
you may want to actually place a value in the actual ai.ctl[ ] specified by the record. You may want
to actually set the state of a signal referenced by a record of type output signal. In these cases, this
routine will take care of the work of actually setting the relevant data type.
This routine must be used to write the values of statement arguments specified as --o_variable--.
Unlike most sequence arguments, a value of zero does not mean that the argument is undefined. A
special global variable va.undef.var is provided to allow testing of this case. For example:
IF args[out.arg] == va.undef.var THEN
;If variable not defined
...
END
Related Routine
rn.get.va.num
435
rn.resp.rest
Calling Sequence
CALL rn.resp.rest (resp[])
Function
Restores the response codes that were previously saved by the routine rn.resp.save( ).
Input Parameter
resp[ ]
A real-valued array containing the desired or saved error response codes.
If any value is set to zero, the default system response code is used.
resp[0]
resp[1]
resp[2]
resp[3]
resp[4]
resp[5]
resp[6]
Optional message code for “Proceed”.
Optional message code for “Retry action”.
Optional message code for “Skip action”.
Optional message code for “Retry statement”.
Optional message code for “Skip statement”.
Optional message code for “Skip sequence”.
Optional message code for “Abort runtime”.
Output Parameter
None.
Details
The labels associated with the push-buttons on the Task Control Panel can be dynamically set
using rn.error.resp( ) and rn.resp.save( ). This routine returns the labels to their saved values.
The restored codes are used by subsequent calls to rn.error( ).
This routine may be called instead of rn.error.resp( ).
Related Routines
rn.error.resp
rn.resp.save
436
rn.resp.save
Calling Sequence
CALL rn.resp.save (resp[])
Function
This routine saves the response codes that are currently in effect for rn.error( ). The codes may be
restored by calling the routine rn.resp.rest( ).
Input Parameter
resp[ ]
A real-valued array that can accept elements from 0 to 6.
Output Parameter
None.
Details
The labels associated with the push-buttons on the Task Control Panel can be dynamically set
using rn.error.resp( ). If you wish to save a set of labels for all calls from rn.error( ) use this routine.
The saved values can be restored with rn.resp.rest( ).
Related Routines
rn.error
rn.resp.rest
437
rn.sched.init
Calling Sequence
CALL rn.sched.init ()
Function
Initialize data structures when starting up the AIM scheduler.
This routine must be called once from each runtime task whenever the scheduler is started and
prior to calling any statement routines.
Input Parameter
None.
Output Parameter
None.
Details
This routine initializes internal AIM data structures that are used by the runtime routines.
438
rn.sched.start
Calling Sequence
CALL rn.sched.start (error)
Function
This routine performs application-dependent initialization when a runtime scheduler is started.
Input Parameter
None.
Output Parameter
error
Standard operator error code.
439
rn.send.menu
Calling Sequence
CALL rn.send.menu ($cmd, status)
Function
Send a request to the operator interface menu driver.
Input Parameter
$cmd
Standard menu command buffer.
Output Parameter
status
Details
This routine is called from a runtime task to send a request to the operator interface menu driver. It
does not wait for the operator interface to respond. Messages are queued.
Related Routines
io.post.cmd
mu.set.goto
mu.set.rtrv
440
rn.seq.exec
Calling Sequence
CALL rn.seq.exec (seqnum, cycles, dflags, ctl[], error)
Function
Main runtime sequence execution routine.
Input Parameters
seqnum
Number of the sequence to execute. Not the database number.
cycles
Number of cycles to execute.
dflags
Bit flags that are BOR’ed with the current context to determine what
statements can be executed. If a bit is set in the combined mask, then any
sequences with the corresponding bits set cannot be executed, and they
will generate an error.
ctl[ ]
Column of rn.ctl[TASK( ),] for this task.
ctl[rn.ctl.c.step]
Number of next step to be executed
ctl[rn.ctl.f.step]
Number of final step to be executed
ctl[rn.ctl.complete]
Count of loops completed
ctl[rn.ctl.seqnum]
Current sequence number
Output Parameter
error
Standard operator response code.
Details
Execute a sequence for a specified number of cycles. The proper module must already be assigned.
Any previous runtime context is pushed onto a stack. The sequence is assigned to this task, and
the runtime control data structures are initialized. Pause after statement and pause at end of
sequence are supported.
Global Variables
The following global variables contain the sequence execution stack for each runtime task.
rn.sp[TASK( )]
Stack pointer, initially –1, Incremented by 1 for each sequence pushed.
rn.stk[TASK( ),(rn.sp–1)∗rn.ctl.stk.num+index–1] Pushed values of ctl[index].
rn.seq.flags[TASK( ),sp] Flags enabled for this task.
441
rn.signal.out
Calling Sequence
CALL rn.signal.out (signal, pulse, error)
Function
Runtime routine to change or pulse a digital output signal, checking for validity.
is read.
Input Parameters
signal
Real value specifying the number of a digital signal to be asserted. Only
output signals (numbers 1 to 512) or software signals (numbers 2001 to
2512) can be used.1
If the parameter is negative, the absolute value of the number is used to
determine the signal number, and the logic of that signal is inverted.
pulse
Real value specifying the pulse time for this output, in hundredths of a
second. If zero, the signal is not pulsed, it is simply asserted.
Output Parameter
error
Details
This routine assists in processing digital output signals from the AIM runtime by checking if the
specified signal is installed and is valid for output. If an error occurs, the operator is notified, and
the operator response is returned.
In addition, this routine permits the output signal to be pulsed. However, because of the timing of
the V+ system, the pulse time is accurate only to within 16 milliseconds.
Related Routines
rn.signal.test
rn.signal.wait
1.
442
Systems that include an Adept robot can access the special 3000 series of signals.
rn.signal.test
Calling Sequence
CALL rn.signal.test (signal, error, value)
Function
Runtime routine to test the state of a digital input signal, checking for validity.
is read.
Input Parameter
signal
Real value specifying the number of a digital signal to be tested. Only
input signals (numbers 1001 to 1512) or software signals (numbers 2001 to
2512) can be used.1
Output Parameters
error
value
Real variable that receives the logical value (TRUE or FALSE) of the
specified digital input signal. If the error output parameter is nonzero
(indicating an error), this parameter always returns FALSE.
Details
This routine assists in processing digital input signals from the AIM runtime by checking if the
specified signal is installed and is valid for input. If an error occurs, the operator is notified, and
Related Routines
rn.signal.out
rn.signal.wait
1.
443
rn.signal.wait
Calling Sequence
CALL rn.signal.wait (signal, error)
Function
Runtime routine to wait for a digital input signal to become TRUE (FALSE when the logic is
inverted), checking for validity.
is read.
If the signal is already TRUE (FALSE when the logic is inverted), this routine does not wait.
Input Parameter
signal
Real value specifying the number of a digital signal to be tested. Only
input signals (numbers 1001 to 1512) or software signals (numbers 2001 to
2512) can be used.1
Output Parameter
error
(Response value rn.opr.skip is handled internally and is never returned.)
Details
This routine assists in processing digital input signals from the AIM runtime by checking if the
specified signal is installed and is valid for input. If an error occurs, the operator is notified, and
This routine waits for the specified signal to be asserted. While the routine is waiting, it checks for
robot errors and presses of the software panic button. If any error occurs, the operator is notified
and allowed to respond.
NOTE: An operator response of “skip action” causes this routine to stop
waiting and exit with the error parameter set to zero, just as if the wait
condition had been satisfied normally.
Related Routines
rn.signal.out
rn.signal.test
1.
444
rn.srv.reply
Calling Sequence
CALL rn.srv.reply ($msg, $data, error)
Function
Send a reply to a client task. The client task address is read from the $msg input buffer.
Input Parameters
$msg
Original input buffer from dv.recv( ).
$data
Data to be sent as reply.
Output Parameter
error
0 if reply is sent without error. Otherwise, standard operator error code.
Details
This routines is called by a server task to return information in response to a request from a client
task. This routine will wait if the specified queue is full. Thus, all requests will be processed, but if
a client is not removing data from the queue, the system will wait indefinitely.
Related Routines
dv.srv.reply
rn.cli.connect
rn.cli.send
rn.cli.reply
rn.cli.send
445
rn.status.num
Calling Sequence
CALL rn.status.num (idx1, num1, idx2, num2, idx3, num3, idx4,
num4)
Function
Set ai.ctl[ ] variable values for use by the operator interface.
Input Parameters
idx1
Optional. The index for the ai.ctl[ ] variable to which the first numeric
value is sent. Ignored if index is zero.
num1
Optional. First numeric value to send.
idx2
Optional. The index for the ai.ctl[ ] variable to which the second numeric
num2
Optional. Second numeric value to send.
idx3
Optional. The index for the ai.ctl[ ] variable to which the third numeric
num3
Optional. Third numeric value to send.
idx4
Optional. The index for the ai.ctl[ ] variable to which the fourth numeric
num4
Optional. Fourth numeric value to send.
Output Parameter
None.
Details
This routine sends up to four user-defined numbers to the operator interface task where they are
copied to ai.ctl[ ] variables for displaying on a status or control page.
446
rn.status.str
Calling Sequence
CALL rn.status.str (index, $msg)
Function
Set an $ai.ctl[ ] value for the operator interface.
Input Parameters
index
The index for the $ai.ctl[ ] variable to which this string is sent.
$msg
The string data that is sent. Only the first 80 bytes of the string are sent.
Output Parameter
None.
Details
This routine sends a user-defined status string to the operator interface task where it is copied to
an $ai.ctl[ ] variable for displaying on a status or operator control page.
447
rn.wait.idle
Calling Sequence
CALL rn.wait.idle (error)
Function
Runtime routine to handle teaching and other runtime functions while the task is idle.
This routine must be called by a runtime task when the task is idle (see Example below).
Input Parameter
None.
Output Parameter
error
Real variable that receives zero if the task is active, or rn.opr.abort if the
wait for startup has been aborted. These are the only two codes returned.
See the standard operator error response values.
Details
This routine serves as an interface between runtime functions, such as setup and teaching, and the
operator interface task. This routine should be called from each runtime task whenever the task
becomes idle and is waiting to be started.
If this routine returns with a non-zero error value, the global AIM shutdown variable ai.stop.prog
must be tested to see if AIM is shutting down. If this variable is FALSE, this routine should be
called again.
Example
The following code segment shows how this routine is used within the standard AIM
runtime task:
DO
CALL rn.wait.idle(error)
IF error GOTO 100
; Execute runtime code until loops are completed
; or "rn.opr.abort" is received.
100 UNTIL ai.stop.prog
This loop executes until the AIM system is shut down and the variable ai.stop.prog is set to
TRUE.
448
rn.wait.time
Calling Sequence
CALL rn.wait.time (time, error)
Function
Runtime routine to cause the current runtime task to wait for a specified time.
This routine does not affect any current robot motion.
Input Parameter
time
Real value that specifies the time to wait, in seconds.
Output Parameter
error
Real variable that receives a standard operator error response value. The
value rn.opr.abort indicates that an error has occurred during the wait,
and the operator has chosen to stop the runtime. Otherwise, the value
zero is returned.
Details
This routine waits for a specified time. The actual wait time is accurate to 16 milliseconds. The
actual time may be much longer than the specified time, depending on the relative priorities of
tasks in the system.
If errors occur or the panic button is pressed, the operator is notified and allowed to respond with
proceed, skip action, or abort. The proceed response continues waiting from the point at which the
error occurred. The skip action response terminates the waiting and returns the value zero in the
error parameter. The abort response returns the value rn.opr.abort in error.
Related Routine
rn.delay
449
rn.walk.train
Calling Sequence
CALL rn.walk.train (db, field, index, status, error)
Function
Runtime routine to train a value in a database record during walk-thru training mode.
The database record containing the field to be trained should be open when this routine is called.
Input Parameters
db
field
Real value specifying the number of the field whose value is to be trained.
This parameter must be greater than or equal to zero.
index
trained if the specified field contains an array. Zero is assumed if this
contain an array.
status
Real value that specifies the status code returned from the database
routine that attempted to read the data value. The status code may
indicate success or any other database error.
Output Parameter
error
Real variable that receives a value indicating the operator response to the
request to train data. See the standard operator error response values.
Details
This routine is normally called only when walk-thru training mode is enabled. This is the lowestlevel walk-thru training routine, and it is used within routines such as rn.get.num( ) and
rn.get.trans( ). Those routines should be used if possible.
See the sample walk-thru training program in “Sample Walk-Thru Training Program” on page 78
for an example of how rn.walk.train( ) is used.
If appropriate, this routine displays a message to the operator requesting the specified data field to
be defined or modified. A message is sent to the operator under the following conditions:
• An unexpected database error occurred when accessing the value.
• An undefined required data field is encountered. (The ai.attr.opt bit is not set in the field
attributes.)
• Edit-data mode is selected and an optional data field is encountered with no data defined.
450
rn.walk.train
• Edit-data mode is selected and a data field with the edit-data attribute is encountered, even if
valid data is already defined. (The ai.attr.edit bit is set in the field attributes.)
Related Routines
rn.get.a.num
rn.get.a.nums
rn.get.a.str
rn.get.num
rn.get.trans
451
select_task
Calling Sequence
CALL select_task (args[], error)
Function
Statement execution routine for the SELECT_TASK statement.
Input Parameter
args [ ]
Not used.
Output Parameter
error
Details
The specified module and sequence are selected for the specified task.
Syntax:
Argument
SELECT_TASK task {MODULE module} {SEQUENCE sequence}
Type or Database
Misc.
task
task name
$sq.args[1]
module
module name
optional
$sq.args[2]
sequence
sequence name
optional
$sq.args[3]
File:
CTLRUN.V2
452
set
Calling Sequence
CALL set (args[], error)
Function
This routine is called from the runtime scheduler when it encounters a SET statement. It evaluates
an expression and sets the value in the specified variable.
Input Parameter
args[ ]
Output Parameter
error
Syntax:
SET dst_var = {uopr} var1 {opr1 var2 {opr2 var3 ...
}... }
Details
Argument
Type or Database
Misc.
dst_var
o_variable
args[1]
dummy
none
=
args[2]
uopr
Unary operator
optional
args[3]
var1
variable
opr1
Binary operator
optional
args[5]
var2
variable
optional
args[6]
...
...
...
...
opr5
Binary operator
optional
args[13]
var6
variable
optional
args[14]
File:
CNDRUN.V2
args[4]
453
set_response
Calling Sequence
CALL set_response (args[], error)
Function
This routine is called from the runtime scheduler when it encounters a SET_RESPONSE statement.
Input Parameter
args[ ]
Array of arguments (recorded numbers or constants)
Output Parameter
error
Details
This routine uses the input argument value and processes it as if it were an operator response
code. The runtime execution may be stopped or the normal flow of sequence execution may be
changed.
If an invalid response code is received, an error is issued.
Syntax:
Argument
response
SET_RESPONSE response
Type or Database
variable
Misc.
args[1]
Related Routine
message
454
start_task
Calling Sequence
CALL start_task (args[], error)
Function
Statement execution routine for the START_TASK statement.
Input Parameter
args[ ]
Output Parameter
error
Details
The specified runtime task is linked if necessary and started.
Syntax:
Argument
START_TASK task
Type or Database
task
task name
File:
CTLRUN.V2
Misc.
$sq.args[1]
455
stop_task
Calling Sequence
CALL stop_task (args[], error)
Function
Statement execution routine for the STOP_TASK statement.
Input Parameter
args[ ]
Output Parameter
error
Details
The specified runtime task is paused. If the event is not specified, an immediate stop is requested.
Syntax:
Argument
STOP_TASK task {AFTER event}
Type or Database
task
task name
event
constant
File:
CTLRUN.V2
Misc.
$sq.args[1]
optional
args[2]
456
unload
Calling Sequence
CALL unload (args[], error)
Function
Statement execution routine for the UNLOAD statement.
Input Parameter
args[ ]
Not used.
Output Parameter
error
Details
The module and its related databases are unloaded.
Syntax:
Argument
UNLOAD MODULE module
Type or Database
module
module name
File:
CTLRUN.V2
Misc.
optional
$sq.args[1]
457
value
Calling Sequence
CALL value (args[], error)
Function
This routine is called from the runtime scheduler when it encounters a VALUE statement.
Input Parameter
args[ ]
Output Parameter
error
Syntax:
VALUE constant {, constant1 {, constant2 ... } ... }
Details
Argument
Type or Database
Misc.
constant1
constant
args[1]
constant2
constant
optional
args[2]
constant3
constant
optional
args[3]
constant4
constant
optional
args[4]
constant5
constant
optional
args[5]
constant6
constant
optional
args[6]
constant7
constant
optional
args[7]
constant8
constant
optional
args[8]
constant9
constant
optional
args[9]
constant10
constant
optional
args[10]
null
458
args[11]
next
[statement number]
from linker
args[15]
end
[statement number]
from linker
args[16]
wait
Calling Sequence
CALL wait (args[], error)
Function
This routine is called from the runtime scheduler when it encounters a WAIT statement.
Input Parameter
args[ ]
Output Parameter
error
Details
This routine causes a sequence to wait for the specified time in 1/100ths of a second.
Syntax:
Argument
WAIT time
Type or Database
time
CONSTANT
File:
CNDRUN.V2
Misc.
args[1]
459
wait_for
Calling Sequence
CALL wait_for (args[], error)
Function
This routine is called from the runtime scheduler when it encounters a WAIT_FOR statement.
Input Parameter
args[ ]
Output Parameter
error
Details
This routine is also called by the routine that interprets the IO statement. The arguments are the
same, except that in this case, sig1 is optional. So in this routine, all three arguments are assumed
to be optional: sig1, sig2, and time.
Syntax:
Argument
WAIT_FOR sig1 {OUTPUT sig2 {PULSE time}}
Type or Database
Misc.
sig1
output signal
args[1]
sig2
output signal
optional
args[2]
time
constant
optional
args[3]
File:
CNDRUN.V2
460
wait_until
Calling Sequence
CALL wait_until (args[], error)
Function
This routine is called from the runtime scheduler when it encounters a WAIT_UNTIL statement.
Input Parameter
args[ ]
Output Parameter
error
Details
This routine waits for the signal expression to be TRUE, or until the optional time-out expires. The
time-out is in 1/100ths of a second.
Syntax:
WAIT_UNTIL {uopr} var1 {opr1 var2 {opr2 var3 ...}...}
{TIMEOUT constant}
Argument
Type or Database
Misc.
optional
uopr
Unary operator
args[1]
var1
variable
opr1
Binary operator
optional
args[3]
var2
variable
optional
args[3]
...
...
...
...
opr5
Binary operator
optional
args[11]
var6
variable
optional
args[12]
time-out
Constant
optional
args[13]
File:
CNDRUN.V2
args[2]
461
while
Calling Sequence
CALL while (args[], error)
Function
This routine is called from the runtime scheduler when it encounters a WHILE statement.
Input Parameter
args[ ]
Output Parameter
error
Details
This statement marks the beginning of a WHILE loop. The statements between the WHILE
statement and its corresponding END statement will execute until the while condition is FALSE.
Syntax:
WHILE {uopr} var1 {opr1 var2 {opr2 var3 ...}...}
Argument
Type or Database
Misc.
optional
uopr
Unary operator
args[1]
var1
variable
opr1
Binary operator
optional
args[3]
var2
variable
optional
args[4]
...
...
...
...
opr5
Binary operator
optional
args[11]
var6
variable
optional
args[12]
next
statement number
from linker
args[16]
File:
CNDRUN.V2
args[2]
462
Chapter 17
Descriptions of Menu Spawn Routines
This chapter describes the functions and calling sequences of user-written spawn routines used
with the menu driver. These routines, which are used for implementing non-standard operatorinterface functions, are called by the menu driver. (Refer to Chapter 9 for more information on the
menu driver in general, and on spawn routines in particular.)
NOTE: Unlike the routines described in Chapter 14 and Chapter 16, the
routines described here are written by the system customizer and called
by the AIM system.
Each routine is presented on a separate page, in alphabetical order. The “dictionary page” for each
routine contains the following sections, as applicable:
463
Chapter 17 - Descriptions of Menu Spawn Routines
Program Parameters
The formats of the calls to menu spawn routines are established within the AIM system and
cannot be changed by the system customizer. To be compatible with the subroutine call, the first
line of the spawn routine must have the format shown in this section.
NOTE: The routine name, and the variable names used for the routine
parameters, are for explanation purposes only. Your spawn routine can
use any (unique) routine name and any variable names you want.
Function
This section is used to point out special considerations associated with the routine.
Routine Name
This represents the user-defined name of the menu spawn routine. This name must exactly match
the name specified for the related menu item.
As with all V+ program names, this name must: begin with a letter; can be one to fifteen characters
long; and consist of only letters, numbers, and period (“.”) and underbar (“_”) characters.
Input Parameter
Each of the input parameters in the calling sequence is described in detail. The routine should not
modify any of the input parameters.
Output Parameter
Each of the output parameters in the calling sequence is described in detail. The spawn routine
must set the output parameters as described.
Details
A description of the routine and its use is given.
464
menu.but.spawn
Program Parameters
.PROGRAM menu.but.spawn (arg, db.p, $cmd)
Function
Respond to activation of a menu spawn-routine button. See section 8.9.
The routine menu.but.spawn( ) is not provided with the AIM system. This documentation
describes the calling sequence for menu “button” spawn routines, which must be written by the
system customizer.
There can be as many “button” spawn routines as desired. The actual names for such routines are
established by the system customizer, but the calling sequence must be as described here.
None of the input parameters should be modified by the routine.
When a spawn routine needs to access the menu window, it can do so by referencing logical unit
number io.lun. However, user routines should never alter which window is open on this logical
unit (that is, routines should never perform FCLOSE or FOPEN operations on this logical unit).
User routines should never access logical unit number io.lun2, which is used by the menu driver
for the main menu window.
Routine Name
User Defined
The name you choose for this spawn routine must match the one
specified in the menu page item. Additionally, the parameter list must
match the number and type of the parameters listed above, although you
can use any variable names you wish. You can create as many different
spawn routines of this type as needed.
Input Parameters
arg
Specifies the value of the routine argument defined in the button menu
record. This value is not used by the menu driver; it is passed to the
spawn routine to help differentiate which button was selected.
db.p
Specifies the number of the primary database in effect for the current
menu page. All record-oriented operations (for example, delete record
and append record) are directed to the primary database. Also, any menu
items that reference a database, but do not have a database specified, use
the primary database number.
$cmd
Contains the ky.spawn or ky.m.spawn command that initiated the menu
spawn routine. The command is stored in the standard format for I/O
communications buffers.
Output Parameter
$cmd
String variable that contains an error message or a new command to be
processed by the menu driver. In either case, the value is returned in the
standard format for I/O communications buffers.
465
menu.but.spawn
If an error is returned, the qualifier of the communications buffer must
contain the error code. In this situation, the error will be displayed by the
menu driver, after which the original menu page will be redrawn
automatically.
If a command is to be processed on completion of the spawn routine, the
communications buffer must contain the command, stored in the
standard I/O buffer format. Some typical commands that are returned by
this type of routine are as follows:
Command
Interpretation
ky.refresh
Update any fields marked as auto refresh
ky.redraw
Redraw the displayed menu page and reevaluate any conditional format
ky.exit
ky.yes
ky.no
Terminate execution of the current menu
page, pop the menu stack, and continue
execution of the next higher-level menu (etc.)
ky.menu
Display and execute the menu page that is
specified in this communications buffer
If no operation is to be performed on exit, and no error occurred, the qualifier of the
communications buffer should be set to 0.
Details
This type of spawn routine is called by the menu driver when the operator activates a menu
spawn-routine button. These spawn routines can be utilized to implement special functions that
are not supported by the menu driver. Often, these routines perform a simple function, do not
generate any output to the operator, and quickly return control to the menu driver. At other times,
these spawn routines provide a means for major software packages to take over full control of the
operator interface.
When this type of routine begins execution, the menu page that contained the spawn-routine
button will be displayed in a screen window that is opened on logical unit number (LUN) io.lun.
The spawn routine is free to write to this window. However, the spawn routine should not alter
which window is opened on this LUN, as this may affect the operation of the menu driver when
the spawn routine terminates execution.
When a button spawn routine exits, it returns a standard I/O communications buffer. The
communications buffer can contain an error code that will be interpreted and displayed by the
menu driver. Alternately, the communications buffer can contain any standard menu-driver
command, which will subsequently be interpreted and executed by the menu driver.
466
menu.chk.spawn
Program Parameters
.PROGRAM menu.chk.spawn (arg, mode, db.p, type, db[], vals[],
$stg, $cmd)
Function
Respond to a request from the menu driver to verify that the value of a data field can be modified.
See sections 8.10, 8.11, and 8.13.
The routine menu.chk.spawn( ) is not provided with the AIM system. This documentation
describes the calling sequence for menu “value_check” spawn routines, which must be written by
the system customizer.
There can be as many “value_check” spawn routines as desired. The actual names for such
routines are established by the system customizer, but the calling sequence must be as described
here.
Routine Name
User Defined
Input Parameters
arg
Specifies the value of the “routine argument” defined in the data-editing
menu record. This value is not used by the menu driver: it is passed to the
spawn routine to help differentiate which data field is being modified.
mode
Specifies the action to be taken as follows:
0
A new value has been entered. The spawn routine must validate the
new value and return an indication of whether or not the new value
is acceptable.
1
The value of the field is to be deleted. The spawn routine must verify
that the value can be deleted.
2
A new value has been entered, custom formatting is enabled. Only
occurs if
Check before display is indicated for this field in the
menu page field definition.
✔
467
menu.chk.spawn
3
A new value is about to be displayed, custom formatting is enabled.
Only occurs if
Check before display is indicated for this field in
the menu page field definition.
10
The value has been double clicked or a Go To (F3) has been received.
The spawn routine can execute any required special processing, or
allow the menu driver to perform the standard processing of this
event.
11
A Display (F5) command has been received. The spawn routine can
execute any required special processing, or allow the menu driver to
perform the standard processing of this event.
✔
db.p
type
Specifies the type of data field that is being accessed. The possible values
are as follows:
db[ ]
Value
Interpretation
mu.ty.bsig
Digital signal
mu.ty.cval
Scalar number
mu.ty.cstg
String
mu.ty.trans
Transformation
mu.ty.date
Date/time
Real array that contains information that defines the database field or
system control value that is being accessed.
If a database field is being accessed, this array contains the following
information:
db[0]
db[1]
db[2]
db[3]
db[4]
Database number (1 to n)
Field number (0 to m)
Array index (0 to p)
Bit number (0 = not a bit field, 1 = LSB, etc.)
Current menu database number.
If a V+ variable is being accessed, this array contains the following
information:
db[0]
db[1]
db[2]
db[3]
db[4]
468
–1
0
0
Bit number (0= not a bit field, 1= LSB, etc.)
Current menu database number. In this case, the name of the
V+ variable may be determined with mu.get.vname( ).
menu.chk.spawn
If a system control value (ai.ctl[ ] or $ai.ctl[ ]) is being accessed, this array
contains the following:
db[0]
db[1]
db[2]
db[3]
db[4]
vals[ ]
0
0
Index for either ai.ctl[ ] or $ai.ctl[ ]
Bit number (0 = not a bit field, 1 = LSB, etc.)
Current menu database number.
Real array that contains the new value(s) to be written. Depending upon
the type parameter, this array contains the following values (only for
mode 0):
Type
Contents
Digital signal
vals[0] contains TRUE or FALSE
Scalar number
vals[0] contains new value
String
vals[0] contains 0
Transformation
vals[0] through vals[5] contain the
DECOMPOSEd components of the
transformation
Date/time
vals[0] contains the date and vals[1]
contains the time, in the format returned by
the real-valued function TIME( )
In mode 1, for completeness, all of the elements of vals[ ] are set to zero.
$stg
Contains the new value of the string if the type is mu.ty.cstg (mode 0
only). For all other data types, the value of this string is null.
In mode 0: For string data types (type is mu.ty.cstg), this contains the new
value of the string. Otherwise, an empty string.
In mode 2: This contains the raw ASCII data received for input. In all
other modes, this is an empty string.
$cmd
Contains the command that was received, in the standard format for I/O
communications buffers (valid only for modes 10 and 11).
Output Parameters
For mode 0, the output parameters are as follows:
vals[ ]
Real array whose input values are modified to reflect the actual values to
be written. The spawn routine can modify the input values if desired, and
the modified values will be written and displayed. This array is valid
only if no error is indicated and the data type is not mu.ty.cstg.
$stg
String variable whose input value is modified to reflect the actual value to
be written. The spawn routine can modify the input value if desired, and
the modified value will be written and displayed. This string value is
valid only if no error is indicated and the data type is mu.ty.cstg.
469
menu.chk.spawn
$cmd
String variable that returns an error message, in the standard format for
I/O communications buffers. If the value contained in vals[ ] or $stg is
valid, the qualifier of the I/O buffer must be greater than or equal to zero.
Otherwise, if the value is invalid, the qualifier must contain an error code.
For mode 1, the output parameter is as follows:
$cmd
I/O communications buffers. If deleting is permitted, the qualifier for the
buffer should be zero. Otherwise, the qualifier should be set to an error
code.
$cmd
Command I/O buffer that contains either a 0 for the qualifier to indicate
that the input should be accepted or an error code if the input is not
accepted.
$stg
The ASCII data to be processed according to the indicated field type.
$cmd
Command IO buffer that contains either a 0 for the qualifier to indicate
that the field should be displayed normally or an error code if the field
should not be displayed at all.
$stg
If a 0 qualifier is returned in $cmd, and if, and only if, $stg is not null, $stg
is used as the display for the field. If the field type is an icon, $stg is used
as the name of the icon and vals[0] is used as the icon index.
vals[ ]
If $stg is null, vals[ ] contains the value to be formatted and displayed
according to the format specified in the record.
For modes 10 and 11, the output parameter is as follows:
$cmd
String variable that returns a command or error message. If the menu
driver is to process the double click or Go To (F3) in the usual fashion, the
value of $cmd should not be changed from its input value. Otherwise, the
output value should be a menu command or error, in the standard format
for an I/O communications buffer.
Details
This type of spawn routine is associated with a data field that allows write access to a database
value, a global control value, or a digital output signal. The spawn routine permits application
programs to perform special range checking and operations each time a new value is entered for a
data field.
A value check routine can be specified for every menu database record which allows read or write
access to a database value, a global control value, or a binary output signal. This check routine is
called in the following circumstances:
1. Before the value is displayed on the menu page. The check routine may check the value and
indicate an error or it may change (or set) the value to be displayed. It may allow the menu
driver to display the value using the format indicated by the field, or it may display the value
using a custom format.
470
menu.chk.spawn
2. After the value has been edited by the operator, but before the menu driver has examined the
ASCII input data. The routine may modify the ASCII input which is then processed according
to the specified format.
3. After the value has been edited by the operator and verified for proper format and range by
the menu driver. If the check routine returns an indication that the value is acceptable, the
new value will be written by the menu driver. If the check routine returns an error code, the
corresponding error message will be displayed as a pop-up.
4. When the associated data field is selected and a double click event, a GOTO key press or a
display selection key press is issued. The check routine is called before the menu driver
processes the key press. This allows the check routine to intercept the event and perform an
alternate operation, if desired.
471
menu.cnd.spawn
Program Parameters
.PROGRAM menu.cnd.spawn (arg, db.p, draw)
Function
Respond to a request from the menu driver to define the state of a menu page conditional section.
See section 8.14.
The routine menu.cnd.spawn( ) is not provided with the AIM system. This documentation
describes the calling sequence for menu “conditional” spawn routines, which must be written by
There can be as many “conditional” spawn routines as desired. The actual names for such routines
are established by the system customizer, but the calling sequence must be as described here.
Routine Name
User Defined
Input Parameters
arg
Specifies the value of the “routine argument” defined in the conditional
menu record. This value is not used by the menu driver, but is passed to
the spawn routine to help differentiate which conditional test is to be
performed.
db.p
Output Parameter
draw
472
Real variable that receives the value TRUE if the menu items within the
conditional section should be displayed. Otherwise, the value FALSE is
returned.
menu.cnd.spawn
Details
This type of spawn routine is called by the menu driver when a conditional menu record is
encountered whose state is dependent upon the result returned by a spawn routine. This type of
spawn routine can be utilized to evaluate conditional display requirements that are more
complicated than the simple equality tests that can be performed automatically by the menu
driver.
The spawn routine will be called when the menu page is first drawn, and each time that it is
redrawn (assuming that the conditional record is not ignored due to a higher-priority conditional
being FALSE).
473
menu.pag.spawn
Program Parameters
.PROGRAM menu.pag.spawn (arg, mode, db.p, lun, luns[], $cmd)
Function
Respond to a request from the menu driver for any special processing desired for a menu page.
See section 8.8.
The routine menu.pag.spawn( ) is not provided with the AIM system. This documentation
describes the calling sequence for menu-page spawn routines, which must be written by the
system customizer.
There can be as many “page” spawn routines as desired. The actual names for such routines are
Routine Name
User Defined
Input Parameters
474
arg
Specifies the value of the “routine argument” defined in the page header
menu record. This value is not used by the menu driver; it is passed to the
spawn routine to help differentiate which menu page is being processed.
mode
Specifies the menu processing mode, as follows:
mode
Interpretation
mu.rf.first
The menu page has just been selected and is being
drawn for the first time. The page spawn routine is
called after the page header record has been
opened and before any other processing for the
menu page is performed. This call to the page
routine will be followed by a call with mode
mu.rf.redraw.
menu.pag.spawn
mode
Interpretation
mu.rf.redraw
The menu page is about to be completely drawn or
redrawn. A full redraw occurs when: the menu
page is first invoked, the Redraw (Shift+F6) key is
pressed, a field value is edited and a redraw is
requested, another menu spawn routine has
requested a redraw, processing of the menu page
is being resumed after the completion of another
menu page that was invoked from this page, or a
different record is selected in the primary database
being edited.
The page routine is called after the window has
been created or cleared, but before any menu
records (other than the page header) are
processed.
mu.rf.refresh
The auto-refresh fields of a page are about to be
sampled for refresh. The page routine is called
before any values are sampled.
mu.rf.lun.io
Input has been received on an auxiliary LUN that
is being scanned. The received input is passed to
this routine and not processed by the menu driver.
mu.rf.nxt.menu
A new menu page (possibly a pop-up) has been
invoked; processing of the current page is being
suspended. The page routine will be called later,
either with mode mu.rf.redraw to indicate that
processing of the page has resumed, or mode
mu.rf.exit to indicate that the processing of the
page is being terminated.
mu.rf.spw.str
Control is being passed to a button spawn routine,
and so processing of the menu page is being
suspended.
mu.rf.spw.end
The button spawn routine has completed
execution and processing of the menu page is
being resumed.
mu.rf.rec.opr
A record operation has been invoked (for example,
delete database record or move to next record). If
this command is ignored, the menu driver will
process the record operation in the normal
manner. Otherwise, the page routine can take
whatever action is required, and return an
alternate command.
mu.rf.exit
Processing of the current menu page is being
terminated.
475
menu.pag.spawn
db.p
This value is always 0 for mode mu.rf.first, since the primary database is
not established at the time this routine is called.
lun
Specifies the number of the logical unit on which input was received
(valid only in mode mu.rf.lun.io).
$cmd
String value, variable, or expression that contains an input event or
command in the standard format for I/O communications buffers.
The value of this parameter is interpreted as a function of the mode
parameter, as follows:
mode
Interpretation of $cmd
mu.rf.lun.io
The buffer contains the input event that
was received on the LUN. The event type is
contained in the buffer qualifier, and the
event parameters are stored in io.int1,
io.int2, and io.int3 in the buffer data
section.
mu.rf.rec.opr
The buffer contains one of the following
commands:
ky.back
ky.index
ky.previous
ky.copy.rec
ky.last
ky.repeat
ky.cut.rec
ky.new
ky.retrieve
ky.first
ky.next
ky.search
ky.paste.rec
ky.search.fail
mu.rf.refresh
The buffer is initialized to the value
$io.cmd.nop as a convenience.
(all others)
Not used.
Output Parameters
For mode mu.rf.redraw, the output parameter is as follows:
luns[ ]
Real array that contains a list of auxiliary LUNs that the menu driver is to
scan for input. The number of auxiliary LUNs to scan is in luns[0]. The
auxiliary LUN numbers are stored in sequential elements starting with
luns[2] (not element #1). Element zero is initialized to 0 by the menu
driver. Up to nine LUNs can be specified.
NOTE: The menu driver uses logical unit io.lun for all of its window
operations and logical unit io.lun2 for the main pull-down window.
Thus, these logical units should never be specified as auxiliary logical
units.
476
menu.pag.spawn
For mode mu.rf.lun.io, the output parameter is as follows:
$cmd
String variable that returns a command, in the standard format for I/O
communications buffers. This command is generated by the spawn
routine in response to input received from the auxiliary LUN, and is
processed by the menu driver when this routine exits. If no action is to be
taken, the buffer qualifier should be set to zero. While this command
buffer can contain a window event command (mouse down, etc.),
normally one of the following key-press commands is returned:
ky.exit
Exit menu page
ky.redraw
Redraw menu page
ky.refresh
Update auto-refresh values
For mode mu.rf.refresh, the output parameter is as follows:
$cmd
String variable that returns a command or error message, in the standard
format for I/O communications buffers. If no special function is to be
performed following the refresh operation, this parameter should be
unchanged from its initial value of $io.cmd.nop. Otherwise, this can
contain any error code or command that you wish to have executed. As
with mode mu.rf.lun.io, the most likely commands returned are
ky.redraw or ky.exit.
For mode mu.rf.rec.opr, the output parameter is as follows:
$cmd
format for I/O communications buffers. If the menu driver is to process
the record operation in the normal fashion, this parameter should be
unchanged from its input value. Otherwise, $cmd should contain a menu
command or error, in the standard I/O communications buffer format. If
the record operation is to be ignored, the buffer qualifier should be set to
zero.
Details
A menu-page spawn routine is specified in the header record for a menu page and is called
whenever the page is drawn or an operation is performed that has an effect on the entire page.
This type of routine can be used to precompute values referenced by the page, write additional
information in the menu window, intercept and change the meaning of record-oriented
operations, or service input from auxiliary LUNs.
For menu pages that include a page routine, this spawn routine will be called under the following
circumstances:
1. Just before the page is fully drawn or redrawn.
2. Just before the auto-refresh values of the page are updated.
3. If input is received on an auxiliary LUN.
4. When processing of the menu page is being terminated.
5. Just before a record operation is to be performed (delete record, create record, next record,
etc.).
477
menu.pnl.spawn
Program Parameters
.PROGRAM menu.pnl.spawn (arg, mode, db.p, x, y, dx, dy $cmd)
Function
Respond to a request from the menu driver for any special processing desired for a panel (or
rectangle) on a menu page, including special handling of input events that occur when the panel
(or rectangle) is selected. See section 8.12.
The routine menu.pnl.spawn( ) is not provided with the AIM system. This documentation
describes the calling sequence for menu “panel” spawn routines, which must be written by the
system customizer.
There can be as many “panel” spawn routines as desired. The actual names for such routines are
Routine Name
User Defined
Input Parameters
arg
Specifies the value of the “routine argument” defined in the panel (or
rectangle) menu record. This value is not used by the menu driver, but is
passed to the spawn routine to help differentiate which panel (or
rectangle) is being processed.
mode
0 The window is being completely drawn. The spawn routine is being
notified of the window coordinates of the panel (or rectangle).
1 Either the panel (or rectangle) has been selected, or a mouse or key-press
event has occurred within the window. The spawn routine is being
passed the selection notification or event so that it can perform
whatever processing is required.
db.p
478
menu.pnl.spawn
x, y, dx, dy
Specify the coordinates of the panel (or rectangle) defined by the menu
record. The x and y values are coordinates of the upper left-hand corner
of the panel (or rectangle), and the dx and dy values are the width and
height, respectively, of the panel (or rectangle). All the values are in
pixels. In mode 1, these values are all zeros.
Normally, the graphics generated by this routine are drawn within this
rectangle, but graphics may be drawn anywhere in the window.
$cmd
Contains the key press or mouse command that was received, in the
standard format for I/O communications buffers (valid only for mode 1).
The following are possible qualifiers of the command:
ky.b.tab
ky.display
ky.f.up
ky.but.down ky.down
ky.goto
ky.but.move ky.f.down
ky.return
ky.but.up
ky.f.left
ky.tab
ky.dbl.clk
ky.f.right
ky.up
Use INTB($cmd, io.qal) to extract the qualifier.
Output Parameter
$cmd
format for I/O communications buffers (this parameter is ignored in
mode 0). This command is processed by the menu driver when this
routine exits. If no operation is to be performed, the qualifier should be
set to 0. If an error is to be reported by the menu driver, the qualifier
should contain the error code.
Details
This type of spawn routine is associated with a menu record that draws a panel (or a rectangle).
This spawn routine permits application software to detect how a panel (or rectangle) is positioned
and sized, and to intercept all mouse events that occur within the panel (or rectangle).
When the panel (or rectangle) is drawn, this routine is called with the position and dimensions of
the panel (or rectangle). This allows customized graphics to be drawn in a window location
determined by the standard menu editor.
While the panel (or rectangle) is displayed, any key presses that select the panel (or rectangle) or
any mouse events within the panel (or rectangle) are sent to this routine.
Application programs can output to the window using standard V+ graphics instructions that are
directed to the logical unit io.lun. When this spawn routine is called, the logical operation is set to
“source”, and the texture mode and pattern are set to “transparent” and “solid”, respectively. If
these settings are changed, they must be restored to these initial values before the routine returns.
The initial color values are not initialized, may be freely changed, and do not need to be restored.
479
menu.scr.spawn
Program Parameters
.PROGRAM menu.scr.spawn (arg, mode, db.p, line, n.line, $line,
$cmd)
Function
Respond to a request from the menu driver for any special processing desired for a scrolling-text
window. See section 8.15.
The routine menu.scr.spawn( ) is not provided with the AIM system. This documentation
describes the calling sequence for menu “scrolling-text” spawn routines, which must be written by
There can be as many “scrolling-text” spawn routines as desired. The actual names for such
routines are established by the system customizer, but the calling sequence must be as described
here.
Routine Name
User Defined
Input Parameters
480
arg
Specifies the value of the “routine argument” defined in the scrolling
window menu record. This value is not used by the menu driver, but is
passed to the spawn routine to help differentiate which scrolling window
is being processed.
mode
0
The window is being completely drawn. The spawn routine must
return the total number of text lines and the number of the selected
line.
1
A line of text is being displayed. The spawn routine must return the
contents of the line.
2
The selected line has been changed. The spawn routine is receiving
notification of this event. If there are no lines to select, this mode will
not be generated.
menu.scr.spawn
Immediately after the spawn routine is called in mode 2, it will be
executed again in mode 1 to allow the selected line to be redrawn.
Also, formerly, if a line was already selected and the operator
clicked on the same line, the spawn routine was not executed.
However, this was changed in 3.0, and the spawn routine is
executed in mode 2, even if the line was formerly selected.
10
Double click or Go To (F3) was received in the scrolling window.
This command can be generated even if there are no lines defined in
the scrolling window.
11
A Display (F5) command was received in the scrolling window. This
command can be generated even if there are no lines defined in the
scrolling window.
db.p
line
Real value, variable, or expression that is interpreted based upon the
value of mode as follows:
mode
0
Not used as an input parameter
1
Number of the line being displayed (1 to n)
2
Number of the line being selected (1 to n)
10 or 11
$cmd
Interpretation of line
Number of the line currently selected (0 to n)
String value, variable or expression that contains the command that was
received, in the standard format for I/O communications buffers (valid
only for mode 10 and mode 11).
Output Parameters
line
Real variable that returns the number of the first selected line (0 to n).
Zero should be returned only if the scrolling window does not contain
any lines of text.
n.line
Real variable that returns the total number of lines that can be displayed
(0 to n).
$line
String variable that returns the contents of the line to be displayed.
$cmd
I/O communications buffers. The qualifier of the buffer should be greater
481
menu.scr.spawn
than or equal to zero if no error occurred in creating the text line.
Otherwise, the qualifier should be set to an error code.
If the qualifier is ky.color, the qualifier is followed by a value that
specifies the color to be used to draw the text returned in $line.
The color standards are:
io.col.cmplx (blue)
Indicates a complex item or label for a list of
items (e.g., used for directory file names or labels
above groups of radio buttons).
io.col.err (red)
Highlights an error message.
io.col.hilgt (maroon)
Highlights a selected item (e.g., selected item in
the motion tweek pop-up).
For mode 2, there are no output parameters.
For mode 10 and mode 11, the output parameter is as follows:
$cmd
format for I/O communications buffers. If the menu driver is to process
the double click or Go To (F3) in the usual fashion, the value of $cmd
should be unchanged from its input value. Otherwise, this parameter
should contain a menu command or error in the standard format for I/O
communications buffers.
Details
This type of spawn routine is called by the menu driver in connection with a menu record for a
scrolling-text window. This type of spawn routine performs the following functions:
1. When the window is first drawn, the spawn routine specifies the number of text lines that
exist and defines the number of the first selected line.
2. When the window is first drawn and each time it is scrolled, this routine supplies the lines of
text that are displayed in the window.
3. Each time a new selected line is specified by the operator, this routine receives notification of
the new selected line.
4. Each time a double click, Go To (F3) or Display (F5) command is received in the scrolling
window, this routine receives notification of the event before the menu driver processes the
event. This allows the user routine to intercept the event and perform an alternate operation,
if desired.
While this routine is responsible for supplying all of the text information, the menu driver is
responsible for displaying the information and controlling the highlighting to indicate the selected
line.
482
Appendix A
Baseline Menu Bars and Quick Keys
This chapter gives a brief overview of the pull-down menus and quick keys associated with the
baseline system. Additional pull-down menus and quick keys are defined in other AIM modules
that you may have (MotionWare or VisionWare, for example).
483
Appendix A - Baseline Menu Bars and Quick Keys
A.1
Database Manager Utility Menu
The following menu options are available whenever the database manager utility is open
(Utilities ➡ DBM Utilities):
File
Switch File
Select a different database or record/field definition file to edit
Save Changes
Save changes made to the definition file
Export RFD File
Export an ASCII version of the .RFD file.
Export DB File
Export an ASCII version of the database file
Convert DB
Convert a database to a new format specified by the existing .RFD file.
Merge DB Data
Merge data from another database with the current database
Compress File
Remove all records that are marked as deleted in the current database
Delete All Records
Remove all records from the current database
Exit
Exit the database manager utility
New
Create RFD File
Create a new record/field definition file
Extract RFD from DB
Create a record definition file based on an existing database file
Create DB From RFD
Create a new database file based on the current .RFD file
484
The Menu Editor Menus and Quick Keys
A.2
When you enter the menu page editing mode (Utilities ➡ Edit Menu), a special menu bar will be
displayed. The editing operations that can be performed from this menu bar are described below.
File
Switch File
Switch to a different file of menu pages to edit
Create File
Create a new file of menu pages
Reset Conditionals
Reset any conditionals altered from the “Conditional Item Index” window
Save Changes
Save changes made to any menu pages
Create Page
Create a new menu page in the current file
Copy Page
Create a copy of the current menu page and go to that page
Copy Page to File
Copy the current menu page to a different menu page file
Rename Page
Rename the current menu page
Delete Page
Delete the current menu page
Exit and Save
Exit the menu page editor
Go
Edit Page Header
Edit the page header for the displayed menu page
Edit Items
Display a pick list of menu items, select an item to edit
Conditionals
Open “Conditional Item Index” window, set the status of any conditional item
Menu Pages
Display a pick list of the menu pages in the current file
485
Appendix A - Baseline Menu Bars and Quick Keys
New
Menu Button
Create a button that will display a menu page
Spawn Rtn Button
Create a button that will spawn (call) a V+ routine
Sequence Button
Create a button that will execute an AIM control sequence
Number
Create a menu item that will access a numeric field or ai.ctl[ ] value
String
Create a menu item that will access a string field or $ai.ctl[ ] value
Digital IO
Create a menu item that will monitor a digital I/O signal
Transform
Create a menu item that will access a transformation field
Date/Time
Create a menu item that will access a Date/Time field
Scrolling Window
Create a new scrolling window
Conditional
Create a new conditional section
Static Text
Create a new static text item
Static Panel
Create a new static panel
Static Icon
Place a static icon on the menu page
Item
Edit Item
Open the editing window for the selected item
Copy Item
Create a copy of the selected item
Delete Item
Delete the selected item
Store Item
Copy and item and store it in memory so it can be pasted multiple times
Paste Item
Paste item copied with previous Store Item option
Fine
Moves
Enable or disable precision moves when positioning menu items
486
Menu Editing Quick Keys
Table A-1 lists the special keys that are active whenever you are in menu editing.
Table A-1
Menu Editing Quick Keys
Key(s)
Action
New (F2)
Create a new menu page
Save (Shift+F2)
Save menu page changes to the hard drive
Go To (F3)
Open the item editing page for the highlighted item
Exit (F4)
Close the current window
Shift+F4
Close all open windows
Display (F5)
Display a pick list of menu items on the current page
Undo (F6)
Undo the most recent changes from the keyboard (only if the
changes have not been entered by pressing Enter or selecting
another menu item)
Redraw (Shift+F6)
Redraw the menu page (forces execution of any menu
activities that occur when a menu page is redrawn)
Copy (F9)
Copy the selected menu item
Cut (Shift+F9)
Delete the selected menu item
Tab
Select the next menu item
Shift+Tab
Select the previous menu item
Drag with right mouse button
Constrain menu item to move in an up/down, left/right
direction
←,→,↑,↓
Move selected menu item in the indicated direction, or size the
menu item
Ctrl+ ←,→,↑,↓
Select menu items in a left/right or up/down direction
487
Appendix B
Disk Files
This appendix lists all the disk files included in the AIM Base system. Information is also provided
on specifying the disk drive(s) to be accessed by the AIM system.
Four file-name extensions are used for program files; and they indicate the type of information in
the files, as described in Table B-1.
Table B-1
Extensions for AIM Program File Names
Extension
File Contents
.V2
V+ programs with all comments included
.SQU
V+ programs with comments removed to reduce the amount of
system memory occupied
.OV2
V+ programs (with all comments included) that are loaded into
memory only when needed for the function they perform
.OVR
V+ programs (with comments removed) that are loaded into
memory only when needed for the function they perform
In some cases, there are .V2 and .SQU files and .OV2 and .OVR files with the same name (for
example, CUSTOM.V2 and CUSTOM.SQU). The programs in such paired files are functionally
identical. The AIM system executes the programs in the .SQU and .OVR files. The corresponding
.V2 program files are provided so system customizers can work with fully commented programs.
The program “a.squeeze” can be used to create a . SQU file from a .V2 file or an .OVR file from an
.OV2 file. That program is contained in the file SQUEEZE.V2 on the standard Adept Utility Disk #1.
Refer to the manual Instructions for Adept Utility Programs for information on how to use the
squeeze program.
Table B-2 lists all the AIM Base V+ program files. These files are distributed on the “System
Software” diskette unless otherwise noted.
Table B-2
AIM V+ Program Files
File Name
Description of Contents
ACCOUNT
.OVR
Overlay for user log-on account routines
ADXCORE
.OVR
Program files for the ADX translator
ADXMENU
.SQU
Squeezed version of the ADX menu files
ADXMENU
.V2
Menu driver routines for the ADX module
489
Appendix B - Disk Files
Table B-2
AIM V+ Program Files (Continued)
File Name
ADXMOD
.OV2
Initialization routines for the ADX module
ADXMOD
.OVR
Squeezed versions of the ADX initialization routines
AIM
.SQU
Top-level routines for the AIM System
BASMOD
.OV2
Initialization routines for the base line AIM system
BASMOD
.OVR
Squeezed versions of the base line initialization routines
BASRES
.SQU
Reserved for future use
BKAIM
.OVR
Overlay file for the backup utility
BKENG
.OVR
Overlay file for the backup utility system files
CNDRUN
.V2
Statement routines for conditional statements
CNDRUN
.SQU
Squeezed versions of the conditional statement routines
CTLRUN
.V2
Statement routines for the sequence control routines
CTLRUN
.SQU
Squeezed versions of the sequence control routines
CUSTOM
.V2
Variables and routines for customizing AIM Base
CUSTOM
.SQU
Squeezed copy of CUSTOM.V2
DBMLIB
.SQU
Database library routines
DBMUTIL
.OVR
Overlay for database utility package
EDIT
.SQU
Routines for editing AIM sequences
EDIT
.OVR
Overlay for AIM sequence editor
ERROR
.SQU
Error message conversion and handling routines
ERROR
.OVR
Overlay for error message conversion and handling routines
ERROR2
.OVR
Overlay for error message conversion and handling routines
EXECTL
.SQU
Low level routines for the sequence control statement routines
EXECUTE
.SQU
Execution control, status functions, and walk-thru training
EXEUSR
.V2
User execution control and status routines
EXEUSR
.SQU
Squeezed copy of EXEUSR.V2
FILEMGR
.OVR
Routines for the file manager utility
INI
.OVR
Routines that support the initialization databases
INIT
.OVR
Overlay containing system initialization routines
IOGBL
.SQU
Routines to handle inter-process communication
IOWIN
.SQU
Input/output routines for the windowing environment
490
Disk Files
Table B-2
AIM V+ Program Files (Continued)
File Name
KEYWORD
.SQU
Routines that support the keyword facility
LBASE
.V2
Command program to load AIM files into memory for
execution
LINK
.SQU
Routines for linking databases before execution
LINK
.OVR
Overlay for linking routines
LOAD
.SQU
Loadable database management routines
LOAD
.OVR
Overlay for loadable database management routines
MENU
.SQU
Menu driver routines
MENU
.OVR
Overlay for the menu driver routines
MENUEDIT
.OVR
Overlay for the interactive menu editor routines
MENURTN
.SQU
System menu spawn routines
MENUUSER
.V2
User menu spawn routines
MENUUSER
.SQU
Squeezed copy of MENUUSER.V2
MODULE
.OVR
Programs that support the resource module facility
MODULE
.SQU
Squeezed copy of MODULE.OVR
PUBLIC
.OV2
Programs that initialize the AIM global data structures
PUBLIC
.OVR
Squeezed copy of PUBLIC.OV2
QUEMAN
.SQU
Routines for data queuing
RUNLIB
.SQU
Library of user-callable runtime subroutines
RUNLIB2
.SQU
Secondary library of user-callable runtime subroutines
RUNUSR
.V2
Top level sequence execution routines
RUNUSR
.SQU
Squeezed version of RUNUSR.V2
STMT
.OVR
Routines that support statement creation and management
TEACH
.SQU
Data teaching routines
TEXT
.OV2
Overlay for text initialization routines
TEXT
.OVR
Squeezed copy of TEXT.OV2
TIFF
.OVR
Overlay file for the window export utility
TREE
.SQU
Tree drawing routines
TSKCOM
.SQU
Inter-task communication routines
VPLUS
.OVR
Routines that support the V+ Developer
491
The file-name extensions used for data files (listed in Table B-4) are described in Table B-3.
Table B-3
Extensions for AIM Data Files
Extension
File Contents
.RFD
Database record definitions
.DB
Database file
.MNU
Menu pages
.HLP
Help information
.DAT
Icon definitions
Table B-4 lists the files associated with the system databases and menus. These files are distributed
on the “System Data” diskette.
Table B-4
AIM Database Files
File Name
ACCOUNTS
.RFD
Users and access levels database field definitions
ACCOUNTS
.DB
Users and access levels database data
ACCOUNTS
.MNU
Users and access levels database menus
ADX
.MNU
Menu pages for the ADX module
ATTACH
.DB
Sequence editor copy buffer
BACKUP
.DB
Database holding the user backup definitions
BACKUP
.RFD
Definition file for the backup database
BACKUP
.MNU
Menu file for the backup/restore utility
BASEINI
.DB
Base system initialization database
BASMOD
.DB
Resource module database
DBMUTIL
.MNU
Database utility menus
EDIT
.MNU
Sequence editor menus
FILEMGR
.MNU
Menu page file for the file manager utility
HELP
.RFD
Help database field definitions
HELP
.MNU
Help database menus
INI
.MNU
Menu page file for the initialization database facility
INI
.RFD
Database field definitions for the initialization databases
LOAD
.MNU
Loadable database management menus
492
Disk Files
Table B-4
AIM Database Files (Continued)
File Name
MENU
.RFD
Menu database field definitions
MENUEDIT
.MNU
Interactive menu editing menus
MODULE
.MNU
Menu page file for the resource module facility
MODULE
.RFD
Database field definitions for the resource module
databases
OPERICON
.DAT
Icons for the operator interface
SAMPLE
.MNU
Sample menu page menus
SAMPLE
.HLP
Sample menu page help information
SEQ
.RFD
Sequence database field definitions
SEQ
.MNU
Sequence database field menus
SETUP
.MNU
Cell setup menus
STAT
.RFD
Statement database field definitions
STAT
.DB
Empty Statement database for baseline
STAT
.MNU
Statement database menus
STATBASE
.DB
Baseline statement definitions
STATCTL
.DB
Sequence control statement definitions
STATUS
.MNU
Execution and status menus for task 3
STATUS2
.MNU
Execution and status menus for task 6
SYSICON
.DAT
Base line system icons
SYSTEM
.MNU
System menus
TIFF
.MNU
Menu page file for the window import/export utility
TREE
.MNU
Tree drawing menus
TWEEK
.MNU
Menu page file for the “Tweek Motions” facility
USERINI
.DB
Initialization database for user error databases
VAR
.DB
Variable database
VAR
.MNU
Menu page file for the Variable database
VAR
.RFD
Database field definitions for the variable database
VPLUS
.MNU
Menu pages for the V+ Developer
493
Table B-5 lists the files associated with the Error Message database. Except for ERROR.DAT, these
files are distributed on the “System Data” diskette. That file is automatically generated during
initialization of the AIM system.
Table B-5
AIM Error Message Database Files
File Name
ERROR
.RFD
Error Message database field definitions
ERROR
.DB
Error Message database data
ERROR
.MNU
Error Message database menus
ERROR
.DAT
Error Message data file (not distributed—generated
automatically at start-up if not present)
The system disk drives are used extensively with AIM. First the basic AIM software is loaded into
memory (with the command program in the file L∗.V2). During start-up and normal execution,
AIM accesses database disk files and files containing various data (for example, vision calibration
data). Also, during normal operation, AIM software “overlays” are read from disk.
The standard AIM system accesses the V+ “default” disk drive for all files. (The default drive is
determined by the V+ system boot disk, and it can be changed with the V+ DEFAULT command.
That command can also be used to set a default subdirectory to access.)
The AIM system can be customized to access other disk drives (and subdirectories). The following
global variable can be used to specify disk drives (and subdirectories) to be accessed by the AIM
system. If the variable contains an empty string (“”), the data disk files are accessed on theV+
default disk (and subdirectory).
$cu.dat.disk
This string variable can be assigned a specification (for example, “A:” or
“C:\DATA\ ”) for the disk drive (and subdirectory) to be accessed for all
“data” files. That is, all files with the name extensions .DAT, .DB, .HLP,
.MNU, .RFD, and .VS.
NOTE: The AIM software overlay files are always read from the V+
default disk. Thus, the V+ DEFAULT command must be used to redirect
that disk activity.
494
Appendix C
AIM Messages
While using the AIM system, it is possible for certain abnormal conditions to occur. For example, if
menu selections or data values are not entered in the correct way, or if some other indiscretion is
attempted, AIM rejects the input. The usual response is to output to the system terminal an
indication of what is wrong so the user can correct the error.
The following section contains all the error messages produced by AIM, explains what they mean,
and indicates what should be done in response. This list also includes a variety of informational
messages that AIM displays under certain circumstances.
Almost every AIM message is assigned a numeric code that can be used to identify the message.
When an error message is logged or transmitted to an external computer, the error code is
normally stored or sent with the message. The error code for each message is shown at the right
margin for all those messages that have a code.
C.1
Alphabetical List
All the AIM messages are described in this section. Each description includes the text of the
message, its error code, an explanation of the probable cause of the message, and a suggestion of
what action you should take.
*A scratch Frame store is needed (use VSELECT)*
–756
Explanation:
VCORRELATE returns this error when performing a grayscale hierarchical
search or binary search and no scratch frame store is available.
User action:
Use VSELECT to invalidate a virtual frame store in a physical frame store
which is different than the physical frame store being searched.
2106
Abort runtime
Explanation:
This selection causes the runtime task to stop execution. The runtime
cannot be continued after it is aborted, but must be restarted from the
beginning.
User action:
None.
–400
Aborted
Explanation:
The last command requested, or the program that was executing, has been
aborted at the operator’s request.
User action:
None.
4001
Accessing:
Explanation:
This is a trace message displayed while in walk-through training. The
system is accessing the feeder shown during an attempt to acquire a part.
User action:
None required.
495
Appendix C - AIM Messages
4000
Acquiring:
Explanation:
system is about to acquire the part shown.
User action:
None required.
Added new conveyor queue object:
4030
Explanation:
This is a trace message, displayed while in walk-through training, which
indicates that the conveyor manager has placed a new object in a queue.
The name of the object and the queue are displayed.
User action:
None required.
*Allocated databases all in use*
–2100
Explanation:
A command was issued to load another loadable database. However, the
maximum number of databases that can be loaded at one time has been
exceeded.
User action:
Use the Load/Unload Utilities to unload an unused database and repeat
the load operation. If you wish to increase the limit on the number of
databases that can be loaded and sufficient memory exists, see your system
specialist about increasing the limits within the CUSTOM file.
*Already attached to logical unit*
–515
Explanation:
A program has executed more than one ATTACH instruction for a specific
logical unit, without executing a DETACH in between. (The program is still
attached to the logical unit after this error occurs.)
User action:
Check the program logic and remove redundant ATTACH instructions.
*Ambiguous AUTO invalid*
–477
Explanation:
When exiting from the program editor, V+ has encountered an automatic
variable with undetermined type. That is, the system cannot determine if
the variable is real-valued or a transformation. Automatic variables cannot
be ambiguous, since their storage requirements must be known before they
are referenced.
User action:
Include the “REAL” or “LOC” type specification parameter in the AUTO
statement that declares the variable, or reference the variable in a program
instruction in a manner that makes its type clear.
–453
*Ambiguous name*
Explanation:
The abbreviation used for the last command, instruction, or systemdefined name was not long enough to identify the operation intended.
User action:
Reenter the last line, using a longer abbreviation.
10
Are you sure (Y/N)?
496
Explanation:
The requested command will have a significant effect on the state of the
system and V+ wants to know if you really want it to happen.
User action:
To have V+ continue, type “Y” followed by a carriage return. An “N”
followed by a carriage return, or just a carriage return, causes the command
to be aborted.
Alphabetical List
–409
*Arithmetic overflow*
Explanation:
The result of a calculation was outside the allowable range for real variables
or V+ has encountered a number that is outside the allowed range for
integers while converting a real-valued number to a decimal, hexadecimal,
or octal integer, or logical value. Logical values use 32-bit integers, but
most program instructions that require integer arguments allow only 16-bit
integers. Also, real variables can have only magnitudes in the range from
about 5.4E–20 to 9.2E+18.
User action:
Modify the program as required.
*Assembly arrival time-out*
–6108
Explanation:
A request has been issued to load a new assembly into the work area.
However, no new assembly has been loaded within the allowed time limit.
User action:
Check if an assembly has actually been loaded. If it has, verify that the
digital I/O signals associated with loading an assembly and detecting a
loaded assembly are functioning properly. Be sure the time limit specified
for loading an assembly is long enough.
*Assembly stop signal still present*
–6111
Explanation:
A request has been made to unload an assembly from the work area.
However, the assembly is still present.
User action:
Check if the assembly is actually unloaded. If it is, verify that the digital
I/O signals associated with unloading an assembly and detecting a loaded
assembly are functioning properly.
4008
Asserting signal:
Explanation:
This is a trace message that announces that a digital I/O signal is being set
or cleared. If the signal number is negative, the signal is being cleared.
User action:
None required.
*Attempt to modify active belt*
–614
Explanation:
A program instruction has been executed that will modify the belt variable
that is currently being tracked by the robot.
User action:
Change the program in order not to modify the variable while the robot is
tracking it.
*Attempt to redefine variable class* variableness
–470
Explanation:
Upon exiting from the editor, the named variable was found in two of the
following places: the.PROGRAM argument list, an AUTO statement, a
LOCAL statement, or a GLOBAL statement.
User action:
Modify the program to include the variable in only one of these places.
*Attempt to redefine variable type* variableness
Explanation:
–469
If a program is being edited, the line just entered contains a reference to a
variable in a manner inconsistent with its use elsewhere in the program.
The most likely problem is confusing a location variable with a real
497
variable. If you just exited from the editor, the named variable conflicts with
a global variable that already exists.
User action:
If the new use of the variable is correct, you must delete all references to the
incorrect variable and then reenter the statement that caused the error. If the
new use is incorrect, use a different variable name. If there is a conflict with
a global variable, either use a DELETE_ command to delete that variable, or
make the conflicting variable AUTO or LOCAL to the current program.
2008
Average cycle time (secs):
Explanation:
This message is displayed after a sequence stops running. It gives the
average time to complete one cycle through the sequence, which is simply
the total running time of the sequence divided by the number of cycles.
User action:
None required.
–2231
*Backup limit exceeded*
Explanation:
One of the limits of the backup operation has been exceeded.
User action:
Divide the backup operation into two or more smaller backup savesets.
–523
*Bad block in disk header*
Explanation:
While formatting a disk, a bad disk block has been found in the disk header
area. The format operation has failed and the disk is not usable.
User action:
Enter the FORMAT command again-use a different diskette if the error
persists.
–726
*Bad camera calibration*
Explanation:
A VPUTCAL instruction has been used to pass vision calibration data to the
AdeptVision system, and one or more of the data elements is not valid.
User action:
Make sure the program reads the calibration data from a valid data file, or
make sure valid values are asserted by the program.
–721
*Bad grip definition*
Explanation:
The DEFGRIP instruction was performed with incorrect parameters.
User action:
Check the DEFGRIP parameter values. The locations specified by the
transformations must not be unreasonably far from the prototype, and the
widths and heights of the grip rectangles must not be unreasonably large.
An “unreasonable” distance is one greater than a couple of image widths.
–2220
*Bad IGES file format*
498
Explanation:
The IGES file that is being converted does not have the proper format. The
file must be in ASCII format with (fixed-length) 80-character lines. The file
must also be compatible with version 3.0 of IGES.
User action:
Check that the IGES Converter on the CAD system is able to create ASCII
files with (fixed-length) 80-character lines that are compatible with version
3.0 of IGES. If there is a choice for the format that the CAD system uses,
change it to match this format. Otherwise, you will have to customize the
IGES Converter supplied with the CAD Data Translator to support your
format.
Alphabetical List
–2300
*Belt did not move*
Explanation:
The conveyor belt did not move when expected. For example, during belt
calibration the belt must move for the scale factor to be determined.
User action:
Follow instructions to move the belt at the proper time. Check to make sure
that the belt encoder is functioning properly.
–615
*Belt not enabled*
Explanation:
A robot operation that references a moving conveyor belt has been
attempted when the conveyor tracking feature is disabled.
User action:
Enter an ENABLE BELT command and retry the operation.
–617
*Belt servo dead*
Explanation:
The belt processor isn’t responding to commands from V+.
User action:
After saving the programs, power down the controller and power it up
again. If this error occurs repeatedly, contact Adept Field Service.
–616
*Belt window violation*
Explanation:
Either a robot motion has been planned that will move the robot outside of
the belt window, or the robot has moved outside of the belt window while
tracking the belt.
User action:
Modify the program so that the robot will not move outside the belt
window. Consult the BELT.MODE parameter and the WINDOW
instruction for different ways to define the belt window.
*Branch to undefined label* Step NNE
–412
Explanation:
A program instruction references a program label that is not defined in the
program. Either the label is missing or was mistyped when defined or in the
reference.
User action:
Check the label definition and reference.
17
Breakpoint at (task) program_name, step n
Explanation:
A breakpoint was encountered before the indicated step. (Any output
associated with the breakpoint is displayed after the message shown
above.)
User action:
Enter a PROCEED (Ctrl+P), RETRY, SSTEP (Ctrl+Z), or XSTEP (Ctrl+X)
command to resume program execution. Otherwise, enter any other
monitor command.
*Breakpoint not allowed here*
–380
Explanation:
An attempt has been made to set a breakpoint before the first executable
statement of a program.
User action:
Enter a new BPT command specifying a step after the first executable
statement. That is, after the .PROGRAM statement, any AUTO and LOCAL
statements, and all comments and blank lines at the start of the program.
499
–425
*Calibration program not loaded*
Explanation:
An attempt has been made to calibrate the robot when the calibration
program is not loaded into memory. Normally this program loading is
automatic.
User action:
After saving any programs, issue the ZERO command to clear your V+
system memory and retry the operation. Verify that any custom
calibration procedures are functioning properly.
*Calibration sensor failure* Mtr n
Explanation:
During calibration, the calibration sensor for the indicated motor could not
be read correctly. Either the robot is blocked from moving, or a hardware
error has occurred.
User action:
Retry the CALIBRATE command or instruction after making sure that the
robot is not blocked. If the problem persists, contact Adept Field Service.
–719
*Camera already off*
Explanation:
A VPICTURE operation to turn the camera off has been processed when the
camera is already off (line vision only).
User action:
Modify the program to remove redundant VPICTURE OFF instructions.
*Camera already running*
–714
Explanation:
A VPICTURE operation to turn the camera on has been processed when the
camera is already running (line vision only).
User action:
Modify the program to remove redundant VPICTURE ON instructions, or
insert a VPICTURE OFF instruction.
–710
*Camera disconnected*
Explanation:
The vision interface hardware indicates that the camera is not connected.
User action:
Check the camera and cabling to make sure it is connected properly. If the
problem persists, consult your vision system manual.
*Camera interface board absent*
–722
Explanation:
The vision interface board is not responding to a command from the vision
system.
User action:
Make sure that the vision interface board is installed properly. After saving
all the programs and prototypes in memory, power down the controller
and power it up again. Consult Adept Field Service if the problem persists.
*Camera mixup with proto-finder*
500
–1106
–6207
Explanation:
The virtual camera associated with the proto-finder is not associated with
the prototype in the vision system.
User action:
Enter prototype training and assign the proper camera to the prototype, or
change the camera associated with the proto-finder record (via its picture
source).
Alphabetical List
–705
*Camera not running*
Explanation:
An attempt has been made to process a vision system operation when the
camera is not running (line vision only).
User action:
Enter a VPICTURE ON command and retry the vision operation that failed.
*Cameras must be the same*
–6221
Explanation:
The current vision operation requires that the camera records referenced by
the picture-class sources must be the same.
User action:
Edit the vision operation picture-class sources so that they reference the
same camera record.
–358
*Cancelled*
Explanation:
An editor, debugger, or pendant operation has been terminated due to
operator intervention.
User action:
This is usually an informative message to acknowledge the cancellation of
the operation.
*Cannot shutdown. Backup/Restore still active*
–2226
Explanation:
The AIM system cannot be shutdown when a backup or restore operation is
active.
User action:
Either wait until the current operation has completed, or abort the
operation by selecting either Backup or Restore in the Utilities menu, and
then select the Abort button on the status display.
*Can’t access protected or read-only program*
–310
Explanation:
An attempt has been made to edit a protected or read-only program. These
programs cannot be edited.
User action:
None.
*Can’t ALTER and track belt*
–626
Explanation:
Either a belt-relative motion was specified while ALTER mode was
enabled, or an attempt was made to enable ALTER mode while the selected
robot was tracking a belt. Both operations are prohibited because belttracking and ALTER mode cannot be performed at the same time.
User action:
Either disable ALTER mode or stop tracking the belt.
*Can’t change active vision db*
–6213
Explanation:
While it is possible to access different loadable vision databases
simultaneously, only one vision database can be the “active” vision
database. When a vision database is being executed by the runtime or being
edited, it must be the active vision database. This error occurs if an
operation requires that the active vision database be changed, but the
currently active vision database is already being accessed by the runtime or
is being edited.
User action:
If you wish to execute your operation, terminate sequence execution or
editing of the vision database and reissue the command that generated the
error.
501
*Can’t change modes while task running*
Explanation:
A command was issued to change from debug monitor mode to debug
editor mode while the program task being debugged was executing. You
can change to debug editor mode only when the associated task is stopped.
User action:
Stop execution of the program task being debugged, or continue without
using debug editor mode.
*Can’t create new slide bar*
–557
Explanation:
An attempt has been made to create a graphic slide bar in the horizontal or
vertical scroll bar. Slide bars should be created only in the main window,
although they can appear in the title or menu bars.
User action:
Modify the arguments for the GSLIDE instruction to have the slide bar
created within the window.
*Can’t create program in read-only mode*
–364
Explanation:
An attempt has been made to initiate editing of a program in read-only
access mode, but the program does not exist.
User action:
If the program name was entered incorrectly, enter the command again
with the correct name. Do not select read-only access (with “/R”) when
creating a new program.
*Can’t delete .PROGRAM statement*
–350
Explanation:
An attempt has been made to delete the .PROGRAM statement while
editing a program.
User action:
To change the .PROGRAM statement, replace it with another .PROGRAM
statement. To delete lines at the beginning of the program, move down to
line 2 before issuing delete commands.
*Can’t execute from SEE program instruction*
–362
Explanation:
An attempt has been made to use a SEE editor command that cannot be
used after the editor has been initiated with the SEE program instruction.
User action:
Enter another command or exit the editor and reenter from the V+ monitor.
*Can’t exit while lines attached*
–355
Explanation:
You attempted to terminate execution of the editor while lines were present
in the attach buffer. The attach buffer must be empty before the editor can
be exited.
User action:
You can use Shift+Copy to deposit the contents of the attach buffer into the
current program. You can also use “Esc K” to delete lines from the attach
buffer (“99 Esc K” will delete up to 99 lines from the buffer).
*Can’t find calibration program file*
Explanation:
502
–361
–426
An attempt has been made to load the robot calibration program from disk
but the program cannot be found. The calibration program file is named
“cal_util.v2”. The loading operation searches the following disk
directories, in order: 1) the default directory, 2) \calib\ on the boot disk,
and 3) c:\calib\.
Alphabetical List
User action:
Check that the calibration program is found in one of these three areas. If it
is not, restore it from your system distribution disks or from a backup disk.
Contact Adept Field Service for a replacement.
–6050
*Can’t find fiducial*:
Explanation:
A statement has been executed that was to locate a fiducial mark to
determine a board or assembly location. However, the expected fiducial
could not be identified.
User action:
Examine the board or assembly to ensure that the fiducial is present and
positioned correctly. If so, adjust the vision or other sensor utilized to detect
the fiducial. For the vision system, this adjustment usually requires that the
threshold be reset or the fiducial prototype be refined.
*Can’t find specified menu page*
–2127
Explanation:
The menu driver was unable to locate the specified menu page in the
designated Menu database file.
User action:
Examine the menu page specification and verify that the menu page and
menu file are specified correctly. If they are, examine the Menu database
and verify that the menu page exists. Correct any problems that are
discovered.
*Can’t generate error popup*
–2128
Explanation:
An error needs to be displayed in the standard error popup window, but
the menu page for the error display could not be found.
User action:
Most likely, the main database that contains the menu pages for the system
has been deleted, moved or corrupted. Examine the disk directory and
verify that the main Menu database (AIM.MNU) is present. If not, copy
this file to the required directory. If the file is present, replace it with a new
copy from a backup diskette.
*Can’t go on, use EXECUTE or PRIME*
–313
Explanation:
An attempt has been made to continue the execution of a program that has
completed or stopped because of a HALT instruction. Normally, an error
results when a PROCEED, RETRY, or XSTEP command is entered (or the
pendant RUN/HOLD button is pressed) after a program has completed all
its cycles.
User action:
Use the EXECUTE or PRIME command, or the pendant PRIME function, to
restart the program from the desired instruction.
–450
*Can’t interpret line*
Explanation:
The last command or instruction entered could not be interpreted by V+ .
User action:
Check the spelling and usage and reenter the line. In the case of an error
while loading from the disk, edit the affected programs to correct the
indicated lines-they will have been converted to bad lines.
503
–414
*Can’t mix MC & program instructions*
Explanation:
A program instruction has been encountered during processing of a
command program, or an MC instruction has been encountered in a normal
program.
User action:
Edit the command program to use the DO command to include the
program instruction, or remove the MC instruction from the normal
program.
*Can’t open menu record* menu, db, record, error:
–2133
Explanation:
An error occurred when the menu driver attempted to read a record from a
menu (.MNU) file. This error, which is not expected to occur in a properly
functioning controller, indicates that either a hardware failure has occurred
or a system error has been encountered.
User action:
Examine the trailing error message and determine if a hardware error has
occurred. If so, follow the corrective procedures for the hardware fault. If
not, report the system error to Adept Application Engineering.
–734
*Can’t open vision window for read/write*
Explanation:
An attempt has been made to open the vision window in read/write mode,
but the vision system is performing some critical processing that precludes
it from releasing the window.
User action:
Change the program to have it try the FOPEN again later; or specify /
WRITEONLY if no reading will be performed.
–2126
*Can’t open window*
Explanation:
The system was unable to open a new window as requested. Most likely,
either the window specification called for too large a window to be created,
or too many windows have already been created and not enough memory
space or window descriptors are available.
User action:
Examine the window specification and verify that the window size specification is reasonable. If the size is correct, use the V+ FREE monitor
command to determine if enough window descriptors and graphics
memory space are available. If there are not enough window descriptors,
reconfigure the system with more window descriptors. If not enough
graphics memory is available, restructure your application to use fewer or
smaller windows.
*Can’t start while program running*
Explanation:
An attempt has been made to start execution of a program from the manual
control pendant while a program is already executing as task #0.
User action:
Stop the program currently executing and then retry the operation.
*Can’t unload database being edited*
Explanation:
504
–312
–2122
An attempt was made to unload a loadable database (e.g. a Sequence or
Assembly) while the database was being edited. Normally, this will
condition will only occur when a task is automatically loading and
unloading databases and the operator interface is simultaneously utilized
to access the databases.
Alphabetical List
User action:
While an independent task is responsible for loading and unloading
databases, avoid using the operator interface to access the same databases.
*Can’t unload executing database*
–2114
Explanation:
A command was issued to unload the Sequence or Assembly database that
is either running or primed to run. Note that even if sequence execution has
been paused, the referenced Sequence and Assembly databases cannot be
unloaded unless execution is completed or aborted.
User action:
Either wait until the current sequence completes execution before
attempting to unload the database, or go to the status menu page to
terminate and abort execution.
*Cartesian control of robot not possible*
–635
Explanation:
A program has attempted to move the robot to a Cartesian location
(specified by a location transformation) or to move the robot in a straight
line trajectory, when the robot kinematic module does not support such
motions. For example, the “Joints” kinematic module does not allow such
motions.
User action:
Make sure your program has selected the proper robot. Make sure the
proper kinematic module is installed on your boot disk. Edit your
program to not move to Cartesian locations or use straight line motions.
11
Change?
Explanation:
You are being given an opportunity to modify the location value just
created by a HERE or POINT command.
User action:
Enter any desired new components, separated by commas; or press the
Return key to indicate that no changes are desired.
4003
Changing tool to:
Explanation:
current part type is associated with the tool shown, which is different from
the current tool. The new tool will now be used.
User action:
None required.
–742
*Character not in font*
Explanation:
In a string of characters to be recognized by, or trained for, optical character
recognition (OCR), one or more characters are not in the current font
definition.
User action:
Redefine the font to include the missing character(s).
2054
Choice already used
Explanation:
The specified choice in the backup saveset specification is already being
used by a different backup specification.
User action:
Either cancel the operation of setting the choice, or displace the existing
choice.
505
*Circular linking relationship illegal*
Explanation:
In analyzing the linking rules defined for the fixed databases, a series of
rules result in a linking sequence that circles back to a previous database in
the linking sequence. Circular relationships of this type are not allowed.
User action:
Redefine the linking rules so that no circular linking relationships exist.
*Communication time-out*
–531
Explanation:
An I/O operation has not completed within the allotted time interval. For
data communications, the remote communications device has not properly
acknowledged data that was sent.
User action:
Make sure the remote device is communicating. Make sure connections to
the remote device are operating properly.
*Communications overrun*
–524
Explanation:
Data has been received on an I/O device faster than V+ is processing it, and
some data has been lost. This will happen only on the serial interface line
or the network.
User action:
Modify the program to service the I/O device more often, add a
handshaking protocol, or slow down the transmission rate to V+.
–603
*COMP mode disabled*
Explanation:
The command attempted requires computer control of the robot, but
COMPUTER mode was not selected on the pendant.
User action:
Select COMP mode on the pendant or enable DRY.RUN mode from the
terminal, then reissue the command.
2003
Completed assembly:
Explanation:
An assembly sequence has just been completed. The name of the assembly
is shown.
User action:
None required—this is an informative message.
2010
Completed sequence:
Explanation:
An AIM sequence has been completed.
User action:
*Conditional statements nested too deeply*
–2120
Explanation:
Conditional sequence statements can only be nested to finite depth.
sequence being linked exceeds this depth. EXIT_LOOP and NEXT_LOOP
statements also contribute to nesting depth.
User action:
Edit the sequence to reduce the depth of nested conditional statements.
*Control structure error* Step step_number
Explanation:
506
–2112
V+ has detected an incomplete or inconsistent control structure at the
specified step when exiting the program editor, loading a program, or
processing a BPT command.
–472
Alphabetical List
User action:
Edit the program to correct the control structure. The actual error may not
be at the indicated step.
–473
*Control structure error* Step nnn
Explanation:
An incomplete control structure has been encountered during program
execution.
User action:
Edit the program to correct the control structure.
–631
*Controller overheating*
Explanation:
The temperature sensor in the controller power supply has detected an
overheating condition. Robot power is switched off.
User action:
Make sure the controller fans are operation and are not obstructed. Make
sure the fan filters are clean. Power-down the controller to let it cool off.
–6019
*Conveyor not initialized*
Explanation:
A conveyor-relative reference frame has been accessed when the conveyor
server is not active.
User action:
Stop the robot tasks and conveyor server task. Make sure you start the
conveyor server before starting the robot tasks which use it.
*Coplanarity calculation failure*
–6550
Explanation:
No stable resting plane was found for the leads on the part currently being
inspected.
User action:
If several pictures of the part were taken to gather the lead information,
verify that they were taken in the correct order (that is, moving clockwise
around the part as seen by the camera).
*Correlation template too big*
Explanation:
A vision correlation template has been defined that is too large.
User action:
Redefine a smaller template
–754
–2003
*D.b. file not found*
Explanation:
No file with the given name was found when attempting to open a database. Either the name was mistyped or the wrong diskette is being read.
User action:
Enter the correct file name or access the correct disk.
–2009
*D.b. is read-only*
Explanation:
An attempt was made to modify a database that was opened in read-only
mode. Memory-resident databases may be opened so that any attempt to
modify a field causes this error; or so that changes to the values in memory
are allowed, but any attempt to store the modifications out to the database
file on disk causes an error.
User action:
Either do not attempt to make changes to the database, or reopen the
database in read-write mode.
507
*D.b. is the currently selected d.b.*
Explanation:
When prompted for a database name, the operator has provided the name
of the database that is already being displayed by the Database Utility.
However, the Database Utility function invoked requires that the database
specified be different than the one currently displayed.
User action:
Reference the manual for the Database Utility and review the requirements for the desired function. Reexecute the function and provide the
proper database file name.
*D.b. must be a module member*
–2149
Explanation:
An attempt has been made to reference a resource module database from a
global database. For example, a retrieve has been attempted from a frame
module member to a global path database. Such references are not allowed.
User action:
Import the global database to your resource module so that both databases
are in the module, or delete the resource module database so that both
databases are global.
*D.b. must be empty to change definition*
–2050
Explanation:
An attempt was made to change the definition of a record field description
for a database that contains allocated records. The operation was not
permitted because the change would have required that all the database
records be reformatted and data could have been lost. This type of change is
allowed only for empty databases (that is, typically an “.RFD” file).
User action:
If you really desire to make the change, edit the “.RFD” file for the database
and then run the database conversion option within the Database Utility to
convert the database to the new format.
*D.b. name already in use*
–2117
Explanation:
An ADX command has been issued to create a new Sequence or Assembly
database. However, the name of the new database corresponds to the name
of a database that already exists. Sequence and Assembly database names
must be unique.
User action:
Select a new database name (or delete the existing database) and reenter the
command.
*D.b. not memory resident*
–2008
Explanation:
A library routine attempted to reference a database that had been opened as
disk resident.
User action:
When opening the database specify that it should be memory resident.
–2002
*D.b. not open*
508
–2053
Explanation:
An attempt was made to reference a database that had not been opened.
User action:
The database needs to be opened or created before any references to it are
made.
Alphabetical List
*D.b. number already in use*
–2006
Explanation:
An attempt was made to open or create a new database using the number of
a database that is already in use. Only one database may be associated with
a given database number at any one time.
User action:
Either close the other database first, or open the new database with a
different database number.
*D.b. numeric value not in range*
–2014
Explanation:
An attempt was made to store a number in a byte field that was not in the
range 0 to 254, or in an integer field outside the range –32,767 to 32,767.
(Note that for byte fields, the value 255 is used to indicate “no valid data in
field”.)
User action:
Only values in the correct range can be stored. If larger values must be
stored, the field needs to be changed from byte to integer, or integer to real,
and the database converted.
*D.b. search failed to find match*
–2021
Explanation:
A search of the database failed to find any record with the specified value
for the indicated field. Possibly the search was not started from the first
record in the database, or was too constrained. For example, searching for
an exact match of a real number is apt to fail—a small tolerance value
(0.0001) should be used.
User action:
Change the search goal, starting record, or tolerance.
–510
*Data checksum error*
Explanation:
An error was detected while transferring information to or from an
external device.
User action:
Attempt the transfer again. If the problem persists, contact Adept Field
Service.
–522
*Data error on device*
Explanation:
An error was detected while attempting to read information from an
external device, possibly because a diskette has been damaged or was not
formatted properly.
User action:
Attempt the read again. Make sure the correct diskette is being used, that it
is properly installed in the drive, and that it is formatted. (Recall that
formatting a diskette erases its contents.)
*Data overflow*
–755
Explanation:
The binary correlation hardware has found more matches within the search
area than it can process.
User action:
Search a smaller area or redefine your binary template so that it contains
more distinguishing features.
Database file not up-to-date
Explanation:
–2280
The requested file operation cannot be performed on a database file
because the data in the file is not consistent with the database in memory.
509
For example, a module component file cannot be exported unless it
accurately reflects the data in the database.
User action:
Choose the “Save All DBs” pull-down to save all database data back to the
proper database files, and then try the operation again. Pause any runtime
tasks which may be writing and thus modifying the database.
–2279
*Database file open*
Explanation:
The requested operation cannot be performed because a database file is
open. For example, a module component cannot be deleted when the
database associated with the file is open.
User action:
Stop an runtime tasks which may be using the database. Use the module
utility to deselect the module which contains the indicated file.
*Database manager internal error*
Explanation:
This error indicates that a database instruction has encountered an
inconsistency.
User action:
Contact Adept Application Engineering. Please record the details of exactly
what you were doing at the time the error occurred.
*Data-logging not enabled*
–6214
Explanation:
A vision operation or statement in the sequence about to be run requires
that data-logging be enabled, but it is not. For example, the OCR_OUTPUT
statement in VisionWare, can only output strings to the disk file or serial
line set up for data-logging. The sequence can still execute, but data will not
be logged.
User action:
Enable data-logging.
Deadlocked with other robot
–4010
Explanation:
In a two-robot cell, the current robot has detected a deadlock condition.
The current robot is waiting for the other robot to perform some action and
has detected that the other robot has stopped.
User action:
Check that both robots have properly moved out of any shared workspace
and that workstations are empty or full as indicated by the status display.
Enter PROCEED to continue if the deadlock is cleared. Otherwise issue the
appropriate commands to the robots to retry or restart operation.
Defined optional value—proceed or edit:
–4008
Explanation:
During walk-through training, an editable optional data value that already
has a value has been encountered. The runtime has paused to give you a
chance to modify or delete this value. The name of the data field is shown.
User action:
Press the “Edit” button to edit the named data field, or press the “Proceed”
button to continue with the AIM runtime.
Defined value—proceed or edit:
Explanation:
510
–859
–4006
During walk-through training, an editable required data value that already
has a value has been encountered. The runtime has paused to give you a
chance to modify this value. The name of the data field is shown.
Alphabetical List
User action:
Press the “Edit” button to edit the named data field, or press the “Proceed”
button to continue with the AIM runtime.
–660
*Device error*
Explanation:
An error was detected for an external device such as one specified in the
last DEVICE or SETDEVICE program instruction. The actual error
depends upon the type of device referenced.
User action:
Check the instruction to make sure the parameters are valid. Refer to the
documentation for the device type referenced for information on how to
determine what has caused the error.
–503
*Device full*
Explanation:
There is no more space available on a device. If received for a disk file, the
disk is full (if there are many small files on the device, this error indicates
the disk directory is full). If received for a servo device, an attempt has been
made to assign too many servo axes to a single CPU.
User action:
Delete unneeded disk files, or use another drive or diskette. Reconfigure
your system so the maximum number of axes per CPU is not exceeded.
–658
*Device hardware not present*
Explanation:
An attempt has been made to reference a device that is not present in your
system.
User action:
Check that the device were correctly specified. Check that the device
hardware is present and is configured properly.
–668
*Device in use*
Explanation:
An attempt has been made to attach, assign, or configure a hardware device
(e.g., a VMI axis) which is already being used.
User action:
Check the program code to make sure the requested device has not already
been attached.
–6018
*Device mismatch*
Explanation:
Robot database record can be assigned to a particular robot device. An
attempt has been make to access such an item by a task which is
controlling a different robot device.
User action:
Verify that the proper database record is being accessed. Modify the device
assignment for the database record. If you do not want the robot device to
be checked, set the device assignment to “any device”.
–508
*Device not ready*
Explanation:
1. The requested disk device, or remote network task is not prepared to
communicate with the V+ system. 2. A limited-access device like the
terminal, the manual control pendant, or a serial line is attached to a
different program task. 3. You have tried to write into a pull-down window
while it is displayed.
User action:
1. If the intended device is a floppy disk, make sure the diskette is correctly
inserted and formatted. 2. If a limited-access device is specified, ABORT
and KILL the program task that has it attached, or wait for the program task
511
to release the device. If the intended device is on the network, check that the
proper connections are made and that the remote system is operating
correctly. 3. The pull-down menu should not be modified with the FSET
instruction while it is being displayed.
–663
*Device reset*
Explanation:
The device is busy processing a reset operation. The reset could have been
requested (with a SETDEVICE instruction) by another program task that is
accessing the device, or the device could have initiated the reset on its own.
User action:
Use software interlocks to prevent a second program task from accessing
the device after a reset operation has been requested. (Note that the
requesting SETDEVICE instruction will wait for the reset to complete.)
Refer to the documentation for the specific device for information on its
self-generated resets.
–662
*Device sensor error*
Explanation:
A hardware error occurred in the sensing system accessed with the last
DEVICE instruction.
User action:
Refer to the documentation for the sensing system for information on how
to determine the cause of the error.
–659
*Device time-out*
Explanation:
The device has not responded within the expected time.
User action:
Check the documentation for the device type referenced for how to
determine what has caused the error. Check that the device hardware is
configured properly.
–509
*Directory error*
Explanation:
An error occurred while accessing a disk directory, possibly because the
diskette was not formatted or the diskette has been damaged in some way.
User action:
Make sure the correct diskette is being used, that it is properly installed in
the drive, and that it is formatted. (Recall that formatting a diskette erases
its contents.)
–302
*DO not primed*
Explanation:
A DO command was attempted without specifying a program instruction
to be executed and no previous DO had been entered.
User action:
Provide the desired instruction with the DO command.
Done with conveyor queue object:
Explanation:
indicates that a robot task is done using an object in the conveyor queue.
The name of the object and the queue are displayed.
User action:
None required.
*Driver internal consistency error*
Explanation:
512
4032
An I/O device or servo has responded in an unexpected manner.
–519
Alphabetical List
User action:
Retry the operation that caused the error. If it persists, contact Adept Field
Service.
–468
*Duplicate .PROGRAM arguments*
Explanation:
At least two of the arguments in a .PROGRAM statement have the same
name.
User action:
Edit the .PROGRAM line so all the arguments have unique names. (With
the V+ SEE editor, you can press the Undo function key or enter the
command Esc Ctrl+C to cancel the changes you have made to a
.PROGRAM line.)
–740
*Duplicate character in font*
Explanation:
A character appears more than once in the string that defines a font for
optical character recognition (OCR).
User action:
Delete all but one occurrence of each character in the string of characters
being defined.
–2281
*Duplicate database type*
Explanation:
An attempt has been made to define the same database type more than
once.
User action:
Change the database type definitions so that each type is defined only once.
Database types are defined by the routine “ai.db.define”.
*Duplicate field name specified*
–2052
Explanation:
While editing a database record field definition, the operator has specified a
field name that is already in use. Field names must be unique within each
database.
User action:
Select a field name that is not in use.
*Duplicate prototype name*
–718
Explanation:
The file specified in the current VLOAD command contains a prototype
with the same name as one that already exits.
User action:
VDELETE the conflicting prototype that already exits. As a precaution, save
the exiting prototypes first with a VSTORE command.
*Duplicate sort field specified*
–2051
Explanation:
While editing a database record field definition, the operator has specified a
sort order number that is already in use by another field. The sort order
numbers can range from 1 to 254, and they must be unique. (As a special
case, sort order 1 can be specified as –1 to indicate that there cannot be
multiple records with the same value in the primary sort-order field.)
User action:
Select a new sort-order number that is not in use.
*Duplicate statement label*
Explanation:
The same program statement label is used more than once in a user
program.
User action:
Change one of the duplicate labels.
–464
513
*Duty-cycle exceeded* Mtr n
Explanation:
The indicated motor has been driven fast for too long a period of time. The
servo system has disabled Arm Power to protect the robot hardware.
User action:
Turn on Arm Power; reduce the speed and/or acceleration for the motion
that was in progress, or for motions that preceded that motion; and repeat
the motion that failed.
–6208
Edge of square not found
Explanation:
While performing the quick calibration in VisionWare, one or more sides of
the calibration square were not found using line finders. Calibration was
aborted.
User action:
Click on the “Show edges” button on the calibration popup and adjust the
edge strength so that all the edges of the square are visible. Also, make sure
the light/dark color selection is correct.
2005
Empty:
Explanation:
The last part has been removed from a feeder. The feeder has been disabled
and will not be accessed again until enabled by the operator or a hardware
control program. The feeder name is shown.
User action:
None required—this is an informative message. However, if the feeder is
manually loaded, reload it and reenable it via the feeder control panel so
that it can be used in the future.
–1025
*Encoder fault*
Explanation:
The V+ system has detected that a wire from an encoder has been broken,
and robot power has been turned off.
User action:
For non-Adept robots, check the encoder wiring. For Adept robots, contact
Adept field service.
*Encoder quadrature error* Belt n
–1013
Explanation:
The position encoder signal from the specified conveyor belt is sending
information that is not phased correctly. The encoder or its cabling may be
defective. (Encoder error checking is initiated by the DEFBELT instruction,
and by enabling the BELT switch while a belt is defined.)
User action:
Make sure the encoder cable is properly connected. Try to run the
conveyor at a slower speed. Contact Adept Field Service if the error
persists.
*Encoder quadrature error* Mtr n
514
–1021
–1008
Explanation:
The position encoder signal from the specified motor is sending
information that is not phased correctly. The encoder or its cabling may be
defective.
User action:
Turn on Robot Power and try to perform the motion at a slower speed. If
the error persists, contact Adept Field Service.
Alphabetical List
–1006
*Envelope error* Mtr n
Explanation:
The indicated motor was not tracking the commanded position with
sufficient accuracy, indicating a failure in the hardware servo system or
something impeding the path of the robot.
User action:
Turn on Robot Power and try to perform the motion at a slower speed.
Make sure nothing is obstructing the robot motion. If the error recurs,
contact Adept Field Service.
–641
*E-STOP from amplifier*
Explanation:
The motion interface board has detected an E-STOP condition generated by
the motor amplifiers. It indicates that the amplifiers have detected some
fault condition.
User action:
Check for a subsequent message or type listr error(task,4), where task is the
number of the task that received the error. If no additional information is
available, check that the amplifiers are plugged into the backplane correctly,
the fixing screws are tightened, and the motor and signal cables are
connected correctly.
–643
*E-STOP from backplane*
Explanation:
The motion interface board has detected an E-STOP due to the BRAKEESTOP signal being asserted on the VME bus. The error message *Motion
interface E-STOP* (–630) should normally be seen instead of this error. If
that error is seen, it indicates a transient BRAKE-ESTOP signal or a problem
with either the motion interface board or the SIO module.
User action:
available, call Adept Customer Service.
–640
*E-STOP from robot*
Explanation:
The motion interface board has detected an E-STOP condition generated by
the RSC in the robot. This error is probably due to low air pressure, joint-1
overtravel, or motor overheating. A subsequent error message may provide
more information. The function ERROR(task,4) should be used to provide
more information, if available.
User action:
available, check for low air pressure, joint 1 overtravel, or motor
overheating.
–642
*E-STOP from SYSFAIL*
Explanation:
The motion interface board has detected an E-STOP due to the SYSFAIL
signal being asserted on the VME bus. The error *SYSFAIL asserted* (−629)
should normally be seen instead of this error. If that error is seen, it
indicates a transient SYSFAIL signal or a problem with either the motion
interface board or the SIO module.
User action:
available, call Adept Customer Service.
515
50
Executing in DRY.RUN mode
Explanation:
The DRY.RUN switch is enabled and program execution has been
requested. Thus, no motion of the robot will occur.
User action:
None unless motion of the robot is desired. In that case, abort execution of
the program and disable the DRY.RUN switch.
2000
Execution started
Explanation:
The AIM runtime system has been started.
User action:
2001
Execution stopped
Explanation:
The AIM runtime system has stopped, either because all cycles have been
completed, or because the operator issued an “abort” request.
User action:
–745
*Expected character(s) not found*
Explanation:
While training characters for subsequent optical character recognition
(OCR), the number of characters in the given string did not correspond to
the number of characters found in the training window. Character training
has been aborted.
User action:
Make sure the given string matches the characters in the training window.
*Expected part not present*
Explanation:
A part-present sensor indicates that a part is not present in a situation
where the robot gripper should be holding a part.
User action:
Retry the previous action or statement to properly acquire a part. Manually
place a part in the gripper. Verify that the part-present sensor is operating
properly. Verify that the proper signal is being used for the part-present
sensor.
*External control panel enabled*
–2255
Explanation:
An operation has been attempted on the operator control panel window
which is not allowed because the external control panel feature is enabled.
User action:
Use the external control panel connected to the system, or pull-down the
“Execute/External Control Panel” menu item to disable the external control
panel.
–608
*External E-STOP*
516
–6073
Explanation:
The hardware panic button on the controller or pendant has been pressed,
or the external panic circuit has been interrupted, causing Robot Power to
be turned off. This message is also displayed if the MANUAL button is
pressed or the PANIC command is entered while a robot control program is
executing.
User action:
If Robot Power is off, release the panic button or restore the external panic
circuit. Then turn on Robot Power. If Robot Power is not off, reselect COMP
mode on the manual control pendant. Then resume program execution.
Alphabetical List
*[Fatal] Initialization failure* Mtr n
–1014
Explanation:
During initialization of a robot kinematic module, the indicated motor
failed initialization. The problem may be a missing or improperly
configured servo interface board, or an incorrect motor mapping for this
module.
User action:
Verify that all servo interface boards are correctly installed and configured
(use the SPEC.V2 utility for motor mapping). If the problem persists,
*[Fatal] Servo checksum error* CPU n
–1103
Explanation:
During initialization, V+ detected a memory error in the servo process on
the indicated CPU. V+ will continue to operate, but will not allow Robot
Power to be turned on.
User action:
Power down the controller and restart. If the problem persists, contact
Adept Field Service.
*[Fatal] Servo code incompatible* CPU n
–1102
Explanation:
During initialization, V+ detected an improper version of servo software on
the indicated CPU. V+ will continue to operate, but will not allow Robot
Power to be turned on.
User action:
–1104
*[Fatal] Servo dead* Mtr n
Explanation:
The servo process for the indicated motor is not responding to commands
from V+. V+ will continue to operate, but will not allow Robot Power to be
turned on.
User action:
*[Fatal] Servo init failure* Board n
–1107
Explanation:
During system initialization the indicated servo interface board could not
be initialized. The problem may be an invalid servo configuration, a
missing or improperly configured servo interface board, or a hardware
failure.
User action:
Power down the controller and restart, making sure you are using the
correct system disk. If the problem persists, contact Adept Field Service.
*[Fatal] Servo process dead* CPU n
–1101
Explanation:
V+ failed to detect proper operation of the servo process on the indicated
CPU. V+ will continue to operate, but will not allow Robot Power to be
turned on.
User action:
Power down the controller and restart. Use the CONFIG_C.V2 utility to
verify that a servo process is enabled for this CPU. If the problem persists,
517
–6502
*FIB command error*
Explanation:
The Force Interface Board has received an invalid command from the Force
Processor Board.
User action:
Execute the “fs.setd.reset” SETDEVICE instruction to reset the force system,
and then proceed. Call Adept Field Service if the problem persists.
–6516
*FIB command timeout*
Explanation:
The Force Interface Board did not respond to a command from the Force
Processor Board within the timeout period.
User action:
–6515
*FIB data timeout*
Explanation:
The Force Interface Board did not return force data to the Force Processor
Board within the timeout period.
User action:
–6501
*FIB internal error*
Explanation:
The Force Interface Board experienced an internal error.
User action:
–6504
*FIB NV memory error*
Explanation:
A Force Interface Board memory failure occurred.
User action:
–6505
*FIB reset occurred*
Explanation:
The Force Interface Board sensed a hardware reset signal, possibly due to
system noise.
User action:
*FIB ribbon cable disconnected*
Explanation:
The Force Interface Board appears to be disconnected from the Force
Processor Board.
User action:
Reseat the 50-pin ribbon cable between the two boards. Execute the
“fs.setd.reset” SETDEVICE instruction to reset the force system, and then
proceed. Call Adept Field Service if the problem persists.
*FIB voltage supply failure*
518
–6500
–6503
Explanation:
The Force Interface Board (FIB) has detected a voltage supply out of the
design range.
User action:
Check continuity and voltage levels at fuses F1, F2 and F3 on the FIB. The
voltage levels at the three fuses should be +12, +5 and –12 volts DC,
Alphabetical List
respectively. Turn off the system before replacing any failed fuses. Execute
the “fs.setd.reset” SETDEVICE instruction to reset the force system, and
then proceed. Call Adept Field Service if the problem persists.
–500
*File already exists*
Explanation:
There is already a disk file or a graphics window with the name supplied to
the last storage request.
User action:
Reissue the storage request with a different file name, or delete the old file.
–506
*File already open*
Explanation:
A disk file or graphics window is already open on a logical unit, and
another open request has been attempted.
User action:
Modify the program to use a different logical unit number for the file or
window you want to open, or perform an FCLOSE operation on the file or
window currently open on the specified logical unit number before
performing the FOPEN operation.
–512
*File format error*
Explanation:
The requested disk file is not in a format acceptable to V+ because either it
was not created by V+ or the file has been corrupted.
User action:
Use another diskette or reference another file.
*File not opened*
–513
Explanation:
A program request was made to read or write data from a disk device when
no file was open, or an attempt was made to access a graphics window that
is not open.
User action:
Modify the program to open the file or graphics window before attempting
to read or write data.
*File or subdirectory name error*
–514
Explanation:
The specified file name or subdirectory was not a valid disk file name, the
directory path contained invalid syntax, or the directory path was too long.
User action:
Retry the operation with a correct file name or subdirectory name. Verify
that syntax of the directory path is correct. Check that any default directory
path specified by the DEFAULT command is correct. Check that the total
directory path is not too long when the default is combined with the current
file specification.
*First statement must be .PROGRAM*
–351
Explanation:
An attempt was made to insert or deposit a program statement above the
.PROGRAM statement, which must be the first statement in the program.
User action:
Move the cursor to below the .PROGRAM line of the program before
attempting to insert or deposit statements.
–737
*Font already defined*
Explanation:
An attempt has been made to VLOAD a font file (for subsequent optical
character recognition) that contains a font with the same number as one
519
already in memory. The load operation has been aborted and none of the
fonts in the file have been loaded.
User action:
Rename or delete the font currently defined in memory.
*Font not completely trained*
Explanation:
During planning of a font for optical character recognition (OCR), some or
all of the characters in the font have not been trained.
User action:
Display the font (with VSHOW.FONT) to see which characters have not
been trained. Then train those characters or delete them from the font.
–736
*Font not defined*
Explanation:
The font specified for optical character recognition (OCR) is not defined.
User action:
Use VDEF.FONT or VLOAD to define the font.
–551
*Font not loaded*
Explanation:
The specified font does not exist.
User action:
Specify another font (font #1 is always loaded).
*Force protect limit exceeded*
–624
Explanation:
At least one force-sensor strain gauge reading has exceeded the preset limit,
causing a robot panic stop. This may happen due to high forces experienced
during an insertion, a crash, or high acceleration.
User action:
If a crash occurred, ensure that the work area is cleared. If the limit was
exceeded in normal operation, the limit should be increased or Protect
mode should be disabled. Enable Robot Power with the manual control
pendant and continue operation.
–6506
*Force sensor data error*
Explanation:
The data returned from the force-sensing wrist has been corrupted either by
noise or by an electrical failure.
User action:
*FPB calibration checksum error*
–6518
Explanation:
The Force Processor Board indicated that invalid calibration data was read
from the force sensor.
User action:
*FPB calibration load timeout*
520
–738
–6517
Explanation:
The Force Processor Board timed out while attempting to load calibration
data from the force sensor.
User action:
Alphabetical List
–6520
*FPB internal error*
Explanation:
The Force Processor Board experienced an internal error.
User action:
Reboot the robot system. If the problem persists, call Adept Field Service.
*FPB/FIB handshake error*
–6519
Explanation:
A communication protocol violation occurred between the Force Processor
Board and the Force Interface Board.
User action:
*Function already enabled*
–422
Explanation:
Certain functions or operations must not be enabled when they are already
enabled or active. ALTER mode is an example of such a function.
User action:
Avoid reenabling the function or operation.
*Graphics processor timeout*
–552
Explanation:
The graphics processor (on the system processor) failed to respond to a
command from V+ within five seconds.
User action:
Save all your programs and variables on disk and then reboot the system
from disk. Contact Adept Field Service if the problem repeats.
*Graphics software checksum error*
Explanation:
The code on the graphics board has been corrupted.
User action:
Save new or modified programs, restart the controller, reload the
programs. If the problem persists, contact Adept field service.
*Graphics storage area format error*
–558
–555
Explanation:
During execution of a FREE command, V+ has detected that the
information in graphic memory may have been corrupted. This may have
been caused by a momentary hardware failure or a software error.
User action:
Attempt to save as much as possible onto disk. Issue ZERO 1 and ZERO 2
monitor commands to delete graphics data. If the error persists, power
down the controller and restart the system.
8
(HALTED)
Explanation:
A HALT instruction has been executed, and thus execution of the current
program has terminated.
User action:
Any monitor command can be entered, but PROCEED cannot be used to
resume program execution.
–805
*Hardware not in system*
Explanation:
An instruction has attempted to access optional hardware (such as a
FORCE board) that is not installed in the system.
User action:
Install the needed hardware or remove the instruction that addresses the
hardware.
521
*HPS data file for wrong robot*:
–2150
Explanation:
The data file that has been loaded for the High-Accuracy Position System
(HPS) option does not apply to the current system. The robot model
number and serial number stored in the data file, which are shown in the
error message, do not match any robot in this system.
User action:
If you want to ignore this data file and continue normal AIM execution,
press the “Continue” button. Otherwise, edit the HPS initialization
program (“hp.mod.init” in the files HPSMOD.OVR and HPSMOD.OV2) to
specify the correct HPS data file, or edit the program “ai.module.init” in
your application load file to not load the HPS option.
–507
*I/O communication error*
Explanation:
A hardware error has been detected in the I/O interface.
User action:
Try your command again. If the problem persists, contact Adept Field
Service.
–517
*I/O queue full*
Explanation:
Too many I/O requests have been issued to a device too quickly, and there
is no more room to queue them.
User action:
Retry the operation. If the problem persists, it would be appreciated if you
would report the error to Adept Application Engineering. Please include
the details of the error message and exactly what you were doing at the
time the error occurred.
*I/O statements not allowed*
–2148
Explanation:
An attempt has been made to execute an AIM sequence which contains I/O
statements in a context where they are not allowed.
User action:
Verify that the proper sequence is being executed. Edit the sequence to
remove the I/O statements.
*Illegal .PROGRAM statement*
Explanation:
An attempt has been made to: (1) enter a line other than a .PROGRAM
statement as the first line of a program, or (2) enter a .PROGRAM
statement that contains a syntax error.
User action:
Move below the first line of the program, or reenter the line correctly. (With
the V+ SEE editor, you can press the Undo function key or enter the
command Esc Ctrl+C to cancel the changes you have made to a
–404
*Illegal array index*
522
–467
Explanation:
An attempt has been made to: 1. Use a negative value or a value greater
than 32767 as an array index. 2. Specify a simple variable where an array
variable is required. 3. Omit an array index in a context where it is required.
4. specify an explicit index in a context which requires a null array index. 5.
Specify an index to the right of a blank index for a multiple-dimension
array.
User action:
Correct the line.
Alphabetical List
–403
*Illegal assignment*
Explanation:
The assignment operation just attempted was invalid, possibly because it
attempted to assign a value to a variable name that is a reserved word or a
function.
User action:
Reenter the line, using a different variable name if necessary.
–803
*Illegal camera number*
Explanation:
A vision command or instruction has specified a camera number value that
is invalid.
User action:
Reenter the command or edit the program using the correct camera
number.
*Illegal d.b. specified in link rule*
–2111
Explanation:
A linking rule between two databases or a database and a strategy routine
refers to an invalid database. The only databases that are valid in this
context are opened, fixed, runtime databases. In particular, the following
databases are NOT valid: non-runtime databases (such as the Menu, Error
Message, Help, and directory databases), Assembly and Sequence
databases, and closed databases.
User action:
If the link is unnecessary, system execution can be continued since the link
was ignored. If the link is required, make sure that the proper databases are
opened by “cu.open.fix.dbs” during system start-up.
–405
*Illegal digital signal*
Explanation:
A number or bit field specifies a digital signal that is not in one of the
allowed ranges or that is not installed.
User action:
Correct the signal number, check your digital I/O configuration.
*Illegal expression syntax*
–458
Explanation:
While decoding a numeric or logical expression, a compound
transformation, or a string expression, V+ has encountered syntax that it
does not understand. Possible errors include unmatched parentheses,
missing variables or missing operators.
User action:
Retype the line containing the expression, being careful to follow the V+
syntax rules.
*Illegal force operation while enabled*
Explanation:
The force system was instructed to do an invalid operation—such as
configuring Guarded or Monitor mode while it is enabled, or reading
information from the force signature buffer while it is enabled.
User action:
Check your program to ensure that the failed DEVICE instruction is
preceded by an instruction to disable the given mode.
*Illegal function on this page*
Explanation:
–6522
–2132
The operator has attempted to execute a function that cannot be performed in the context of the current menu page. Most likely the function requires
a record operation to be performed for the primary database associated
523
with the page (for example, delete a record, create a record, move to the
next record), but record operations are not permitted.
User action:
If the function was a record operation that should be allowed, edit the menu
page header and enable the “Record operations allowed” check box.
*Illegal I/O channel number*
Explanation:
An internal I/O channel number has been encountered that is invalid. This
indicates a V+ internal software problem.
User action:
It would be appreciated if you would report the error to Adept
Application Engineering. Please include the details of the error message
and exactly what you were doing at the time the error occurred.
*Illegal I/O device command*
–502
Explanation:
A command to an I/O device was rejected by that device. Certain devices
will not accept all commands. For example, random access I/O is illegal to
the terminal or to the Kermit device; the GETC function cannot read from a
disk file opened for random access. This error may also indicate a hardware
problem with the device controller.
User action:
Correct the I/O command as required to suit the device. If you continue to
have difficulty, contact Adept Application Engineering for assistance.
*Illegal I/O redirection specified*
–525
Explanation:
An unacceptable I/O redirection has been specified in a DEFAULT monitor
command, a disk I/O monitor command (LOAD or STORE_), or in an
ATTACH instruction. Either there is a syntax error, or the requested
redirection is not allowed for your I/O configuration.
User action:
Check the syntax of the offending statement. Check your I/O
configuration to make sure the requested redirection device is allowed.
*Illegal in debug monitor mode*
–359
Explanation:
An operation was attempted that is not accepted in debug monitor mode.
User action:
Use a different command, change to debug editor mode, or exit from the
program debugger.
*Illegal in read-write mode*
–365
Explanation:
An editor function was attempted that cannot be performed while
accessing a program in read-write mode.
User action:
Change to editing the program in read-only mode, or use a different editor
command.
–609
*Illegal joint number*
524
–518
Explanation:
A joint number has been specified out of the allowed range.
User action:
Correct the joint number.
Alphabetical List
*Illegal memory reference*
–418
Explanation:
An operation has attempted to reference an invalid memory address. That
is, one that is either out of the allowed range, or that is not in use for any
input/output module.
User action:
Correct the address or install the missing module.
*Illegal monitor command*
–300
Explanation:
The name of the command just attempted was not recognized by the
system, possibly because it was mistyped, or because it was a program
instruction and not a command.
User action:
Check the spelling of the command name and enter the command again.
Use the DO command to invoke a program instruction from the terminal.
*Illegal motion from here*
–613
Explanation:
The motion just attempted cannot be performed from the current robot
location. For example, NEST can be executed only immediately after a
READY instruction; CALIBRATE can be executed only after power-up,
LIMP, or NEST; and only CALIBRATE or READY can be executed when the
robot is in the nest.
User action:
Perform the appropriate operation sequence before retrying the desired
motion.
*Illegal number of reference frames*
–2119
Explanation:
A database is specified as having either a negative number of associated
reference frames or too many reference frames. Most databases will have
either 0 or 1 associated reference frame. In a cell with two robots, databases
that contain data for both devices may have 2 associated reference frames.
User action:
Review the program that specified that the database was to be opened, and
correct the reference frame specification.
–423
*Illegal operation*
Explanation:
A program instruction has attempted to perform an operation that is not
possible.
User action:
Check the instruction executing when the error occurred. Make sure all
conditions necessary for its successful completion are met.
–528
*Illegal record length*
Explanation:
An FOPEN instruction has specified a record length that is not acceptable.
For example, the value is negative or too large, or the record length is zero
with random-access mode specified.
User action:
Edit the program to specify a correct record length or specify sequentialaccess mode.
*Illegal use of belt variable*
–466
Explanation:
A belt variable has been used in a context where it is not allowed, probably
in a compound transformation but not at the left-most position.
User action:
Edit the program to use the belt variable correctly.
525
*Illegal user LUN specified*
Explanation:
An I/O instruction has specified a logical unit number (LUN) that is not
defined in the V+ system, or cannot be accessed in the manner attempted.
(See the description of the ATTACH instruction for a list of the valid logical
unit numbers and the devices to which they apply.)
User action:
Edit the program to use a logical unit number appropriate for the
instruction.
–402
*Illegal value*
Explanation:
A numeric or expression value that is not in the allowed range was
specified within a command or instruction.
User action:
Edit the program to use a legal value.
*Illegal when command program active*
–419
Explanation:
A command program is active and an attempt has been made to execute a
command that would interfere with operation of the command program.
(For example, processing a ZERO command would cause the command
program to be deleted from the system memory.)
User action:
Edit the command program and delete the command causing the error.
*Illegal when network enabled*
–543
Explanation:
An attempt has been made to perform certain network functions, which
require that the network be disabled, but the network is enabled.
User action:
Disable the network and retry the operation.
*Illegal while joints SPIN’ing*
–637
Explanation:
A program has attempted to execute a regular motion instruction after a
SPIN instruction has been executed to start an axis spinning.
User action:
Edit your program to add a SPIN instruction to stop the current spin axis or
add a BRAKE instruction before the normal motion instruction.
*Illegal while protocol active*
–548
Explanation:
This message indicates that the user tried to enter passthru mode, or did
something unexpected on the serial line configured for use with Kermit
while a file was being processed.
User action:
Make sure there is no file being accessed by Kermit, and retry the failed
operation.
*Illegal while sequence active*
526
–527
–2135
Explanation:
An operation was attempted that is not permitted while a sequence is
running and is active. As an example, teaching a location is not permitted
while a sequence is active, since the robot is attached to the runtime task.
User action:
If you wish to perform the operation immediately, pause or abort sequence
execution and retry the operation. Otherwise, wait until sequence
execution has stopped or paused and perform the operation at that time.
Alphabetical List
*Illegal while sequence running*
–2125
Explanation:
An operation was attempted that is not permitted while a sequence is
running. For example, deleting a record in a runtime database is not
permitted while a sequence is running, since the record may be referenced
by the runtime and/or deleting the record may cause the records to be
resorted. A sequence that is in “Operator Attention” mode is still
considered to be running.
User action:
If you wish to perform the operation immediately, abort sequence execution
and retry the operation. Otherwise, wait until sequence execution has
stopped and perform the operation at that time.
*Image processing board failure*
–728
Explanation:
The controller circuit board that processes vision images has failed to
respond while processing a request to grab a frame.
User action:
After saving the programs, variables, and vision prototypes in memory,
power down the controller. Make sure the image processor is firmly seated
in the controller backplane. Contact Adept Field Service if the problem
persists.
*Incompatible backup version*
–2230
Explanation:
The backup saveset file cannot be used, since it was created with another
version of the backup utility.
User action:
Use a newer version of the backup utility.
*Incompatible d.b. version*
–2007
Explanation:
An attempt was made to open a database file with an incompatible internal
format that had been created with a different version of the database
system.
User action:
Either recreate the database file with the correct version of the database
system, or use the appropriate Adept-provided routine to convert the file to
the correct format.
*Incompatible record size*
–2016
Explanation:
An attempt was made to copy the contents of a string array into a database
record and the information in the string does not match the field structure
of the record.
User action:
Make sure the correct record was initially read, and that the correct record is
being written into.
–2124
*Inconsistent arguments*
Explanation:
During a link or data structure building process, a database record has been
encountered which is inconsistent with other records or data structures.
For example, an attempt has been made to associate a vision-based frame
with a non-vision conveyor.
User action:
Verify that the various databases are being used consistently. Change the
parameters in the databases so that they are consistent.
527
*Incorrect background color*
Explanation:
A vision operation has failed because the required background color or
brightness was not detected in the area being processed. For example, a
vision ruler scan started on an object rather than on the expected
background. In an inspection, this may mean that the object is defective.
User action:
Examine the scene to ensure that the object is positioned correctly in the
field of view. Make sure the correct background color is specified in the
vision operation. Adjust the camera or vision parameters to ensure that the
object and background are visible.
*Incorrect feature spacing*
–6060
Explanation:
A vision operation has failed because two or more features have been
detected at a spacing that is not within the specified range of spacings. In an
inspection, this may mean that the object is defective.
User action:
field of view. Make sure the correct spacing parameters are specified in the
object is visible.
–6059
*Incorrect feature width*
Explanation:
A vision operation has failed because a feature being measured is not
within the specified range of widths. In an inspection, this may mean that
the object is defective.
User action:
field of view. Make sure the correct width parameters are specified in the
object is visible.
*Incorrect lead sweep angle*
–6552
Explanation:
A vision operation has failed because the sweep angle of one or more leads
is greater than the maximum sweep angle allowed. In an inspection, this
may mean the part is defective.
User action:
field of view. Make sure the correct sweep-angle parameter is specified in
the vision operation. Adjust the camera or vision parameters to ensure that
the object is visible.
–6551
*Incorrect lead toe angle*
Explanation:
A vision operation has failed because the toe angle of one or more leads is
greater than the maximum toe angle allowed. In an inspection, this may
mean the part is defective.
User action:
field of view. Make sure the correct toe-angle parameter is specified in the
object is visible.
*Incorrect restore source volume*
Explanation:
528
–6058
–2224
The source volume provided during the restore operation is not correct.
Alphabetical List
User action:
*Incorrect robot configuration*
–6010
Explanation:
An attempt has been made to move the robot to a location that was taught
with a configuration different from the current robot configuration and
automatic configuration changing is not possible.
User action:
Make sure that the robot is moving to the proper location. Make sure that
the “rn.cfg.auto” and “rn.cfg.set” bits are set correctly in the location type
bits for the destination. If necessary, add a path to change configuration.
*Incorrect robot configuration, no auto config defined*
–6011
Explanation:
An attempt has been made to move the robot to a location that was taught
with a configuration different from the current robot configuration. The
configuration would be changed automatically, but no configurationchange routine has been defined.
User action:
Make sure that the robot is moving to the proper location. Make sure that
the “rn.cfg.auto” and “rn.cfg.set” bits are set correctly in the location type
bits for the destination. Make sure that a “rn.auto.config” routine has
been defined.
*Information not available*
–730
Explanation:
(1) A VGETPIC, VPUTPIC, VRULER, VRULERI, or VWINDOW operation
has been attempted when the specified frame store (binary or grayscale)
does not contain valid picture data. (2) No information is available for
VGAPS or VSUBPROTO (for example, V.LAST.VER.DIST is set to zero), or
the prototype name specified is not the name of the last object located.
User action:
Change the operations that precede the failed one, to make sure the
required conditions are satisfied.
*Initialization failure* Belt n
–1015
Explanation:
The indicated belt encoder monitoring system failed to respond to V+
during the initialization caused by the DEFBELT instruction.
User action:
Adept Field Service. (You can prevent this error from being reported by
enabling the DRY.RUN system switch.)
–511
*Input block error*
Explanation:
A read error has occurred while reading a binary-data file from the floppy
disk. This indicates that the wrong file was specified or that the data in the
file is corrupted.
User action:
Try the operation again. If the error recurs use another diskette.
16
*Input error* Try again:
Explanation:
The input provided was not consistent with what V+ expected.
User action:
Provide another response.
529
2053
Insert next volume
Explanation:
Either the volume is full during a backup operation, or the end of the
current backup saveset volume has been reached during a restore
operation.
User action:
If during a backup operation, insert a new volume. If during a restore
operation, insert the specified volume.
–6069
*Inspection failed*
Explanation:
The object currently being inspected has failed inspection because one or
more of its features were not within the limits specified for this vision
operation.
User action:
If the object is not defective, examine the scene to ensure that the object is
positioned correctly in the field of view. Adjust the camera or vision
parameters to ensure that the object is visible. Relax the inspection
tolerances if appropriate.
–2134
*Insufficient access level*
Explanation:
The operator has attempted to execute a function that is not permitted
given the current user access level. The access-level protection feature is
provided so that only authorize personnel are permitted to access and
modify information contained within the system.
User action:
If access to protected information is required, modify the current user
access level via the access-level menu page. If your personal access level is
too low, please see the system manager to obtain higher access privileges.
*Insufficient placement accuracy obtained*
–6071
Explanation:
The part currently being handled could not be placed to the accuracy
specified in the Part Type database within the number or retries specified.
User action:
Increase the number of retries, or relax the placement tolerances.
*Inter-robot I/O channel not operating*
–6100
Explanation:
For a two-robot system, the communications channel between the two
robots was not opened and operating at the time a communications request
was attempted.
User action:
Make sure that the second (remote) robot is still operating properly. If it has
stopped execution of the remote AIM program, restart program execution.
If the remote robot is executing properly, check for a failure in the serial line
that connects the two robots.
–407
*Invalid argument*
530
Explanation:
An argument for a function, program instruction, or SEE editor command is
not in the accepted range.
User action:
Check the range of arguments for the function, program instruction, or
editor command being used.
Alphabetical List
*Invalid backup/restore operation*
–2225
Explanation:
The attempted backup or restore operation failed when an invalid internal
state was detected. This could happen, for example, if a previous backup
or restore operation was terminated abnormally.
User action:
Check for a previous operation that should be resumed. If none is found,
delete the real variable “bk.state.tn” and try the new operation again.
*Invalid camera calibration*
–802
Explanation:
A vision system operation has been attempted before the camera-to-robot
calibration has been done.
User action:
Execute the camera-to-robot calibration program provided by Adept, or
load previous calibration data. The latter can be done, for example, by
calling the subroutine “load.line” provided on the Adept Utility Disk in the
file LOADAREA.V2.
*Invalid camera mounting*
–6055
Explanation:
A vision operation has attempted to use a camera that has an invalid or
inconsistent mounting code. If a group of cameras is used in a single
operation, all must be mounted in the same way and the objects viewed
must all be held in the same way.
User action:
Make sure that the vision calibration files specify the correct camera
mounting. Check that all cameras referenced in a vision operation have the
same type of mounting code and object-held specification.
–741
*Invalid character in font*
Explanation:
An invalid character appears in the string that defines a font for optical
character recognition (OCR). The characters in the string must be in the
range ASCII 33 (“!”) to 126 (““).
User action:
Delete the invalid character from the string.
*Invalid connection specified*
–540
Explanation:
An invalid logical network connection has been specified. For example, a
zero connection ID is invalid.
User action:
Specify a valid logical connection ID.
–2015
*Invalid d.b. array index*
Explanation:
An attempt was made to reference an array element with an index that was
either negative or greater than the number of array elements allocated.
User action:
Use a valid index value.
*Invalid d.b. field number*
–2011
Explanation:
An attempt was made to use a field number that was either negative or
greater than the number of fields in the record.
User action:
Use a valid field number. (The routine “db.lookup.field” can be used to get
the field number associated with a given field name.)
531
–2116
*Invalid d.b. name*
Explanation:
An ADX input text line was expected to contain the name of a database, but
no valid name was found. Databases are specified by their titles. For
example, Sequence and Assembly databases are specified as “xxx
sequence” and “xxx assembly”, where “xxx” is an AIM item name. The
Feeder and Part Type databases are specified as “feeder” and “part type”,
respectively.
User action:
Correct the input text to include a valid database name.
–2001
*Invalid d.b. number*
Explanation:
An attempt was made to reference a database with a negative database
number.
User action:
Use a database number with a positive value.
*Invalid data passed to force system*
–6521
Explanation:
The force system has indicated that data sent to it is inconsistent or out of
range. This can result, for example, from configuring directional or planar
trip conditions with zero-magnitude trip vectors.
User action:
Check the documentation (in the “Force Sensing Module User’s Guide”) for
the DEVICE instruction that generated this error to ensure that the
arguments being passed are valid.
–520
*Invalid disk format*
Explanation:
An attempt has been made to read a disk that is not formatted, or is
formatted improperly; or a FORMAT command has been entered that
specifies invalid format parameters for the device specified.
User action:
If a FORMAT command has been entered, check the command syntax and
retry the command. Otherwise, try a different diskette or reformat the
current one. Remember that formatting erases all information on the
diskette. If the diskette was created on an IBM PC, be sure it was formatted
with one of the formats accepted by the V+ system.
*Invalid error code* Belt n
Explanation:
An unrecognized error was reported by the controller for the indicated
conveyor belt.
User action:
Attempt the operation again. If the error repeats, report the situation to
Adept Application Engineering.
*Invalid force mode configuration*
532
–1010
–6523
Explanation:
An attempt to configure Guarded or Monitor Mode was made with invalid
data, or an attempt was made to enable one of the modes without proper
configuration.
User action:
Ensure that your program executes a valid V+ DEVICE instruction to
configure Guarded or Monitor Mode.
Alphabetical List
–461
*Invalid format specifier*
Explanation:
An unrecognized output format specifier was encountered in a TYPE or
WRITE instruction, or an $ENCODE function.
User action:
Edit the program to use a valid format specifier.
*Invalid hardware configuration*
–533
Explanation:
An attempt has been made to access an I/O device in a manner
inconsistent with its current configuration. Either the I/O device is not
present in the system, or it is configured for some other use. For example, if
a serial communication line is configured as a network port, it cannot be
accessed as a user serial line.
User action:
Make sure the correct device is being accessed. Power down the controller
and try starting it again. Make sure the boot disk you are using is valid for
your controller. Use the “CONFIG_C” utility program to make sure the
serial I/O configuration is correct. If the problem persists, contact Adept
Application Engineering. If the error resulted from a disk I/O operation,
the disk controller hardware is not configured correctly. Contact Adept
Field Service.
*Invalid IGES transformation form*
–2223
Explanation:
The IGES Converter supports two data forms for transformation matrices.
A transformation of an unsupported form was found in the IGES file.
User action:
You can ignore the error if the transformation is not needed to position a
part. Otherwise, the transformation must either be modified on the CAD
system to result in a supported form type (forms 0 or 1) or the Adept IGES
Converter must be customized to recognize and support the new form type.
*Invalid in read-only mode*
–352
Explanation:
An editor function was attempted that cannot be performed while
accessing a program in read-only mode.
User action:
Change to editing the program in read-write mode, or use a different editor
command.
–732
*Invalid model name*
Explanation:
The name of a prototype, subprototype, OCR font, or correlation template
has been incorrectly specified. The correct format for prototype names is
“proto:subproto”, where “proto” is a prototype name and “subproto” is a
subprototype name. Font names have the form “FONT_n”, where “n” is
an integer in the range 0 to 50. (The special name “FONT_0” refers to all
fonts.) Similarly, template names have the form “TMPL_n”. Prototype
names should not begin with “FONT_” or “TMPL_”.
User action:
Enter the attempted operation again, correctly specifying the prototype,
subprototype, OCR font, or correlation template.
–6021
*Invalid motion segment*
Explanation:
An attempt has been made to move the robot to a motion segment which is
not valid for the current motion block. For example, an attempt has been
533
made to move to the “depart” location of a path point, or to use the
MOVE_REL statement after a move to a non-standard motion block.
User action:
Verify that relative move statements are being executed only when
expected. Verify that any custom statements are calling the robot motions
routine “rn.move.loc” correctly.
–2042
*Invalid name*
Explanation:
An AIM item name was expected but could not be found. An item name
consists of a letter followed by any combination of letters, numbers, periods
and underline (“_”) characters. Item names can consist of up to 15
characters. Letters used in item names can be entered in either lowercase or
uppercase.
User action:
Correct the input text to include a valid item name.
*Invalid network address*
Explanation:
The network software has encountered an invalid network address
specification.
User action:
Refer to the AdeptNet User’s Guide.
*Invalid network protocol*
–541
Explanation:
A message has been received and rejected by a remote node because it does
not follow the expected protocol. If the “KERMIT” device was being
accessed, this error indicates the remote server reported an error or sent a
message not understood by the V+ Kermit driver.
User action:
Check that network software version on the remote node is compatible with
the network software on the local node. DISABLE and ENABLE the
affected network nodes and retry the operation. If this error occurs
repeatedly, contact Adept Application Engineering for assistance. (See V+
Language User’s Guide for information on Kermit.)
*Invalid network resource*
–560
Explanation:
The network software has encountered an invalid resource specification.
User action:
–456
*Invalid number format*
Explanation:
A syntax error was detected while reading a number. For example, an 8 or 9
digit was encountered while reading an octal number.
User action:
Reenter the line with a valid number.
Invalid or incompatible TIFF header
534
–561
–6216
Explanation:
The TIFF file containing an image is either of an invalid TIFF format or is
incompatible with the version handled by AIM. AIM only handles a very
limited subset of the full TIFF specification.
User action:
Check that the file was created using the Import/Export Windows menu
under AIM.
Alphabetical List
–619
*Invalid orientation*
Explanation:
A motion has been requested to a location that is defined by a
transformation with its orientation pointed up instead of down.
User action:
Correct the definition of the destination transformation. For example, you
may need to correct the base transformation in the compound
transformation. (The “p” component of all destination transformations
should be approximately 180 degrees.)
–455
*Invalid program or variable name*
Explanation:
A user-defined name used in a command or instruction was not recognized
by V+.
User action:
Check the name and retype the line.
–2253
*Invalid program task*
Explanation:
A program task number has been specified that is not defined on the
referenced controller. Either the number is incorrect, or the V+ system in the
controller is not configured properly. Task numbers may range from 0 to 6.
User action:
Change the task number to a correct value. Verify that the V+ system is
configured to have the proper number of tasks.
–476
*Invalid qualifier*
Explanation:
An invalid qualifier was specified on the last command.
User action:
Enter the command again, with a valid qualifier.
–6112
*Invalid reference frame*
Explanation:
An attempt was made to perform a relative motion with respect to an
unknown or undefined reference frame, or the relative motion mode in the
motion type bits is incorrect.
User action:
Specify or define the reference frame and restart execution, or modify the
motion type bits to correspond to the correct relative motion mode.
*Invalid request while camera running*
–706
Explanation:
An operation was attempted that requires the vision system to be idle, but it
was still processing an image.
User action:
Use a VWAIT instruction to make program execution wait for the vision
system to be idle.
*Invalid request while vision training*
Explanation:
An VEDGE.INFO or VGAPS instruction has been attempted while the
vision system is in prototype training mode.
User action:
Use the manual control pendant to terminate prototype training, type
Ctrl+C at the system terminal to abort a VTRAIN command, or abort
execution of the program that initiated training.
–729
535
*Invalid runtime task specified*
–2258
Explanation:
An unknown runtime task name has been specified. Either the task was
never defined or it has been entered incorrectly.
User action:
Verify that the task was defined previously in a call to the routine
“ai.task.define”. Verify that the task name is spelled correctly.
*Invalid servo error* Mtr n
Explanation:
An unrecognized error was reported for the indicated robot motor.
User action:
Attempt the operation again. Contact Adept Field Service if the error
repeats.
–1001
–625
*Invalid servo initialization data*
Explanation:
During V+ system initialization after booting from disk, servo
initialization data in the wrong format was found. This can be caused by
using a version of the SPEC utility that is incompatible with the V+ system.
User action:
Make sure your system disk has been configured correctly. Contact Adept
Application Engineering for assistance.
–315
*Invalid software configuration*
Explanation:
During initial start-up, V+ has detected that the system software is not
configured properly for the options or hardware present.
User action:
Power down the controller and try starting it again. Make sure that the boot
disk you are using is valid for your controller. If the problem persists,
contact Adept Field Service for assistance.
–463
*Invalid statement label*
Explanation:
The program statement label was not an integer from 0 to 65535.
User action:
Reenter the line with a valid label.
*Invalid user field attributes*
Explanation:
An unexpected value was found in the user-defined field attributes of a
location field while preparing for robot motion. Either the field attributes
were not set up properly during database definition, or the wrong field is
being accessed for robot motion.
User action:
Check to make sure that the database and field being accessed are correct.
If so, stop execution and use the Database Utility to specify the correct user
field attributes for this location field.
*Invalid user name or password*
536
–6113
–2136
Explanation:
While attempting to change the current system access level, the operator
specified a logon user name or password that did not match any of the
information in the Accounts database.
User action:
Correct any errors in the spelling of the name or the password and reenter
the information. If the user name or password is still not accepted, see the
system manager to verify that the information in the Accounts database is
correct.
Alphabetical List
*Invalid VFEATURE access*
–801
Explanation:
A VFEATURE function has been used to access, from the vision system,
data that is not valid. In particular, after a VLOCATE instruction in no-wait
mode, the vision data is invalid if VFEATURE(1) returns the value FALSE.
User action:
Edit the program to ensure that, after a no-wait VLOCATE, no VFEATURE
accesses [other than VFEATURE(1)] occur if the vision data is indicated by
VFEATURE(1) to be invalid.
–735
*Invalid vision argument*
Explanation:
An argument for a vision function, program instruction, or command is not
in the accepted range.
User action:
Check the acceptable range of arguments for the function, program
instruction, or command being used. Check the vision calibration to make
sure the scaling is reasonable.
*Invalid vision record type*
–6202
Explanation:
The vision record that was specified has a type that is invalid in the current
context. For example, a vision tool was specified where an inspection is
required. This error also can occur when selecting a vision database to edit.
It then means that there are vision records in the database that are not
supported by the currently loaded AIM application.
User action:
Specify a vision record that has the correct type, or delete the record with
the wrong type and create a new record.
–6217
*Invalid vision system*
Explanation:
The vision system specified for this vision record or operation is not correct.
This can happen when there is more than one vision system specified from
within one vision database. That is, that there are picture records trying to
make use of physical cameras from two different vision systems.
User action:
Check the calibration records referenced from within the vision database.
All picture records must use physical cameras from the same vision system.
–6200
*Invalid vision tool data*
Explanation:
An unexpected value was found in a Vision database. Either the database
has been corrupted, or it is incompatible with the current vision system
software. This could also mean that a vision tool record in the sequence
does not have a picture record associated with it. Or, that when it will
execute in the sequence, the picture will not have been snapped.
User action:
Check to make sure that the correct database and AIM system software are
being used. If not, exit from AIM and restart. If only a single database
record is affected, delete the record and retrain it. Or, check that the vision
tool records in the sequence have pictures associated with them.
–727
*Invalid vision X/Y ratio*
Explanation:
A VPUTCAL instruction has been used to pass vision calibration data to the
AdeptVision system, and the x-scale to y-scale is not in the acceptable
range.
537
User action:
Make sure the program reads the calibration data from a valid data file, or
make sure valid values are asserted by the program.
*Invalid when program on stack*
Explanation:
An attempt has been made to edit a .PROGRAM or AUTO statement while
the program appears on some task execution stack. While a task is on a
stack, its subroutine arguments and automatic variable values are kept on
the stack. Changes to these statements would modify the stack, which is not
allowed.
User action:
Remove the program from the stack by allowing the task to run until the
desired program executes a RETURN instruction, or issue a KILL monitor
command to clear the stack. If you are using the SEE program editor, press
the Undo key to allow you to continue editing.
*Invalid when program task active*
–311
Explanation:
An attempt has been made to begin execution of a robot or PC program task
when that task is already active.
User action:
Abort the currently executing task, or execute the program as a different
task, if possible.
*Joint 1 in brake track or robot overheated*
–606
Explanation:
(1) Robot joint 1 has been moved into the hardware brake track area, which
causes robot power to be turned off and prevents the robot from moving.
User action:
(1) Push the brake release button at the robot base and move the joints back
into the normal working range. Turn on robot power and continue program
execution.
*Kermit server not in binary mode*
–2232
Explanation:
The attempted backup or restore operation was accessing the Kermit
device, and determined that the Kermit server is not operating in binary
mode. That mode is required in order to correctly store or read a backup
saveset.
User action:
Use the PASSTHRU monitor command to connect to the remote system
running the Kermit server, and restart the server in binary mode. Then retry
the backup or restore operation.
*Keyswitch not set to NETWORK*
–317
Explanation:
An attempt has been made to use a serial line configured for network use,
but the controller keyswitch is not in the “NETWORK” position. If you do
not have a front panel, the keyswitch is assumed to be in the “TERMINAL”
position.
User action:
Move the keyswitch to the “NETWORK” position and retry the operation.
*Keyswitch not set to PENDANT*
Explanation:
538
–366
–304
An attempt has been made to PRIME or otherwise initiate program
execution from the manual control pendant, when the controller keyswitch
is not in the “PENDANT” position. If you do not have a front panel, the
keyswitch is assumed to be in the “TERMINAL” position.
Alphabetical List
User action:
Move the keyswitch to the “PENDANT” position or start program
execution from the selected device.
–303
*Keyswitch not set to TERMINAL*
Explanation:
An attempt has been made to PRIME or otherwise initiate program
execution from the terminal, when the controller keyswitch is not in the
“TERMINAL” position.
User action:
Move the keyswitch to the “TERMINAL” position or start program
execution from the selected device.
–6068
*Lead scan failed*
Explanation:
A lead-scan vision operation has failed to find the object for which it is
looking.
User action:
Make sure the scene is as expected by the scan pattern. Make sure the
pattern parameters are defined properly. Make sure the correct camera is
used and that it is calibrated properly.
–354
*Line too long*
Explanation:
An operation was attempted that would have resulted in accessing a
program step that contains too many characters. A single program step can
contain at most about 150 characters.
User action:
Enter the program step as two or more separate steps.
–2115
*Link operation failed*
Explanation:
The sequence and database linking process has failed. Linking occurs
either when explicitly requested or whenever an attempt is made to start
sequence execution. This message should have been preceded by other
error messages or popups which describe the specific link errors in more
detail.
User action:
Note the errors which preceded this message and fix them as appropriate. If
this error is received when attempting to link from a runtime task, repeat
the link from the operator interface task so that no intermediate messages
are suppressed.
*Local command mailbox empty*
–6101
Explanation:
For a two-robot system, the local mailbox that stores the commands from
the remote robot is empty. The commands are instructions to the local
runtime routines concerning what sequence step or function should be
executed next.
User action:
This error message does not indicate a real system failure. It simply
indicates that the remote robot has not yet generated the next command.
The program that detected this error code should repeat the read request
again after performing a WAIT instruction.
*Locating pins didn’t register*
Explanation:
–6109
A new assembly has just been loaded into the work area, but the assembly
locating pins did not register as expected.
539
User action:
Check if the assembly is positioned correctly. If it is, verify that the digital
I/O signals associated with the locating pins are functioning properly.
Retry the operation.
*Locating pins didn’t retract*
–6110
Explanation:
An attempt to unload an assembly from the work area has failed because
the locating pins did not retract as expected.
User action:
Check if the locating pins are jammed. If they are not jammed, verify that
the digital I/O signals associated with the locating pins are functioning
properly. Retry the operation.
–610
*Location out of range*
Explanation:
V+ has encountered a location that is too far away to represent, possibly
within an intermediate computation. This probably indicates an error in a
location function argument value or in a compound transformation.
User action:
Check to make sure you are using location functions and operations
correctly and edit the program as required.
–618
*Location too close*
Explanation:
An attempt has been made to move the robot to a location that is too close
to the robot column. This probably indicates an error in the value of a
location function argument or an incorrect compound transformation.
User action:
Check to make sure you are using location functions and operations
correctly and edit the program as required.
4020
Loops remaining:
Explanation:
This is a trace message displayed while in walk-through training. It
displays the number of loops which remain when a REPEAT sequence
statement or its corresponding END statement is executed.
User action:
None required.
Lost busy conveyor queue object:
Explanation:
indicates that a robot task has lost a busy object because it is too far
downstream on a tracking conveyor. Busy objects should never be lost.
Lost objects use up system memory until the conveyor manager is
restarted. The name of the object and the queue are displayed.
User action:
Check your sequence to discover why object frames are not being released
before they go downstream. Add a RELEASE_FRAME statement to your
program if needed, or uncheck the “keep frame” boxes on the location
records.
–639
*Manual brake release*
540
4034
Explanation:
V+ has detected that the manual brake release button for the robot has been
pressed and robot power has been disabled.
User action:
Re-enable robot power after you are done manually moving the robot.
Alphabetical List
*Manual control pendant failure*
–650
Explanation:
A program has attempted to access the manual control pendant when it is
disconnected or has failed.
User action:
Make sure the pendant is connected properly. If the problem persists,
Marking as done (info only):
Explanation:
This is a trace message displayed while in walk-through training.
User action:
None required.
*Maximum number of prototypes exceeded*
4012
–712
Explanation:
A maximum of 25 prototypes may be in the AdeptVision system memory at
one time.
User action:
If not all of the current prototypes are needed, then store them on disk using
the VSTORE monitor command and VDELETE the prototypes that are not
needed. This will reduce the number of prototypes in memory so that more
may be VTRAINed or VLOADed.
*Maximum number of samples trained*
–739
Explanation:
An attempt has been made to train a character more than 30 times for
optical character recognition (OCR).
User action:
Display the font (with VSHOW.FONT) and determine which characters
have already been trained 30 times. Don’t train those characters any more.
*Menu check routine not executable*
–2131
Explanation:
The menu driver attempted to execute a V+ check routine associated with a
value field, but the specified routine was not executable. (The check routine
is called each time the operator attempts to modified the value of the
associated field.) Most likely the routine is not loaded, is being edited, or
contains a syntax error.
User action:
Verify that the routine name is specified correctly, and that the routine is
loaded and contains no syntax errors.
*Menu spawn routine not executable*
–2130
Explanation:
The menu driver attempted to execute a V+ spawn routine, but the specified
routine was not executable. The spawn routine was probably specified in a
menu button or pull-down menu. Most likely the routine is not loaded, is
being edited, or contains a syntax error.
User action:
Verify that the routine name is specified correctly, and that the routine is
loaded and contains no syntax errors.
*Mismatch in controller model/serial ID*
–2228
Explanation:
An attempt is being made to restore files from a backup saveset that was
created on a different controller.
User action:
Either override this warning message and continue with the restore
operation, or cancel the operation and restore from a saveset that was made
on the current controller.
541
*Misplaced declaration statement*
Explanation:
Upon loading a program or exiting from the program editor, V+ has
encountered an AUTO or LOCAL statement that follows an executable
program instruction.
User action:
Edit the program to make sure that AUTO and LOCAL statements are
preceded only by blank lines, comments, or other AUTO and LOCAL
statements.
–454
*Missing argument*
Explanation:
A valid argument was not found for one or more of the arguments required
for the requested command or instruction. That is, the argument was not
present at all or an invalid argument was present. A possible cause is the
use of a single equal sign (“=”) for the equality relational operator (“==”).
User action:
Check the operation syntax and reenter the line.
–475
*Missing bracket*
Explanation:
In the specification of an array element, a left bracket has been found with
no matching right bracket. Either too many left brackets are present or a
right bracket has been omitted.
User action:
Reenter the line with correctly matching left and right brackets.
–459
*Missing parenthesis*
Explanation:
An attempt was made to evaluate an expression that did not have correctly
matching left and right parentheses.
User action:
Correct the expression.
–460
*Missing quote mark*
Explanation:
A quoted string has been encountered that has no matching quote mark
before the end of the line.
User action:
Insert a quote mark at the end of the string. Strings may not cross line
boundaries.
*Mixing half and full resolutions*
–750
Explanation:
A model (recognition prototype, OCR font, or correlation template) was
defined using a full-frame image, but was applied to a half-frame image
(field only), or vice versa.
User action:
Make sure the correct virtual camera is being used for both defining the
model and applying the model. Associated with each virtual camera is a
calibration array, which contains information indicating whether fullframe or half-frame images are to be acquired with the virtual camera.
*Module already assigned*
Explanation:
542
–471
–2285
An attempt has been made to assign a module to an AIM server task when
a module has already been assigned. For example, two different AIM
runtime tasks may be attempting to access the same vision server task,
using different modules. Vision servers are selected based on the vision
system number used by the vision database.
Alphabetical List
User action:
Verify that AIM runtime tasks use different vision systems in their vision
databases. Verify that the proper sequences have been selected for each
runtime tasks.
*Module data inconsistent*
–2271
Explanation:
The module data structures in AIM memory are inconsistent with the data
in the module database. This error should not normally be encountered.
User action:
Shutdown AIM and restart. If the problem persists, report this error to
Adept field service.
*Module file format error*
–2270
Explanation:
The module file “module.db” has become corrupted due to a hardware or
software error. This error should not normally be encountered.
User action:
Make backup copies of all files which are members of modules. These file
names are of the form <module_name>.<type>. Store these files in a
separate disk directory or on a floppy disk. Use the module utility to
examine the modules and delete the offending items. Recreate the module
by importing the backed up module files. Report this error to Adept field
service.
*Module has not been modified*
–2143
Explanation:
The operator is attempting to save a V+ program module that has not been
modified in memory. Saving the module is somewhat wasteful since the
module’s disk file is already identical to the memory image.
User action:
No harm will be done if the module is written to the disk so the user can
continue the operation if they so choose.
–2276
*Module in use*
Explanation:
The requested operation cannot be performed because the referenced
module is in use. For example, a module cannot be unloaded while it is
assigned to an active runtime task or is selected by the operator interface.
User action:
Use the module utility to deselect the referenced module. Stop any runtime
tasks which are using this module.
–2278
*Module not assigned*
Explanation:
The requested operation cannot be performed because no module is
assigned to the current task.
User action:
Use the module utility to select a module.
–2273
*Module not found*
Explanation:
The module referenced by an operation does not exist.
User action:
Verify that the referenced module name is correct. Use the module utility
to create the module.
–2272
*Module not loaded*
Explanation:
The module referenced by an operation is not loaded when it should be.
543
Alphabetical List
User action:
Use the module utility to load the module. If this module is used
frequently, specify “auto load” for this module so that it will be
automatically loaded when AIM starts. Verify that the referenced module
name is correct.
–630
*Motion interface E-STOP*
Explanation:
The AdeptMotion system has detected an error or problem and has asserted
the BRKSTOP signal on the VME bus.
User action:
Correct the problem generating the error from the motion system.
–6020
*Motion not initialized*
Explanation:
An attempt has been made to move the robot using certain motion control
software before the motion has been properly setup. For example, the
routines “rn.move.loc” have been called before calling “rn.setup.move”.
Relative motion statements such as “MOVE_REL” may have been executed
before a basis location is setup.
User action:
Verify that relative move statements are being executed only when
expected. Verify that any custom statements are calling the robot motions
routines correctly.
*Motion statements not allowed*
–2146
Explanation:
An attempt has been made to execute an AIM sequence which contains
robot motion statements in a context where they are not allowed. For
example, robot motion is not permitted in a location or path strategy
routine.
User action:
remove the robot motion statements.
*Motor amplifier fault 2* Mtr n
–1019
Explanation:
The power amplifier for the indicated motor has signaled a fault condition
on fault line 2. This fault occurs only for devices controlled by the
AdeptMotion Servo system. The interpretation of this fault depends on the
particular device being controlled.
User action:
Turn Robot Power back on and restart the program. If the error persists,
implement procedures appropriate for your AdeptMotion system. If the
robot is a standard Adept product, contact Adept Field Service.
–1020
Explanation:
The power amplifier for the indicated motor has signaled a fault condition
on fault line 3. This fault occurs only for devices controlled by the
AdeptMotion Servo system. The interpretation of this fault depends on the
particular device being controlled.
User action:
implement procedures appropriate for your AdeptMotion system. If the
robot is a standard Adept product, contact Adept Field Service.
544
Alphabetical List
*Motor amplifier fault* Mtr n
–1018
Explanation:
The power amplifier for the indicated motor has signaled a fault condition.
The interpretation of this fault depends on the particular device being
controlled.
User action:
implement procedures appropriate for your system. If the robot is a
standard Adept product, contact Adept Field Service.
*Motor overheating* Mtr n
–1016
Explanation:
The indicated motor is overheating.
User action:
Reduce the speed, acceleration, and/or deceleration of the robot motions;
or introduce delays in the application cycle to give the motor an
opportunity to cool.
*Motor power failure* Mtr n
–1017
Explanation:
The power source for the indicated motor has signaled a fault condition. A
momentary power failure or a hardware error may have occurred.
User action:
–1007
*Motor stalled* Mtr n
Explanation:
The indicated motor has stalled while being driven. This is usually caused
by the robot encountering an obstruction.
User action:
Turn Robot Power back on and restart the program. Remove the obstruction
or modify the program to have the robot follow a different path.
*Motor start-up failure* Mtr n
–1105
Explanation:
During calibration, the indicated motor did not move as expected. The
problem may be: (1) the motor is obstructed or up against a limit stop, (2)
the load on the robot is too large for calibration, (3) the motor drive
hardware is not functioning, or (4) the position encoders are not
functioning.
User action:
Move the robot away from its limit stops and remove any unusual load.
Turn Robot Power back on and try to calibrate again. Contact Adept Field
Service if the error persists.
4005
Moving along:
Explanation:
User action:
None required.
4013
Moving to vision location:
Explanation:
User action:
None required.
4004
Moving to:
Explanation:
545
User action:
None required.
*Multiple AIM systems not supported*
–2256
Explanation:
An attempt has been made to enable multiple AIM systems in a controller
which does not support this feature. Multiple AIM systems are only
supported in V+ version 11.0 and later, and require multiple V+ CPU boards
to be installed.
User action:
Verify that you are using V+ version 11.0 or later. Verify that more than one
CPU board is installed and is running V+.
–360
*Must be in debug mode*
Explanation:
An editor function was attempted that is accepted only when the program
debugger is active.
User action:
Use a different editor command or activate the program debugger with the
SEE editor DEBUG extended command or the DEBUG monitor command.
*Must have exactly one picture*
–2121
Explanation:
All the vision trees which are associated with a specific moving reference
frame must be based on a single picture. This restriction applies to all object
definitions which are associated with that moving reference frame.
User action:
Edit the objects or vision trees associated with a moving reference frame so
that only one picture record is referenced.
–666
*Must use CPU #1*
Explanation:
In a multiple CPU system, a secondary CPU has attempted to issue a
program instruction or monitor command which is only valid when issued
by CPU #1. For example, the command “ENABLE POWER” is only valid
from CPU #1.
User action:
Switch to the monitor window for CPU #1 and reissue the command. Edit
your program to not attempt to execute such instructions when running on
a CPU other than the first.
–666
*Must use Monitor #1*
Explanation:
A command or instruction that requires execution on CPU #1 has been
attempted on a different CPU.
User action:
*Must use straight-line motion*
Explanation:
A joint-controlled motion instruction was attempted while the system was
in a mode requiring that only straight-line motions be used. For example,
while tracking a conveyor, only straight-line motions can be used.
User action:
Change the motion instruction to one that requests a straight-line motion.
–2139
*Name already exists*
Explanation:
546
–611
An attempt has been made to use a name that already exists, in a context
where names must be unique. For example, many databases require that all
the record names must be unique.
Alphabetical List
User action:
If possible, display the index of names already in use in the current context,
and then repeat the operation with an unused name.
–410
*Negative square root*
Explanation:
An attempt has been made to calculate the square root of a negative
number.
User action:
Correct the program as required.
–535
*Network closed locally*
Explanation:
An attempt has been made to access a DDCMP serial line when the protocol
is not active. The protocol was probably stopped because of some other
error condition.
User action:
Restart the DDCMP protocol.
–538
*Network node off line*
Explanation:
An attempt has been made to send data to a known network node that is
off-line. Either the node has been disabled, or it is not connected to the
network.
User action:
Check that the remote node is active and connected to the network. Check
that the local node is connected to the network.
–542
*Network not enabled*
Explanation:
An attempt has been made to access a remote network node, or perform
certain network functions, when the network is not enabled.
User action:
Enable the network and retry the operation.
*Network resource name conflict*
Explanation:
The network software has encountered a resource name which is in
conflict with an existing name.
User action:
*Network restarted remotely*
–564
–534
Explanation:
V+ has received a DDCMP start-up message from the remote system when
the protocol was already started. The remote system has probably stopped
and restarted its protocol. The local protocol is stopped and all pending I/O
requests are completed with this error.
User action:
(1) Close and reopen the DDCMP line. (2) Check the remote program logic
to see why it restarted the protocol.
–562
*Network timeout*
Explanation:
The network software has timed out waiting for a response.
User action:
Verify that your controller is connected to the network. Check your
Ethernet cable connections. Verify that the node being accessed is
connected and functioning properly. Refer to the AdeptNet User’s Guide.
547
–1299
*NFS error* Code n
Explanation:
Network File System (NFS) which uses the network has detected an error.
NFS returns error codes in the range 0 to 99. V + reports NFS error n as error
code -1200-n.
User action:
–1200
*NFS error* Code n
Explanation:
The Network File System (NFS), which uses the network, has detected an
error. NFS returns error codes in the range 0 to 99. V + reports NFS error n
as error code -1200-n.
User action:
–607
*No air pressure*
Explanation:
V+ detected that the air supply to the robot brakes and hand has failed.
Robot Power is turned off and cannot be turned on until the air pressure is
restored.
User action:
Restore the air pressure, turn Robot Power back on, and resume program
execution. If the error persists, contact Adept Field Service.
*No available LUNs for d.b.*
Explanation:
When opening or closing a database there were no LUNs available for use
by the database routines. Opening a memory-resident database takes one
LUN; opening a disk-resident database requires two LUNs. Creating either
type requires two LUNs. An opened memory-resident database uses no
LUNs unless it is being updated or closed. An opened disk-resident
database continues to use one LUN, and uses an additional LUN when
being sorted.
User action:
Free up enough LUNs. Either use less disk-resident databases or less userassigned LUNs.
–6052
*No camera defined*
Explanation:
An attempt has been made to take a picture without specifying a camera.
The picture may have been attempted during editing or while performing
some vision operation.
User action:
Edit the picture record and specify a camera.
–2200
*No d.b. attached*
Explanation:
An ADX command was issued that required access to a database, but no
database is currently attached to the ADX system.
User action:
Use a $ATTACH or $LOAD command to attach a database and then retry
the command that failed.
*No d.b. record currently open*
548
–2005
–2022
Explanation:
An attempt was made to read or write a record field, but no record was
open.
User action:
Open a record before attempting to access its fields.
Alphabetical List
–526
*No data received*
Explanation:
An I/O read request without wait has not found any data to return. This is
not really an error condition.
User action:
Continue polling the I/O device until data is received, or use a read request
that waits automatically for data to be received.
–6003
*No entry point for*:
Explanation:
An attempt has been made to move along a path that contains no entry
points. The name of the path is shown.
User action:
Edit the path and define at least one entry point.
–6004
*No exit point for*:
Explanation:
An attempt has been made to move along a path that does not contain
enough exit points. Most paths require only one exit point, but some paths
(such as reject paths) require more than one. The name of the path is
shown.
User action:
Edit the path and define (at least) one more exit point.
–6006
*No feeders defined for*:
Explanation:
An attempt has been made to acquire a part that has no feeder associated
with it. The name of the part is shown. This error cannot be corrected while
the runtime is active.
User action:
Stop the AIM runtime and then edit the specified part. Specify at least one
feeder for the part.
–6000
*No feeders ready*:
Explanation:
An attempt has been made to acquire a part when no feeder associated with
it is enabled and ready. The name of the part is shown.
User action:
Look at the named part to see what feeders are associated with it. Make
sure that at least one feeder is ready, and then enable it via the feeder
control panel.
*No files to backup/restore*
–2227
Explanation:
This is a warning that there are no files for the requested backup or restore
operation to process. This can occur when requesting a backup of all files
that have changed since the previous backup operation and no files have
been modified. Another possibility is that there are no files that match the
file specification provided for a backup.
User action:
No action is necessary, but a different file specification might be
appropriate.
–2140
*No help available*
Explanation:
The operator has requested help information for a selected field or page,
but no help information is available for this field or page.
User action:
None required.
549
*No known part-moving statement in IGES.TEMPLATE*
–2222
Explanation:
The IGES Converter uses the sequence IGES.TEMPLATE to determine
which AIM statement to use for moving parts to the assembly. The second
statement in this sequence must be a part-moving statement.
User action:
Use the menu selection “Utilities/Sequence Management” to load the
sequence IGES.TEMPLATE and its associated assembly, IGES.ASSEMBLY,
into memory. Edit the sequence so that the second statement is a partmoving statement, such as TRANSFER or TRANSFER.FP. Then, invoke the
IGES Converter again to create the new Sequence and Assembly databases.
*No leads seen*
–6064
Explanation:
No leads were seen on the part currently being inspected.
User action:
Make sure the correct camera is used and that it is calibrated properly.
Adjust the camera settings to make the leads visible.
–6065
*No line found*
Explanation:
A vision operation has failed because a line could not be located. In an
inspection, this may mean the object is defective.
User action:
Adjust the camera settings or line fitter size or position to allow a line to be
found. Make sure the scene is as expected by the scan pattern. Make sure
the pattern parameters are defined properly. Make sure the correct camera
is used and that it is calibrated properly.
–539
*No matching connection*
Explanation:
A request for a logical network connection has been received and rejected
because there is no matching connection on the remote node.
User action:
Check that the proper logical connection was specified. Check that the
remote node is operating properly.
(no message or popup is generated)
Explanation:
This is an error code that generates no message, but otherwise it is treated
like an error. It may be useful occasionally for customizers, but in general it
should be used with caution. When this error code is returned to the menu
driver, requested actions will not be performed, but NO MESSAGE OR
POPUP WILL APPEAR.
User action:
None required.
–2284
*No modules defined*
550
–2142
Explanation:
An attempt has been made to select a database from a module when there
are no modules defined for the current AIM system. For example, the
sequence editor cannot display an index of the sequences in modules if
there are no module.
User action:
Use the module utility to create a module.
Alphabetical List
*No more records allowed*
–2041
Explanation:
An attempt was made to insert or append a new record when the memoryresident database already contained the maximum number of records
allowed.
User action:
Delete an unneeded record before attempting to create the new record.
–704
*No objects seen*
Explanation:
The vision system reports that no objects were seen, in response to a
VTRAIN or VLOCATE command. In the VLOCATE case, it is an error only
if you expect to see objects.
User action:
In the training case, make sure the training object is visible under the
camera. If you expect to see objects, check the threshold parameter, the
minimum area parameter, and the camera hardware.
*No other program referenced*
–353
Explanation:
A command was issued that attempted to reference a previously edited
program, but no other program has been edited during the current editing
session.
User action:
Use the New or GoTo function-key command (or the “N” keyboard
command) to change to a new program.
*No picture data available*
–723
Explanation:
A vision operation was attempted that requires processed picture data (run
length encodings) when no processed picture data was available.
User action:
Issue a VPICTURE or VWINDOW command or instruction with a mode
parameter of –1 or 1. This will provide the processed picture data needed
for rulers or reprocessing.
–301
*No program specified*
Explanation:
No program was specified for an EXECUTE or SEE command or
instruction, or DEBUG command, and no previous program is available as
a default.
User action:
Type the line again, providing a program name.
–702
*No prototypes*
Explanation:
This is the response to the monitor commands VSTORE and VSHOW
(without a parameter) when no prototypes currently exist.
User action:
Load some vision object prototypes or train a new one.
–2201
*No record selected*
Explanation:
An ADX command was issued that required access to a record of the
database currently attached, but no record has been selected for
modification.
User action:
Use a $MODIFY_RECORD or $RECORD command to select the desired
record to modify, and then retry the command that failed.
551
*No robot connected to system*
Explanation:
An attempt has been made to attach a robot with a system that does not
support control of a robot. (Note that some commands, instructions, and
functions implicitly attach the robot.)
User action:
Make sure the system has been booted from the correct system disk (for
example, use the ID command to display the system identification).
Change the program so that it does not attempt to attach the robot.
–2137
*No sequence selected*
Explanation:
An attempt has been made to start execution of a sequence, but none has
been selected.
User action:
Select a sequence and then retry the start operation.
–2010
*No such d.b. field name*
Explanation:
A call was made to “db.lookup.field” with a string that did not match any
of the fields associated with the specified database.
User action:
Check that the field name is spelled correctly and that the right database is
being specified. The Database Utility may be used to display the fields in
the records of a database.
–2020
*No such d.b. record*
Explanation:
An attempt was made to open a non-existent record. Either an invalid
record number was specified (that is, one with a negative value or a value
greater than the number of records in the database) or the next record
before (after) the first (last) non-deleted record was requested.
User action:
Request a valid record number.
*No V+ task available*
–2261
Explanation:
An attempt has been made to start a concurrent process which uses a V+
task when all tasks are already in use. The custom variables “cu.conc.task”
and “cu.num.conc” define the range of tasks which AIM may use for
concurrent processes. V+ systems require the V+ Extensions option in order
access the higher numbered tasks.
User action:
Wait until some active concurrent processes have stopped and then retry
starting your new process. Stop an active concurrent process such as the
dynamic “Status Window” or the profiler. Add the V+ Extensions option to
your V+ system. Increase the value of variable “cu.num.conc” in the custom
file.
*No valid data in d.b. field*
–2013
Explanation:
An attempt was made to read the value of a field that never had a value
assigned. The value zero is returned.
User action:
Make sure the correct field was accessed.
*No value assigned to frame*
Explanation:
552
–622
–6017
An attempt has been made to use a variable reference frame which has no
object assigned to it.
Alphabetical List
User action:
Change your program to issue a GET_FRAME statement for that reference
frame before using, or use a different reference frame.
*No vision system selected*
–751
Explanation:
The current task has not selected a vision system. By default, vision system
1 is selected. This error may indicate the vision option is not installed.
User action:
Use the SELECT( ) function to select a vision system.
–1011
*No zero index* Belt n
Explanation:
The conveyor belt controller did not detect a zero-index mark for the
indicated belt.
User action:
Make sure the value of the BELT.ZERO.COUNT parameter is set correctly.
Make sure the belt encoder is connected properly. If the problem persists,
–1004
*No zero index* Mtr n
Explanation:
The motor controller did not detect a zero-index mark for the indicated
joint.
User action:
Contact Adept Field Service.
–501
*Nonexistent file*
Explanation:
(1) The requested file is not stored on the disk accessed. Either the name
was mistyped or the wrong disk was read.
User action:
(1) Check the file name—use the FDIRECTORY command to display the
directory of the disk.
*Nonexistent subdirectory*
–545
Explanation:
The subdirectory referenced in a file specification does not exist on the disk
that is referenced. Note that the subdirectory may be part of a default
directory path set by the DEFAULT monitor command.
User action:
Check that the subdirectory name was entered correctly. Check that the
correct disk drive was referenced and that the correct diskette is loaded.
Use an FDIRECTORY command to display the directory containing the
subdirectory. Check that the default directory path is correct.
–2283
*Not a control sequence*
Explanation:
The sequence associated with a menu button press is not a control
sequence.
User action:
Assign a different sequence to the menu button, or use the module utilities
to flag the desired sequence as a control sequence.
*Not a valid backup saveset file*
–2229
Explanation:
The restore operation failed because the backup saveset file being used is
not valid.
User action:
Check that the file is the correct backup saveset file.
553
–516
*Not attached to logical unit*
Explanation:
A program has attempted to perform I/O to a logical unit that it has not
attached with an ATTACH instruction. Logical unit 4 allows output
without being attached, but all other logical units require attachment for
both input and output.
User action:
Edit the program to make sure it attaches a logical unit before attempting
to use it to perform I/O.
–544
*Not configured as accessed*
Explanation:
An attempt has been made to access a serial line or other I/O device in a
manner for which it is not configured. For example, a Kermit or network
line cannot be accessed as a simple serial line.
User action:
Check on the proper way to access the serial line for the current
configuration. Use the configuration utility program to display the serial
line configuration and change it if desired.
*Not enough frame buffers available*
Explanation:
The total number of frame buffers required to execute the current vision
sequence exceeds the number of buffers available in the system. There are
two frame buffers in the system. If using “ping-pong” mode, you can only
have one picture in the sequence. If you are not using any ping-pong
pictures, this error could indicate that the vision trees in the sequence are
requesting and using pictures in such a way that requires a picture be
snapped more than once per cycle.
User action:
Check your picture definitions to be sure you are not trying to use “pingpong” on more than one picture in the sequence. Or, if not using ping-pong,
reorder the statements and/or record trees, so that the pictures are used in a
different order.
*Not enough memory available*
–2040
Explanation:
While sorting a disk-resident database, there was not enough memory
available. The disk file remains unsorted.
User action:
Increase the value of the variable “db.max.blks.srt” to accommodate the
database file. For sorting to work, the value must be at least as large as
*Not enough program stack space*
–413
Explanation:
An attempt was made to call a subroutine, process a reaction subroutine, or
allocate automatic variables when the stack for the program task was too
full.
User action:
Reorganize the program logic to eliminate one or more nested subroutine
calls or reactions; eliminate some of the automatic variables that are
allocated by the programs; use the STACK monitor command to increase
the size of the stack for the program task. The program may be restarted
with the RETRY command.
*Not enough prototype storage area*
Explanation:
554
–6203
The vision system does not have enough memory to store all of the
prototypes requested.
–717
Alphabetical List
User action:
VDELETE unused prototypes, load fewer prototypes, or use simpler object
models.
*Not enough ruler transitions*
–6057
Explanation:
A vision operation that uses rulers has failed because the number of
transitions detected is less than the number required. In an inspection, this
may mean that the object is defective.
User action:
field of view. Make sure the correct number of transitions is specified in the
object is visible.
–411
*Not enough storage area*
Explanation:
There is no more space in RAM for programs or variables.
User action:
Delete unused programs and variables. If the memory is fragmented
because of numerous deletions, it can be consolidated by issuing the
commands “STORE save_all”, “ZERO”, and “LOAD save_all”. This will
write the memory contents to the disk and read them back into memory.
Note, however, that this procedure will not retain any variables that are not
referenced by any program in memory, nor will it retain the values of
variables that are defined to be AUTO or LOCAL.
–356
*Not found*
Explanation:
The search operation was unable to locate the specified string.
User action:
Enter a new search string, or consider this an informational message and
continue with other operations.
–665
*NVRAM battery failure*
Explanation:
The non-volatile RAM battery backup has failed and the RAM may not
hold valid data.
User action:
Replace NVRAM battery.
–661
*NVRAM data invalid*
Explanation:
The non-volatile RAM has not been initialized or the data has been
corrupted.
User action:
Power down your controller and reboot your system. If the error persists,
*Only searches for d.b. values allowed*
–2138
Explanation:
The operator has attempted to initiate a database search operation via a
menu page. However, searches are permitted only under the following
conditions: (1) the menu page must allow record operations on a specified
primary database, (2) a database field value must be currently selected, and
(3) the selected field must be contained in the primary database.
User action:
Most likely, you have not selected a field that can be used to perform the
search operation. Ensure that a valid field is selected before initiating the
search operation.
555
*Operator control statements not allowed*
Explanation:
An attempt has been made to execute an AIM sequence from the runtime
interface when the sequence contains statements which are restricted to the
AIM operator interface.
User action:
remove the statements restricted to the operator interface.
*Optimized move not possible*
–6014
Explanation:
An optimized move has been encountered in a situation where it cannot be
grouped into a depart/approach/move sequence.
User action:
Edit the sequence or location database to not select optimized moves in the
current situation.
–804
*Option not installed*
Explanation:
An attempt has been made to use a feature of a V+ system option that is not
present in this robot system.
User action:
Power down the controller and try starting it again. Contact Adept
Application Engineering if the problem repeats.
*Optional argument can’t be specified*
–2113
Explanation:
While an assembly sequence was being scanned, an optional statement
argument was encountered that is specified but should not be. This can
occur if an argument follows an unspecified argument in an optional
clause, or if a specified nested clause is contained within a clause that is not
unspecified.
User action:
Edit the assembly sequence using the sequence editor and correctly specify
the optional arguments.
*Out of graphics memory*
–549
Explanation:
There is no more space in the graphics memory on the system processor for
windows, icons, fonts, or other graphics items.
User action:
Delete unused graphics items, or reduce the size of windows, to free up
graphics memory.
–532
*Out of I/O buffer space*
Explanation:
An I/O operation cannot be performed because the V+ system has run out
of memory for buffers.
User action:
Delete some of the programs or data in the system memory and retry the
operation. (Also see “*Not enough storage area*”.)
*Out of network resources*
556
–2145
–559
Explanation:
The network software has run out of resources for communication. Either
you have attempted to make too many simultaneous network connections,
or you have not configured your network software properly.
User action:
Alphabetical List
Out-of-range conveyor queue object:
4035
Explanation:
indicates that an object which cannot be reached has been encountered on a
null or indexing conveyor. Normally, all objects on such a conveyor are
reachable. The objects are removed from the queue, but are not “lost”. The
name of the object and the queue are displayed.
User action:
Verify that unreachable objects are expected for this application.
–529
*Output record too long*
Explanation:
A TYPE, PROMPT, or WRITE instruction has attempted to output a line
that is too long. The maximum line length is 512 characters.
User action:
Change the program to output less information from each instruction.
Remember that you can concatenate the output from separate instructions
by using “/S” to suppress the carriage return and line feed normally done
at the end of each TYPE output.
–633
*PANIC command*
Explanation:
The operator has entered a V+ PANIC monitor command which has
stopped the current robot motion. Robot power is still enabled.
User action:
To continue withe current motion, enter the RETRY monitor command. to
continue after the current motion, enter the PROCEED monitor command.
–6002
*Part insertion failed at*:
Explanation:
An attempt to insert a part in an assembly has failed and no reject path is
specified. The runtime has paused so that the operator can correct the
problem.
User action:
Manually remove or insert the part and appropriately set the “part
inserted” indicator on the operator control panel. Continue with the desired
operator response.
2007
Part insertion failed at:
Explanation:
An attempt to insert a part in an assembly has failed, and the part will be
rejected automatically. The name of the assembly location is shown.
User action:
9
(PAUSED)
Explanation:
A PAUSE instruction has been executed, and thus the current program has
suspended execution.
User action:
Any monitor command can be entered. To continue execution of the
program, type “PROCEED”.
–4003
Pausing at end of action
Explanation:
The AIM runtime system has paused at the end of an action in response to
the “Pause After Action” box being checked on the Debug Control Panel.
User action:
Press one of the operator response buttons to continue the runtime system.
To disable additional pauses, turn off the “Pause After Action” box on the
control panel.
557
–4002
Pausing at end of cycle
Explanation:
The AIM runtime system has paused at the end of a cycle in response to the
“Pause” button being pressed on the Operator Control Panel, or the “Pause
After Cycle” box being checked on the Debug Control Panel.
User action:
To stop the runtime, press the “Stop” button on the Operator Control Panel,
or the “Abort Execution” button on the Debug Control Panel.
Pausing at end of operation
Explanation:
The AIM runtime system has paused at the end of an operation in response
to the “Pause After Operation” box being checked on the Debug Control
Panel. For robot systems, an operation is a single robot motion.
User action:
To disable additional pauses, turn off the “Pause After Operation” box on
the control panel.
Pausing at end of statement
–4001
Explanation:
The AIM runtime system has paused at the end of an statement in response
to the “Pause After Statement” box being checked on the Debug Control
Panel.
User action:
To disable additional pauses, turn off the “Pause After Statement” box on
the control panel.
–4020
Pausing immediately
Explanation:
The AIM runtime system has paused at the first opportunity in response to
the “Pause Immediately” box being checked on the Debug Control Panel.
User action:
To disable additional pauses, turn off the “Pause Immediately” box on the
control panel.
*Pending optimized depart has been skipped*
–6013
Explanation:
A non-optimized approach/move operation is about to be executed when a
optimized depart is pending. The depart cannot occur since it must be
perform with an optimized approach/move.
User action:
Move the robot to a safe place where a depart is not required and then
proceed the motion. Edit the sequence or locations to ensure that an
optimized depart is always paired with an optimized approach/move.
4010
Performing operation:
Explanation:
indicates that a vision operation is about to begin execution.
User action:
None required.
–6220
*Picture not taken*
Explanation:
558
–4004
An attempt has been made to evaluate a vision tree in “save previous”
mode and one or more pictures in the tree not been taken. This mode is
Alphabetical List
used by MotionWare when the “SAVE_PREVIOUS” clause in a statement is
set to “yes”.
User action:
Edit your sequence to execute a “PICTURE” statement before executing the
statement which caused the error. Set the “SAVE_PREVIOUS” clause in the
statement to “no” (or delete it). Check your vision tree to make sure it does
not reference an unwanted picture.
*Picture strobe signal required*
–6211
Explanation:
A dynamic reference frame which uses belt tracking and vision has been
encountered in which the picture record does not specify “strobe output”.
Dynamic reference frames use the latched belt position, and therefore
require that pictures generate the strobe.
User action:
Check the “strobe output” check-box on the picture record associated with
the dynamic reference frame.
*Position out of range* Jt n
–1002
Explanation:
The requested motion was beyond the software-limited range of motion for
the indicated joint.
User action:
Redefine the destination location.
*Position out of range* Mtr n
–1023
Explanation:
The requested motion was beyond the hard limit range of motion for the
indicated motor.
User action:
Redefine the destination location.
*Power failure detected by robot*
–632
Explanation:
Indicates that a controller power failure condition has been detected by the
robot control software while a robot is attached to a program. This error is
issued in addition to –667 if a program has a robot attached and has a
REACTE routine defined. Unlike error –667, if no REACTE routine is
defined and a robot is attached, the V+ program stops with this error.
User action:
The user may need to restart or repeat any operations that were
interrupted by the controller AC power failure. Some reinitialization of the
system may be required: for example, any robot(s) connected to the
controller will need to be recalibrated after a controller power failure
–667
*Power failure detected*
Explanation:
Indicates that a controller AC power fail condition has been detected. If
battery backup is installed, this error will be reported (when power is
restored) by any I/O operations that were cancelled due to the power
failure. This error code may be trapped by a program using the REACTE
instruction in order to provide some level of automatic power failure
response.
User action:
The user may need to restart or repeat any operations that were
interrupted by the controller AC power failure. Some reinitialization of the
system may be required: for example, any robot(s) connected to the
controller will need to be recalibrated after a controller power failure.
559
2100
Proceed
Explanation:
This selection causes the runtime task to continue, assuming that any error
conditions have been cleared manually by the operator.
User action:
Clear any error conditions and make sure the robot is in a safe position for
proceeding.
–4011
Proceed or edit:
Explanation:
During walk-through training, an editable record has been encountered.
The runtime has paused to give you a chance to modify this record. The
name of the database and record are shown.
User action:
Press the “Edit” button to edit the record or press the “Proceed” button to
continue with the AIM runtime.
–309
*Program already exists*
Explanation:
An attempt has been made to LOAD a program that already exists, or to
COPY or RENAME a program to a name that is already in use.
User action:
Delete the conflicting program or use a different name.
*Program argument mismatch*
–408
Explanation:
The arguments in a CALL, CALLS, or EXECUTE instruction do not match
the arguments in the program being referenced, because they are of
different types.
User action:
Modify the CALL, CALLS, or EXECUTE instruction, or the .PROGRAM
statement of the referenced program, so that the argument types match. If
arguments are omitted in the CALL, CALLS, or EXECUTE instruction,
make sure the appropriate commas are included to position the arguments
that are present.
3
Program completed
Explanation:
The program has been executed the number of times specified in the last
EXECUTE command or instruction.
User action:
Any monitor command can be entered, except that PROCEED cannot be
used to resume program execution.
15
Program HOLD
Explanation:
The RUN/HOLD button on the pendant has been pressed while a robot
program was executing, and it is now suspended.
User action:
Any monitor command can be entered. To continue execution of the
program, type PROCEED or RETRY, or press the PROGRAM START button
on the controller. (The RUN/HOLD button can be held down to
temporarily resume execution of the program if the controller keyswitch is
in the “PENDANT” position).
–308
*Program interlocked*
Explanation:
560
An attempt has been made to access a program that is already in use by
some V+ process. For example, you have attempted to delete or edit a
program that is being executed, or execute a program that is being edited.
Alphabetical List
User action:
Abort the program or exit the editor as appropriate and retry the operation.
You can use the SEE editor in read-only mode to look at programs that are
interlocked from read-write access.
–307
*Program not executable*
Explanation:
Because of program errors detected during loading or upon exiting from
the editor, this program cannot be executed.
User action:
Edit the program to remove any errors.
*Program not on top of stack*
–421
Explanation:
A DO context specification has referenced an automatic variable or a
subroutine argument in a program that is not on the top of the stack for the
specified task.
User action:
Reenter the DO command and specify the correct program context or
eliminate references to automatic variables and subroutine arguments. Use
the STATUS command to determine which program is on the top of the
stack.
4
Program task # stopped at program_name, step step_number date ti
Explanation:
Execution of the program task indicated by “#” has terminated for the
reason indicated in the message that preceded this message. The step
number displayed corresponds to the next NEXT program step that would
be executed (for example, if PROCEED were entered). The current date and
time are displayed if the system date and time have been set.
User action:
None. This is only an informational message.
–318
*Program task not active*
Explanation:
An attempt was made to abort a task that was not active.
User action:
None required if the correct task number was specified. Otherwise, use the
STATUS command to determine which task number should have been
used.
–319
*Program task not in use*
Explanation:
A program task cannot be accessed because it has never been used. Such
programs do not use any system memory, and do not appear in the STATUS
display.
User action:
None.
53
*Protected program*
Explanation:
An attempt has been made to list a program that is protected from user
access.
User action:
None.
*Protection error*
–530
Explanation:
An I/O operation cannot be performed because (1) it attempted to write to
a disk that is write protected, or (2) the user does not have the proper access
status.
561
User action:
Check the diskette to make sure the write-protect tab is in the correct
position. Use an FDIRECTORY command to display the disk directory. If
the file has protected (“P”) or read-only (“R”) protection, you cannot access
it in the way attempted.
*Prototype not fully trained*
Explanation:
A vision prototype record in the sequence to be run does not have a fullytrained prototype associated with it in the vision system. The prototype
must be trained at least two times to be usable.
User action:
Enter prototype editing mode and train the prototype at least one more
time. The prototype will be saved in a disk file the next time the operator
performs a Save operation, or when AIM is shut down.
*Queue item tag does not match frame*
–6015
Explanation:
The next item in a queue has a tag signal which does not match the tag
specified in the dynamic reference frame associated with the queue. The
queue is associated with more than one dynamic reference frame.
User action:
Be sure that the sequence contains the proper conditionals so that the
dynamic reference frame is only accessed when its tag signal is set. Use the
CHECK_FRAME statement to be sure that the next item in the queue is not
flushed because it is out of reach.
–2118
*Records not sequential*
Explanation:
A database record is out of sequence within a series of records.
User action:
Abort execution. Renumber the records in order to make them sequential.
*Recursive macros illegal*
–357
Explanation:
An attempt was made to execute a macro recursively. That is, the macro
contained a command character sequence that (directly or indirectly)
restarted execution of the macro.
User action:
Change the macro definitions as necessary to make sure neither macro
invokes itself. You can have the U macro invoke the Y macro, or vice versa
(but not both).
*Reference frame not specified*
–6009
Explanation:
For the current operations to be performed, the locations within the current
database must be defined relative to a reference frame variable. However,
the location is currently defined relative to the fixed, world reference frame
of the robot.
User action:
Abort execution of the assembly sequence and execute the sequence and
assembly utility routines via the menu pages to specify a reference frame
variable for the assembly. Then reexecute the sequence.
*Referenced V+ routine not executable*
Explanation:
562
–6201
–2107
While an assembly sequence was being scanned, a referenced database
record was found that contained the name of a V + subroutine that is not
executable. Most likely the subroutine is a V+ strategy routine that is not
executable due to a syntax error.
Alphabetical List
User action:
Edit the V+ subroutine and correct the syntax error.
*Referenced V+ routine not loaded*
–2106
Explanation:
record was found that contained the name of a V + subroutine that was not
loaded into memory. Most likely the subroutine is a missing V+ strategy
routine.
User action:
Ensure that the name of the routine was not misspelled. If the spelling was
correct, locate the disk file containing the routine and load the file into
memory.
–743
*Region too big*
Explanation:
While using optical character recognition (OCR) to recognize text (VOCR)
or train a font (VTRAIN.OCR), a region in the given window was more
than 63 pixels in the horizontal or vertical dimension.
User action:
Make sure there are no extraneous regions in the training window. If the
characters in the font are too large, use a camera lens with a shorter focal
length, or increase the distance between the camera and the text.
–744
*Region too complicated*
Explanation:
While using optical character recognition (OCR) to train a font
(VTRAIN.OCR), a character region was encountered with more than 20
concavities and holes.
User action:
Look at the binary image (with VDISPLAY mode 2). Perhaps the threshold
needs adjustment.
2004
Rejected assembly:
Explanation:
An assembly sequence has just been rejected due to an error or an operator
request. The name of the assembly is shown.
User action:
Rejected item from conveyor queue:
4033
Explanation:
indicates that a robot task has rejected a conveyor queue object because it is
too far downstream on a tracking conveyor or out of reach on an indexed
conveyor. The name of the object and the queue are displayed.
User action:
None required.
2006
Rejected:
Explanation:
The indicated part has been rejected, either automatically or because of an
operator command. Automatic rejection may occur because a part failed
inspection or an insertion attempt failed.
User action:
563
*Remote AIM system not ready*
Explanation:
In a multi-processor AIM system, the remote AIM system did not respond
to communications from the processor which issued the error message,
within the allotted time period.
User action:
Verify that AIM is loaded and running on both processors. If the error
occurs during AIM start-up, start the secondary AIM system first.
*Remote command mailbox busy*
–6102
Explanation:
For a two-robot system, the command mailbox for the remote robot still
contains the last command that was transmitted. A new command cannot
be transmitted until the remote robot processes the previous command and
signals that the mailbox is empty.
User action:
This error message does not indicate a real system failure. It simply
indicates that the remote robot has not yet processed the command that had
been previously transmitted. The program that detected this error code
should repeat the transmission request again after performing a WAIT
instruction.
*Remote has not exported network resource*
–563
Explanation:
The network software has attempted to access a remote network resource
which is not available.
User action:
*Repeat record exhausted*
–6210
Explanation:
When a vision record has this as a status value, it means that when the
record was evaluated, a repeat record in its tree had run out of results
instances. This error code is passed up the tree and appears in each of the
records that use that repeat record.
User action:
This is a normal message during walk-through training when using repeat
records that have no corresponding combination records. In this case, if it
seems reasonable that the repeat record should be out of results, simply
select “Proceed”. Otherwise, you may want to edit the record and
investigate.
*Required database not loaded*
–2110
Explanation:
A function was invoked that operates on a database which is not currently
loaded.
User action:
Use the menu pages for module selection and modification to include the
database in the current module or edit the custom file to load the database
as a fixed global database at system start-up time. If no such database exists,
use the module modification or database utility to first create the desired
database or database definition.
*Required value not defined*
564
–2257
–2129
Explanation:
The operator has attempted to terminate editing of a database record
without specifying values for all the fields that require a value.
User action:
Examine the record and assign values for all the fields that require a value.
If you are unable to supply the required values or are unable to determine
Alphabetical List
which fields require a value, as a last resort, you can delete the entire
record.
–457
*Reserved word illegal*
Explanation:
An attempt has been made to use a V+ reserved word for a variable name.
(See Chapter 1 for a list of the reserved words.)
User action:
Use a different name for the variable. You can, for example, append a prefix
or suffix to the attempted name.
*Retrieve failed, can’t write name*
–2141
Explanation:
The operator has attempted to Retrieve the name of a database record and
automatically have it written into the record currently displayed. However,
the operation has failed because the field into which the name is to be
written is not currently displayed or is not writable. Since the field cannot
be written, the Retrieve’d name is ignored and the operation is cancelled.
User action:
If the operation failed because the field to be written was on a popup menu
page, reopen the popup page and Retrieve the name from the index of
possible names, rather than performing a Go To and a Retrieve.
2101
Retry action
Explanation:
This selection causes the runtime task to retry the previous action which
may have been unsuccessful.
User action:
retrying.
2103
Retry statement
Explanation:
This selection causes the runtime task to retry the entire statement.
User action:
retrying the statement.
*Robot already attached to program*
–602
Explanation:
A program has executed more than one ATTACH instruction for the robot,
without executing a DETACH in between. Or an attempt has been made to
SELECT another robot when one is already attached. The robot is still
attached even after this error occurs.
User action:
Check the program logic-remove redundant ATTACH instructions, or
DETACH the current robot before attempting to SELECT another robot.
*Robot approach too close*
–6012
Explanation:
The robot has been commanded to move too close to some object in the
workcell. The object and the distance depend upon the particular
application.
User action:
Enter the desired operator response. Select PROCEED to ignore this error
and perform the next robot motion.
565
–621
*Robot interlocked*
Explanation:
An attempt has been made to access a robot or external device that is
already being used by a different program task or by the system monitor.
User action:
Review the program logic and make sure the robot or device is being
controlled by only one program task.
–628
*Robot module not loaded* ID: n
Explanation:
This error occurs only during start-up when a robot module has been
configured using the CONFIG_C or DM_UTIL utilities, but the robot
module is not present in memory.
User action:
Use the DM_UTIL or CONFIG_C utility to add the robot module or the
encoder module to the boot disk before rebooting.
*Robot not attached to this program*
Explanation:
An attempt has been made to execute a robot-control command or
instruction in one of the following invalid situations:
User action:
(1) Make sure the system is booted from the proper system disk, or remove
the robot-control instruction.
–605
*Robot not calibrated*
Explanation:
An attempt has been made to execute a robot-control program when the
robot is not calibrated. No motion is allowed until the robot is calibrated.
User action:
If you want to use the robot, issue a CALIBRATE command or have your
program execute a CALIBRATE instruction. Or enable the DRY.RUN switch
to allow program execution without using the robot.
–604
*Robot power off*
Explanation:
Robot Power is not turned on, or cannot be turned on because of a
hardware failure.
User action:
Turn on Robot Power and reenter the last command.
–627
*Robot power on*
Explanation:
An attempt has been made to perform an action that requires robot power
to be off.
User action:
DISABLE POWER and reexecute the action.
*Robot stopped in unsafe area*
–6008
Explanation:
An error has occurred that caused the robot to stop in an area where it may
hit, or be hit by, other equipment in the work area.
User action:
Use the manual control pendant to move the robot to a safe area and then
enter the desired operator response.
*RSC calibration load failure*
566
–601
–656
Explanation:
V+ cannot load calibration data from the robot signature card (RSC).
User action:
Power down the controller and make sure the robot cables are correctly and
securely connected. If the problem persists, contact Adept Field Service.
Alphabetical List
*RSC communications failure*
–651
Explanation:
V+ has lost communications with the robot signature card (RSC). Either a
hardware problem has occurred or the robot is being operated in an
environment with excessive electrical noise.
User action:
Check the connections of the robot cables. Turn Robot Power back on and
resume program execution. If the problem persists, contact Adept Field
Service.
–669
*RSC hardware failure*
Explanation:
V+ has detected a failure in the Remote Signature Card (RSC) which is
located in the robot base and robot power cannot be enabled.
User action:
Retry enabling robot power. Power down your controller and reboot. Make
sure the robot cables are secure. If the problem persists, contact Adept Field
Service.
*RSC module ID doesn’t match robot*
–676
Explanation:
In a system which has a Remote Signature Card (RSC) located in the base of
the robot, the data which identifies the robot type code not match the
possible data found in the running V+ system.
User action:
Verify that the proper V+ boot disk was used to start your controller. Verify
that the proper controller is being used for the robot. Verify that the robot is
connected to the proper servo interface boards and that those boards are
configured properly. Verify that the proper kinematic module is installed on
your boot disk. Contact Adept Field Service to have your RSC data
checked.
–670
*RSC power failure*
Explanation:
Retry enabling robot power. V+ has detected a power failure in the Remote
Signature Card (RSC) which is located in the robot base and robot power
cannot be enabled.
User action:
Power down your controller and reboot. Make sure the robot cables are
secure. If the problem persists, contact Adept Field Service.
–652
*RSC reset*
Explanation:
V+ has detected that the robot signature card (RSC) has lost power
temporarily, but is now functioning.
User action:
Turn Robot Power back on and resume program execution. If the problem
persists, check the cabling to the robot. Contact Adept Field Service if no
solution can be found.
–653
*RSC time-out*
Explanation:
V+ has not received a response from the robot signature card (RSC) when
expected, during the initial calibration data load. The RSC or its cabling is
probably faulty.
User action:
Power down the controller and check the cables to the robot. If the problem
persists, contact Adept Field Service.
567
–654
*RSC transmission garbled*
Explanation:
V+ has received an invalid transmission from the robot signature card
(RSC). Either a hardware problem has occurred or the robot is being
operated in an environment with excessive electrical noise.
User action:
None unless the calibration load fails or RSC communications fail. If the
problem persists, contact Adept Field Service.
*Ruler scan pattern failed*:
Explanation:
A ruler scan vision operation has failed to find the object for which it is
looking.
User action:
Make sure the camera and scene are as expected by the scan pattern. Make
sure the pattern parameters are defined properly. Make sure the correct
camera is used and it is calibrated properly.
*Runtime execution interlocked*
–2251
Explanation:
Runtime execution cannot be initiated or continued because some other
system task has control of required resources. The user was probably
teaching or executing a vision tool from the editor.
User action:
Wait until editing operations are complete and retry the previous operation,
or abort the runtime.
*Runtime preprocessing failed*
–2123
Explanation:
The preruntime processing of a sequence or database failed and the
sequence cannot be run. Preruntime processing occurs whenever a
sequence is started. The specific errors which caused this failure should
already have been reported.
User action:
Fix the errors previously reported during the preruntime processing.
*Runtime statements not allowed*
–2144
Explanation:
An attempt has been made to execute an AIM sequence from the operator
interface when the sequence contains statements which are restricted to the
AIM runtime.
User action:
remove the statements which are restricted to the runtime.
Search required—PROCEED to update database, else SKIP ACTION
–4009
Explanation:
During walk-through training, a search operation was required for the
previous part insertion to succeed. AIM will update the Assembly database
to reflect the new insertion location, if desired.
User action:
To continue execution after updating the Assembly database with the new
location, select PROCEED. To continue execution and not update the
Assembly database, select SKIP ACTION.
*Sequence calls nested too deeply*
Explanation:
568
–6054
–2260
An attempt has been made to execute an AIM sequence when there are too
many sequence calls already on the stack. Sequences executed directly via
“CALL” statements and sequences executed as strategy routines within
Alphabetical List
statements all count toward the nesting depth. Normally this error indicates
a programming error in which sequences are called in an infinite recursion
loop.
User action:
Press “proceed” to allow this instance of sequence call to execute normally.
Verify that there is no programming error causing infinite recursion.
Increase the value of “cu.sp.max” in the custom file to allow more nested
sequence calls.
–2277
*Sequence in use*
Explanation:
The requested operation cannot be performed because the referenced
sequence is in use. For example, a sequence cannot be unloaded while it is
assigned to an active runtime task or is selected by the operator interface.
User action:
Use the module utility to deselect the module in which the sequence is
found. Stop any runtime tasks which are using this sequence.
–2274
*Sequence not found*
Explanation:
The sequence referenced by an operation does not exist within the current
module.
User action:
Verify that the referenced sequence name is correct. Verify that the correct
module is currently selected. Use the module utility to create the sequence
within the current module.
–2401
*Server not enabled*
Explanation:
This error is reported by a client task when it attempts to access a server
which is not ready to accept requests. The server may not be ready for
several reasons: 1) You have not started the server task from the control
panel, 2) The server task has stopped due to an error condition, 3) You do
not have the AIM or V+ options required by the server, 4) The server task is
not defined in your runtime configuration.
User action:
Verify that the server task is active. Check for errors reported by the server
task. Verify that you are not using statements for AIM options you do not
have installed. Check the runtime task configuration in your
“ai.module.init” program.
–2400
*Server request aborted*
Explanation:
This error is reported by a client task when a server request is aborted by an
operator request or by an unrecoverable error condition. The server task
itself should have already displayed the actual error message which has
probably been handled by the operator.
User action:
Look at the error display for the appropriate server task to determine the
actual error condition.
*Servo board 12V fuse open*
–671
Explanation:
V+ has detected that the 12V fuse on the servo board has opened, which
prevents robot power from being enabled.
User action:
Retry enabling robot power. Replace the servo board for the indicated
robot. If the problem persists, contact Adept Field Service.
569
*Servo board E-Stop fuse open*
Explanation:
V+ has detected that the Emergency Stop (E-Stop) circuit fuse on the servo
board has opened, which prevents robot power from being enabled.
User action:
*Servo board solenoid fuse open*
–672
Explanation:
V+ has detected that the hand control solenoid fuse on the servo board has
opened, which prevents robot power from being enabled.
User action:
–674
*Servo task overloaded*
Explanation:
The servo interrupt task is using up all of the CPU time. This error is not
reported until the servo interrupt task completely occupies more than 10
time slices within a second of real time. The servo interrupt task is
terminated and the robot enters “Fatal Error” state.
User action:
Restart your controller and try again. If the error persists, change one or
more of the following: Move the control of some axes to a secondary CPU.
Change the problem CPU from a 68030 board to a 68040 board. Reduce the
number of robots or axes that you are operating.
4002
Setting tool to NULL
Explanation:
current part type has no tool associated with it so the current tool transform
is assumed to be NULL, and there are no gripper signals.
User action:
None required.
*Skew envelope error* Mtr n
–1022
Explanation:
The two motors associated with a “split” robot axis were not tracking each
other with sufficient accuracy.
User action:
Make sure nothing is obstructing the robot motion. Turn on Robot Power
and try to perform the motion at a slower speed. If necessary, use the SPEC
utility to increase the maximum skew error.
2102
Skip action
Explanation:
This selection causes the runtime task to ignore whatever error may have
occurred and continue normal processing.
User action:
skipping the current action.
2105
Skip sequence
Explanation:
570
–673
This selection causes the runtime task to skip to the end of the current
sequence and continue execution from there. If there are more cycles to be
executed, execution continues at the first statement of the sequence. For
some applications, this selection causes the current assembly to be rejected.
Alphabetical List
User action:
skipping to the end of the sequence.
2104
Skip statement
Explanation:
This selection causes the runtime task to skip the current statement and
continue execution at the start of the next statement.
User action:
skipping to the next statement.
Skipping operation (sources not done):
4011
Explanation:
The named vision record cannot be executed because at least one of the
source records has not been done yet. This normally happens when a
MotionWare tree is being evaluated and not all pictures have been taken
yet.
User action:
More pictures need to be taken before this will not appear.
*Software checksum error*
–316
Explanation:
During processing of a FREE command the V+ system has detected a
checksum error in the system memory. This indicates a problem with the
system software or hardware. A checksum error is also reported if any
patches are made to the system software after the system is started. The
following codes are appended to the message indicating where the error
occurred: Os, operating system; V+, V+ interpreter or trajectory generator;
Vi, vision software; Sv, servo software.
User action:
Report the error and information about any possible contributing
circumstances to Adept Application Engineering. You can continue to use
the system, but you should keep in mind the possibility of a problem with
the hardware.
*Software incompatible* Code n
–1026
Explanation:
The servo code has detected an incompatibility between the servo code and
calibration software.
User action:
Make sure that you are using the calibration software (in the \CALIB\
directory) that you received with the V+ system you are using. If you are
using the correct software, note the code number, and call Adept Customer
Service.
*SPIN motion not permitted*
–638
Explanation:
A program has issued a SPIN instruction to move a joint which has not
been configured for spinning, or to spin a joint while the robot is tracking a
belt or moving under ALTER control.
User action:
Make sure the proper robot is selected. Use the SPEC utility to configure
the selected joint for spinning. Edit your program to not issue the SPIN
instruction while the robot is tracking a belt or moving under ALTER
control.
571
2002
Started assembly:
Explanation:
The system is beginning to work on a new assembly. The name of the
assembly is shown.
User action:
2009
Started sequence:
Explanation:
An AIM sequence has been started.
User action:
4014
Starting operation:
Explanation:
indicates that a vision operation is about to begin execution.
User action:
None required.
0
Step syntax MUST be valid
Explanation:
The SEE editor AUTO.BAD extended command has been used to change
the action to be taken when an invalid line is detected while editing.
Subsequently, the editor will require that such a line be corrected before
you will be able to perform any operation that would move the cursor off
the bad line.
User action:
None. This is an informational message.
–623
*Stop-on-force triggered*
Explanation:
A force-sensor Guarded Mode trip occurred when the robot was not under
program control.
User action:
Robot power must be reenabled before robot motion may continue. If the
trip was not desired, make sure that Guarded Mode is disabled before the
program relinquishes control of the robot to the manual control pendant.
2023
Stopped at end of action
Explanation:
An AIM runtime task has stopped at the end of an action in response to a
“stop after action” request from the operator interface.
User action:
None required.
2022
Stopped at end of cycle
Explanation:
An AIM runtime task has stopped at the end of a cycle in response to a
“stop at end of cycle” request from the operator interface.
User action:
None required.
Stopped at end of operation
572
2024
Explanation:
An AIM runtime task has stopped at the end of an operation in response to
a “stop after operation” request from the operator interface.
User action:
None required.
Alphabetical List
2021
Stopped at end of statement
Explanation:
An AIM runtime task has stopped at the end of a statement in response to a
“stop at end statement” request from the operator interface.
User action:
None required.
–600
*Stopped due to servoing error*
Explanation:
Program execution has stopped because of one or more servo errors.
User action:
Correct the source of the reported servo errors, referring to your system
hardware manual as required.
2025
Stopped execution
Explanation:
An AIM runtime task has stopped in response to a “stop immediately”
request from the operator interface.
User action:
None required.
–305
*Storage area format error*
Explanation:
During execution of a FREE command, V+ has detected that programs or
data in RAM may have been corrupted. This may have been caused by a
momentary hardware failure or a software error.
User action:
Attempt to save as much as possible onto the disk. Then enter a ZERO
command or power down the controller and restart the system.
*Straightener/cutter closed*
–6115
Explanation:
In a two-robot cell, the part presentation robot is about to insert a part into
the straightener/cutter and has detected that the clamp is closed.
User action:
Make sure that the straightener/cutter is empty and that the clamp device
is open. If they are, check that the digital I/O signals for the straightener/
cutter are functioning properly. Issue the appropriate operator responses to
restart the cell operation.
*Straightener/cutter empty*
–6114
Explanation:
In a two-robot cell, the part insertion robot has detected that an expected
part is not in the straightener/cutter.
User action:
Make sure that the straightener/cutter status shown on the STATUS AND
EXECUTION CONTROL menu page is correct. If not, change the status, or
place the required part in the straightener/cutter. Issue the appropriate
operator responses to restart the cell operation.
*Straight-line motion can’t alter configuration*
–612
Explanation:
A change in configuration was requested during a straight-line motion.
This is not allowed.
User action:
Delete the configuration change request, or use a joint-interpolated motion
instruction.
573
–417
*String too short*
Explanation:
A program instruction or command expected a string argument with a
certain minimum length, and received one that was too short.
User action:
Review the syntax for the program instruction and edit the program to pass
a string of the correct length.
*String variable overflow*
Explanation:
An attempt has been made to create a string value that is greater than the
maximum string length of 128 characters.
User action:
Edit the program to generate strings of the proper length.
–547
*Subdirectory in use*
Explanation:
An attempt has been made to delete a subdirectory that still contains files or
that is being referenced by another operation (for example, an
FDIRECTORY command).
User action:
Check that all the files within the subdirectory have been deleted. Check
that no other program tasks are referencing the subdirectory. Retry the
delete operation.
*Subdirectory list too long*
–546
Explanation:
A directory path contains too many subdirectories, or the directory path is
too long to be processed. The path is a combination of subdirectories in the
file specification and the default directory path set by the DEFAULT
monitor command. Directory paths are limited to a total of 16
subdirectories and 80 characters (including any portion of the directory
path specified by the current default path).
User action:
Specify a shorter directory path in the file specification or in the DEFAULT
command. If you are accessing a foreign disk that contains more than 16
nested subdirectories, you cannot read the files in subdirectories nested
deeper than 16 levels. In that case you will need to use the system that
created the disk to copy the files to a directory that is nested less deeply.
–314
*Switch can’t be enabled*
Explanation:
An ENABLE command for a certain switch has been rejected because of
some error condition. For example, ENABLE POWER will fail if the system
is in FATAL ERROR state.
User action:
Review the description for the switch you are trying to enable, correct the
error condition, and try again.
–629
*SYSFAIL asserted*
574
–416
Explanation:
A board on the VME bus has encountered a severe error and asserted
SYSFAIL which turns off robot power.
User action:
Restart the system. Check for proper seating of the system boards and
correct device connections to the boards. Test the system with as many
boards removed as possible, adding boards back in until the problem board
is identified. If the problem persists, contact Adept field service.
Alphabetical List
–748
*Template already defined*
Explanation:
When defining a new correlation template with the program instruction
VTRAIN.MODEL, the number of an existing template was given.
User action:
Delete the existing template if it is no longer needed, or use a different
number in the VTRAIN.MODEL instruction.
–747
*Template not defined*
Explanation:
The correlation template referenced in a VCORRELATE, VDELETE,
VSHOW.MODEL, or VSTORE operation does not exist.
User action:
Check the correlation number supplied to the operation to make sure it is
correct. Use the “Models” pull-down menu in the vision window (or the
VSHOW.MODEL program instruction) to get a list of the templates
currently defined in the vision system.
*Template of uniform intensity*
–746
Explanation:
When defining a correlation template with the VTRAIN.MODEL program
instruction, the area of the image within the given template bounds has
uniform intensity. Image templates must have some variation in
brightness. (That is, there must be some features in the template to correlate
with later.)
User action:
Check the position of the template in the image and make sure it is in the
desired place. Also, view the grayscale image in the current frame to make
sure it is valid. (For example, maybe a strobe light did not fire, or the lens
cap is still on the camera.)
*Timeout enabling amplifier* Mtr n
–1009
Explanation:
The power amplifier for the indicated motor has not removed its fault
signal within the required time limit.
User action:
Turn Robot Power back on and restart the program. Verify that the
amplifier is working properly and that the cabling is correct. Modify the
amplifier timeout value using the SPEC utility. If the robot is a standard
Adept product, contact Adept Field Service.
*Timeout enabling power*
–675
Explanation:
After requesting that robot power be enabled, V+ has not detected it within
the allotted time.
User action:
For non-Adept robots, increase the value of the high power timeout using
the SPEC utility. For Adept robots, double check your installation (cabling,
AC power line voltages, etc.) and try again. Make sure that amplifier
chassis has is properly connected to a power source and is turned on. If the
*Time-out nulling errors* Mtr n
–1003
Explanation:
The indicated motor took too long to complete the last motion, possibly
because the robot is blocked and cannot reach its destination.
User action:
Turn on Robot Power and retry the motion after making any necessary
program changes. If this error occurs repeatedly, contact Adept
Application Engineering for assistance.
575
*Timeout waiting for task to start*
Explanation:
AIM has timed out waiting for the specified task to begin execution. Tasks
signal that they have begun execution by setting the global variable
“ai.task.wait” to FALSE. Either a V+ program error has occurred which
prevented the task from executing, or a higher priority task is preventing
this task from running.
User action:
Check the V+ monitor to make sure that no V+ program errors have
occurred. Use the profiler utility to check if the task is being starved by a
higher priority task. If a custom non-runtime task is being started, verify
that it is setting “ai.task.wait” to FALSE when it begins execution.
–6212
*Time-out while waiting*
Explanation:
A vision operation (usually a picture record) which waits on an I/O signal
has taken too long to execute. When editing, waiting for signals is generally
not allowed to continue for more than about 10 seconds. For pictures, the
wait signals are only active if using the “Image->New Picture” pulldown or
the LOOP popup on the picture record menu page. Otherwise, they are
ignored.
User action:
Trip the signal before the time-out period elapses, do not use signal wait
records, or do not use “New Picture” pulldown.
–553
*Too many arguments*
Explanation:
Too many arguments were specified for the last command or instruction.
User action:
Reenter the command or instruction, but with the correct number of
arguments.
–474
*Too many array indices*
Explanation:
The specification of an array element contains more then three indexes.
User action:
Reenter the line with the correct number of indexes.
*Too many closeable windows*
–554
Explanation:
The names of too many graphics windows have been specified to appear in
the pull-down under the Adept logo in the status line at the top of the
screen.
User action:
Specify all subsequent windows as /NOCLOSEABLE, or delete some
existing windows that appear in this pull-down.
–556
*Too many icons*
576
–2259
Explanation:
An attempt has been made to define more graphic icons than the system is
configured to support.
User action:
Delete any icons that are no longed needed. If necessary, use the
“CONFIG_C” utility program to reconfigure your V+ system to support
more icons.
Alphabetical List
–536
*Too many network errors*
Explanation:
(1) The number of errors detected by the DDCMP protocol has exceeded the
maximum allowed. The local protocol is stopped and all pending I/O
requests are completed with this error.
User action:
(1) Use the NET monitor command to determine the type of errors that
have occurred. Check for noise on the communication line, errors in the
remote DDCMP implementation, or program logic that sends messages
faster than they can be processed. Use the appropriate FCMND instruction
to increase the maximum number of errors.
–6209
*Too many pictures*
Explanation:
An attempt has been made to use more pictures than possible in a single
sequence or vision tree. The number of pictures is limited by the number of
virtual cameras available. By default, there are 16 virtual cameras available,
so there can be no more than 16 pictures referenced.
User action:
Edit the vision operation or sequence to reduce the number of pictures
being used.
–6007
*Too many retries for*:
Explanation:
An operation has failed after performing a number of retries. The name of
the data record associated with the operation is shown.
User action:
Determine why the operation has failed, and correct the problem or
increase the number of retries specified. Select “Retry” to perform
additional retries.
*Too many vision requests pending*
–703
Explanation:
A program has issued too many VLOCATE commands before the first ones
have completed.
User action:
Edit the program to wait for pending VLOCATE requests to complete
before issuing more.
–550
*Too many windows*
Explanation:
An attempt was made to create a graphics window when the maximum
number of windows were already defined. (The V+ system uses two
windows for the screen and the top status line. Every title bar, menu bar,
and scroll bar is a separate window. The pull-down window is always
allocated, even if it is not visible. Systems with AdeptVision always have
the vision-training window allocated.)
User action:
Where possible, change your window definitions to omit menu bars and
scroll bars. If necessary, use the utility program CONFIG_C to increase the
number of window buffers.
–636
*Trajectory clock overrun*
Explanation:
One of two errors has occurred: 1) It was time for a new trajectory setpoint
to be computed but the trajectory generation task was computing the
previous setpoint. 2) The trajectory generation task took too long to
compute a setpoint and the data was not available when the servos
expected it.
577
User action:
Increase the trajectory generation cycle time to 16ms. Move servo tasks off
of CPU #1 to allow more time for trajectory generation. Change CPU #1
from a 68030 to a 68040 board. Reduce the number of robots or axes that
you are operating. Change the servo rate to 1ms if the trajectory cycle time
is set to 2ms.
*Undefined global reference frame*
Explanation:
A database was encountered that has an associated global reference frame
specified, but the frame is not defined in the Reference Frame database.
Relative locations within the database are defined with respect to the global
frame. Therefore, the global frame must be defined prior to location
teaching and sequence execution.
User action:
Edit the Reference Frame database using the database editor and define the
required reference frame. The value for the frame can be taught using the
special frame teaching utility, which is initiated from the CELL SETUP
AND ADJUSTMENT menu page.
Undefined optional value—proceed or edit:
–4007
Explanation:
During walk-through training, an editable optional data value that does not
have a value has been encountered. The runtime has paused to give you a
chance to define this value. The name of the data field is shown.
User action:
Press the “Edit” button to define the named data field, or press the
“Proceed” button to continue with the AIM runtime.
*Undefined program or variable name*
–406
Explanation:
The program or variable, referenced in a command or program step, does
not exist-possibly because the name was mistyped.
User action:
If the correct name was entered, create the program or variable using one of
the V+ editors, the appropriate V+ monitor commands, or by loading from
a disk file.
*Undefined referenced data record*
–2101
Explanation:
While an assembly sequence was being scanned, an argument name was
encountered that is not defined in the database referenced.
User action:
If the argument name was incorrectly typed, use the sequence editor to edit
the step and correct the argument name. If the name is correct, use the
database editor to define the required database record.
*Undefined value in this context*
578
–2109
–420
Explanation:
An automatic variable or subroutine argument value appears in a monitor
command, but the specified program is not on the execution stack for the
specified program task. Automatic variables and subroutine arguments
have values only when the program that defines them is on a stack.
User action:
Change the monitor command to not reference the variables. Check that the
program is on the expected execution stack. You can place a PAUSE
instruction or breakpoint in the program to stop it while it is on the
execution stack.
Alphabetical List
–4005
Undefined value—edit:
Explanation:
During walk-through training, a required data value that is undefined has
been encountered. The runtime has paused to give you a chance to define
the value. The name of the data field is shown.
User action:
Press the “Edit” button to edit the named data field, or press the “Skip
Action” button to continue with the value undefined. Note, however, that
selecting “Skip Action” may cause errors later in execution of the sequence.
–401
*Undefined value*
Explanation:
(1) A variable has been referenced that has not been assigned a value.
User action:
(1) Assign the variable a value or correct its name.
–504
*Unexpected end of file*
Explanation:
1. If a file was being loaded from the disk, the end of the file was
encountered unexpectedly. 2. If a program is reading a file, this error code
merely indicates that the end of the file has been reached and should not be
interpreted as a real error. 3. This message results if a Ctrl+Z is entered in
response to a program PROMPT. 4. A break condition was detected on a
serial line.
User action:
1. Try again to read the file. 2. Close the file and continue program
execution. 3. Treat the program as having been aborted early by user
request.
–6072
*Unexpected part present*
Explanation:
A part-present sensor indicates that a part is present in a situation where
the robot gripper should be empty.
User action:
Manually remove the part from the gripper. Verify that the part-present
sensor is operating properly. Verify that the proper signal is being used for
the part-present sensor.
*Unexpected sensor state*:
–6001
Explanation:
A sensor connected to a digital I/O signal is not in the expected state for the
operation about to be performed. For example, a the part-present sensor
may be TRUE before a part is acquired. The name of the sensor is shown.
User action:
Check that the condition associated with the sensor is correct. Verify that
the digital I/O signals for the sensor are defined correctly and are in the
correct state.
*Unexpected text at end of line*
–451
Explanation:
The previous command or instruction could not be recognized by V+,
possibly because of a mistyped function name or because an argument was
specified where none is allowed.
User action:
Reenter the line, correcting the syntax error.
*Unexpected zero index* Belt n
Explanation:
–1012
A zero index signal was received from the encoder for this motor belt at an
unexpected time. The encoder may be gaining or losing counts, there may
579
be a hardware problem with the zero index signal, or the “Counts per zero
index” configuration parameter may be set incorrectly.
User action:
Continue to use the system. Contact Adept Field Service if this error occurs
repeatedly.
*Unexpected zero index* Mtr n
Explanation:
A zero index signal was received from the encoder for this motor at an
unexpected time. The encoder may be gaining or losing counts, there may
be a hardware problem with the zero index signal, or the “Counts per zero
index” configuration parameter may be set incorrectly.
User action:
Turn on Robot Power and continue to use the system. If this error occurs
repeatedly, contact Adept Field Service.
*Unknown ADX command*
–2203
Explanation:
An unknown command name has been encountered in an ADX data file.
All ADX command names begin with a dollar sign character (“$”), and any
text line that begins with a dollar sign is assumed to contain an ADX command. This error is normally caused by incorrectly specifying a command
name, or inadvertently beginning a data line with a dollar sign.
User action:
Correct the spelling of the ADX command name, or rewrite the data line so
that it does not begin with a dollar sign. If the dollar sign is the first
character of a string, enclose the string in double-quote characters.
–2204
*Unknown data type*
Explanation:
An unknown data type was encountered while reading in an ADX format
specification or an initialization database.
User action:
Check the format specification and correct the data type.
*Unknown database type*
–2282
Explanation:
A database type code has been encountered which is not defined for the
current AIM system. The type code may be defined for an AIM option
which is not installed.
User action:
Verify that the proper AIM application code is being used and that all
expected options are installed. Verify that menu pages specify valid type
codes rather than database number. Verify that all custom data types are
properly defined by calling the routine “ai.db.define”.
*Unknown device specified*
–2252
Explanation:
A device number has been encountered that does not correspond to any of
the devices defined for the system.
User action:
Check that the device specified is correct. Check that the device definitions
for your system are correct.
*Unknown editor command*
580
–1005
–363
Explanation:
An unknown keystroke or extended command was issued while using the
SEE program editor.
User action:
Enter another command.
Alphabetical List
–800
*Unknown error code*
Explanation:
An error code that does not correspond to a known error message was
received by V+ from an external device.
User action:
If an external computer is communicating with V+ when the error occurs,
verify that it is sending proper error codes. Otherwise a software error is
indicated. It would be appreciated if you would report the error to Adept
Application Engineering. Please include the details of the error message
and exactly what you were doing at the time the error occurred.
–462
*Unknown function*
Explanation:
While accepting a program statement, V+ has encountered a reference to a
function that it does not recognize. This could be due to a mistyped
function name, or leaving out an operator between a symbol and a left
parenthesis.
User action:
Check the spelling and syntax and reenter the line.
–452
*Unknown instruction*
Explanation:
An instruction was entered (or read from a disk file) that was not
recognized by the system. This error is often caused by mistyping the
instruction name, or trying to use a command as an instruction or vice
versa. Note that statements with errors are turned into “bad lines”
beginning with a question mark.
User action:
Correct the line or enter it again, making sure the spelling and usage are
correct. When using the SEE editor, an invalid statement is either converted
to a “bad line” or must be corrected before you can leave that line
(depending on the setting of the AUTO.BAD feature). In the case of an error
while loading from the disk, edit the program to correct the indicated
instruction.
–424
*Unknown keyword*
Explanation:
The keyword in an FSET instruction is unknown in the context in which it
was found. (Most often, a keyword used for a serial line was used when
referencing a window or visa versa.)
User action:
Correct the line in the executing program or reenter the command with the
correct keyword.
*Unknown message destination*
–2250
Explanation:
An attempt was made to send a message to a group or task that does not
exist. The send has failed.
User action:
Check that the DEVICE field value in any referenced database corresponds
to an actual robot or task in your system. Check the group and task
definitions to make sure that the referenced device is defined.
*Unknown network node*
Explanation:
–537
A reference has been made to a network node address that is not known by
the local network.
581
User action:
Check that the correct node address was specified. Check that the remote
node is active and connected to the network. If explicit routing tables are
used, check that they specify this node.
–707
*Unknown prototype*
Explanation:
A vision command or instruction has referenced an object prototype that is
not known to the vision system. This may be due to mistyping the
prototype name.
User action:
Enter the command VSHOW at the terminal for a list of the known
prototypes. If necessary, load the appropriate prototype file from disk, or
VTRAIN the prototype.
*Unknown statement argument type*
Explanation:
A sequence step has been encountered that included an argument type
which not known to AIM. The argument may specify a database which is
not in the system or is not a runtime database, or it may specify a keyword
which is not defined. Examples of non-runtime databases include the
Menu, Error Message, Help and directory databases.
User action:
If an non-existent database was referenced, check to ensure that the proper
system was loaded and that it was configured properly. If an invalid
keyword index or a non-runtime database was referenced, correct the
statement definition.
–2104
*Unknown statement*
Explanation:
While an assembly sequence was being scanned, a statement name was
encountered that is not defined in the Statement database. Normally, an
invalid statement name cannot be entered since the sequence editor
requires that statements be fully defined.
User action:
If the statement is not appropriate for the current system, delete the
statement using either the sequence editor or the database editor. If the
statement is desired, examine the Statement database and verify that the
proper Statement database has been loaded. Reenter the statement
definition if required.
–731
*Unknown subprototype*
Explanation:
A vision command or instruction has referenced an object subprototype
that is not known to the vision system. This may be due to mistyping the
prototype name.
User action:
Use the command VSHOW at the terminal to display the subprototypes
defined for the specified prototype. If necessary, load the appropriate
prototype file from disk, or use VDEF.SUBPROTO to define the
subprototype.
*Unspecified required record name*
Explanation:
582
–2103
–2105
record was found that contained an unspecified field. Most likely the
undefined field must contain the name of a record stored within another
database.
Alphabetical List
User action:
Edit the database using the database editor and fill in unspecified field—for
example, the name of the required database record.
*Unspecified required statement argument*
–2102
Explanation:
While an assembly sequence was being scanned, a statement argument was
encountered that is undefined and is required for the proper execution of
the statement.
User action:
Edit the assembly sequence using the sequence editor and fill in the
required argument.
*Unspecified required string value*
–2108
Explanation:
record was found that contained a required string field whose value was
unspecified or null. In most instances, the missing name is the name of a V+
strategy routine that is required for proper execution of the step.
User action:
Edit the database using the database editor and fill in the value of the
required string.
–2202
*Unterminated string*
Explanation:
The double-quote character (“) that marks the end of a string could not be
found. Since text strings can contain an arbitrary number of words
separated by space and tab characters, both the beginning and the end of
certain text strings must be marked with double quotes.
User action:
Correct the input text by placing a double-quote character at the end of the
text string.
4031
Using conveyor queue object:
Explanation:
indicates that a robot task is using a conveyor queue object. The name of
the object and the queue are displayed.
User action:
None required.
*V+ *RSC bad packet format*
–655
Explanation:
V+ has received an incorrect data packet from the robot signature card,
during the initial calibration data load.
User action:
None unless the calibration load fails. If the problem persists, contact Adept
Field Service.
*V+ programming error*
–2254
Explanation:
A V+ programming error has occurred and is being displayed on the V+
monitor window. The error occurred within the specified task which is
now stopped.
User action:
Look at the monitor window to see the error message. If the task number is
not 3, use the “Utilities/Save Databases” pull-down to save data. Edit any
customized programs to eliminate the error. RETRY the specified task, or
issue commands ABORT 0, EX AIM to restart AIM. Contact Adept to report
errors within protected AIM programs.
583
*Value already assigned to frame*
–6016
Explanation:
An attempt has been made to assign an object value to a reference frame
which already has an object assigned to it. For example, you have
attempted a GET_FRAME statement for a frame which has not yet been
released.
User action:
Change your program to release reference frames properly, or uncheck the
“Keep Frame” boxes on the location frames you are using.
–6300
*Variable is read only*
Explanation:
An attempt has been made to write to a constant symbol in the variable
database. Constant values cannot have their values changed by the
runtime code.
User action:
Change your program to not attempt to write to this constant, or replace the
constant in your statement with a read-write variable.
*Variable must be read only*
–6301
Explanation:
An attempt has been made to use a read-write variable from the variable
database in a context where a constant value must be used.
User action:
Change your program to use a constant value, or change your statement
definition and runtime routine to support a variable in this context.
–465
*Variable type mismatch*
Explanation:
One or more of the variables in the line is of a type inconsistent with the
other variables or with the type required by the command or instruction.
For example, you may be trying to mix location variables with real-valued
variables. If this error occurs upon exiting from the editor, the variable type
within the program conflicts with the type of a global variable that is
already defined.
User action:
Check the syntax for the operation and reenter the line, correcting the
mismatch. Delete conflicting global variables, if appropriate.
*Vision aborted*
–749
Explanation:
(1) The “Abort” menu item in the vision window has been selected. If a
vision instruction in a V+ program was being executed, it is aborted and the
error code for this message is returned (for access with the ERROR
function). (2) A V+ program has been aborted when it was executing a
vision instruction. (In this case, the error code for the standard “Aborted”
message is normally returned.) (3) a VABORT instruction was issued.
User action:
If you selected the “Abort” menu item by mistake, you can make the V+
program continue by typing “RETRY n” on the keyboard, where n is the
number of the task that stopped. Typing “PROCEED n” will also resume
program execution, but the aborted vision instruction will not be retried.
*Vision calibration not successful*
584
–6215
Explanation:
The vision calibration cannot complete successfully.
User action:
Restart the calibration process and make sure to read all messages and
popups as you go.
Alphabetical List
*Vision could not locate object*:
–6051
Explanation:
A vision operation that locates objects has failed. The name of the vision
record is shown.
User action:
Check that the scene is correct and that the camera and lighting are adjusted
properly. Check that the parameters for the vision operation are correct.
–713
*Vision not calibrated*
Explanation:
A vision command was entered that required the vision system to be
calibrated, and the vision system is not calibrated.
User action:
Calibrate the vision system or load calibration data from a disk file.
–701
*VISION not enabled*
Explanation:
A vision command was entered before the vision system has been enabled.
User action:
Enter an ENABLE VISION command and retry the previous command.
–6204
*Vision operation failed*
Explanation:
The vision operation was not successful for some reason, which may
depend on the type of operation. A common example is when a feature
(such as a line or a point) is required, but was not found or computed
successfully.
User action:
Check the positions of finders or other sources involved in the evaluation of
the current vision operation.
*Vision operator off screen*
–6205
Explanation:
An attempt has been made to perform a vision operation that is partially or
completely out of the camera image. No valid vision data is available from
this operation. Either the vision operator is specified incorrectly, the wrong
camera is referenced, or the camera calibration is incorrect.
User action:
Check the position of the vision operation, including any reference frames.
Check that the correct camera is specified and that its calibration is valid.
–720
*Vision option not installed*
Explanation:
During initialization, the V+ system failed to detect the presence of the
vision processor. No vision instructions or commands will be accepted.
Otherwise, V+ will operate normally.
User action:
Check to make sure that the vision processor is installed and that your
software supports vision. Power down the controller and restart. If the
*Vision picture frames not coplanar*
–6206
Explanation:
An attempt has been made to perform a vision operation that uses results
from two different pictures whose reference frames (as calibrated) are not
coplanar. The vision system does not handle three dimensions.
User action:
Recalibrate the cameras used for those pictures, being careful to have a
single plane of view.
585
*Vision server not initialized*
Explanation:
The vision server has received a request to perform some vision operation
before a vision database has been assigned.
User action:
Check that the module assigned to the vision server has a vision database
as a member. Verify that the runtime scheduler routine has assigned a
module to the vision server.
*Vision statements not allowed*
–2147
Explanation:
An attempt has been made to execute an AIM sequence which contains
vision statements in a context where they are not allowed.
User action:
remove the vision statements.
*Vision system already in use*
–6218
Explanation:
The vision system used by this vision database is already actively in use by
another runtime task. There can only be one vision runtime task going for
each vision system at one time.
User action:
Select a different sequence to run (which uses a different vision system) or
wait until the active sequence is through.
*Vision system out of memory*
–733
Explanation:
The vision system has run out of free memory for the last operation
attempted. This message should not be confused with “*[Vision error] Out
of memory*”. This error does not disable the vision switch and is always
returned in direct response to the last vision instruction.
User action:
Reduce the complexity of the image or reduce the number of models in
memory. If the problem persists, contact Adept Field Service.
4007
Waiting for:
Explanation:
This is a trace message displayed while in walk-through training. It
indicates that the runtime is waiting for the specified digital I/O signal to
become TRUE.
User action:
None required.
–4000
Waiting to start execution
Explanation:
The runtime has started in walk-through training mode and has paused
waiting for an operator response.
User action:
Respond with “Proceed” to continue runtime execution, or with “Abort
Execution” to stop runtime execution.
*Warning* Watchdog timer disabled
Explanation:
586
–6219
56
Displayed at start-up by all CPUs if the watchdog timer on the board is
disabled. For Adept CPUs, the timer is enabled by removing a jumper. This
timer is a hardware device which asserts SYSFAIL on the VME bus (which
drops robot power) if the CPU halts or gets hung. On the Adept 030 board,
the green light goes out if SYSFAIL is asserted. This message also is
Alphabetical List
displayed whenever a user task is started from the monitor and the
watchdog timer is disabled.
User action:
Replace the watchdog timer jumper. See the Adept MV Controller User’s
Guide.
*Warning* D.b. contains non-unique primary sort field values
2050
Explanation:
During a database sorting operation, at least two records were found to
contain the same value in the primary sort field and the field value must be
a unique. For most databases, this error will occur when two or more
records have been assigned the same name.
User action:
Edit the database and change one of the records that contains a duplicate
primary sort field (for example, rename the record).
*Warning* D.b. time postdates current time
2051
Explanation:
During the scanning of a database, a date and time associated with the
database was found to be in the future according to the current system date
and time. Most likely the system date and time was set incorrectly when the
database was last accessed or the system date and time are now set
incorrectly.
User action:
Check the current system date and time and correct them if they are
incorrect. If the date and time associated with the database were incorrect,
no action is required since AIM automatically resets any postdates it
encounters.
*Warning* IGES part not in Part database
–2221
Explanation:
The IGES file contains a part that is not present in the Part database. Only
parts in the Part database can be extracted from the IGES file and inserted
into the AIM databases.
User action:
If a desired part is not being extracted from the IGES database, append it to
the Part database and invoke the IGES Converter again. (Conversely, you
may delete any parts from the Part database that are not intended to be
extracted.)
*Warning* Monitoring watchpoint
Explanation:
Program execution has begun while a watchpoint is set.
User action:
None. This is an informational message. You may want to disable the
watchpoint to eliminate its slowing down of program execution.
55
51
*Warning* Not calibrated
Explanation:
The robot servo system and joint position sensors are not calibrated. Thus,
any location variables that are defined may not represent the locations
desired.
User action:
Enter a CALIBRATE command or have your program execute a
CALIBRATE instruction.
587
52
*Warning* Protected and read-only programs are not stored
Explanation:
A STORE command has been executed while protected and/or read-only
programs are loaded in the V+ system memory. The protected and readonly programs are not stored in the new disk file.
User action:
Use the FCOPY command if you want to move read-only programs from
one disk to another. Protected programs cannot be moved from one disk to
another.
2052
*Warning* Reduced monitor speed will affect AIM motions
Explanation:
The monitor-controlled motion speed is currently set to a value less than
100. Since AIM assumes the monitor speed is set to 100, robot motions
executed by AIM may not be performed at the proper speed.
User action:
If the monitor speed was intentionally set low, simply continue program
execution. Otherwise, reset the speed by executing the command “SPEED
100” in the Monitor window.
54
*Warning* SET.SPEED switch disabled
Explanation:
A PRIME operation has been performed from the manual control pendant
while the SET.SPEED system switch is disabled. Therefore, the monitor
speed specified in the PRIME command has no effect.
User action:
If you want the PRIME command to change the monitor speed, enter the
command “ENABLE SET.SPEED” at the keyboard.
18
Watchpoint changed at (task) program_name, step n. ...
Explanation:
User action:
*Wrong d.b. field type for get/put*
–2012
Explanation:
An attempt was made to read or write a field of the record currently open
using an incorrect data type.
User action:
Check that the right field is being accessed, and that the correct database
number was specified.
–521
*Wrong disk loaded*
Explanation:
The diskette in a disk drive has been changed while a file was still open.
Further attempts to access the file result in this error. Data being written
into the file may be lost.
User action:
Check your diskette to see if any data was lost. If so, it’s too late now. Be
more careful in the future.
4500
Zeroing force sensor
588
Explanation:
This is a trace message indicating that the force sensor is being zeroed.
User action:
None required.
Numerical List
C.2
Numerical List
This section lists all the AIM messages by their numeric code. (The list includes the V+ error
messages for which AIM global variables are defined [error codes from −407 to −803]. Refer to the
V+ Language Reference Guide for explanations of those error messages.)
The following information is provided for each message:
1. Message code number (all are decimal numbers)
2. Name of the AIM global variable (if any) used to reference the message code
3. Text of the message
Code #
Global Variable
Message
4500
ec.zero.sensor
Zeroing force sensor
4035
ec.mque.out
Out-of-range conveyor queue object:
4034
ec.mque.lock
Lost busy conveyor queue object:
4033
ec.mque.rej
Rejected item from conveyor queue:
4032
ec.mque.done
Done with conveyor queue object:
4031
ec.mque.get
Using conveyor queue object:
4030
ec.mque.put
Added new conveyor queue object:
4020
ec.loop.cnt
Loops remaining:
4014
ec.vop.start
Starting operation:
4013
ec.mve.cam
Moving to vision location:
4012
ec.vop.info
Marking as done (info only):
4011
ec.vop.skip
Skipping operation (sources not done):
4010
ec.vop.exe
Performing operation:
4008
ec.assert.sig
Asserting signal:
4007
ec.wait.sig
Waiting for:
4005
ec.mve.path
Moving along:
4004
ec.mve.part
Moving to:
4003
ec.chg.tool
Changing tool to:
4002
ec.nul.tool
Setting tool to NULL
4001
ec.acc.feed
Accessing:
4000
ec.acq.part
Acquiring:
2106
Abort runtime
589
Code #
Global Variable
Message
2105
Skip sequence
2104
Skip statement
2103
Retry statement
2102
Skip action
2101
Retry action
2100
ec.err.resp.0
Proceed
2054
ec.bk.choice
Choice already used
2053
ec.bk.next.vol
Insert next volume
2052
ec.reduced.spd
*Warning* Reduced monitor speed will affect AIM motions
2051
ec.bad.db.time
*Warning* D.b. time postdates current time
2050
ec.dup.sort.val
*Warning* D.b. contains non-unique primary sort field values
2025
ec.stop.imm
Stopped execution
2024
ec.stop.move
Stopped at end of operation
2023
ec.stop.act
Stopped at end of action
2022
ec.stop.seq
Stopped at end of cycle
2021
ec.stop.stm
Stopped at end of statement
2010
ec.seq.comp
Completed sequence:
2009
ec.seq.start
Started sequence:
2008
ec.avg.cyc.tim
Average cycle time (secs):
2007
ec.ins.fail.m
Part insertion failed at:
2006
ec.part.rej
Rejected:
2005
ec.empty.feed
Empty:
2004
ec.asm.rej
Rejected assembly:
2003
ec.asm.comp
Completed assembly:
2002
ec.asm.start
Started assembly:
2001
ec.exe.stop
Execution stopped
2000
ec.exe.start
Execution started
56
*Warning* Watchdog timer disabled
55
*Warning* Monitoring watchpoint
54
*Warning* SET.SPEED switch disabled
53
*Protected program*
590
Numerical List
Code #
Global Variable
Message
52
*Warning* Protected and read-only programs are not stored
51
*Warning* Not calibrated
50
ec.wrndry
Executing in DRY.RUN mode
18
Watchpoint changed at (task) program_name, step n. ...
17
Breakpoint at (task) program_name, step n
16
*Input error* Try again:
15
Program HOLD
11
Change?
10
Are you sure (Y/N)?
9
(PAUSED)
8
(HALTED)
4
Program task # stopped at program_name, step step_number
date ti
3
Program completed
0
Step syntax MUST be valid
−300
*Illegal monitor command*
−301
*No program specified*
−302
*DO not primed*
−303
*Keyswitch not set to TERMINAL*
−304
*Keyswitch not set to PENDANT*
−305
*Storage area format error*
−307
ec.prog.no.x
*Program not executable*
−308
ec.prgilk
*Program interlocked*
−309
*Program already exists*
−310
*Can’t access protected or read-only program*
−311
*Invalid when program task active*
−312
*Can’t start while program running*
−313
*Can’t go on, use EXECUTE or PRIME*
−314
*Switch can’t be enabled*
−315
*Invalid software configuration*
−316
*Software checksum error*
591
Code #
Global Variable
Message
−317
*Keyswitch not set to NETWORK*
−318
*Program task not active*
−319
*Program task not in use*
−350
*Can’t delete .PROGRAM statement*
−351
*First statement must be .PROGRAM*
−352
*Invalid in read-only mode*
−353
*No other program referenced*
−354
*Line too long*
−355
*Can’t exit while lines attached*
−356
ec.not.found
*Not found*
−357
*Recursive macros illegal*
−358
*Cancelled*
−359
*Illegal in debug monitor mode*
−360
*Must be in debug mode*
−361
*Can’t change modes while task running*
−362
*Can’t execute from SEE program instruction*
−363
*Unknown editor command*
−364
*Can’t create program in read-only mode*
−365
*Illegal in read-write mode*
−366
ec.ponstk
−380
*Invalid when program on stack*
*Breakpoint not allowed here*
−400
ec.abort
Aborted
−401
ec.undval
*Undefined value*
−402
ec.badnum
*Illegal value*
−403
*Illegal assignment*
−404
ec.badarr
*Illegal array index*
−405
ec.badsig
*Illegal digital signal*
−406
ec.undnam
*Undefined program or variable name*
−407
ec.illarg
*Invalid argument*
−408
−409
592
*Program argument mismatch*
ec.arith.ovr
*Arithmetic overflow*
Numerical List
Code #
Global Variable
Message
−410
*Negative square root*
−411
*Not enough storage area*
−412
ec.mislbl
*Branch to undefined label* Step nnn
−413
*Not enough program stack space*
−414
*Can’t mix MC & program instructions*
−416
*String variable overflow*
−417
*String too short*
−418
ec.illmem
*Illegal memory reference*
−419
*Illegal when command program active*
−420
*Undefined value in this context*
−421
*Program not on top of stack*
−422
*Function already enabled*
−423
*Illegal operation*
−424
*Unknown keyword*
−425
*Calibration program not loaded*
−426
*Can’t find calibration program file*
−450
ec.badlin
*Can’t interpret line*
−451
ec.unexp.text
*Unexpected text at end of line*
−452
*Unknown instruction*
−453
*Ambiguous name*
−454
ec.noargu
−455
−456
*Invalid program or variable name*
ec.badnfm
−457
−458
*Missing argument*
*Invalid number format*
*Reserved word illegal*
ec.synerr
*Illegal expression syntax*
−459
*Missing parenthesis*
−460
*Missing quote mark*
−461
*Invalid format specifier*
−462
*Unknown function*
−463
*Invalid statement label*
−464
ec.duplbl
*Duplicate statement label*
593
Code #
Global Variable
Message
−465
ec.badtyp
*Variable type mismatch*
−466
*Illegal use of belt variable*
−467
*Illegal .PROGRAM statement*
−468
*Duplicate .PROGRAM arguments*
−469
*Attempt to redefine variable type* variable_name
−470
*Attempt to redefine variable class* variable_name
−471
*Misplaced declaration statement*
−472
*Control structure error* Step step_number
−473
ec.badcond
*Control structure error* Step nnn
−474
*Too many array indices*
−475
*Missing bracket*
−476
*Invalid qualifier*
−477
**Ambiguous AUTO invalid*
−500
ec.iefilx
*File already exists*
−501
ec.ienexf
*Nonexistent file*
−502
*Illegal I/O device command*
−503
*Device full*
−504
ec.ieeof
*Unexpected end of file*
−506
ec.iefao
*File already open*
−507
−508
*I/O communication error*
ec.iebsy
−509
−510
*Directory error*
ec.iechk
−511
−512
*Device not ready*
*Data checksum error*
*Input block error*
ec.iefmt
−513
*File format error*
*File not opened*
−514
ec.iefbn
*File or subdirectory name error*
−515
ec.ieala
*Already attached to logical unit*
−516
ec.ienat
*Not attached to logical unit*
−517
*I/O queue full*
−518
*Illegal I/O channel number*
594
Numerical List
Code #
Global Variable
Message
−519
*Driver internal consistency error*
−520
*Invalid disk format*
−521
*Wrong disk loaded*
−522
*Data error on device*
−523
*Bad block in disk header*
−524
*Communications overrun*
−525
*Illegal I/O redirection specified*
−526
ec.nod
−527
*No data received*
*Illegal user LUN specified*
−528
ec.ieirl
*Illegal record length*
−529
ec.ieovr
*Output record too long*
−530
−531
*Protection error*
ec.ietmo
*Communication time-out*
−532
*Out of I/O buffer space*
−533
*Invalid hardware configuration*
−534
*Network restarted remotely*
−535
*Network closed locally*
−536
*Too many network errors*
−537
*Unknown network node*
−538
*Network node off line*
−539
*No matching connection*
−540
*Invalid connection specified*
−541
*Invalid network protocol*
−542
*Network not enabled*
−543
*Illegal when network enabled*
−544
*Not configured as accessed*
−545
*Nonexistent subdirectory*
−546
*Subdirectory list too long*
−547
*Subdirectory in use*
−548
*Illegal while protocol active*
−549
*Out of graphics memory*
595
Code #
Global Variable
Message
−550
*Too many windows*
−551
*Font not loaded*
−552
*Graphics processor timeout*
−553
ec.iemarg
*Too many arguments*
−554
*Too many closeable windows*
−555
*Graphics storage area format error*
−556
*Too many icons*
−557
*Can’t create new slide bar*
−558
*Graphics software checksum error*
−559
*Out of network resources*
−560
*Invalid network resource*
−561
*Invalid network address*
−562
*Network timeout*
−563
*Remote has not exported network resource*
−564
*Network resource name conflict*
−600
*Stopped due to servoing error*
−601
ec.robnat
−602
*Robot not attached to this program*
*Robot already attached to program*
−603
ec.iencmp
*COMP mode disabled*
−604
ec.nohpwr
*Robot power off*
−605
ec.notcal
*Robot not calibrated*
−606
*Joint 1 in brake track or robot overheated*
−607
*No air pressure*
−608
*External E-STOP*
−609
*Illegal joint number*
−610
ec.outrng
*Location out of range*
−611
ec.slonly
*Must use straight-line motion*
−612
ec.cancfg
*Straight-line motion can’t alter configuration*
−613
*Illegal motion from here*
−614
*Attempt to modify active belt*
−615
596
ec.nobelt
*Belt not enabled*
Numerical List
Code #
Global Variable
Message
−616
ec.winerr
*Belt window violation*
−617
−618
*Belt servo dead*
ec.ltocls
−619
*Location too close*
*Invalid orientation*
−621
ec.ierin
*Robot interlocked*
−622
ec.norobt
*No robot connected to system*
−623
*Stop-on-force triggered*
−624
*Force protect limit exceeded*
−625
ec.invsdt
*Invalid servo initialization data*
−626
*Can’t ALTER and track belt*
−627
*Robot power on*
−628
*Robot module not loaded* ID: n
−629
*SYSFAIL asserted*
−630
*Motion interface E-STOP*
−631
*Controller overheating*
−632
*Power failure detected by robot*
−633
*PANIC command*
−635
*Cartesian control of robot not possible*
−636
*Trajectory clock overrun*
−637
*Illegal while joints SPIN’ing*
−638
*SPIN motion not permitted*
−639
*Manual brake release*
−640
*E-STOP from robot*
−641
*E-STOP from amplifier*
−642
*E-STOP from SYSFAIL*
−643
*E-STOP from backplane*
−650
ec.mcpfail
*Manual control pendant failure*
−651
*RSC communications failure*
−652
*RSC reset*
−653
*RSC time-out*
−654
*RSC transmission garbled*
597
Code #
Global Variable
Message
−655
*V+ *RSC bad packet format*
−656
*RSC calibration load failure*
−658
*Device hardware not present*
−659
*Device time-out*
−660
*Device error*
−661
*NVRAM data invalid*
−662
*Device sensor error*
−663
*Device reset*
−665
*NVRAM battery failure*
−666
*Must use CPU #1*
−666
*Must use Monitor #1*
−667
ec.powerf
*Power failure detected*
−668
ec.devinu
*Device in use*
−669
*RSC hardware failure*
−670
*RSC power failure*
−671
*Servo board 12V fuse open*
−672
*Servo board solenoid fuse open*
−673
*Servo board E-Stop fuse open*
−674
*Servo task overloaded*
−675
*Timeout enabling power*
−676
*RSC module ID doesn’t match robot*
−701
ec.novis
*VISION not enabled*
−702
*No prototypes*
−703
*Too many vision requests pending*
−704
ec.noobj
−705
*No objects seen*
*Camera not running*
−706
ec.camrun
*Invalid request while camera running*
−707
ec.unkpro
*Unknown prototype*
−710
*Camera disconnected*
−712
ec.maxpro
*Maximum number of prototypes exceeded*
−713
ec.vnotcal
*Vision not calibrated*
598
Numerical List
Code #
Global Variable
Message
−714
*Camera already running*
−717
*Not enough prototype storage area*
−718
ec.protadf
−719
−720
*Duplicate prototype name*
*Camera already off*
ec.vinins
*Vision option not installed*
−721
*Bad grip definition*
−722
*Camera interface board absent*
−723
ec.nppd
*No picture data available*
−726
ec.bad.vcal
*Bad camera calibration*
−727
ec.inv.xy
*Invalid vision X/Y ratio*
−728
*Image processing board failure*
−729
*Invalid request while vision training*
−730
ec.ninf
*Information not available*
−731
*Unknown subprototype*
−732
*Invalid model name*
−733
*Vision system out of memory*
−734
*Can’t open vision window for read/write*
−735
ec.illvarg
*Invalid vision argument*
−736
ec.fontndf
*Font not defined*
−737
ec.fontadf
*Font already defined*
−738
ec.inclfont
*Font not completely trained*
−739
*Maximum number of samples trained*
−740
*Duplicate character in font*
−741
*Invalid character in font*
−742
ec.nfontch
*Character not in font*
−743
ec.regbig
*Region too big*
−744
−745
*Region too complicated*
ec.xpchars
−746
*Expected character(s) not found*
*Template of uniform intensity*
−747
ec.tmplndef
*Template not defined*
−748
ec.tmpladf
*Template already defined*
599
Code #
Global Variable
Message
−749
ec.vis.abo
*Vision aborted*
−750
ec.mixing.res
*Mixing half and full resolutions*
−751
ec.no.vis.sel
*No vision system selected*
−754
ec.tmpl.toobig
*Correlation template too big*
−755
*Data overflow*
−756
*A scratch Frame store is needed (use VSELECT)*
−800
*Unknown error code*
−801
*Invalid VFEATURE access*
−802
ec.camcal
*Invalid camera calibration*
−803
ec.illcam
*Illegal camera number*
−804
ec.ienopt
*Option not installed*
−805
*Hardware not in system*
−859
*Database manager internal error*
−1001
*Invalid servo error* Mtr n
−1002
ec.jlimit
*Position out of range* Jt n
−1003
*Time-out nulling errors* Mtr n
−1004
*No zero index* Mtr n
−1005
*Unexpected zero index* Mtr n
−1006
*Envelope error* Mtr n
−1007
*Motor stalled* Mtr n
−1008
*Encoder quadrature error* Mtr n
−1009
*Timeout enabling amplifier* Mtr n
−1010
*Invalid error code* Belt n
−1011
*No zero index* Belt n
−1012
*Unexpected zero index* Belt n
−1013
*Encoder quadrature error* Belt n
−1014
*[Fatal] Initialization failure* Mtr n
−1015
*Initialization failure* Belt n
−1016
*Motor overheating* Mtr n
−1017
*Motor power failure* Mtr n
−1018
*Motor amplifier fault* Mtr n
600
Numerical List
Code #
Global Variable
Message
−1019
−1020
−1021
*Duty-cycle exceeded* Mtr n
−1022
*Skew envelope error* Mtr n
−1023
*Position out of range* Mtr n
−1025
*Encoder fault*
−1026
*Software incompatible* Code n
−1101
*[Fatal] Servo process dead* CPU n
−1102
*[Fatal] Servo code incompatible* CPU n
−1103
*[Fatal] Servo checksum error* CPU n
−1104
*[Fatal] Servo dead* Mtr n
−1105
*Motor start-up failure* Mtr n
−1106
*Calibration sensor failure* Mtr n
−1107
*[Fatal] Servo init failure* Board n
−1200
*NFS error* Code n
−1299
*NFS error* Code n
−2001
db.inv.db.num
*Invalid d.b. number*
−2002
db.not.open
*D.b. not open*
−2003
db.no.db.file
*D.b. file not found*
−2005
db.no.lun
*No available LUNs for d.b.*
−2006
db.already.open
*D.b. number already in use*
−2007
db.bad.version
*Incompatible d.b. version*
−2008
db.not.mem.res
*D.b. not memory resident*
−2009
db.read.only
*D.b. is read-only*
−2010
db.no.field
*No such d.b. field name*
−2011
db.inv.fnum
*Invalid d.b. field number*
−2012
db.bad.type
*Wrong d.b. field type for get/put*
−2013
db.no.data
*No valid data in d.b. field*
−2014
db.bad.range
*D.b. numeric value not in range*
−2015
db.inv.index
*Invalid d.b. array index*
−2016
db.bad.rec.size
*Incompatible record size*
601
Code #
Global Variable
Message
−2020
db.no.such.rec
*No such d.b. record*
−2021
db.no.match
*D.b. search failed to find match*
−2022
db.no.open.rec
*No d.b. record currently open*
−2040
db.no.memory
*Not enough memory available*
−2041
db.no.more.recs
*No more records allowed*
−2042
db.inv.name
*Invalid name*
−2050
du.cant.chg.def
*D.b. must be empty to change definition*
−2051
du.dup.sort.spc
*Duplicate sort field specified*
−2052
du.dup.fld.name
*Duplicate field name specified*
−2053
du.already.set
*D.b. is the currently selected d.b.*
−2100
ec.no.free.db
*Allocated databases all in use*
−2101
ec.und.data
*Undefined referenced data record*
−2102
ec.uns.arg
*Unspecified required statement argument*
−2103
ec.unk.arg
*Unknown statement argument type*
−2104
ec.unk.stmt
*Unknown statement*
−2105
ec.uns.rec
*Unspecified required record name*
−2106
ec.unl.sbr
*Referenced V+ routine not loaded*
−2107
ec.nxe.sbr
*Referenced V+ routine not executable*
−2108
ec.uns.sbr
*Unspecified required string value*
−2109
ec.und.frame
*Undefined global reference frame*
−2110
ec.no.loaded
*Required database not loaded*
−2111
ec.ill.lk.db
*Illegal d.b. specified in link rule*
−2112
ec.cir.link
*Circular linking relationship illegal*
−2113
ec.opt.ill
*Optional argument can’t be specified*
−2114
ec.cant.unl
*Can’t unload executing database*
−2115
ec.link.bad
*Link operation failed*
−2116
ec.inv.db.name
*Invalid d.b. name*
−2117
ec.dup.db.name
*D.b. name already in use*
−2118
ec.rec.sequence
*Records not sequential*
−2119
ec.ill.ref.num
*Illegal number of reference frames*
−2120
ec.cond.nest
*Conditional statements nested too deeply*
602
Numerical List
Code #
Global Variable
Message
−2121
ec.1.picture
*Must have exactly one picture*
−2122
ec.cant.unl.ed
*Can’t unload database being edited*
−2123
ec.prep.fail
*Runtime preprocessing failed*
−2124
ec.inc.arg
*Inconsistent arguments*
−2125
ec.ill.seq.run
*Illegal while sequence running*
−2126
ec.io.win.err
*Can’t open window*
−2127
ec.no.menu.pg
*Can’t find specified menu page*
−2128
ec.err.err
*Can’t generate error popup*
−2129
ec.req.no.def
*Required value not defined*
−2130
ec.rtn.not.exc
*Menu spawn routine not executable*
−2131
ec.ck.rtn.err
*Menu check routine not executable*
−2132
ec.ill.mnu.opr
*Illegal function on this page*
−2133
ec.mu.rec.err
*Can’t open menu record* menu, db, record, error:
−2134
ec.no.access
*Insufficient access level*
−2135
ec.ill.seq.act
*Illegal while sequence active*
−2136
ec.not.authoriz
*Invalid user name or password*
−2137
ec.no.seq.sel
*No sequence selected*
−2138
ec.ill.search
*Only searches for d.b. values allowed*
−2139
ec.dup.name
*Name already exists*
−2140
ec.no.help
*No help available*
−2141
ec.bad.retrieve
*Retrieve failed, can’t write name*
−2142
ec.no.change
(no message or popup is generated)
−2143
ec.not.moded
*Module has not been modified*
−2144
ec.st.not.run
*Runtime statements not allowed*
−2145
ec.st.not.opr
*Operator control statements not allowed*
−2146
ec.st.not.move
*Motion statements not allowed*
−2147
ec.st.not.vis
*Vision statements not allowed*
−2148
ec.st.not.io
*I/O statements not allowed*
−2149
ec.mod.db.req
*D.b. must be a module member*
−2150
ec.hps.no.robot
*HPS data file for wrong robot*:
−2200
ec.db.not.att
*No d.b. attached*
603
Code #
Global Variable
Message
−2201
ec.rec.not.sel
*No record selected*
−2202
ec.unter.stg
*Unterminated string*
−2203
ec.unk.adx.cmd
*Unknown ADX command*
−2204
ec.unk.data.typ
*Unknown data type*
−2220
ec.bad.iges.fil
*Bad IGES file format*
−2221
ec.no.iges.part
*Warning* IGES part not in Part database
−2222
ec.bad.iges.tpl
*No known part-moving statement in IGES.TEMPLATE*
−2223
ec.inv.iges.trn
*Invalid IGES transformation form*
−2224
ec.bk.rest.vol
*Incorrect restore source volume*
−2225
ec.bk.bad.state
*Invalid backup/restore operation*
−2226
ec.bk.not.idle
*Cannot shutdown. Backup/Restore still active*
−2227
ec.bk.no.files
*No files to backup/restore*
−2228
ec.bk.mismatch
*Mismatch in controller model/serial ID*
−2229
ec.bk.bad.bkd
*Not a valid backup saveset file*
−2230
ec.bk.version
*Incompatible backup version*
−2231
ec.bk.limit
*Backup limit exceeded*
−2232
ec.bk.kermit
*Kermit server not in binary mode*
−2250
ec.unk.msg.dst
*Unknown message destination*
−2251
ec.run.lock
*Runtime execution interlocked*
−2252
ec.unk.device
*Unknown device specified*
−2253
ec.ill.task
*Invalid program task*
−2254
ec.prog.err
*V+ programming error*
−2255
ec.ext.panel
*External control panel enabled*
−2256
ec.no.multi
*Multiple AIM systems not supported*
−2257
ec.no.remote
*Remote AIM system not ready*
−2258
ec.bad.task
*Invalid runtime task specified*
−2259
ec.tmo.task
*Timeout waiting for task to start*
−2260
ec.seq.nest
*Sequence calls nested too deeply*
−2261
ec.no.task
*No V+ task available*
−2270
ec.md.format
*Module file format error*
−2271
ec.md.ice
*Module data inconsistent*
604
Numerical List
Code #
Global Variable
Message
−2272
ec.md.load
*Module not loaded*
−2273
ec.md.no.mod
*Module not found*
−2274
ec.md.no.seq
*Sequence not found*
−2276
ec.md.mod.ref
*Module in use*
−2277

AIM Customizer`s Reference Guide

Transcription

Similar documents

View our Events Brochure

Untitled - CooGiE`s Cafe Santa Monica

ZAGWEB – Registration and Payment for Classes

YES, WE ARE OPEN ON NEW YEAR`S DAY!

Step # 13 Open up TMPGEnc 4.0 Express and click on “Start a new

Boi na Braza - Downtown Cincinnati Restaurant Association

Galway Advertiser – A Very Tasty Diversion

- La Gentilhommière

Active Listening Guide: