TIA CM Send_PtP Fehlermeldung RS-232

[joachim93]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

wir würden gerne über ein CM-Modul einen Kühler via RS232 ansteuern.
Wenn wir versuchen eine Anweisung via Send_PtP zu senden wird sowohl die Variable "Error" als auch "Done" kurz auf TRUE gesetzt.
Als Fehlermeldung erscheint in der Variable STATUS dabei ganz kurz '16#7002', sonst gibt die Variable '16#7000' aus.

Laut dem Funktionshandbuch für CM PtP bedeutet '16#7000' Baustein im Leerlauf und '16#7002' Zwischenaufruf, Datenübertragung läuft.
Versteh ich das richtig, dass das bedeutet dass die Anweisung gar nicht gesendet wird?

Bzw. laut Funktionshandbuch sollte ENTWEDER die Variable Done ODER Error auf TRUE gesetzt werden, ich bin verwirrt weil es bei uns beide sind.
An was kann das liegen? Weiß jemand weiter?

(noch zur Info: wir arbeiten mit der CPU 1516-3 PN/DP und dem CM PTP RS-232 BA; unser Kühler hat auch einen RS-232-Anschluss. Das verwendete Kabel von CM zu Kühler ist wie vom Hersteller gefordert ein Nullmodemkabel - also gekreuzt, könnte es am Kabel liegen?)

Danke schonmal!!!

 

[PN/DP]

Wie beobachtest du DONE und ERROR und STATUS? Die Signale liegen meist nur einen Zyklus lang an, das kann man durch beobachten mit PG fast nie sehen.
Hänge mal an DONE und ERROR je einen Zähler und schau, ob der Zählerstand sich ändert. Und wenn ERROR = 1 ist, dann den Wert von STATUS in eine Merk-Variable umkopieren.

PS: welche Artikelnummer genau hat das CM PTP RS-232 BA?

 

[joachim93]

Zuviel Werbung?
-> Hier kostenlos registrieren

Genau so hab ich es auch gemacht - an DONE und ERROR einen Zähler gehängt. Und bei beiden ändert sich der Zählerstand mit Aufruf um eins nach oben.
Den Wert Status versuche ich so abzugreifen:

IF "Send_P2P_DB_2".ERROR THEN
"Cooler_PtP_DB".Status_changed := "Send_P2P_DB_2".STATUS;
END_IF;

Was leider nicht funktioniert - die Variable "Cooler_PtP_DB".Status_changed bleibt immer auf 16#0000
Haben es auch schon mit einer positiven Flanke bei Error probiert, passiert auch nichts.

Dass die Status-Variable kurz auf 16#7002 springt wissen wir, weil wir ein Video gemacht haben ^^
In dem Video sieht man aber nicht, dass DONE und ERROR true sind, deshalb könnte mir auch vorstellen, dass noch ein anderer Fehlercode auftaucht, der so kurz ist dass man ihn selbst auf dem Video nicht sieht.

Was könnte an dem Code oben falsch sein?

 

[joachim93]

Wie beobachtest du DONE und ERROR und STATUS? Die Signale liegen meist nur einen Zyklus lang an, das kann man durch beobachten mit PG fast nie sehen.
Hänge mal an DONE und ERROR je einen Zähler und schau, ob der Zählerstand sich ändert. Und wenn ERROR = 1 ist, dann den Wert von STATUS in eine Merk-Variable umkopieren.

PS: welche Artikelnummer genau hat das CM PTP RS-232 BA

Ganz überlesen: Artikelnummer ist die 6ES7540-1AD00-0AA0

 

[PN/DP]

Der Zählerstand vom ERROR ändert sich, der STATUS-Wert kommt aber nicht in "Cooler_PtP_DB".Status_changed an?
Überschreibst du die Variable noch woanders? Der Code ist erstmal richtig so, wenn "Send_P2P_DB_2" der IDB vom Send_P2P ist.

Würdest du uns noch die genaue Artikelnummer deines Gerätes verraten, damit wir für dich checken können, ob du überhaupt die richtigen Anweisungen verwendest? PS: ahh, OK, hast du gerade angegeben. Die Anweisungen Send_P2P / Receive_P2P sind zu verwenden.

 

[JesperMP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Du kannst ein Trace für die relevante Variabeln erstellen.
Die Trace ist Zyklusgenau. Ist für genau solche Fällen eine guten Tool..

 

[joachim93]

Danke euch! Ich hatte anderswo einen Fehler, es wird jetzt nur noch DONE auf true gesetzt das passt also
Leider macht unser Kühler immer noch nichts, deshalb hab ich jetzt versucht Daten von ihm zu empfangen via Receive_P2P.
Dazu schicke ich schon die jeweilige "Anfrage" via Send_P2P und die Antwort des Kühlers sollte dann in dem Buffer erscheinen die man bei Receive_P2P angibt oder?

Einmal kam auch eine Antwort zurück, jetzt leider wieder nicht mehr und ich weiß nicht woran es liegt.
Der Status von Receive_P2P ist dauerhaft auf 16#7002 - es werden also die ganze Zeit Daten übertragen was mir komisch vorkommt.
Die Variable received_length der Anweisung ist auf 7, ich finde aber nirgendwo was es damit auf sich hat, bzw. nur das hier:



Bedeutet das, die insgesamte Anzahl der erhaltenen Zeichen? Das würde nämlich stimmen...

 

[joachim93]

Noch ein Nachtrag bzw. eine Frage: wir brauchen laut Hersteller ein gekreuztes Kabel (Nullmodem), mit einmal Stecker für den Anschluss an den Kühler und einmal Buchse für unser CM-Modul. Jetzt haben wir leider ein falsches Kabel bestellt, weil die Buchse mit Muttern ist was nicht an unser CM-Modul passt, wir bräuchten eigentlich eine Buchse mit Schrauben.
Als vorübergehende Lösung haben wir jetzt ein nicht-gekreuztes serielles Kabel an das CM-Modul gesteckt und das andere Ende des Kabels mit dem gekreuzten Kabel verbunden, das gekreuzte dann an den Kühler gemacht.
(Ja das ist vermutlich höchst unprofessionell ^^)

Könnte es daran liegen? Dass die Übertragung von einem auf das andere Kabel so gar nicht funktionieren kann und wir stattdessen einen Adapter brauchen?

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

wir brauchen laut Hersteller ein gekreuztes Kabel (Nullmodem), mit einmal Stecker für den Anschluss an den Kühler und einmal Buchse für unser CM-Modul.

Das ist etwas ungewöhnlich, wenn man gekreuztes Kabel braucht. Normalerweise haben gekreuzte Kabel an beiden Enden den gleichen Stecker...

Wenn das Kabel nur RX, TX und GND braucht, dann kann man leicht ausmessen, wie die Drähte angeschlossen werden müssen.
Messe die Spannung vom Pin (2 und 3) jeweils nach Pin 5 (GND bei 9-polig). Wenn die Spannung ca. -3V bis ca. -15V oder +3V bis +15V beträgt, dann ist das der Ausgang TX. Wenn die Spannung bei ca. 0V bis 1V liegt, dann ist das der Eingang RX. RX muß jeweils mit TX der Gegenstelle verbunden werden. Und GND wird mit GND verbunden

Falls auch RTS, CTS, DTR ... gebraucht werden, dann kann man die Belegung auch ausmessen, wenn die Geräte Schnittstellen-Belegungen nach Norm verwenden. Allerdings: ob da noch Brücken im Stecker gebraucht werden, kann man nicht messen, sondern muß man im Zweifelsfall ausprobieren.

Leuchten/flackern denn die TXD-LED und auch die RXD-LED am CM PtP? Leuchten weitere Status-LEDs?

wir bräuchten eigentlich eine Buchse mit Schrauben.
Als vorübergehende Lösung haben wir jetzt ein nicht-gekreuztes serielles Kabel an das CM-Modul gesteckt und das andere Ende des Kabels mit dem gekreuzten Kabel verbunden, das gekreuzte dann an den Kühler gemacht.
(Ja das ist vermutlich höchst unprofessionell ^^)

Das kann man so machen und sieht man auch öfters an Anlagen. Ob das RS232-Kabel aus mehreren Kabeln oder Adaptern zusammengesteckt ist, spielt normalerweise keine Rolle. Es sollte nur nicht insgesamt wesentlich länger als 10m sein. Wenn ich ein RS232-Kabel brauche, was es so nicht günstig zu kaufen gibt, dann konfektioniere/löte ich mir den einen besonderen Stecker selber, mit einem Steckergehäuse meiner Wahl.

 

[joachim93]

Das ist etwas ungewöhnlich, wenn man gekreuztes Kabel braucht. Normalerweise haben gekreuzte Kabel an beiden Enden den gleichen Stecker...

Wenn das Kabel nur RX, TX und GND braucht, dann kann man leicht ausmessen, wie die Drähte angeschlossen werden müssen.
Messe die Spannung vom Pin (2 und 3) jeweils nach Pin 5 (GND bei 9-polig). Wenn die Spannung ca. -3V bis ca. -15V oder +3V bis +15V beträgt, dann ist das der Ausgang TX. Wenn die Spannung bei ca. 0V bis 1V liegt, dann ist das der Eingang RX. RX muß jeweils mit TX der Gegenstelle verbunden werden. Und GND wird mit GND verbunden

Falls auch RTS, CTS, DTR ... gebraucht werden, dann kann man die Belegung auch ausmessen, wenn die Geräte Schnittstellen-Belegungen nach Norm verwenden. Allerdings: ob da noch Brücken im Stecker gebraucht werden, kann man nicht messen, sondern muß man im Zweifelsfall ausprobieren.

Leuchten/flackern denn die TXD-LED und auch die RXD-LED am CM PtP? Leuchten weitere Status-LEDs?


Das kann man so machen und sieht man auch öfters an Anlagen. Ob das RS232-Kabel aus mehreren Kabeln oder Adaptern zusammengesteckt ist, spielt normalerweise keine Rolle. Es sollte nur nicht insgesamt wesentlich länger als 10m sein. Wenn ich ein RS232-Kabel brauche, was es so nicht günstig zu kaufen gibt, dann konfektioniere/löte ich mir den einen besonderen Stecker selber, mit einem Steckergehäuse meiner Wahl.

Danke dir!
Das mit dem Kabel sollte so denk ich dann passen, hier noch die Belegung der Pins aus dem Kühler:


Und aus dem CM-Modul:

Mit dem gekreuzten Kabel gehen wie du schon meintest RX von dem einen mit TX von dem anderen verbunden.

Zwecks der LEDs: Es leuchtet nur die RUN-LED grün (also sie ist ein und blinkt nicht) - das sollte also passen.
Wenn ich den Send_PtP schicke, blinkt kurz die TXD-LED - sollte also auch passen. Die RXD aber leider nie - empfange nach wie vor nichts mehr.

Ich habs jetzt mal noch mit der Anweisung Receive_Reset probiert, für den Fall dass es an einem vollen Buffer liegen sollte - ist scheinbar auch nicht der Fall...

Mit der Anweisung Signal_Get erhalte ich folgendes Ergebnis:



Mit der Anweisung Get_Features das hier:


Die Fehlermeldungen bedeuten "Baustein im Leerlauf".
Langsam bin ich mit meinem Latein am Ende^^
Weiß jemand weiter?

Danke!!

 

[PN/DP]

Wenn ich den Send_PtP schicke, blinkt kurz die TXD-LED - sollte also auch passen. Die RXD aber leider nie - empfange nach wie vor nichts mehr.

Wenn die RXD-LED nie flackert, dann antwortet der Partner nicht (schon mal mitgesniffert?) oder es ist ein elektrisches Problem (RXD oder TXD falsch oder gar nicht verbunden, GND fehlt, zu niedriger Pegel, Kabel zu lang?).

 

[Oberchefe]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ist das Kabel ein vollbelegtes (also mit Pin 7/8)?

Muss an dem Gerät etwas parametriert werden damit die Buchse auch auf RS232 reagiert? Möglichwerweise erwartet das Gerät sonst RS485!

 

[joachim93]

Wenn die RXD-LED nie flackert, dann antwortet der Partner nicht (schon mal mitgesniffert?) oder es ist ein elektrisches Problem (RXD oder TXD falsch oder gar nicht verbunden, GND fehlt, zu niedriger Pegel, Kabel zu lang?).

Nein ich hab noch nie mitgesniffert Ich konnte das Problem mittlerweile zum Glück lösen - es lag tatsächlich daran, dass etwas am Gerät nicht richtig eingestellt war. Es war zwar auf RS232 und Remote, es gab aber noch eine andere Einstellung die noch nicht richtig war..

Danke euch trotzdem!!! Ich war überzeugt es muss an dem Kabel liegen ^^