750-652: Kommunikationsprobleme der Seriellen Schnittstelle

[Lgls33]

Zuviel Werbung?
-> Hier kostenlos registrieren

Guten Morgen,

ich habe zur Zeit ein Problem mit der Kommunikation bei dem ich selber nicht weiter komme.

Mein Ziel ist es eine Hardware Ansteuerung vom PC auf eine SPS zu switchen.
Ich habe Leistungsansteuerungen für Motoren, die Befehle über einen RS-232 Com Port des PCs erhalten.
Nun habe ich für die Kommunikation das Modul 750-652 gewählt, da die serielle Schnittstelle an der Leistungsansteuerung eine RS422 ist.

Ich habe ein Testprogramm geschrieben in dem ich einen String (Befehl) ':S$R' den die Leistungsansteuerung kennt einmal sende.
Der Satzaufbau muss wie folgt ablaufen, Satzanfang mit ':' und Satzende mit Carriage Return. Das 'S' ist in diesem Fall eine Statusabfrage.
Die Kommunikation findet auch statt und ich erhalte von der Leistungsansteuerung eine Antwort '(E 71) $R$N'.
Dies ist ein Fehler, der lautet: Empfänger überlauf oder Break auf Eingang.

Da ich den Fehler permanent erhalte habe, habe ich die Fehleranalyse von Beginn auf an überprüft.
Ich habe eine Verbindung von dem Modul zum PC über einen Adapter realisiert und habe den String gesendet.
Dieser kommt in RealTerm (Programm zum auslesen des Com Ports und schicken einer Zeichenfolge) wie gewünscht nur einmal an. Die SPS wartet dann in dem State auf eine Antwort. Empfängt das Modul etwas wird dies ausgegeben. Auch dieser String ist in der SPS identisch zu dem gesendeten String aus RealTerm.

Somit würde ich behaupten, dass die Probleme bei der Leistungsansteuerung liegen. Jedoch fehlen mir die Ideen was ich noch überprüfen kann.
Aus der Doku der Leistungsansteuerung kann ich die folgenden Informationen entnehmen.

Datenübertragung erfolgt mit Ascii-Zeichen 7 Bit plus geradem Paritybit und einem Stopbit mit einer Baud einstellbar von 1200..9600.

Die Einstellung ist zur Zeit auf 9600 Baud, sodass ich die Einstellungen auch so vorgenommen habe.

Auf Abschlusswiderstände habe ich verzichtet, da die Leitungslänge nur ca. 4m beträgt.

Hat jemand eine Idee die mich voran bringt?

Vielen Dank im Voraus

Lgls33

 

[LargoD]

Es könnte an der Datenflusssteuerung liegen.
Da gibt es Hardwarelösungen, z. B. CTS/RTS oder DTR/DSR
und Softwarelösungen z. B. X-ON/X-OFF oder ETX/ACK.
Was sagt denn die Doku dazu?

Gruß
Erich

 

[JSEngineering]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kannst Du mal die Einstellungen, die Du über I/O Check am Modul gemacht hast, mal posten?

Setzt Du die Einstellungen im Programm (noch mal)?

Was sagt die Diagnose der Karte?

Hat die Leistungsansteuerung eine Diagnose, die man auslesen kann?

 

[Oberchefe]

Fabrikat und Type vom Gegenstück?

 

[Lgls33]

Guten Morgen,
danke schon einmal für die schnellen Rückmeldungen.
@Oberchefe:
Bei dem Gegenstück handelt es sich um eine Leistungsansteurung von ehem. Berger Lahr heute Schneider Electric.
Die Type ist KIP 530.0301.
@LargoD:
Ich hatte auch schon Kontakt zu Schneider Electric, jedoch ist der technische Support leider schon eingestellt.
Aus der Doku ist leider nicht wirklich viel ersichtlich, worauf ich mein Wissen auf das vorhandene stütze.
In den Dokus die ich von Schneider Electric zur Verfügung bekommen habe, ist ersichtlich, dass vermutlich ein XON/XOFF Handshake benutzt wird.
Leider kann ich das nicht nachvollziehen, da unter VB6 (jetziger Stand) kein Handshake benutzt wird.
Auch beim Test mit Handshake XON/XOFF habe ich den gleichen Fehler gehabt.



Unter VB wird eine Datenflusskontrolle genutzt, jedoch sind die meines Wissens im Stecker gebrückt, sodass diese kein wirklichen Nutzen haben.
Als Gegenüberstellung habe ich einmal die Einstellungen von VB zu e!cockpit.



@JSEngineering:
Diese Aufgabe ist Teil meiner Bachelorarbeit, wodurch ich das erste mal mit Wago und e!cockpit in Berührung komme. Eine Diagnose von der Leistungsansteuerung gibt es wenn über Win Dos. Meinst du mit der Diagnose der Karte einen I/O-Check? Im Programm setze ich die Parameter tatsächlich noch einmal über den FbSerialInterface_cpt. Sind jedoch die gleichen Einstellungen. Sichtbar in der folgenden Grafik.



Stellt das ein Problem dar? Muss ich dort einfach Default eingeben? Ich bin davon ausgegangen, dass meine Einstellung keine Probleme verursachen.

Vielen Dank für weitere Tipps.

Lgls33

 

[JSEngineering]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin,

auf den ersten Blick sieht das erst einmal alles plausibel aus.

Diagnose meine ich: In der Regel gibt es irgendwo Zähler, die man auslesen kann. Die sagen einem z.B. wie viele Zeichen empfangen wurden, wie viele gesendet wurden, wie viele Fehler dabei aufgetreten sind. Sowas. Und da ist die Frage, ob Du zu dem Fehler mehr Infos auslesen kannst. Eventuell hast Du Checksummenfehler. Mal probiert, Endwiderstände einzusetzen?

Das mit dem doppelten Paramater Setzen finde ich suboptimal. Man sollte sich für einen Ort entscheiden. Und da im Handbuch steht, daß man über den Dialog mehr Einstellmöglichkeiten hat als über die Funktion, würde ich es ggf. über den Dialog machen und im Programm nichts mehr überschreiben. Da müßtest Du mal in die Funktionsdoku gucken, ob Du die Parameter einfach weg läßt oder auf einen Default-Wert setzt. Vermutlich einfach weg lassen.

Kannst Du mit Deinem Terminal-Programm die Anfrage manuell fehlerfrei machen?

Ich würde sonst auch mal zum Testen die Geschwindigkeit runter setzen auf 1200. Damit wird die Übertragung deutlich robuster und man weiß, ob das Programm funktioniert oder die Leitung Probleme macht.

Gruß
Jens

 

[Oberchefe]

wurde in Codesys 3 die Syntax geändert?

LENGTH(s_Fahrbefehl)

Ich hätte da LEN(s_Fahrbefehl) erwartet?

 

[Lgls33]

Moin,

@Oberchefe: Die Funktionen sind im Prinzip die gleichen zu benutzen für einen maximalen String(255).
Der Unterschied ist dabei der Rückgabewert. LEN gibt einen Int-Wert zurück und Length gibt einen UDINT zurück.
Für die Funktion FbSerialInterface_cpt benötige ich einen UDINT bei der Länge, weshalb ich mich für Length entschieden habe.

@JSEngineering: Mit Endwiderständen habe ich es schon versucht und bin auf das gleiche Ergebnis gestoßen.
Ich habe mich gestern mit dem Problem weiter auseinander gesetzt. Mich verwundert, dass ich eine Kommunikation zwischen Computer und SPS
aufbauen kann, welche einwandfrei läuft. Sprich ich kann ein String von der SPS zum Computer korrekt senden und vom Computer über das Terminal Programm zur SPS ohne Fehler. Von der SPS zur Leistungsansteuerung bekomme ich immer noch den gleichen Fehler gesendet. Wenn ich nun
den Computer mit dem Terminal Programm an die Leistungsansteuerung anschließe und den vermutlich gleichen String sende ist die richtige Funktion
gegeben und ich bekomme den Code von der Leistungsansteuerung für 'keinen Fehler' zurück gegeben.
Beim senken der Baud auf 1200 kam ein Fehlercode der Paritätsfehler meldet. Dies kann aber eigentlich nicht sein, da ich die richtige Parität gewählt
habe.

 

[JSEngineering]

Zuviel Werbung?
-> Hier kostenlos registrieren

Beim senken der Baud auf 1200 kam ein Fehlercode der Paritätsfehler meldet. Dies kann aber eigentlich nicht sein, da ich die richtige Parität gewählt
habe.

Der Paritätsfehler bedeutet, daß die zur Kontrolle erzeugte Parität nicht mit der übermittelten Parität übereinstimmt: Es ist ein Fehler in der Übertragung aufgetreten. Die Meldung hat erst einmal nichts mit Deinen Einstellungen zu tun, sondern damit, daß die Übertragung nicht fehlerfrei ist. Da hast Du vermutlich auf einer Seite die Geschwindigkeit nicht richtig eingestellt.

Also nochmal zusammengefaßt:

PC <-> SPS = OK
PC <-> LA = OK
SPS <-> LA = NOK

Also funktionieren beide Partner erst einmal.
Ich gehe davon aus, daß Du die Parameter der PC-Schnittstelle nicht zwischendurch änderst.
Nutzt Du das gleiche Kabel für jeden Test oder verschiedene Kabel für die verschiedenen Tests?
Warum schreibst Du "den vermutlich gleichen String sende"? Kannst Du das nicht eindeutig belegen? Dann wäre hier vielleicht mal die Gelegenheit, das zu verifizieren, ob der String von der SPS korrekt gesendet wird.

Was mir noch auffällt: Du sendest $R, die LA sendet aber $R$N zurück! Bitte teste einmal, ob ggf. ein $R$N zu senden Dein Problem behebt. Eventuell macht das Dein Terminalprogramm auch, so daß es da funktioniert.

 

[Oberchefe]

Was mir noch auffällt: Du sendest $R, die LA sendet aber $R$N zurück! Bitte teste einmal, ob ggf. ein $R$N zu senden Dein Problem behebt. Eventuell macht das Dein Terminalprogramm auch, so daß es da funktioniert.

So ganz klar ist mir das auch noch nicht. Im Handbuch steht, dass der Datensatz mit Enter abgeschlossen wird, das Linefeed wird da eigentlich nicht erwähnt. Es steht aber wiederum was drin dass mehrere Anweisungen in einer Zeile übermittelt werden können, das könnte demzufolge schon erfordern, dass nach dem CR noch ein LF benötigt wird.

 

[Lgls33]

Moin,

am gestrigen Tage konnte ich nun endlich den Fehler identifizieren.
Ich habe die Signale mit einem Oszilloskop aufgenommen. Dabei sind mir zunächst keine Fehler aufgefallen, da die gesendeten Signale identisch waren.

Im Endeffekt war das Problem das die LA einen Dauerpegel erwartet. Das bedeutet, dass die SPS erst aktiv sein muss und den Kanal geöffnet werden muss,
bevor die LA eingeschaltet wird. Das ist tatsächlich auch mit einer Ansteuerung über dem PC identisch, jedoch nie aufgefallen.

@Oberchefe: Der String zum Senden wird tatsächlich wie in der Doku beschrieben nur mit einem CR gesendet und zurück wird ein CR LF erhalten.

@JSEngineering: Ich habe tatsächlich zwei verschiedene Kabel benutzt, schon aus dem Grunde, dass ich einen Adapter für USB/COM brauchte.
"Vermutlich" habe ich geschrieben, da es mich dann doch verunsichert hat ob der gleiche String gesendet wird. Durch die Bilder vom Oszi konnte ich dann aber mir sicher sein, dass die Baud richtig war und der Abbild des Signals identisch ist.


Bei einer Aufnahme mit dem Oszilloskop bei dem Handling RS422 über dem Modul 750-652 ist mir aufgefallen das der Pegel im positiven Bereich nicht ganz "sauber" ist. Da ich mit dem Wago Support parallel kommuniziert habe, wurde mir als Tipp mit auf den Weg gegeben, das man die Leitungsendwiderstände am besten immer mit integrieren sollte. (Nicht erst ab 10m wie in der Doku beschrieben) Das verursacht in meinem Fall zwar keine Probleme, da sich meine Pegel nicht im Randgebiet des erlaubten halten, könnte aber anderen später einmal helfen.

Vielen Dank für eure ganze Hilfe, nun kann ich mich der Hauptaufgabe wieder widmen.

Viele Grüße
Lgls33