USB Virtual COM Port
A USB Virtual COM Port allows you to use a USB Interface to talk to serial devices. This essentially gives users a simple pathway to communicating to peripherals using software development tools that support serial communications, a relatively common standard is most programming languages.
If you have ever attempted to write a program that communicates with a USB peripheral device, you will quickly find that it is a rather daunting task. We began developing USB devices years ago, but quickly ran into a brick wall when it came to making our earlier USB devices user-friendly. So we shelved the product line for a few years, waiting for the development tools and technologies to mature. And it did. We discovered a company called FTDI (www.ftdichip.com) that had the solution we were looking for. An easy way to implement USB into our growing line of products.
FTDI manufactures a line of microprocessors that convert USB to Serial communications. These chips allow you to implement a USB Virtual COM Port, making it possible to control external peripherals with simple RS-232 serial commands. This provided us with the communications path we needed to make USB device user friendly. There are many companies on the market that make such chips, but when you get into the intricacies of USB to Serial conversion, you will quickly find that FTDI clearly stands above all others…and for good reason.
Unlike other USB to Serial converters on the market, FTDI had two primary focuses in mind: 1) Ease of integration for the engineer (us), and 2) Compatibility for the consumer (you). And it was a perfect fit. With regard to compatibility, FTDI has gone far beyond the call of duty, offering drivers for every major operating system, and then some. As for compatibility, we have not experienced any compatibility issues. And this is actually a little surprising. We have customers who are using LabVIEW in conjunction with our products. LabVIEW has had difficulties with compatibility of some of the commercially available USB to Serial converters we have tried. And for good reason, many of the devices we tried had weak drivers that were not properly implemented. This has not been the case with FTDI, LabVIEW recognizes our device as a real serial device, and from that point forward, its just a matter of sending serial commands to the controller….without a USB interface fighting your development.
So here we have a known good FTDI USB to Serial Adapter married to the latest generation of ProXR firmware (that’s the technology we have been developing since 2004, which shares some of the same features of the controllers we developed back in 1994 when we first began developing relay controllers). So now that we have two known good technologies married together, we now are able to offer a large line of USB devices that are perfectly suited for many applications.
For the user, its really just a matter of downloading the USB Virtual COM drivers from their web site. Plugging in our device, and waiting for the COM port to be assigned (we will get into the details of this in future articles). Once the COM port has been assigned, you simply open the COM port at 115.2K Baud and communicate to the device as though it were plugged into the serial port of your computer.
Now all of this may sound too good to be true. And in some respects, it is. There is one hurdle that we are working to overcome, a hurdle that will put handcuffs on many of your applications if you choose to use a USB interface.
When you plug any USB device into a computer, the motherboard of your computer begins sending a series of data packets to the remote device, and the remote device MUST respond….constantly, and without interruption. If there is ever a interruption in the data flow between the USB to Serial converter and the motherboard, your application will stop, and your motherboard will kick the USB device off the computer. The device will go offline, and you won’t be able to use it again until you unplug the device, and then plug it back in.
With all of the glory of USB communications, there are two things that developers of the USB protocol did not account for 1) making it easy to use and implement for the causal programmer, and 2) the biggest problem we currently face: USB’s inability to self correct. In other words, USB does not have any form of error checking built into the protocol. It is a Zero Tolerance protocol, and if anything goes wrong…its a one strike and your out kind of protocol. The most unforgiving of ALL computer to device communication technologies. You have likely experience this yourself, that thumb drive didn’t work when you plugged it in, so you unplugged it and plugged it back in…then it was fine. Or maybe your webcam froze and would not work until you either unplugged it or restarted your computer. And for us, we face an even greater challenge than any webcam, hard drive, thumb drive, keyboard, mouse, or printer….we face the potential of EMI interacting with the USB interface….and so the bloody, knock-down drag out battle begins…EMI vs. USB.
EMI vs. USB
Like a spoiled child, USB always gets its way. It tolerates nothing from its adversary. Its heartless, uncompassionate, and has the authority to rule the communications between your computer and all peripheral devices. In the other corner is EMI, Electromagnetic Interference. It should be equated to a lightning strike, a very serious burst of energy that is so strong, it has the ability to interfere with the high-speed flow of USB traffic. And here’s why. On our controllers, the USB interface is located just inches from the relay. And while relays are electrically isolated, they are NOT EMI isolated. So here we have a lighting strike operating next to a delicate microprocessor that does not tolerate EMI. And we don’t have much of a choice about it.
Make no mistake though, EMI is inducted beyond the bridge of a galvanic isolator, and brings an absolute halt to USB traffic. But that doesn’t mean it is not useful, it just means that, in the current state of technology, you MUST limit yourself to USB control of applications that do NOT introduce ANY EMI in the course of switching external devices. So unless the device is otherwise noted, you will see the following warning on devices that cannot tolerate EMI:
This Device CANNOT be used in inductive control applications. Click Here for More Information
Avoiding EMI Applications
There are a few rules about what is safe and what is not safe to control. The yellow link above gives you these rules in brief, and here I will reiterate these rules so they become clear. If you are trying to control anything that moves, it will be inductive, and it will not work with our USB controllers. In addition to things that move, things that contain transformers are also inductive. This includes high voltage power supplies, fluorescent lighting, and even computer. They are all inductive. To to generalize what is not safe, if it contains a magnetic coil, it is inductive, and it cannot be used with our current line of USB devices (though it will work fine with other communication technologies). Please reference our article on induction suppression, it is very useful for other interface devices: Controlling Inductive Devices: Managing Electromagnetic Interference
On the other hand, there are many applications where USB switching can be employed with reliable daily service. Where USB can coexist with other kinds of switching applications. That is what our current line of USB devices focus on, both in terms of cost and features. Here are some examples of what is safe: High voltage incandescent lighting (if it contains a filament, with no transformer, then its safe). This includes halogen and standard incandescent lighting applications. In addition, you can safely control video signals, line level, and amplified audio signals are all ok. We have also introduced a line of Reed Relay controllers, which are ideal for small signal telecommunications switching, and have already found their home in test fixture applications. In addition, it should be possible to use some of our USB controllers for light duty data communications traffic switching, though actual applications have not yet been tested. And have no fear, the future of USB and EMI together is brighter than it may seem…
USB and EMI: The War to End
All hope is not lost, we have already developed devices that allow USB and EMI to coexist peacefully in the same application. We have been working on the release of a new technology that solves these problems entirely. Later, in the upcoming product released, the battle of EMI and USB will be over, and two bitter enemies will finally be able to work together. This means more control applications for you with a minimal increase in hardware. This is not to say the current line of USB products will become obsolete. They are, and will always be, ideal choices for some applications. But until we have specifically stated, “Inductive Rated” on a USB device, caution should be exercised when mixing USB with an inductive EMI application.
|Advantages of USB Communications||Disadvantages of USB Communications|
|Power Available for Powering Small External Devices||If you are NOT using Virtual COM Communications, Plan on Spending a Year or More Learning Use USB|
|Capable of High-Speed Communications||No Error Checking|
|Versatile Architecture Ideal for Large Array of Diverse Applications||No Tolerance for EMI Applications, Drops Connected Devices if a Single Communication Error Occurs|
|Easily Adapted to Serial Communications for Easy Programming||Distance Limitations|
|The Most Unforgiving of ALL Computer/Device Communication Protocols|