How to Code for RS232 in Visual Basic? Part 3 – Example

You can download the example program written in Visual Basic 6.0 from the following link:

MsCommSample.zip

Sample includes detailed explanations as comment lines, so I am not going to explaing details of coding in this post.

To test the software you need to have a null modem cable if you want to communicate two computers.

You can make your own cable by soldering pins of two female DB9 connectors as follows.

Connector 1                   Connector 2
Pin 2 <---------------------> Pin 3
Pin 3 <---------------------> Pin 2
Pin 5 <---------------------> Pin 5

If you just want to test how data is sent and received on your computer, you just need one connector; short circuit pin 2 and pin 3:

Connector 1
Pin 2 <--
        |
Pin 3 <--

Make the cables at your own risk, short circuiting any pins other than 2 and 3 may damage serial port of your computer.

By default, software opens the Com1 port in 9600 bauds, no parity, 8 data bits and one stop bit without handshaking protocol. You can change it in source codes.

You also need to have Visual Basic 6.0 software to edit, debug and recompile program.

How to Code for RS232 in Visual Basic? Part 2 – Getting Data From Serial Port

In this post, we are going to focus on OnComm event of serial port programming components. The most widely used serial port component is the MSComm.ocx of Microsoft, however it has some limited properties such as working up to COM16, you may also find more sophisticated components such as SAX Comm.

Also there was a TCommPort component for Delphi, also .Net has serial port support for 2005 and after. There are several alternatives to get data from serial port but the methods used for getting data is similar. So I want to explain this method in pseudo code in this post, and for the next post I want to give a real example with MsComm32.ocx and Visual Basic 6.0

There are two major methods to get data from serial port; polling method and event driven method. Polling method is the simplest, just place a timer on your form and continuously read the data from port. However with polling method you may get your data in partly, and you may need to write extra code to comb out different data packets received consecutively.

I want to focus on event driven method, which is more convenient, fast and less CPU consuming. 

Whatever the method used for reading, the first step is opening the port with proper communication parameters. Generally, I open the port on start up procedure of program, and do not close it until the end of program. You can't communicate with a closed port, so prefer to keep it always open. 

Some applications close the port when they do not need it, it may be useful especially in mobile devices to save power, but in desktop computers, it is better to keep always open, especially if your software is about industrial automation. 

I also get communication port settings from an ini file, because communication port parameters may depend on the device that you are communicating or the communication port limitations of the host computer, so remember to get the settings from an ini file, but this is optional, so say that it is the step zero of our pseudo code.

Setting up the port is easy, you must give following parameters:

- Communication speed

- Number of data bits; 7 or 8

- Type of parity; even, odd or none

- Handshake: Hardware handshake (RTS/CTS), software handshake (XON/XOFF) or none.

And if you prefer to use event driven method, you should also enable event triggering on data receive. For MSComm32.ocx it is set up by receive threshold value, you should set the number of bytes to trigger data received event.

Normally, I use 1 for receive threshold to get informed even a single byte received by comm port.  It should be better to set it to 1 if you receive variable length of data. In our examples, I am going to set it to 1.

With MSComm32.ocx, it is set up as follows:

MSComm1.RThreshold = 1

Then you can open the comm port. For MSComm32, it is opened as follows:

MSComm1.PortOpen = True

Sometimes, you may not be successful for opening the port, so it is strictly advised to code some error handling routines to catch any possible errors, otherwise your program may rise run time error and shutdown.  Most common errors are 'port already open / port already in use'  error and 'invalid port number'. There may be another software using your comm port, also another copy of your own software may block your port. To avoid blocking the comm port by the ghost of your software, it is better to check if another copy is already running on computer. 

We already have three steps of pseudo code including the optional one:

Step 0: Get communication port settings from ini file (Optional)

Step 1: Setup the port

Step 2: Open the port

  

Sending data is the simplest part, let's send 'Hello World' through comm port:

MSComm1.Output = "Hello World!"

If port is not open, you will probably get 'port not open / operation valid only when the port is open' error. So it is better to check if port is really open before sending data.

When data is received from a serial port, it is kept in a buffer until you read it. For MSComm32.ocx, you can get your data as follows:

Data = MSComm1.Input

If you put a timer on your form and continiously read the buffer, you get the data collected in buffer. This is called polling.

For event driven programming, you use the event triggered on receiving data. Here is the pseudo code for receiving a data by event driven programming:

Step 1: Continue if event is really triggered by received data.

Step 2: Disable event generation

Step 3: Wait for a while to get possible remaining bytes.

Step 4: Read and concatenate the data into a dummy static variable

Step 5: If expected data received completely (eg. received a terminator character), use it and clear the dummy static variable.

Step 6: Enable event generation

Now let's have a closer look into steps.

Step1: Some serial communication libraries use a single event for receiving. If you are using such kind of library, you don't need to check if event is triggered by received data. MSComm32 uses the same event for all communication port related events such as buffer owerflow, cts received etc. So it is necessary to check if event is triggered by received data:

Private Sub MSComm1_OnComm()

    If MSComm1.CommEvent = comEvReceive Then

        ' Do whatever you need

    End If

End Sub

Step2: If you don't disable event generation on data receiving, received byte(s) can break your already running flow, and if it happens before you flush the reading buffer, breaking events may flush them and you may get mis-ordered data. Altough its low probability, never forget that CPU can do millions of operations in a second and one in a million chance may hit in every seconds. So, disable event generation. For MSComm object, just assign a zero to receive threshold:

MSComm1.RThreshold = 0

Step3: Modern computers are faster than serial communication speeds. Taking a little breath in codes is adviced if you are using MSComm. There is a little bug I have noticed, if you poll MSComm objects buffer so frequently, it may not have a chance to flush its buffer and you may randomly get same bytes in your data. So, it is better to put some NOP code before reading buffer. There is a sleep API of Windows, however I am not satisfied with this API because I realised that it waits several lines of code after it has called, I know it sounds weird but I guess that sleep API is slowing down the Visual Basic interpreter, not the code interpreted. May be it works in compiled code but I am not happy to use it while debugging my source code. So I have my own subroutine which executes DoEvents in a loop.

Step 4: If your communication speed is so low, you may not receive it completely in a single event handler. If you see that you don't have the terminator character of your data package, you should keep your previously received data in a static variable. Example for MSComm:

Static DummyData As String 

...

DummyData = DummyData & MSComm1.Input

Step 5: If you receive the terminator character, use your data and clear static variable.Assuming that terminator character is carriage return:

If Right(DummyData,1= vbCrLf Then

    ' Data received completely

    ' Do some code to use for received data

  

    DummyData = vbNullString

End If

Step 6: If you don't re-enable the event generation, you can't get more data.

In our next post, we are going to have some practice, we are going to code a sample application in Visual Basic 6.0

How to Code for RS232 in Visual Basic? Part 1 – Serial Communication Basics

In this post series, I would like to talk about receiving data from serial port. It is one of the FAQ of industrial automation forums, but it is difficult to find a proper code or advice. 


I am not going to talk about in details of a specific communication protocol, it may be a subject for another series of post. 


I only want to describe a sample method, and give an example by Visual Basic 6.0.  As I will talk about the method, you can apply it for .Net languages or any other programming languages such as Delphi.


We can choose a sample problem; I think reading data from a barcode scanner may be a right and simple example.


Now, let’s have a little bit theory about RS232 communications, it is designed to communicate for long distances without using many cables. RS232 defines the electrical signal levels, and those signals may be converted into other defined standards such as RS485 or RS422, so I am going to describe it with logical signal levels. 


Serial communication is just like a dialog between two people. Both of them have ears and mouths to listen and speak.


When Alice talks, Bob hears with his ears.


The RS232 port has a transmitting pin and a receiving pin. If you want to establish a communication between two RS232 devices, you must connect one device’s transmitting pin to other device’s receiving pin. Just as talking and listening. 


There is also one more pin which is used as a voltage reference, it is called ground. So only three cables are enough to make a serial communication. If communication should be done for one way only, two cables are enough, one for data and one for voltage reference.


When sending a byte, transmitting pin sends a single start bit signal to inform that a new byte is coming. 


Data bits sent after start bit, number of data bits can be 7 or 8 and it depends on the settings that you decide for communication.


It has information about number of logic 1 signals, even or odd numbers.


And finally stop bits come; number of stop bits can be 1 or 2. It can be considered as a guard time between data packages.


Most important parameter in serial communications is the baud rate, which is the number of bits per second. If you set your communication parameters as  8 data bits and 1 stop bit, you should use 11 bits for each byte packet (1 start + 8 data + 1 parity + 1 stop) and with the speed of 9600 baud, you can send up to 872 bytes per second.


In serial devices, an IC named UART makes the communication and buffers some amount of data inside. 


In next post, I am planning to tell a pseudo code for receiving data from serial port. 

Simple PC – PLC Communications Part V - Expect The Unexpected

The handshake used for PC – PLC communication works well if everything is perfect. But what happens if something happens that violates the handshake?


In some countries power loss is an ordinary part of life. Generally PC is supplied by UPS, but PLC is not. In a power loss, PLC lefts the communication unexpectedly.


Even if you are using an industrial PC, it is not stable as a PLC. PC or the software running on PC may be frozen. In this case, PC or software may need a restart.


In the other hand, physical conditions may also violate the handshake. Imagine that boxes crashing on station:

It is possible; sensors may be dirty or defected, or any other unexpected reason may cause this.

So, how can we restore the stable cycle again?

Most PLC systems use non-volatile memory for holding data permanently. For a PLC system, it is not difficult at all.

If we are programming the PC, it is obvious that we have to store some information in a file or in database to avoid failure after power loss.

If we say as a rules of thumb:

1. Store all global variables (handshakes last time interval, all counters etc. and the most important; the last data you wrote in to PLC) in to a text file or database as soon as they changed.
   
   
2. Restore all global variables on start up.
   
   
3. Do not execute 'Write all outputs' before restoring all global variables.
   
   

For obeying rule 1, you can use 'Property' in addition to a global variable. Think the 'Property' as a global variable, however it is possible to execute defined subroutines when property is read or write.

VB6.0 example:

Public Property Get Data As Integer

Data = m_Data

End Property

Public Property Let Data(ByVal New_Data As Integer)

m_Data = New_Data

SaveProperty (m_Data,"Data") 'Save routine for recording Data
End Property

'Get' routine is executed whenever you attempt to read property 'Data' as

A = Data

or

MsgBox Data

And 'Let' routine is executed whenever you attempt to write property 'Data' as:

Data = 5

or

Data = Text1.Text

Use 'Property' as a global variable, add a record routine inside 'Let' and never mind again.

For the example above, restoring the 'm_Data' global variable instead of restoring 'Data' is works faster because restoring 'Data' will cause re-recording the 'Data' again and in some cases it may cause a violation error as 'File Already Open'

Rule 2 is clear so nothing to explain.

Rule 3 is also important. Think about the handshake graphics:

PC Status = '0000' also means that 'PC has completed operations, so that PLC can send the existing product and bring the new one'. Visual Basic assigns 0 into variables as they created.


C may assign anything in the memory unless variable is initialised.

Writing uninitialized data into PLC may result unexpected and unwanted results. So do not execute 'Write All Outputs' routine before loading all global data or properties and the last data written into PLC.

As the summary of those three rules of thumb, you are free to last time intervals in handshake as long as you want, however do not switch into another time interval or do not cause PLC to switch into another time interval.

You can consider putting a button on screen for resetting the handshake cycle against deadlocks, you can simply switch to T1 and clear 'PC Status' with this button, but never switch to T1 on start up. Let the operator decide for reset if necessary.

If it is not possible to control write and reads?

If your application writes 'PC_Status' into PLC before restoring it on initial start, it may cause unexpected movements on the assembly line. Some may get injured or you can miss one product.

Some SCADA systems also uses 'Read All Inputs' and 'Write All Outputs' routines for PC – PLC communications. However some of them may execute those routines in a separate thread so it may be possible to write a global variables (mostly named as 'Tag' in SCADA systems) value into PLC before initialising or restoring it.

So, what can you do if you are using a SCADA and not be able to manage 'Read All Inputs + Write All Outputs' process ?

One solution is using a cyclic counter in PLC. PLC has an increasing counter and PC echoes it into another data memory of PLC. If counter value is equal to the echo, PLC increases the counter and waits the same value from PC. If PC can not update in a certain time, PLC understands that PC has failed, and the data from PC is untrusted. This method also can be used to understand if PC is still working.

Fragmanted Information

Other than power interruptions, communicating with lots of data may cause unexpected results. Most PC – PLC communication protocols have packet length limits. For that reason, if PC wants to write too many information into PLC, it should use many data packets to write information in to PLC.

This may be dangerous if automation system designers don't take sufficient precautions.

Assume that PC is writing a receipt into PLC data memories, and 'receipt ready' flag is at the beginning of the data memory area.

PLC may apply the receipt as soon as it realises 'receipt ready' flag is set, however receipt may not be ready on time. This results of this design may be difficult to debug.

How can we avoid fragmented information?

1. We can use checksum at the beginning or at the end of data memory area reserved for PC's write operations. However, there is still a probability that something may leak because there are too many possibilities to produce the same checksum value.
   
   
2. We can use the counter solution stated above. Reserve two data memories in the data memory area which is reserved for PC's write. Let the PC fill two data memories with the echo from PLC. If both data memories are same and fresh, PLC can trust that information is consistent and trustable.
   
   

With this post, we completed the 'Simple PC – PLC Communications' series.

Our next post will be about customers. 'Customer is always right and mostly undefined'. And we will have another series with a case study. We are going to examine a data collection system to use for assembly line balancing and reporting the bottle necks on an assembly line.