TIA LED CB1241

L

Lea_6343

Level-1
Beiträge
16
Reaktionspunkte
0
Hallo zusammen

Sorry für die doofe frage. Aber ich komm im Moment absolut nicht weiter. Ich habe eine S7 1215C mit einem CB1241 zur Kommunikation über RS485. Vor etwa zwei Wochen habe ich über dieses Modul Motorentreiber angesteuert. In der Zwischenzeit habe ich am weiteren Programmablauf gearbeitet und der Implementation von anderen Aktoren über I/O und nicht RS485. Als ich die Treiber Ansteuerung nun in meinen Ablauf implementieren wollte ging nichts mehr. Zudem ist mir aufgefallen, dass die Kommunikation LED des CB 1241 nicht mehr leuchten. Was ist die genaue Voraussetzung, dass diese LED's leuchten? Sicher mal eine korrekte Hw-Konfiguration und was sonst noch alles?
 
Aus dem Systemhandbuch S7-1200 (2019):
13.1 Mit den seriellen Kommunikationsschnittstellen arbeiten
LED-Anzeigen
...
● Sende-LED (Tx): Die Sende-LED leuchtet, wenn Daten über den Kommunikationsport gesendet werden.
● Empfangs-LED (Rx): Diese LED leuchtet, wenn Daten über den Kommunikationsport empfangen werden.
Zum Vergrößern anklicken....
Beobachte in Deinem Programm beim Aufruf der Sende-Anweisung, ob die überhaupt aufgerufen wird und Sendeaufträge ausgelöst werden und ob die Anweisung einen ERROR-STATUS liefert.
Gibt es vielleicht Einträge im CPU-Diagnosepuffer bezüglich des CB 1241? Leuchten rote LEDs?
Wenn Du die SPS komplett ausschaltest (stromlos machen) und wieder einschaltest, leuchten die Tx und Rx LED kurz?

Hast Du bei der letzten Programmierung Variablen (z.B. Merker) benutzt, die Du auch schon bei der RS485-Programmierung benutzt hast oder hast Du Adress-Überlappungen?

Harald
 
Ich hab den Baustein nochmals im Run beobachtet. Heute morgen hatte es keinen einzigen Fehler nur den Status 7000. Jetzt aber wird mir am MB_Master ein Fehler mit dem Status 16#8180 also "Ungültiger Wert für die Port-ID" angezeigt. Versteh ich das richtig das er meint mit dem Eingang "Port" am Baustein MB_COMM_LOAD stimmt etwas nicht? Der Baustein sieht so aus:
1666783801615.png
Ich weiss ehrlich gesagt nicht was ich da anders machen muss. Weisst du da mehr?
 
Um zu erkennen ob es mit das Anwenderprogramm zu tun hat, kannst du zurück zu die vorige Programmstand gehen und ein erneute Test machen ?

Es fällt mir ins Auge das REQ mit FirstScan gesteuert wird. Dass kan ja nicht rihtig sein, oder ? War das auch so in die vorige (und funktionierende) Programmstand ?
 
JesperMP schrieb:
Es fällt mir ins Auge das REQ mit FirstScan gesteuert wird. Dass kan ja nicht rihtig sein, oder
Zum Vergrößern anklicken....
REQ braucht nur einen Pos_Trigger und wird einmalig abgearbeitet. Danach muss man nur noch mal REQ triggern wenn Parameter der Kommunikation sich geändert haben oder um zurückzusetzen, z.B. bei einem Fehler.
 
Die Ausgänge DONE und ERROR bleiben nur einen Zyklus lang aktiv oder? Ich finde das irgendwie nicht beim MB_COMM_LOAD.
Nicht das der MB_Master nur meckert weil der MB_COMM_LOAD nicht ausgeführt wurde.
Ich kann mir gerade kaum vorstellen das MB_MASTER den Port anmeckert den der MB_COMM_LOAD als gültig durchgewunken hat.

Vielleicht zusätzlich zum FirstScan einmal einen Merker zum retriggern versuchen?
 
Lea_6343 schrieb:
Ich hab den Baustein nochmals im Run beobachtet. Heute morgen hatte es keinen einzigen Fehler nur den Status 7000. Jetzt aber wird mir am MB_Master ein Fehler mit dem Status 16#8180 also "Ungültiger Wert für die Port-ID" angezeigt. Versteh ich das richtig das er meint mit dem Eingang "Port" am Baustein MB_COMM_LOAD stimmt etwas nicht?
Zum Vergrößern anklicken....
Nein eher nicht. Zeige mal ein Bild vom MB_MASTER. Hat Dein MB_MASTER den Instanz-DB DB4?

JesperMP schrieb:
Es fällt mir ins Auge das REQ mit FirstScan gesteuert wird. Dass kan ja nicht rihtig sein, oder ?
Zum Vergrößern anklicken....
Doch, das ist ja nicht die Sendeanweisung MB_MASTER, sondern MB_COMM_LOAD, die nur die Schnittstelle konfiguriert (Baudrate und so). Das wird auch im TIA Programmbeispiel mit FirstScan gesteuert.

Harald
 
JesperMP schrieb:
Und zwischen die zwei Zeitpunkte wurde das Programm oder die HW Konfiguration nicht geändert ?
Zum Vergrößern anklicken....
Der gesamte Teil der RS485 Kommunikation mit dem CB 1241 und die komplette Hw-Konfiguration waren gleich bei den ersten Test gestern. Mittlerweile habe ich aber die ganze Hw-Konfiguration gelöscht und einzeln neu aufgebaut und geladen. Die FBs zu der ganzen Ansteuerung habe ich zwischendurch auch entfernt und anschließend wieder eingefügt.
 
escride1 schrieb:
Die Ausgänge DONE und ERROR bleiben nur einen Zyklus lang aktiv oder? Ich finde das irgendwie nicht beim MB_COMM_LOAD.
Nicht das der MB_Master nur meckert weil der MB_COMM_LOAD nicht ausgeführt wurde.
Ich kann mir gerade kaum vorstellen das MB_MASTER den Port anmeckert den der MB_COMM_LOAD als gültig durchgewunken hat.

Vielleicht zusätzlich zum FirstScan einmal einen Merker zum retriggern versuchen?
Zum Vergrößern anklicken....
Das hat mir im Bezug auf den Fehler am MB-Master geholfen da ist jetzt keiner mehr. Vielen Dank.

Leider funktioniert aber die Kommunikation im gesamten immer noch nicht.
PN/DP schrieb:
Nein eher nicht. Zeige mal ein Bild vom MB_MASTER. Hat Dein MB_MASTER den Instanz-DB DB4?


Doch, das ist ja nicht die Sendeanweisung MB_MASTER, sondern MB_COMM_LOAD, die nur die Schnittstelle konfiguriert (Baudrate und so). Das wird auch im TIA Programmbeispiel mit FirstScan gesteuert.

Harald
Zum Vergrößern anklicken....
Ja alle meine MB_Master haben den DB4 als Instanz DB
1666789588052.png
Mittlerweile zeigt er aber keinen Fehler mehr an wegen dem Tipp mit dem Merker zum retriggern.

PN/DP schrieb:
Die Hardware wurde auch komplett übersetzt und in die CPU geladen? Und die Software auch?
Zum Vergrößern anklicken....
Ja ich wüsste nicht was ich da falsch gemacht haben könnte. Habe auch immer wieder zwischendurch den MRES verwendet um alles aus der CPU zu löschen.
 
Bin nicht sicher, aber ich glaube dass die HW_IO adressen sind Teil von die Bausteinkonsiztenzprüfung.
Wenn die HW_IO geändert wird, löst es eventuell aus dass die Konstantenwert geändert wird, und damit wird die Baustein geändert, and alles was geändert geworden sind muss in die CPU geladen werden.
Sollte nicht schief gehen können.

Du kannst nicht zürück zu eine alte fungierende Programmstand gehen ?
 
Lea_6343 schrieb:
Ja alle meine MB_Master haben den DB4 als Instanz DB
Anhang anzeigen 64529
Zum Vergrößern anklicken....
Hast Du mehrere MB_MASTER-Aufrufe im Programm? Wie sind die gegeneinander verriegelt (mit EN)? Sind da vielleicht an mehreren Aufrufen gleichzeitig EN und REQ aktiv? Wenn mehrere MB_MASTER-Aufrufe gleichzeitig EN aktiv haben, dann müsste ja die Instanz (DB4) mehrmals im Zyklus TRUE und FALSE sehen ... :unsure: Ich habe keine Erfahrung mit dem MB_MASTER, die TIA-Beschreibung dazu liest sich aber etwas gruselig ;) was die interne State-Machine betrifft, wenn alle MB_MASTER mit dem selben Instanz-DB arbeiten. Ob das wirklich richtig funktioniert wenn mehrere Aufrufe gleichzeitig enabled sind ??

Ich würde gefühlsmäßig lieber mit nur einer MB_MASTER-Instanz mit nur einem Aufruf arbeiten, und je nachdem was gesendet werden soll, die Auftrags/Eingangsparameter (DATA_ADDR, MODE, ...) umschalten/umladen. Weil das etwas aufwendig ist, hat Siemens vielleicht die Idee implementiert, daß die Aufrufe mit der selben Instanz das selber auseinander klamüstern? :unsure:

Kannst Du testweise nur einen einzigen MB_MASTER-Aufruf mit EN = TRUE beschalten und alle anderen Aufrufe mit EN = FALSE?

Harald
 
Verkehrt ist es nicht mit den gleichen IDBs, sogar richtig.
Nur nach Screenshot würde es nicht funktionieren da der EN nicht verriegelt ist.
Irgendwo hat Siemens da auch ein Beispielprogramm für hinterlegt, glaube aber da steht das nicht so eindeutig drin sondern ist nur verriegelt ohne das gezeigt wird wie verfahren werden sollte.
 
escride1 schrieb:
In einem Projekt haben mehrere FBs den gleichen IDB? Das wäre nicht so hilfreich.
Zum Vergrößern anklicken....
Ja ich habe ein Testprogramm des Treiber Herstellers übernommen. Da wird das ganze so gelöst. So wie ich das aber sehe sind die Bausteine gegen einen gleichzeitigen Aufruf abgesichert (Über "REQ"). Vor zwei Wochen war es schon das selbe Programm und da hat es funktioniert.

JesperMP schrieb:
Bin nicht sicher, aber ich glaube dass die HW_IO adressen sind Teil von die Bausteinkonsiztenzprüfung.
Wenn die HW_IO geändert wird, löst es eventuell aus dass die Konstantenwert geändert wird, und damit wird die Baustein geändert, and alles was geändert geworden sind muss in die CPU geladen werden.
Sollte nicht schief gehen können.

Du kannst nicht zürück zu eine alte fungierende Programmstand gehen ?
Zum Vergrößern anklicken....
Nein leider kann ich nicht mehr zurück. ich habe nicht mit solchen Schwierigkeiten gerechnet.

PN/DP schrieb:
Hast Du mehrere MB_MASTER-Aufrufe im Programm? Wie sind die gegeneinander verriegelt (mit EN)? Sind da vielleicht an mehreren Aufrufen gleichzeitig EN und REQ aktiv? Wenn mehrere MB_MASTER-Aufrufe gleichzeitig EN aktiv haben, dann müsste ja die Instanz (DB4) mehrmals im Zyklus TRUE und FALSE sehen ... :unsure: Ich habe keine Erfahrung mit dem MB_MASTER, die TIA-Beschreibung dazu liest sich aber etwas gruselig ;) was die interne State-Machine betrifft, wenn alle MB_MASTER mit dem selben Instanz-DB arbeiten. Ob das wirklich richtig funktioniert wenn mehrere Aufrufe gleichzeitig enabled sind ??

Ich würde gefühlsmäßig lieber mit nur einer MB_MASTER-Instanz mit nur einem Aufruf arbeiten, und je nachdem was gesendet werden soll, die Auftrags/Eingangsparameter (DATA_ADDR, MODE, ...) umschalten/umladen. Weil das etwas aufwendig ist, hat Siemens vielleicht die Idee implementiert, daß die Aufrufe mit der selben Instanz das selber auseinander klamüstern? :unsure:

Kannst Du testweise nur einen einzigen MB_MASTER-Aufruf mit EN = TRUE beschalten und alle anderen Aufrufe mit EN = FALSE?

Harald
Zum Vergrößern anklicken....
Das Aktuelle Programm welches ich habe wird vom Treiber Hersteller zur Verfügung gestellt um seine Treiber mit einer S7 1200 anzusteuern. Dies hat vor zwei Wochen auch noch super funktioniert. Aber klar ich probiere das mal.


escride1 schrieb:
Verkehrt ist es nicht mit den gleichen IDBs, sogar richtig.
Nur nach Screenshot würde es nicht funktionieren da der EN nicht verriegelt ist.
Irgendwo hat Siemens da auch ein Beispielprogramm für hinterlegt, glaube aber da steht das nicht so eindeutig drin sondern ist nur verriegelt ohne das gezeigt wird wie verfahren werden sollte.
Zum Vergrößern anklicken....
Ja die Bausteine haben alle nichts am Enable aber sie sollten aufgrund der REQ Bedienung nie gleichzeitig Aufgerufen werden.

Das ihr wisst wie das ganze Programm aussieht hänge ich euch noch die Anleitung des Treiberherstellers an.
 

Anhänge

JesperMP schrieb:
Du kannst nicht zürück zu eine alte fungierende Programmstand gehen ?
Zum Vergrößern anklicken....
Lea_6343 schrieb:
Nein leider kann ich nicht mehr zurück. ich habe nicht mit solchen Schwierigkeiten gerechnet.
Zum Vergrößern anklicken....
Schade. Das wäre mein Vinkel um das Problem anzugreifen wenn man die Ursache nicht schnell erkennen kann.
Man wöhnt sich an häufig dass Programm unter neue versionsnummern zu speichern. Z.B wenn etwas erfolgreich getestet ist und man fängt an mit einen neuen 'Kapitel'.
 
Wenn man nach der Anleitung geht ist am MB_COMM_LOAD am EN auch der FirstScan angeschrieben worden. Im Screenshot von Dir nicht. Schafft das Abhilfe?

Am MB_MASTER kenne ich nur das EN und REQ verarbeitet werden. EN bis Done kommt und REQ zum Anstossen. Ob es mit dauerhaft EN=TRUE funktioniert vermag ich nicht zu sagen.
 

Similar threads

P
Step 7 DALI-LED Sporadisch eingeschalten
Antworten
3
Aufrufe
326
Blockmove
B
S
Step 7 Modbus RTU - Comm_LOAD Fehler 81AA - falsche Betriebsart
Antworten
17
Aufrufe
870
SNCS_MarkusKarl
S
P
TIA DALI LED-Steuerung
Antworten
1
Aufrufe
517
hobby
H
K
Step 5 Simatic S5 115U CPU 942B in unserer Kirche macht Probleme
2
Antworten
34
Aufrufe
6K
rlw
R
A
TIA Profienergy I-Device Implementierung
Antworten
0
Aufrufe
228
arnevoelker
A
Zurück
Oben