Step 7 Problem mit CP340: kann nicht senden

Wurst.feat.Senf

Level-1
Beiträge
9
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo liebe Community,
Ich besuche dieses Forum schon seit einiger Zeit ohne Account um Hilfe bei S7 Problemen zu erhalten und wurde bisher nie enttäuscht, dafür erstmal ein großes Dankeschön.
Für meine jetzige Arbeit komme ich allerdings mit den Beiträgen, die hier bereits vorhanden sind leider nicht weiter.
Folgendes Problem liegt vor:
Ich habe eine S7-300 und benutze als Software WinSPS-S7 V6. Ich möchte über eine CP340 mittels RS232 einen Hex-Befehl an einen Schrittmotor senden. Da das mitgelieferte Softwarepaket für die CP340 nur mittels Step 7 installiert werden konnte, habe ich mir über MHJ die nötigen Funktionsbausteine für den CP340 zukommen lassen. Die CP340 ist über die Hardware-CFG von WinSPS Projektiert.
Ich habe den P_Send Baustein (Bei mir FB3) in den OB1 eingefügt und folgendermaßen Parametriert:
IN:
REQ: E124.0
R: E124.1
LADDR: 272
DB_NO: 10
DBB_NO: 0
LEN: 9

OUT:
DONE: M1.0
ERROR: M1.1
STATUS: MW10

Als Instanz-DB für den FB3 habe ich den DB3 neu angelegt, dieser wird ordnungsgemäß vom FB3 verwendet und schreibt Daten hinein. Laut Hardware-CFG ist die E/A-Adresse des CP340 272-287, diesen habe ich auch über den SFC5(GADR_LGC) überprüft (Bei einer anderen LADDR kommt ein "SF-Fehler" an der SPS). Ich habe einen DB10 erstellt aus dem ich einfach ein WORD senden will.

Wenn ich über REQ das Senden anstoße kommt eine positive ERROR Flanke, wenn ich R anstoße kommt eine positive DONE-Flanke. Bei der ERROR-Flanke wird in den STATUS der Fehler W#16#1E0F geschrieben. Laut Handbuch ist dies ein Fehler der Ereignisklasse 30: "Fehler bei der Kommunikation zwischen CP und CPU" :

"Statischer Fehler bei Aufruf des SFC WR_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."

SFC WR_REC ist der SFB53 in meiner Software
Diesen habe ich parametriert und seinen STATUS ebenfalls ausgelesen. Im Idle-Zustand wird Fehler 16#7000 ausgegeben, was nur bedeutet REQ=0 und BUSY=0. Wenn ich REQ=1 ansteuere kommt der Fehler 80C1:
"Die Daten des auf der Baugruppe vorangegangenen
Schreibauftrags für denselben Datensatz sind von der
Baugruppe noch nicht verarbeitet."

BUSY ist dann dauerhaft auf 1 geschaltet und es passiert nichts weiter. An der CP340 leuchtet auch keine TXD-Lampe. Hat jemand eine Vermutung woran es hängt? Ich habe das Gefühl es sind nur 1-2 präzise Handgriffe nötig damit es klappt aber habe schon alles probiert was mir einfällt und mir läuft die Zeit davon.

Mit freundlichen Grüßen
Andre
 
Hallo,
ich kenne mich zwar mit diesem WinSPS überhaupt nicht aus, in Step7 benötigt man aber für dein Vorhaben lediglich den P_Send FB. Dieser nutzt intern die WRREC und RDREC Bausteine. Meine Vermutung wäre jetzt, dass durch den separaten Aufruf von WR_REC die Kommunikation zwischen dem P_Send FB und dem CP gestört wird.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie hast du denn ohne das Softwarepaket für den CP diesen parametriert, also bezüglich Baudrate, Start/Stoppbits etc.? Oder ist das in deiner Konfigurationssoftware alles vorhanden?

Hast du noch andere Kommunikationsprozessoren im Rack? Der CP340 kann nicht hinter einem anderen CP betrieben werden (CP343-5, CP343-1) evtl. fängt deine Software das nicht ab.
 
Danke für eure Antworten

@312C

Den Baustein WR_REC habe ich ebenfalls im OB1 in einem Netzwerk, da ich gesehen habe, dass der Instanz-DB von P_Send auf diesen zugreifen will. Ich habe diesen jetzt aber manuell parametriert, teilweise habe ich an die Eingänge Daten des Instanz-DBs gelegt. Ist es ausreichend, wenn der WR_REC lediglich im Projekt und in die SPS geladen wird?


@Thomas_v2.1

Den Cp konnte ich ohne Softwarepaket ins Rack einfügen, auch mit Baudrate, Anzahl der Bits, Übertragungsprotokoll, usw. Dies lief meiner Ansicht nach auch erfolgreich, da weder an der SPS noch an der CP die SF-Led leuchtete. Ich habe nur diese eine CP im System und will auch nur an einen einzigen Teilnehmer senden/empfangen.
Lediglich die Programmbausteine zum Senden und Empfangen und was noch dazugehört musste ich mir erst besorgen und ins Projekt importieren.
 
UPDATE:
Wenn ich den Instanz-DB von P_SEND beobachte kann ich die Variablen beobachten, welche an WRREC adressiert sind. Mögliches Problem, welches ich hierbei sehe ist, dass die Variable WRREC_1.REQ immer FALSE ist und der SFB dadurch gar nicht anfängt zu arbeiten. Ich habe jetzt mal den REQ manuell auf TRUE geschaltet und die Eingänge alle manuell mit den zugehörigen WRREC-Werten aus dem Instanz DB von P_SEND verknüpft und etwas erreicht: Wenn ich das Senden über P_Send anstoße blinkt die TxD Lampe am CP340 ein paar mal kurz. Also ein erstes Lebenszeichen. Der ERROR Ausgang von SFB53(WRREC) ist aber permanent TRUE und im Instanz-DB steht der Fehlercode 80C1

"Die Daten des auf der Baugruppe vorangegangenen
Schreibauftrags für denselben Datensatz sind von der
Baugruppe noch nicht verarbeitet."
 
@Micha51

Ich habe mich daran orientiert, was im Eingang des Bausteins für ein Datentyp gefragt war, das was du sagst geht auch, in den Werten im Instanz-DB steht in beiden Fällen dasselbe. Habe es mittlerweile etwas weiter eingrenzen können: im Instanz-DB des WRREC steht in der Variable RECORD im Beobachtungsmodus ein "?".

Dabei ist es egal, ob ich auf den Eingang des RECORD den Verweis aus dem Instanz-DB wähle, oder manuell den pointer direkt in meinen Sende-DB zeigen lasse.

Im Fehlercode steht dabei "8922" (DW#16'C0892200), dieser Fehlercode ist aber nicht aufgelistet in der Dokumentation.
 
Danke für eure Antworten

@312C

Den Baustein WR_REC habe ich ebenfalls im OB1 in einem Netzwerk, da ich gesehen habe, dass der Instanz-DB von P_Send auf diesen zugreifen will. Ich habe diesen jetzt aber manuell parametriert, teilweise habe ich an die Eingänge Daten des Instanz-DBs gelegt. Ist es ausreichend, wenn der WR_REC lediglich im Projekt und in die SPS geladen wird?
Letzteres ist meiner Meinung nach der Fall. Der Baustein muss nicht separat aufgerufen werden, wenn dieser innerhalb von P_Send aufgerufen wird, läd TIA den Baustein automatisch herunter. (wird das WinSPS auch tun, sonst würde die CPU sich über den nicht vorhandenen aber aufgerufenen Baustein beschweren) Vermutlich kommt der 80C1 Fehler auch davon, dass durch den separaten Aufruf zweimal gleichzeitig ein Datensatz an den CP gesendet wird.

Nur um gefragt zu haben. R ist schon false während ein Sendeauftrag angestoßen wird ? EN ist true ?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@312C

Ich werde es morgen mal ausprobieren und den WRREC aus dem Netzwerk nehmen. Beim P_SEND ist R nicht TRUE, EN habe ich nicht belegt, der Baustein wird doch über REQ gestartet? Zumindest gibt er STATUS Meldungen heraus. Wenn ich R=TRUE betätige kommt sogar eine positive DONE Flanke.
 
@312C

Wenn ich bei P_SEND den EN positiv belege und dann über REQ einen Sendeanstoß gebe geht die CPU in den Stopp Zustand, und die SF-Leuchte geht an.
In der Diagnose steht:
-STOP durch nicht geladenen Peripheriezugriffsfehler-OB
-Peripherie-Zugriffsfehler, lesend OB 122
Habe es mit und ohne den WRREC Baustein im Netzwerk versucht.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
UPDATE:

Ich habe es geschafft ein Datenpaket an den Motor zu senden, und es wurde auch korrekt ausgewertet, sprich der Motor dreht sich. Es hat sich herausgestellt dass es an mehreren Baustellen etwas zu tun gab:
1. Wie @312C richtig hingewiesen hat muss EN bei P_SEND TRUE sein, sonst gibt es den Fehler, dass die Kommunikation zwischen CPU und CP fehlerhaft ist (1E0F)
2. Der WRREC darf nicht im Netzwerk sein, sonst gibt es einen doppelten Aufruf und er sendet zu oft hintereinander (80C1)
3. Es gab ein Problem mit dem Sende-DB: Ich habe dort Daten in einem STRUCT abgelegt, in welchem BYTE-WERTE standen. Der Name des STRUCT hatte ein Leerzeichen und die Adressierung konnte vom Programm nicht ausgelesen werden, daher waren alle Aktualparameter im DB immer B#16#00. Das ist mir erst später aufgefallen, da es beim Kompilieren des Programmes keine Fehlermeldung diesbezüglich gab.
 
Zurück
Oben