Cp340 rcv_status 1e0e ?

[noeppkes]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich habe eine Kommunikation mittels einem CP340 laufen.
Ab und zu bleibt diese hängen.
Als Status bekomme ich vom P_RCV im Status: 1E0E was anscheinend bedeutet:

Statischer Fehler bei Aufruf des SFC RD_REC bzw.
SFB RDREC. Der Returnwert RET_VAL des
SFCs/SFBs wird Ihnen in der Variablen SFCERR
bzw. SFCSTATUS im Instanz-DB zur Auswertung​

zur Verfügung gestellt.

Das sagt mir nun rein gar nichts.
Fakt ist, sobald ich die CPU resette, läuft die Kommunikation wieder einwandfrei.
Daher kann es nicht an meinen Teilnehmern liegen.
Der P_RCV meldet dann auch ERROR zurück.
Kann mir hier jemand weiterhelfen ?

noeppkes ...

 

[noeppkes]

Weitere Info's

Es ist ein Fehler 14 habe ich gerade herausgefunden.
In Handbuch steht:

Ereignisklasse 30 (1EH):​

“Fehler bei Kommunikation zwischen CP und CPU”

Laden Sie die Variable SFCERR bzw.​

SFCSTATUS aus dem Instanz-DB.

Tja schön. Aber wie kann ich den Feher beheben ohne jedesmal die SPU aus- und wieder einschalten zu müssen.

noeppkes ...

 

[noeppkes]

Zuviel Werbung?
-> Hier kostenlos registrieren

SFCERR und SFCSTATUS zeigen Werte an

Hallo,

ich habe nun folgendes aus dem Instanzdatenbaustein DB2 für den CP340 ausgelesen.
Ab und zu ist SRCERR mit -30941 und SFCSTATUS mit 1E0E geladen.
Wie komme ich nun weiter ?

noeppkes ...

 

[Ralle]

Mal zu -30941
Das ist in Hex W#16#8723

Wenn du den SFC RD_REC mal in der System-Library raussuchst und dann F1 drückst, beommst du die Hilfe dazu.

In dieser Hilfe ganz unten stehen die spezifischen Fehlercodes für diesen SFC W#16#80xy, ganz unten dann die allgemeinen Felercodes, die für alle SFC gelten W#16#8xyz

dazu gehört W#16#8723 und wenn man dem Link folgt findet man:

8x23 Bereichslängenfehler beim Lesen eines Parameters.Bereichslängenfehler beim Schreiben eines Parameters.Dieser Fehlercode zeigt an, daß sich der Parameter x vollständig oder teilweise außerhalb des Operandenbereichs befindet oder die Länge eines Bitfeldes bei einem ANY-Parameter nicht durch 8 teilbar ist.

Ich kann jetzt nur vermuten, da ich dein Programm ja nicht kenne. Also mal nachsehen, ob denn immer alle ankommenden Daten auch in den dafür vorgesehenen Bereich passen, bzw. ob dieser Bereich nicht zu kurz gewählt ist, bzw. ob dieser Bereich nicht im Datenbaustein zu kurz angelegt ist.
Kann auch sein, falls du den Bereich der Datenablage und damit den Any selbst berechnest, daß da ein Fehler drinsteckt.

 

[noeppkes]

@Ralle
Hallo Ralle,

schon etwas länger her meine Frgae, aber der Fehler kommt sao selten.
Es ist tatsächlich so dass die ankommenden Daten NICHT in den Datenbaustein passen.
Eigentlich sind es immer 22 Bytes, der Datenbaustein (Receive-Baustein vom RS485-Modul) ist mit 50 Bytes angelegt.
Unter Umständen werden 66 Bytes empfangen, was gleichbedeutend ist mit 3 Telegrammen.
Das habe ich heute morgen herausgefunden.
Reset des P_RCV bringt nichts. (Reset im Aufruf gesetzt).
Ich habe den Dateibaustein nun auf 66 Bytes vergrössert.
somit sollte erst einmal das Problem beseitigt sein.

Und nun meine Frage:
Was aber wenn noch mehr Daten ankommen. Dann kommt doch der Fehler wieder. Wie bekomme ich den Fehler zur Laufzeit weg?

Über eine Antwort würde ich mich sehr freuen.

noeppkes ...

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Eines versteh ich nicht. Normalerweise, muß der CP ja erkennen, wann das Telegramm komplett ist. Also entweder über eine Endekennung oder über einen Zeitverzug zwischen den Zeichen. Dann holt er die Daten ab und fertig. Also erkennt er das Ende des 1. und 2 Telegrammes nicht korrekt oder die Telegramme kommen zu schnell hintereinander. Ich vermute ihr macht das über Zeichenverzugszeit. Optimaler wäre in diesem Falle eine Endekennung. Leider weiß ich auch nicht, wie man einen aufgetretenen Fehler am besten quittiert, hab momentan kein CP und den Fehler so noch nie gehabt. Den DB würde ich aber normalerweise ohnehin größer anlegen.

 

[noeppkes]

@Ralle

Danke Ralle für deine Hilfe.
Da ich ziemlicher Neuling bin, habe ich den CP laut Beispiel programmiert.
Der Aufruf des Receive-CP's lautet:

RCV: CALL "P_RCV" , "DB_P_RCV"
EN_R :="EN_R_R"
R :="RESET_R"
LADDR :="BGADR"
DB_NO :="RCV_DBNR"
DBB_NO:="RCV_DWNR"
NDR :="RCV_NDR"
ERROR :="RCV_ERROR"
LEN :="RCV_LEN"
STATUS:="RCV_STATUS"

wobei hier die Dateibausteinnummer (20), der Start im DB bei 0 übergeben werden.

Ich habe eine Ende-Erkennung ins Telegramm gebastet.

Jetzt stellen sich mir 2 Fragen:
1.) Wo aber kann ich die Ende-Erkennung (mein endezeichen ist LF (0x0a) übergeben.
2.) Wo kann ich die max. Telegrammlänge festetzen (bei mir 22 Zeichen)
Das mit RCV_LEN scheint ja die Rückgabe zu sein.

Die Zeichenverzugszeit lege ich wahrscheinlich in der Hardware-Konfig an.
Und da hast du recht.
Meine Hardware reagiert SEHR SCHNELL auf ein Fragetelegramm und sendet sofort die Antwort raus.
Somit ist es wahrscheinlich Zufall dass das ganze über die Zeichenverzugszeit läuft.

noeppkes ...

 

[Ralle]

Das kannst du in der Hardwarekonfig einstellen. Doppelclick auf die CP340 und dann unten neben der OK-Taste "Parameter". Dann Doppelclick auf Protokoll. Ich glaube das ging allerdings nur, wenn du die zur CP340 gehörende Zusatzsoft für den Step7-Manager installiert hast.

Eine Überlegung wäre auch, ob man nicht immer nur eine Anforderung senden sollte, wenn die vorhergehende Anforderung mit einem Empfangs-Telegramm beantwortet wurde.