Architektur

Bei einer konventionellen seriellen Schnittstelle spricht der Treiber über einen internen Hardwarebus direkt mit dem Chip (UART). Der TwinCAT Virtual Serial COM Treiber dagegen nutzt ADS und das EtherCAT Protokoll für diese Kommunikation.

 

Architektur 1:

 

Der Treiber instanziert auf dem Rechner, auf dem er installiert wurde, einen ADS Server mit fester Portnummer, der im folgenden TcEL60xx-AdsServer genannt wird. Über diesen ADS Server können COM Schnittstellen erzeugt werden. Der Client des TcEL60xx-AdsServers ist das EtherCAT Slave Objekt, welches im TcIo Treiber liegt. Für jede EtherCAT Busklemme wird ein solches Objekt erzeugt. Damit eine Klemme als COM Schnittstelle des Betriebssystems verwendet werden kann, gibt es für die EL60xx Klemmen eine spezielle Klasse von EtherCAT Slave Objekten. Diese können per ADS Daten zum Verschicken empfangen, die dann an die zugeordnete Klemme weitergereicht werden und sie können Daten, die von den Klemmen kommen, über ADS an den TcEL60xx-AdsServer weiterschicken. Dieser gibt die Daten dann ggf. an eine Applikation weiter, die gerade die COM Schnittstelle geöffnet hat.

Die folgende Abbildung illustriert die Architektur der XP Variante des EL60xx Treibers.

Architektur 2:

 

Hinweis
Datenverlust

Wenn eine EL60xx Busklemme und ein virtueller COM-Port in der SPS verwendet wird, dann muss der Zugang zur Klemme über einen übergeordneten Kontrollmechanismus realisiert werden

Nach dem Öffnen des jeweiligen virtuellen COM-Ports, werden die Zugriffe durch die SPS blockiert, solange der virtuelle COM-Port geöffnet ist. Sobald der virtuelle COM-Port geschlossen wurde kann die SPS wieder auf die Busklemme zugreifen.

Der Treiber berücksichtigt keine laufenden Transfers. Ebenso wird die Konfiguration der Busklemme nicht wiederhergestellt auch wenn sie durch die Anwendung verändert wurden, die den virtuellen COM-Port benutzen.

 

Architektur 3:

Voraussetzungen

Entwicklungsumgebung

Zielplattform

TwinCAT v3.0.0

PC oder CX (x86)