# Probleme mit Modbus RTU Kommuinikation mit 750-653/003-000 (Slave)



## julianpe (4 Januar 2018)

Hallo zusammen,

ich möchte eine Modbus RTU (basierend auf einer Zweidraht RS485 Verbindung) realisieren.
Dazu habe ich eine Modbus RTU Master Software (Modbus Poll) auf dem Laptop laufen.
Weiterhi nutze ich einen Meilhaus Redcom USB<->RS485/RS422 Konverter. Den Konverter habe ich gemäß
beiliegender Bedienungsanleitung mittels Jumpersteckern auf RS485 eingestellt.

Nun nutze ich einen Sub-D Stecker mit folgender Belegung (Auszug aus Handbuch von Meilhaus):


Konverter                   Wago 750-653/003-000
Pin 1 = Data - (A)----------Pin 5 (TxD-)
Pin 2 = Data + (B)----------Pin 1 (TxD)
Pin 5 = GND-----------------Masse


Mittels Wago IO Check kann ich das Eingangsprozessabbild der Kommunikationsklemme 750-653/003-00 einsehen.

Ich erhalte folgendes Abbild (toggelt):

Byte    7    6    5    4    3    2    1    0
    00    00    00    00    00    00    01    12
    00    00    00    00    00    00    00    00

Währenddessen requeste ich mittels Modbus Poll folgende Nachricht:
01 02 00 02 00 01 18 0A

Modbus Poll meldet einen Timeout error.

Mein Problem ist, dass ich nicht genau abschätzen kann, an welcher Stelle der Schuh drückt.
Wer kann etwas dazu sagen?

Danke und Gruß


----------



## weißnix_ (4 Januar 2018)

Die Frage ist:
-passt die Baudrate?
-passt die Adressierung?

Am Eingangsprozessabbild kannst Du IMHO nicht viel sehen, da zu schnell. Du musst auf der Wago ein Progrämmchen laufen lassen, welches den Input ausliest und anzeigt.
Vermutlich wird auch erst dann eine Kommunikation zustandekommen. Die Klemme ist IMHO erstmal nur eine serielle Schnittstelle.


----------



## julianpe (4 Januar 2018)

Baudrate habe ich foldermaßen eingestellt:
In IO Check für die Klemmenparametertierung 9600
In der SPS Software vom Baustein MB_Slave 9600
Und in der Connection in ModbusPoll auch 9600.


BTW:
In der Steuerungskonfiguration in Codesys sehe ich im Online Modus,
dass die Binäreingänge "Reception request" sowie "Number of received characters Bit 0" regelmäßig getoggelt werden.
Weiterhin wird auch das Input Byte "Input data Byte 0" im selben Abstand von 0 auf 1 getoggelt.


----------



## weißnix_ (4 Januar 2018)

Ein Timeout kann ja nur zustandekommen wenn eine antwort zwar erwartet, aber nicht empfangen wird. Ergo musst Du Dein SPS-Programm mal genau ansehen.
Bei Modbus RTU antwortet nur der adressierte Teilnehmer. Alle anderen verwerfen die Pakete. Hast Du also auf beiden Seiten eine korrekte Adress3?


----------



## julianpe (4 Januar 2018)

Alles klar, das ist dann momentan noch gewollt, da der Modbus Slave Baustein nur initialisiert ist, jedoch noch keine Antworten sendet.
Das Problem ist, dass in dem Baustein keine eingehenden Functions Codes Request vom Modbus RTU Master erkannt wird.
Hingegen im Eingangsbuffer werden temporäre Werte abgelegt, die z.T. der CRC Summe des Telegrams entsprechen.


----------



## wolfi-sps (4 Januar 2018)

Hallo julianpe,

welche CodeSys Version hast Du - ab der 2.3.9.42 (oder 47)  gibt es den Modbus-Konfigurator.
Den verwende ich. Habe vorher auch den Modbusbaustein verwendet -ist aber sehr aufwendig.

Wolfgang


----------



## julianpe (5 Januar 2018)

Hallo Wolfgang,

danke für Deine Rückmeldung. Ich habe folgendes Konfigurationsfenster in Codesys gefunden.
Jedoch wird mir nur Modbus UDP und Modbus TCP angeboten - kein Modbus RTU so wie ich es benötige.


----------



## ccore (5 Januar 2018)

Hallo julianpe, 

hast du auch einen Modbus Master hinzugefügt? 


Im Fenster Modbus-Master Konfiguration mit Rechtsklick auf den Master. 

Dann hast du auch die Auswahl mit dem RTU Master.

Gruß
Christian


----------



## weißnix_ (5 Januar 2018)

Master scheint aber der USB-Adapter lt.#1.
Also Modbus RTU Slave hinzufügen


----------



## Tobsucht (5 Januar 2018)

Hallo julianpe,

es könnte durchaus ein sein, dass das Timing des Slaves nicht passt.
Zu aller erst würde ich den Modbus_Extended_Slave verwenden.

Wichtig ist hier der Parameter tTIME_OUT. Nach dem letzten empfangenen Zeichen des Masters wird diese Zeit gewartet bis das empfangene Telegramm ausgewertet wird.
Ist diese Zeit zu groß gewählt. läuft der Master in den Timeout.

Deine Verdrahtung scheint in Ordnung zu sein.
Aufgrund Deines Screenshots gehe ich davon aus, dass Du einen 750-8203 einsetzt. Dieser hat keine RS232/RS485 Schnittstelle. Deshalb taucht im Screenshot Modbus RTU nicht auf.

Grüße


----------



## julianpe (15 Februar 2018)

Hallo zusammen,

nochmal ein Statusupdate.

Ausgangssituation:
Laptop mit Modbus Poll (Master)
Über USB mit einem Meilhaus RS485 Converter verbunden.

Von dort aus mittels SUB-D / offenes Kabelende auf einen Wago 750-653/003-000 (Serielle Schnittstelle für RS422/RS485).

In meinem Codesys Programm kann ich mit der Funktion Modbus_Extended_Slave die Anfragen vom Master im ReceiveBuffer einsehen.
Zu Testzwecken frage ich nur ein binäres Register an und sende auf dem Ausgangsdatenarray aData[0].4 ein dauerhaftes true.
Im Ausgangsbuffer kann ich auch diese Nachricht korrekt einsehen.

Folgende Anfrage geht von Modbus Poll an den Slave:
Tx:-01 02 00 04 00 01 F8 0B 

Bedeutet Anfrage an:
Slave-Adresse 1
Funktionscode 2
Register 4
mit der Länge 1
sowie die letzten Doppelbytes beinhalten die Checksumme.

Die identische Nachricht bekomme ich wie gesagt in meinem Codesys im Eingangsbuffer.

Über Modbus-Poll erreicht mich nun folgende Antwort:

Rx:01 02 01 01 60 48 

Bedeutet Rückmeldung von:
Slave-Adresse: 01
Funktionscode 02
Status: 01 (TRUE)
der Länge 1
mit einer Checksumme.

Das sieht nach einer erfolgreichen Kommunikation aus.

Jetzt jedoch zum merkwürdigen Teil:


```
Tx:15718-01 02 00 04 00 01 F8 0B Rx:15719-01 02 01 01 60 48 
Tx:15720-01 02 00 04 00 01 F8 0B 
Rx:15721-01 02 01 00 00 01 
Tx:15722-01 02 00 04 00 01 F8 0B 
Tx:15723-01 02 00 04 00 01 F8 0B 
Tx:15724-01 02 00 04 00 01 F8 0B 
Tx:15725-01 02 00 04 00 01 F8 0B 
Tx:15726-01 02 00 04 00 01 F8 0B 
Tx:15727-01 02 00 04 00 01 F8 0B 
Rx:15728-01 02 01 01 60 48 
Tx:15729-01 02 00 04 00 01 F8 0B 
Rx:15730-01 02 01 00 00 01 01 60 48 
Tx:15731-01 02 00 04 00 01 F8 0B 
Rx:15732-01 02 01 01 60 48 
Tx:15733-01 02 00 04 00 01 F8 0B 
Rx:15734-01 02 01 00 00 01 01 60 48 
Tx:15735-01 02 00 04 00 01 F8 0B 
Tx:15736-01 02 00 04 00 01 F8 0B 
Rx:15737-01 02 01 01 60 48 
Tx:15738-01 02 00 04 00 01 F8 0B 
[FONT=Verdana]Rx:15739-01 02 01 00 00 01 01 60 48 [/FONT]
```

Man sieht, dass die Anfrage immer identisch ist, jedoch die Rückmeldung variiert - obwohl der angefragte Wert dauerhaft stabil bleibt (auch im Ausgangsbuffer).
Nachdem bspw. zweimal hintereinander ein Tx ohne passendes Rx gesendet wird, scheint das System wieder eine valide Rückmeldung zu liefern. Zwischendurch werden Nachrichten mit Checksummen-Error ausgegeben (obwohl der Ausgangsbuffer konstant bleibt): 

Rx:15739-01 02 01 00 00 01 01 60 48 

Die Kommunikationsparameter wie folgt:

Modbus-Poll:
Baud-Rate: 19200
8 Data bits
None Parity
1 Stop Bit

Response Timeout [ms] = 2000
Delay Between Polls[ms] = 200
Flowcontrol: 
CTS, DTR enabled
DSR, RTS Toggle und Echo disabled

Codesys Schnittstelle:
Baud-Rate 19200
No Parity
Stopbit 1
Bytesize 8
Flowcontrol Modus, NCS_Halfduplex (RS485, ohne continous sending)
tTime_Out = 1000ms
Watchdog = 5000 ms





Meine Frage nun an die Profis.
An welcher Stelle könnte es noch ein Problem mit der Kommunikation geben?

Vielen Dank im Voraus,

Gruß
Julian
Meine Frage nun an die Profis.
An welcher Stelle könnte es noch ein Problem mit der Kommunikation geben?


----------



## ClMak (15 Februar 2018)

Hallo,

versuch es einmal mit geänderter Einstellung der Wago Schnittstelle 750-653
Ich würde folgende Änderung empfehlen:

Flow Control: Halfduplex *mit *continous send
tTimeout : 100ms oder 200ms

Des Weiteren wäre interessant, welche Zykluszeit bzw. Taskkonfiguration das SPS-Programm hat.

VG


----------



## Triox85 (16 Februar 2018)

Hast du die Datenbreite der Karte richtig eingestellt und auch so eingebunden?
Das kannst du mit der Wago IO check sehen und auch unter Einstellung anpassen.


----------



## julianpe (16 Februar 2018)

Triox85 schrieb:


> Hast du die Datenbreite der Karte richtig eingestellt und auch so eingebunden?
> Das kannst du mit der Wago IO check sehen und auch unter Einstellung anpassen.



Habe die defaultmäßig auf 3 Byte gelassen - an welcher Stelle könnte diese Einstellung problematisch werden?


----------



## julianpe (16 Februar 2018)

ClMak schrieb:


> Hallo,
> 
> versuch es einmal mit geänderter Einstellung der Wago Schnittstelle 750-653
> Ich würde folgende Änderung empfehlen:
> ...



Mit continous send bekomme ich gefühlt nach einer gewissen Zeit eine Menge "Datenmüll" aus dem FIFO Buffer der klemme.
Da fehlen dann zuum Teil die Slave Adresse und der Funktionscode bei der Antwort.

Das Programm welches nur für die Modbus RTU Kommunikation zuständig ist, läuft in einer einzelnen freilaufenden Task welche mit Prio 3 arbeitet.
Wie kann ich die Zykluslaufzeit berechnen/anzeigen lassen?

Vielen Dank bereits im Voraus


----------



## ClMak (16 Februar 2018)

Hallo,

die Einstellung *mit *continious send ist auf alle Fälle richtig und sollte so bleiben.
Was ist mit dem Wert für Timeout? Hast du damit schon verschiedene Einstellungen geprüft (50ms, 100ms...).
Kannst Du das Abfrageintervall einmal langsamer einstellen um zu prüfen ob das einen Einfluss hat?

Die Zykluszeit kannst Du über den PLC Browser abfragen.
1. PLC Browser öffnen
2. In die Eingabezeile den Befehl "login admin wago" eingeben und Enter drücken
3. In die Eingabezeile den Befehl "tsk" eingeben und Enter drücken.

VG


----------



## julianpe (19 Februar 2018)

Hallo,

vielen Dank fÃ¼r Deine Meldung.
Die Tasks sehen wie folgt aus:


```
Number of Tasks: 5
Task 0: SampleDistance,  ID: 3
   Cycle count: 3393
   Cycletime:       92 microseconds
   Cycletime (min): 61 microseconds
   Cycletime (max): 400 microseconds
   Cycletime (avg): 95 microseconds
   Status: RUN
   Mode:   CONTINUE
   ----
   Priority:  2
   Intervall: 100 ms
   Event:     NONE
   ----
   Function pointer: 16#B601B280
   Function index:   246


Task 1: Cyclic,  ID: 4
   Cycle count: 3394
   Cycletime:       1846 microseconds
   Cycletime (min): 1600 microseconds
   Cycletime (max): 2215 microseconds
   Cycletime (avg): 1750 microseconds
   Status: RUN
   Mode:   CONTINUE
   ----
   Priority:  1
   Intervall: 100 ms
   Event:     NONE
   ----
   Function pointer: 16#B601B22C
   Function index:   245


Task 2: ALARM_TASK,  ID: 5
   Cycle count: 1131
   Cycletime:       215 microseconds
   Cycletime (min): 215 microseconds
   Cycletime (max): 2339 microseconds
   Cycletime (avg): 318 microseconds
   Status: RUN
   Mode:   CONTINUE
   ----
   Priority:  15
   Intervall: 300 ms
   Event:     NONE
   ----
   Function pointer: 16#B60112DC
   Function index:   244


Task 3: Modbus,  ID: 7
   Cycle count: 30496
   Cycletime:       2461 microseconds
   Cycletime (min): 215 microseconds
   Cycletime (max): 99270 microseconds
   Cycletime (avg): 776 microseconds
   Status: RUN
   Mode:   CONTINUE
   ----
   Priority:  63
   Intervall: 0 ms
   Event:     NONE
   ----
   Function pointer: 16#B603942C
   Function index:   481


Task 4: KBus-Task,  ID: 999
   Cycle count: 0
   Cycletime:       953 microseconds
   Cycletime (min): 769 microseconds
   Cycletime (max): 1938 microseconds
   Cycletime (avg): - microseconds
   Status: RUN
   Mode:   CONTINUE
   ----
   Priority:  0
   Intervall: 0 ms
   Event:     0000:0000:0000
   ----
   Function pointer: 16#00000000
   Function index:   0
```

Das Problem mit continous send, ist, dass ich hÃ¤ufig eine Rx-Nachricht erhalte, die komplett korrupt ist:

```
Tx:550-01 02 00 04 00 01 F8 0B
Rx:551-00 00 48 01 02 01 01 60 48
```
WÃ¤ren die ersten drei Doppelbytes nicht in der Nachricht, so wÃ¤re die Nachricht valide und ich erhalte kein CheckSum Error.

Momentan lÃ¤uft folgende Konfiguration:

Modbus RTU Slave:
Baud-Rate: 9600
None Parity
Stopbits 1
Bytesize 8
Halfduplex mit continous sending
tTimeOut 200ms
tWatchdog 2000ms


Modbus RTU Master:
Baud-Rate: 9600
None Parity
Stopbits 1
Bytesize 8
Delay between polls 100 ms
Response Timeout 1000ms
Scan Rate 2000ms
CTS, DTR enabled
DSRm RTS Toggle disabled


Am Anfang sieht die Kommunikation gut aus, im weiteren Verlauf werden die Nachrichten jedoch wieder korrupt:


```
Tx:584-01 02 00 04 00 01 F8 0B
Rx:585-01 02 01 01 60 48
Tx:586-01 02 00 04 00 01 F8 0B
Tx:587-01 02 00 04 00 01 F8 0B
Rx:588-01 02 01 01 60 48
Tx:589-01 02 00 04 00 01 F8 0B
Rx:590-01 02 01 01 60 48
Tx:591-01 02 00 04 00 01 F8 0B
Tx:592-01 02 00 04 00 01 F8 0B
Rx:593-01 02 01 01 60 48
Tx:594-01 02 00 04 00 01 F8 0B
Tx:595-01 02 00 04 00 01 F8 0B
Rx:596-01 02 01 00 00 01 01 60 48
Tx:597-01 02 00 04 00 01 F8 0B
Rx:598-00 00 48 01 02 01 00 00 01 01 60 48
Tx:599-01 02 00 04 00 01 F8 0B
Rx:600-00 00 48 01 02 01 00 00 01 01 60 48
```



Edit:

Dieses Verhalten kann ich häufig beobachten.
Kann mir das aber nicht erklären.
Die korrekten Antworten kommen zum Master mit einem Timeout (also zwei mal Tx und einmal Rx)
Dann nach einer gewissen Zeit kommen korrupte Antworten aber ohne Timeout (Anzahl Tx und Rx identisch):


```
Tx:22005-01 02 00 04 00 01 F8 0B
Tx:22006-01 02 00 04 00 01 F8 0B
Rx:22007-01 02 01 01 60 48
Tx:22008-01 02 00 04 00 01 F8 0B
Tx:22009-01 02 00 04 00 01 F8 0B
Rx:22010-01 02 01 01 60 48
Tx:22011-01 02 00 04 00 01 F8 0B
Tx:22012-01 02 00 04 00 01 F8 0B
Rx:22013-01 02 01 01 60 48
Tx:22014-01 02 00 04 00 01 F8 0B
Tx:22015-01 02 00 04 00 01 F8 0B
Rx:22016-01 02 01 01 60 48
Tx:22017-01 02 00 04 00 01 F8 0B
Tx:22018-01 02 00 04 00 01 F8 0B
Rx:22019-01 02 01 01 60 48
Tx:22020-01 02 00 04 00 01 F8 0B
Tx:22021-01 02 00 04 00 01 F8 0B
Rx:22022-01 02 01 01 60 48
Tx:22023-01 02 00 04 00 01 F8 0B
Tx:22024-01 02 00 04 00 01 F8 0B
Rx:22025-01 02 01 01 60 48
Tx:22026-01 02 00 04 00 01 F8 0B
Tx:22027-01 02 00 04 00 01 F8 0B
Rx:22028-01 02 01 01 60 48
Tx:22029-01 02 00 04 00 01 F8 0B
Tx:22030-01 02 00 04 00 01 F8 0B
Rx:22031-01 02 01 01 60 48
Tx:22032-01 02 00 04 00 01 F8 0B
Tx:22033-01 02 00 04 00 01 F8 0B
Rx:22034-01 02 01 01 60 48
Tx:22035-01 02 00 04 00 01 F8 0B
Tx:22036-01 02 00 04 00 01 F8 0B
Rx:22037-01 02 01 01 60 48
Tx:22038-01 02 00 04 00 01 F8 0B
Tx:22039-01 02 00 04 00 01 F8 0B
Tx:22040-01 02 00 04 00 01 F8 0B
Tx:22041-01 02 00 04 00 01 F8 0B
Tx:22042-01 02 00 04 00 01 F8 0B
Rx:22043-01 02 01 01 60 48
Tx:22044-01 02 00 04 00 01 F8 0B
Tx:22045-01 02 00 04 00 01 F8 0B
Tx:22046-01 02 00 04 00 01 F8 0B
Rx:22047-01 02 01 00 00 01 01 60 48
Tx:22048-01 02 00 04 00 01 F8 0B
Rx:22049-00 00 48 01 02 01 00 00 01 01 60 48
Tx:22050-01 02 00 04 00 01 F8 0B
Rx:22051-00 00 48 01 02 01 00 00 01 01 60 48
Tx:22052-01 02 00 04 00 01 F8 0B
Rx:22053-00 00 48 01 02 01 00 00 01 01 60 48
Tx:22054-01 02 00 04 00 01 F8 0B
Rx:22055-00 00 48 01 02 01 00 00 01 01 60 48
Tx:22056-01 02 00 04 00 01 F8 0B
Rx:22057-00 00 48 01 02 01 00 00 01 01 60 48
Tx:22058-01 02 00 04 00 01 F8 0B
Rx:22059-00 00 48 01 02 01 00 00 01 01 60 48
Tx:22060-01 02 00 04 00 01 F8 0B
Rx:22061-00 00 48 01 02 01 00 00 01 01 60 48
Tx:22062-01 02 00 04 00 01 F8 0B
Rx:22063-00 00 48 01 02 01 00 00 01 01 60 48
Tx:22064-01 02 00 04 00 01 F8 0B
Rx:22065-00 00 48 01 02 01 00 00 01 01 60 48
Tx:22066-01 02 00 04 00 01 F8 0B
Rx:22067-00 00 48 01 02 01 00 00 01 01 60 48
Tx:22068-01 02 00 04 00 01 F8 0B
Rx:22069-00 00 48 01 02 01 00 00 01 01 60 48
Tx:22070-01 02 00 04 00 01 F8 0B
Rx:22071-00 00 48 01 02 01 00 00 01 01 60 48
Tx:22072-01 02 00 04 00 01 F8 0B
Rx:22073-00 00 48 01 02 01 00 00 01 01 60 48
Tx:22074-01 02 00 04 00 01 F8 0B
Rx:22075-00 00 48 01 02 01 00 00 01 01 60 48
Tx:22076-01 02 00 04 00 01 F8 0B
Rx:22077-00 00 48 01 02 01 00 00 01 01 60 48
Tx:22078-01 02 00 04 00 01 F8 0B
Rx:22079-00 00 48 01 02 01 00 00 01 01 60 48
Tx:22080-01 02 00 04 00 01 F8 0B
Rx:22081-00 00 48 01 02 01 00 00 01 01 60 48
Tx:22082-01 02 00 04 00 01 F8 0B
Rx:22083-00 00 48 01 02 01 00 00 01 01 60 48
Tx:22084-01 02 00 04 00 01 F8 0B
Rx:22085-00 00 48 01 02 01 00 00 01 01 60 48
Tx:22086-01 02 00 04 00 01 F8 0B
Rx:22087-00 00 48 01 02 01 00 00 01 01 60 48
Tx:22088-01 02 00 04 00 01 F8 0B
Rx:22089-00 00 48 01 02 01 00 00 01 01 60 48
Tx:22090-01 02 00 04 00 01 F8 0B
```


----------



## julianpe (22 Februar 2018)

Hier nochmal ein Newsupdate:

  Ich habe heute nochmal ein bisschen experimentiert und die Modbus RTU Routine exportiert.


  Diese habe ich in ein neues Projekt, basierend auf den Wago 750-881 importiert.
  Dort lief die Kommunikation perfekt und ohne jegliche Fehler.

  Den gleichen Vorgang habe ich dann mit einem anderen Wago 750-8203 Controller probiert.
  Die Steuerungskonfiguration sah nur die Klemme 750-653/003-000 (5 Byte Länge) vor.
  Auch hier gab es keine Probleme mit der Kommunikation.

  Nun habe ich das bestehende Softwareprojekt genommen und auf den anderen Wago 750-8203 kopiert.
  Hier gab es die bekannten Probleme:
  ·         Spontaner Ausfall der Kommunikation -> es wurden keine Telegramme mehr von der Klemme verschickt -> TimeOut Errror
  ·         Antworttelegramme werden häufig mit Doppelbyte Nullen gefüllt -> CheckSum Error

  Nun habe ich mir die Taskprioritäten angeschaut (PLC-Browser):


```
Number of Tasks: 5
  Task 0: SampleDistance,  ID: 4
     Cycle count: 3320
     Cycletime:       92 microseconds
     Cycletime (min): 61 microseconds
     Cycletime (max): 2739 microseconds
     Cycletime (avg): 107 microseconds
     Status: RUN
     Mode:   CONTINUE
     ----
     Priority:  8
     Intervall: 100 ms
     Event:     NONE
     ----
     Function pointer: 16#B6021C10
     Function index:   315
   
   
  Task 1: Cyclic,  ID: 5
     Cycle count: 3318
     Cycletime:       1847 microseconds
     Cycletime (min): 1662 microseconds
     Cycletime (max): 21694 microseconds
     Cycletime (avg): 2286 microseconds
     Status: RUN
     Mode:   CONTINUE
     ----
     Priority:  9
     Intervall: 100 ms
     Event:     NONE
     ----
     Function pointer: 16#B6021B68
     Function index:   313
   
   
  Task 2: ALARM_TASK,  ID: 6
     Cycle count: 1328
     Cycletime:       215 microseconds
     Cycletime (min): 185 microseconds
     Cycletime (max): 2769 microseconds
     Cycletime (avg): 254 microseconds
     Status: RUN
     Mode:   CONTINUE
     ----
     Priority:  31
     Intervall: 250 ms
     Event:     NONE
     ----
     Function pointer: 16#B6017C18
     Function index:   312
   
   

  Task 3: Modbus,  ID: 7
     Cycle count: 33004
     Cycletime:       2738 microseconds
     Cycletime (min): 246 microseconds
     Cycletime (max): 95608 microseconds
     Cycletime (avg): 2772 microseconds
     Status: RUN
     Mode:   CONTINUE
     ----
     Priority:  1
     Intervall: 10 ms
     Event:     NONE
     ----
     Function pointer: 16#B6021BBC
     Function index:   314
   
   
  Task 4: KBus-Task,  ID: 999
     Cycle count: 0
     Cycletime:       1230 microseconds
     Cycletime (min): 892 microseconds
     Cycletime (max): 1415 microseconds
     Cycletime (avg): - microseconds
     Status: RUN
     Mode:   CONTINUE
     ----
     Priority:  0
     Intervall: 0 ms
     Event:     0000:0000:0000
     ----
     Function pointer: 16#00000000
     Function index:   0
```



  Hier sehe ich auf den ersten Blick auch keine kritische Zeiten. Dennoch scheitert die Kommunikation bereits nach kurzer Zeit.


----------



## Traveler91 (25 Februar 2018)

Ich hoffe es passt hierhin;

Ich habe eine 750 889 und kann via Modbus die Digitalen Ein und Ausgänge lesen.
Allerdings wenn ich eine variable global deklariere zb. Mx0.0 kann ich diese nicht auf adresse 12288 wie in der Anleitung beschrieben auslesen.
Habe ich evt gewisse Einstellungen vergessen?


----------



## ccore (7 März 2018)

Traveler91 schrieb:


> Ich hoffe es passt hierhin;
> 
> Ich habe eine 750 889 und kann via Modbus die Digitalen Ein und Ausgänge lesen.
> Allerdings wenn ich eine variable global deklariere zb. Mx0.0 kann ich diese nicht auf adresse 12288 wie in der Anleitung beschrieben auslesen.
> Habe ich evt gewisse Einstellungen vergessen?



Verbindung geht? Richtiger FC ausgewählt?


----------

