Hallo,
ich habe da mal ein etwas komplexeres Problem:
In der _config.rsc steht zu einer Variablen leider nur die Bytelänge und nicht der eigentliche Datentyp. Um die Daten sauber lesen zu können, brauche ich aber den Datentyp für die Unterscheidung.
Bsp: Datenlänge 4 Byte : Was ist es? ein DWORD, DINT, String[4], ein REAL, ... ??
Also muss ich über das Feld _config.rsc->id den Namen der RAP Datei ermitteln und die RAP Datei mit einlesen.
Wenn nun in der RAP Datei wiederum "Variants" benutzt werden, wäre ich davon ausgegangen, das in der _config.rsc in den Feldern "inpVariant" und "outVariant" die Varianten stehen, zumindest so, wie sie in der RAP angeben sind.
Soweit ich das sehe, sind die Varianten in einer RAP als String angegeben. In dem Beispiel, was ich gefunden habe, steht zBsp. "002". In der _config.rsc scheint das aber ein Integer Wert zu sein (wobei bei mir immer 0 drinsteht).
Hier meine erste Frage: Was genau steht in der _config.rsc; ist es die Integer Interpretation des String Feldes aus der RAP oder ist es zBsp. die (0 basierte) ID des Variants aus der RAP oder ist es noch etwas anderes?
leider hilft mir da piTest auch nicht weiter, bei Strings kommt zBsp. "internal Error", es scheint dort nur bei Ganzzahltypen zu funktionieren.
Gruß,
Heron
_config.rsc/*.rap
Ich werde den verantwortlichen Kollegen bitten, das hier im Forum genau zu erläutern. Kann ein wenig dauern...
Unser RevPi Motto: Don't just claim it - make it!
Hallo Heron,
zur Beantwortung Deiner Fragen:
1. es ist tatsächlich so, dass die eigentlichen Geräte-Daten (input, output etc.), die in den RAP-Dateien definiert sind, NICHT noch einmal redundant in der RSC-Datei gespeichert werden. Wenn sie zur Verarbeitung benötigt werden müssen so, wie Du es schon beschreibst, die RAP-Dateien zusätzlich zur RSC Datei gelesen werden.
2. der 'inpVariant' und 'outVariant' Wert in der RSC-Datei ist tatsächlich der 0-basierte Index der in der RAP-Datei vorhandenen Variante. D.h. wenn es beispielsweise in einer RAP-Datei drei Input-Varianten gibt, und in 'PiCtory' die erste der drei Varianten ausgewählt wurde, dann enthält 'inpVariant' den Wert 0.
Der "variants"/"id"-String in der RAP Datei (z.B. "002") hat für die Zuordung keinerlei Bedeutung; das ist lediglich ein sprechender Name der Variante, der in einer zukünftigen 'PiCtory' Version voraussichtlich (optional) statt der Anzahl der Eingänge / Ausgänge in den gleichnamigen Spalten der "Gerätedaten" Tabelle angezeigt werden kann, um die Identifizierung von Varianten leichter zu machen. Dieser "id"-Wert wird aktuell in 'PiCtory' noch nirgends genutzt oder angezeigt - er ist, wie gesagt, wie zukünftige Verwendung gedacht.
Gruß
Frank
zur Beantwortung Deiner Fragen:
1. es ist tatsächlich so, dass die eigentlichen Geräte-Daten (input, output etc.), die in den RAP-Dateien definiert sind, NICHT noch einmal redundant in der RSC-Datei gespeichert werden. Wenn sie zur Verarbeitung benötigt werden müssen so, wie Du es schon beschreibst, die RAP-Dateien zusätzlich zur RSC Datei gelesen werden.
2. der 'inpVariant' und 'outVariant' Wert in der RSC-Datei ist tatsächlich der 0-basierte Index der in der RAP-Datei vorhandenen Variante. D.h. wenn es beispielsweise in einer RAP-Datei drei Input-Varianten gibt, und in 'PiCtory' die erste der drei Varianten ausgewählt wurde, dann enthält 'inpVariant' den Wert 0.
Der "variants"/"id"-String in der RAP Datei (z.B. "002") hat für die Zuordung keinerlei Bedeutung; das ist lediglich ein sprechender Name der Variante, der in einer zukünftigen 'PiCtory' Version voraussichtlich (optional) statt der Anzahl der Eingänge / Ausgänge in den gleichnamigen Spalten der "Gerätedaten" Tabelle angezeigt werden kann, um die Identifizierung von Varianten leichter zu machen. Dieser "id"-Wert wird aktuell in 'PiCtory' noch nirgends genutzt oder angezeigt - er ist, wie gesagt, wie zukünftige Verwendung gedacht.
Gruß
Frank
Hallo,
vielen Dank für die Info!!
Gruß,
Heron
vielen Dank für die Info!!
Gruß,
Heron
