Also ich würde auch die zweite Version (mit Array) bevorzugen.
Allerdings würde ich (bei beiden Versionen) weitestgehend mit Konstanten arbeiten. Ist zwar mehr Schreiberei und auf den ersten Blick auch nicht wirklich übersichtlich, aber spätestens der nächste Kollege der an diesem Projekt arbeiten muß wird es einem danken...
Also etwa so:
CONST num CMaxItems:=3;
CONST num CItemNo4711:=1;
CONST num CItemNo4712:=2;
CONST num CItemNo4799:=3;
CONST num CIN4711_Param1:=15;
CONST num CIN4712_Param1:=19;
CONST num CIN4799_Param1:=22;
! Das geht leider bei Persistenten nicht, da bei PERS keine Deklaration mit bezeichneten Konstanten erlaubt ist
! PERS num nOutPut_Array{CMaxItems}:=[CIN4711_Param1,CIN4712_Param1,CIN4799_Param1]; <- Fehler !!!
! aber bei VARs gehts
VAR num nOutPut_Array{CMaxItems}:=[CIN4711_Param1,CIN4712_Param1,CIN4799_Param1];
! wenn's PERS sein muß, dann nur so:
PERS num nOutPut_Array{CMaxItems}:=[15,19,22];
! in der "alten" Version sähe es dann so aus:
TEST nMould_No
CASE CItemNo4711 : nOutput := CIN4711_Param1;
CASE CItemNo4712 : nOutput := CIN4712_Param1;
CASE CItemNo4799 : nOutput := CIN4799_Param1;
DEFAULT: Stop;
ENDTEST
Ein Nachteil der Array-Methode ist jedoch das die Indizierung lückenlos sein muß und bei Eins beginnt. Wenn z.B. die Teile/Artikel/Item-Nummer von einem übergeordneten Prozessleitrechner in ASCII-Form ("ABC-221244", "ADB-469809", "XYZ-909850", usw.) geliefert wird, oder als Ganzzahl mit großen Lücken (z.B.: 0, 23, 567, 698977, usw.) dann müsste man diese Nummer erst wieder in einen fortlaufenden Index konvertieren und dann kann man schon fast wieder besser mit TEST bzw. IF THEN ELSE arbeiten.
Bei einer großen Anzahl von Varianten und/oder bei großen Parametersätzen würde ich aber ohnehin alles in eine externe Konfig.-Datei packen die vom Rob gelesen wird und mit einem (Text-)Editor angepasst werden kann.
Schönes WE noch
Rainer