LabVIEW SVE Implemention (again)

Here are some more thoughts on LabVIEW SVE

Let's start by distinguishing the following levels:

LabVIEW Application
This is the user code (like ENVEX1 or the TCS simulator) which consists of SML devices that implement the business logic as German likes to call it.
In some of these (user) devices the user might want to interact with our shared variables system.

For that we have to provide a set of maybe 4 VI's the user can include (from the palette or whatever the standard LV method is). These VIs are the equivalent of a C library or a Python module.

I think we will need 4 VIs - I call them SVE VIs (or SV if you prefer)

a) Publish - Publish a variable to the SVE system
Input: Variable Name, Group Name, (Error In)
Output: Error

b) Subscribe
Input: Variable Name, Group Name, Callback, (Error In)
Output: Error

c) Write
Input: Variable Name, Group Name, Value (as a string - we make everybody flatten his value to a string), (Error In)
Output: Error

d) Read
Input: Variable Name, Group Name, (Error In)
Output: Value (as string), Time of update, isUpdated Flag (True is value was updated since last read), isAlive Flag (True if connection to SVE is operational), Error

Explanation:
Variable and Group Name specify the Shared Variable. This combination has to be unique systemwide.
Callback is based on a good idea from Jacob. When a user wants to receive a callback when a variable is updated he creates the appropriate command in one of his devices and passes the device name and command name as string to the callback input of the VI. The lvSVE.py script that we discuss later records that callback together with the variable and group names. When an update is received lvSVE.py issues a SML command via FROMPML to the labview device specified by callback with the command as an argument.

Time, isUpdated, isAlive provide additional information on the SV.

Functionality:
Each of these 4 VI's simply implements a SML sendCommand vi and passes the parameters including the command name to a new SML device that we provide. Let's call this device TOSVE.
TOSVE is a SML client device to the syntax of the SML command string will have a syntax close to this: TOSVE TX publish myVariable myGroup

To Do:
Code these 4 SVE VIs in LabVIEW

LabVIEW System
We have now reached the LabVIEW system level. This TOSVE device is a direct copy of the TOPML device with the only difference that it starts a different python script (lvSVE.py). Again we pass the IP address, port number and appname to the python script. The SML configuration files will get an extra entry to specify this new device and also a new [SRV] entry.

When TOSVE receives a command from any of the SVE VIs it simply forwards it (after removing the TOSVE TX part from the string) to the attached server which will be implemented by the lvSVE.py script. There is no local copy of the SV within this device so every read call goes to the python script and returns the value from there. All the SVE commands are of type question.

To Do:
Not much, just copy TOPML.vi and change the script name.

Python Level
The lvSVE.py script which is spawned by the TOSVE device during initialization is a slightly modified version of the fromSML_toPML script. It pretends to be a SML server and understands the SML protocol. But instead of using the strings it receives from TOSVE to make Pyro calls to PML devices it parses the text and extracts the command, the variable and group name and other parameters if applicable. It then simply calls the appropriate functions in the SVE client module and returns the results to TOSVE. For the subscribe command it records any call backs and should a SV with a call back get updated the script issues an SML command back to the LabVIEW application via our standard FROMPML server device.

To Do:
Modify fromSML_toPML, add a second thread for the callbacks, add the SVE client interface