S5 115 - Profibus - S7 312

Zuviel Werbung?
-> Hier kostenlos registrieren
Verbindungspartner

Tja, es ist von der Hardware her ein PC. Die Firma hat diese Kläranlagenleittechnik selber geschrieben.
Ich kann mal fragen, was für ein Entwicklungstool die verwenden....
Gruß,
Aksels
 
OK, das war schon, was ich wissen wollte.

Auf dem Leitrechner läuft eine fertige Software, welche die Option bietet, über TCP/IP mit einer S7 zu kommunizieren (D.h. Du musst auf PC-Seite nichts programmieren).

Du kannst, wie ich annehme, auf dem Leitsystem direkt die DB-Nummer angeben, welche Du in der S7 verwendet hast, und das Leitsystem holt sich dann zyklisch (bspw. alle 2 Sekunden) die Werte aus diesem DB. Richtig?

In diesem Fall wäre das Protokoll so wie ich das sehe das Siemens eigene Protokoll (von Siemens meist als "S7 Kommunikation" bezeichnet).



Zu den "Glitches" fallen mir 2 Dinge ein:
  • Die S7 hat keine Bereichsprüfung. Wenn Du einen Puffer mit 228 Bytes anlegst und die Empfangs-Funktion 232 Bytes empfängt, dann überschreibt sie 4 Bytes an einer fremden Stelle. Möglicherweise entstehen dadurch die Fehlwerte. Verwende 1024 Bytes, das ist zumindest bei den Siemens-FBs die ich verwendet habe, so vorgesehen.
  • Es gibt verschiedene "ByteOrders": Manche Systeme verwenden bei einem 16-Bit Wert das erste Byte als höherwertiges, andere machen das umgekehrt. Machen die Werte sinn, die er ohne die "<>" empfängt?

grx
hr
 
Puffer vergrößert.

Guten Abend allerseits.
Habe die Puffer mal auf 1024 vergrößert und die Datenbausteine doppelt so groß gemacht.
Ich bekomm dann antwort, obs was gebracht hat und melde es hier.


Gruß,
Aksels
 
Keine Veränderung.

Die Glitches sind immer noch da.
Ich muss doch mal testen, ob in meinem DB die Daten nicht schon falsch drinstehen. Hab seither angenommen daß die im DB noch richtig sind und erst beim Transport über Ethernet kaputt gehen. Aber vielleicht sehe ich das nicht im Step7. Dann könnte die FMS-Verbindung fehlerhaft sein....
Fragen über Fragen.


Gruß,
Aksels
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Neue Infos.

Hallo Leute.
Hab mir die Daten in meinen DBs mal angeschaut. Da seh ich keine Glitches.
Hab mal alles durchbeobachtet. Dabei ist mir folgendes aufgefallen:
Der Status und der Error zittern immer zwischen 0 / 8181 und 1 / 8183
8181 ist Auftrag läuft. 8183 bedeutet
Die Projektierung fehlt oder der Dienst im Ethernet-CP ist noch nicht gestartet.
http://asz.dyndns.org/F1.JPG
http://asz.dyndns.org/F2.JPG

Ich sehe nie daß "Done" true werden würde.
Der Mensch auf der Empfängerseite bekommt aber Daten. :confused:
Nur eben, daß die manchmal verstümmelt sind.
Im NCM-S7 Diagnose sieht es so aus:
http://asz.dyndns.org/F3.JPG
http://asz.dyndns.org/F4.JPG

Die Verbindung so.
http://asz.dyndns.org/F5.JPG
http://asz.dyndns.org/F6.JPG

Kann da irgendjemand was absonderliches erkennen?

Gruß,
Aksels
 
Code:
>ping asz.dyndns.org

Ping asz.dyndns.org [87.106.57.3] mit 32 Bytes Daten:

Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.

Ping-Statistik für 87.106.57.3:
    Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4 (100% Verlust),
ERROR 404: Dein Webserver ist down.:TOOL:
 
Ich sehe nie daß "Done" true werden würde.
Der Mensch auf der Empfängerseite bekommt aber Daten. :confused:
Nur eben, daß die manchmal verstümmelt sind.

Kann da irgendjemand was absonderliches erkennen?

Gruß,
Aksels

Ich weiß nicht ob das schon kam. Ich denke, "Done" ist nur einen Zyklus lang da. Du solltest dir das mal testweise mit einem freien Merker fangen.

U #Done
S MX.Y

Solange "Auftrag läuft" solltest du keinen neuen Auftrag anstoßen, falls du das nicht schon so hast. Weiß allerdings jetzt auch nicht, ob ein Auftrag bei de7nen FC/FB/SFC/SFB mit einer Flanke angestoßen wird.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nächstes Experiment.

So, habe jetzt noch ein Experiment.
Ich habe einen neuen DB aufgemacht.
Die Zählwerte beider KRs dort hineinkopiert (move).
Diese Baustein mittels

CALL "AG_SEND"
ACT :=M56.0
ID :=1
LADDR :=W#16#110
SEND :="DBZaehlwerte".Data
LEN :=128
DONE :=M56.1
ERROR :=M56.2
STATUS:=MW58

und

R M 56.0
SET
U M 56.1
SPB don3
SET
U M 56.2
SPB err3
SPA end4
don3: S M 56.0
SPA end2
err3: NOP 1
NOP 1
S M 56.0
end4: NOP 0


freigegeben.
Nun habe ich ab und zu die Glitches auf dem neuen DB214 und auf dem DB212, scheinbar nie gleichzeitig. Vorher waren sie auf DB210. Irgendwas hat sich also verschoben.
Ob ich nochmal eine neie Verbindung projektieren soll?

Gruß,
Aksels
 
Umschreiben

Hallo liebe Mitstreiter.

Ich versuche gerade das Programm umzuschreiben.
Dazu wollte ich einen FB anlegen.
In dem FB ist das AG_Send.
Den "SEND" Parameter wollt eich natürlich als IN-Schnittstelle übergeben.
Der ist am AG_Send vom Typ "ANY". ANY lässt er mich auch als In-Variable anlegen, aber wenn ich diese dann an der AG_Send weitergeben möchte heisst es immer "Unzulässige Parameterzuweisung".
Auch als Pointer lässt er es nicht zu.
Von aussen soll an den FB dann ein Wert wie (Sym) DB100.Data kommen was P#DB100.DBX0.0 Zugriffsbreite 228 Entspricht.
Wie mache ich das?

Gruß,
Aksels
 
Update. AG-Send AG-Receive unnötig.

Habe gerade mit Siemens gesprochen.
Der meinte für Fetch/Write passiv brauche ich doch gar kein AG-Send AG-Receive. Da müsse man doch gar nichts programmieren, sondern nur projektieren.
Hab jetzt alle meine AG-Send und AG-Receives rausgenommen und es geht trotzdem.
Mann war das peinlich.
Ich hoffe ich erspare einem von Euch diese Peinlichkeit durch diesen Bericht.
Ist diese Vorgehensweise mit Fetch/Write passiv denn so ungewöhnlich und selten, dass das echt keiner von Euch wusste? :confused:

Gruß,
Aksels
 
Zuviel Werbung?
-> Hier kostenlos registrieren
TcpDump

Hallo Leute.

Da niemand der beteiligten Firmen der Meinung ist daß der Fehler bei Ihm liegen könnte, habe ich jetzt TCP-Dumps des Datenverkehrs angelegt.
Leider sind die Pakete nicht so gut lesbar, wie ich gehofft hatte. Weiter unten ein Auszug.
Irgendwie muss man doch eine Protokollbeschreibung herbekommen können von diesem Fetch Passiv von Siemens. Wenn von Euch keiner einen Tip hat werde ich mich wohl oder Übel auf die Odyssee bei Siemens begeben müssen.
Mich interessiert: wie kann ich einen Lesevorgang auf DB210 DW 164 identifizieren und das empfangene Datum auslesen. Es entartet nänlich immernoch sporadisch. Zählwert ist erst 20101, dann irgenwas über 3 Mrd dann wieder 20101 (oder ähnlich). Ich möchte nun sehen, ob das schon im TCP-Päckchen falsch ist (Siemens hat ein Problem) oder erst auf dem Leitrechner entartet (Leitstellenprogramm hat ein Problem).

Gruß,
Aksels

15:01:36.205308 IP 192.168.0.102.sieve > 192.168.0.100.1045: P 378901:378981(80) ack 60992 win 2048
0x0000: 0040 f203 0e66 000e 8c97 5f1e 0800 4500 .@...f...._...E.
0x0010: 0078 797e 0000 1e06 a0e7 c0a8 0066 c0a8 .xy~.........f..
0x0020: 0064 07d0 0415 5bf3 9880 147a 452a 5018 .d....[....zE*P.
0x0030: 0800 7807 0000 5335 1001 0306 0f03 00ff ..x...S5........
0x0040: 0700 0000 0000 0000 0000 0000 0000 9980 ................
0x0050: 8999 9999 80d8 9891 0001 0000 0000 0000 ................
15:01:36.205565 IP 192.168.0.100.1045 > 192.168.0.102.sieve: . ack 378981 win 17456
0x0000: 000e 8c97 5f1e 0040 f203 0e66 0800 4500 ...._..@...f..E.
0x0010: 0028 3ee5 0000 4006 b9d0 c0a8 0064 c0a8 .(>...@......d..
0x0020: 0066 0415 07d0 147a 452a 5bf3 98d0 5010 .f.....zE*[...P.
0x0030: 4430 8f3c 0000 3000 0018 00c6 D0.<..0.....
15:01:36.261684 00:0e:8c:97:5f:1e (oui Unknown) > 01:80:c2:00:00:0e (oui Unknown), ethertype Unknown (0x88cc), length 147:
0x0000: 0180 c200 000e 000e 8c97 5f1e 88cc 0209 .........._.....
0x0010: 0773 372d 6370 3334 3304 0907 706f 7274 .s7-cp343...port
0x0020: 2d30 3031 0602 0014 1038 0501 c0a8 0066 -001.....8.....f
0x0030: 0300 0000 012c 0000 0001 0000 0000 0000 .....,..........
0x0040: 2262 0000 0001 0000 0001 0000 0002 0000 "b..............
0x0050: 0001 0000 0003 0000 0008 0000 0001 0000 ................
15:01:36.407680 IP 192.168.0.100.1045 > 192.168.0.102.sieve: P 60992:61008(16) ack 378981 win 17520
0x0000: 000e 8c97 5f1e 0040 f203 0e66 0800 4500 ...._..@...f..E.
0x0010: 0038 3ee6 0000 4006 b9bf c0a8 0064 c0a8 .8>...@......d..
0x0020: 0066 0415 07d0 147a 452a 5bf3 98d0 5018 .f.....zE*[...P.
0x0030: 4470 2458 0000 5335 1001 0305 0308 01d4 Dp$X..S5........
0x0040: 0040 0032 ff02 .@.2..
15:01:36.408709 IP 192.168.0.102.sieve > 192.168.0.100.1045: . ack 61008 win 2048
0x0000: 0040 f203 0e66 000e 8c97 5f1e 0800 4500 .@...f...._...E.
0x0010: 0028 797f 0000 1e06 a136 c0a8 0066 c0a8 .(y......6...f..
0x0020: 0064 07d0 0415 5bf3 98d0 147a 453a 5010 .d....[....zE:p.
0x0030: 0800 cb5c 0000 5335 0000 0000 ...\..S5....
 
TCP Dump

Hallo,

Aksels schrieb:
wie kann ich einen Lesevorgang auf DB210 DW 164 identifizieren
Also in deinem Dump findet sich dieser Lesevorgang auf jeden Fall nicht.

Lade Dir erstmal einen vernünftigen Netzwerksniffer herunter, und zwar hier :

http://www.wireshark.org/

Installiere Wireshark, logge den Datenverkehr mit und sende mir die Logdatei per PN zu.

Gruß

Question_mark
 
Aahhrrgg

Hallo,

Aksels schrieb:
wie kann ich einen Lesevorgang auf DB210 DW 164 identifizieren

Mal ein Ausschnitt aus deinem Log

0x0000: 000e 8c97 5f1e 0040 f203 0e66 0800 4500 ...._..@...f..E.
0x0010: 0038 3ee6 0000 4006 b9bf c0a8 0064 c0a8 .8>...@......d..
0x0020: 0066 0415 07d0 147a 452a 5bf3 98d0 5018 .f.....zE*[...P.
0x0030: 4470 2458 0000 5335 1001 0305 0308 01d4 Dp$X..S5........
0x0040: 0040 0032 ff02 .@.2..

Hier wird angefordert, aus einer S5 aus dem DB 212 ab dem DW 64 insgesamt 50 DW auszulesen.

So what ????

Gruß

Question_mark
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Und noch einen ..

Hallo,

und das hier ist ein Antworttelegramm aus einer früheren Fetch Anforderung :

0x0030: 0800 7807 0000 5335 1001 0306 0f03 00ff ..x...S5........
0x0040: 0700 0000 0000 0000 0000 0000 0000 9980 ................
0x0050: 8999 9999 80d8 9891 0001 0000 0000 0000
................

Die zurückgelieferten Nutzdaten habe ich mal fett markiert. Da Dein Auszug aus dem Datenverkehr ziemlich kurz ist, kann ich nicht feststellen, aus welchem Datenbereich die Nutzdaten stammen.
Das Antworttelegramm sagt aus, dass der Telegrammverkehr für diese Fetch-Anforderung ohne Fehler durchgeführt wurde.

Gruß

Question_mark

PS : Die Nutzdaten sehen nach Gleitkommazahlen (KG) aus ....
 
Zuletzt bearbeitet:
Mein Tip ..

Hallo,

Aksels schrieb:
ob das schon im TCP-Päckchen falsch ist (Siemens hat ein Problem) oder erst auf dem Leitrechner entartet (Leitstellenprogramm hat ein Problem).

Nur mal so nebenbei bemerkt, aus meiner Erfahrung heraus darfst Du dich bei der Fehlersuche auf den Leitstellenrechner oder auf Deine eigenen Fehler konzentrieren .. :ROFLMAO: :ROFLMAO:

Gruß

Question_mark
 
Schon klar!

Tja, Question_mark, schon klar, aber ich steh dazwischen. Siemens sagt an Ihnen kanns nicht liegen, der Leittechnikbetreuer meint "Bei allen anderen Kunden funktionierts aber!"
Nun habe ich die Glitsches abgewartet und aufgezeichnet. Da ich nun weiß (besten dank) wie das zu lesen ist kann ich zeigen, daß das Päckchen kaputt oder OK ist wenns am Hub vorbeikommt. Ja nachdem muss dann Siemens her (neue Firmware für CP?) oder der Leittechnikprogrammieren, und ich bin raus!

Hehehe.

Gruß,
Aksels
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Defekte Pakete gefunden.

Guten Morgen zusammen.
Habe das defekte Päckchen gefunden.
Hier ein Paket vorher:

Code:
15:01:34.287411 IP 192.168.0.100.1045 > 192.168.0.102.sieve: P 60848:60864(16) ack 378125 win 17520
        0x0000:  000e 8c97 5f1e 0040 f203 0e66 0800 4500  ...._..@...f..E.
        0x0010:  0038 3e4d 0000 4006 ba58 c0a8 0064 c0a8  .8>M..@..X...d..
        0x0020:  0066 0415 07d0 147a 449a 5bf3 9578 5018  .f.....zD.[..xP.
        0x0030:  4470 27f0 0000 5335 1001 0305 0308 01d2  Dp'...S5........
        0x0040:  00a4 0020 ff02                           ......
15:01:34.288315 IP 192.168.0.102.sieve > 192.168.0.100.1045: . ack 60864 win 2048
        0x0000:  0040 f203 0e66 000e 8c97 5f1e 0800 4500  .@...f...._...E.
        0x0010:  0028 796a 0000 1e06 a14b c0a8 0066 c0a8  .(yj.....K...f..
        0x0020:  0064 07d0 0415 5bf3 9578 147a 44aa 5010  .d....[..x.zD.P.
        0x0030:  0800 cf44 0000 5335 0000 0000            ...D..S5....
15:01:34.320795 IP 192.168.0.102.sieve > 192.168.0.100.1045: P 378125:378205(80) ack 60864 win 2048
        0x0000:  0040 f203 0e66 000e 8c97 5f1e 0800 4500  .@...f...._...E.
        0x0010:  0078 796b 0000 1e06 a0fa c0a8 0066 c0a8  .xyk.........f..
        0x0020:  0064 07d0 0415 5bf3 9578 147a 44aa 5018  .d....[..x.zD.P.
        0x0030:  0800 3ab9 0000 5335 1001 0306 0f03 00ff  ..:...S5........
        0x0040:  0700 0000 0000 0000 647f 0000 2e01 0000  ........d.......
        0x0050:  7bb9 0000 3d8d 0000 3b5c 0000 2885 0000  {...=...;\..(...


Das defekte Paket:

Code:
15:01:35.937527 IP 192.168.0.100.1045 > 192.168.0.102.sieve: P 60960:60976(16) ack 378821 win 17520
        0x0000:  000e 8c97 5f1e 0040 f203 0e66 0800 4500  ...._..@...f..E.
        0x0010:  0038 3ec4 0000 4006 b9e1 c0a8 0064 c0a8  .8>...@......d..
        0x0020:  0066 0415 07d0 147a 450a 5bf3 9830 5018  .f.....zE.[..0P.
        0x0030:  4470 24c8 0000 5335 1001 0305 0308 01d2  Dp$...S5........
        0x0040:  00a4 0020 ff02                           ......
15:01:35.938428 IP 192.168.0.102.sieve > 192.168.0.100.1045: . ack 60976 win 2048
        0x0000:  0040 f203 0e66 000e 8c97 5f1e 0800 4500  .@...f...._...E.
        0x0010:  0028 797b 0000 1e06 a13a c0a8 0066 c0a8  .(y{.....:...f..
        0x0020:  0064 07d0 0415 5bf3 9830 147a 451a 5010  .d....[..0.zE.P.
        0x0030:  0800 cc1c 0000 5335 0000 0000            ......S5....
15:01:35.968286 IP 192.168.0.102.sieve > 192.168.0.100.1045: P 378821:378901(80) ack 60976 win 2048
        0x0000:  0040 f203 0e66 000e 8c97 5f1e 0800 4500  .@...f...._...E.
        0x0010:  0078 797c 0000 1e06 a0e9 c0a8 0066 c0a8  .xy|.........f..
        0x0020:  0064 07d0 0415 5bf3 9830 147a 451a 5018  .d....[..0.zE.P.
        0x0030:  0800 d4ed 0000 5335 1001 0306 0f03 00ff  ......S5........
        0x0040:  0700 0000 0000 0202 0005 3c31 3232 3e00  ..........<122>.
        0x0050:  0000 0000 0000 0000 3b5c 0000 2885 0000  ........;\..(...
Ein Paket nachher.

Code:
15:01:37.607689 IP 192.168.0.100.1045 > 192.168.0.102.sieve: P 61072:61088(16) ack 379517 win 17520
        0x0000:  000e 8c97 5f1e 0040 f203 0e66 0800 4500  ...._..@...f..E.
        0x0010:  0038 3f4d 0000 4006 b958 c0a8 0064 c0a8  .8?M..@..X...d..
        0x0020:  0066 0415 07d0 147a 457a 5bf3 9ae8 5018  .f.....zEz[...P.
        0x0030:  4470 21a0 0000 5335 1001 0305 0308 01d2  Dp!...S5........
        0x0040:  00a4 0020 ff02                           ......
15:01:37.608585 IP 192.168.0.102.sieve > 192.168.0.100.1045: . ack 61088 win 2048
        0x0000:  0040 f203 0e66 000e 8c97 5f1e 0800 4500  .@...f...._...E.
        0x0010:  0028 7989 0000 1e06 a12c c0a8 0066 c0a8  .(y......,...f..
        0x0020:  0064 07d0 0415 5bf3 9ae8 147a 458a 5010  .d....[....zE.P.
        0x0030:  0800 c8f4 0000 5335 0000 0000            ......S5....
15:01:37.640025 IP 192.168.0.102.sieve > 192.168.0.100.1045: P 379517:379597(80) ack 61088 win 2048
        0x0000:  0040 f203 0e66 000e 8c97 5f1e 0800 4500  .@...f...._...E.
        0x0010:  0078 798a 0000 1e06 a0db c0a8 0066 c0a8  .xy..........f..
        0x0020:  0064 07d0 0415 5bf3 9ae8 147a 458a 5018  .d....[....zE.P.
        0x0030:  0800 3469 0000 5335 1001 0306 0f03 00ff  ..4i..S5........
        0x0040:  0700 0000 0000 0000 647f 0000 2e01 0000  ........d.......
        0x0050:  7bb9 0000 3d8d 0000 3b5c 0000 2885 0000  {...=...;\..(...

In der Leittechnik sieht das dann so aus (Auf dem Linux Rechner muss man 2 h abziehen wegen UTC):

http://asz.dyndns.org/KaBlaF3.JPG

So wie es aussieht kann man doch sagen, daß das ein Siemens Fehler sein muss?
Ich habe ja für die Verbindung kein Programm (passiv fetch). Meinen DB überwache ich mit einem größer-Vergleich (die Zählwerte ändern sich sehr langsam), dann wird ein Merker gesetzt. Das passiert aber nie.

Ich werde denen das jetzt mal schicken.


Gruß,
Aksels
 
Zuletzt bearbeitet:
Paket wirklich defekt ??

Hallo,

Aksels schrieb:
So wie es aussieht kann man doch sagen, daß das ein Siemens Fehler sein muss?

Bevor Du jetzt in der falschen Richtung losgallopierst, mal ein kleiner Denkanstoss. Das Paket ist nicht defekt, sondern zeigt korrekt die Nutzdaten im DB zum Zeitpunkt des Sendens. Bei Dir werden in der SPS im DB 210 ab DW 164 die ersten 8 Datenworte sporadisch in der SPS mit von Dir unerwarteten Werten überschrieben.

Gruß

Question_mark
 
Hmmm...

Genau das habe ich doch aber in meiner SPS abgecheckt.
Ich prüfe, ob die 10 Worte nach 164 (und andere) um mehr als 50 springen. Dann wird ein Merker gesetzt. Tun sie aber nicht. Hab das Prüfprogramm auch gestestet indem ich einen Zählwert von Hand von 20000 auf 20200 gesetzt habe und das Merkerbit wird gesetzt. Während dieses "kaputte" Paket vorbeikam war das aber nicht der Fall. Da ich sonst mit diesen Daten nicht arbeite und sie per passiv fetch abgeholt werden..... wo soll der Fehler dann herkommen?

Der Siemens mitarbeiter hat gerade angerufen und erzählte was von Lock Bausteinen und gleichzeitigem Zugriff auf den DB von FMS und TCP aus.
Werde ich nun auch noch versuchen.........


Gruß,
Aksels
 
Zurück
Oben