IN DA NOTES

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

2009-10-23T15:42:00.001+03:00

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

2009-08-07T16:14:00.000+03:00

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

2009-08-06T17:18:00.000+03:00

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.

Developing An ActiveX for WinCC Flexible

2009-08-04T11:22:00.004+03:00

Several months ago, a customer requested a product tracing system which should work with SIEMENS PLC.

They already had a WinCC flexible licence and requested the project in WinCC.

First of all, I could not find a way to use RS232 comm ports with WinCC, so I decided to use SAX Comm library for RS232 communication.

It was not possible because I could never be able to compile the software even without any script code in it. Just adding SAX Comm object was enough to crash WinCC development environment. WinCC was raising the following error:

“Fatal ERROR: screen item Screen_1 in screen Screen_1 contains inconsistent data and should be deleted.”

Then I tried to code my own ActiveX, embedded SAX Comm object and mapped some properties and events, however result did not changed, WinCC was still crashing.

I decided to walk step by step, I realised that WinCC had a really pain about ActiveX, so I have started with a totally empty ActiveX and successfully compiled the WinCC project.

Then I started to add properties one by one, and with the first property of ActiveX caused a crash again.

In WinCC programming manual, it says that it is possible to read and write a property of an ActiveX within a script, but it was not true.

Reading or writing a property inside a script directly causes a crash.

I have found that the only way to use properties of An ActiveX is using ‘Internal Tags’ of WinCC. If you want to send data inside of an ActiveX, you create an internal tag and assign it to the one of the properties of ActiveX.

With Internal tags, I was successful to get data from PLC to my ActiveX, however I realised the major problem when I finished developing my ActiveX, and it was not possible to send data from ActiveX to WinCC (so PLC)

It was not possible to send by properties, because assigning ActiveX property to an internal tag was working one way only. There was not any ‘direction’ option.

Then I tried to send data by triggering ActiveX events, it was possible to trigger events of ActiveX but it was not possible to send some data by parameters of event.

So I decided to use ActiveX events as digital outputs, I have used them without sending any parameters.

For Boolean data, triggering was not a problem; I have created 2 events for each Boolean output and altered a Boolean internal tag on those events.

My final challenge was sending an integer code to a test device. Boolean outputs were easy but of course it is not convenient to create 255 events for a byte value.

So I created following events for sending byte information to WinCC:

ResetByte()
SetBit_0()
SetBit_1()
SetBit_2()
SetBit_3()
SetBit_4()
SetBit_5()
SetBit_6()
SetBit_7()
ByteReady()

Created a dummy internal tag and wrote single line scripts for each event:

Sub ResetDummy
tgDummy = 0
End Sub

Sub SetDummy_0
tgDummy = tgDummy + 1
End Sub

Sub SetDummy_1
tgDummy = tgDummy + 2
End Sub

Sub SetDummy_2
tgDummy = tgDummy + 4
End Sub

Sub SetDummy_3
tgDummy = tgDummy + 8
End Sub

Sub SetDummy_4
tgDummy = tgDummy + 16
End Sub

Sub SetDummy_5
tgDummy = tgDummy + 32
End Sub

Sub SetDummy_6
tgDummy = tgDummy + 64
End Sub

Sub SetDummy_7
tgDummy = tgDummy + 128
End Sub
And finally, for ByteReady() event I have write the following code for sending output to PLC:

Sub SetByteOutput()
tgByteOutput = tgDummy
End Sub

As an example, if I want to send code 120 to the test device, I convert its value to binary:

120 decimal = 0111 1000 Binary.

And triggered following events consequently:

ResetByte()
SetBit_3()
SetBit_4()
SetBit_5()
SetBit_6()
ByteReady()

Conclusions: In my opinion, WinCC Flexible is giant software, occupies gigabytes of space in hard disk but does not worth its price. Its tools are a little bit limited and it is difficult to do following tasks:

- Query some value from database and make decisions according to records from database.
- Serial or Ethernet communications with any devices other than SIEMENS.
- Third party ActiveX, WinCC does not have any guarantee for third party ActiveX.

And WinCC Flexible is only convenient if you:

- Don’t have experience on programming
- Use WinCC as only HMI
- Don’t need complex operations controlled by PC
- Have patience and high budget at the same time.

Importance of State Analysis In Automation Systems - - Part 2

2009-05-16T16:15:00.002+03:00

Here is the second part of state analysis. In this post, we are making a state analysis for a simple single station for both PC and PLC.

Importance Of Sa P2

View more presentations from moosty.

Importance of State Analysis In Automation Systems - Part 1

2009-03-15T00:43:00.002+02:00

One of the major problems in PC supported automation systems is deadlock problem.

Sometimes, systems fall into a deadlock, making it impossible to free up without intervention or you can miss your products without recording their information into database.

In this post, I want to give a poor design sample which may cause a deadlock with a presentation.

Next post, we will make a state analysis for a single task station.

Deadlock situation and missed products

View more presentations from moosty.

Case Study: Power Measurement System with Accurate Timing

2009-01-21T21:11:00.000+02:00

In this post, I want to talk about a power measurement test system that tests an electrical device.

Our customer is producing a household appliance which has a boot up sequence. In this sequence, device drives its internal components in certain time intervals which makes it possible to test if connections are done properly. So, each products have a power consumption graphic as below:

This graphic can be considered as a signature for products, many products have similar graphic with different level of power consumptions in different time intervals.

I can summarize customer requests as below:

Test parameters should be defined by a web page.

Test system should produce a test result code which can define each components test status such as 'heater is under it's low limit and fan is over it's high limit'. And of course, it should be reported on the web.

It is needed to store power consumption graphics for statistical calculations and it should be possible to report on a web page.

It is possible to apply power on the fly without an operator, customer does not want any operator except test parameter management.

Defected products should be diverted automatically to the defected area.

Project requires web reporting, web reporting requires DB interaction, DB interaction requires PC.

Project requires measurement with accurate timing, however PC can not do this properly because of its instability. It was necessary to take samples in each 100 milliseconds. Sure PC can handle this speed but it may not be possible to this in exactly 100 milliseconds. Well, sure it is possible but it is just a little bit difficult to do it, not easy for a formerly PLC programmer. It can be done with multimedia programming techniques, recording a voice in 44 kHz is a similar but much more difficult task.

If you only have a hammer, you always consider that all problems are nail, so we decided to do it with PLC.

We decided to measure with PLC and buffer the results in PLC memory.

Of course we could do it without wasting PLC data memory, PLC could send data to PC in every 100 milliseconds, and it is very easy to handle it in PC, you can do it by RS232 or Ethernet, does not matter. Both of them triggers an event in PC which breaks existing program flow. However, we should also make a handshake between PC and PLC, because customer wanted products to be automatically diverted defected products, and PC has the answer.

How did we manage the buffer in PLC?

We continuously copied analog data to the beginning of memory buffer. We only copied 'FFFF' value once as the test started. Then used 'SHIFT' command in PLC.

So the result was as follows:

In PC, we have polled the memory buffer continuously and searched for the first 'FFFF'. When found, copied them in another array in reverse order.

So we were sure that analog sampling was done in 100 milliseconds.

Another alternative for using 'FFFF' was incrementing one counter in every shift to determine the starting point of the shift, but using 'FFFF' technique required less coding in PLC.

PC Stability

2008-12-20T00:34:00.000+02:00

My graduation thesis was about designing a smart card reader / writer circuit and making necessary software development for it. I have tried to design a low cost reader, so I decided to use parallel port of PC instead of using a micro controller.

My advisor encouraged me to develop the software in Linux, that is the story of 'How I met your Linux'. My first experience on linux was on Mandrake Linux 8.

One day, I have wondered how stable was the PC, and decided to make a little test. I have wrote a small software in C and compiled with GCC to produce square wave with the highest frequency that PC can handle.

I have visualised the wave in oscilloscope. PC was able to produce square wave approximately at 200 kHz. Frequency was decreasing as the CPU was loaded, as I expected.

Then I wondered the result in Windows. Rebooted the PC with Windows 98, wrote an equivalent code in assembly and executed. I was expecting to have a little bit higher frequency because code was written in assembly.

Result was surprising for me, it was impossible to lock to the signal to display it on oscilloscope. Frequency was so unsteady that it was impossible to see with auto trigger or manual trigger.

Then I have tried to close some windows and terminated some background processes such as anti-virus. Frequency become more stable but it was still difficult to catch complete cycles more than five seconds. Finally, screen saver disturbed all the frequency.

I have measured the frequency with a frequency counter and it was nearly same as in Linux version, maximum 200 kHz.

Today, we are developing most of the automation projects on Windows operating system, so I wanted to make a small test before sending this post.

I wrote the following code:

---

Private Declare Function GetTickCount Lib "kernel32" () As Long

Private Sub Form_Load()

Dim i As Long

Dim j As Long

Dim StartTime As Long

Dim StartCount As Long

Open App.Path & "\Tick.csv" For Output As #1

For i = 1 To 1000

j = 0

StartCount = GetTickCount

Do While GetTickCount - StartCount < 20

j = j + 1

DoEvents

Loop

Print #1, j

Next i

End Sub

---

Executed the code with and without DoEvents line. DoEvents function gives a breath to CPU for executing other processes.

Results are as follows, I have also calculated the histograms. The first one is with 'DoEvents':

And the histogram is:

And without 'DoEvents':

And histogram:

Adding 'DoEvents' decreases the execution speed but increases the stability.

Graphics shows that you may not execute your code on time when you need it.

Windows XP is more stable than I expected. However it seems that timing is still a problem if you don't use multimedia programming techniques for precise timing.

In this test, you may realise one absence. I have intended to execute some amount of code in a certain time. But I have realised that time was not certain at all. I also intended to make one more test, I also have planned to measure the time to execute certain amount of code, however I have realised that GetTickCount functions resolution is not enough at all. I have realised that it returns multiple times of 16, not 1. I decied not to try to make the second experiment.

So I have suspections about the code above, I may have inaccurate measurements but it does not change the reality. PC is not stable enough if you are dealing with miliseconds.

Perhaps, many people think the 'mean time between failures' when I talk about stability, blue screen of death (http://en.wikipedia.org/wiki/Blue_Screen_of_Death) is another problem in PC based automation systems. I think the maximum up time of PC is the matter of sustainability, not stability.

Sustainability is another problem, I have searched a little about the GetTickCount function (http://en.wikipedia.org/wiki/GetTickCount). It gives the uptime of computer in miliseconds. It can work up to 2^32 milliseconds=49.71 days. I have never had a time to wait for, but possibly it will rise an 'overflow run time error' if not handled properly. This means that if you use GetTickCount function in your applications, you may need to restart your computer at most 49 days.

In next post, I am going to tell about a power measurement system as a case study. Our customer was producing electrical devices which have a boot up sequence. During boot up, devices were driving their internal electrical components one by one in certain amounts of time, which makes it possible to test some components by measuring the power consumption.

Customer requested to manage all test parameters over a web page, and also wanted to see reports of test results in web pages, making us to use PC. We were going to handle miliseconds with a PC.

Object Oriented Design in Industrial Automation - Example

2008-12-01T03:11:00.002+02:00

When I was a PLC programmer, object oriented programming was an unknown concept for me. I did not mind about it since I have become a PC programmer.

In this post, I would like to talk about some benefits of object oriented programming with a simple case study.

An object is described as a computer representation of an existing real world thing or event. Object orinted programming languages gives the opportunity of dealing with these virtual objects, however if you don't design your system as 'object oriented', you can't use the benefits of object oriented approach.

Many PLC programmers have their programming library, most of the times they 'copy and paste' their rungs from previous or existing projects in to the new projects.

"DRY - Don't repeat yourself" philosophy is against for information duplication because duplication may increase the difficulty of change and decrease inconsistency. So, DRY philosophy should be agains 'copy and paste'.

Object oriented design helps you to not to repeat yourself.

Before giving an example, I would like to tell some concepts in object oriented programming, first concept is 'class'.

Class can be considered as a set of objects, and classes are also objects too. For example, a book can be considered as a class made up of multiple page objects. There are some properties of the book such as page count or colour. Also, there are some possible actions can be done with a book, such as reading, or placing on a shelf.
However, in programming classes are not object at all. They are definitons of object and its properties. With this point of view, a class can be considered just as a cookie cutter.

Once you design a cookie cutter, and you produce many cookies with it. The disadvantage of object oriented design can be seen here, if you are going to make only one or two cookies, building a cookie cutter is not convenient. But if you want to make dozens of cookies, a cookie cutter may be a good idea.

It is also possible to extend capabilities or properties of a class and make a superior class. For example, a dictionary is a special book that you can search words in it. So we can talk about the class 'dictionary' which can be derrived from class 'book'. All the actions can be done with a book is still valid with a dictionary, we can read it or place it on a shelf. This is inheritance, which aids reuse of code.

When you read a book, you don't mind how that book was written or how that book was published. You only see the pages of the book which can be considered as 'interface'. This is the principal of information hiding and mostly named as encapsulation.
Information hiding principle has two advantages:
- Programmer does not need to be so experienced
- It is difficult to corrupt the object, because its internal structure is protected

Let's back to our 'book' object. We are able to read books including dictionaries, almanacs, novels etc. Reading action can work on many different types of books. This is called polymorphism. You can ask many different objects to perform the same action.

Before starting to an example on real world of automation, let's revise the concepts we told about:
- Object
- Class
- Inheritance
- Encapsulation
- Polymorphism

Because we are going to check if it is possible to apply them in automation systems design.

A multiple rack store system is a common structure. Mostly, two or more shuttles are used to put or take goods. FIFO can be achieved by this system, and sometimes one of the racks runs in reverse direction to make it possible to take out a good in the middle of the rack.
Well, I think this system is common, becase I have seen at least five and they were used for different purposes such as automatic storage and retrieval system or quality assurance test system.
Anyway, we are going to model such a system below:

Eight racks with two shuttles, one rack is working in reverse direction. The shuttle on the right is used for loading, and the other is used for unloading.

It is possible to store up to 128 boxes in this storage area.

We want to built a virtual model of the real world, we are going to start by finding out the objects in this system.

It is not too difficult, the first object is conveyor. Our conveyors are driven by a motor, and a conveyor can store two boxes. Each conveyor conducts the boxes forward if next conveyor is available:

Our second object is shuttle. There are two shuttles and each shuttle can give and take boxes in reverse or forward direction.

Our third object is a little bit hidden. Racks are also objects, and they consist of conveyors.

Now, let's focus on our objects capabilities. For example, each conveyor can conduct a box from one conveyor to the next one. Also, each conveyor take boxes.
Many PLC programmers use at least two output flags to give information to the next conveyors code:
1 - I am ready to give
2 - I am giving

and use at least two input flags to give information from previous conveyors code:
1 - I am ready to take
2 - I am taking

Logic is easy, if target conveyor is ready to take and source conveyor is ready to give, box should move to the next conveyor.

We can think about two more objects on the basic conveyor object: a transmitter and a receiver. Of course, these are not real objects, just functionalities but thinking them as seperate objects will be convenient for us.
It is obvious that, transmitter object has 'Transmit' method, and receiver object has 'Receive' method. By designing them as methods, we won't involve in handshaking between two conveyors, remember the encapsulation.

Most object oriented PC programming languages present a notation for objects and methods as follows:
Transmitter.Transmit()
Receiver.Receive()

And these two objects are belong to a conveyor object, so in programming notation, it also can be presented as:
Rack.Transmitter.Transmit()
Rack.Receiver.Receive()

If you realise an inconsistency or a bug in your logic, you do not need to code for all conveyors, just change the transmit or receive method and all objects using these methods will be get changed. Maintenance of object oriented code is easy.

And what about shuttles? Shuttles are also conveyors and also should have transmitter and receiver. So, to transfer a box from shuttle to a conveyor, we should be able to write as:
Shuttle.Transmitter.Transmit()
Rack.Receiver.Receive()

However, shutles have one more fuınctionality, they can move in Y direction to travel between racks, so we can think for a move method for shuttle:
Shuttle.MoveY()

Our another object is rack. A rack is made up of 8 conveyors. Rack can take boxes from shuttle and give boxes to another shuttle. It seems hat we can directly map the rearmost conveyors receive method as racks receive methods and map the farthermost conveyors transmit method as racks transmit method. Mapping is done once, and programmer can use it as:
Rack.Transmit()
without minding that it is actually:
FarthermostConveyor.Transmit()

Many experienced programmers realise one more object: Eight racks form another big object, the 'layer'. Programmers must anticipate that system may be upgraded to a multilayer stock system in next years.

And the final object is the system itself, having several methods such as:
System.Store()
System.Retrieve()

It would be nice to retrieve a box of chocolates just by executing a single command:
System.Retrieve("The yummy one")

Conclusions:
PLC programmers are working with objects for many years, each conveyor, machine, system is an object. Object oriented design and object oriented programming are different concepts.
In our example, we designed our system in object oriented approach but could not give example with rungs. Actually, object oriented PC programming languages present tools and facilities to implement an object oriented system as a code, however the code running at the back is not so different from procedural programming

For example, in object oriented way, you create a Shuttle class. Then you create a specific shuttle object, such as 'InputShuttle'.

You do it as:
____________
Class Shuttle
Method MoveY()
...
...
End Class

Dim InputShuttle As Shuttle
...

InputShuttle.MoveY
__________

And in procedural way, you write a function for moving any shuttle, and state the shuttle to be moved as a function parameter:
__________
Function MoveY(Shuttle As TShuttle)
...
End Function

Dim InputShuttle As Shuttle
...

MoveY(InputShuttle)
...
_____________

With this point of view, function blocks can be used in procedural way.

PLC software development environments and languages does not supply neccessary support for object oriented programming, however you can still design your system in abject oriented approach to recude the amount of code you wrote.

I hope, PLC vendors intruduce new functionalities to their development tools for supporting object oriented programming.

For the next post, I am planning to post something about PC stability. Then I am planning to post a case study, 'Power measurement test system - Beating the speed limits'

Object Oriented Design in Industrial Automation

2008-11-23T14:29:00.000+02:00

Object Oriented Programming (OOP) is supported by many PC programming languages.

How about PLC programming systems? Do you think that object oriented programming is possible for industrial automation systems?

Some automation gurus say that 'object oriented programming is for only programs, an automation system is not a program; may have a program but it is not a program, it is not a desktop application. So automation systems can not be object oriented'

And some gurus say that 'we are already designing in object oriented for many years, before it applied to PC programming'

What do you think?

I will be glad if you write some comments before starting a new post series. Should I define and describe the basics of object oriented design? Or directly run in to a case study of 'object oriented design in an automation system?'

INDAFINS - OMRON Fins OCX

2008-11-18T21:32:00.004+02:00

--------------------------------------------------------
05.12.2009 21:05

INDAFINS sources are uploaded to

http://groups.google.com/group/indanotes/web/OCX.zip

I was planning to publish all source codes by releasing beta version. (INDAFINS is still alpha version).

Unfortunately I don't have too much time to upgrade it. So I have decied to publish source codes of alpha version.

And also I was planning to upgrade INDAFINS as INDAFINS.Net for .Net environment after adding several more functionalities:
- Serial port support
- Read / Write I/O and timers, etc.

Please feel free to modify it,but I have several petitions:
- Please do not remove any links and information about indanotes.blogspot.com and this post.
- Please keep existing comments.
- Please add your name to source code as a comment if you modify it, and send to me to publish new versions here. I promise, I will keep your name also in this historical post.

--------------------------------------------------------
26.11.2008 00:35

I have released the documentation. I also realized that bad naming on source codes and fixed them.

You can download them from

http://code.google.com/p/indafins/downloads/list

--------------------------------------------------------
19.11.2008 13:32

Google rocks! I decided to host the project at google code instead of sourceforge.

You can download the setup files from

http://code.google.com/p/indafins/downloads/list

Setup file contains the ActiveX and a tester. I am going to publish the source codes soon.

---------------------------------------------------------
18.11.2008

An ActiveX controller 'INDAFINS' for OMRON FINS protocol is going to be published.

This posts address will be a permanent link, I am planning to edit this post on each version release.

It is still in alpha version and supporting only read & write data memories and extended memory banks over ethernet UDP.

I am planning to cover at least %90 of FINS protocol. Also I am planning to give FINS over RS 232 in the same ActiveX, so it should be very easy to change an applications communication method just only chancing one single line in a project.

Unfortunately, there is no documentation yet, I am planning to write a draft document as soon as possible.

However, when you are using this ActiveX, please:
- Use it by your own risk, it is not a commertial product. Just a freeware.
- Never place an emergency stop function on your PC applications, PC devices and communications are not stable, you may not stop the system in case of emergency.
- New warnings about INDAFINS can be added to this blog, it would be better to subscribe to RSS feed of this blog to be get informed.

I was planing to publish this ActiveX controller as an open source project in www.sourceforge.net, however I need to study more on CVS to publish on SourceForge.

I am going to find a reliable download host other than rapidshare, I would be glad if someone can offer me a good link.

Operation Times Reporting In an Assembly Line - DB Application

2008-11-15T14:09:00.001+02:00

Operation Times Reporting In an Assembly Line - DB Application

In our previous post, we have studied on data collection. In this post, we are going to study on database design.

Let's remember, we were going to deal with more than 30 million records annually in a database, and we were seeking a way to handle it without throttling the database server.

Let's remember what our customer needed:

Operation times distribution as an histogram : Calculating an histogram may be a little bit difficult. We should prefer to display reports which are easily derived with SQL sentences. And displaying 70 stations histogram in a single page may not help to understand bottlenecks.

The box plot graphics seemed the best alternative for histogram. It includes basic information from histogram:

and can present all stations graph in a single page:

Pictures are taken from wiki pages, unfortunately I can't publish samples from customers reports.

Idle time to find out bottle necks: For idle time, less is better. So, what about displaying them with a colourful background? Report data is simple, will just include two rows, 'Station name' for first row and average idle time for the second row. It would be nice to change proportionally the background of the cell for idle time according to idle time. If smaller values are better, we can display minimum idle time in totally green, and maximum idle time in totally red. And the others may be proportionally colourized in a gradient:

Station 3 is totally red, so customer can easily understand the most unbalanced station is the third one and can give more operations to station 3.

Also a box plot report should be fine for idle times to see more details.

Efficiency of stations : There are loops in the assembly line and those loops are used for fine tuning of some products if necessary. Because of those fine tuning operations, some products visits same stations more than once and this decreases efficiency of course.

So, customer wanted an efficiency calculation of station x as follows:

Efficiency of x = 100 x (Total products produced by last station / products produced by station x)

A gradient colourized report fits for this need.

Transfer times: Customer wants to see how mechanical movements between stations limit the productivity. Box plot fits better.

Now, lets see the structure that we can get by PLC:

Nearly, 2 or 3 records in a second.

We decided to store them in database in two steps. At first step, we appended all records in to a text file and gave a name ending with date and hour, e.g.

LogFile08_11_15_13.dat

which includes all detailed information between 13:00:00 and 13:59:59

Next file name should be LogFile08_11_15_14.dat.

Then we developed an application for summarising the detailed data file for database, and inserting them into database. It was a scheduled task to run for every hour, summarising the data, inserting the summary records into database and finally copying the detailed data file into a zipped archive file.

And the summary included following fields:

Station number
Date
Hour
Number of products
Minimum of T1
Maximum of T1
Q1 of T1
Q3 of T1
Median of T1
Average of T1
Standard deviation of T1
And same calculations same as T1 for T2 and T3 time intervals.

Our database transaction seriously decreased from approximately 8500 records to 70 records hourly.

And overall cost of the project was not too much:

Half a day for PLC software modification
Quarter of a day for PC software development
Quarter of a day for PC summarising task application
One day for report web pages

However, customer was angry with us because the project was too easy and cheap to be as a default feature of the assembly line. What can I say, customer is always right. I am planning to add this system as a default feature if someone orders us an assembly line again.

Operation Times Reporting In an Assembly Line

2008-11-12T12:11:00.001+02:00

In our previous post, I have told about a customers request for reporting operation times of stations in their assembly line.

They were going to use it for assembly line balancing

Many readers may think that 'well, assembly line balancing should be done before establishing the assembly line', you are right.

But our customers assembly line was producing mixed products, I mean there could be several types of product at the same time. In the other hand they had too many types of product, and new types of products were being developed by their R&D department.

If you want to see the performance of stations in your assembly line, what would you like to have in your reports?

I would like to see the operation times distribution as an histogram.
I would like to see the idle time to find out bottle necks.
I would like to see the efficiency of stations.
I would like to see how mechanical movements limit my productivity

We had a budget limited with only software change, customer did not wanted to add any extra devices or operations on assembly line.

Let's consider our scenario with a single station:

Station is free.
New product comes from previous station
Operator starts working on product.
Operator pushes the 'operation complete' button to send the product.
Product waits if the next station is busy.
Product moves to the next station when the next station is free.
Station becomes free.

What we have as hardware:

Product complete button
Product presence sensor
A buzzer to warn the operator on exceeding the cycle time

Customer has approximately 70 stations, designed system should be flexible to add new stations.

We had to design the system for both convenient for PC and PLC software development.

First we discussed about storing the measured operation times in PLC, then transfer to PC. Not so convenient. There were more than 70 stations, meaning 70 more timers or counters in PLC. For our project it was impossible without PLC upgrade.

And not only operation times of course, we had to think about transfer times and idle times also. It was impossible with customers existing PLC system.

And making necessary software changes in PLC should take at least one week.

So we decided to copy only hardware inputs from PLC to PC. Solving the problem in PC was more convenient.

In PLC, we made two flags:

Product presence flag, which is directly connected to product presence sensor, set to “1” if station is occupied with a product and reset to “0” when station is free.

Operation complete flag, which is set to “1” when operator pushes to the operation complete button and resets to “0” when product leaves the station.

Let's draw a timing diagram, this is not an handshake, just a timing diagram for two flags:

T1,T2 and T3 shows only one products timing. TA,TB and TC is the next products timing.
Normally T1, T2 and T3 corresponds with TA, TB and TC respectively.

T1 is the time interval that the station is free, however a new product may be on the way.
T2 is exactly the operation time which spend for assembly operations.
T3 is the idle time, where all assembly operations are completed and product is waiting for the next station to become free.

T2 and T3 were the exactly time intervals we would like to see. But, what about transfer time? We also needed to report transfer times.

For an exact transfer time calculation, we have to measure the time between our stations product presence flag and next stations product presence flags rising edge.

However, it is just a little bit difficult because to do this, we also have to consider order of stations to know which station follows which. It was difficult to manage because assembly line was not straight, there were branches and loops.

So we decided to accept that TA as a transfer time.

Why not T1? Also T1 was possible, but we considered that PC is an unstable device, may be frozen or application may hang. So PC software may be restarted anywhere in the cycle and measure time intervals as shorter than it is. We wanted PC to record clear measurements only.

In PLC software, we had represented the flags as bits in a byte, so a single byte stored 4 stations information.

For 70 stations, 18 bytes were enough. PC was going to read 18 bytes from PLC and was going to write 9 bytes for buzzer alarm.

In PC, we have considered all stations as an array, just wrote few lines of code for one station and applied to all stations in a For..Next loop.

Overall code except 'Read all inputs' and 'write all inputs' took less than 100 lines of codes.

Data was collected successfully.

For our next post, I am planning to tell you about the database structure and web page reporting of this project. We had some limitations in DB.

I think may people guessed our problem, there were 70 stations meaning that each product will produce at least (at least because there were some loops in assembly line) 70 records in database.

One shift was producing approximately 600 products.

There were three shifts daily.

Working 5 days in a week.

Working nearly 50 weeks in a year.

So we were expecting:

70 x 600 x 3 x 5 x 50 = 31 500 000

more than 30 million records.

And customer was planning to apply the project to their second assembly line if project not fails.

More than 60 million records. So huge that consumes too much CPU in database server and possibly may slow down other applications.

For the next post, we are going to focus on database design and some statistics.

Customer is always right and sometimes undefined

2008-11-10T11:04:00.003+02:00

You may remember the cartoon about ‘IT Project Management’

This is a great similitude and fits for most IT projects.

In this post, I would like to tell you about a project of mine which is different at the beginning.

Normally customers may request features that are contradictional, those contradictions are eliminated during project design in co ordinance with customer.

One of our customers requested us a project. It was a modification on an existing assembly line which was developed by our team.

Let’s see how our customer described the request:

“We need to see cycle times of all stations on a web page, and also want to warn the operator on exceeding the cycle time.”

That’s all? No.

“We have a limited budget and don’t want to spend too much money and don’t want operators to do extra operations for reporting cycle times.”

Yes, that’s all. I just imagined the cartoon below:

On the left, how most of the customers explain their request. And on the right, my customer.

A warning light lit in my mind, it may be risky without handshaking clearly. Something was wrong.

So I asked:

“What do you want to get by reporting cycle times?”

The answer was:

“For line balancing of course”

Well, no more information. Just all, we had to guess what customer is really requesting.

First of all, “cycle times of all stations” was cloudily, because assembly lines don’t have distinct cycle times. Assembly lines have an average cycle time during a time interval, and that is calculated as:

Cycle Time = (Total time spent [e.g. in a shift]) / (Total number of products)

It’s the average time needed to produce one product, and it is same for all stations because all stations are cascaded to each other.

So, probably the customer was mentioning “operation times” actually. Now it was clearer, probably customer wanted to see “how their assembly line balanced, and how efficiently working”

Even customer did not request clearly, they should need the following reports:

- Where are bottlenecks? (To consider dividing station or sharing some operations between neighbor stations)

- Where are the most inefficient stations? (This is different than bottleneck. Some stations may cause scrap and it is possible to detect if any station is producing more products than final stations output.

In most cases, data collecting terminals are placed on assembly lines to collect number of products and operation times, but ,in this project customer did not want to add anything.

Customer also did not wanted the answer of question “why my assembly line stopped in a certain time interval”

We had approximately 70 stations with operators. Operators have pushbuttons to send the product to next station. We were going to take necessary information from this buttons and existing sensors.

As you see, some customers may have contradictional requests, and some have none.

We are going to start to a new series of a case study, collecting operation times from assembly line. We are going to tell about how to analyze the project and how to design.

I would be glad if you comment on this post, especially what would you like to see in the case study.

Simple PC – PLC Communications Part V - Expect The Unexpected

2008-11-08T01:20:00.003+02:00

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:

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.
Restore all global variables on start up.
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

MsgBox Data

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

Data = 5

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?

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.
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.

Simple PC – PLC Communications Part IV - Evaluation Code Sample

2008-11-06T03:19:00.004+02:00

In this post, I would like to give a simple pseudo code for managing time intervals, how to switch them between. Remember that following code is belong to 'Evaluate' function which is stated in second post and executing in a continious loop:

Global TimeInterval

Function Evaluate()

Select Case TimeInterval

Case "T1"

If PLC_Read.Request = True

TimeInterval = "T2"

End If

Case "T2"

RecordData()

TimeInterval = "T3"

PLC_Write.Response = True

Case "T3"

If PLC_Read.Request = False Then

TimeInterval = "T4"

End If

Case "T4"

TimeInterval = "T1"

PLC_Write.Response = False

End Select

End Function

However, it is just a sample, it is possible to simplify this code into less steps. For example it is possible to insert into database and then switch into last step according to read data from PLC.

For next post, we are going to give some tips about managing steps and increasing immunity against deadlocks may be caused by power loss and operators unwanted, unexpected behaviours.

Simple PC – PLC Communications Part III – Signals with animation

2008-11-02T22:23:00.003+02:00

A presentation may explain lots of things than words:

Simple PC - PLC communications Presentation

View SlideShare presentation or Upload your own. (tags: communication plc)

Simple PC – PLC Communications Part II – A Case Study for Product Traceability

2008-11-01T01:19:00.002+02:00

In our previous post we examined a simple application structure for basic PC – PLC communication.

In this post, we are going to focus on 'evaluate' part of the algorithm.

It is better to focus on evaluation in a case study, assume that we have three consecutive stations in an assembly line as follows:

Assume that each station is driven by distinct motors. We are going to study on Station Y.

If we are studying on a case, we need a scenario. Assume that we have an operator, say 'Mike', on assembly line.

Mike is working on Station Y and he is responsible for checking if boxes are good or not. He has two push buttons, one red and one green. He presses green button for good boxes and presses red for defected. Boxes come from Station X, and left Station Y towards Station Z after Mike's decision.

We also have a barcode reader on Station Y which is directly connected to PLC. A bar code reader connected to a PC requires a little trick that we are going to discuss later.

With Mike and other components, our system should seem as:

Now our goal is collecting information from boxes and matching them with their quality status.

Finally, we want a data table in our PC as follows:

Date Time	Barcode Data	Station	Quality Status
10.10.2008 16:18:30	8463952819456	Station Y	OK
10.10.2008 16:19:02	8392753021983	Station Y	NOK
...	...	...	...

We can derive several reports with this data, we can use pivot charts to see summary, or we can develop a web page to present our data, it is not in this scope of this post.

When we think over scenario we see that events should happen step by step:

A new box arrives on Station Y

Barcode reader scans the barcode (Assuming that it never fails)

Mike pushes a button

Data is recorded

Box leaves Station Y and moves to Station X

Following informations can be supplied by PLC:

Product presence on station

Scanned barcode data

Which button is pushed

PC can only supply one information:

Confirmation of record created successfully.

We need to exchange information between PC and PLC and we must do it with a handshake protocol.

This handshake protocol is not the one used for PC – PLC communication. For example, it is not FINS protocol of Omron or it is not Modbus protocol.

We are already reading a part of PLC data memory and filling another part continuously with an endless loop, I mean we need a safe method to manage information carried by physical PC – PLC communication.

Following diagram is a sample protocol that can be used for our case:

Information exchange done in four steps.

Our next post we will continue on the same case study.

We are going to discuss:

What happens in T1, T2, T3 and T4 intervals ?

How can we organise internal structure of evaluation algorithm ?

Few tips about design

See you in next post!

Simple PC - PLC Communications Part I

2008-10-30T22:30:00.006+02:00

A simple PC application structure that communicates to PLC

In most cases PLC is enough to solve automation tasks with its programming interface and special designed architecture.

However, it is not always possible to solve all problems such as database support. Some PLC brands have command sets supporting table search but it is not intended for complex operations.

In this post, we will focus on a PC application that supports PLC by exchanging data.

Most common PC – PLC communication methods are RS 232 and Ethernet, they do not differ in
basic software structure, so you can apply this structure for both RS232 and Ethernet communications. Also it is possible to use parallel hardware I/O cards on PC for communication, the same structure also fits for I/O cards.

The most convenient way for communicating is continuously exchanging snapshots of memory areas between PC and PLC.

Actually, all PLC systems do the same thing at the background:

Reading inputs, evaluating them to calculate necessary outputs and writing outputs continuously in a loop.

If we adopt this to a PC application, same algorithm could be as follows:

This structure simplifies PC evaluation algorithm.

Next post is going to be a simple case study, we will design a station that gives feedback to PC for
recording a products information to maintain traceability.

First Post

2008-10-29T14:37:00.003+02:00

This is the very first post, I hope we will share lots of experience in this blog.

I am an automation engineer and using PC for many industrial automation problems.

In da notes stands for 'Industrial Automation Notes' and I am planning to publish some of my experiences as case studies in this blog. As I said, my favourite tool is PC for automation, so probably you will find more tips and trics with PC.

However, automation without PLC is impossible, for that reason this blog will contain example applications with PC and PLC.

If you are also an automation guy, you should be so busy and can understand me if I can't feed this blog so frequently. All experiences from readers are wellcome.

I am planning to post tutorials from simple to complex, this structure requires references links to older posts. Probably my second post will be about simple PC - PLC communication basics.

I offer you to subscribe this blog to be informed on new posts because I may not feed so frequently. Unfortunately you may fed up checking this blog without any new posts, so it should be better to subscribe.

See you in next post !