Abfrage mit RK512 !?

Oeltermann

Level-1
Beiträge
5
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
ich versuche mit der Siemens "ComWare.dll" ( 3964r Protokollltreiber )
an einer "Schleicher SPS" daten auszulesen, über ein 3964R Modul.

Wenn ich die Anleitungen zum Protokoll richtig lesen mus ich den Datenblock wie folgt aufbauen:

char c[]={0x00,0x00,0x45,0x44,0x09 , 0x70,0x00,0x02,0xFF,0x1F};

1+2 = 00h ( Telegramm nr. und Folge )
3 = 45h ( GET )
4 = 44h ( Typ Datenbaustein ) << ??
5 = 09h ( DB 9 )
6 = 70h ( Offset 112 )
7 = 00h (länge high byte )
8 = 01h (länge low byte )
9 = FFh ( ?? steht so in bei spiel als Default )
10 = 1Fh ( ?? steht so in bei spiel als Default )

Ich brauche also DB9 offset 112 1 WORT ( 2Byte ?)

obiger Datenblock wird über die Schnittstelle verschickt und durch die SPS Modul mit "NAK" quittiert.

Kann mit jemand sagen wie ich das richtig 'verpacken' muss damit ich eine Antwort bekomme ?


gruss
K.O.
 
In Byte 9 steht bei RK512 die Bytenummer des Koordinierungsmerkers, 0xFF wenn kein KM verwendet wird.
In Byte 10 steht Bit 0..3 die Bitnummer des KM (0x0F wenn kein KM verwendet wird) und in Bit 4..7 die Nummer der CPU (0xF0 wenn keine spezielle CPU angegeben wird).
Vielleicht gehts ja mit 0xFF 0xFF in Byte 9 und 10 besser.
Was geht tatsächlich über die Schnittstelle hin- und her? Notfalls mit http://www.serial-port-monitor.com/ Table-View und Reqeust-View aufzeichnen, danach je Fenster exportieren und mir mailen. Kann dann ggf. mehr dazu sagen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
hier 2 sätze aus den seriellen Mitschnitt.
Bei der 2. Zeile habe ich das 9+10 Byte auf FF gesetzt wie du meinstes.


02 10 00 00 45 44 09 70 00 01 FF 1F 10 03 E1 15

02 10 00 00 45 44 09 70 00 01 FF FF 10 03 01 15

 
Da würde ich auch mit 15 antworten. Mal im Ernst, nach meinen Berechnungen (allerdings mit dem Taschenrechner) kommt als Prüfsumme 6A raus und nicht 01.
 
Es ist RK512, nicht nur 3964R

Hallo,

Rainer Hönle schrieb:
Da würde ich auch mit 15 antworten

Genau, 0x15 --> NAK --> negativ acknowledgement
Der Partner ist aus irgendeinem Grunde mit dem empfangenen Telegramm nicht einverstanden. Eigentlich sollte er ein Reaktionstelegramm senden, wenn alles richtig abläuft. Das "NAK" setzt den Treiber zurück und man hat einen neuen Versuch frei ....

Gruss

Question_mark
 
Zuviel Werbung?
-> Hier kostenlos registrieren
CPU-Nummer, da hat sich mal was geändert ....

Hallo,

Rainer Hönle schrieb:
und in Bit 4..7 die Nummer der CPU

Ja, bei Steuerungen, die Mehrprozessorfähig sind, also 135U, 155U. Bei den Protokollen für 150S, 150U und so weiter gibt es keine explizite CPU-Nummer.
Siemens hat da mal am RK512-Protokoll für die Mehrprozessorfähigen AG's herumgefrickelt. Je nachdem, wie alt der verwendete Treiber ist, kann der Partner sich vielleicht bei der CPU-Nummer verschlucken ...

Gruss

Question_mark
 
Uppsss ...

Hallo,

Rainer Hönle schrieb:
(0xF0 wenn keine spezielle CPU angegeben wird).

Uppsss, das habe ich doch glatt übersehen. Mein voriger Post sagt genau das gleiche aus, hätte ich mir sparen können.
Der Telegrammkopf ist ok (sofern der DB beim Partner vorhanden und lang genug ist), dann bleibt doch nur der BCC übrig, aber heute habe ich keine Lust mehr, den BCC nachzurechnen.

Gruss

Question_mark
 
Hatten die Daten verändert :-(

02 10 00 00 45 44 09 70 00 01 FF 1F 10 03 8A 15

02 10 00 00 45 44 09 70 00 01 FF FF 10 03 6A 15



Hier die unveränderte Ausgabe der beiden versuche.......
Ändert aber leider nix an dem NAK
Ich erwähne nochmal das ich hier eine Schleicher ProModul-U habe.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das Telegramm ist jetzt meines Erachtens nach korrekt. Somit scheint der Fehler tiefer zu sitzen. Kann die Schleicher 3964R oder nur 3964? Ist die Schleicher wegen der ungeraden Anzahl vielleicht verärgert? Einfach mal 02 (Worte) probieren und schauen was passiert.
 
Ich habe es jetzt mit 2 Worte jeweils mit und ohne Blockcheck probiert, immer NAK als Antwort bekommen.

Wenn das BCC nicht übertragen wird ist eine deutliche verzögerung bis zum NAK zu bemerken, scheinbar erwartet die Steuerung das BCC....

mfg
K.O.
 
Wie lang ist der DB in der Schleicher? Rechnet die Schleicher in Bytes oder in Worten? Was passiert beim Lesen von Offset 0? Muss bei der Schleicher noch irgend etwas freigeschaltet werden? Was sagt der Schleicher-Support?
 
nu gehts....

Die parität war schuld. :rolleyes:
Die mir genannten Einstellungen waren falslch, mit 'Even' Parität funktioniert es.

Danke allen die sich beteilig haben.:cool:
 
Die Antwort NAK kommt auch, wenn die Parität falsch eingestellt ist.
Probier mal 8E1.
Ist im Prinzip richtig. Aber hätte dann nicht bereits nach dem 02 ein Fehler kommen müssen? Wenn ungerade (oder keine) Parität eingestellt war, hätte es doch dort bereits einen Framing-Error geben müssen. Oder sehe ich das verkehrt?
 
Ist im Prinzip richtig. Aber hätte dann nicht bereits nach dem 02 ein Fehler kommen müssen? Wenn ungerade (oder keine) Parität eingestellt war, hätte es doch dort bereits einen Framing-Error geben müssen. Oder sehe ich das verkehrt?

Nicht unbedingt: Sagen wir Sender S ist auf 8N1 eingestellt,
Schleicher E auf die üblichen 8E1.
Sendet S die 2, so interpretiert E das Stoppbit als Parität.
Und die stimmt.
Framingfehler würde E schon erkennen, aber da ist ja die Pause,
die S machen muss, um auf das DLE zu warten...
 
Zurück
Oben