MicroControl:Design

communication

Basic communication between client and server is achieved by message passing over TCP. Each message is a five byte header followed by the message itself.

The header has two fields -

1. A single byte character which describes type of incoming chunk
   1. 'f' stands for a file (mostly image file)
   2. 'x' stands for an incoming XML (typically a compilation of scalar and vector values)
2. An unsigned long integer (4 bytes) describing the size of the incoming data

That means the image size is currently limited by the highest number that can be stored in unsigned long integer.

blocking and queuing =

If a new request is initiated while the TCP client is already waiting for the results from a previous request, blocking may occur. This typically results from request of image scan which may take long time. Also when the live view functionality is turned on, the client is always waiting for new images.

Blocking is handled by a queuing mechanism as follows. If GUI is making another request while the client is already in waiting mode, satXML sets up a queue and adds current request to it. The status is checked for every request made to satXML.

There is still a limitation that get and set requests are not mixed currently. That can be solved by using a separate queue for get and set requests.

Protocol description

<source lang="xml" style="display: inline-block;">

<satXML type=”response”>

 < scalars>
    <position x="1.3 " y="2.3"/>
    <scan speed=”3”>
 </scalars>
 
 <image fname="c:\neuron.png" size="326870"/>

</satXML> </source>

Live view functionality

While setting up stage and scan settings, users tweak hardware parameters while looking through the eyepiece. This practice must be followed even when the user is remotely adjusting hardware parameters.

Since visual basic runs in event driven mode, its possible on server.

Typically the user will invoke other client GUI functionality while the client continuously requests images from the client.

So at the moment when user invokes a GUI action to request some other communication with the uScope, the communication system may be

• "Not connected with uScope" - User is presented with a dialog that his request cannot be processed right now
• "In Waiting mode" - Different actions are taken depending on whether the wait is due to live update mode or otherwise. In case live update mode is on, there will be an additional communication coming up soon (to give interactive feel for the user) to get the data from the uScope, so the request can be queued and sent to uScope in the next update.

The remote client must also be multi-threaded now ready to receive images continuously updating the view window. And another communication with the server must consider possibility of this continuous interaction.

On server side, a global variable (which ?) is used to maintain the state whether continuous scan is required. Upon completion the current image is exported onto disc with a temporary filename (which ?) and a new XML response is created and is sent back to the client.

The XML handler should be processed while images are scanned. The continuous XML takes the control away from the default XML, hence it is necessary to assemble and return correct response. If non-returning satXMLControl function is called again and again, it might result into a stack overflow. But usually only once instance of continuous image generation will be accepted.

ProcessParent

Subwindow elements like panels etc can get handle of their top level window by function GetTopLevelParent(self). This is usually the main_window and has a method to process

1. Every dialog box must be set with a window handle "processParent". This can be either supplied to the constructor __init__ method, or later set explicitly. Th