VSCP Works is a graphical toolbox for VSCP developers and users that is available for Linux and Windows. It can be used to update code in in-house nodes and nodes that sit at a location on the other side of the earth. It can be used to view events sent by a node, to configure a node using a high end interface and to simulate a node. New functionality will be added to VSCP Works as needs arise.
There is a three video walkthrough on Youtube that look at some of the essentials of VSCP Works
With the clinet window of VSCP works it is possible to open communication sessions either
Use the File/New VSCP Client window to open a new client window. You can now select a predefined interface to connect to or create a new session.
Below is a picture of how the window looks as on Ubuntu Linux
and on windows
Remote interfaces have “TCP/IP:” in front of them and local interface or direct connections to CANAL drivers have “CANAL:” in front of them. The first type listed is the “Unconnected Mode” wich opens the window without a connection either to a remote server or a CANAL driver. This is here to able to investigate saved session data.
With the Add button a new TCP/IP or CANAL interface can be added. With the Edit button an available interface setting can be edited and last the remove button can be used to remove an interface.
The image below shows how the CANAL session edit window looks like on Ubunti Linux
and on windows
Standard CANAL interface settings are available here.
A CANAL driver can have an internal XML file stored that describes the configuration string. If the driver has such information the button to the right of the configuration string can be used to run a wizard that helps in setting up both the flags value and the configuration string without needing to find the drivers documentation.
The image below shows how the remote TCP/IP server edit window looks like on Ubuntu Linux
and on windows
For the remote TCP/IP interface some parameters need to be set also
The GUID for the interface to use on the server should be set to all zero for a standard server connection. In this case a sent event from our client will be sent on all other interfaces. If a valid interface GUID is entered here all send events will only go to devices on the selected interface. As a help to set the correct interface Get Interface button is available which will fetch all available interfaces from the server and allow a selection among them in a listbox.
Use the Set Filter button to set an incoming filter from this session. Only events that satisfy the filter/mask combination will be received.
Use the Test Connection button to test the connection to the server.
Selecting one of the interfaces and pressing OK (or dubbelclicking the line) opens the session window
Ubuntu Linux session window
and on windows
The VSCP communication session window is divided into two areas. The upper area is the receive list and the lower area is the transmission list. Events that are received for this client is listed in the receive list also transmitted events are showed here. Further more it is possible to save the list to disk and later load it for investigation.
Currently only a chronological view is available (message log). Later another view will be added that makes it possible to see how many events of a certain class/type pair that has been received (message count).
By right clicking on the receive list some functionality will be available
Naturally it is also possible to clear the receive list window.
In the transmission object list rows are available that can be transmitted on the interface. It is possible to load and save transmission row sets which can be handy in many situations. It is possible to creat rows that is automatically transmitted with a selected period expressed in milliseconds and which continue to do so as long as they are active. It is also possible to create transmission row objects that automatically send out one or more event when another event is received.
On the right of the Transmission object list is a set of buttons
and on windows
that control rows in the list.
The first button add a new transmission object. The second button edit a selected row and the third button delete a row.
The forth button load a transmission ro set from a file and the fifth button save the current rows.
On the right isa single button
and on windows
This button is used to send the selected row(s). A single row can also be sent by double clicking on it but by selection several rows and clicking on this button the rows will be sent in sequence.
Some additional functionality is available by right clicking on the transmission object list.
The transmission row edit window looks like this on Ubuntu Linux
and like this on Windows
Standard settings for events are available here. To use the GUID assigned by the daemon as the originator for the event set GUID to all zeros.
Data for the event is just a comma separated (mixed if needed) list of hexadecimal or decimal values.
Count is the number of sends of the transmission row.
Period is the time in milliseconds between automatically transmitted rows.
Trigger is a selected trigger among the available triggers.
The node configuration window can be used to set parameters for a device.
On Ubuntu Linux this window looks like this
In the above screenshot I have higlighted the registry entry that set the interval for temperature reports on the Kelvin module. To change it just click on the value and update. The operations are the same if the module is locally connected or located on the other side of the earth.
And on Windows
Before this windows a session must be selected just as for the communication settings window. It is possible to connect through a local CANAL driver or a remote TCP/IP server. The only difference is that you need to enter a valid nickname id for a CANAL session before clicking update and that this id must be a full interface id with the least significant byte set to the nickname id of the device on that interface.
The update loads all registers from the device, both custom and standard. A clear text field is available at the bottom of the screen where data is presented in a more human suitable form. For instance the MDF URL is in clear text etc.
After updating the registers they can be edited and have threre register content changed and after that another click on the update button will write the content back.
The undo button can be used to reset all register to the content they had when the register session was opened.
In the clear register mode VSCP Work only recognize standard registers. It is therefore impossible for it to differentiate between read only and read/write registers in the custom register space. The MDF button address this.
After an update a click on the MDF button will automatically donwload the MDF file belonging to the device. It will then parse it and use the correct descriptions also for the custom registers. Further more now the abstractions can be used and entering register values can be done in a more human friendly way,
The nodeid field looks different when connected to a remote server as above or to a local CANAL driver. For a remote server the interface GUID is part of the id for the node and it tells which interface to talk to on the server. The least significant byte is the node id for the device connected to that interface. For a session connected directly to a CANAL device just the node-id is entered here.
To the right of the node-id field is a search button. It can be used to check that a node with the entered node-id really is present.
The connected/disconnected button tell if the connection to the server is active or not.