- Dieses Thema hat 14 Antworten, 6 Teilnehmer und wurde zuletzt aktualisiert 3 Jahre, 4 Monate da
.
-
Post
-
In Bezug auf den ModbusMaster-Block werden im IEC 61131-3 LogicLab-Programmierhandbuch die Fehlercodes aufgeführt, die über die SysGetLastError-Funktion erfasst werden können. Insbesondere die Fehler während des Empfangs des Antwortrahmens auf die vom Master gesendeten Nachrichten, die als 10007500 ~ 7 (dh von 0 bis 7) angezeigt werden, jedoch ohne die verschiedenen Fälle zuzuordnen. In meinem speziellen Fall wird der Fehler 10007505 angezeigt, aber ich verstehe nicht, auf welche Bedingung er sich bezieht (falsches Zeichen, falsche Länge, CRC usw.).
Nach dem, was ich aus dem Lesen des Handbuchs verstehe, wird jedes Mal, wenn ein Lese- / Schreibzyklus ausgeführt wird, am Ende des Zyklus die Ausgabe „Fertig“ ausgelöst, unabhängig davon, ob die Aktion erfolgreich ist oder nicht. Es ist jedoch möglich, Anzeigen in diesem Sinne über die Werte zu erhalten, die von den Ausgängen "Ok" und "Fehler" angenommen werden. Wenn der Zyklus fehlschlägt, wird der nächste Lese- / Schreibversuch direkt vom ModbusMaster-Block ausgeführt oder muss der Enable-Eingang erneut umgeschaltet werden?
Für den Fall, dass immer derselbe Speicherbereich in einem einzelnen Slave gelesen werden muss und der Eingang "Enable" immer aktiv bleibt, werden die Lesezyklen direkt vom ModbusMaster-Block ausgeführt, oder es muss immer der Eingang Enable aktiviert werden, um den zu aktivieren mehrere Zyklen?
Tatsächlich haben wir nicht alle Fehler gemeldet, was im Allgemeinen darauf hinweist, dass der Fehler beim Senden oder Empfangen des Pakets liegt, auch weil der Fehler oft einen falschen Hinweis darauf gibt, was das Problem tatsächlich ist. In Ihrem Fall zeigt der Fehler 10007505 an, dass entweder eine Antwort von einer anderen Knoten-ID oder ein anderer Funktionscode als der angeforderte empfangen wird. Der beste Weg, um zu verstehen, wo das Problem liegt, ist die Aktivierung der Spionage (Betreff).
Was das aufeinanderfolgende Lesen betrifft, so ist die Ausgabe von Erledigt bei der Einreise verweigert Ermöglichenmöglicherweise eine Zeit von definieren Verzögerung Wenn Sie eine Zeit zwischen Befehlen einfügen möchten. Der FB wurde entwickelt, um Kaskade und dieses Thema beschäftigen wir uns mit dem Thema.
Die Antwort auf Ihre letzte Frage ist in der vorherigen Antwort enthalten.
Ich versuche, ein einzurichten NetlogIII für die Kommunikation in Modbus RTU mit einem ABB ACS580-Antrieb, der an einen RS485-Feldbus angeschlossen ist. In LogicLab habe ich die Blöcke Sysfopen und ModBusMaster verwendet. Die erste Frage betrifft die Nummerierung der Ports, ich konnte keine Informationen in den Handbüchern finden, der Feldbus entspricht COM2, richtig?
Sobald das Programm geladen wurde, bestätigt der Wechselrichter, dass die Verbindung in Ordnung ist, kein Fehler und zeigt an, dass er Daten auf dem Modbus korrekt empfängt und sendet, während auf der SPS die Variable SysGetLastError den Fehler 10007506 und von der Toolly-Telnet-Konsole anzeigt, die ich anzeige der Fehler "Antwortrahmen zu lang".
Ich versuche, ein 16-Bit-Wort in einem Speicherregister zu lesen. Ich habe die Kabel, die Polarität, die Geschwindigkeit und das Paritätsbit des Busses auf den beiden Geräten überprüft und alles ist korrekt. Es befinden sich keine anderen Geräte am Bus. Der Abschlusswiderstand ist sowohl am Laufwerk als auch an der SPS aktiv, während die Vorspannung auch am Laufwerk aktiv ist.
Auf XTarget_12 (ab Firmware SFW184B000) wurde der FB erstellt, um die serielle Schnittstelle zu öffnen SysSerialPort Dadurch können neben dem Öffnen auch die Kommunikationsparameter eingestellt werden. Obwohl es richtig ist, die zu verwenden Sysfopen Ich schlage vor, Sie verwenden den neuen FB (Aktualisieren Sie gegebenenfalls die Firmware auf dem NetlogIII, Siehe FAQ). Die Tür Fieldbus Ist der COM2-Anschluss, bezieht sich der Fehler 10007506, den Sie im Handbuch sehen, auf einen Fehler beim Empfang.10007500~7 Errore in ricezione frame risposta (Carattere errato, lunghezza errata, CRC).Jetzt sagst du mir, dass in Telnet mit Toolly "Antwortrahmen zu lang" angezeigt wird, was bedeutet, dass du ihn aktiviert hast SpyOn und Sie spionieren die Modbus-Kommunikation zum Laufwerk aus. Dann werden sowohl der gesendete Anforderungsrahmen als auch der empfangene Antwortrahmen angezeigt, wenn Sie diese überprüfen frames Nach der Modbus-Spezifikation werden Sie wahrscheinlich feststellen, dass eine bestimmte Anzahl von Registern in der Anforderung angefordert wurde und dass in der Antwort mehr Daten empfangen wurden als erwartet. Warum passiert das? Ich sollte den Spionagebericht auf Toolly sehen, aber im Allgemeinen sind Sie sicher, dass Sie den Kommunikationsmodus richtig eingestellt haben (Baudrate, Parität, Bits), Sie sind sicher, dass Sie den richtigen Lesecode und den richtigen verwenden Registeradresse (Merken Sie sich den Offset von 1). Der ModbusMaster FB sagt: "Gemäß den Modbus-Spezifikationen lautet die im Datenrahmen gesendete Adresse (Adresse-1).” Dies liegt daran, dass wer Modbus-kompatibel ist, 1 zur empfangenen Adresse hinzufügt, aber viele devices Sie addieren sich nicht, daher müssen Sie 1 zum Wert von addieren Adresse an die FB übergeben. Wenn du mir eine schickst printscreen Auf dem Toolly-Bildschirm kann ich vielleicht genauer sein.
In der Zwischenzeit vielen Dank für die schnelle und vollständige Antwort, außergewöhnliche Unterstützung!
Sobald ich einen Test mit dem SysSerialPort-Block durchführen kann, hatte ich tatsächlich einige Zweifel hinsichtlich des Unterschieds zwischen den beiden Blöcken. In der Toolly-Konsole wird angezeigt, dass das gesendete und das empfangene Paket identisch sind:| Tx | 02 04 9C 44 00 01 5F BC
| Rx | 02 04 9C 44 00 01 5F BC
| Er | Antworte zu langeModBusMaster: Typ: 0; Knoten: 2; FCode: 16 # 03; Adresse: 40005, Punkte: 1; IFTime: 286; Timeout: 500; Verzögerung: 1000.
(Ich entschuldige mich, aber ich konnte nicht finden, wie ich Bilder an das Forum anhängen kann ...)Die Adresse ist kein Problem, da ich eine Reihe benachbarter Register habe, daher sollte ich höchstens andere Daten als die gewünschten lesen.
Vielen Dank für die Komplimente ... heute ein Brückentag und dann ohne Telefonanruf haben Sie mehr Zeit für das Forum. Der gesendete Modbus-Frame kehrt nicht zu mir zurück. Der Knoten ist 02, aber der Funktionscode ist 04 und nicht 03, wie Sie sagen, dass Sie eingestellt haben. Die Registeradresse, wie Sie sehen, ist 9C44, was 40004 entspricht (Adressensatz -1), fragen Sie nach einem Register 00 01 und die CRC ist 5FBC.
Aber die Antwort ist falsch, sie darf überhaupt nicht mit der Anfrage übereinstimmen, es scheint ein Echo des Laufwerks zu sein, das absolut nicht passieren darf, da der FB die Antwort erwartet, die vom Typ 02 04 02 xx xx CRC sein sollte. Das heißt, Sie haben nach einem Register gefragt, und das Laufwerk antwortet mit 02 Byte, gefolgt von ihrem Wert und der CRC.
Sie können versuchen, mit einem parallelen RS485-Port auf der Kommunikationsleitung auszuspionieren, um festzustellen, ob nach dem Anforderungsrahmen ein Echorahmen und dann tatsächlich der Antwortrahmen vorhanden ist. Nachdem der erste Frame empfangen wurde, überprüft der FB ihn und bricht im Fehlerfall das Warten auf den nächsten Befehl ab und zeigt Ihnen daher nicht den richtigen Frame an, der folgt.
Der Grund für den Fehler ist offensichtlich, 7 Bytes Antwort werden erwartet und stattdessen werden 8 empfangen.
Ich habe den FB-Test durchgeführt SysSerialPort aber ohne Erfolg. Das Laufwerk teilt mir mit, dass auf dem Bus keine Aktivität vorhanden ist und keine Daten ausgetauscht werden, während auf der SPS der ModBusMaster-FB den Fehler 10007010 ausgibt.
Wenn ich es stattdessen nochmal mit dem probiere Sysfopen Ich erhalte den Paketaustausch mit dem bereits hervorgehobenen Fehler zurück. Ich habe auch im Handbuch des Laufwerks überprüft, ob die Möglichkeit einer Echoantwort besteht, aber ich habe keine Spur gefunden, sodass ich die Antwort nicht erklären kann. Ich habe es auch noch einmal versucht, indem ich die Busgeschwindigkeit auf 9600 gesenkt habe, aber ohne Erfolg ist das Kabel nicht die Spitze, aber da es nicht einmal 2 m lang ist, glaube ich nicht, dass es Interferenzprobleme gibt.
Zeigt der Fehler an, dass der Wert für die Datei nicht definiert ist, aber haben Sie den Wert für Datei aus dem SysSerialPort-FB an den ModbusMaster-FB übergeben? Bei so kurzen Längen hat das Kabel normalerweise keine Probleme. Um das Problem zu verstehen, müssen Sie nur das Problem ausspionieren Kommunikation über RS485 oder Senden von Modbus-Befehlen von Toolly (siehe den letzten Beitrag von dieses Thema) oder mit einem Modbus-Simulationsprogramm zum Beispiel am besten Modbus-Mastersimulator.
Ich habe in der Praxis ein Problem mit Toolly. Nach der Authentifizierung antwortet der SpyData-Befehl, dass es nicht aktiv ist. Trotzdem habe ich den SpyOn des ModbusMaster FB auf TRUE konfiguriert. Warum? Wo irre ich mich
Läuft der ModbusMaster FB?
Ist der File-Parameter richtig eingestellt, bezieht er sich auf ein gültiges FILEP?Ok Danke, es war der Ort des Programms, der nicht in Back war. Jetzt sehe ich die gesendeten und empfangenen Daten ...
Ich experimentiere mit der Verwendung des ModbusMaster FB ohne Erfolg. Ich habe ein Objekt, das Modbus TCP-Kommunikation akzeptiert. Die Verbindung zum Objekt ist erfolgreich, der Parameter für die ausgehende Datei ist nicht NULL. Die Verwendung des Modbus Master Simulator-Programms hat einen anderen Beitrag empfohlen ... es liest mir die Daten korrekt vor.
Ich stelle die Parameter im TCP- und Modbus-Master-Verbindungs-FB wie im Simulationsprogramm ein. Ich erhalte die Fehlermeldung 10007506: Ich glaube, ich habe die Daten falsch definiert und wie viele Register müssen gelesen werden ... kann es sein?
Die Daten, die ich zu lesen versuche, sind ein Wert im 5-Zahlenregister, der als 32-Bit-Ganzzahl definiert ist (es ist eine Temperatur).
Ich definiere eine DINT-Variable in LogicLab, ich definiere die anderen Parameter, die Adresse minus eins, also gebe ich 4, aber ich bekomme immer diesen Fehler. Ich habe versucht, die Variable anders zu definieren (INT, USINT usw.), aber nichts.
Ich weiß, dass ich einen trivialen Fehler mache, weil das Objekt im Modbus kommuniziert, aber ich verstehe nicht, wo ich falsch liege.
Verwenden Sie Spionage ist die Lösung, mit der Sie verstehen können, wo Sie sich irren. Wir sprechen zuerst in diesem Beitrag darüber, oder wenn Sie danach suchen, finden Sie viele Themen, die sich mit der Spionagekonsole befassen (Artikel).
Ich nehme diesen Beitrag noch einmal, um den Unterschied zwischen 10007500-7-Typfehlern zu verstehen. Ich erkläre es. Ich habe eine SlimLine Cortex M7 [MPS054B110] frage ich über eine TCP / IP-Verbindung ein modBus-Gerät ab, das mir 8 BYTEs an jeweils 4 verschiedenen Adressen zurückgibt, um Float-Werte (REAL) zu erstellen. Die Anfrage erfolgt ununterbrochen und passiert mir auf absolut zufällige Weise (ich habe alles überprüft: Zeit, Gleichzeitigkeit mit anderen Funktionen usw.), dass nach 2-3 Tagen oder nach 5 die Kommunikation unterbrochen wird und der Fehler 10007505 erzeugt wird.
Die einzige Möglichkeit, die Kommunikation neu zu starten, besteht darin, die Kommunikation neu zu starten SlimLine. Da ich dachte, es könnte ein Problem mit dem Gerät sein, habe ich einen PC an das Gerät selbst angeschlossen und mit einem kleinen Programm in Python zwei Wochen hintereinander überwacht, aber die Kommunikation wurde nie unterbrochen. Was bedeutet dieser Fehler im Detail zusätzlich zu dem generischen "Fehler beim Empfangen des Antwortrahmens (falsches Zeichen, falsche Länge, CRC)"? Können Sie sich noch andere Tests vorstellen?
Der von Ihnen erwähnte Fehler wird angezeigt, wenn Sie Zeichen in der Antwortzeichenfolge vermissen. Dies könnte ein ähnliches Problem sein wie das, das in den letzten Beiträgen von gemeldet wurde dieses Thema. Um das Problem zu verstehen, wäre es nützlich, einen Spionagebericht über die Kommunikation mit Toolly zu haben.
Da es eine Weile funktioniert und dann einfriert, ist es sehr seltsam, natürlich den ModbusMaster FB zu verwenden, der das verwendet IFTime Um die Modbus-Pakete aufzuteilen, reicht es für das Slave-Gerät aus irgendeinem Grund aus, die Antwort auf mehrere TCP-Pakete zu fragmentieren, damit dies das Problem verursachen kann.
Wie in dem Thema empfohlen, das ich mit Ihnen verlinkt habe, empfehle ich Ihnen, den Modbus-Verwaltungs-FB durch die neue Version zu ersetzen ModbusMaster_v1 Das Paket wurde komplett neu gestaltet, wodurch die Kontrolle über die Interframe-Zeit entfällt. Es wird vollständig abgehört und überprüft, wodurch es unabhängig von der Zeit wird.
- Sie müssen angemeldet sein, um auf dieses Thema antworten zu können.