Lean MES Open Source Manufacturing Execution System
Flexible Manufacturing Solutions through Open Standards and Free Software....

TCP-IP Client-Server sockets communication for OPTO22 PAC

Demonstration of  Bi-directional TCP-IP synchronous communications between PAC and Applications.
Tested with Microsoft WindowsXP Hyper Terminal Application.
Tested with TcpXcoN TcpIp Client Windows Service Application.
Stable, confirmed on: SNAP-LCE(R7.2h), SNAP-PAC Sim(R8.2).

Deployment/Test Instructions:

1. Download the SimpleOPTO22EchoTcpServerV2.zip strategy and extract files.
2. Download the TcpXconSetup.msi.zip installer, extract, run install, requires .NET Framework 3.5.
3. Open strategy in PAC Control Pro.
Configure/Update Control Engine, set active engine to SNAP-PAC Sim(R8.2)
5. Compile strategy, load to PAC Sim and click the Run Strategy button.
6. Test 1: Open extracted Hyper-Terminal 8081.ht file, in properties set IP address of Active Control Engine.
7. Save 8081.ht file, click the "Connect" button. Within 9 sec. type "Hello" press the "Enter" key.
8. Close
the Hyper-Terminal application.
9. Test 2: In Computer Management (WMI) click the Services node, start service TcpXcoNService.
10. Using the System Event Viewer to observe  Application log for TcpXcoN related messages.
11. In PAC Control Pro, use/create the watch window to test the non-Heartbeat scenario by
      writing a desired sequence of characters to the "sDataToSend" tag.

Preface for
TcpXcoN TcpIp Client Windows Service Application prototype;

Objective: Provide reliable and extensible communication link mechanism.

Reason: Demand for dependable error-handling and communication recovery with persistent connection verification.

Implementation: Server: Listening socket with self-recovery and communication heartbeat timeout.
                           Client: Connecting socket using call-back, with self-recovery and communication heartbeat timeout.

Reason: Using empirical method it was proven the listening socket in OPTO22 PACs
is more reliable, easier to recover, simpler to implement and does not impact strategy performance
during communication loss, compare to connecting socket.

Area of applications: Multi-channel communication between computer applications and TCP-IP enabled devices.
Typical computer applications scenarios;
   a. distributed file exchange between devices and computer applications, e.g. MSMQ.
   b. communication/protocol gateway device to computer application or device to device.
   c. devices to database connectivity.
Typical devices scenarios;
   d. PAC with open or custom protocol.
   e. Vision Inspection controllers, e.g. Banner, Cognex.
   f. Tool controllers, e.g. Atlas-Copco, Stanley, Makita.
   g. RFID transceivers, e.g. Balog BIET-170.

Prototype source code released under the terms of the GNU General Public License.
You may download the source code for TcpXcoN TcpIp Client Windows Service Application prototype here.
Note! Config.ini integration intentionally skipped, Although you may recompile the service
to have a specific device IP address set, currently hard-coded to for PAC-SIM.
To modify the device IP address  use the following region in TcpXcoN.cs :

        // set default initialization settings
        private string  mpath   = "";
        private string  fpath   = "Config.ini";
        private string  address = ""; //"";
        private int     port    = 8081;
        private int     reconnect   = 5000; //reconnect to server, milliseconds
        private int     retries = 1;
        private int     timeout = 5000; // milliseconds
        private int     eomchar = 13; // ascii {CR}
        private int     logLevel= 3; //{0;4} 4 -log all

Further modifications are subject to  GNU General Public License.
Print screens
Fig.1 TcpXconService installed and started.

Fig.2 PAC Control Professional IDE, monitoring TCP Server communication status in watch window.

 Fig.3 Established connection between Client(TcpXcoN) and Server(PAC) using port 8081. Ports 22001 are utilized for communications between device and PAC Control Professional applicaton.

Fig.4 Communication messages observed in Application log.

Fig.5 Communication failure message on cable disconnect (Ethernet switch was present between Server and Client, cable was unplugged from the Server(SNAP-LCE).
Note the "Syn sent" status, client is actively trying to connect to server.

Fig.6 Communication has recovered, heartbeat counter restarted.

Fig.7 Demonstration of on demand communication between PAC and Application. While connection exist, PAC can send data to Application at any time.

Copyright (C) 2011 Agile Automation Technology LLC.