Hi, das Modem heißt energy2scada und kommt von H &IT Berlin. Einen Auszug aus der Anleitung in dem der Modbus beschrieben ist, sende ich in der Anlage.
Startwerte und Beobachtungswerte sind ungleich weil ich rumprobiert habe...
...das frag ich mich auch: der Status wechselt immer zwischen 7005, 7006 und 8383 der screenshot hat grad 7005 erwischt - die dürfte doch aber gar nicht da sein
wenn ich auf 103 stelle oder...?
Doch, eben weil gespielt wurde. Wenn Du mitten im Aufruf, ohne REQ entfernt und einen Zyklus später Disconnect setzt und wartest bis er disconnected ist und dann startest, einfach die Ansteuerungswerte änderst, unter anderem die VerbindungsID, dann wird die SPS solange auf dem aktuellen Zustand verharren bis der Timeout kommt, der wiederrum als Sende-/Empfangsfehler dokumentiert werden könnte wenn die ID verschwindet, oder aber abgebrochen wird. Die ID ist dann eben "verwaist", jedoch bekommt der Baustein noch immer die Rückmeldungen und zeigt dann eben "Sendefehler" an obwohl man gerade "liest", solange bis man die ID wieder mit dem MB_Client nutzt und dieser diese ID "Zuende" abarbeiten kann. Schlimmstenfalls ist die Funktion in der SPS (mb_client) einfach nur auf Error und zeigt es nicht an weil die ID nicht mehr aufgerufen werden kann. Könnte man als fehlerhafte Programmierung seitens Siemens sehen oder einfach nur nicht ausgeklügeltes Fehlermanagement von Siemens, wie man mag, Siemens wird dazu jedoch nur sagen: Wurde falsch genutzt, bitte richtig nutzen.
Im seltensten Fall trifft die richtige ID die richtige Anforderung und es baut sich alles von selbst wieder ab, ist jedoch sehr unwahrscheinlich.
In Deiner Beobachtung - das wechseln zwischen 7005, 7006 und 8383 liegt eventuell daran das Du 3 mal REQ gesetzt hast während die ID bereits genutzt wurde oder die ID/Mode geändert hast während REQ aktiv war, die SPS also 3 mal die Funktion MB_CLIENT aktiv geöffnet hat und nun willkürlich die Informationen zurückliefert, da sie diese selbst nicht mehr eindeutig zur ID zuordnen kann. Sie hat sich also aufgehangen: Einzige Lösung - In Stop versetzen und neu starten.
Könnte aber auch daran liegen das Du 3 mal MB_Client im Programm aufrufst, einmal lesend, dann schreibend, und einmal mit falschen Daten, oder aber 2 mal aufgerufen und es wird mitgeteilt: lese, kurz danach dann 8383 erscheint. Wer weiß.
Der Anstoss über REQ geschieht zwar nur in einem Zyklus, die tatsächliche Bearbeitung dahinter jedoch über mehrere Zyklen. Dafür wurde der Ausgang Done geschaffen, der die Fertigmeldung darstellt damit man weiß das der nächste Anstoss geschehen kann. Busy existiert z.B. damit REQ nicht gesetzt wird wenn er noch am arbeiten ist und die Verbindung danach abgebaut werden soll. Abschließen kann die SPS die Anforderung REQ auch nur wenn MB_CLIENT aktiv aufgerufen wird. Wenn ich also REQ setze, er fängt an, dann setze ich EN auf FALSE, so wird die SPS nie mehr mit dem Teilnehmer kommunizieren. Selbst wenn ich EN nun wieder auf TRUE schalte wird die Verbindung nicht mehr genutzt werden können.
Also: Für Lesen und Schreiben optimalerweise immer eine Verschaltung nutzen, sodaß es nicht vorkommen kann das beides gleichzeitig ausgeführt wird, ebenso die ID/Mode nicht verändern.
Um die Verbindung "sauber" zu trennen sollte man die Verschaltung dazu nutzen, um es "unsauber" zu trennen: SPS neu starten.
Heißt: Niemals den DB händisch bearbeiten solange u.a. REQ oder BUSY auf TRUE steht, dann kommen solche merkwürdige Konstellationen(Beobachtungswerte) auch nicht zustande.
Ich habe den Modbus "MB_Client" Baustein genommen der im TIA standartmäßig unter - weitere - Modbus tcp - zu finden ist..
Der Baustein ist im OB1 aufgerufen und mit einem DB Parametriert aus dem auch der screenshot stammt.
Das Modem ist Slave - also Server - PN/DP hat den richtigen Hinweis gegeben - hier muss es natürlich nicht Master/Slave sondern Client/Server heißen
sorry für diese Vermischung...
Also, wir reden hier vom Server und die S7 ist client.
Ja, ich neige dazu Dinge zu verschlucken die ich für mich als selbstverständlich erachte, Harald schreibt lieber ausführlich. Er ist schon länger hier im Forum dabei und hat einiges gelernt wie man es besser ausschreiben sollte, bzw. wann.
Daran muss ich mich gewöhnen, unsere Azubis finden das auch nicht immer lustig
.
Der Baustein MB_Client ist schon richtig.
Du willst 72DW lesen.
Was ich sicher sehe ist, das Du eine Länge von 72 Halteregistern beginnend ab Adresse 0 im Beobachtungswert hast.
Von der richtigen IP etc. gehe ich mal aus.
Du hast aber die Ansteuerung des MB_Client nicht angegeben, daher könnte ich nun raten. Willst Du das nachholen?
Benötigt wird z.B.:
Screenshot vom MB_Client im Programm
Screenshot vom Datenbereich auf den an MB_DATA_PTR verwiesen wird.
Screenshot während der Beobachtung wie oben bereits geschehen, jedoch wenn die korrekten Informationen bei REQ=TRUE-Flanke bereits anlagen, also die Reaktion auf die "vermeintlich" richtige Ansteuerung mitsamt des dann entstandenen Fehlers.
Die Anleitung vom Modem in welcher aufgeschlüsselt wird welche der Register einfache Worte, und welche Doppelworte sind, also das was auf Seiten 12..13 oder so steht.
Je mehr Informationen von Dir aufbereitet an uns übergeben werden desto einfacher und zielgerichteter können wir die Lösung des Problems nennen. Raten will ich eigentlich nicht und die fertige Lösung ist nach vorliegenden Informationen nur schwer zu präsentieren da die Halteregister erraten werden müssen.
Was ich jedoch vermute ist das die Anzahl der tatsächlichen Register an MB_DATA_PTR nicht mit MB_DATA_LEN übereinanderstimmen, da es sich um einen 16- und 32-Bit-Mix an Registern handelt und der Baustein optimiert ist.
Beispiel was für Infos benötigt werden die hier noch fehlen (Aufbereitung):
UDT Siemens PAC4200 -> Lesedaten
Code:
Lesedaten "Siemens PAC4200 Lesedaten" 16.0 True True True False
[...] // Alles hiervor ist wie Offset 119 deklariert
Offset 119: Maximaler THD Spannung L2-L3, Einheit %, Wertebereich 0 … 100 Real 252.0 0.0 True True True False
Offset 121: Maximaler THD Spannung L3-L1, Einheit %, Wertebereich 0 … 100 Real 256.0 0.0 True True True False
Offset 123: Reserve, Einheit -, Wertebereich - Word 260.0 16#0 True True True False
Offset 125: Reserve, Einheit -, Wertebereich - Word 262.0 16#0 True True True False
Offset 127: Reserve, Einheit -, Wertebereich - Word 264.0 16#0 True True True False
Offset 129: Maximale Netzfrequenz, Einheit Hz, Wertebereich 45 … 65 Real 266.0 0.0 True True True False
Offset 131: Maximaler 3-Phasen Durchschnitt Spannung L-N, Einheit V, Wertebereich - Real 270.0 0.0 True True True False
Offset 133: Maximaler 3-Phasen Durchschnitt Spannung L-L, Einheit V, Wertebereich - Real 274.0 0.0 True True True False
[...] // Alles hiernach ist wie Offset 133 deklariert
Insgesamt sind 100 Einträge vorhanden.
Ansteuerung:
#"Kommunikation aufbauen" wird gebildet aus einem Zähler für freie Verbindungs-IDs sowie maximal alle 2 Sekunden.
Code:
REGION Leseauftrag
//Lesen
#DB_MB_Client(CONNECT := #Adressierung,
REQ := #"Kommunikation aufbauen" AND NOT #MBClient_Busy,
DISCONNECT := #MBCLient_Done OR NOT #"Kommunikation aufbauen",
MB_MODE := 103,
MB_DATA_ADDR := 1,
MB_DATA_LEN := 101,
MB_DATA_PTR := #Lesedaten,
DONE => #MBCLient_Done,
BUSY => #MBClient_Busy,
ERROR => #MBClient_Error,
STATUS => #MBClient_Status);
END_REGION
REQ= TRUE
DONE = FALSE
BUSY = TRUE
ERROR = TRUE
STATUS = 16#8383
Aus diesen Informationen können hier viele mindestens einen der (absichtlichen) Fehler erkennen.
Nicht böse gemeint, aber wenn wir nachfragen müssen nach Daten die man vorher schon bereitstellen könnte, dann wirst Du irgendwann das Problem bekommen das Dir die Zeit wegläuft (u.a. weil auch wir auf Baustellen sind und daher nicht dauernd hier hineinschauen können) und wir können nichts beantworten was nicht ersichtlich ist. In vielen Themen wird deshalb immer mit "ich befrage mal die Glaskugel" geantwortet.
confused
)
