|
DataMuseum.dkPresents historical artifacts from the history of: CP/M |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about CP/M Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - download
Length: 98432 (0x18080)
Types: TextFile
Names: »D87«
└─⟦e634bf8f4⟧ Bits:30005867/disk11.imd Dokumenter (RCSL m.m.)
└─⟦this⟧ »D87«
\f
i
T_A_B_L_E_ _O_F_ _C_O_N_T_E_N_T_S_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_
1. INTRODUCTION ........................................... 1
2. STANDARD INSTALLATION .................................. 2
3. KEYBOARD ............................................... 4
4. SCREEN CONTROL ......................................... 6
5. PRINTERS ............................................... 7
A_P_P_E_N_D_I_C_E_S_:
A. REFERENCES ............................................. 9
B. FUNCTION KEYS .......................................... 10
\f
F_ 1_._ _ _ _ _ _ _ _ _I_N_T_R_O_D_U_C_T_I_O_N_ 1.
The present release of the WordStar 3.0 text processing system
has been adapted specially for use on your RC855 Work Station.
WordStar runs under the control of the CP/M operating system. It
is assumed that CP/M has been installed on your RC855 Work Sta-
tion and that you are familiar with the basic CP/M procedures.
The WordStar package you have received contains the following ma-
terials:
- This manual: "WordStar for the RC855 Work Station, Instal-
lation Guide".
- MicroPro's documentation of WordStar including:
"WordStar, General Information Manual"
"WordStar, Reference Manual"
"WordStar, Installation Manual".
- A diskette containing the WordStar system.
Do not write on the original distribution diskette as it is your
master copy and last resort in case of errors.
\f
F_ 2_._ _ _ _ _ _ _ _ _S_T_A_N_D_A_R_D_ _I_N_S_T_A_L_L_A_T_I_O_N_ 2.
Start by making a copy of the original WordStar distribution
diskette - for details concerning copying see ref. 1, BACKUP
(all references are listed in appendix A of this manual). After
the copy has been made, proceed step by step as follows:
1) Transfer all WordStar files to a CP/M system diskette by means
of CP/M command PIP or TRANSFER (the use of PIP and TRANSFER
is explained in ref. 1).
2) When you again see the CP/M prompt symbol (A> or B>) on the
display, type
INSTALL
and then press the RETURN key (marked on the RC855
keyboard).
3) At the bottom of the display you should now see a question
asking you to answer Y (for "yes") or N (for "no"). PLEASE
DO NOT ANSWER THIS OR OTHER QUESTIONS (AND MENUS) UNTIL YOU
ARE EXPLICITLY INSTRUCTED TO DO SO.
4) Now you may answer the question by pressing the key marked
Y. A new text should appear at the bottom of the display. The
new text concludes with an
"OK (Y/N):"
meaning that a Y or N answer is expected. DO NOT ANSWER YET.
5) Answer as you did with the first question by pressing Y.
A new text should appear at the bottom of the display. The
new text concludes with a
"PLEASE ENTER SELECTION (1 LETTER):"
meaning a letter is to be chosen from the menu above.DO NOT
ANSWER YET.
\f
6) Answer by pressing the key marked U. A new text will appear
at the bottom of the display. The new text is the first of 9
questions and menus. Each question concludes with the text "OK
(Y/N):", and each menu concludes with the text "PLEASE ENTER
SELECTION (1 LETTER):".
7) Starting with the text currently at the bottom of the
display, answer Y each time a new question appears and U each
time a new menu appears. CONTINUE TO ANSWER Y OR U UNTIL NO
NEW QUESTION OR MENU APPEARS. At this point WordStar should
start automatically, and after a few seconds you should see a
WordStar menu with the heading:
<<< NO - FILE MENU >>>
If you do not see this menu, perform a soft or hard boot and
start again with step 2.
8) Installation of the standard WordStar system is now complete.
You may now either:
a) proceed to use WordStar
or
b) return to CP/M by pressing X.
\f
F_ 3_._ _ _ _ _ _ _ _ _K_E_Y_B_O_A_R_D_ 3.
Installed as described above, WordStar enables you to use the
standard keys on the keyboard, i.e. all alphabetic, numeric and
special characters. However, you may also wish to make use of the
special function keys included on the RC855 keyboard (see ap-
pendix B for a list of these). To do so you must first perform
the following supplementary procedure:
If WordStar is waiting for a command, exit to CP/M by typing X.
When you see the CP/M prompt (e.g. A>), type
EXTEND WS
(Note: if your WordStar command file has some other name than WS,
type that name instead of WS). Press the RETURN key.
You have just executed the program EXTEND making it possible for
you to use the special RC855 function keys with WordStar.
When the CP/M prompt reappears on the screen, you can restart
WordStar by typing
WS
and then pressing the RETURN key.
It is now possible to use the special function keys with
WordStar, however please note the following points:
- After EXTEND has been executed - and only then - an error in
WordStar 3.0 may cause WordStar to break down after the
following sequence of entries:
E_N_T_R_Y_ _ _ _ _ _ _ _ _ _ _ _ _ C_O_M_M_E_N_T_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
R WordStar's run-a-program command
CTRL-U This cancels previous command
<do anything> Any WordStar command
X Exit-from-WordStar command
\f
The problem may be remedied by replacing CTRL-U in the se-
quence above with the name of a small (dummy) program, e.g.
STAT.
- For each installation of WordStar, EXTEND may be executed
once and only once.
\f
F_ 4_._ _ _ _ _ _ _ _ _S_C_R_E_E_N_ _C_O_N_T_R_O_L_ 4.
The headings and menues of the standard system are displayed in
the form of inverted and underlined text. For further information
about attributes please see ref. 1, appendix B.
The standard screen options can be changed by patching the sys-
tem. For further information about patching, please see ref. 2.
\f
F_ 5_._ _ _ _ _ _ _ _ _P_R_I_N_T_E_R_S_ 5.
The WordStar system is provided with a set of printer options
which make it possible to use almost any type of printer.
You may choose the standard option by selecting U from the
printer menu during installation (as described in chapter 2 of
this manual). If, on the other hand, you wish to choose an
alternative printer option, then please note the following
points:
- The printer chosen may make special demands on the communi-
cations protocol and/or the printer driver. Please check
ref. 1 appendix F, ref. 2 chapter 7 and the technical
specifications of the printer.
- The following printers may, however, be used without chang-
ing the printer driver or the communications protocol:
1) OKI 83A, Matrix Printer
2) Qume Sprint 5
3) NEC Spinwriter 7710/772 Thimble Printer
To ensure full utilization of the printer facilities, choose
option U for OKI, F for Qume and G for NEC in the printer
menu. If you choose options F or G, INSTALL will advise you
to select a special communications protocol. Answer by typ-
ing U.
\f
F_
\f
F_ A_._ _ _ _ _ _ _ _ _R_E_F_E_R_E_N_C_E_S_ A.
1 RCSL No 42-i1687:
RC855 Work Station, User's Guide
2 WordStar, Installation Manual (by MicroPro)
\f
F_ B_._ _ _ _ _ _ _ _ _F_U_N_C_T_I_O_N_ _K_E_Y_S_ B.
The table below lists the special function keys on the RC855 key-
board, shows the WordStar function corresponding to each key when
EXTEND has been executed, and finally indicates the equivalent
command key in unextended (standard) WordStar.
M_ R_C_8_5_5_ _F_u_n_c_t_i_o_n_ _k_e_y_ W_o_r_d_S_t_a_r_ _F_u_n_c_t_i_o_n_ C_o_m_m_a_n_d_ _K_e_y_
(Danish) (Standard)
SELECT SELECT = NOT USED =
CLEAR CLEAR = NOT USED =
PA1 PA1 = LINE UP = @Z
PA2 PA2 = LINE DOWN = @W
PA3 PA3 = SCREEN UP = @C
PA4 PA4 = SCREEN DOWN = @R
PA5 PA5 = STOP COMMAND = @U
USM USM = NOT USED =
PF10 PF10 = HELP MENU = @J
PF11 PF11 = BLOCK MENU = @K
PF12 PF12 = ONSCREEN MENU = @O
PF13 PF13 = PRINT MENU = @P
PF14 PF14 = QUICK MENU = @Q
CURSR SELCT CURSR SELCT = NOT USED =
PRINT PRINT = PRINT = @P
TEGN IND INS MODE = INSERT ON/OFF = @V
= CURSOR UP = @E
SLET LINIE DEL LINE = DELETE LINE = @Y
SLET FELT ERASE FIELD = ERASE WORD RIGHT = @T
MARKER MARK = BLOCK OPERATIONS = @K
= CURSOR LEFT = @S
= NOT USED =
= CURSOR RIGHT = @D
SLET DATA ERASE INPUT = DELETE CHAR LEFT = DEL
FLYT MOVE = MOVE BLOCK = V
= LEFT WORD = @A
SLET TEGN DEL CHAR = DELETE CHAR = @G
= CURSOR DOWN = @X
LINIE IND INS LINE = INSERT NEW LINE = @N
FM FM = FORMATTING = @O
DUP DUP = COPY BLOCK = C
ESC ESC = ESCAPE = ESC
= WORD RIGHT (SINGLE KEY) = @F
SEND SEND = CR = CR
= TABULATION (DOUBLE KEY) = @I
RESET RESET = NOT USED =
P_ = CARRIAGE RETURN = CR
\f
i
I_N_D_H_O_L_D_S_F_O_R_T_E_G_N_E_L_S_E_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _S_I_D_E_
1. INDLEDNING ............................................ 1
1.1 Hvad er et overvågningssystem .................... 1
1.1.1 Formål .................................... 1
1.1.2 Generelle krav ............................ 1
1.1.3 Krav til systemets funktion ............... 1
1.2 Overvågningssystemet RC-Proces ................... 2
2. KONFIGURATION ......................................... 4
2.1 Datamatsystem .................................... 5
2.2 Tidsfølgemelderudstyr ............................ 5
2.3 Procesudstyr ..................................... 6
2.4 Digitale ind- og udgange ......................... 7
2.5 Betjeningspladser ................................ 7
2.6 Øvrigt periferiudstyr ............................ 8
3. SIGNALINDSAMLING OG -BEHANDLING ....................... 9
3.1 Instrumentkontrol af analoge signaler ............ 9
3.2 Anlægskontrol af analoge signaler ................ 11
3.3 Behandling af tidsfølgemeldinger ................. 12
3.4 Database og dataindfyldning ...................... 13
4. BETJENINGSPLADSER ..................................... 15
4.1 Farveskærmen ..................................... 15
4.2 Skærmbilleder .................................... 15
4.2.1 Blindskemaer .............................. 16
4.2.2 Alarmtabeller ............................. 18
4.2.3 Tidskurver ................................ 21
4.2.4 Profiler .................................. 22
4.2.5 Stavdiagrammer ............................ 22
4.2.6 Skemabilleder ............................. 23
4.2.7 Billedbygning ............................. 23
\f
ii
I_N_D_H_O_L_D_S_F_O_R_T_E_G_N_E_L_S_E_ _(_f_o_r_t_s_a_t_)_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _S_I_D_E_
5. LAGRING ............................................... 24
5.1 TEM-tabellen ..................................... 24
5.2 Korttidsarkivet .................................. 24
5.3 Langtidsarkivet .................................. 25
5.4 Hændelsesregistrering ............................ 25
5.5 Fejlskriver ...................................... 25
6. RAPPORTERING .......................................... 27
6.1 Driftsøkonomiske rapporter ....................... 27
6.2 Driftstekniske rapporter ......................... 28
6.3 Analyserapporter ................................. 28
7. PROGRAMMELSYSTEM ...................................... 29
7.1 Basisprogrammel .................................. 29
7.2 Front-end programmel ............................. 29
7.3 Monitor .......................................... 29
7.4 File-processor (FP) .............................. 30
7.5 Operativsystemet POPS ............................ 30
7.5.1 Kommunikation mellem anvenderopgaver ...... 30
7.6 Applikationsprogrammel ........................... 31
7.6.1 Periodeadministrator ...................... 32
8. BRUGERPROGRAMMER ...................................... 33
8.1 Anvendelse af farveskærme ........................ 33
8.2 Dataaccess ....................................... 33
8.3 Aksgol ........................................... 34
\f
F_ 1_._ _ _ _ _ _ _ _ _I_N_D_L_E_D_N_I_N_G_ 1.
1_._1_ _ _ _ _ _ _ _H_v_a_d_ _e_r_ _e_t_ _o_v_e_r_v_å_g_n_i_n_g_s_s_y_s_t_e_m_ 1.1
1_._1_._1_ _ _ _ _ _F_o_r_m_å_l_ 1.1.1
Et overvågningssystem har et såvel kortsigtet som langsigtet
formål:
P_å_ _k_o_r_t_ _s_i_g_t_ skal systemet gøre det muligt at kontrollere og evt.
styre den daglige drift af den proces, der overvåges.
P_å_ _l_æ_n_g_e_r_e_ _s_i_g_t_ skal systemet gøre det muligt at optimere driften
med hensyn til udnyttelse af anlæg og ressourcer, der indgår i
processen.
1_._1_._2_ _ _ _ _ _G_e_n_e_r_e_l_l_e_ _k_r_a_v_ 1.1.2
For at et system kan opfylde disse formål, må der stilles følgen-
de generelle krav til det:
a) Systemet skal være pålideligt.
b) Systemet skal være robust over for fejlagtige data eller
fejlbetjening.
c) Systemet skal være fleksibelt med hensyn til udvidelser og
ændringer i programmel og maskinel.
d) Systemet skal give effektiv og hurtig respons på driftsvagtens
kommandoer.
1_._1_._3_ _ _ _ _ _K_r_a_v_ _t_i_l_ _s_y_s_t_e_m_e_t_s_ _f_u_n_k_t_i_o_n_ 1.1.3
Overvågningssystemet må funktionsmæssigt være i stand til at
opfylde følgende:
\f
- løbende opsamle data fra processen.
- afgive alarm ved unormale anlægstilstande.
- fremstille information om anlæggets tilstand for driftsvagten
på en for denne hensigtsmæssig og overskuelig måde.
- løbende foretage beregninger og automatisk generere rapporter
om anlæggets drift.
- generere langtidsarkiver over måleværdier og hændelser med
henblik på senere analyse.
- generere rapporter ud fra arkiverede data, således at anlæggets
drift over en længere periode kan analyseres med henblik på
optimering af driften.
- indpasse nye funktioner i systemet.
1_._2_ _ _ _ _ _ _ _O_v_e_r_v_å_g_n_i_n_g_s_s_y_s_t_e_m_e_t_ _R_C_-_P_r_o_c_e_s_ 1.2
RC-Proces blev udviklet i forbindelse med en overvågningsopgave
på Asnæsværket ved Kalundborg. I de følgende kapitler er eksem-
pelmaterialet hentet fra denne anvendelse. RC-Proces kan dog
udmærket anvendes til andre typer processer end elektricitets-
fremstilling.
Kapitel 2 beskriver det udstyr, som indgår i en typisk RC-Proces
konfiguration, dvs. såvel hoveddatamaten RC8000 som opsamlings-
og kommunikationsudstyr og øvrigt perifert udstyr.
Kapitel 3 beskriver den overvågning, de tilsluttede signaler som
standard kan udsættes for. Overvågningen tjener som kontrol af
såvel indsamlingsapparaturet (instrumentkontrol) som af selve an-
lægget (anlægskontrol). Desuden beskrives, hvordan data, der be-
skriver signalerne indlægges i systemet og tilknyttes de forskel-
lige behandlinger.
\f
Kapitel 4 beskriver kommunikationen mellem driftsvagten og RC-
Proces via farvedataskærme i den daglige drift. Der gives bl.a.
en oversigt over de forskellige billedtyper, der anvendes.
Kapitel 5 beskriver lagring og arkivering af information i
RC-Proces. Den information, der løbende registreres om drifts-
tilstanden, lagres i kortere eller længere tid i forskellige
tabeller og arkiver.
Kapitel 6 beskriver rapporteringsfaciliteten i RC-Proces. Der kan
genereres rapporter af flere forskellige typer ud fra de lagrede
data.
Kapitel 7 giver en oversigt over det programmelsystem, der ligger
til grund for RC-Proces.
Kapitel 8 beskriver nogle værktøjer, der gør det muligt for bru-
geren selv at skrive programmer til RC-Proces og derved udvide
systemet til sit specielle formål.
\f
F_ 2_._ _ _ _ _ _ _ _ _K_O_N_F_I_G_U_R_A_T_I_O_N_ 2.
RC-Proces systemet er baseret på en RC8000 datamat med tilslut-
ning af opsamlingsudstyr, betjeningspladser og andre ydre en-
heder.
Figur 1 viser principskitse for et RC-Proces overvågningssystem
til en større kraftværksblok.
Figur 1: Principskitse \f
F_2_._1_ _ _ _ _ _ _ _D_a_t_a_m_a_t_s_y_s_t_e_m_ 2.1
RC8000 er en middelstor generel datamat. Den består af centralen-
hed med lager og direkte tilkoblede pladelagre. Øvrige ydre en-
heder tilkobles via en eller flere front-end minidatamater
(RC8301). I den viste konfiguration er anvendt 2 front-end data-
mater, hvoraf den ene har tilkoblet betjeningspladser samt tra-
ditionelle ydre enheder, mens den anden varetager opsamling af
analoge måleværdier fra processen samt digitale indgange og ud-
gange.
Centralenheden findes i flere versioner, så kapaciteten kan til-
passes den enkelte installations krav.
2_._2_ _ _ _ _ _ _ _T_i_d_s_f_ø_l_g_e_m_e_l_d_e_r_u_d_s_t_y_r_ 2.2
Tidsfølgemelderen RC7100 har i mange år været i brug på danske
kraftværker og har fremvist en meget høj driftssikkerhed. Under
normale driftsforhold transmitteres meldingerne til edb-anlægget
og udskrives via dette. I tilfælde af driftsstop på RC8000 be-
nyttes tidsfølgemeldernes lokale skrivemaskiner. Tidsfølgemelde-
ren indeholder en skanner, der registrerer tilstandsskift med en
opløsning på 0.5 mS og lagrer disse i rigtig sekvens i en buffer.
Herfra hentes registreringerne en ad gangen af den indbyggede
minidatamat. Denne påfører klokkeslæt fra den interne real-time
clock med en opløsning på 10 mS, hvorefter meldingerne lagres i
en uddatakø. Herfra sendes de enten til RC8000 eller til den
lokale skrivemaskine.
En af tidsfølgemelderens indgange kan benyttes til tilkobling af
et signal fra et ur, som skifter hvert minut. Tidsfølgemelderen
vil da finindstille sit interne ur efter dette signal.
Udskriften på tidsfølgemelderens skrivemaskine kan forsynes med
en frit valgt tekst, der kan indtastes på skrivemaskinen, over-
sendes fra RC8000, eller indlæses fra papirstrimmellæser.
\f
Hver tidsfølgemelder kan forsynes med indtil 1024 digitale ind-
gange. Benyttes flere tidsfølgemeldere, flettes meldingerne i
RC8000 på basis af tidsmærkningen.
Klokkeslæt kan indtastes på tidsfølgemelderens skrivemaskine
eller oversendes fra RC8000 til tidsfølgemelderen.
2_._3_ _ _ _ _ _ _ _P_r_o_c_e_s_u_d_s_t_y_r_ 2.3
Som procestilslutningsudstyr for analoge signaler anvendes CAMAC
udstyr. CAMAC er en internationalt anerkendt standard for elek-
tronisk udstyr, såvel mekanisk som elektrisk, ligesom ind- og
udlæsning af data foregår på standardiseret måde.
Hvor antallet af målepunkter og afstandene i procesanlægget gør
det hensigtsmæssigt kan målepunkterne fordeles på en hovedstation
og en eller flere understationer, som er indbyrdes forbundet ved
hjælp af en seriel databus. Herved undgås at transportere signa-
ler over store afstande, og herved minimeres både kabelom-
kostninger og risiko for overlejring af støj.
A/D-converteren kan programmeres til seks forskellige måleområder
for fuldt udslag fra
19.999 mV til 1999.9 V
Endvidere er der mulighed for programmæssigt at reducere rampe-
tiden til 2 mS mod at reducere opløsningen fra 4 1/2 ciffer til 3
1/2 ciffer.
Signalerne føres til A/D-converterne via relæmultiplexere, så-
ledes at der til hver A/D-converter kan tilsluttes indtil 256
signaler.
\f
2_._4_ _ _ _ _ _ _ _D_i_g_i_t_a_l_e_ _i_n_d_-_ _o_g_ _u_d_g_a_n_g_e_ 2.4
Digitale indgange tilsluttes via DST 701, der indeholder 48 bit
(=12 BCD cifre). Antallet af indgange kan udvides til max. 4096.
Som digital output modul anvendes DOT 701, der indeholder 32 ka-
naler. Antallet af udgange kan udvides til max. 4096.
2_._5_ _ _ _ _ _ _ _B_e_t_j_e_n_i_n_g_s_p_l_a_d_s_e_r_ 2.5
Der kan tilsluttes flere betjeningspladser, der hver består af en
semigrafisk farveskærm, et funktionstastatur og et alfanumerisk
tastatur. Desuden kan der tilsluttes en trackerball for cursor-
positionering.
Farveskærmkontrolleren er af typen ND 680, der indeholder et
tegnsæt på 256 tegn, og farvesættet består af 16 forgrundsfarver
og 8 baggrundsfarver. Såvel tegnsæt som farvesammensætning kan
udskiftes dynamisk. Kontrolleren har RGB udgang, så der kan til-
sluttes en monitor, som har tilsvarende indgange, f.eks. BARCO
type CDCT 2/51.
Funktionstastaturet består af 128 taster, der bruges til billed-
valg, igangsætning af specielle funktioner, og til cursorpositio-
nering. Tasterne er forsynet med lys, der kan styres programmæs-
sigt.
Det alfanummeriske tastatur, RC812, er et sædvanligt alfanumme-
risk tastatur (skrivemaskinetastatur) suppleret med enkelte
funktionstaster.
Med en videokopienhed (Tektronix type 4632) kan tages sort/hvide
kopier af skærmbilleder ved tilslutning til skærmens videoudgang.
Videokopienheden kan samtidig tilsluttes indtil 4 skærme, og kan
styres manuelt eller programmæssigt via digitale udgange.
\f
2_._6_ _ _ _ _ _ _ _Ø_v_r_i_g_t_ _p_e_r_i_f_e_r_i_u_d_s_t_y_r_ 2.6
Som operatørkonsol anvendes TTY model 43 med en skrivehastighed
på 30 tegn/sek.
Pladelagre findes i flere størrelser, f.eks. 33 MB (RC8223) eller
66 MB (RC8224).
Herudover kan tilsluttes et udvalg af enheder efter den enkelte
installations behov. Som eksempler kan nævnes:
- RC3615 båndstation, 9 spor, 800/1600 bpi.
- RC3640 formatteret matrix printer.
- Calcomp 565 plotter.
- RC3682 asynkron multiplexer (bruges til tilkobling af farve-
skærme og terminaler).
- RC822B skærmterminal.
\f
F_ 3_._ _ _ _ _ _ _ _ _S_I_G_N_A_L_I_N_D_S_A_M_L_I_N_G_ _O_G_ _-_ _B_E_H_A_N_D_L_I_N_G_ 3.
Dette kapitel beskriver, hvilke former for behandling eller over-
vågning de tilsluttede signaler som standard kan udsættes for.
Desuden skitseres hvordan data for tilsluttede signaler kan ind-
lægges eller ændres i systemet.
Alarmovervågning tjener i princippet to formål, dels at detektere
giverfejl (instrumentkontrol), dels at detektere unormale til-
stande i anlægget (anlægskontrol). Overvågningen sker normalt
periodisk ved at en gruppe af målinger tilmeldes til periodead-
ministratoren (afsnit 7.3.1).
3_._1_ _ _ _ _ _ _ _I_n_s_t_r_u_m_e_n_t_k_o_n_t_r_o_l_ _a_f_ _a_n_a_l_o_g_e_ _s_i_g_n_a_l_e_r_ 3.1
Denne kan deles i overvågning af en enkelt målt eller beregnet
værdi, og i mere sammensatte overvågninger, hvori der indgår
flere dataværdier. I det følgende beskrives de former for in-
strumentkontrol, der findes i systemet. Formålet med instrument-
kontrollen er at forhindre at signaler, der er fejlramte indgår i
anlægsovervågningen.
O_V_E_R_L_O_A_D_
Genereres, hvis signalspændingen kommer uden for A/D-converterens
måleområde.
I_N_S_T_R_U_M_E_N_T_ _H_Ø_J_
En maksimal grænse, som målingen rent fysisk ikke skulle kunne
komme over.
I_N_S_T_R_U_M_E_N_T_ _L_A_V_
En minimal grænse, som målingen rent fysisk ikke skulle kunne
komme under.
\f
H_Y_S_T_E_R_E_S_E_
En meldt alarm afmeldes først, når et specificeret interval
(hysterese-intervallet) i_n_d_e_n_f_o_r_ grænsen er passeret.
A_F_V_I_G_E_L_S_E_ _F_R_A_ _M_I_D_D_E_L_V_Æ_R_D_I_
For en sammenhørende gruppe målinger dannes middelværdien, og det
kontrolleres, at ingen af målingerne afviger utilladeligt fra
middelværdien.
T_I_D_S_F_O_R_S_I_N_K_E_L_S_E_
Generelt er det muligt at tidsforsinke alle former for instru-
mentkontrol, således at de først registreres efter en vis tid.
B_E_T_I_N_G_E_L_S_E_
Instrumentkontrol af en måling kan gøres betinget af anlægstil-
standen, dvs. gøres afhængig af, om en anden måling eller be-
regnet værdi er større eller mindre end en bestemt angivet værdi.
Ligeledes kan instrumentkontrollen gøres betinget af en digital
værdi.
E_R_S_T_A_T_N_I_N_G_S_V_Æ_R_D_I_E_R_
Målinger, som er fanget af instrumentkontrollen vil normalt ikke
blive benyttet i overvågning eller akkumulering. For alligevel at
kunne udføre sådanne beregninger har man indført to former for
e_r_s_t_a_t_n_i_n_g_s_v_æ_r_d_i_e_r_:
1. Fast (konstant) erstatningsværdi.
2. Erstatningsværdi i form af anden måling eller en beregnet
værdi.
\f
3_._2_ _ _ _ _ _ _ _A_n_l_æ_g_s_k_o_n_t_r_o_l_ _a_f_ _a_n_a_l_o_g_e_ _s_i_g_n_a_l_e_r_ 3.2
I det følgende beskrives, hvilke typer unormaliteter i anlægget,
der kan opfanges af anlægskontrollen.
De grænseværdier, der indgår i overvågningerne kan være konstante
eller variable i form af en anden måling eller beregnet værdi, og
grænserne kan være individuelle for en måling eller fælles for
flere målinger.
A_N_L_Æ_G_ _H_Ø_J_ _+_ _I_N_T_E_R_V_A_L_
Alarm afgives ved overskridelse af den høje grænse, samt hver
gang grænsen plus et helt multiplum af intervallet overskrides.
A_N_L_Æ_G_ _L_A_V_ _-_ _I_N_T_E_R_V_A_L_
Alarm afgives ved overskridelse af den lave grænse samt hver gang
grænsen minus et helt multiplum af intervallet overskrides.
H_Y_S_T_E_R_E_S_E_
En meldt alarm afmeldes først, når hystereseintervallet er pas-
seret.
M_I_D_D_E_L_V_Æ_R_D_I_
En måling kan indgå i beregning af fælles middelværdi og overvå-
ges for afvigelse ud over et specificeret interval herfra.
G_R_A_D_I_E_N_T_
Der afgives alarm, hvis målingens ændring pr. tidsenhed er større
end den specificerede grænse.
U_B_A_L_A_N_C_E_
Alarm, hvis differencen mellem to analoge målinger bliver større
end en specificeret grænse. I tilfælde af ubalance afgives alarm
på begge dataværdier.
\f
A_N_A_L_O_G_-_D_I_G_I_T_A_L_ _C_H_E_C_K_
Forholdet mellem analoge og digitale værdier kan overvåges på den
måde, at der til den analoge værdi angives en høj eller lav græn-
se. Ved grænseoverskridelse afgives alarm, hvis en specificeret
digital værdi ikke er i overensstemmelse hermed. Der kan til den-
ne funktion knyttes en tidsforsinkelse.
G_L_A_T_N_I_N_G_
Der er i systemet mulighed for at danne en glattet værdi ud fra
enhver indsamlet eller beregnet værdi. Dette kan være hensigts-
mæssigt, hvis værdien som følge af en urolig måling fremtræder
med store udsving. Med en glatningsfaktor, der angives som para-
meter beregnes den glattede værdi ud fra følgende formel:
Ny glattet værdi =
M_m_m_ g_l_._g_l_a_t_t_e_t_ _v_æ_r_d_i_ _-_ _m_å_l_t_ _v_æ_r_d_i_
målt værdi -
_ _ _t_ _ _ _ _ _ _ _ _ _ _ _
1 +
P_p_p_ glatningsfaktor
hvor t er tiden, der er gået siden sidste glatning.
B_E_T_I_N_G_E_L_S_E_
En alarm kan gøres betinget af anlægstilstanden, dvs. gøres af-
hængig af, om en anden måling eller beregnet værdi er større el-
ler mindre end en bestemt angivet værdi. Ligeledes kan en over-
vågning gøres betinget af en digital værdi.
3_._3_ _ _ _ _ _ _ _B_e_h_a_n_d_l_i_n_g_ _a_f_ _t_i_d_s_f_ø_l_g_e_m_e_l_d_i_n_g_e_r_ 3.3
Når meldinger fra tidsfølgemelderen sendes til RC8000, kan de ud-
sættes for behandling udover indsættelse i tidsfølgemeldertabel
og hændelsesregistrering i en rigtig rækkefølge.
\f
F_l_e_t_n_i_n_g_ _a_f_ _m_e_l_d_i_n_g_e_r_ _f_r_a_ _f_l_e_r_e_ _t_i_d_s_f_ø_l_g_e_m_e_l_d_e_r_e_
Er der tilkoblet flere tidsfølgemeldere vil meldingerne blive
indsat i tabellerne i rigtig rækkefølge, idet tidsmærkningen fra
de enkelte tidsfølgemeldere benyttes som sorteringskriterium.
A_l_a_r_m_e_r_
En tidsfølgemelding kan betegnes som en alarm, hvorved den bliver
indsat i alarmtabellen og giver anledning til afgivelse af akus-
tisk alarm.
A_r_k_i_v_k_o_p_i_
En tidsfølgemelding kan udpeges til at forårsage at der foretages
kopiering af korttidsarkivet, således at det kan gemmes til sene-
re analyse.
S_p_e_c_i_a_l_b_e_h_a_n_d_l_i_n_g_
En tidsfølgemelding kan overføres til videre behandling af en
brugerdefineret opgave.
3_._4_ _ _ _ _ _ _ _D_a_t_a_b_a_s_e_ _o_g_ _d_a_t_a_i_n_d_f_y_l_d_n_i_n_g_ 3.4
Internt i systemet er ethvert tilsluttet signal og enhver bereg-
net værdi identificeret ved et entydigt datanummer. RC-Proces er
udformet således, at man kan anvende en brugernummerkode i daglig
drift. Brugerkoden oversættes af edb-anlægget til datanumre.
Til et datanummer er knyttet såvel en værdi som et statusord.
Statusordet benyttes til at markere, i hvilken tilstand den
pågældende måling befinder sig, dvs. om den er i alarmtilstand,
om den er gjort inaktiv osv.
Al information om de enkelte datanumre, dvs. kanalnummer, bruger-
nummerkode, grænseværdier, erstatningsværdier osv. findes i den
primære database.
\f
Da systemet skal bruges til overvågning og rapportering, er det
nødvendigt let at kunne ændre den primære database.
Ændringer i den primære database foregår - for at forstyrre
overvågningen så lidt som muligt - i følgende 3 trin.
1. Ændringen(erne) b_e_s_k_r_i_v_e_s_ af brugeren overfor systemet. Dette
gøres via et eller flere indfyldningsbilleder. Et eksempel på
indfyldningsbillede er givet på figur 2.
2. Systemet k_o_n_t_r_o_l_l_e_r_e_r_ om ændringen er lovlig, f.eks. må et
datanummer, som indgår i en opgave ikke fjernes, dvs. opgaven
skal først tages ud. Hvis ændringen kan lade sig gøre k_l_a_r_-
g_ø_r_e_s_ en ny database ud fra den gamle og ændringen. Overvåg-
ningen foretages stadig på baggrund af den "gamle" database.
3. Overvågningen standses og databasen o_m_b_y_t_t_e_s_, hvorefter over-
vågningen straks startes på baggrund af den ændrede database.
Figur 2: Indfyldningsbillede.
\f
F_ 4_._ _ _ _ _ _ _ _ _B_E_T_J_E_N_I_N_G_S_P_L_A_D_S_E_R_ 4.
Under den daglige drift præsenteres resultaterne af de forskel-
lige overvågninger for driftsvagten i kontrolrummet via en eller
flere semigrafiske farveskærme. Denne præsentationsform giver
vagten et hurtigere overblik og bedre grundlag for at træffe
beslutninger om indgreb i fejlsituationer.
Dette kapitel beskriver principperne i on-line anvendelse af
RC-Proces via farvedataskærme, som den foregår i den daglige
drift.
4_._1_ _ _ _ _ _ _ _F_a_r_v_e_s_k_æ_r_m_e_n_ 4.1
Til hver farveskærm hører to tastaturer, et funktionstastatur og
et alfanumerisk tastatur, som også indeholder en række taster til
markørstyring.
På de semigrafiske farveskærme er der 64 tegnfelter pr. linie og
48 linier. Hvert tegnfelt består af 8 x 6 punkter, og de enkelte
tegn dannes ved at farvelægge nogle af punkterne med en for-
grundsfarve mens farven på resten af punkterne kaldes baggrunds-
farven.
I alt rummer systemet mulighed for at anvende 256 forskellige
tegn, 16 forgrundsfarver og 8 baggrundsfarver. Tegnsæt og farver
kan defineres og redefineres efter behov.
4_._2_ _ _ _ _ _ _ _S_k_æ_r_m_b_i_l_l_e_d_e_r_ 4.2
Til brug i den daglige drift er defineret en række forskellige
billedtyper, nemlig:
\f
- blindskemaer
- alarmtabeller
- tidskurver
- stavdiagrammer og profilvisninger
- skemabilleder
Ethvert skærmbillede uanset type består af et grundbillede og
noget dynamisk information, som benyttes til på forskellig form
at præsentere og vedligeholde målte eller beregnede værdier fra
overvågningen.
Billeder kan opbygges og ændres fra skærmen.
På de næstfølgende sider gennemgås hovedprincipperne ved de en-
kelte billedtyper.
4_._2_._1_ _ _ _ _ _B_l_i_n_d_s_k_e_m_a_e_r_ 4.2.1
Blindskemaer kan benyttes til at vise processkemaer og tilsvaren-
de billeder, hvor man kan se aktuelle måleværdier og forskellige
komponenters stilling.
I blindskemaer er der mulighed for at definere følgende typer af
dynamiske felter:
- digitalvisning
- analogvisning
- symbolvisning
Disse opdateres hvert 10. sek. (når billedet er vist) på baggrund
af værdier fra overvågningen.
Ved d_i_g_i_t_a_l_v_i_s_n_i_n_g_ vises de aktuelle måleværdier som tal.
Ved a_n_a_l_o_g_v_i_s_n_i_n_g_ vises måleværdier som stave eller punkter, der
bevæger sig indenfor bestemte grænser. Såvel digitale som analoge
visningers farve gøres afhængig af status for målepunktet, dvs.
om målingen er f.eks. over høj grænse, inaktiv, osv.
\f
Ved s_y_m_b_o_l_v_i_s_n_i_n_g_ kan man afhængig af en/flere måleværdier vælge
mellem et antal symboler og farver for dem, hvorefter symbolet
vises i det dynamiske felt.
Symbolvisning kan f.eks. benyttes til at vælge mellem symboler
for om et spjæld er åbent, mellemstillet eller lukket udfra
edb-systemets oplysninger herom.
Åbent, mellemstillet
og lukket spjæld.
Udover dynamiske felter kan man i blindskemaer definere nogle
såkaldte indvalgspunkter, dvs. punkter, som er tabuleringspunkter
for markørstyringen. Til sådanne indvalgspunkter er der mulighed
for at knytte forskellig information under opbygningen af bil-
ledet. F.eks. kan man til et indvalgspunkt knytte et bestemt job
eller billede. Anbringes markøren i punktet, vil aktivering af
send-tasten bevirke at det tilhørende job/billede startes/vises.
Den sidste facilitet giver mulighed for at opnå en slags zoom-
effekt.
Foruden ovenstående type indvalgspunkter, er der knyttet ind-
valgspunkter til alle symbolvisninger samt analog- og digital-
visninger. Ved at anbringe markøren i et sådant indvalgspunkt og
aktivere bestemte funktionstaster, kan man "udvælge målepunktet"
for at få yderligere information om status eller for senere at
kunne vise dets værdi i anden sammenhæng, f.eks. som tidskurve.
Nedenfor er vist eksempel på et blindskema med analogvisning,
digitalvisning og symbolvisning. \f
Figur 3: Blindskema.
4_._2_._2_ _ _ _ _ _A_l_a_r_m_t_a_b_e_l_l_e_r_ 4.2.2
Alarmtabeller benyttes til præsentation af forskellige alarmty-
per. Der findes 2 slags alarmtabeller:
- en a_l_a_r_m_t_a_b_e_l_, der skal indeholde alarmer fra unormale
anlægstilstande.
- en i_n_s_t_r_u_m_e_n_t_a_l_a_r_m_t_a_b_e_l_, der indeholder alarmer fra fejlramte
signaler eller signaler, hvor overvågning eller indlæsning er
stoppet.
Hvorvidt en hændelse skal i den ene eller den anden tabel, af-
gøres af signalbehandlingen (jfr. afsnit 3.1).
Alarmer i a_l_a_r_m_t_a_b_e_l_l_e_n_ kan inddeles i 3 typer:
- konventionelle alarmer, dvs. alarmer, der bliver meldt både i
alarmtabellen og på det konventionelle alarmanlæg.
- edb-alarmer, dvs. alarmer, der alene bliver meldt i alarmta-
bellen. \f
- OBS-alarmer dvs. alarmer, der kun er meldt i alarmtabellen, men
som også burde være meldt på det konventionelle alarmanlæg.
En alarm-linie har følgende format:
tid kvitteringstype klartekst fejltype interval værdi
tid tidspunkt for alarmens opståen i time og
minutter.
kvitteringstype et tegn, som angiver om alarmen er af
konventionel, edb eller OBS type.
klartekst en 30-tegns beskrivelse af fejlstatus, eks.
herpå er A-HØJ (høj anlægsgrænseværdi), GRADI
(gradient for høj).
interval et tal, der kan vise hvilken intervalgrænse,
der overskrides.
værdi for binære alarmer 1 eller 0 mens den for
analoge alarmer består af:
værdi enhed alarmgrænse ekstragrænse
Nedenfor er vist et eksempel på en alarmtabel.
Figur 4: Alarmtabel.
\f
En alarmlinie skrives med en farve, som vælges ud fra status for
det pågældende målepunkt og alarmer i alarmtabellen opdateres
hvert 10. sek. således at vagten løbende kan følge udviklingen af
den aktuelle værdi og status for målepunktet.
I i_n_s_t_r_u_m_e_n_t_a_l_a_r_m_t_a_b_e_l_l_e_n_ anføres alarmer eller meldinger fra:
- analogsignaler, der er fanget af instrumentkontrollen.
- analog- og digitalsignaler, hvor overvågningen er stoppet.
- analog- og digitalsignaler, hvor indlæsningen er stoppet.
- OBS-alarmer (vises både i alarm- og instrumentalarm-tabellen).
En linie i instrumentalarmtabellen har følgende format:
tid kvitteringstype klartekst fejltype erstat værdi
tid som alarmtabel
kvitteringstype et tegn, som angiver, om det er en OBS-alarm
eller andet.
klartekst en 30-tegns beskrivelse af fejlstatus, eks.
herpå er I-HØJ (høj intervalgrænse)
erstat et 1-tegns felt, som angiver om der indgår
erstatningsværdi for målingen:
F, erstattet af konstant værdi.
D, erstattet af måling.
Blank, ingen erstatning.
værdi for binære alarmer 1 eller 0, mens den for
analoge alarmer består af:
værdi enhed alarmgrænse
Alarm- henholdsvis instrumentalarm-tabellen kaldes frem ved tryk
på funktionstast. Hver tabel har plads til 18 alarmer på et
skærmbillede. Da tabellerne kan fylde flere skærmbilleder, kan
man ved hjælp af funktionstaster blade frem eller tilbage i
tabellen og få vist det ønskede udsnit.
\f
4_._2_._3_ _ _ _ _ _T_i_d_s_k_u_r_v_e_r_ 4.2.3
Tidskurver kan benyttes til grafisk at vise den tidsmæssige
udvikling af analoge og digitale signaler samt beregnede værdier.
Til dette formål opsamles og lagres data løbende i systemet.
Visning af tidskurver foregår i billeder med to eller fire kurver
i hvert sit koordinatsystem. Nedenfor er vist et eksempel på et
tidskurvebillede. I koordinatsystemerne er x-aksen tidsaksen og
y-aksen måleaksen. Tidsaksen er inddelt således, at de ældste
punkter står til venstre. Den sidste 1/3 af tidsaksen anvendes
til visning af de nyeste værdier, således at en kurve vil bevæge
sig hen mod måleaksen. Når kurven er nået hen til måleaksen,
rykkes hele kurven 1/3 tilbage.
Figur 5: Tidskurver.
Såvel tidsakse- som måleakse-inddeling kan gøre finere/grovere
ved aktivering af forskellige funktionstaster. Mens ændring af
tidsakseenhed gælder for alle koordinatsystemer i et billede
under t, skaleres måleakserne enkeltvis. Dette medfører at man
kan have kurver for forskelligartede målepunkter vist på samme
billede, og hver især med den mest hensigtsmæssige skalering.\f
Endvidere kan man ved aktivering af en bestemt funktionstast få
vist grænseværdier for de viste måleværdier.
For at kunne udpege samme tidspunkt på alle 4 kurver findes en
"sigtelineal", som man kan placere på et bestemt sted i en af
kurverne, hvorved den automatisk vises på samme sted i de øvrige
kurver. Samtidig vises måleværdien for det punkt hvori
sigtelinealen er placeret.
4_._2_._4_ _ _ _ _ _P_r_o_f_i_l_e_r_ 4.2.4
I profilbilleder præsenteres et antal forskellige måleværdier af
samme type som punkter i t og samme koordinatsystem. Profilbil-
leder kan f.eks. anvendes til at vise temperaturfordelingen i et
snit gennem kedelrørene.
Ligesom ved tidskurver kan operatøren ved hjælp af funktionstas-
ter ændre måleaksens inddeling, og der kan vises grænseværdier
for de enkelte målepunkter.
Værdier i profilbilleder opdateres på farveskærmen hver 10. sek.
med de nyeste målte/beregnede værdier.
4_._2_._5_ _ _ _ _ _S_t_a_v_d_i_a_g_r_a_m_m_e_r_ 4.2.5
I stavdiagrammer vises aktuelle værdier for forskellige måle-
punkter som vandrette stave. I modsætning til profiler kan
stavdiagrammer præsentere værdier for målepunkter af forskellig
type, idet stavene skaleres enkeltvis.
Foruden stavene vises målingernes værdi samt grænserne som tal.
Der er for hver måling plads til den klartekst, som beskriver
målepunktet.
\f
Mens målepunkter i profilbilleder og visse stavdiagrammer skal
defineres under opbygningen af billedet, findes der et specielt
stavdiagrambillede, som fra starten er opbygget uden definerede
målepunkter. Heri kan operatøren selv indsætte målepunkter, som
er interessante i den aktuelle driftsituation.
4_._2_._6_ _ _ _ _ _S_k_e_m_a_b_i_l_l_e_d_e_r_ 4.2.6
Skemabilleder (indfyldningsbilleder) kan indeholde såkaldte "åbne
felter", hvori man kan indtaste data, som senere skal viderebe-
handles i systemet. Normalt er skemabilleder opbygget til spe-
cielle formål, og de benyttes i kommunikationen med bestemte
programmer. F.eks. anvendes skemabilleder ved ændringer i data-
basen, jfr. afsnit 3.4, hvor der er givet et eksempel.
4_._2_._7_ _ _ _ _ _B_i_l_l_e_d_b_y_g_n_i_n_g_ 4.2.7
Skærmbilleder kan som tidligere nævnt opbygges og ændres af
operatøren fra farveskærmen. Vi vil ikke på dette sted komme
nærmere ind på hvordan, blot skal det nævnes at opbygningen
foregår i en dialog med systemet, og at den kan foregå s_i_d_e_-
l_ø_b_e_n_d_e_ med overvågningen, forstået på den måde, at man fra n
skærm kan bygge billeder mens den/de øvrige anvendes til
almindelig driftsovervågning.
\f
F_ 5_._ _ _ _ _ _ _ _ _L_A_G_R_I_N_G_ 5.
Med henblik på drifts- og analyseformål lagres den information om
driftstilstanden, der registreres af anlægget, i kortere eller
længere tid i forskellige tabeller og arkiver.
Opbevaring i kortere tid finder sted i korttidsarkivet,
TEM-tabellen og de to alarmtabeller, som allerede er beskrevet.
Langtidsopbevaring sker i langtidsarkivet og i
hændelsesregistreringen, som indeholder alle hændelser, der er
registreret i anlægget.
Fejlskriveren kan starte registrering ved bestemte hændelser, og
registreringen kan langtidsgemmes på magnetbånd.
5_._1_ _ _ _ _ _ _ _T_E_M_-_t_a_b_e_l_l_e_n_ 5.1
Denne tabel indeholder til enhver tid de sidste 250 TFM-hændelser
(fra tidsfølgemelder), dvs. TFM-alarmer og TFM-meldinger.
5_._2_ _ _ _ _ _ _ _K_o_r_t_t_i_d_s_a_r_k_i_v_e_t_ 5.2
I korttidsarkivet gemmes værdier (cyklisk) til visning som
tidskurver, idet formålet er at vise de enkelte målværdiers
udvikling i tid. For hvert datanummer, som er specificeret til
arkivering i korttidsarkivet, gemmes værdier opsamlet med
forskellig tidsafstand i hver sin afdeling.
I Asnæsværkets system er korttidsarkivet dimensioneret til ca.
1500 datanumre og fire afdelinger med tidsintervaller på hhv. 10
sek., 1 min, 10 min. og 1 time. I hver afdeling er der 60
måleværdier pr. datanummer.
\f
5_._3_ _ _ _ _ _ _ _L_a_n_g_t_i_d_s_a_r_k_i_v_e_t_ 5.3
Formålet med langtidsarkivet er at opsamle sammenhørende data, så
længe blokken er i drift for senere at kunne analysere langtids-
ændringer i procesanlægget.
Der tages en gang i timen et sæt af værdierne fra korttidsarki-
vet. Værdierne lagres. Der er plads til 50 døgns arkivering, her-
udover er der mulighed for at gemme værdier på bånd, hvis længere
opbevaring ønskes.
Data fra langtidsarkivet kan (hvadenten de er lagret på disk el-
ler bånd) vises som specielle tidskurver på skærm, eller de kan
udskrives på printer eller plotter.
5_._4_ _ _ _ _ _ _ _H_æ_n_d_e_l_s_e_s_r_e_g_i_s_t_r_e_r_i_n_g_ 5.4
Hændelsesregistreringen kan betragtes som anlæggets "logbog",
idet alle hændelser, der registreres i anlægget, dvs. tidsfølge-
meldinger, alarm til- og afmeldinger, signal ud- og indkoblinger
gemmes her. Hændelsesregistreringen giver derfor et godt data-
grundlag for analyse dels af hændelsesforløbet i forskellige
driftssituationer dels af belastningen på edb-anlægget.
Et vist antal (f.eks. 1000) af de nyeste hændelser gemmes på
disk, hvorfra de kan overføres til magnetbånd for længere opbe-
varing.
5_._5_ _ _ _ _ _ _ _F_e_j_l_s_k_r_i_v_e_r_ 5.5
Fejlskriveren anvendes til at fastholde den tidsmæssige udvikling
i et antal målinger fra kort tid før en specificeret hændelse til
en passende tid efter hændelsen.
\f
Til brug for fejlskriverfunktionen indsamles til stadighed vær-
dier for et antal målinger. Disse værdier lagres cyklisk, således
at man til ethvert tidspunkt har de n_y_e_s_t_e_ værdier. Når en af de
på forhånd specificerede starthændelser indtræffer gemmes de cyk-
lisk lagrede værdier sammen med efterfølgende værdier for de sam-
me målepunkter, indsamlet i et passende tidsrum efter hændelsen.
Herudover gemmes oplysninger om tidspunkt og starthændelse for
registreringen. Registreringerne kan udskrives på plotter/prin-
ter eller som tidskurver på farveskærm.
\f
F_ 6_._ _ _ _ _ _ _ _ _R_A_P_P_O_R_T_E_R_I_N_G_ 6.
Overvågningsanlæggets store kapacitet med hensyn til dataindsam-
ling og -bearbejdning giver gode muligheder for en god og omfat-
tende rapportering.
Rapporteringen tjener flere formål, hvorfor man har inddelt rap-
porterne i tre hovedtyper, nemlig:
- driftsøkonomiske rapporter
- driftstekniske rapporter
- analyserapporter
Alle rapporter udskrives på printer, fordi studier af dem så kan
foregå som skrivebordsarbejde uden at blokere dataskærmene og
fordi de på denne måde kan opbevares til senere brug.
Det vil i høj grad være op til den enkelte anvender af RC-Proces
at fastlægge, hvilke rapporter, der kan være til hjælp i den kon-
krete situation. Under gennemgangen af de tre rapporttyper skit-
seres, hvilke rapporter der anvendes på Asnæsværket.
6_._1_ _ _ _ _ _ _ _D_r_i_f_t_s_ø_k_o_n_o_m_i_s_k_e_ _r_a_p_p_o_r_t_e_r_ 6.1
Formålet med denne rapporttype er at give et overblik over sam-
menhængen mellem virkningsgrader og blokkens varmeforbrug. Dette
forhold siger noget om produktionen, set ud fra et driftsøkono-
misk synspunkt.
Man har der ønsket en døgn- og månedsrapport, som giver overblik,
og på grundlag af hvilken man kan beslutte, om mere detaljeret
information er nødvendig. Opsamling af data til disse rapporter
foregår automatisk. Ud over døgn- og månedsrapporten findes en
timerapport, hvori der angives værdien for hver af døgnets 24
timer. På denne måde får man overblik over, hvordan økonomien er
på forskellige tidspunkter af dagen, hvor belastningen er for-
skellig.
\f
6_._2_ _ _ _ _ _ _ _D_r_i_f_t_s_t_e_k_n_i_s_k_e_ _r_a_p_p_o_r_t_e_r_ 6.2
Ved hjælp af en effektiv rapportering om maskinanlæggets tilstand
og en registrering af levetidsforbruget på de kritiske komponen-
ter, er der skabt grundlag for at forebygge en lang række maskin-
uheld, uden at skulle udskifte særligt belastede komponenter alt
for ofte. Data og beregninger vil således for disse rapporters
vedkommende koncentrere sig om de mest belastede komponenter.
På Asnæsværket har man besluttet sig for to driftstekniske rap-
porter, nemlig en lastrapport og en temperatursummeringsrapport.
Lastrapporten fordeles efter specifikation i en kedellastrapport
og en turbinelastrapport.
Temperatursummeringsrapporter udskriver en opgørelse over det
antal timer en værdi har ligget i hvert af syv prodefinerede
intervaller akkumuleret over hele blokkens levetid.
6_._3_ _ _ _ _ _ _ _A_n_a_l_y_s_e_r_a_p_p_o_r_t_e_r_ 6.3
Hovedformål med disse rapporter er at medvirke til en effektiv og
hurtig analyse af hændelsesforløb, først og fremmest ved fejl
eller ændringer i procesanlægget, hvor tingene ofte udvikler sig
hurtigt.
I RC-Proces er forløbig implementeret en TFM-rapport.
I TFM-rapporten udskrives tidsfølgemeldinger indenfor et døgn med
døgnskift kl. 24.00. Rapporten udskrives automatisk hver dag kl.
07.00.
\f
F_ 7_._ _ _ _ _ _ _ _ _P_R_O_G_R_A_M_M_E_L_S_Y_S_T_E_M_ 7.
Programmel til RC-Proces omfatter:
- RC8000 basisprogrammel
- et specielt operativsystem, POPS
- applikationsprogrammel
7_._1_ _ _ _ _ _ _ _B_a_s_i_s_p_r_o_g_r_a_m_m_e_l_ 7.1
RC8000 basisprogrammellet kan opdeles i følgende dele:
- front-end programmel
- monitor
- file processor (FP)
7_._2_ _ _ _ _ _ _ _F_r_o_n_t_-_e_n_d_ _p_r_o_g_r_a_m_m_e_l_ 7.2
Front-end maskinerne tager sig af behandlingen af ydre enheder.
De mest resourcekrævende enheder er dataskærmene og CAMAC-udsty-
ret. Derfor kobles dataskærmene til den ene front-end og CAMAC-
udstyret til den anden.
Programafvikling i en front-end maskine er styret af en m_o_n_i_t_o_r_ _i_
f_r_o_n_t_-_e_n_d_>_e_n_, der tillader udførelse af flere programmer samti-
dig.
De øvrige programmer varetager dels behandlingen af ydre enheder,
dels forbindelsen til RC8000.
7_._3_ _ _ _ _ _ _ _M_o_n_i_t_o_r_ 7.3
Monitoren er den del af basisprogrammellet, der gør det muligt at
multi-programmere, dvs. at udføre flere processer samtidig i sy-
stemet. Monitoren hjælper desuden de øvrige programmer med at be-
\f
tjene de ydre enheder via front-end maskinerne. Endelig indehol-
der monitoren en række funktioner til brug for operativsystemet.
7_._4_ _ _ _ _ _ _ _F_i_l_e_-_p_r_o_c_e_s_s_o_r_ _(_F_P_)_ 7.4
File-processoren (FP) er standardopgaveafvikleren på RC8000. Sam-
men med operativsystemet (her: POPS, se afsnit 7.5) kontrollerer
FP udførelsen af jobs.
FP læser kommandoer en ad gangen. Udførelsen af den enkelte FP-
kommando indebærer, at et til kommandoen svarende hjælpeprogram
"loades" ind i centrallageret.
7_._5_ _ _ _ _ _ _ _O_v_e_r_a_t_i_v_s_y_s_t_e_m_e_t_ _P_O_P_S_ 7.5
Operativsystemet POPS er den del af basisprogrammellet, der sør-
ger for at datamaskinen og dens resourcer udnyttes så hensigts-
mæssigt som muligt. POPS er specielt tilpasset den anvendelse af
datamaskinen, som RC-Proces står for.
I POPS fastlægges reglerne for opgaveudvælgelse. Endvidere optræ-
der POPS som mellemled mellem applikationsprogrammer og monitoren
i forbindelse med betjeningen af nogle ydre enheder, f.eks. ter-
minaler, linieskrivere og magnetbåndsstationer. Endelig admini-
strerer POPS en væsentlig del af kommunikationen mellem anvender-
opgaverne (applikationerne).
7_._5_._1_ _ _ _ _ _K_o_m_m_u_n_i_k_a_t_i_o_n_ _m_e_l_l_e_m_ _a_n_v_e_n_d_e_r_o_p_g_a_v_e_r_ 7.5.1
En meget væsentlig egenskab ved et multiprogrammeret "real time"
system er dets evne til at overføre information genereret af en
opgave til en anden opgave. Måden hvorpå dette problem løses, er
afgørende for, hvorledes opgavestrukturen kan opbygges, og hermed
for, hvor bekvemt systemet er at arbejde med.
\f
I RC-Proces sker informationsoverførsel mellem processer ved
hjælp af "d_a_t_a_s_t_r_ø_m_m_e_". En datastrøm er en ensrette kommunika-
tionsvej, hvorigennem information kan sendes fra et antal pro-
cesser til en bestemt proces.
Afsenderprocesserne leverer informationen i datastrømmen, hvor
den sættes i kø. Modtageren får informationer udleveret i den
rækkefølge, de blev sendt.
Modtagerprocessen kan vente på, at der kommer information i en
datastrøm på en sådan måde, at opgaveudførelsen suspenderes i
processen, indtil et informationsmodul ankommer. Modtagerproces-
sen kan også blot afføle datastrømmen, uden at den videre opgave-
udførelse forsinkes. Endelig kan en proces vente på flere data-
strømme samtidig, idet datastrømme kan kobles sammen.
Datastrømmen kan således sammenlignes med et rørpostanlæg, der
kan have flere afsendelsessteder, men kun eet modtagelsessted, og
brevene modtages i den rækkefølge, hvori de er afsendt.
En datastrøm har en forudbestemt kapacitet på et givet antal
informationselementer af en bestemt længde og kan således fungere
som buffer mellem producent(er) af information og den forbrugende
opgave. Specielle datastrømme er knyttet til visse af de ydre
enheder.
7_._6_ _ _ _ _ _ _ _A_p_p_l_i_k_a_t_i_o_n_s_p_r_o_g_r_a_m_m_e_l_ 7.6
Applikationsprogrammellet er betegnelsen for de programmer, der
løser de egentlige anvendelsesopgaver i RC-Proces, det vil sige
f.eks.:
- indlæsning af anlægsværdier
- overvågning
- beregning af driftsværdier
- billedvisning på skærme
- mand-maskine kommunikation
- opgaver, der danner rapporter.
\f
Nogle anvendelsesopgaver kører evigt, nogle kører periodisk, og
nogle startes ved bestemte hændelser eller operatørindgreb.
Periodeadministratoren er et anvendelsesprogram, der selv er be-
regnet til at køre evigt og som administrerer de periodiske ap-
plikationer.
7_._6_._1_ _ _ _ _ _P_e_r_i_o_d_e_a_d_m_i_n_i_s_t_r_a_t_o_r_ 7.6.1
Administratoren starter periodiske opgaver på basis af en grund-
periode, f.eks. på 10 sekunder. Dvs. at hvert 10 sekund undersø-
ges, hvilke opgaver der skal startes.
For de opgaver, der skal startes på samme tid, bestemmes den or-
den, hvori de startes, med et ordennummer. Opgaver med lavere
ordennummer startes før opgaver med højere ordennummer.
Foruden en opgaves periode angives et første starttidspunkt og en
sluttid, hvorefter opgaven ikke udføres mere.
Periodeadministratoren har sin egen proces. I en datastrøm mod-
tager den tidsmeldinger fra POPS, svarende til grundperioden og
kommandoer om tilmelding og fjernelse af periodiske opgaver.
Information om tilmeldte opgaver holdes i en opgavetabel.
Fra administratoren kan opgavetabellen kopieres til en fil som
derpå kan benyttes til en listning.
\f
F_ 8_._ _ _ _ _ _ _ _ _B_R_U_G_E_R_P_R_O_G_R_A_M_M_E_R_ 8.
8_._1_ _ _ _ _ _ _ _A_n_v_e_n_d_e_l_s_e_ _a_f_ _f_a_r_v_e_s_k_æ_r_m_e_ 8.1
Al mand-maskine-kommunikation i forbindelse med udtagning af lag-
ret information, dvs. visning af data og bestilling af print-ud-
skrifter af tabeller og rapporter foregår via farveskærmene. Det-
te medfører, at en lang række forskellige programmer skal kunne
anvende farveskærmene. For at holde styr på de mange programmers
anvendelse af skærmene er de altid "ejet" af et bestemt program -
PICTA, som så midlertidig kan "udlåne" en skærm til et program.
Normalt startes et program som skal bruge skærmen via tryk på en
funktionstast. Hvis skærmen ved tastning allerede var "udlånt"
til et andet program, vil dette blive fjernet, før det nye pro-
gram startes.
For at lette opbygningen af algol-programmer, der vil benytte
farveskærmene (via PICTA) stiller RC-Proces en række standardpro-
cedurer til rådighed herfor. F.eks. kan man ved hjælp af sådanne
procedurer få sat et nyt billede op, få input fra skærmen og
skrive på skærmen med almindelige algol i/o procedurer osv.
8_._2_ _ _ _ _ _ _ _D_a_t_a_a_c_c_e_s_s_ 8.2
For at give brugerprogrammer adgang til at læse og arbejde på de
data, der findes i systemet, findes nogle accesprocedurer, der
dels benyttes til at fremskaffe interne referencer i systemet ud-
fra en brugerkode (aks - nummer) dels kan fremskaffe de ønskede
data udfra den interne reference. Disse procedurer er de samme
som benyttes af dataindfyldningssystemet og nogle af overvåg-
ningsprogrammerne, således at brugerprogrammerne har helt de
samme dataaccesmuligheder.
Samtidig er det dog muligt at begrænse brugerprogrammers adgang
til at ændre visse data i systemet.
\f
8_._3_ _ _ _ _ _ _ _A_k_s_g_o_l_ 8.3
Hvis programmer skal bruge data hyppigt, er det af effektivitets-
grunde nødvendigt at de arbejder direkte på intern referencer.
For at man alligevel kan skrive brugerkoden i programmet, kan man
ved hjælp af forprocessoren Aksgol få omsat brugerkoden til en
intern reference før programmet udføres.
Dette indebærer blot, at de pågældende programmer skal genover-
sættes, hvis der sker ændringer af datastrukturen, men dette ad-
ministreres helt af dataindfyldningssystemet.
\f
i
T_A_B_L_E_ _O_F_ _C_O_N_T_E_N_T_S_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_
1. INTRODUCTION ........................................... 1
2. SHORT DESCRIPTION OF TOP80 ............................. 2
2.1 Different Processes in TOP80 ...................... 3
3. STRUCTURE OF TESTPROGRAM INTERFACE ..................... 5
3.1 Decision Point .................................... 5
4. DEMANDS FROM TEST TO TOP ............................... 8
5. LIBRARY ROUTINES IN TOP80LIB ........................... 9
5.1 Procedure print ................................... 9
5.2 Procedure errxtstart .............................. 9
5.3 Procedure errtxtfinis ............................. 9
5.4 Function check _result ............................. 9
5.5 Function converthex ............................... 10
5.6 Procedure memory _configuration .................... 10
5.7 Function get _buf .................................. 10
5.8 Function getparam ................................. 10
5.9 Procedure runupdate ............................... 11
5.10 Procedure maximummess ............................. 11
5.11 Procedure get _pending ............................. 11
5.12 Procedure testoutput .............................. 11
5.13 Procedure get _answer .............................. 12
5.14 Procedure save _err ................................ 12
6. TEXT FILES FOR TOP80 ................................... 13
A_P_P_E_N_D_I_C_E_S_:
A. REFERENCES ............................................. 15
B. TOP80 ENVIRONMENT ...................................... 16
\f
1_._ _ _ _ _ _ _ _ _I_N_T_R_O_D_U_C_T_I_O_N_ 1.
This manual is a guide for designing a testprogram which should
interact with TOP80.
The interface to TOP80 will be seen from the testprogram's point
of view.
Observe that the rules introduced in this manual should be kept,
if a proper operation of your testprogram is wanted.
TOP80 is a T_est O_P_erating system developed for the RC3502 com-
puter.
TOP80 is written in Real Time Pascal.
\f
F_ 2_._ _ _ _ _ _ _ _ _S_H_O_R_T_ _D_E_S_C_R_I_P_T_I_O_N_ _O_F_ _T_O_P_8_0_ 2.
TOP80 is developed for the RC3502, but could with some small
changes be reused for other Real Time Pascal based machines.
It uses the I/O-system developed for the RC3502 and the testsys-
tem, called TOPIO - ref. 2.
The testsystem has an interface to the user that is similar to
the one in TOP for RC8000. TOP80 has some common routines (admin-
istrative and input/output) for the testprograms. The testpro-
grams are normally reliability tests and should use the common
interface to TOP80.
The logical structure of TOP80 can be seen on fig. 1.
TOP
TESTSERVER TESTSERVER TESTSERVER
TEST TEST TEST
Figure 1: Logical structure of TOP80.
The structure of the testserver can be seen on fig. 2,
TOP
TPS OUTPUT
TPIP INPUT
DRIVER TEST OUTPUT
Figure 2: Logical structure of Testserver.
\f
The TPS (TEST-PROGRAM-SERVER) is the central logic. TPIP (TEST-
PROGRAM-INPUT-PROCESS) is taking care of input to TPS. Input/
Output is produced with the help of TOPIO, see ref. 2.
TOP80 could be split up as shown in fig. 3. DISPLAY gives an im-
pression on how the state of the tests is. TOP is the central
logic creating and removing the tests.
INPUT
TOP OUTPUT
OUTPUT DISPLAY
TESTSERVER TESTSERVER
Figure 3: Inner Structure of TOP80.
2_._1_ _ _ _ _ _ _ _D_i_f_f_e_r_e_n_t_ _P_r_o_c_e_s_s_e_s_ _i_n_ _T_O_P_8_0_ 2.1
T_O_P_: The head of the family. TOP has one waiting point, the se-
maphore of the inputzone. Depending on the read, TOP will do one
of the following actions:
a) Start an incarnation of DISPLAY.
b) Write informations to the user.
c) Start an incarnation of a test.
d) Remove an incarnation of a test.
e) Send a message to one of the TPS's.
D_I_S_P_L_A_Y_: There is created an incarnation of this process by TOP.
DISPLAY has one waiting point, a semaphore. When requested by
TOP, a request is sent to each TPS about the actual status. When
the answers are returned, they will be printed.
\f
T_E_S_T_P_R_O_G_R_A_M_S_E_R_V_E_R_ _(_T_P_S_)_: Every incarnation of this process is
managing one and just one testprogram. When TPS is created, an
incarnation of TPIP is created.
TPS has one waiting point from where it can do one of the fol-
lowing actions depending on the message:
a) Initialize the parameter segment (PS) (see section 3.1) and
pass it to the test.
b) Edit PS (via TPIP).
c) Manage the test, start, stop, request default parameters,
request select of subtest.
d) Route driver messages to and from device driver for the
test.
e) Handle breaks from TOP or TIMER.
T_E_S_T_P_R_O_G_R_A_M_ _I_N_P_U_T_ _P_R_O_C_E_S_S_ _(_T_P_I_P_)_: For every TPS there is one
TPIP. TPIP has one explicit waiting point, a request semaphore,
and one implicit waiting point, the read semaphore of the input-
zone. Normally TPS sends a request to TPIP to get input and
which kind of input is expected. TPIP gets input via TOPIO and
sends an answer to TPS.
\f
F_ 3_._ _ _ _ _ _ _ _ _S_T_R_U_C_T_U_R_E_ _O_F_ _T_E_S_T_P_R_O_G_R_A_M_ _I_N_T_E_R_F_A_C_E_ 3.
This is a description of how the testprogram should be structured
to interact correctly with TOP80.
The process head of the test should look like this:
PROCESS comtest (VAR testsem, tps _sem: semaphore;
VAR semvector: system _vector;
name: alfa);
In the initialization the testprogram should open an output zone
(OPENZONE), and link, create and start its TPS-process before the
wait decision point.
TPS is created with the call:
i:= create ("tps", tps (tps _sem, test _sem, driver _answ,
ref (driver _sem), semvector (operatorsem),
name), tps _shadow, 500);
TPS is started with the call:
start (tps _shadow, -3);
3_._1_ _ _ _ _ _ _ _D_e_c_i_s_i_o_n_ _P_o_i_n_t_ 3.1
In the outer, loop the testprogram has a wait point where it de-
cides whether it should enter the testloop, the default parameter
generation or the select test mode.
Which state the test should enter is decided by the U1 field of
the message received from TOP. The message polled between TOP and
the testprogram is of type "ps-type", see appendix B.
\f
U_1_ _=_ _1_,_ _s_e_l_e_c_t_t_e_s_t_:
A test could consist of different subtests. In this state the
test should initialize the parameter segment (ps _type) as fol-
lows:
p000 should hold the character identifying the default subtest.
The booleans in usedparam indexed 0 until (number of subtests +
2) should be true.
Paramnames (0):= "testprogram:";
Paramnames (1):= "a:<text identifying the subtest>";
and so on.
Paramnames (50) and paramnames (51) always contain a text ident-
ifying this testprogram followed by a version date.
example: paramnames (50):="** com 203 test **";
paramnames (51):="** ver 81.10.08**";
U_1_ _=_ _2_,_ _p_a_r_a_m_e_d_i_t_:
The testprogram has a set of default parameters which must be
initialized in this state. Again the ps _type is used. The para-
meter segment ps _type has a set of parameters identified by a "p"
in the beginning of the names. They have different types and
numbers. The ones used should be identified in the array called
usedparam. The related text for the parameters is placed in the
array paramnames. Still paramnames (0), paramnames (50) and pa-
ramnames (51) are reserved as in select _test.
U_1_ _=_ _2_4_,_ _r_u_n_n_i_n_g_:
In this state, it is expected that the testing loop is entered.
But before this happens the "paramvalues" in the parametersegment
(ps _type) should be limit checked, the "statarray" be reset and
the "statistic _info" contain the possible errortexts of the test.
The latter is done to make TPS able to print an error statistic
on request or at the end of the test based upon the summary of
"statarray". Device drivers could also be started now.
\f
In the testing loop the parameter segment is polled between the
test and TOP (the test does this as wait, return), (see chapter
4).
If TOP at any time changes the U1 field of the message from run-
ning (24), the test should terminate and go to the outer loop.
(Maybe after some cleaning up).
\f
F_ 4_._ _ _ _ _ _ _ _ _D_E_M_A_N_D_S_ _F_R_O_M_ _T_E_S_T_ _T_O_ _T_O_P_ 4.
In the testing loop the parametersegment is polled between the
test and TOP with the following legal commands placed in U1 by
the test:
M_M_m_m_ U1 = 3, run _adm:
P_P_p_p_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
With this command the test will force TOP to count up the run
number.
M_M_m_m_ U1 = 4, err _adm:
P_P_p_p_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
With this command the test will force TOP to count up its error-
counters and terminate the test if the total number is reached.
The total number should be placed in the reserved parameter of
the parameter segment PO18P049(49).
M_M_m_m_ U1 = 5, access _driver:
P_P_p_p_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
With this command the test accesses a possible device driver. It
also tells TPS that the message is a stack, where the message
underneath the TOP-message is a drivermessage, that is to be sent
to the device driver in question. (Push the TOP-message on top of
the drivermessage).
M_M_m_m_ U1 = 21, get _pending:
P_P_p_p_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
With this command the test is just polling TOP (TPS) and getting
possible device driver answers in a stack.
Every time TOP (TPS) is sending the parameter segment as a mes-
sage, this message can be a stack containing one or more device
driver answers. The test is to pop the parameter segment off the
stack and examine every one of the remaining driveranswers of the
stack.
Do inspect appendix B to see TOP80 environment.
\f
F_ 5_._ _ _ _ _ _ _ _ _L_I_B_R_A_R_Y_ _R_O_U_T_I_N_E_S_ _I_N_ _T_O_P_8_0_L_I_B_ 5.
5_._1_ _ _ _ _ _ _ _P_r_o_c_e_d_u_r_e_ _p_r_i_n_t_ 5.1
PROCEDURE print (VAR z: zone; no: textindex);
This is a procedure which can print one of the texts contained in
the procedure. The text is output via the zone (TOPIO). If NL is
true, the text is output followed by an nl-character.
5_._2_ _ _ _ _ _ _ _P_r_o_c_e_d_u_r_e_ _e_r_r_t_x_t_s_t_a_r_t_ 5.2
PROCEDURE errtxtstart (VAR z: zone; n: integer);
Outputs a line of asterixes with actual run.no. <n>. To be used
as heading for errormessages from test. This procedure is called
by TOP (TPS) when the command err _adm (see chapter 4) is sent
from test to TOP.
5_._3_ _ _ _ _ _ _ _P_r_o_c_e_d_u_r_e_ _e_r_r_t_x_t_f_i_n_i_s_ 5.3
PROCEDURE errtxtfinis (VAR z: zone);
Outputs trailing line of asterixes "*". To be used as end of
errormessages from test.
5_._4_ _ _ _ _ _ _ _F_u_n_c_t_i_o_n_ _c_h_e_c_k_r_e_s_u_l_t_ 5.4
FUNCTION check _result (VAR z: zone; inc: check _descr): boolean;
Is used to check whether a call of CREATE, LINK or UNLINK is
successful or not.
If not ok, an errormessage is output via the zone and the
function returns false.
\f
5_._5_ _ _ _ _ _ _ _F_u_n_c_t_i_o_n_ _c_o_n_v_e_r_t_h_e_x_ 5.5
FUNCTION converthex (int: integer): alfa;
Converts a 16 bit integer into a string of 2 digits, a space and
2 digits (a hexdigit).
5_._6_ _ _ _ _ _ _ _P_r_o_c_e_d_u_r_e_ _m_e_m_o_r_y_c_o_n_f_i_g_u_r_a_t_i_o_n_ 5.6
PROCEDURE memory _configuration (VAR z: zone);
Outputs the modulnumbers, which are occupied by RAM and ROM.
5_._7_ _ _ _ _ _ _ _F_u_n_c_t_i_o_n_ _g_e_t_b_u_f_ 5.7
FUNCTION get _buf (VAR r: reference;
VAR allo, s: semaphore;
no, l _r _size: integer): byte;
Dynamic buffer allocation getting "no" of buffers from the allo-
cator with size "l _r _size". Return value is number of buffers
(kind). Return value is zero if no buffers available or if asked
for too many. "allo must be semvector (allocatorsem)@".
5_._8_ _ _ _ _ _ _ _F_u_n_c_t_i_o_n_ _g_e_t_p_a_r_a_m_ 5.8
FUNCTION getparam (par: integer; VAR r: reference): param _type;
The testprogram parameter needed for inspection is picked from
the record of parameters (ps _type) and placed in one of the
variables "lett, yesno, numb".
\f
5_._9_ _ _ _ _ _ _ _P_r_o_c_e_d_u_r_e_ _r_u_n_u_p_d_a_t_e_ 5.9
PROCEDURE runupdate (VAR r:reference);
Communicates the parametersegment to TOP asking for an update of
the run number.
5_._1_0_ _ _ _ _ _ _P_r_o_c_e_d_u_r_e_ _m_a_x_i_m_u_m_m_e_s_s_ 5.10
PROCEDURE maximummess (VAR r: reference);
Communicates the parametersegment to TOP asking for an update of
the error count (errtxtstart is called by TOP).
5_._1_1_ _ _ _ _ _ _P_r_o_c_e_d_u_r_e_ _g_e_t_p_e_n_d_i_n_g_ 5.11
PROCEDURE get _pending (VAR r: reference);
Communicates the parametersegment to TOP asking for returned
drivermessages if any.
5_._1_2_ _ _ _ _ _ _P_r_o_c_e_d_u_r_e_ _t_e_s_t_o_u_t_p_u_t_ 5.12
PROCEDURE testoutput (txt, no, chan, expec, rece,
by _no, blck: integer;
VAR r: reference;
ertext: erportion;
VAR o _zone: zone);
Designed to format the erroroutputs from device tests. Makes a
headline telling about the error, and one or more lines associa-
ted to the error. "no" is module number (level), "chan" is chan-
nel number (printed if different from -1), "expec" expected pat-
tern (printed if either expec or rece or both are different from
-1), "rece" received pattern, "by _no" byte number (printed if
different from -1), "blck" blocksize (printed if different from
-1).
"ertext" is the errortexts related to the test.
\f
5_._1_3_ _ _ _ _ _ _P_r_o_c_e_d_u_r_e_ _g_e_t_a_n_s_w_e_r_ 5.13
PROCEDURE get _answer (VAR messema, resqu: semaphore;
VAR ans _ref: reference;
VAR terminate: boolean);
Awaits answers from TOP80 and checks the result. If U1 is differ-
ent from running the variable, terminate is true. If the answer
contains any returned driver messages, they are unstacked and
sent to the fifo "resqu".
5_._1_4_ _ _ _ _ _ _P_r_o_c_e_d_u_r_e_ _s_a_v_e_e_r_r_ 5.14
PROCEDURE save _err (VAR queue, answer: semaphore;
VAR er _mess: pool 1;
er _type, ch, b _length, by _no, exp,rec: integer;
VAR out _lost: integer;
VAR adm _state: adm _type);
Saves information about an occurred error that is to be printed
later in the test cycle, in the fifo "queue".
\f
F_ 6_._ _ _ _ _ _ _ _ _T_E_X_T_ _F_I_L_E_S_ _F_O_R_ _T_O_P_8_0_ 6.
The names of the text files that contain the total TOP80 system
are:
LTOP80TOP
LTOP80TPS
LTOP80LIB
TOP80ENV
The names of the textfiles for TOPIO are:
LTOPIOLIB
TOPIOENV
The multijob is called TOPJOB.
\f
F_
\f
F_ A_._ _ _ _ _ _ _ _ _R_E_F_E_R_E_N_C_E_S_ A.
1 RCSL No 42-i1542:
RC3502 - PASCAL80, Reference Manual
2 RCSL No 30-M301:
RC3502 TOPIO, Input/Output Routines, Programming Guide
3 RCSL No 52-AA964:
PASCAL80 REPORT
4 RCSL No 52-AA988:
PASCAL80 on the RC3502 Computer, How to use the RC3502
\f
F_B_._ _ _ _ _ _ _ _ _T_O_P_8_0_ _E_N_V_I_R_O_N_M_E_N_T_ B.
\f
F_
\f
F_
\f
«eof»