-
Notifications
You must be signed in to change notification settings - Fork 5
Desktop wiki
- [sensor 1, position] (http://128.178.5.201:8080/s1.html)
- [sensor 2, video] (http://128.178.5.201:8080/s2.html)
- [actuator 1, set postion] (http://128.178.5.201:8080/a1.html)
The figures below are LabVIEW pseudo code. For clarity reasons most of code has been remove.
Figure 1. shows the global architecture of the LabVIEW smart device package. The first part (1) initialize the server and launch the workers (autonomous threads that wlll do the work, i.e. handling the transmission with the clients) Then listeners (2) that will receive the client connections are instantiated. (3) When a connection is received it is validated and checked in (4) theses tests allows the implementation of mechanisms to avoid flooding, redirection, etc. When the connection is validated it is passed to one of the available worker (4). The number of worker is dynamical. With the current setting we successfully handled 50 concurrents connections for streaming video via websocket. The worker (5) “links” the client with the hardware (6), its internal process is explained below. There is another thread that handle the GUI.
Fig. 1 The LabVIEW smart device package main architecture
The LabVIEW smart device package is an high multithreaded server that exchanges information through Queues. There is for example a queue that manages acquired data and makes it available to worker.
Fig. 2 Hardware thread that enqueue the acquired data
Similarly information coming from workers can be retrieved and sent through other threads via queues.
Fig. 3 Decoding thread that handle user sent value for an actuator named “slider0”
Once the worker receive a connection to handle, it will first answer the browser websocket challenge (1) then the connection between the server and the browser is really established. Then every information received by the worked is decoded and enqueued in the specified queue (3 - read) and concurrently when data has to be sent to the client via websocket it is dequeue from the specified queue, encoded as websocket and finally sent to the client (3- write). When the connection is closed the worker go back in its initial state waiting for another request to handle.
Fig. 4 Worker internal
A regular web request is handle similarly by the worker. It is only simpler, the relative code is not shown in Fig. 4
The Figure 5 shows how the link between the different queues is made through the configuration VI. Is also shows how a simple HTML code can be defined.
Fig. 5 The LabVIEW smart device package configuration
A lab owner will have to first implement the needed threat to access the hardware (Fig.2). He/she will also have to validate the client command prior to apply it to the hardware (Fig.3) He/she may also need to add the needed logic to control his/her physical equipment. Once this is completed He/she needs to link the various queues in the configuration VI and at the same time write the metadata JSON replies as well as any other HTML reply He/she may want to serve.