Architecture

Considering a conventional serial port the driver communicates with the UART chip through an internal hardware bus. In case of the TwinCAT-Virtual-Serial-COM-Driver this communication is implemented using ADS and EtherCAT protocol.

 

Architecture 1:

When the driver is installed on a computer, it instantiates an ADS server with fixed port number, the so-called TcEL60xx-AdsServer. This ADS server provides an ADS interface to create serial COM ports. Within the TcIO driver EtherCAT slave objects are the clients of the TcEL60xx-AdsServer. TcIo has a special class of EtherCAT slave objects that are created for each EL60xx bus terminal on TwinCAT start. They have the capability to transmit data packets from the TwinCAT-Virtual-Serial-COM-Driver to the bus terminal, and to receive data from the bus terminal which is in turn forwarded to the driver. The driver will forward it to a Windows application which has a pending read on the respective serial port.

The following image illustrates the architecture for the Windows driver variant.

 

Architecture 2:

Note
Data loss

If an EL60xx bus terminal is utilized from PLC and also as virtual COM port, then access to the bus terminal must be coordinated by a superior mechanism. On opening the respective virtual COM port, accesses by PLC are blocked as long as the virtual COM port is open. When the virtual COM port is closed, PLC can access the bus terminal again. However, the driver will not regard any running transfers. It will also not restore the bus terminal configuration like baud rate, or stop bit settings, even if it has been modified by an application which used it through a virtual COM port.

 

Architecture 3:

Requirements

Development environment

Target system type

TwinCAT v3.0.0

PC or CX (x86)