If you're familiar with OmniServer, you likely already know how OmniServer is commonly used to retrieve information from devices that use ‘non-standard’ protocols to communicate such as weight scales, barcode readers, and printers either over serial connections or Ethernet connections.
However, with the advent of USB connectivity, many such devices that would have traditionally been a serial/COM device now physically connect to a machine via USB, instead.
Continuing our "OmniServer Did You Know?" blog series, we will cover how OmniServer can easily connect to USB or serial-to-Ethernet devices that are mapped virtually as Serial/COM devices.
Choosing what type of "connection" to make to your non-standard device 20 years ago was simpler - it was typically a physical serial/COM port connection between the COM port on the device to the COM port on your OmniServer machine or it was an Ethernet connection. Over the years, though, some of those lines have become blurred.
USB as a physical connection medium has become more and more common as time has progressed. I remember the first handheld barcode scanner I ever integrated with OmniServer - it was a standard RS-232 Zebex barcode scanner. These days, while it might still be an option to have a classic COM port interface on a barcode scanner, the default is normally either USB or Ethernet.
If you missed our original blog series "OmniServer Did You Know?", get caught up here!
Additionally, many companies that have a large installed base of serial port devices no longer find it practical to connect via serial but it's also not financially attractive to rip and replace all of those serial devices that are still operating as expected. It's become very common over the years to "upgrade" those existing serial devices by adding a serial/Ethernet converter or device server, allowing those devices to be wired via Ethernet, instead (manufacturers of such converters are common these days, but think Lantronix or Comtrol).
From OmniServer's perspective, for such devices, it's still just a simple COM or Ethernet device connection. It's just a matter of understanding what to look out for.
How Do I Integrate Virtual COM Devices?
Virtual COM is essentially a piece of software that knows how to communicate with a device via either USB or Ethernet and, on the OmniServer machine, it maps that device as a virtual COM port in the Windows Device Manager (go ahead, look in the Windows Device Manager after installing and it will show up as a COM port).
This is the same concept as USB COM ports that have become necessary for newer machines that don't even support physical COM ports any more. The "driver" that installs for those USB COM ports is essentially Virtual COM software.
Since all of that mapping is abstracted from OmniServer at the OS level, all OmniServer needs to know is the COM port that Windows assigned to that Virtual COM port and the associated COM parameters (i.e. Baud Rate, Parity, Stop Bits, etc), which can all be found in the properties of the COM port in the Device Manager.
At that point, it's the exact same process to configure OmniServer as it is for a physical COM port - simply create a new "Serial/USB Mapped" device with the correct COM port and COM parameters specified and that's it! Typically, other than the COM Port, the other COM parameters are generally fine at the OmniServer defaults, as well.
How Do I Integrate Serial/Ethernet Converted Devices?
So I also mentioned earlier that it's common for serial devices to be added to an Ethernet network using serial/Ethernet converters (also sometimes referred to as serial/Ethernet device servers or some variant of that). There are typically a couple of options for successfully integrating these Ethernet connected serial devices with OmniServer - some are better than others.
Many of these serial/Ethernet converters will include a Virtual COM option where there is a "driver" software component that installs on the machine that needs to communicate with the devices (i.e. the OmniServer machine, in our case). That "driver" essentially handles the TCP socket connection to the converter and maps to a Virtual COM port on the machine.
In theory and concept, this is a very straightforward way to integrate such devices - especially with software that only supports COM type connections. And it's certainly possible to connect OmniServer to such devices using this method (even though OmniServer is not limited to just COM type connections) - it's the exact same method as we just covered in the previous section.
However, it is not the preferred method of connecting OmniServer to these now Ethernet-enabled devices. Most of these serial/Ethernet converters also support something called "TCP Server" mode or something similar. It is generally recommended that this mode be enabled for use with OmniServer.
The difference is that, rather than relying on that additional "driver" from the serial/Ethernet converter manufacturer, this method allows OmniServer to control the TCP socket handling with the converter. This is important because it's not uncommon for those "drivers" mapping the converters to a Virtual COM port to fail, which then causes communications failures outside of the control of OmniServer.
This also simplifies the process - from OmniServer's perspective, that Ethernet-enabled serial device just becomes a native Ethernet device. Simply configure an "Ethernet" device in OmniServer with the IP Address (or even DNS name, if your IT department has mapped the IP Address to a DNS entry) and port that are configured on the converter and you're good to go. This also makes it easier to troubleshoot Ethernet connectivity issues using tools like Wireshark.
Regardless of which method is chosen for those Ethernet-enabled serial devices, though, it's straightforward to implement in OmniServer as either COM or Ethernet - it's just a matter of finding out which option the converter is configured for. Just keep in mind the benefits of going the TCP Server route on those converters, if at all possible.
Where can I get more information?
Do you have a non-standard device that isn't currently integrated that would benefit your process but you're not sure how to get started? As always, we're happy to help with a complimentary protocol review of your protocol documentation or to answer questions you may have.
Email us at support@softwaretoolbox.com with your questions and subscribe to our blog for more quick and easy OmniServer tutorials and tips. Then, make sure to download the OmniServer trial to try it yourself for free.
