Practical approach of using embedded controllers for virtual instrument over TCP/IP and 802.11 b/g protocols.

Risteiu, Mircea ; Ileana, Ioan ; Tulbure, Adrian 等

1. INTRODUCTION

We have started using LabVIEW implementation for wind energy evaluation taking into account the power of G-based programming language. Today's measurements for this kind of implementation are based on a data logger with GSM-based gateway for downloading data from the site measurements. This implementation is required for real time measurements.

The main requirement for using real time measurement around LabVIEW implementation was the demand for adding some environment monitoring parameters to the main wind energy parameters list (T. Savu, G. Savu, 2000). This aspect requested to mix together some heterogeneous parameters. The entire in-site implementation is powered by an optimized solar panel module. In our approach we use some sensors for typical measurements, as follow: temperature, wind speed; wind direction, noise level, stroboscopic effect and 2 axes vibrations; wind direction; wind speed sensor--anemometer; atmospheric pressure; humidity; temperature sensor attached on the metallic wind direction support; tilt sensor (this sensor includes vibration and temperature measurement parameters); solar radiation sensor.. In our approach, the data is sent to a computer through a wireless connection. The main advantage of this implementation is based on the fact that the TCP/IP- based reconfigurable controller allows us to organize a mobile and real time measuring system with remote control facilities. For such issue, we have access to buss controller and monitor, and remote terminal. A brief description of the reconfigurable controller we use here is focused on: embedded controller use 40MHz processor; 512 MB of Nonvolatile memory; real-time data transmission capabilities; local and remote working capability; configuration and programming accessibility by using the FPGA and Real-Time; the TCP/IP Ethernet interface.

For this embedded controller, there is used a measuring chassis with 2 x cRIO-9201/9221 modules. The cRIO9201/9221 returns uncalibrated, as binary data. It has to be calibrated and scaled in software side. The accuracy of the measurements with cRIO 9201 is proved in lab experiments, and is resumed in table 1.

To transmit all recorded environmental data from controller to a high level processing unit (PC-based) over a large distance (remotely) we implemented a wireless network for this purpose. The controller was directly connected to a Wireless Acces Point (WAP) and a 26dB antenna, via TCP/IP port. For extending wireless range we attached external antennas to WAP. With both 26 dB antennas we have got stable connection at 30 km distance. For the proposed application we use Wired Equivalency Privacy (WEP) general encryption protocol, that easily exploited by software that can break the encryption after capturing traffic and recognizing encryption patterns. We also used WAP 2 encryption method for dedicated situations, like local configuring session.

Hardware configuration (UTP port, measuring module, and other local facilities) is done through software assistance. We used MAX- controller dedicated software- to configure the Ethernet interface of controller, to assign an IP and a name to the device, in order to be able to work in the network. Then measuring modules are settled up with particular properties. For local configuring procedures, a 232 port with TPC device is also enabled. After this step is done we tested the connectivity and the link between all devices in the network (PING command). Then we are setting up first communication parameters (time delay of the measurements, level of radio signal, antennas positions) with Windows- based software on the host computer.

2. LABVIEW CONTROLLING APPLICATIONS

The most interesting and challenging part of the project was the designing of an application module in LabVIEW, for effectively display and manipulate the read data from all connected sensors. To do this, we needed to create a new Lab View project on a target device (in our case, cRIO named as "myRioK"). We created two VIs: one on FPGA Target and second on the REAL-TIME part. The first VI called "FPGA buf read 2.vi" on FPGA Target is reading the data from the channels of NI9221 and stores it into a FIFO for each channel (buffer). We used a FPGA I/O node to be able to read data (signals) from NI9221--cRIO.

Each "FIFO--read" has a numeric indicator where data is displayed, and the indicators are invoked in the second VI to manipulate the contained data (for the real-time mode). The second VI, named "Real time read-scalare 2.vi", is realized on the REAL-TIME part of the project and invokes the first VI and to be more precise, the four indicators (Element4, Element5, Element6, and Elementl) are used, and invoked as a VI reference object on FPGA Target. In this VI we made few mathematic calculations that are called calibrations which mean we used few linear transformations to adjust the displayed value to the real value. These kinds of sensors that we have used are not factory default scaled, so the values recorded and transmitted needs a linear transformation to display the real value. The general formula used (Zhang, W.; Branicky, M.S.;& Phillips, S.M., 2001) to scale the results is:

x = a x abs (S)/[2.sup.k] x [epsilon] (1)

Where:

x--Real displayed value on the application side;

a--Data read from remote channel;

+/- t--superior/ inferior module voltage limit;

S--Unsigned sum of 't';

[epsilon]--Error coefficient used for accuracy of scaling process

Depending on different used sensors and different signals, each channel might be scaled with different parameters.

It was attached to this VI (inside it) a loop timer to read data from cRIO only in specified time intervals (dynamic control). The reason of this approach is based on the fact that the speed of the FPGA is 40 MHz (250 ns) and it is useless to display so fast changes at the client side. An important aspect of measuring stage is the oscillation of the displayed value. That value is permanently changing in a small interval. The problem of the chaotic oscillation depends in high percent on what hardware is used. This means the FPGA controller frequency is responsible for this kind of oscillations and the reason is very simple; the FPGA makes a reading at 40 MHz that means at every 250 ns a reading is done and the human eye cannot distinguish the displayed values. The specified reading has certain accuracy and of course the error level of reading is included in an interval. The general idea is to create a VI on the FPGA part where the read data are put (or memorized) into an array using an I/O FPGA node and an array object (exactly how the data is read at 40 MHz), then in a VI on the Real-Time part the data stored in the array is taken, and using a "for" or "do...while" loop for every element in the array is calculated it's average value. The loop counts only 4000 elements, this represents all the readings made in 250 ms by FPGA controller. This algorithm can be changed or easily modified depending on what the user wants to do or to be displayed on the front panel.

3. TESTING DELAY MEASUREMENT IN SITUU

Next step of our implementation is focused on developing delay measuring setup for evaluation of the effects of wireless transmission for real time measurements. The block diagram of this experiment is shown in figure 1 (Risteiu, M.; Ileana, I.; &Tulbure, A., 2007). The assumption that the network can be described by a delay distribution implies that there is no correlation between consecutive packets sent over the network. The assumption holds if the packets are transmitted sufficiently far apart, so that the queue lengths have time to change between the packets. This is not the only requirement since the delay is usually also dependent on the utilization of the network and the utilization changes. To model a network with correlation, a Markov chain can be used. For this reason the repeatability of the data has to be ensured. For the proposed measurements we are using Visual Route (Windows based software that access DataLink layer on OSI model). Based on fixed conditions (Zhang, W.; Branicky, M.S.;& Phillips, S.M., 2001), first records with packet losses are shown in figure 2. The accuracy of the measurements is summarized in table 2. For our purpose, the measurements are valid (Zhang, W.; Branicky, M.S.;& Phillips, S.M. 2001), (Cabulea, L., 2003).

[FIGURE 1 OMITTED]

[FIGURE 2 OMITTED]

4. CONCLUSION

Real time measurements are challenging because of time delay and packet losses. It is necessary to built up on host computer individual configuration process. Using 802.11b/g protocol for UTP port asks for testing the delay of data sending session. We proved that 20 ms is actual limit delay, and over this limit another sending data session has to be designed.

5. REFERENCES

Cabulea, L., (2003), Procedee de aproximare in statistica si probabilitati (Approximation approaches in statistics and probabilities), Aeternitas Publishing House, 2003, ISBN 978-973-7942-84-2

Mikael Pohjola, (2006). PID Controller Design in Networked Control Systems, Helsinki University Of Technology Report, Issue 2, Department of Automation and Systems Technology, January 2006.

Risteiu, M.; Ileana, I.; &Tulbure, A. (2007). Integration of the Zigbee Smart Sensors in TCP/IP Infrastructure for Fast Enabling Remote Data Acquisition, Process Control 2007

T. Savu, G. Savu (2000). Tehnologii Asistate de Calculator (Computer Aided Technologies), Editura ALL, Bucuresti,

Zhang, W.; Branicky, M.S.;& Phillips, S.M. (2001), Stability of Networked Control Systems. IEEE Control Systems Magazine. Vol. 21, Issue 1, February 2001. ISSN: 0272-1708.

Tab. 1. Accuracy of measurements with cRIO 9201/9221

Error Percent of Percent of
 Reading Range *

 cRIO-9201/9221

Calibrated max (-40 to 70 [degrees]C) [+ or -]0.25% [+ or -]0.25%
Calibrated type (25 [degrees]C,
 [+ or -] 5 [degrees]C) [+ or -]0.04% [+ or -]0.07%
Uncalibrated max (-40, 70 [degrees]C) [+ or -]0.67% [+ or -]1.25%
Uncalibrated typ (25 [degrees]C,
 [+ or -]5 [degrees]C) [+ or -]0.26% [+ or -]0.46%

* Range equals 10.53 V for the cRIO-9201, 62.50 V for the
cRIO-9221