Daten lesen von RS232-Sensor an Konsolen-Port P2:

Hallo, Spezialisten,

wir wollen einen Sensor mit RS232-Schnittstelle am Konsolen-Port auslesen. Getriggert wird er mit einem Hardware-Signal. Das funktioniert. Die Daten kommen bei meinem Programm nur teilweise oder auch gar nicht an. Der Sensor wurde bisher über eine Umsetzung RS232 -> DeviceNet betrieben (früheres Thema KL6031), daher wissen wir, dass der Sensor auswertbare Daten sendet. Die Umsetzung dauert für schnelle Messanwendungen aber zu lange, deshalb wollen wir es direkt mit der RS232-Schnittstelle versuchen.

An die Schnittstelle am Schaltschrank (DSub 25 polig) werden vom Sensor mit 9600 Baud 15 byte gesendet (das Geschehen wurde mit Schnittstellentester und Oszilloskop geprüft). Am DSub-Stecker, der von außen aufgesteckt wurde, wurde Pin 4 mit 5 und Pin 6 mit 20 gebrückt gemäß Handbuch 82595.

P2: soll konfiguriert werden:
1. Beabsichtigt ist, für P2: X on/off zu deaktivieren mit
stat=SET_PORT_ATR(port_?,atr_xonoff,xf_not_used)
Da die Ports standardmäßig mit XONOFF arbeiten, muss man es deaktivieren. Ich habe versucht, den richtigen Port zu finden, indem ich nachfolgende Abfrage verwendet habe:

atr_value=-1
stat=GET_PORT_ATR(port_2,atr_baud,atr_value)
-- atr_value bleibt -1, egal, ob statt port_2 port_1 oder port_3 angegeben ist
In der Karel-Doku auf S. 138 findet sich

The following STRING values can be used to associate file variables with serial communication
ports on the KAREL controller. Defaults for are:
— ’P2:’ - Debug console connector on the outside of the operator panel

Auf S. 139 kommt
--literal communication port
OPEN FILE file_var4 (’RW’, ’P2:’)

d.h, man kann diesen Port benutzen.

Jetzt fehlt f. das Setzen und Abfragen der Port-Attribute die Zuordnung der phys. Ports zu den vordefinierten Konstanten port_1, port_3, port_4 und port_5. Zufällig habe ich entdeckt, dass der Floppy port_2 zugeordnet ist (s. S. 365). Zu den anderen Konstanten gibt es keine Angaben.
stat=SET_PORT_ATR (port_2, ATR_READAHD, 1) -- sets FLPY: to have a read
-- ahead buffer of 128 bytes.

Weiß jemand, welche Konstante (port_1, port_3, port_4 und port_5) dem phys. Port P2: zugeordnet ist?

Gruß

PA

Das Problem hat sich erledigt. Den benutzten Port unter MENU > SETUP > PortInit auf [no use ] setzen, dann spielt XONOFF etc. keine Rolle.

GET_PORT_ATR funktioniert wahrscheinlich nicht (Auskunft von Fanuc-Mitarbeiter war, dass nicht alle Funktionen wirklich gehen, deshalb darf man wohl davon ausgehen, dass diese Funktion auch nicht geht). Die angefragten Konstanten kann man offenbar getrost vergessen.

Jetzt funzt das Auslesen des Sensors, schade ist nur, dass mehr als 9600 Baud nicht möglich sind.

Gruß

PA

Der Port kann sogar 38400. Das Gespräch gestern mit FANUC und die Konsante BAUD_9600 ließ vermuten, dass da nicht mehr ist. Die Baudratenerhöhung scheint aber nix zu bringen. Wir müssen in schneller Folge Messungen machen, deshalb öffne ich den Port 1 Mal zu Beginn der Mess-Schleife, in jedem Schleifendurchlauf wird dann CLR_IO_STAT (file) gemacht, dann gelesen.

Unter Verwendung von $fast_clock (incrementiert inzwischen alle 2 ms um 1) habe ich f. 15 byte zwischen 40 u. 48 ms bei 9600 baud , der Maximalwert ist auch bei 38400 Baud nicht kleiner. Es wurden je 3 Zyklen mit jeweils 20 Messungen gemacht, also 60 Messungen mit 9600 Baud, dann 60 Messungen mit 38400 Baud.. Der Sensor schreibt Daten, wenn er hardwaremäßig getriggert wird. Nach Messung, also vor Rückkehr an den Schleifenanfang, habe ich den nächsten Triggerpuls f. die Folgemessung und damit die nötige Pause (da PULSE ohne nowait), um die Messungen durchzukriegen. Ohne Pause verharrt das System nach wenigen Messungen in READ ... und macht nicht mehr weiter. Bei diesen Tests lief kein weiteres Programm.

Bei XML-Kommunikation ist das übrigens genauso, ohne einige Delays läuft eine XML-Kommunikation nicht zuverlässig.

Gruß

PA