Importance of State Analysis In Automation Systems - Part 1

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

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

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

   

 Close

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.