S4c OS3.0 - Kommunikation über RS232 zwischen Visionsystem und IRB

[cyRocks]

Guten Tag.

Ich versuche einen ABB Roboter "IRB 4400, S4C, OS 3.0" mit einem Visionsystem "Matrox Iris Gt1200" über eine serielle Schnittstelle RS232 zu verknüpfen.
Ich habe folgende Probleme:

- Ich empfange keinen String am Roboter. Der String jedoch wird vom Visionsystem aus gesendet, das konnte ich mit dem Hyperterminal am Pc prüfen.
- Gestern hatte ich einen kurzzeitigen Erfolg. Ich habe ca. 4x mal einen String mit 20 Zeichen empfangen können.

Die Verdrahtung dürfte korrekt sein, da ich vom Roboter aus per Write einen String an das Hyperterminal senden kann. Er ist bis jetzt auch immer ohne Fehler angekommen. Ich habe irgendwo im Referenzhandbuch gelesen das der String maximal 80 Zeichen lang sein darf. Jetzt kommt mir die Überlegung, dass vllt. der Puffer meiner Schnittstelle überlaufen bzw. voll sein könnte. Wenn ja wie bekomme ich diesen gelöscht bzw. löscht er sich selbst wenn die Schnittstelle per Close geschlossen wird?. Der Befehl "ClearIOBuff" wird leider noch nicht von dem OS 3.0 unterstützt. Im Anhang sende ich euch noch meinen Quellcode, der so simpel wie möglich gehalten wurde.

Über Ratschläger wäre ich sehr dankbar.

Code:

MODULE Serial

!###################################################
!##      T E S T  P R O G R A M M  F U E R        ##
!##    S E R I E L L E U E B E R T R A G U N G    ##
!###################################################
!---------------------------------------------------------------------
!
PROC Haupt()

SerialTEST;

ENDPROC


PROC SerialTEST ()

VAR iodev com1;
VAR bool bOkx;
VAR bool bOky;
VAR bool bOka;
VAR num noffx:=0;
VAR num noffy:=0;
VAR num noffa:=0;
VAR string stDaten:="00000000000000000000";
VAR string stdatax;
VAR string stdatay;
VAR string stdataa;


Stop;
!Cam bereit?

!Schnittstelle oeffnen und String lesen
!######################################
Open "sio1:", com1\write;
Write com1, "H";
Close com1;

Open "sio1:", com1\read;
Set DO10_14;                            ! Wird benoetigt um den String von der Kamera zu senden
!Write com1, "Abarbeitung gestartet";
stDaten:=ReadStr(com1\Time:=5);         ! 123456A123456B12345C     20 Zeichen
Close com1;
Reset DO10_14;

! String aufteilen
!######################################
stdatax:=StrPart(stDaten,1,6);
stdatay:=StrPart(stDaten,8,6);
stdataa:=StrPart(stDaten,15,5);

! String konvertiern
!######################################
bOkx:=StrToVal(stdatax,noffx);
bOky:=StrToVal(stdatay,noffy);
bOka:=StrToVal(stdataa,noffa);

!Offset ausgeben
!######################################
TPErase;
TPWrite "Offset   X= "\Num:=noffx;
TPWrite "Offset   Y= "\Num:=noffy;
TPWrite "Rotation A= "\Num:=noffa;
TPWrite stDaten;


ENDPROC

ENDMODULE

[Micky]

Hallo,

ich habe bisher die serielle Kommunikation immer nur über einen binär geöffneten Kanal durchgeführt, so dass man sich das Öffnen und Schließen spart, wenn man Schreiben bzw. Lesen will.

Desweiteren solltest Du eine Fehlerbehandlung für die Überschreitung der Wartezeit einfügen,  denn sonst wird der Timeout-Fehler als Systemfehler angezeigt.

Anbei ein kurzes Beispiel für den binären Zugriff, wobei Du die Fehlerbehandlung noch fertig programmieren musst.

Code:

  Open "sio1:", com1\Bin;
  ClearIOBuff com1;                    !Löschen des Eingangspuffers (evtl. gibt es diese Instruktion in Deiner Steuerung noch nicht)
  WriteStrBin com1, "H";

  Set DO10_14;                            ! Wird benoetigt um den String von der Kamera zu senden
  stDaten:=ReadStrBin(com1,20\Time:=5);         ! 123456A123456B12345C     20 Zeichen
  Close com1;
  Reset DO10_14;

ERROR
  IF ERRNO=ERR_DEV_MAXTIME THEN
    !Timeout fehler behandeln
    Reset DO10_14;

     ...
  ENDIF

  IF ERRNO=ERR_FILEACC THEN
   !Zugriffsgehler behandeln
     ...
  ENDIF

ENDPROC

Prinzipiell gibt es bei der seriellen Kommunikation die folgenden möglichen Fehler:

1. Das Kabel ist nicht gekreuzt (Nullmodemkabel)
2. Die Kommunikationsparameter sind an beiden Steuerungen nicht identisch (also Baudrate, Stopbit, Parität, Anzahl der Bits)
3. Es fehlen Steuerzeichen bei der Übertragung der Daten (z.B. "\0D" für Carriage Return)
4. Die Anzahl der zu übertragenden Zeichen stimmt nicht mit der erwarteten Anzahl überein.

Anmerkung:

Die Bezeichnung der Signale (z.B. DO10_14) solltest Du vielleicht nochmal überdenken, den die Verwendung der physikalischen Adresse im Signalnamen bedeutet, dass der gesamte Programmcode angepasst werden muss, wenn das Signal auf eine andere Karte bzw. anderen Kanal gelegt wird. Desweiteren ist für einen Aussenstehenden die Verwendung des Signals nicht klar, hier würde eher eine Signalbezeichnung helfen, die die Funktion des Signals beschreibt.


Gruß

Micky

[cyRocks]

Hallo,
zuerst einmal danke für die Hilfe.

An das binäre öffnen hatte ich auch schon gedacht! Jedoch kennt leider die alte Softwareversion OS3.0 noch kein "ReadStrBin", so dass ich entweder mit "ReadBin" jedes Zeichen bzw. Bit einzeln einlesen oder mit "ReadStr" arbeiten muss. Was dann bei "ReadStr" die folge hat, dass ich die Schnittstelle immer Öffnen und Schließen muss. Wie ich es machen werde weiß ich noch nicht. Auch über das Fehlerhandling habe ich mir noch nicht wirklich viele Gedanken gemacht, da ich wie gesagt ja erstmal etwas empfangen möchte.
 
Letzte Woche habe ich noch ein sehr interessantes Gespräch mit dem ABB Service geführt. Die haben mir nach eifriger Diskussion den Tipp gegeben zwei Brücken am Phönixstecker der SIO 1 zu machen. Erstens bei PIN 2 mit 5 (CTS mit RTS) und zweitens bei PIN 7 mit 8 (DTR mit DSR).

- Ich werde heute im laufe des Tages mal diese Brücken machen, und zudem die Idee mit dem „\0D" Carriage Return versuchen.
- Beim Kabel bin ich mir mittlerweile ziemlich sicher das es nicht die Ursachen sein kann, da ich ohne jegliche Problem vom Roboter aus senden kann.
- Die Schnittstellenparameter stimmen auch überein.
- Das Problem mit der nicht übereinstimmen Zeichenanzahl dürfte ich ja nicht haben, da ja nur bei „ReadStrBin“ die Zeichen angegeben   
  werden müssen.
- Noch kurz zu den Ausgängen. Auch diese werde ich natürlich später richtig benennen. Wie gesagt, es ist noch alles zu Testzwecken aufgebaut.

Nochmals danke für die Hilfe. Bin für jede Antwort dankbar, da ich zurzeit ziemlich Ratlos bin.

Gruß cyRocks

[Micky]

Hallo,

meines Erachtens benötigt die Funktion "ReadStr" ein <LF> als Endekennung für das Einlesen eines Strings.

Probier doch mal ob Du ein LineFeed-Zeichen (<LF>  = 0A h) an Deinen zu sendenden Text anhängen kannst.

Alternativ könntest Du auch mal probieren ob das zeichenweise Einlesen mit "ReadBin" funktioniert, also nur um sicherzustellen ob die Übertragung funktioniert.


Es könnte aber auch sein, dass Deine Baudrate zu hoch eingestellt ist, bzw. dein Kabel zu lang ist. Beim seriellen Übertragen über RS232 beträgt die max. Kabellänge 15m.

Gruß

Micky

[cyRocks]

Hi,

ich glaube ich habs! Will mich aber auch nicht zu früh freuen. Wie gesagt bis jetzt funktioniert es.

Was habe ich gemacht:

- Ich habe die besagten Brücken am Phönixstecker verdrahtet
  Wobei ich sagen muss, dass das alleine nichts bewirkt hat.

- Zudem habe ich, so musste ich feststellen, immer den falschen Steuercode mit gesendet. Ich habe die letzten Wochen immer wieder mit diesen
  Codes herum experimentiert. Da meine Kamera ein "\cr" nicht akzeptierte habe ich es mit dem Hexadezimalwert versucht. Sprich "\0D".
  Da er auch nichts bewirkt hatte probierte ich es mit dem Dezimalwert "\13" ... Naja war auch erfolglos.
  Das Gleiche versuchte ich mit dem "\LF". Ebenfalls erfolglos.
  
  Jetzt kommt der Qlue. Ich habe durch einen doofen Zufall in der Dokumentation meiner Kamera gelesen, dass bestimmte Steuerzeichen mit
  gesendet werden können. "\n" und "\r". Mit "\n" habe ich es ausprobiert und siehe da es funktioniert.

Wer jetzt so wie ich anfangs nichts mit den Steuerzeichen "\n" und "\r" anfangen kann, hier die Aufklärung.

- Es sind Steuercodes aus der Programmiersprache C. Da meine Kamera auf der Programmiersprache C basiert, unterstützt diese dummerweise
  leider nur diese Zeichen

  \n = Zeilenvorschub (LF oder 0x0A als ASCII-Code)
  \r = Wagenrücklauf (CR oder 0x0D als ASCII-Code)

Danke an alle beteiligten und interessierten Mitleser.