Remote Serial Communications Via Winsock -- A Pair of ActiveX Controls and a Compact Framework DLL
Goal: To allow two network connected computers to communicate using Winsock (TCP/IP), and additionally to allow one computer to use the physical serial port of the other.
Scenario: Suppose that we have a laboratory instrument, data acquisition system, control system, or similar equipment with which you would like to interact both locally and remotely. With the proliferation of WiFi (802.11b and similar) high performance wireless networking solutions, this becomes even more attractive. It now is practical to write applications that use fixed-point hardware almost without limit. In fact, a little ingenuity allows us to share this fixed hardware among multiple remote users, with little additional expense.
Naturally, what is under discussion here involves providing serial connectivity over a LAN. There are hardware solutions that tackle this problem (for example, take a look at http://www.lantronix.com/products/ds/index.html, http://www.sgi.com/peripherals/networking/serial_port/ and http://www.newageautomation.com/SerialHub.htm), and others have developed software solutions such as Telnet/Rlogon. The advantage to the ActiveX controls that I have developed is that they are low cost (free in the Demo version), and allow more programmer flexibility than most other solutions. It is easy to write a program (I use VB, but you can choose any programming environment that supports ActiveX controls) to work with a locally connected serial device, then to add remote connectivity with a few lines of code. The API for both local programming and remote are quite similar. Thus, it is possible to write a program that executes on the remote computer(s) that has the same in look and feel, and is different in internal detail in only a few minor ways.
Solution: I have developed two ActiveX controls that wrap the functionality of the Microsoft Comm control and the Microsoft Winsock control. One of these controls, RemoteComm.ocx, is used in an application that executes on the PC that is connected by one of its serial port to some other hardware system. The other control is LocalComm.ocx. It uses Winsock to connect over a LAN to use remote services provided by the RemoteComm.ocx.
The RemoteComm.ocx ActiveX control may be used in a fashion similar to MSComm32.ocx, the Microsoft Comm control. Most (though not all) properties and events of MSComm are mirrored in RemoteComm.ocx -- thus, it may be used as a stand-alone serial communications add-on.
Add LocalComm.ocx to an application written to execute on a PC that is networked with the computer running the application that hosts the RemoteComm.ocx. The properties, methods, and events of LocalComm allow you to control any serial port on the other PC, and to send and receive data using that serial port.
NEW Feature June 2005 — Virtual Serial Port Support. Note, VSP does not work under Vista x64 ◄◄◄◄◄
Object models:
The example programs that are installed when you run the Setup program illustrate all important properties, methods and events for these controls. None-the-less, there are some issues that deserve comment. I'll discuss these here.
RemoteComm Methods
Listen (Value As Boolean) -- True allows remote connections to be established from the LocalComm.ocx (see the LocalComm Connect method).
SendMessage (Message As String) -- This allows you, the programmer, to send "out of band" messages to the LocalComm.ocx. Messages sent using this method are not interpreted as serial data or control messages. You can use these to send other program messages or signals that do not deal specifically with the actual serial data. The example that is included in the Setup programs use SendMessage to implement a "Chat" feature. However, a more likely function that would use this communications channel is to control functions in the either PC program that are needed. For example, you might use SendMessage to send a command from one program to the other to simulate a button click, or, perhaps, to update a progress bar. See the Corresponding OnMessage event in both RemoteComm and LocalComm object models.
RemoteComm Properties
UseSocket (Socket As Integer) -- Use this property to specify the Winsock socket on which to Listen. If set to 0 (zero), any available socket may be used.
InputData (read only Data As String) -- This property is analogous to the MSComm32.ocx Input property. It may be used by the local program to read receive data. The use of this property does not interfere with data that will be sent from RemoteComm to LocalComm -- thus, it allows you to monitor all serial data that will be seen by the remotely connected PC.
TransmitData(read only Data As String) -- This property reflects data sent by the remotely connected PC that has been output on the local serial port. Do not confuse this property with the Output property, which may be used by the local program also to send data via the local serial port.
RemoteComm Events
OnMessage(Message As String) -- This event is generated when the LocalComm uses the SendMessage method. The Message content is not structured. Thus, it is up to you to decide the meaning of any specific message.
rError (ErrorNumber As Errors) -- This event is generated when an unexpected communication exception occurs. Exceptions of this type may happen if the network connection is broken, resulting in the attempt to use a socket to send data, when Windows has closed that socket. Such an exception may occur when using a WiFi, wireless, network connection, for example. Another exception might occur if there is an uncorrected data error in the data received via Winsock. While TCP/IP attempts to assure accurate data transfer, errors can happen. If they do (an if the error is detectable; not all such possible errors can be detected), then this error will be raised.
OnComm -- This event it generated for communications events associated with the local serial port. It has a somewhat abbreviated set of associated CommEvent properties. However, importantly, one additional condition will cause an OnComm event. If the remotely connected PC sends serial data, a copy of that data may be read using the TransmitData property.
Other RemoteComm events (OnComm) and properties are analogs to those of MSComm. Please use other documentation (such as my book, Visual Basic Programmer's Guide to Serial Communications) for these details.
LocalComm Methods
Connect -- Call to connect via the socket specified by the RemotePort property to the PC specified by the RemoteHost property.
SendMessage (Message As String) -- This allows you, the programmer, to send "out of band" messages to the RemoteComm.ocx. Messages sent using this method are not interpreted as serial data or control messages. You can use these to send other program messages or signals that do not deal specifically with the actual serial data. The example that is included in the Setup programs use SendMessage to implement a "Chat" feature. However, a more likely function that would use this communications channel is to control functions in the either PC program that are needed. For example, you might use SendMessage to send a command from one program to the other to simulate a button click, or, perhaps, to update a progress bar. See the Corresponding OnMessage event in both RemoteComm and LocalComm object models.
LocalComm Properties
RemotePort (Socket As Integer) -- Use this property to specify the Winsock socket on which to Connect.
RemoteHost(HostName As String) -- Use this property to specify the name (or explicit IP address) of the PC where the application hosting RemoteComm.ocx is running.
ReceiveData (read only Data As String) -- This property is analogous to the MSComm32.ocx Input property. It may be used by the local program to read receive data. The use of this property does not interfere with data that will be sent from RemoteComm to LocalComm -- thus, it allows you to monitor all serial data that will be seen by the remotely connected PC.
Output (Data As String) -- Use this property to output data on the remote PC serial port. This property serves the same function as the MSComm Output property.
LocalComm Events
OnMessage(Message As String) -- This event is generated when the LocalComm uses the SendMessage method. The Message content is not structured. Thus, it is up to you to decide the meaning of any specific message.
rError (ErrorNumber As Errors) -- This event is generated when an unexpected communication exception occurs. Exceptions of this type may happen if the network connection is broken, resulting in the attempt to use a socket to send data, when Windows has closed that socket. Such an exception may occur when using a WiFi, wireless, network connection, for example. Another exception might occur if there is an uncorrected data error in the data received via Winsock. While TCP/IP attempts to assure accurate data transfer, errors can happen. If they do (an if the error is detectable; not all such possible errors can be detected), then this error will be raised.
OnComm -- This event it generated for communications events associated with the remote serial port. It has a somewhat abbreviated set of associated CommEvent properties.
Other LocalComm events (OnComm) and properties are analogs to those of MSComm. Please use other documentation (such as my book, Visual Basic Programmer's Guide to Serial Communications) for these details.
Compact Framework CFRemoteSerialIO
The same functionality that the LocalComm ActiveX control provides for Visual Basic (and equivalent ActiveX hosts) is provided for PocketPC and Windows CE 4.1 devices using a Visual Studio .NET 2003 assembly (DLL). The object model is shown below.
Example Programs
There are two example programs included in the Setup program. These illustrate most of the important features of RemoteComm.ocx and LocalComm.ocx. The architecture that is supported by the two ActiveX controls is "host/client." The "host machine" is the PC that provides the physical serial port; the Remote Comm Host program illustrates it. The "client machine" is the PC that initiates a connection to the host. The example program for this is Test Remote Communications Terminal.
Run Remote Comm Host on one machine. It doesn't need any configuration. Remote Comm Host has three active windows. Remote Comm Host listens for a Connect request from the other application (Test Remote Communications Terminal in our example). After a connection has been established, all serial data transactions are displayed in the Monitor Window. Data sent from Test Remote Communications Terminal to the physical serial port are displayed in blue, while data received from the connected device, and then sent using Winsock to Test Remote Communications Terminal, are displayed in red. The Chat windows may be used to send/receive data to the connected Test Remote Communications Terminal program, "out-of-band," without affecting the serial data stream.
Run Test Remote Communications Terminal on a client machine. There are a few configuration parameters needed. These parameters may be provided using the Remote Port menu item. Most important is the RemoteHost name. You must specify the name of the computer where Remote Comm Host is executing. This is the name used by the LAN, and will be shown under My Network Places. You may specify the Serial Port Number and Serial Port Settings using the same menu. If you click the "Open" menu item, LocalComm.ocx will use Winsock to attempt to connect with Remote Comm Host. if the connection is established, the parameters that have been specified (some are hard coded) for the serial port will be used to actually open the physical port on the PC that is executing Remote Comm Host. If the serial port cannot be opened, then a MsgBox will be displayed. Otherwise, all data typed in the Terminal Window will be sent to Remote Comm Host (and output on the serial port). Serial data messages received from Remote Comm Host will be displayed in Terminal Window. The Chat windows may be used to send/receive data to the connected Test Remote Communications Terminal program, "out-of-band," without affecting the serial data stream.
Both the Remote Comm Host and the Test Remote Communications Terminal employ some other routines that I haven't described here. You will want to examine these routines. The figure below shows a typical communications session. I used a modem on my host machine for this example, just to keep things simple and easy to understand.
A Compact Framework example named CFClientTest.sln is included. It functions in the same way as the Test Remote Communications Terminal example (PocketPC only).
NEW Feature June 2005 — Virtual Serial Port Support
These two figures illustrate the use of the LocalComm ActiveX control with a device driver that creates a Virtual Serial Port. This allows any external program to access the remote serial port on the host machine over the Winsock connection! I have illustrated this by creating a virtual Com4 serial port on my local machine, opening Com4 using HyperTerminal, opening the remote serial port using the facilities of the LocalComm/RemoteComm ActiveX controls, and then sending commands to a remote device (a modem on the remote machine, for illustration), and receiving data from that remote device in my HyperTerminal session.
Demo Versions
The Setup program contains "Demo" versions of these two ActiveX controls and the Compact Framework DLL. These display a MsgBox with a copyright message each time the control is sited (when first executed in design or run mode), or when the CF class is instantiated. If you find these to be valuable, you may want to purchase versions without the MsgBox. These are bargain priced! You can purchase either of them at $10 each, $20 for the pair of ActiveX controls, and $25 if you want to the Compact Framework version (all three objects). You also may use the buttons below for purchase. Contact me directly for this. For this low cost, I cannot provide much in the way of support. However, I will try to answer specific questions. Naturally, I am available for consultation at my regular hourly rate.
The Setup program does not include the Virtual Serial Port software. This is available for an additional cost. The device driver used to create the virtual serial port is a 3rd party product, and its use incurs an additional licensing charge. The additional cost will range from $50 for a single site application license to about $400 for a developer license for unlimited redistribution of derivative products. Contact me for more information about this feature.
Source Code, code for PocketPC, and Visual Studio .NET
Source code also is available at additional cost. Contact me directly for this.
END-USER LICENSE AGREEMENT FOR THIS SOFTWARE (LocalComm/RemoteComm
ActiveX controls and Compact Framework CFRemoteSerialIO DLL).
IMPORTANT—READ CAREFULLY: This End-User License Agreement (“EULA”) is a legal
agreement between you (either an individual or a single entity) and Richard
Grier for the software product identified above, which includes computer
software and may include associated media, printed materials, and “online” or
electronic documentation (“SOFTWARE PRODUCT”). By installing, copying, or
otherwise using the SOFTWARE PRODUCT, you agree to be bound by the terms of this
EULA. If you do not agree to the terms of this EULA, do not install or use the
SOFTWARE PRODUCT.
SOFTWARE PRODUCT LICENSE
The SOFTWARE PRODUCT is protected by copyright laws and international copyright
treaties, as well as other intellectual property laws and treaties. The SOFTWARE
PRODUCT is licensed, not sold.
1. GRANT OF LICENSE. This EULA grants you the following rights:
· Installation and Use. You may install and use one copy of the SOFTWARE PRODUCT
on any computer used for software development. You may distribute and use any
derivative product in any fashion that you chose.
2. DESCRIPTION OF OTHER RIGHTS AND LIMITATIONS.
· Limitations on Reverse Engineering, Decompilation, and Disassembly. You may
not reverse engineer, decompile, or disassemble the SOFTWARE PRODUCT, except and
only to the extent that such activity is expressly permitted by applicable law
notwithstanding this limitation.
· Software Transfer. You may permanently transfer all of your rights under this
EULA, provided the recipient agrees to the terms of this EULA.
· No Support. Richard Grier does not provide support for the SOFTWARE PRODUCT.
· Termination. Without prejudice to any other rights, Richard Grier may
terminate this EULA if you fail to comply with the terms and conditions of this
EULA. In such event, you must destroy all copies of the SOFTWARE PRODUCT and all
of its component parts.
3. COPYRIGHT. All title and copyrights in and to the SOFTWARE PRODUCT (including
but not limited to any images, photographs, animations, video, audio, music,
text, and “applets” incorporated into the SOFTWARE PRODUCT), the accompanying
printed materials, and any copies of the SOFTWARE PRODUCT are owned by Richard
Grier. The SOFTWARE PRODUCT is protected by copyright laws and international
treaty provisions. Therefore, you must treat the SOFTWARE PRODUCT like any other
copyrighted material except that you may install the SOFTWARE PRODUCT on a
single computer provided you keep the original solely for backup or archival
purposes.
MISCELLANEOUS
This EULA is governed by the laws of the State of Colorado.
4. DISCLAIMER OF WARRANTIES. To the maximum extent permitted by applicable law,
Richard Grier provides the SOFTWARE PRODUCT and any (if any) support services
related to the SOFTWARE PRODUCT (“Support Services”) AS IS AND WITH ALL FAULTS,
and hereby disclaim all warranties and conditions, either express, implied or
statutory, including, but not limited to, any (if any) implied warranties or
conditions of merchantability, of fitness for a particular purpose, of lack of
viruses, of accuracy or completeness of responses, of results, and of lack of
negligence or lack of workmanlike effort, all with regard to the SOFTWARE
PRODUCT, and the provision of or failure to provide Support Services. ALSO,
THERE IS NO WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT, QUIET POSSESSION,
CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT, WITH REGARD TO THE SOFTWARE
PRODUCT. THE ENTIRE RISK AS TO THE QUALITY OF OR ARISING OUT OF USE OR
PERFORMANCE OF THE SOFTWARE PRODUCT AND SUPPORT SERVICES, IF ANY, REMAINS WITH
YOU.
5. EXCLUSION OF INCIDENTAL, CONSEQUENTIAL AND CERTAIN OTHER DAMAGES. TO THE
MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL Richard Grier BE
LIABLE FOR ANY SPECIAL, INCIDENTAL, INDIRECT, OR CONSEQUENTIAL DAMAGES
WHATSOEVER (INCLUDING, BUT NOT LIMITED TO, DAMAGES FOR LOSS OF PROFITS OR
CONFIDENTIAL OR OTHER INFORMATION, FOR BUSINESS INTERRUPTION, FOR PERSONAL
INJURY, FOR LOSS OF PRIVACY, FOR FAILURE TO MEET ANY DUTY INCLUDING OF GOOD
FAITH OR OF REASONABLE CARE, FOR NEGLIGENCE, AND FOR ANY OTHER PECUNIARY OR
OTHER LOSS WHATSOEVER) ARISING OUT OF OR IN ANY WAY RELATED TO THE USE OF OR
INABILITY TO USE THE SOFTWARE PRODUCT, THE PROVISION OF OR FAILURE TO PROVIDE
SUPPORT SERVICES, OR OTHERWISE UNDER OR IN CONNECTION WITH ANY PROVISION OF THIS
EULA, EVEN IN THE EVENT OF THE FAULT, TORT (INCLUDING NEGLIGENCE), STRICT
LIABILITY, BREACH OF CONTRACT OR BREACH OF WARRANTY OF OR ANY SUPPLIER, AND EVEN
IF OR ANY SUPPLIER HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
6. LIMITATION OF LIABILITY AND REMEDIES. Notwithstanding any damages that you
might incur for any reason whatsoever (including, without limitation, all
damages referenced above and all direct or general damages), the entire
liability of and any of its suppliers with regard to the SOFTWARE PRODUCT or
this EULA and your exclusive remedy for all of the foregoing shall be limited to
the greater of the amount actually paid by you for the SOFTWARE PRODUCT or
U.S.$1.00. The foregoing limitations, exclusions and disclaimers shall apply to
the maximum extent permitted by applicable law, even if any remedy fails its
essential purpose.
If you agree to the above license, you may download the Setup program here. Note, by downloading and installing this product, you explicitly agree to this license agreement.