Page 1 of 1

VISUAL BASIC COMMUNICATIONS

Posted: Thu Oct 08, 2009 6:04 pm
by Cyclops
VISUAL BASIC COMMUNICATIONS

Normally, 'digital' data input into a PC is just that – you use your digits; just two of them in my case, as I have never graduated beyond the two fingered school of typing. However, there are other ways to get data into and out of your PC – infra-red ports, network cards, the USB (Universal Serial Bus) and of course the good old-fashioned serial and parallel ports. The serial port and parallel port are typically used to connect either a modem or a printer to your PC. However, you can use them for other purposes. For example, you can use the parallel port to control other hardware – train sets, automated dog walkers and other such useful devices. You can also use the serial port to perform the same functions.

Since the serial and parallel ports can perform the same types of functions in controlling external devices (other than printers and modems, of course), why use one rather than the other? Well, as with most things, it’s horses for courses. The parallel port is better at transferring lots of data – it has eight signal lines compared with a serial port’s one. The parallel port also produces data signals directly at the usual logic levels of 3V or 5V. With the serial port you have to decode the data stream into characters and it operates at a rather inconvenient 10V. You have to use a level converter to get down to logic chip voltages. On the other hand, the serial port can operate over much larger distances than a parallel port – and most importantly - it has fewer wires.

At first sight, the idea of fewer wires being better might seem crazy. But unless you like long sessions with a soldering iron, fewer is definitely better: it takes a lot, lot longer to debug wires than it does a program – believe me, cut-and-paste isn’t too good when you're working with solder-and-chips. If you’ve just spent a few days swearing at a particularly obscure software problem, then a few soldered connections might seem trivial by comparison. However, digital hardware has one characteristic that may not be apparent to programmers – it isn’t digital! Glitches, cross-talk, voltage spikes and things that go bump in the night are par for the hardware course.

Null modem

Here are two computers connected in different ways. The first uses two modems and the public telephone system, while the second eliminates both the modems and the telephone network.
Nullmodem.JPG
Nullmodem.JPG (17.92 KiB) Viewed 6262 times
Communicating - the basics

Serial communication is a heart quite a simple idea. There are three pins that are important. Data is transmitted over one pin (Transmit Data or TXD for short) and received over another pin (Receive Data or RXD). The data is sent sequentially as a series of on-off pulses down the wire, so a byte will take eight bits or pulses to transmit. In fact, there are one or two other bits needed as well for synchronisation and error checking, but that’s the basics. The third wire that’s needed is the Ground wire (GND) – these are electrical signals and so need a return path. While you can get away with just three wires, it’s often useful to have other control signals to make things easier for the software. There are six other signals: Ring Indicator (RI) is set by a modem when it detects an incoming call. Carrier Detect (CD) is again set by the modem when it detects another modem as the originator of the incoming call. For a null-modem, RI and CD can are ignored.

This leaves four other signals which come in pairs. Request To Send (RTS) and Clear To Send (CTS) are used by the PC to signal that it is ready to write or read data respectively. Data Terminal Ready (DTR) and Data Set Ready (DSR) do a similar sort of job (there are actually finer details of what these signals should be used for – but that needn’t bother us here). So for our null-modem purposes there are three pairs of wires – and these need to be ‘crossed over’ for the two ports to communicate. That is, the RCD pin of one port must be connected to the TXD pin of the second and so on. This means that when COM1 transmits data (on TXD) COM2 will receive data on RCD. The complete wiring between the two connectors looks like:
pins3.JPG
pins3.JPG (6.65 KiB) Viewed 6262 times
If you’re confident with a soldering iron you can get the parts separately and wire them up or if you’d rather leave it to an expert, get a ready made cable – though check out the type of ports of the back of your PC first. Older PCs tend to have one 25 pin port and one 9 pin port – all of the above wiring refers to the more modern 9-pin varieties.

OK, so assuming you’re equipped with a suitable null-modem cable and you’ve plugged it into the two ports what next? One way to check that everything is working OK is to use two HyperTerminal sessions, one connected to COM1 the other to COM2 with exactly the same speed settings. You should be able to type from one screen to the other with no trouble. Another way (more interesting, of course!) is to use a Visual Basic program.

I’ve written a simple program using mostly the default settings of the two communication ports to illustrate how events are communicated back to Visual Basic. In the program COMMS.VBP, there are two text boxes that display the input received on the respective port and two sets of buttons that toggle DTR and RTS. There’s also an Initialize button that opens the ports and sets off a polling loop. The code initially sets COM1 and COM2 up in a similar manner with both RTS and DTR off:

Code: Select all

With MSComm1
    .DTREnable = False
    .RTSEnable = False
    .CommPort = 1
    .PortOpen = True
End With
Once set up the program just polls for input:

Code: Select all

Do While MSComm1.PortOpen And MSComm2.PortOpen
    s1 = MSComm1.Input
    s2 = MSComm2.Input
    If s1 <> "" Then
        Port2.Text = Port2.Text & s1
    ElseIf s2 <> "" Then
        Port1.Text = Port1.Text & s2
    Else
        DoEvents
    End If
Loop
There are two things to notice about this simple loop. First, the loop condition tests to see if the ports are still open. If you don’t do this, you will get an annoying error when you close the program. For some reason, Visual Basic seems to close the ports before unloading the form. Secondly, the DoEvents keyword ‘releases’ the program to look for other things – such as a button click or a communication event.

In the DTR (and RTS) toggle code, you’ll see this:

Code: Select all

With MSComm1
    .PortOpen = False
    If .DTREnable = False Then
        .DTREnable = True
    Else
        .DTREnable = False
    End If
    .PortOpen = True
End With 
These communication events (DSR corresponding to DTR and CTS corresponding to RTS) events are detected in the OnComm event code:

Code: Select all

Private Sub MSComm1_OnComm()
   EventLog.Text = EventLog.Text & "Port1: " _
       & CommEventText(MSComm1.CommEvent) & vbCrLf
End Sub 
and just written to the EventLog window.

All this looks pretty neat and simple but there’s a ‘gotcha’: to set a control signal (say, RTS) you have to close the port, set RTS and then reopen it. This is disastrous if you are communicating with some hardware that isn’t really a modem – you can lose data in the small interval while the port is closed.

The problem is that the operating system uses these control wires to signal to the modem that your program is ready (that’s the main use of DTR) and it uses the RTS/CTS wires to implement hardware flow control

Pins and Names
pins.gif
pins.gif (3.04 KiB) Viewed 6262 times
pins2.JPG
pins2.JPG (12.25 KiB) Viewed 6262 times