Gelöst: TC3: Log Level für TF6250 festlegen oder Logging ausschalten

O

oliver.tonn

Level-3
FAQ-Team
Power-User
Beiträge
6.617
Reaktionspunkte
1.599
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
ich hatte hier verschiedene Probleme mit der Modbusübertragung. Um der Ursache auf die Spur zu kommen wurde von Beckhoff ein Logging der TF6250, ich meine in der Registry, eingeschaltet. Leider habe ich mir nicht gemerkt wo und wie das erfolgte. Ich möchte das jetzt wieder ausschalten, dummerweise ist mein Ansprechpartner bei Beckhoff im Moment nicht erreichbar.
Weiß einer hier, wie das geht?
Zum Einsatz kommt TC3.4024.53 auf einem WEC 7 System.
 
So, ich gebe mir hier mal selber die Antwort.
Wie blind kann man eigentlich sein, dass man die Lösung den ganzen Tag übersieht. Wäre ich noch gelenkiger würde ich mir selber in den Ar... treten.
Die Einstellungen für das Logging von TF Paketen müssen in der Registry erfolgen. Unter "HKEY_LOCAL_MACHINE\SOFTWARE\Beckhoff\" muss, soweit er noch nicht vorhanden ist, ein Schlüssel mit dem Namen "TwinCAT3 Functions" hinzugefügt werden. Unter diesem Schlüssel müssen für jedes TF Paket für das ein Logging erfolgen soll ein Schlüssel mit der Nummer und dem Namen des TF Paketes hinzugefügt werden. In meinem Fall für Modbus muss der Schlüssel "TF6250 Modbus TCP" heißen.
Unter diesem Schlüssel muss nun ein DWORD Wert mit dem Namen "LogLevel" hinzugefügt werden. Dieser kann Werte von 0 bis 6 haben, wobei bei einem Wert von 0 das Logging ausgeschaltet ist, nach einem Neustart wird dieser Wert verwendet. Die Loggingdatei wird im Boot-Ordner von TwinCAT abgelegt und lässt sich erst löschen, wenn der DWORD Wert auf 0 gesetzt und das System neu gestartet wurde.
Die Frage, wie man so blind sein kann, kann ich jetzt auch beantworten. Ich arbeite hier an einer Musteranlage und habe von dieser ein Master-Image erstellt, dass auf andere Anlagen eingespielt werden soll. Ich hatte nun immer die Karte der Anlage gesichert und auf diese dann das Master Image eingespielt und bei diesem nach der Einstellung gesucht. Was ich nicht mehr im Kopf hatte war, dass zu der Zeit als ich das Master Image erzeugt hatte das Logging auf der Anlage noch gar nicht hinzugefügt war und somit die Schlüssel auch nicht existierten. Ich hatte zum Schluss von der Anlage nur noch den Boot-Ordner auf das Master Image gezogen, wodurch die Registry erhalten blieb.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo!

was beinhaltet die Log Datei? Kannst bitte einen Ausschnitt posten?

Welche Probleme hattest du?
Ich habe sehr viel mit Ladestationen, Batteriespeicher, Multifunktionsmessgeräte und PV Wechselrichter verschiedenster Hersteller zu tun. Bis auf den Huawai WR ging alles recht problemlos (wenn man die üblichen Probleme wie "wo fängt man an zu Zählen" , "wie sind die empfangenen Wörte zu interpretieren" und "Warum stimmt schon wieder die Dokumentation nicht" gelöst hat). Bei dem Huawai musste ich mit FB_SocketConnect, FB_SocketSend und FB_SocketReceive arbeiten. Sonst hatte ich keine Chance, den Wechselrichter zum Antworten zu übereden.

Danke!

VG

K.
 
Klingone22 schrieb:
was beinhaltet die Log Datei? Kannst bitte einen Ausschnitt posten?

Welche Probleme hattest du?
Zum Vergrößern anklicken....
Bevor ich hier Ausschnitte poste muss ich kurz etwas ausholen.
Die Anlage an der die Probleme auftreten ist ein Verbund von 8 USVen, die elektrisch parallel geschaltet sind. Ein Steuerschrank mit einem Beckhoff CP2715 Panel PC kommuniziert mit diesen USVen nacheinander via Modbus TCP über eine Instanz des Funktionsbausteins "FB_MBReadRegs", wobei pro USV drei Abfragen an unterschiedlichen Adressen mit einer unterschiedlichen Anzahl an Registern erfolgt. Es gibt im ganzen Projekt auch nur diese eine Instanz. Außerdem soll(te) auch ein Janitza Messgerät über diese Instanz abgefragt werden, hier allerdings nur mehrere Register von einer Adresse.
In einem Array einer Struktur ist die Reihenfolge hinterlegt, wann von welcher IP, ab welcher Adresse, welche Anzahl an Registern ausgelesen werden soll.
Hier mal ein Scope View, wo der Fehler zu sehen ist. Die erste (oberste) Achse enthält den Index an dem aus dem Array ausgelesen wird, welcher Slave, an welcher Adresse abgefragt werden soll. Die zweite ist der Eingang "bExecute", die Dritte der Ausgang "bBUSY", die vierte der Ausgang "bError" des FBs, die fünfte Achse zeigt den Zustand des Ausgangs "cbRead" des FBs an und somit die Anzahl der gelesenen Bytes.
Die empfangenen Daten werden in einem Word Array abgelegt. Die letzte Achse enthält die Daten eines einzelnen Index dieses Arrays.
1752125116413.png
Vorab noch eine Bemerkung zum Janitza. Das Janitza wurde nie montiert, aber abgefragt. Das Janitza wird bei Array Index 25 abgefragt, was der höchste Index ist. Diese Abfrage verursacht natürlich einen Fehler.
Auf dem Scope View wird zunächst die Abfrage abgearbeitet, die im Array an Index 22 steht. Vom Slave sollen 80 Register, also 160 Bytes abgefragt werden. Was hier schon auffällig ist, ist, dass der Ausgang "cbRead" des FBs 60 Bytes meldet. Diese Abfrage wird mit einem Fehler (Fehlernummer 1861Dez) beendet/abgebrochen.
Anschließend wird die Abfrage ausgeführt, die im Array an Index 23 steht. Es soll der selbe Slave an einer anderen Adresse abgefragt werden, diesmal sollen 100 Register abgefragt werden, was 200 Bytes entsprechen würde. Auch hier liegt am Ausgang "cbRead" des FBs wieder der Wert 60 an. Hierbei handelt es sich übrigens um die Anzahl Bytes, die bei der jeweils dritten Abfrage eines Slaves übermittelt werden soll.
Diese Abfrage wird scheinbar erfolgreich beendet, denn der Ausgang "bBUSY" geht auf FALSE und der Ausgang "bError" bleibt auf FALSE. Hier passieren nun ganz seltsame Dinge. Der Ausgang "cbRead" wechselt im selben Zyklus wie "bBUSY" von 60 Bytes auf 160 Bytes, dies entspricht der Anzahl Bytes, die bei der vorhergehenden Abfrage übermittelt werden sollten. Das Datum (Ist tatsächlich der Singular von Daten), das auf der letzten Achse angezeigt wird ist die Warn ID, die von der achten USV übermittelt wird. An dieser USV liegt keine Warnung an, daher muss hier eigentlich eine 0 gemeldet werden, was aber nicht der Fall ist. Das übermittelte Datum entspricht dem Inhalt des Registers der vorhergehenden Abfrage.
Hier noch ein paar Auszüge aus dem Logfile:
Code: 
18-06-2025:13:43:44.663: CTcModbusSrv::CTcModbusSrv tComm:5000 tKA:0 prio:200

18-06-2025:13:43:44.702: >>TcModbusSrv: Start
18-06-2025:13:43:44.715: TcModbusSrv: Load mapping from file succeeded
18-06-2025:13:43:44.719: TcModbusSrv: loaded configuration file \Hard Disk\TwinCAT\Functions\TF6250-Modbus-TCP\Server\TcModbusSrv.xml
18-06-2025:13:43:44.731: <<TcModbusSrv: Failed to connect server port hr=0x98110001

18-06-2025:13:48:01.676: >>CTcModbusSrv::Stop

18-06-2025:13:48:01.691: CTcModbusSrv::Stop Stop client

18-06-2025:13:48:01.697: CTcModbusSrv::Stop Stop server

18-06-2025:13:48:01.701: CTcpModbusServer::CloseConnections(); Entry...

18-06-2025:13:48:01.706: CTcpModbusServer::CloseConnections();            Exit

18-06-2025:13:48:01.711: CTcModbusSrv::Stop disconnect ads server

18-06-2025:13:48:01.715: <<CTcModbusSrv::Stop Stop server

18-06-2025:13:49:56.883: CTcModbusSrv::CTcModbusSrv tComm:5000 tKA:0 prio:200

18-06-2025:13:49:56.887: >>TcModbusSrv: Start
18-06-2025:13:49:56.893: TcModbusSrv: Load mapping from file succeeded
18-06-2025:13:49:56.897: TcModbusSrv: loaded configuration file \Hard Disk\TwinCAT\Functions\TF6250-Modbus-TCP\Server\TcModbusSrv.xml
18-06-2025:13:49:56.914: CTcpModbusServer::CloseConnections(); Entry...

18-06-2025:13:51:47.161: CTcpSocket::Release this = 0x008FDDD0, refCnt=1.
18-06-2025:13:51:47.161: >> CTcpSocket::CloseSocket(); this = 0x008FDDD0,
readId == 0x7f8051e socket=5 m_bCreated=1 m_bListening=0.
18-06-2025:13:51:47.168: AmsReceiverThread (008FDDA0-0x789058e) has ended.

18-06-2025:13:51:47.170: CTcpSocket::CloseSocket(); Lock>> this = 0x008FDDD
 ThreadId == 0x7f8051e socket=5 m_bCreated=1 m_bListening=0.
                                                                        
18-06-2025:13:51:47.179: CTcpSocket::CloseSocket(); shutdown reciver this = 0x008FDDD0, ThreadId == 0x7f8051e.

18-06-2025:13:51:47.183: CTcpSocket::Receiver; SOCKET_ERROR err=0x2714!
18-06-2025:13:51:47.184: CTcpSocket::CloseSocket() (1) succeeded this =
008FDDD0, ThreadId == 0x6ab0026
18-06-2025:13:51:47.190: CMBAP::OnReceive(); SocketError:10004
 6   7 4
18-06-2025:13:51:47.192: CMBPduSync signal connection aborted
:
18-06-2025:13:51:47.199: CTcpSocket::Receiver; nErr == 10004 this = 0x008FDDD0!
18-06-2025:13:51:47.201: CTcpSocket::CloseSocket(); unlock>>this = 0x008FDDD0, T
eadId == 0x7f8051e.
18-06-2025:13:51:47.207: >> CTcpSocket::CloseSocket(); this = 0x008FDDD0, ThreadId == 0x7f8051e socket=-1 m_bCreated=0 m_bListening=0.
18-06-2025:13:51:47.210: CTcpSocket::CloseSocket(): Waiting for thread (0x7f8051e) exit !
D$\¡|‡ ‹ ‹ ‹Ð¡|‡ +‰$¡|‡ ‹ ‹@ÿÐ!ÿ‹D$`ƒÄ
18-06-2025:13:51:47.217: CTcpSocket::CloseSocket(); Lock>> this = 0x008FDDD0, ThreadId == 0x7f8051e socket=-1 m_bCreated=0 m_bListening=0.
uô
18-06-2025:13:51:47.223: CTcpSocket::CloseSocket(); unlock>>this = 0x008FDDD0, ThreadId == 0x7f8051e.

18-06-2025:13:51:47.227: << CTcpSocket::CloseSocket() this = 0x008FDDD0, ThreadId == 0x7f8051e.

18-06-2025:13:51:47.233: ####CTcpSocket::Receiver; this = 0x008FDDD0, Thread (0x7f8051e) of TCP port is being stopped!

18-06-2025:13:51:47.237: CTcpSocket::CloseSocket(): Wait for thread (0x7f8051e) exit successful !
 
Zuletzt bearbeitet:
Zurück
Oben