spstiger Support-Community

Daten schreiben stoppt Kommunikation nach Kinco DTools 3.5 -> 4.5 Migration

Turbo

Hallo Community,

Könnt ihr mir bitte bei folgendem Problem helfen oder mir eine Anleitung geben?
Ich habe ein Projekt von Kinco DTools 3.5 auf 4.5 migriert:
– Modbus RTU (HMI ist Master, PLC ist Slave)
– Permanente Lesevorgänge durch die Komponente „Timer“ + „Data transmission“
– Schreiben durch Benutzereingabe in die Komponente „Number“ (Ziel ist PLC) oder durch Eingabe von Daten in die Komponente „Number“ und Senden einer Anfrage durch Drücken der Komponente „Data transmission“

Beim Schreiben (egal, ob 0x06 oder 0x10) stoppt die Kommunikation. Keine Lese- oder Schreibanfragen (auch wenn ich dieselbe Komponente bearbeite). Nach ca. 10 Sekunden erhalte ich die Fehlermeldung „[16] Server nicht bereit“.

Zusätzliche Beobachtung:

Daten erreichen Slave-Gerät erfolgreich.
Es liegt kein PLC-Problem vor (habe echte PLC ausprobiert, verschiedene Emulationen über Anwendungen wie Modbus Slave).
Auf der Slave-Seite sehe ich bei Schreibanfragen sowohl Anfrage als auch Antwort (überprüft im Modbus Slave-Kommunikationsprotokoll sowie im seriellen Port-Monitor).
Ich habe die Komponente „Bit state lamp“ hinzugefügt und mit der Komponente „Data transmission“ verbunden. Beim Auslösen von Benachrichtigungen (Attribute – Steuerungseinstellungen – Benachrichtigungen) sehe ich ein unterschiedliches Verhalten:
* Wenn der Auslöser „Written Notice“ (d. h. vor dem Schreiben) ist, wird er ausgelöst.
* Wenn der Auslöser „After Written Notice“ ist, wird er NICHT ausgelöst.

Es scheint also, als ob auf Kinco-Seite nach dem Senden der Schreibanfrage etwas kaputt ist. Ich weiß aber nicht, wie ich die Ursache finden kann, da die Debug-Tools keine Protokollierung durchführen.

Haben Sie eine Idee, woran das Problem liegen könnte oder wie ich es finden kann? Oder gibt es vielleicht nicht offensichtliche Auswirkungen beim Schreiben von Daten?

P.S.: Entschuldigung, ich kann kein Deutsch, also habe ich einen Online-Übersetzer verwendet.

HMI

Welches Kinco-Display (Modellbezeichnung) und welche Steuerung benutzt du?.
Which Kinco display (model name) and which controller are you using?

Turbo

HMI Welches Kinco-Display (Modellbezeichnung) und welche Steuerung benutzt du?.

Es handelt sich um Kinco GL100E und einen von unserem Unternehmen entwickelten Controller (Modbus RTU unterstützt).
Ich bin mir jedoch sicher, dass es sich nicht um ein Problem mit dem Controller handelt, sondern um etwas innerhalb des Projekts – da das Verhalten nicht nur bei einem echten Controller, sondern auch bei mehreren Anwendungen wie ModbusSlave gleich ist.

HMI

Du hast also das Display bereits mit der Software ModbusSlave getestet und dabei das
gleiche Verhalten festgestellt wie mit eurem Controller?

Hast du das GL100E-Display mit dem KDManager schon auf die neueste Firmware-Version aktualisiert?
Und verwendest du auch die aktuellste Version von Kinco DTools (siehe Screenshot)?

Turbo

HMI Du hast also das Display bereits mit der Software ModbusSlave getestet und dabei das
gleiche Verhalten festgestellt wie mit eurem Controller?

Ja, richtig, getestet mit echtem Controller und 3 verschiedenen Anwendungen wie ModbusSlave

HMI Hast du das GL100E-Display mit dem KDManager schon auf die neueste Firmware-Version aktualisiert?
Und verwendest du auch die aktuellste Version von Kinco DTools (siehe Screenshot)?

Ja, es ist auf dem neuesten Stand.

Aber ich glaube nicht, dass das Problem durch DTools oder HMI selbst verursacht wird. Wahrscheinlich liegt es an einem Problem mit dem Projekt.
Ich verstehe, dass es schwierig ist, konkrete Vorschläge zu machen, ohne das Projekt gesehen zu haben (da ich offenbar bereits alle offensichtlichen Optionen ausprobiert habe). Daher suche ich eher nach zusätzlichen Informationen wie einer detaillierteren Anleitung (im Vergleich zum Handbuch, das DTools beiliegt) oder weiteren Details zum Debugging oder Logging.

HMI

ok.. dann warten wir mal ob dem Steffen noch etwas einfällt oder
er sich mal dein Projekt ansieht.
Weitere Informationen zum Debugging oder Logging gibt es glaube ich nicht von Kinco.

Gruß

Turbo

HMI Weitere Informationen zum Debugging oder Logging gibt es glaube ich nicht von Kinco.

Das ist traurig. Ich hatte gehofft, dass es zumindest einige grundlegende Protokollierungs-/Debugging-Funktionen gibt.

HMI Das ist nur ein Hinweis, siehe mal ob bei dir alle betroffenen Adressen (Variablen) tatsächlich als verwendet Address Browsing markiert sind.

Ich habe versucht, bei einigen Elementen in „Address Browsing“ auf „OK“ zu klicken, aber es ändert sich nichts. Außerdem gibt es sehr viele Elemente, sodass ich nicht wirklich alle durchgehen kann.

spstiger Es muss im Projekt noch irgendwo eine andere Kommunikation eingestellt sein, wie MQTT, OPC UA, FTP, VNC Client oder ein Netzwerk-Treiber. Diese Funktion löst den Fehler aus.

Seltsam, wir sollten außer ModbusRTU keine aktiven Kommunikationen haben, aber ich werde das noch einmal überprüfen. Außerdem ist es immer noch seltsam, dass das Schreiben in Register die Kommunikation unterbricht und genau danach die Meldung „Server Not Ready“ angezeigt wird.

Ich füge das modifizierte Projekt bei, in dem die meisten Frames entfernt wurden, aber der Hauptbildschirm mit der großen blauen Komponente „Data Transmission” erhalten geblieben ist, auf die man klicken kann, um die Modbus-Anfrage zu aktivieren.
Project link
Ich verwende die Online-Simulation DTools + die kostenlose Version von VSPE (https://eterlogic.com/products.vspe.html) + eine beliebige Anwendung wie ModbusSlave mit 100 Eingängen und 100 Halteregistern.

Um es noch einmal zu verdeutlichen:
Hauptfrage – warum unterbricht das Senden von Daten durch Klicken auf „Data Transmission“ die Kommunikation? Denn sowohl weitere Klicks darauf als auch kontinuierliche Leseanfragen danach werden nicht gesendet.
Zusatzfrage – warum wird der Fehler „[16] Server Not Ready“ angezeigt?

HMI

Ich hatte einmal ein Problem mit der Schedule-Funktion, als ich eine Zeitschaltuhr aus einem Projekt
in ein neues Projekt kopiert habe. Dort funktionierte sie zunächst nicht.
Im Address Browsing fiel mir dann auf, dass die eigentlich genutzten Adressen nicht rot markiert waren
also nicht als verwendet galten.

Erst nachdem ich in der Schedule-Liste alle Variablen einmal geöffnet und mit OK bestätigt hatte, wurden sie
korrekt als verwendet markiert. Danach funktionierte die Wochenschaltuhr einwandfrei.
Das ist nur ein Hinweis, siehe mal ob bei dir alle betroffenen Adressen (Variablen) tatsächlich als verwendet
Address Browsing markiert sind.
Mehr fällt mir sonst ohne Projekt auch nicht ein

spstiger

Server Not Ready bedeutet ein Kommunikationsproblem auf der Netzwerk-Ebene. Das HMI versucht eine TCP-Verbindung aufzubauen, aber erreicht den Teilnehmer nicht.

Es hat keinen Bezug zur Modbus RTU, da das seriell läuft.

Es muss im Projekt noch irgendwo eine andere Kommunikation eingestellt sein, wie MQTT, OPC UA, FTP, VNC Client oder ein Netzwerk-Treiber. Diese Funktion löst den Fehler aus.

spstiger

In der "Data Transmission" muss etwas konfiguriert sein, dass nicht da ist. Eventuell in der Quelladresse. Oder es wird ein Makro oder ein Register ausgelöst durch die Schaltfläche in den "Steuerungseinstellungen".

"[16] Server Not Ready" bedeutet, es wird versucht eine TCP-Verbindung aufzubauen, aber die IP ist nicht erreichbar. Es ist ein Fehler für IP-basierte Kommunikation, nicht für serielle Kommunikation.

"PLC No Response" bedeutet, die SPS antwortet nicht oder antwortet mit einem Fehler. Das kann sowohl auf Netzwerk-Ebene als auch auf der Protokoll-Ebene darüber passieren.

Serielle Protokolle lösen "Server Not Ready" nicht aus.

spstiger

Zum Debugging im Netzwerk eignet sich Wireshark, wenn man einen passenden Hub oder Switch hat.
Probiere auch mal die Online-Simulation mit DTools. Kannst du den Fehler hier reproduzieren?

Falls ja, kannst du die Kommunikation in Wireshark aufzeichnen und schauen, was hier versucht wird anzufragen.

spstiger

Poste gern mal einen Screenshot der Einstellungen des Data Transmission Buttons, vielleicht sehen wir ja etwas. Auch gern für die "Steuerungseinstellungen" falls da noch etwas eingestellt ist.

Turbo

spstiger Poste gern mal einen Screenshot der Einstellungen des Data Transmission Buttons, vielleicht sehen wir ja etwas. Auch gern für die "Steuerungseinstellungen" falls da noch etwas eingestellt ist.

Ich verwende nur ModbusRTU, nicht Modbus TCP. Daher scheint Wireshark hier nicht weiterhelfen zu können. Außerdem habe ich die ModbusRTU-Kommunikation überprüft – nach der Schreibanforderung wird alles angehalten.

Das Problem tritt auch dann auf, wenn ich keinen Trigger verwende, sondern nur auf die Komponente „Datenübertragung” klicke.

Das Problem tritt NICHT auf, wenn ich NICHT schreibe.

Ich habe ein Beispielprojekt in meiner obigen Nachricht angehängt.

Und hier ist ein kleines Demo-Video:

spstiger

Die Modbus-Kommunikation funktioniert ohne Probleme, der Schreibbefehl kommt auch an.
Es liegt nicht an dem Schreibbefehl selber. Es muss irgendwelche Neben-Effekte geben.

Eventuell löst der Schreibbefehl eine Datenänderung in der SPS aus, die dann in anderem Kommunikationsverhalten oder der Übertragung anderer Daten mündet?

In dem Projekt sind vor allem Datenübertragungen und Makro-Auslöser auf dem Common Window und ein relativ komplexes Macro für Init und auf dem Common Window drauf.

Ich vermute, es hat etwas damit zu tun, ohne dass ich es genauer eingrenzen kann.

Es gibt auf dem Window auch 5 Direkte Fenster "Direct Window", die alle das gleiche Fenster 0 anzeigen. Das ist ebenfalls etwas seltsam.

Turbo

spstiger der Schreibbefehl kommt auch an

Nicht wirklich. Es scheint, als würde HMI die Antwort zum Schreiben nicht erkennen oder nicht verarbeiten können – denn die Lampe für „Schriftliche Benachrichtigung” (vor der Kommunikation) funktioniert, die für „Nach schriftlicher Benachrichtigung” jedoch nicht.

spstiger In dem Projekt sind vor allem Datenübertragungen und Makro-Auslöser auf dem Common Window und ein relativ komplexes Macro für Init und auf dem Common Window drauf.

Es ist möglich, aber ich bin verwirrt – warum unterbricht eine einzelne manuelle Schreibanforderung die gesamte Kommunikation? Denn auf der HMI-Seite wird ja nichts geändert, es wird lediglich das Register gelesen und in die SPS geschrieb

spstiger Es gibt auf dem Window auch 5 Direkte Fenster "Direct Window", die alle das gleiche Fenster 0 anzeigen. Das ist ebenfalls etwas seltsam.

Höchstwahrscheinlich liegt es daran, dass ich die meisten Frames entfernt habe, um das Projekt zu vereinfachen. Jedenfalls hat das keinen Einfluss auf das Problem.

spstiger Wenn du ein neues Projekt anlegst, das nur einen Wert liest aus dem Modbus und nur den Schreibbefehl ausführt, wirst du wahrscheinlich keine Probleme haben.

Ja, für ein neues Projekt ist das kein Problem. Aber ich muss mit einem bestehenden Projekt arbeiten, das ziemlich groß ist, sodass ich es nicht umschreiben kann.

spstiger

Wenn du ein neues Projekt anlegst, das nur einen Wert liest aus dem Modbus und nur den Schreibbefehl ausführt, wirst du wahrscheinlich keine Probleme haben.

spstiger

Der letzte Befehl in der Aufzeichnung ist ein "Function Code 6", also das Schreiben eines einzelnen Halteregisters (4X)
https://www.simplymodbus.ca/FC06.htm

Es wird der Wert CC CD also Dezimal 52429 an Adresse 0 der Halteregister geschrieben.

Der Befehl wird auch vom Server (Slave) richtig quittiert, indem einfach der gleiche Befehl wiederholt wird.

Danach stoppt die Kommunikation, es muss also irgendwo im Programm ein schwerwiegender Fehler auf dem HMI ausgelöst worden sein. Das hat aber nichts mit dieser Kommunikation zu tun.

spstiger

Das Problem ist ganz sicher nicht der einfache Schreibbefehl, sondern irgendeine Sonderfunktion, die damit interagiert. Kinco entwickelt seit 20 Jahren Geräte mit Modbus RTU. Bei einfachen Funktionen ist es daher sehr unwahrscheinlich, dass ein Bug bei Kinco vorliegt.

Probiere bitte mal genau die gleiche Funktion in einem neuen Projekt, nur um es zu testen. Wenn es dort funktioniert, liegt es an etwas in deinem bestehenden Projekt.

Lösch bitte einmal die Makros aus deinem Projekt (bitte vorher ein Backup machen) und probiere, ob es ohne die Makros funktioniert. Ich tippe auf Interaktionen mit dem Modbus Makro.

spstiger

Das ist übrigens immer eine gute Vorgehensweise für das Finden von Problemen in größeren Projekten:

Ein neues Projekt nur mit der problematischen Funktion erstellen, um zu testen, ob es ein Problem mit der Grundfunktion gibt
Im großen Projekt nach und nach Dinge rauslöschen und nach jedem Löschen prüfen, ob es funktioniert. Wenn es funktioniert, habt ihr die Ursache des Problems gefunden und könnt dort genauer schauen.