TIA Modbus Kommunikation (SPS zu MPA) -> Fehlerbehebung von Modbus_Master

[RONIN]

Zuviel Werbung?
-> Hier kostenlos registrieren

16#FF00 zu senden könnte auch noch nicht ganz richtig sein. Damit wird ja gleich alles gesetzt/gestartet. Ist das wirklich so vorgesehen bei dem Gerät?

Bei einer Längenangabe von LEN=1 - also Function 5 - ist das in Ordnung.

Ganz ist mir hier das Verhalten des Modbus-Bausteins auch nicht klar.

Beispiel für Function 5 - MODE = 1; DATA_ADDR = 3; LEN = 1
Im ersten Register von DATA_PTR kenne ich 3 Werte die für das Setzen von einem einzelnen Ausgangsbit erlaubt sind.
Die Werte 16#FF00 und 16#0100 schicken die gleiche Sequenz am RS485 raus. Das Bit im Slave wird gesetzt.

01 05 00 02 FF 00 2D FA

Der Wert 16#0000 setzt das Bit dann logischerweise zurück.

01 05 00 02 00 00 2D FA

Alle anderen Werte werden vom Modbus-Master-Baustein abgewiesen. Die liefern Fehler 16#8384 ohne das am RS485 ein Telegramm rausgesendet wird.

 

[HT-T]

Einige Dinge fallen mir beim erneuten Lesen der Beiträge auf.

• Beitrag #1 zeigt dein "Modbus_Comm_Load"-Einstellungen. Dort ist 9600 Baud und NoParity eingestellt. Da musst du nochmal die richtigen Einstellungen treffen auch wenn du die HW-Config schon eingestellt hast. Also in deinem Fall (19200 und 2 - Even). Auch den Parameter "MODE" im IDB des "Modbus_Comm_Load" würde ich mit 4 (Halbduplex) beschreiben.
• Den falschen DATA_PTR an "Modbus_Master" hast du ja schon behoben. Was hast du da jetzt dran? Ein Array of Word in einem Global-DB?
• Beitrag #10 zeigt eine Einstellung von 2 Stoppbits. Ist nicht üblich. Eher 1 Stoppbit, kann das aber in der Anleitung des Gerätes auch nicht erachten.

Nachdem du den "Modbus_Comm_Load" dann erfolgreich ausgeführt hast, also Signal "Done" ohne "Error" erhalten hast, könntest du wieder die ersten Versuche starten. Konntest du überhaupt schon Daten lesen? Vor dem Schreiben würde ich immer erstmal versuchen zu lesen.

Ich würde mal versuchen Modbus-Funktion 1 (Read Coils) auszuführen. Zum Beispiel MODE 0, DATA_ADDR 1, LEN 1.
Erst wenn der Befehl mal durchläuft ohne das der Modbus_Master einen Fehler ausspuckt, dann würde ich weitergucken.

Wie gesagt, wenn du einen RS485/USB-Adapter hättest, dann könntest du den Verkehr der aus der CPU kommt beobachten. Damit wären so einfach grundlegende Dinge wie "A/B vertauscht" schon mal weg. Du könntest ggf. den CPU mit einem ModbusSlave-Simulator am PC kommunizieren lassen oder von PC mit einem ModbusMaster-Programm versuchen mit deinem Gerät zu sprechen. Das macht die Fehlersuche deutlich einfacher. Vor allem wenn man dann zwei Geräte (PC und SPS) nicht mit dem Slave sprechen können, dann kann man die Suche im SPS-Code mal beiseite legen.

Ich hab mit einer 1200 und einem CB1241 mal schnell ein Beispiel zusammengeschrieben und getestet. Das funktioniert hier mit dem PC und RS485-Adapter als Modbus-Slave. Das kannst du vielleicht als Anhaltspunkt nehmen.

Lieber @RONIN
Die Baudrate und Parität war in den Anfängen falsch gesetzt, diese Fehler habe ich jedoch recht schnell beseitigt, kann sein das dies bei all den Beiträgen unerwähnt blieb .

Ich musste gar nicht alles probieren was du mir dankbarerweise hier geschrieben hast.
Es war tatsächlich, der Parameter "MODE" im DB des Modbus Comm Load... unglaublich jetzt funktioniert es!!
Mir war leider nicht bewusst das man im DB auch noch extra Parameter händisch setzen muss... ich dachte immer alle wichtigen Parameter sind am Baustein selbst zu vergeben.

Ich danke dir vielmals!

 

[RONIN]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja, ich war mir auch nie sicher ob der Parameter "MODE" im IDB des Modbus_Comm_Load nun noch gesetzt werden muss oder nicht.
Ich habe den eigentlich immer mit-gesetzt. So richtig klar ist es nicht und warum er nicht gleich auf die Bausteineingänge rausgeführt ist...

Gut zu wissen.
Danke für die Rückmeldung

 

[HT-T]

@RONIN Ich habe aktuell noch ein Thema mit der Modbus-Kommunikation, und zwar kann ich problemlos den Slave "Schreiben", wenn ich jedoch versuche etwas aus dem Slave zu "Lesen" dann zeigt es mir in dem zuvor definierten Array keinerlei gelesene Werte im Array an. Alle Werte bleiben per Default auf "0".

Anhand eines RS485 USB Adapter konnte ich mittlerweile das vom Slave rückgemeldete Telegram überprüfen und ausschließen dass ich falsch adressiere, das heißt der Slave meldet entsprechend wie gewünscht an die SPS zurück, nur ließt er die zu lesenden Werte nicht wie gewünscht in den vom Pointer DATA_PTR ausgewählten Array ein.

Im Informationssystem von TIA finde ich zu dem genannten Pointer folgendes:

Ich bin mir unsicher ob ich nicht noch etwas mit dem Array machen muss, es eventuell vor der Nutzung mit einem extra FC zu leeren oder muss ich Einstellungen vornehmen. Wenn ich es richtig verstanden habe muss man für eine "direkte" Adressierung den Attribut des "optimierten Baustein" deaktivieren um direkt adressieren zu können. Bisher hat das allein jedoch noch nicht zum Erfolg geführt.

Ich bin irgendwie irritiert, weshalb kann ich schreiben - aus einem Array und nicht genau dort auch - lesen??

Wie immer wäre ich über eine Hilfestellung diesbezüglich sehr erfreut!
Grüße HT-T

 

[RONIN]

• Bekommts du vom MB_CLIENT am Ausgang DONE auch einen Impuls?
  Also z.B. mit DONE einen Integer hochzählen - tut sich da was?
• Welche Anfrage machst du (MB_ADDR, MODE, DATA_ADDR, DATA_LEN)
• Wie ist dein Ziel-Array strukturiert? Array von/bis of What?

 

[HT-T]

Zuviel Werbung?
-> Hier kostenlos registrieren

• Bekommts du vom MB_CLIENT am Ausgang DONE auch einen Impuls?
  Also z.B. mit DONE einen Integer hochzählen - tut sich da was?
• Welche Anfrage machst du (MB_ADDR, MODE, DATA_ADDR, DATA_LEN)
• Wie ist dein Ziel-Array strukturiert? Array von/bis of What?

Danke für die schnelle Antwort! @RONIN

Ich benutze nicht den MB_Client Baustein sondern ich arbeite mit "Modbus_Comm_Load" und "Modbus_Master".

Der Comm_Load welcher die Verbindung umsetzt ist auf Done... der eigentlich Modbus_Master welcher das Telegramm bestimmt steht dauerhaft auf "Busy" mit dem Fehlercode - 16#7002 - welcher für die anhaltende Ausführung des Bausteins steht.

Mode: 0 <- Lesen
MB_ADDR: 10 <- Slave Adresse
Data_Addr: 40003 <- Registeradresse 2 der Eingangsbytes... (40001 entspricht Registeradresse 0)

Data_LEN <- 1 (da ein Word)
Für mein Zielarray habe ich einen eigene Daten PLC-Datentyp erstellt welches ein Array aus 10 - Word ist...
das Array habe ich dann in einen eigenständigen DB eingefügt.

 

[RONIN]

Der Comm_Load welcher die Verbindung umsetzt ist auf Done... der eigentlich Modbus_Master welcher das Telegramm bestimmt steht dauerhaft auf "Busy" mit dem Fehlercode - 16#7002 - welcher für die anhaltende Ausführung des Bausteins steht.

Das hängt davon ab wie du den REQ-Eingang beschaltet hast. Wenn der Dauer-Eins ist, dann fängt der Baustein nach erfolgreichem oder fehlerhaften Ende eines Auftrags gleich den nächsten an. Da siehst du dann den kurzen Puls auf DONE oder ERR, welcher nur einen Zyklus dauert, beim normalen Beobachten nicht.

Mach mal sowas wie bei dem Screenshot den ich anhänge.
Da siehst du vielleicht mehr.

Data_Addr: 40003 <- Registeradresse 2 der Eingangsbytes... (40001 entspricht Registeradresse 0)

Naja, bei MODE=0 und 40003 würdest du eigentlich ein Halte-Register des Slaves lesen - Modbus-Function 03
Ein Eingangswort wäre mit 30000 - Modbus-Function Code 04.
Kann sein dass du mit "Eingangsbyte" eh die Halteregister meinst, will nur sicher gehen.


Edit: Functioncode-Nummern 03/04 und Screenshot korrigiert.

 

[HT-T]

Das hängt davon ab wie du den REQ-Eingang beschaltet hast. Wenn der Dauer-Eins ist, dann fängt der Baustein nach erfolgreichem oder fehlerhaften Ende eines Auftrags gleich den nächsten an. Da siehst du dann den kurzen Puls auf DONE oder ERR, welcher nur einen Zyklus dauert, beim normalen Beobachten nicht.

Mach mal sowas wie bei dem Screenshot den ich anhänge.
Da siehst du vielleicht mehr.


Naja, bei MODE=0 und 40003 würdest du eigentlich ein Halte-Register des Slaves lesen - Modbus-Function 03
Ein Eingangswort wäre mit 30000 - Modbus-Function Code 04.
Kann sein dass du mit "Eingangsbyte" eh die Halteregister meinst, will nur sicher gehen.


Edit: Functioncode-Nummern 03/04 und Screenshot korrigiert.

Hallo @RONIN ,
ich habe das jetzt mal so aufgebaut und bekomme tatsächlich folgenden Fehler: 16#80C8.


Ich versuche jetzt gerade nachzuvollziehen an welcher Stellschraube ich hier nachjustieren muss.


Vielleicht habe ich mich hier falsch ausgedrückt aber die Adresse muss mit Functions-code 3 angesprochen werden.
Also sollte 40003 schon in Ordnung sein.




Edit: Wenn ich jetzt noch die Rücksetzung des Schalters an REQ des Modbus_Master weglassen, sodass dieser weiter arbeitet auch wenn ein Fehler gesetzt wurde dann gibt er mir den Fehler 16#80C9 aus.


Interessant ist das er diesen Fehler auch beim Schreiben der Wärmeanforderung ausgibt, obwohl ich diese am Slave erfolgreich schalten kann...
Das sieht für mich so aus dass er den Fehler zwar ausgibt, dieser sich aber nicht unmittelbar kritisch auf die Ausführung des Modbus_Master auswirkt. Beim Lesen baut er ja auch erfolgreich die Verbindung zum Slave auf, am Endgerät (Slave) würde er mir ansonsten einen entsprechenden Fehlercode am Display ausgeben wenn die Kommunikation nicht erfolgt wäre.

Ich bin nach wie vor Ratlos weshalb der Modbus das Schreiben erfolgreich abwickelt und beim Lesen keinerlei Feedback im Array anzeigt... außer das scheinbar überall eine "16#0000" drin steht...

 

[Thruser]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi,

hast Du Lesen und Schreiben gegeneinander verriegelt, also das entweder nur Lesen oder nur Schreiben stattfindet, aber nicht beides gleichzeitig?

Sonst zeige einmal beide Abschnitte, eventuell als PDF exportiert.

Gruß

 

[HT-T]

Hi,

hast Du Lesen und Schreiben gegeneinander verriegelt, also das entweder nur Lesen oder nur Schreiben stattfindet, aber nicht beides gleichzeitig?

Sonst zeige einmal beide Abschnitte, eventuell als PDF exportiert.

Gruß

Hallo @Thruser,

in meinem aktuellen Projekt adressiere ich entweder nur den Schreibbefehl oder den Lesebefehl... somit können sich beide auch nicht in die Quere kommen. Eigentlich hatte ich vor zwei unabhängige FB´s zu erstellen, einer zum Lesen und der andere zum Schreiben. Das habe ich bisher jedoch noch nicht zum Laufen gebracht.

Im Anhang findest du den Aufbau, wobei auch hier gerne nochmal... Am Aufbau der Bausteine kann nichts falsch sein da der selbe Aufbau für das erfolgreiche Schreiben verwendet wird...

Das bedeutet der Fehler muss an anderer Stelle liegen, wenn etwas mit der Einstellung der Bausteine nicht stimmen würde dann könnte ich weder Lesen noch Schreiben.

Vielleicht könnte es an der Adressierung des Bausteins liegen?

Bezüglich der "direkten(absoluten) und symbolische Adressierung, ist es ausreichend wenn ich hier die Funktion des Bausteins "optimierter Baustein" deaktiviere?

 

[Thruser]

Hi,

bei den Screenshots die Du immer vom Programm zeigst, zeigst Du irgendwie immer zu kleine Ausschnitte, so daß man keinen Gesamteindruck bekommt. Daher die Nachfragen. So war mir eben nicht klar, daß Du entweder nur schreibst oder nur liest.

Auch bei Modbus wird meistens regelmäßig/zyklisch abgefragt/geschrieben, nicht nur mal bei Bedarf. Daher ging ich davon aus, daß auch Du regelmäßig abfragst. Da kommt es eben öfter mal zu dem Fehler, daß due Aufrufe zum Lesen und zum Schreiben gleichzeitig anstelle von nacheinander erfolgen.

Nach Deiner Aussage ist der Schreibbefehl ja auch nicht erfolgreich, da Du dort auch eine Fehlermeldung erhältst. So wie es aussieht, kann das Siemensmodul die Antworten der MPA nicht lesen. Die versteht aber die Anfrage.

Das kann jetzt daran liegen, daß die MPA etwas Fehlertoleranter ist. Wenn man einen RS485 Anschluß für den PC hätte, könnte man jetzt beobachten ob die MPA antwortet oder nicht und ob die Daten eventuell fehlerhaft übertragen werden.

Bitte noch einmal die Einstellungen prüfen, speziell Anzahl Bits, Parität und Länge Stoppbits.
Dann bitte im Siemensmodul einmal die Einstellung: Vorbelegung der Empfangsleitung ändern.
Was für einen Stecker verwendest Du am Modul und wie ist der belegt? Da ist die gesamte Anleitung etwas undurchsichtig.
Eventuell auch noch einmal die Leitungen tauschen.

Gruß

 

[HT-T]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo @Thruser ,
tut mir leid wenn meine bisherigen Beiträge mehr zur Verwirrung beigetragen haben anstatt mein Problem weiter zu verdeutlichen.
die Screenshots weiter oben habe ich lediglich gepostet weil RONIN mir diesen "Fehlercode - Testaufbau" empfohlen hat.
Wie ich jedoch bereits mehrmals kommuniziert habe funktioniert das "Schreiben" tadellos, ich bekomme ohne Fehlermeldung im TIA die MPA - Wärmeanforderung gesetzt. Damit kann ich eine fehlerhafte Parametrierung des Modbus_Comm und Modbus_Master ausschließen.

Das ausgelesene Telegramm nach dem Versuch des Lesens ist auch wie erwartet richtig zusammengesetzt, das habe ich mir von einem Kollegen der sich diesbezüglich besser auskennt bestätigen lassen.

Aus irgendeinem Grund wird beim Lesen jedoch das adressierte Array nichtgefüllt, ich vermute daher das irgend eine Einstellung des DATA_PTR oder dem damit verbundenen globalen Datenbaustein eine Einstellung fehlerhaft ist.

Für mich ist es leider nicht nachvollziehbar warum das Schreiben funktioniert, das Lesen jedoch nicht.

Soll ich dir eine Kopie des TIA Projekts hier anhängen? Wenn dir das weiterhelfen sollte... wobei du damit auch nichts weiter testen kannst ohne den entsprechenden Slave...

Gruß HT-T

 

[Thruser]

Hi,

Du hast doch weiter oben (#28) geschrieben, daß Du den Fehler auch beim Schreiben erhälst, die MPA aber reagiert.

Es werden also von der SPS Modbus-Daten an die MPA über die RS 485 Schnittstelle geschickt. Die werden von der MPA gelesen und wohl auch ausgewertet, da geschaltet wird. Die MPA schickt aber nach Modbusprotokoll auf eine Schreibanweisung auch noch eine Antwort an den Master zurück, so daß dieser weiß die Anweisung wurde erhalten. Die SPS scheint diese Antwort aber nicht lesen oder empfangen zu können, daher kommt es zu der Time Out Fehlermeldung.

Bei der Leseanforderung reagiert die MPA wahrscheinlich auch, aber auch die Antwort wird von der SPS nicht verstanden. Daher auch dort Time Out.

Das kann jetzt an falschen Pegeln auf der Busleitung liegen, oder an Störungen, mit der das CM nicht umgehen kann. Aber auch an falschen Einstellungen der Schnittstelle. High Tech wie das CM reagiert da manchmal empfindlicher als irgendwelche günstigere Elektronik. Z.B. reagieren viel USB RS485 Umsetzer sehr tolerant auf Timingfehler des Signals, auch ist es denen oft egal ob man nun 1 oder 2 Stoppbits verwendet.

Gruß

 

[HT-T]

Hi,

Du hast doch weiter oben (#28) geschrieben, daß Du den Fehler auch beim Schreiben erhälst, die MPA aber reagiert.

Es werden also von der SPS Modbus-Daten an die MPA über die RS 485 Schnittstelle geschickt. Die werden von der MPA gelesen und wohl auch ausgewertet, da geschaltet wird. Die MPA schickt aber nach Modbusprotokoll auf eine Schreibanweisung auch noch eine Antwort an den Master zurück, so daß dieser weiß die Anweisung wurde erhalten. Die SPS scheint diese Antwort aber nicht lesen oder empfangen zu können, daher kommt es zu der Time Out Fehlermeldung.

Bei der Leseanforderung reagiert die MPA wahrscheinlich auch, aber auch die Antwort wird von der SPS nicht verstanden. Daher auch dort Time Out.

Das kann jetzt an falschen Pegeln auf der Busleitung liegen, oder an Störungen, mit der das CM nicht umgehen kann. Aber auch an falschen Einstellungen der Schnittstelle. High Tech wie das CM reagiert da manchmal empfindlicher als irgendwelche günstigere Elektronik. Z.B. reagieren viel USB RS485 Umsetzer sehr tolerant auf Timingfehler des Signals, auch ist es denen oft egal ob man nun 1 oder 2 Stoppbits verwendet.

Gruß

@Thruser

Ah sorry, jetzt verstehe ich wo du hin willst... für den "Schreibbefehl" wird zwangsläufig ja keine Antwort benötigt, weshalb vermutlich das Setzen trotzdem funktioniert. Beim Lesen hat er aber zu kämpfen da er hier ja auf die Rückmeldung angewiesen ist.... ja ist auch irgendwie logisch.
Für gewöhnlich bringt die SPS jedoch aber einen Fehlercode im Diagnosetool wenn eine unerwartete oder nicht verwertbare Antwort vom Slave eingeht? Das ist jedenfalls nicht der Fall.

Aus der Anleitung der MPA konnte ich jedenfalls entnehmen das hier mit Baudrate 19,2 kbit und Even Parity standardmäßig parametriert ist.
Ich bin mir jedoch bei all den weiteren Einstellung und der Hardwarekonfiguration des CM auch unschlüssig ob hier nicht der Hund begraben liegt.








Ich versuche jetzt mal als nächstes den im Fehlercode erwähnten "Blocked_Proc_Timeout" Parameter ausfindig zu machen.
Vielleicht kann ich hier eine Einstellung vornehmen...

 

[HT-T]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich verzweifle so langsam.... Verdrahtung habe ich geprüft, habe nochmal umverdrahtet dann ging gar nichts mehr und der MPA ging in den Fehlermodus - F9 Fehler Modbus Verbindung...
Nun habe ich wieder alles zurückverdrahtet wie es bisher war. Somit kann ich nun wieder senden, auch wenn mein Modbus_Master ununterbrochen im BUSY-TRUE fest hängt und weiter den Fehlercode 16#80C8 in unendlich Schleife auswirft...

Unser Chef-Programmierer hat mir versichert das die Baudrate bei 19,2k und ein Even Parity Bit parametriert sein muss... das habe ich selbstverständlich bereits vornerein auch so dem Baustein mitgeteilt.

Ich verstehe nicht wo das Problem liegt... Mit dem RS485 USB Adapter meldet er das zu erwartende Telegramm zurück
0A 03 02 00 09 DD 83 - Flammerkennung.

Ich hoffe jemand hat noch eine Idee was ich ausprobieren könnte...

 

[Thruser]

Hallo,

hast Du denn einmal mit den USB Adapter mitgehört, ob der MPA auch auf die Nachricht von der SPS antwortet? Kann man z.b mit qmodmaster machen, oder mit realterm.

Was hast Du denn für einen Stecker? Mit Abschlußwiderstand und BIAS Netzwerk? Hats Du auch mal ohne Vorspannung probiert (Vorbelegung der Empfangsleitung)? Eventuell auch mal Nachrichtenzeitüberschreitung etwas verlängern.

Gruß

 

[HT-T]

Hallo,

hast Du denn einmal mit den USB Adapter mitgehört, ob der MPA auch auf die Nachricht von der SPS antwortet? Kann man z.b mit qmodmaster machen, oder mit realterm.

Was hast Du denn für einen Stecker? Mit Abschlußwiderstand und BIAS Netzwerk? Hats Du auch mal ohne Vorspannung probiert (Vorbelegung der Empfangsleitung)? Eventuell auch mal Nachrichtenzeitüberschreitung etwas verlängern.

Gruß

Hallo @Thruser ,
eine Nachricht weiter oben habe ich geschrieben "Ich verstehe nicht wo das Problem liegt... Mit dem RS485 USB Adapter meldet er das zu erwartende Telegramm zurück 0A 03 02 00 09 DD 83 - Flammerkennung." Ich habe das rückgemeldet Telegramm also bereits mit HTERM abgegriffen und laut meinem Kollegen aus der Entwicklung ist dies auch plausibel.

Falls du mit Stecker den Anschluss am CM Modul meinst, es handelt sich hier um eine RS422/RS485 Schnittstelle (6ES7 241-1CH32-0XB0)... ich habe es auch schon mit der Vorspannung probiert, dann bringt er mir im Master die Fehlermeldung 16#8281...

 

[Thruser]

Zuviel Werbung?
-> Hier kostenlos registrieren

OK, hatte gedacht Du hast mit dem USB Adapter zwischen PC und MPA getestet.

Die Baugruppe hat eine 9 poligen D-Sub Buchse. Verwendest Du dazu den RS 485 Stecker von Siemens mit den Abschlußwiderständen? Hast Du die aktiviert? Wenn ich die Anleitung richtig lese, dann darf bei eingeschalteten Abschlußwiderständen die Vorspannung nicht eingeschaltet sein.

Prüf auch noch einmal, ob Mode = 4 im IDB von Modbus_Comm_Load ist. Der Baustein überschreibt die Hardwareeinstellung RS 485 Halbduplex. Am besten direkt eine Zuweisung vor dem Aufruf des Modbus_Comm_Load Bausteins machen.

Da gibt es auch noch die ICHAR_GAP Einstellung, mit der könnte man auch noch einmal experimetieren.

Gruß

 

[HT-T]

OK, hatte gedacht Du hast mit dem USB Adapter zwischen PC und MPA getestet.

Die Baugruppe hat eine 9 poligen D-Sub Buchse. Verwendest Du dazu den RS 485 Stecker von Siemens mit den Abschlußwiderständen? Hast Du die aktiviert? Wenn ich die Anleitung richtig lese, dann darf bei eingeschalteten Abschlußwiderständen die Vorspannung nicht eingeschaltet sein.

Prüf auch noch einmal, ob Mode = 4 im IDB von Modbus_Comm_Load ist. Der Baustein überschreibt die Hardwareeinstellung RS 485 Halbduplex. Am besten direkt eine Zuweisung vor dem Aufruf des Modbus_Comm_Load Bausteins machen.

Da gibt es auch noch die ICHAR_GAP Einstellung, mit der könnte man auch noch einmal experimetieren.

Gruß

Ja ich habe auf die Modbus Abgänge vom MPA auch den USB Adapter angeschlossen um mitzuhören was die MPA denn auf meine Master Befehle als Slave antwortet...

Ich schließe an die 9 polige D-Sub Buchse direkt dieses Kabel hier an: SPS-Kabel
Welchen Stecker/Adapter meinst du denn konkret? Im Lieferumfang des Moduls war meines Wissens nach nichts weiter mit dabei.
Oder meinst du den seitlichen Abgang?

den Mode 4 habe ich bereits gesetzt... ohne diesen bekomme ich keinen Schreibbefehl in Richtung SPS...

Die von dir erwähnte ICHAR_GAP finde ich im DB des Modbus_Master?

 

[Thruser]

Im Siemenshandbuch ist der 6ES7972-0BA42-0XA0 erwähnt. Hätte ja sein können, daß Du so einen verwendest.



Den Parameter findest Du im DB von Modbus_Comm_Load

Gruß