Introduction

A Data Server Implemented in LabVIEW

A Data Client Implemented in LabVIEW

       Data servers are much like the servers that serve up web pages.  Let's look at some examples.

• Let's say that you have recently purchased 200 shares of XYZ corp, and you want to check the current price of your stock.  (And, just for the record, we tried to get a price fo XYZ - stock symbol - and they couldn't find any record of such a symbol for a company.  Remember, it's just an example.)  Anyhow, you log on to a web page, and you get the price of the stock.  Even better, without you doing anything (like hitting the refresh button), the price gets updated on a regular basis.
• Let's say that you are a fan of a baseball team.  (It might be the Toledo Mudhens, but they are in the minor leagues and we don't know if this service is available for them.)  You log on to a page that displays the score of today's game, and the score is updated after every batter.

        What happens in a data server
 

The browser breaks the URL into three parts:

   1. The protocol ("http")
   2. The server name ("www.howstuffworks.com")
   3. The file name ("web-server.htm")

      Here is a block diagram for a simple temperature server.

        We will examine the flow of information/actions in this vi to see how the server operates.

• We have encapsulated the GPIB reset function as a sub-vi.  That may be overkill since there is only one GPIB Write in the sub-vi.
• We have encapsulated the temperature function as a sub-vi.  This sub-vi has numerous functions including:
• Setting the measurement (DCV), and the scale.
• Taking the measurement.
• Bringing the measurement from the Hydra to the computer.  Note that the data coming from the measurement arrives as a string.

• The server runs two loops.  In the outer loop, the following is taken care of:
• The measurement system is initialized.  In the GPIB system that means you reset the instruments.  That is handled in the sub-vi discussed above.
• There is a TCP/IP listener.  That listener waits for a message from a remote computer indicating that the remote computer wants data.  In essence, the program is "hung" until that request arrives, and the second loop doesn't start operating until a request message arrives.  What actually happens is that the outer loop keeps running (as quickly as possible) checking to see if a request has arrived.
• When a request arrives:
• The request from the client must be directed to the correct IP address of the server (the "phone number") and the correct port (the "extension at that phone number").
• The request must contain the IP address of the client so that the server can send the data to the correct IP address.
• When a request has been received and a connection established, then - and only then - does the inner loop begin to operate.
• To service the request, the server must take a measurement - in the inner loop - and send the results.  The inner loop operates repeatedly at a specified time interval.
• Since measurement string length might be variable, the first thing that the server has to do is examine the string length and transmit a value for the string length.  If the string could be 9, 10, 11 or 12 characters long, it would be wise to send two bytes for the string length, i.e. "09", "10", "11", etc.
• In the diagram above, after doing the string length computation - which results in an integer number (the blue line) - the number is converted to a string, and the string is padded (with a space, if necessary) to a length of two.
• If the actual data string had 100 or more characters, then this would cause an error at the client because the conversion to an integer would expand to whatever length necessary, and the client would be expecting only two characters and would assume that the extra character was part of the data string - sent after the length is sent.
• After sending the string length - so that the client knows how much data to expect - the server needs to send the data string.
• The data manipulation for the above implies that the following happens in the server.
• The measurement yields a string.
• The length of the measurement string is computed - as a number.
• The length of the measurement string is changed to a string, padded as necessary, and sent as a two byte string to the client so that the client knows how much data to expect.
• The measurement string is sent by the server.
• The data manipulation for the above implies that the following happens in the client.
• The client - after initiating a "conversation" waits to receive two bytes (using a TCP/IP Read) that will tell the client how long the data string will be.
• The client gets a two-byte string and converts that to an integer.
• The integer is used to set a TCP/IP Read that will receive the number of bytes specified as a string.
• The data string received is converted to whatever format is appropriate.  For example, it might be converted to a numerical format to display on a thermometer gage.

        In the section above we considered what the data client would have to do.  The next question is how that might be implemented in LabVIEW.  The diagram below is a very simple client for the temperature data server.

Here is what happens in the data client.

• In the first TCP block a connection is opened.
• The connection is specified by the IP Address and the port number of the server.
• Both the IP address and the port number must be known in order to get the data.
• Once the connection is open, inside the loop a TCIP Read block waits for data.
• The first data received should be the number of bytes in the data string.
• The integer "2" at the input of the TCIP Read block indicates that the TCIP Read block waits for two bytes of data.
• The data received - the number of bytes in the data string - is converted to an integer and forms an input to the next TCIP Read block.  That particular input is the number of bytes that the second TCIP Read block should wait for in the data string.