TIA DPRD_DAT liest komischen Wert aus

blimaa

Level-3
Beiträge
1.012
Reaktionspunkte
117
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi

TIA V15.1, SPS Firmware 2.6


Ich möchte mit DPRD_DAT einen Keyence Messtaster GT2 über Profinet auslesen. Nun habe ich die Struktur gemäss Betriebsanleitung aufgebaut. DPRD_DAT gibt als Fehlercode "0" raus, sollte also passen. Nun ist am Schluss von den Werten noch den Messwert (Int32). Also habe ich ein DINT deklariert (auch mit DWORD probiert). Leider wird mir der Wert immer wie mit einem Offset ausgelesen. Sprich die ersten 8 Bit sind alles Nulls und ab Bit 9 fängt der Wert erst richtig an.
Wenn ich direkt vom ED1319 auslese, bekomme ich den Wert richtig.
Ich habe es schon als UDT und auch als Struct deklariert. Immer das selbe Problem.
DPRWD1.jpgDPRWD2.jpg

Was mache ich falsch? Ist ja nicht das erste mal, dass ich diesen Baustein verwende :rolleyes:

gruss blimaa
 
Moin,
deine Struktur ist 24 Bits lang, also 3 Byte und wird vom TIA automatisch um 8 Bits auf eine gerade Word-Adresse erweitert. Erst auf dieser geraden Word-Adresse beginnt dein DInt. Zeig mal die dazugehörige Hardware-Konfig.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Sieht aus wie die Keyence Daten 4 Bytes für die BOOLs sind, obwohl es gibt nur 24 Bytes Nutzdaten. Dies weil den DWORD mit in den erste Byte mit Null gefüllt ist. Also die Daten sind tatsächlich 4 + 4 Bytes = 8 Bytes.
In den Fall sollte aber DPRD_DAT ein Fehler Status ausgeben, weil es versucht ein konsistenten Datenbereich mit den Falsche Byte länge zu lesen.
Oder sind die Daten nicht konsistent ?

Aber
Wenn ich direkt vom ED1319 auslese, bekomme ich den Wert richtig
Also ED1319 ist eine ungerade Addresse. Das ist auch verdächtig. Das passt nicht mit die Teorie 4+4 Bytes. Es pass aber mit 3+7 Bytes.

Ja bitte die Adresszuweisung in den HW Konfig zeigen.
 
Hi
Ja das mit den Auffüllen hatte ich auch mal gedacht. Darum habe ich noch die Struktur mit 8 Bits vor dem Messwert aufgefüllt. --> Gleiches Verhalten!



Keyence_2.jpgKeyence.jpg
Hab mal einen Auszug aus dem Manual beigelegt und die HW Konfig.
 
Hab mal einen Auszug aus dem Manual beigelegt und die HW Konfig.
Das scheint tatsächlich schon von Keyence so Praxis-untauglich geplant zu sein. Der INT32-Komparatorwert soll tatsächlich auf einer ungeraden Adresse beginnen :roll:
Da wirst Du wohl nach DPRD_DAT die 4 Bytes mit dem INT32 auf eine gerade Adresse verschieben/kopieren müssen. Oder das Modul auf eine ungerade E-Adresse im PAE legen.
Was für eine CPU hast Du?

PS:Gibt es eigentlich gar keine Fehler/Warnung von DPRD_DAT, wenn der Speicherbereich an RECORD größer ist als die Modullänge? (Modul: 23 Byte, Struct: 24 Byte)

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Erstens, die einzelne Bytes in GT_eingaenge_struct anlegen.
Etwa wie
Byte_1 STRUCT
Hi : BOOL
Lo : BOOL
.
.
Byte_2 STRUCT
Komparatorwert_ungueltig : BOOL
.
.
Byte_3 STRUCT
.
.
Byte_4 STRUCT // dummy
.
.
Messwert : DWORD

Mit DPRD_DAT in ein 3+4 Byte Buffer einlesen.
Dann die einzelne Strukturen 1-zu-1 von Buffer in GT_eingaenge kopieren.
Etwa wie:
GT_eingaenge.Byte_1 := Buffer.Byte_1
GT_eingaenge.Byte_2 := Buffer.Byte_2
GT_eingaenge.Byte_3 := Buffer.Byte_3
GT_eingaenge.Messwert := Buffer.Byte_4-5-6
 
Hi

Ich habe eine 1511 (Firmware 2.6).
Wie ist dann der Zusammenhang zwischen Eingangsadresse und DPRD_Dat? Wenn ich die Eingansadresse auf eine Ungerade lege, dass der Messwert auf einer Gerade zu liegen kommt, dann sollte dies doch aber auf DPRD_DAT keinen Einfluss haben oder nicht? Ich lege ja nicht die Eingangsadresse an den Baustein sondern die HW-Submodule Nummer (also die Symbolkonstante).
 
DPRD_DAT fungiert wie es soll.
Das Problem entsteht weil du die Daten sinnvollerweise strukturiert, wobei TIA immer neue Strukturen auf gerade Byte Adressen starten will.
Auf diesen Grund kommt es ein unerwünschte Byte mitten in die Daten.

edit: Ich weis nicht ob es macht ein Unterschied wenn GT_eingaenge "optimiert" ist. Ob das überheupt geht mit DPRD_DAT.
Ich verwende immer "nicht optimiert".
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Verwendung DPRD_DAT: Das Problem ist nicht, ob das Modul auf einer geraden oder ungeraden E-Adresse beginnt, sondern die symbolische Struktur an RECORD beginnt auf jeden Fall mit einer geraden Adresse, so daß das 4.-7.Byte mit dem INT32 an einer ungeraden Adresse zu liegen kommt, auf die man aber keinen INT32 deklarieren kann.
Wenn Du das Modul auf eine ungerade E-Adresse im PAE legst, dann wird DPRD_DAT nicht verwendet, dann könntest Du ab der Adresse 1 Byte vor der tatsächlichen Anfangsadresse eine Struktur deklarieren, die mit einem Dummy-BYTE beginnt, dann 24 BOOL, dann ein INT32.

Harald
 
Wie ist denn die Keyence-Seite zu konfigurieren? Könntest du dort nicht vielleicht dieselbe "Reserve" auffüllen, dass der Keyence seinen Messwert dann korrekt auf einer gerade Adresse zur Verfügung stellt?
 
Die Keyence Seite kann ich nicht konfigurieren. Ist so vorgegeben.
Der Vorteil ist doch von DPRD_DAT, dass ich keine Adressen anschliessen muss, sondern nur die HW_Submodulkonstante. Daher verstehe ich nicht, warum man dann an der Adressen herumspielen sollte.
Trotzdem habe ich jetzt die Anfangsadresse mal auf ungerade gelegt. Gleiches Resultat.
Ich verwende bei anderen Kommunikationen auch "optimiert", daher sollte dies schon gehen...
Also heisst das für mich, ich habe keine Chance dies mit DRPD_DAT zu machen, da Keyence nur 3 Bytes vor dem Messwert projektiert hat...

Interessanterweise habe ich mal ein Array [0..80] of bool an Record gelegt. Auch dort konnte ich die richtige Bitreihenfolge nicht erkennen!
 
Gibst Du immer so schnell auf? ;)
Die Lösung ist relativ simpel, eher eine Fleißaufgabe. Kurz gefasst ungefähr so sollte es funktionieren:
Code:
TYPE GT2_raw : STRUCT [COLOR="#008000"]//7 Byte Rohdaten + FüllByte[/COLOR]
    Data : ARRAY[1..7] OF BYTE;
    Byte_8 : BYTE;
  END_STRUCT;
END_TYPE
[COLOR="#008000"]//oder:
//TYPE GT2_raw : STRUCT //7 Byte Rohdaten + FüllByte
//    Data : ARRAY[1..8] OF BYTE;
//  END_STRUCT;
//END_TYPE[/COLOR]

TYPE GT2_mod : STRUCT [COLOR="#008000"]//modifizierte Struktur mit Füllbyte für symbolisches Handling[/COLOR]
    High : BOOL;
    Low  : BOOL;
    ...
    Reserve_3_6 : BOOL;
    Reserve_3_7 : BOOL;
    FillByte_4 : BYTE;
    Messwert : DINT;
  END_STRUCT;
END_TYPE

VAR_TEMP
  tmp_InStruct : GT2_raw;
  tmp_OutStruct [B]AT[/B] tmp_InStruct : GT2_mod;
...
BEGIN

[COLOR="#008000"](* 7 E-Bytes von GT2 einlesen *)[/COLOR]
#iResult := DPRD_DAT(LADDR:=<hwid>, RECORD => #tmp_InStruct.Data);
[COLOR="#008000"]//oder[/COLOR]
#iResult := DPRD_DAT(LADDR:=<hwid>, RECORD => #tmp_InStruct);

[COLOR="#008000"](* 4.-7. Byte zu DInt-Messwert verschieben *)[/COLOR]
#tmp_InStruct.Byte_8  := #tmp_InStruct.data[7];
#tmp_InStruct.data[7] := #tmp_InStruct.data[6];
#tmp_InStruct.data[6] := #tmp_InStruct.data[5];
#tmp_InStruct.data[5] := #tmp_InStruct.data[4];
#tmp_InStruct.data[4] := 0; [COLOR="#008000"]//tmp_OutStruct.FillByte_4 löschen[/COLOR]

[COLOR="#008000"](* Test/Beobachten *)[/COLOR]
#tmp_DInt := #tmp_OutStruct.Messwert;

[COLOR="#008000"](* modifizierte Struktur in Anwender-DB kopieren *)[/COLOR]
"Station_16_DB".Keyence_Messtaster_GT2_BG1602.GT_Eingaenge_Struct := #tmp_OutStruct;

[COLOR="#008000"]//"Station_16_DB".Keyence_Messtaster_GT2_BG1602.GT_Eingaenge_Struct muß vom Typ GT2_mod sein[/COLOR]
Harald
 
Aufgegeben habe ich ja icht ;), hab nur eine schönere Lösung gefunden.

Bei deiner Lösung, müsste ich ja das gleiche bekommen, wie wenn ich ein genug grosses Array of Bool anschliesse?
 
Bei deiner Lösung, müsste ich ja das gleiche bekommen, wie wenn ich ein genug grosses Array of Bool anschliesse?
Man muß 4 Bytes umspeichern. Wenn Du ein Bool-Array nimmst und das ganze symbolisch programmieren willst, dann müßtest Du 32 Bits einzeln umspeichern. :p Und Vorsicht im Zusammenhang mit "optimiertem" Speicher: da sind BOOL Bytes und keine Bits.

Harald
 
@PN/DP Jup habe nicht alle umgespeichert, allerdings die einzelnen Bits angeschaut, ob irgend was gleich wie aus dem E-Bereich... hab allerdings nichts gefunden.


@JesperMP Siehe Anhang.

Mit WRREC kann ich auch die Grenzwerte und die Zählrichtung einstellen
Keyence_3.jpg

Trotzdem vielen Dank für eure Hilfe!
 
Öhm. Frage ich auch.
Ich hatte gedacht dass du irgendwie mit RDREC auf einmal die Daten in dein GT_eingaenge Struktur bekam, und das war das "schöne" dabei.
Aber du lest nur Messwert. Dass konntest du auch mittels PED1319. Was macht RDREC "schöner" ?
 
das Ziel war, ein Baustein für diesen Messtaster, welcher als Adresse nur das Submodule zum Anschliessen hat.
Es wird ja auch noch die Unter und Obergrenze zum Messtaster gesendet sowie auch die Messrichtung.
Dies kann ich nur mit WRREC schreiben.

Dachte bekomme so die Infos direkt vom Eingangsbereich ohne Eingangsadressangabe.


Gesendet von meinem BLN-L21 mit Tapatalk
 
Zurück
Oben