Xcos On Web

IITB SUMMER INTERNSHIP 2017
Xcos-On-Web
Under the Guidance of Dr. D. B. Phatak
Contributors Mentors
Dattatreya Sarma G.V.S Dipti Ghosalkar
Jayaprakash Akula Inderpreet Arora
Ritveeka Vashistha
Ruhi Taj
Shashank Bhalotia
Shivendra Pratap Singh
Xcos-On-Web 4 July 2017
Acknowledgement
By doing this project, we would like to thank all those who have been instrumental in
helping us in achieving the desired outcome. We would like to thank Prof. D.B. Phatak and
IITB for providing us with this opportunity and having faith in our abilities. We would like to
thank our mentors Ms. Dipti Ghosalkar and Ms. Inderpreet Arora for being a constant support
and giving us a broader picture of the whole scenario. Their constant endeavor and guidance
has helped us to complete the project within the stipulated deadline. We would like to thank
Mr. Bikas Chhatri and Mr. Rahul Kharat for providing us the administrative help and making
our working environment comfortable. Last but not the least, we would like to thank our fellow
interns for helping us out with all the problems that we faced and making our internship
experience an enjoyable one.
Indian Institute Of Technology, Bombay 2

Summer Internship 2017
Project Approval Certificate
Department of Computer Science and Engineering,
Indian Institute of Technology, Bombay
The project entitled “Xcos-On-Web” submitted by Dattatreya Sarma, Jayaprakash Akula,

Ritveeka Vashistha, Ruhi Taj, Shashank Bhalotia and Shivendra Pratap Singh is approved for
Summer Internship 2017, at Department of Computer Science and Engineering, IIT Bombay.
____________________ _________________
Prof. D.B. Phatak Miss. Dipti Ghosalkar
Dept. Of CSE, IITB Project Mentor
Principal Investigator
Place: IIT Bombay

Date: July 4, 2017

Table of Contents
1. INTRODUCTION ............................................................................................................................... 6
1.1. AIM ....................................................................................................................................................... 6
1.2. MOTIVATION ........................................................................................................................................... 6
2. USING XCOS ON WEB ....................................................................................................................... 7
2.1 BUILDING SCILAB FROM SOURCE ON LINUX : .................................................................................................. 7
2.2 INSTALLING OTHER REQUIREMENTS :............................................................................................................ 8
3. LIMITATIONS WITH EARLIER VERSION .............................................................................................. 9
4. TWO WAY COMMUNICATION FOR TKSCALE BLOCK ........................................................................ 10
4.1 INTRODUCTION ...................................................................................................................................... 10
4.2 METHODOLOGY ..................................................................................................................................... 10
4.2.1 Creating the sliders for TKSCALE block .......................................................................................... 10
4.2.2 Logging the values of TKSCALE to file ........................................................................................... 15
4.2.3 Generating graph from values of TKSCALE. ................................................................................... 18
4.3 RESULTS ............................................................................................................................................... 20
4.3.1 Experimental setup having a single TKSCALE block ....................................................................... 20
4.3.2 Experimental setup having two TKSCALE blocks ........................................................................... 21
5. XCOS FOR TEXTBOOK COMPANION ................................................................................................ 22
5.1 INTRODUCTION ...................................................................................................................................... 22
5.2 FEATURES / REQUIREMENTS ..................................................................................................................... 22
5.3 THE DIAGRAM GENERATION ..................................................................................................................... 22
5.4 REPLACING THE INNERHTML...................................................................................................................... 24
5.5 FURTHER DEVELOPMENT ......................................................................................................................... 24
6. IMPLEMENTATION OF FUNCTIONALITY OF SINK BLOCKS : .............................................................. 25
6.1. CHANGE IN SOURCE FILES OF SCILAB : ........................................................................................................ 25
6.2. GENERATION OF OUTPUT ON THE WEB : ..................................................................................................... 34
6.2.1. Enabling 2D and 3D graphs :...................................................................................................... 34
6.2.2. Enabling Exporting feature in graphs : ...................................................................................... 34
6.2.3. Adding routes to control output ................................................................................................ 34
6.2.4. Creating 2D-charts for blocks giving 2D results ......................................................................... 35
6.2.5 Creating 3D-charts for blocks giving 3D results : ....................................................................... 36
6.2.6 Processing 2D-data .................................................................................................................... 36
6.2.7 Processing 3D-data .................................................................................................................... 37
6.2.8 Generation of Output .................................................................................................................. 37
6.2.9 Adding Event Listeners for Manipulation of Output Size : ......................................................... 38
6.2.10 Giving download of binary and audio files for blocks WRITEC_f and WRITEAU_f: .................. 39
6.2.11. Changes for implementation of sinks block TOWS_c and source block FROMWSB : .............. 39
6.2.12 Block Identification state and corresponding block event: ....................................................... 41
6.2.13 Results ....................................................................................................................................... 42
7 PARSER .......................................................................................................................................... 45
7.1 INTRODUCTION...................................................................................................................................... 45
7.2 IMPLEMENTATION .................................................................................................................................. 45
7.2.1 Parsing DEFINE : .......................................................................................................................... 45
7.2.2 Parsing GET : ................................................................................................................................ 47
7.2.3 Parsing SET : ................................................................................................................................. 47
7.3 IMPLEMENTED FUNCTIONS :..................................................................................................................... 48
7.4 RESULT : .............................................................................................................................................. 49
7.4.1 Response by get() function: ......................................................................................................... 49
7.4.2 Response by set function: Change in number of input ports from 2 to 3 ..................................... 49
8. MODIFICATION AND IMPLEMENTATION OF FUNCTION .................................................................. 51
8.1 INTRODUCTION ..................................................................................................................................... 51
8.2 ERRORS IN THE PREVIOUS BLOCKSS ........................................................................................................... 51
8.3. MODIFICATION OF ERRORS ..................................................................................................................... 55
8.3.1 Image lost on submission: ....................................................................................................... 55
8.3.2 Wrong display to the blocks having dynamic display: ............................................................. 56
8.3.3 Implementation of set function to CMSCOPE:.......................................................................... 56
8.3.4 Modifications in code for drag-drop......................................................................................... 57
9. REFERENCES.................................................................................................................................. 58

1. Introduction
Numerical simulation is nowadays essential in system design process. Simulation of

complex phenomena (physical, mechanical, electronics, etc.) Allows the study of their
behaviour and results without having to conduct costly real experiments. Scilab is an open
source software dedicated for this purpose. It is widely used in the world of industry and the
future generation of engineers and scientists are trained since secondary school to the concepts
of modelling and simulation.
Xcos is a Scilab tool dedicated to the modelling and simulation of hybrid dynamic systems
including both continuous and discrete models. It also allows simulating systems governed by
explicit equations (causal simulation) and implicit equations (a causal simulation). Xcos
includes a graphical editor which allows to easily represent models as block diagrams by
connecting the blocks to each other. Each block represents a predefined basic function or a
user-defined one. This blocks can be selected from a window called palette browser.[1]
1.1. Aim
Xcos on web is a project to port the core functionalities of Xcos to a browser-only

version that can be used without installing additional plugins or software on the cloud.
1.2. Motivation
Scilab is free and open source software for numerical computation providing a
powerful computing environment for engineering and scientific applications. The current
scilab version is a desktop version, which requires several installations. The current project is
to build a web version, which carries all the functionalities of the original version and
requires no installations. This would allow the user to use the scilab with more ease.

2. Using Xcos on web
2.1 Building Scilab from Source on Linux :
● Download Scilab source folder:

- Goto: https://github.com/shivendra3/scilab_for_xcos.git
- Clone the repository.
● If permission issue occurs, use chmod to grant permission. For Eg. If name of the
extracted folder is scilab-master_5.5.2, use :
$ chmod ugo+wrx scilab-master_5.5.2/ -R
● Go to the scilab folder through terminal and update using :
$ sudo apt-get update
● Installing dependencies :
- Scilab can be compiled with -
- For the C language: GCC (tested from gcc-4.0 => 4.5)
- For the Fortran: Gfortran (GCC suite)
- Java version (>=1.8)
- It is required to install all the build dependencies under Ubuntu and Debian. Starting
with Ubuntu (>= 9.4) and Debian (>= Squeeze), the following command will install
all the build dependencies of Scilab.
$ sudo apt-get build-dep scilab
● Run configure script :
- This script checks for many dependencies on your system and creates a “Makefile”
- Type the following in the terminal : ./configure --disable-static-system-lib
● Make using : $ sudo make -j4
● Now run scilab using : $ ./bin/scilab
Note :
If at any step, “ access denied ” or some other related error occurs, again grant
permission to the scilab folder as before and then redo the step.

2.2 Installing Other Requirements :

● First install python and other necessary software
● Open terminal and type : $ apt-get install libevent-dev python-dev python-setuptools
● Then type : $ pip install gevent flask
● Once installation is completed
● Download Xcos on-Web project from github :
https://github.com/shankyb9/xcos_on_web.git
● Extract Xcos-on-Web, navigate through terminal inside that folder
● And type command : $ python sendlog.py
● Then open browser and type 127.0.0.1:8001
● This will open xcos on browser.
Make sure you change the path of scilab call ie. SCI variable in sendlog.py to your build
scilab path before running any simulation.

3. Limitations with earlier version

i. Two way communication for TK Scale block was not present.
ii. Graphs were not generated dynamically. Only images of chart were being
displayed.
iii. Parameters of blocks could not be modified at runtime.
iv. Some blocks could not be dragged to the working area.
Fig. Block could not be dragged.
v. The images for blocks were disappearing on setting any parameter.

vi. 3-D graphs for some 3-D blocks was not possible.
vii. No option to download the graphs and the .xcos file of the simulated
diagram.
viii. No method for identification of blocks.

4.Two way communication for TKSCALE block
4.1 Introduction
TK Scale is a ‘Slider Widget’ used to choose a numeric value through sliders.

We can say simply say that TK Scale is an input slider Block. User can change the input
during simulation/runtime. TK Scale is a ‘Slider Widget’ used to choose a numeric value
through sliders. We can say simply say that TK Scale is a input slider Block. User can
change the input during simulation/runtime.
Fig 4.1: TKSCALE block diagram

TK Scale has 3 parameters: minimum, maximum and normalization. Minimum
and maximum represents the input range and the output of the block is determined as the
slider’s present value divided by the normalization factor. User can change the input range
using these parameters.
Slider is used to change the input value by the user. User can change the input
range and output of the slider by changing the parameters of TK Scale and all the obtained
data should update in periodically with the specified ‘PERIOD’ parameter of CLOCK_c.
Out of the blocks present in Xcos application, TKSCALE is the only block
which has a real time interaction with the user for input. The earlier version of Xcos on web
has no module which enables the server to interact with user.
4.2 Methodology
4.2.1 Creating the sliders for TKSCALE block
Slider is used to change the input value by the user. User can change the input
range and output of the slider by changing the parameters of TK Scale and all the obtained
data should update in periodically with the specified ‘PERIOD’ parameter of CLOCK_c. So
to create the slider and update the data we will follow the steps mentioned in the Flow Chart.

Xml Code:
Get Details of TK Scale, CLOCK_c, Splits:

Now we will run a loop on xmlcode to get the TK Scale (Basic Block) Details
We will get the count of TK Scales used in experiment with their parameters
stored in an array. Also we have to update the data (input) periodically, so we should also
find ‘which TK Scale is connected to which CLOCK’ and get the clock parameters.
To find the TK Scale and Clock relation we used the following steps:
(i) Find all the clocks with its parameters (clock details)

(ii)
Find the ports of TK Scale and CLOCK_c to find their links. The details of the ports are
under mxcell tags in xmlcode.Also find all split id’s.
We used 2-D array, 1st column represents split id value, 2nd column indicates to which
group split belongs to.
-1 indicates split does not grouped with any other group.

Grouping Method:
(iii) Grouping Method:
Technique which iterates all the links in the experiment and grouping all the TK
Scale and CLOCK_c blocks to find their relation so that we can update the input data
periodically with the specified ‘PERIOD’ parameter.
- Iterating all the links -
--> find the source and target of the present link
--> find whether source or targets belong to any of the splits.
---> if both source and target belong to any of the splits:

(1). If both are not grouped to any other split then make grouping to both
(2). If source is not grouped and target is grouped to another split then add source to the
group where target belongs to.
(3). If target is not grouped and source is grouped to another split then add target to the group
where source belongs to.
(4). If source, target both are grouped with some other splits then merge one group into
another with minimum index number.
---> If source does not belong to splits then it belong to one of the CLOCK_c id's then find
the source and add source a new group.
---> If target does not belong to splits then it belong to one of the TK Scale id's then find the
target and add target to a new group.
We got two connections by the above steps :
. ‘which TK Scale connected to which split’ and
. ‘which CLOCK_c connected to which split’
Using these two connections we will find the RELATION between the TK Scale and
CLOCK_c
- iterate total clock group and finally obtain the detail ‘which split contains the ith clock’ -

From the obtained connection between CLOCK_c and Splits find the
connection between CLOCK_C and TK Scale. Finally we found the required connection. We
have to add the ‘Period’ parameter to the tkclk array
Create Sliders with Obtained Data:
Now we should create the sliders with obtained TK Scale details using slider.html
And the url should passed with the parameters

“window.open('http://127.0.0.1:8001/slider.html?Min='+min+"&max="+max+"&num="+nu
m+"&tag="+tag+"&norm="+norm,"TK-"+i,width="20",height="100"); “
We should also check the condition that ‘Maximum number of Sliders (TK Scales)
allowed in the experiment is 10. We will check the condition after the xcos file is uploaded.
Slider example:
4.2.2 Logging the values of TKSCALE to file
Whenever user slides the pointer in any one of the slider we will update values
of each slider which will be stored in the paragraph (‘p’) id basing on the slider number. The
ten id’s tk1 to tk10 take the updated value from the slider. Whenever any one of the id value
(innerhtml) is changed we will call ‘getcurval’ function using the below method tkclk has the
clock parameter ‘PERIOD’ for every TK Scale and tk1 to tk10 have the updated slider
values. Together we are store them in value Array (valuearr) and we will make an ‘Ajax’
request with that data. It will invoke a function in python named as “updatetkfile” in
sendlog.py
The following flowchart shows the process of updating data to the tk files
Note that when user changes the slider value, updated data will be written to the
file else present value will be written to the file continuously until new value appears. As we
are writing the updated values (input values) to a file. These may overlap when there are
multiple users. To overcome this situation we will creates files with uid (user id) generated
by uuid to every user. Using uuid1() we will not get any duplicate uid’s. If there are more
than 2^14 requests to uuid1 in less than ten nanoseconds then there might may appear few
cases to get duplicates which is impossible in our case due to less time span (10 ns).
Initialize the Process:
Updating the data to the file:

a. Get the uid
b. Check the initialization of writing data
Val.txt file contains the slider’s present value and whenever any data updates, the file
contents will be overwritten and use the same file to append the data repeatedly to get the
graph.

This function takes the updated data and store it in the val.txt file in values folder.
Findfile function checks the val.txt file content.If it contains “Start” it initializes thread and
creates required files,If it contains “Stop” it stop the thread, Else data updation will be done.
By the return value initialization or updation or stopping is done.

Thread Initialization:
We will update the tk files every 0.1 second thereby getting the correct plot for the graph
using ”getdetailsthread()”
Getdetails functions takes the val.txt file and makes the data to be appended at the file end.
Getdetails from Val.txt:
We have to update the data periodically with the time. Val.txt contains only
‘PERIOD’ parameter so in order to update the time as well as data (input value) we pass the
data in val.txt to another function “appendtotkfile” which appends data and time to the file.
Append Data and Time to TK Files:
We created a file time.txt which updates time with the ‘PERIOD’ parameter
initialized to 0’s in findfile function. For every iteration we add the time in time.txt file with
the ‘PERIOD’ parameter and append it to the file with the data in the val.txt. Change Format
will change the time floating value to scientific format and the input value is received in
scientific format.
This process continues until user stops the simulation by closing the simulation window.
Terminate:
For closing sliders and to stop the thread we use the event closing of simulation
window. Stoptk function will close all slider windows as well as the thread by sending
“Stop” data in ajax request in index.html. By receiving the request in sendlog.py file we will
delete all the related files created. We will also call the stoptk function even if user closes the
main window without closing the simulation window.
4.2.3 Generating graph from values of TKSCALE.
The TKSCALE block, now has to read the values from the log file and process
it to generate appropriate graphs. The exact method by which TKSCALE block transmits its
value to the corresponding sink block is unknown. Only the method by which sink block
obtains the resulting value is known. So, the first approach for this problem was to modify
the latter method. But, this method too has its own limitations. For this approach to work
correctly the source code of around 25-30 blocks had to be modified and it is not practically
feasible and not an efficient method.

So, a different approach was adopted. This approach would replace TKSCALE
block by a RFILE_f block. RFILE_f block allows user to read data in a file with the name
defined with the input file name parameter, in text formatted mode or in binary mode. The
file is a sequence of records.. RFILE_f block updates its value from the file periodically
based on the time period set for the CLOCK block it is connected to. This block might
encounter an end of file argument during the reading process. In such cases the block repeats
the last value it read and hence obtained output might not tally with the expected output.
The problem now is how to change the diagram at the backend without the user
actually realizing it. The actual procedure of changing the diagram with TKSCALE to
RFILE_f block is done only when the user runs the simulation. At that time the current xcos
diagram (basically an xml file) is passed as an argument (.xcos file) to upload function. The
entire manipulation of block is done here at the backend without reflecting these changes to
the front end user.
Fig 4.2.3.1 : A sample example of the block diagram and its corresponding diagram at the
backend after altering it.
The question that arises now is “How do we create a new block in the xml file?”
Code has been written to add the entire BASIC BLOCK xml part of RFILE_f in the .xcos
file that gets uploaded to server. For every TKSCALE block a new RFILE_f basic block xml
has been added. The actual basic block xml for RFILE_f block can be obtained by exporting
the xml for diagram containing only that block. As the xml part of the block is very big. It
has been copied to a file and later read from it and written to the .xcos upload file.
The real task is to replace all the connections that a TKSCALE block had
with the new RFILE_f block. A module has been written in python to modify the xcos that
retains the connections of the TKSCALE and make RFILE_f to read the file containing the
slider values. The connections is set in the desired way by just changing ID of RFILE_f with
that of a TKSCALE block. Later the ID of TKSCALE block is altered with a negative
number and henceforth virtually removing it. The parameters of RFILE_f block are changed
to the read the required file by providing it with its location on the disk. Also the exact
format in which the numbers are present in the file have been provided to the RFILE_f block

[2]. Furthermore, the real time scaling value for experiments containing TKSCALE has been
hard coded to 1.0 to give user a live experience.
Usually for the other blocks scilab process communication (continues till the
end of simulation time) and graph generation go hand in hand. But for diagrams with
TKSCALE the same procedure is not applicable as writing values and reading values need to
happen parallel. For this purpose simulation diagrams are checked for non-empty canvas and
then scilab communication is terminated. As scilab communication would restrict any
parallel reading of file necessary for generation of graph. The code is made to sleep for a
small duration of time during the log file reading procedure as some time is required for
updating the log file with new value of TKSCALE.
4.3 Results
The following images will reflect the changes made and show the results of a few
experimental setups containing TKSCALE block.
4.3.1 Experimental setup having a single TKSCALE block
Fig.4.3.1.1 Experimental setup with its corresponding output

The above experimental results are in the case where a single TKSCALE block
is connected to CSCOPE block. The windows next to the setup are the slider window and
simulation graph window. The simulation graph clearly reveals the value of slider at the
instant of time.

4.3.2 Experimental setup having two TKSCALE blocks
Fig.4.3.2.1 Experimental setup with its corresponding output

The above experimental results are in the case where two TKSCALE blocks are
connected to CMSCOPE block with 2 input ports. The windows next to the setup are the
slider window and simulation graph window. The simulation graph clearly reveals the value
of slider at the instant of time. The first TKSCALE block has been set a normalization
parameter as 2 and for the second one as 3.

5. Xcos for Textbook Companion
5.1 Introduction
The Textbook Companion Project (TBC) aims to port solved examples from
standard textbooks using an open source software system, such as Scilab. Any standard
textbook can be used for this purpose.We can implement our Xcos for Textbook Companion
in ‘TBC code search’ section and improve its functionality thereby any user can see and
simulate any example of xcos.
For this idea, we created a generic method which will generate the diagram for the given
.xcos file contents.
5.2 Features / Requirements
1. Each .xcos file should have a unique id

2. All files should be stored under database
3. Fetching File contents should be done from the databases
4. Every Example will follow same URL with difference in id number of the file
At present we are storing and fetching the files from our client side system.
Url Format : http://127.0.0.1:8001/importxcos?Eid=fileuniqueid
We use Details.uid and names (dictionary) as variable names to support functionality to
access Xcos TBC for multiple users.
5.3 The Diagram generation

The technique we followed is to take the .xcos file contents and place the file contents as
innerhtml for a paragraph (‘p’) id and calling the function xcostodiagram to generate the
diagram in the index.html with xcos contents as the innerhtml value.
This method includes the following steps -

1. Invoke Python Function: When a user enters into the url, we should take the
parameter id of the file to fetch the file contents.
a) Get the id number from the url.
b) Fetch the details of the file with the obtained id number.

c) Edit the index.html using beautifulsoup.
d) Find the viewexample (‘p’) id
E) replace innerhtml with Xcos file contents in soup

Temp =
Details.names[Details.uid+"soup"].find(text=Details.names[Details.uid+"innerhtml_1"]).repl
acewith(Details.names[Details.uid+"xcoscontents"])
F) save the changes of soup in the html file
G) In index.html check the innerhtml value and call the function
First we will check the innerhtml value and if it contains the file contents, we
will replace the unnecessary characters to import (generate) the diagram. Xcostodiagram
function will take the file contents and generates the diagram.
H) we have to open our xcos page to run the simulation.
Meanwhile we should replace the innerhtml file contents back to the “xcosnull”
.So we kept a ajax request which will change the innerhtml back to “xcosnull”.

5.4 Replacing the innerhtml

This involves the same steps described as above importxcos method.
a) Take the html file and load it in soup
b) Find the innerhtml value
c) Replace the file contents to xcosnull in soup
d) Save the changes to index.html
5.5 Future development
1) All the Xcos files should be stored in database

2) Each file should have a unique id
3) Fetch the file contents directly from the database

6.Implementation of Functionality of SINK Blocks

To implement the functionality of sinks blocks, i.e., to provide output, following problems
had to be faced:
I. The generation of a proper xcos file.
II. As the xcos would be simulated on Scilab, data of the result generated was required
to generate result on web.
III. Generation of result on web.
The problems were overcomed by :

I. Upon simulation, the xcos diagram generated on Xcos-on-Web was exported to a
xcos file in ‘uploads’ folder on the server. This file was simulated using Scilab.
II. The source files of Scilab were modified to write the data of the simulation result to
a file with a unique id as per the user.
III. The data file generated was used to provide output to the user on the web. For graphs,
highcharts.js[3] was used. For other types of result, other different techniques were
used.
6.1. Change in source files of Scilab :
The source files of Scilab were modified to write the output data to a file with unique
id per user. The following basic steps were followed to store the data:
I. Using a filename with unique id :
This was implemented by concatenating Scilab’s process-id with the filename.
Fig.6.1.1 shows the process of giving unique id in a source C file(cscope.c).
Fig.6.1.1: Using process-id of scilab to generate unique filenames for data files
II. Opening the file in append mode so that data of one block does not overwrite
data of other block.
III. Giving unique block-id to differentiate the data of different blocks.

IV. Defining of the initializing step of the block’s output. Fig.5.1.2 shows the
initialization step for a CSCOPE block. Process-id of Scilab and block-id of
block were used to differentiate the initialization step of different output blocks.
Fig.6.1.2: Writing data to define Initialization state
V. Write each set of data of the output :

Depending on the type of block, required data for generating the result was chosen
and written to the file on each state update. Fig.5.1.3 shows the writing of each set of data on
state update of CSCOPE block.

Fig.6.1.3: Writing data of each output point on state update
VI. Defining the Ending phase of the block’s output :

Fig.6.1.4 shows the Ending step for a CSCOPE block. Process-id of Scilab and
block-id of block were used to differentiate the ending step of different output blocks.
Fig.6.1.4: Writing data to define Ending state
The following files were changed :

1) CSCOPE.c :
This file was modified to write data outputted by a CSCOPE block to a data file.
CSCOPE gives a single graph as output. Fig.6.1.5 shows the data stored for this block.
Fig.6.1.5: Recording each set of data for a CSCOPE block
2) CMSCOPE.c :
This file was modified to write data outputted by a CMSCOPE block to a data
file. CMSCOPE can give multiple output graphs. Fig.6.1.6 shows the data stored for this block.
As it provides multiple outputs, some of the data required had to be calculated.

Fig.6.1.6: Calculating and recording output data for a CMSCOPE block
3) CSCOPXY.c :

This file was modified to write data outputted by a CSCOPXY block to a data
file. CSCOPXY gives a single 2D-graph as output. Fig.6.1.7 shows the data stored for this
block.
Fig.6.1.7: Recording output data for a CSCOPXY block
4) CSCOPXY3D.c :
This file was modified to write data outputted by a CSCOPXY3D block to a data
file. CSCOPXY3D gives a single 3D-graph as output. Fig.6.1.8 shows the data stored for this
block. As it gives a 3D-graph, values of z-axis is also important as well as the angle of rotation
of the axes.
Fig.6.1.8: Recording output data for a CSCOPXY3D block
5) CANIMXY3D :
This file was modified to write data outputted by a CANIMXY3D block to a data
file. CANIMXY3D gives a single 3D-graph as output. Fig.6.1.9 shows the data stored for this
block. As it gives a 3D-graph, values of z-axis is also important as well as the angle of rotation
of the axes. It gives an animated output depending on the buffer size, so that needs to recorded
as well.
Fig.6.1.9: Recording output data for a CANIMXY3D block

6) BARXY_sim.sci :
This file was modified to write data outputted by a BARXY block to a data file.
BARXY gives output as an animated 2D-rotating line. It does so by using sequence of pairs
of points to generate lines while deleting the previous pairs from the output screen. Fig.6.1.10
shows the Initialization phase of BARXY. As BARXY gives output of a different type, a
different format is used for storing its data, as shown in Fig.6.1.11.
Fig.6.1.10: Defining Initialization phase of BARXY
Fig.6.1.11: Recording output data for BARXY block

7) AFFICHEBLOCK.java :
This file was modified to write data outputted by a AFFICH_m block to a data
file. AFFICH_m displays its output on the block itself. Fig.6.1.12 shows the process of
retrieving Scilab’s process-id in java. Fig.6.1.13 shows the step of recording the output data.
Fig.6.1.12: Retrieving process-id of Scilab
Fig.6.1.13: Recording output data for AFFICH_m block
8)CFSCOPE:
This file was modified to write data outputted by a CFSCOPE block to a data
file.It has only one graph for a particular block.The writing to log file part changes in
the file are in fig 6.1.14
Fig.6.1.14: Recording output data for CFSCOPE block

9)CANIMXY:
This file was modified to write data outputted by a CANIMXYblock to a data file.This
block gives a animation as a a output.The animation output depends on buffer so that is also
written in the log file.The changes for data writing to the block file are as follows in figure
6.1.15.
Fig.6.1.15: Recording output data for CANIMXY block
10)WRITEC_f:
This block actually writes binary data in a binary file so in the web version it was needed
that we return a binary file.As this file should be unique to be sent to the client,so we use pid
its name.For uniqueness with several similar blocks we have used timestamp in microsecond
also in the name of file generated.The timestamp generating part is as follows-
Fig.6.1.16: Generating timespace in writec

Then we name the file on the basis of pid ,timestamp and specified name .Here we name the
file on the basis of above specified factors and write the name of the generated file in the log
file along with initialization by the following change in code given in figure 6.1.17
Fig.6.1.17: Initialization ,naming and writing to the log file for WRITEC_f block
We write the ending part in the case when the binary file writing ends as follows-

Fig.6.1.18: Specifying of ending state and closing the log file for WRITEC_f
11)WRITEAU_f:
This block actually writes audio data in a audio file so in the web version it was needed
that we return a audio file.As this file should be unique to be sent to the client,so we use pid
its name.For uniqueness with several similar blocks we have used timestamp in microsecond
also in the name of file generated.The timestamp generating function of writec.c is directly
used.Then we name the file on the basis of pid ,timestamp and audio tag. Here we write the
name of the generated file in the log file along with initialization by the following change in
code:
Fig.6.1.19: Initialization ,naming and writing to the log file for WRITEAU_f block
We write the ending part in the case when the audio file writing ends as follows:

Fig.6.1.18: Specifying of ending state and closing the log file for WRITEAU_f
6.2. Generation of Output on the Web :
The output data recorded through Scilab source files would be used as input to the
web version to generate result for the user.
6.2.1. Enabling 2D and 3D graphs :

As the output maybe in 2D or 3D, it is important to enable both types of graph
which can handle the output data of Scilab efficiently, providing similar results as the Desktop
version of Scilab. Fig.6.2.1a shows the addition of scripts to enable 2D and 3D graphs.
Fig.6.2.1a: Adding scripts in index.html to enable 2D and 3D graphs
6.2.2. Enabling Exporting feature in graphs :

The following script was added in index.html to enable the exporting feature for
graphs:
<script type="text/javascript" src="highcharts/exporting.js"></script>
Enabling this feature provides the user with the facility to print the output graph
in different formats like: JPG, PNG, PDF, etc.
6.2.3. Adding routes to control output :

Due to different nature of outputs, sometimes it needs to communicate to the

server while giving output, due to which certain routes need to be provided. Fig. 6.2.3a shows
the addition of some routes to facilitate communication between the client and server.
o Stop() is used to kill Scilab process by the client. Incase the user cancels the output
window before Scilab’s process ends, then the Scilab process should stop
immediately to reduce processing load. This can be done using this route.
o Endblock() is used to indicate the Ending phase of a block output. For some blocks,
there is no defined ending. Using this route, the block can indicate its ending when
all of its data is sent.
Fig.6.2.3a: Adding routes in sendlog.py
6.2.4.Creating 2D-charts for blocks giving 2D results :

The function shown in Fig.6.2.4a creates a new 2D chart for blocks. As
shown in the figure, it takes the data values for x-y axes to generate the chart. Also, depending
on the block type, it changes the thickness of line which can be used to draw either scatter
points or line as per requirement. Each output graph is given a separate container-id using the
‘id’ parameter, using which it can be referred later. The chart is made using the features of
highcharts.js.
Fig.6.2.4a: Creating 2D-graphs

6.2.5 Creating 3D-charts for blocks giving 3D results :

The function shown in Fig.6.2.5a creates a new 3D chart for blocks. As shown in
the figure, it takes the data values for x-y-z axes to generate the chart. Also, depending on the
block type, it changes the thickness of line which can be used to draw either scatter points or
line as per requirement. Each output graph is given a separate container-id using the ‘id’
parameter, using which it can be referred later. The chart is made using the features of
highcharts-3d.js.
Fig.6.2.5a: Create 3D-graphs
6.2.6 Processing 2D-data :

After taking each line of data from the data file, they need to be processed
according to the type of block. Fig.6.2.6a shows the processing step of 2D-data.
Fig.6.2.6a: Processing 2D-data in chart.js

6.2.7 Processing 3D-data :

After taking each line of data from the data file, they need to be processed
according to the type of block. Fig.6.2.7a shows the processing step of 3D-data.
Fig.6.2.7a: Processing 3D-data in chart.js
6.2.8 Generation of Output :

There are different types of results upon simulation. Thus, different types of block
data needs to be represented accordingly. Fig.5.2.8a shows the process of adding points to
output charts, depending on block type. Fig.6.2.8b shows the process of generating result of
CANIMXY3D block. Fig.6.2.8c shows the process of generating result of BARXY block. In
BARXY, changes are made such that only 2 points remain in the chart at any point of time,
which are connected to form the rotating line.

Fig.6.2.8a: Adding points to graphs(chart.js)
Fig.6.2.8b: Generating output for CANIMXY block(chart.js)
Fig.6.2.8c: Generating output for BARXY block(chart.js)
6.2.9Adding Event Listeners for Manipulation of Output Size :
To give the functionality for maximizing the output graph, event listeners were used
in chart.js. Fig.6.2.9a shows the different event listeners provided for the manipulations.
Fig.6.2.9a: Event listeners for window MAXIMIZE, NORMALIZE and CLOSE

6.2.10 Giving download of binary and audio files for blocks

WRITEC_f and WRITEAU_f:
To give the download we have already given their filenames in the log
file. So whenever in the ‘log’ event listener we have the corresponding block_id we take the
filename and make a new form with filename as data and send it to the server as an
XMLHTTP ‘POST’ request. Then this request is received by a new route ‘/downloadfile’ in
the server which first determines whether it is binary or audio and sends the file
correspondingly. The route is defined in SendLog.py as follows-
Fig.6.2.10a: Route for giving downloads of files
Then the XMLHTTP receives the corresponding file as a blob object and then an object url
is generated for the file with which a download popup for the client is triggered. For this the
corresponding changes in chart.js are as in figure 6.2.10b
Fig.6.2.10b: Giving option of downloads of corresponding binary and audio files
6.2.11. Changes for implementation of sinks block TOWS_c and

source block FROMWSB :
The above blocks use scilab workspace .TOWS_c saves its input in a
specified variable in the scilab workspace and FROMWSB takes a workspace variable and
gives it to some other block. As we have a different scilab instance for each simulation so
we could not directly use the blocks. So to use a workspace for a complete session of the
client we saved and loaded the workspace only when needed. We save the workspce by
modifying the command for running scilab. For that we needed to identify the blocks before
simulation. So we parsed the xml file using minidom library of python during the upload file
process only. We use a counter variable named workspace_counter and set it to 0 if no such
block and 1 corresponding to TOWS_c and 2 corresponding to a FROMWSB block and 3 if
both blocks are present and we assign this workspace_counter to a global list workspace_list
corresponding the the file. We also save the variable to be saved for TOWS_c in a global
dictionary WORKSPACE_dict corresponding to the particular xcos file uploaded.For this
the following changes are done in upload route of SendLog
Fig.6.2.11a: Parsing xml for checking TOWS_c and FROMWSB

For a particular session we need a particular file to save and load the
workspace.We do this by identifying the file on the basis of uuid defined in
Details method.We use this to name the file as follows and use the save command
by modifying the command list and save the workspace in a .dat file and load the
file fr the case.We do it by changes as follows:

Fig.6.2.11b: Saving and Loading workspace commands on the basis of existence of blocks
6.2.12 Block Identification state and corresponding block event:
This is done for case where normal sending of points as in general could
not be used as in the case of BARXY so we defined a new event trigger in the chart.js as
follows:
Fig.6.2.12a: Block event trigger in chart.js for dome blocks The

corresponding changes in SendLog were done to identify and trigger the block event while
parsing the log file
Fig.6.2.12b: Block conditon in parse line in SendLog

6.2.13 Results :
A sample 2D result is shown in Fig.6.2.10a. Fig.6.2.10b shows a sample 3D result.
Fig.6.2.10c shows the result of a BARXY block.
Fig.6.2.10a: Output of a CMSCOPE block, showing the export feature
Fig.6.2.10b: Output of a CSCOPXY3D block
Fig.6.2.10c: Output of a BARXY block being zoomed

Fig.6.2.13d: Output of a CANIMXY block
Fig.6.2.13e: Output of a CFSCOPE block

Fig.6.2.13e: Download option with use of Writec_f and Writeau_f

7 PARSER
7.1 Introduction
In previous version of xcos-on-web neither can user see the current parameters nor can
he/she change parameters for the block. Hence getter and setter functions needed to be
implemented for all 230 blocks . But implementing these many getter and setter functions
would have taken a lot of time, So my mentor asked me to implement a parser which can
parse code of all the blocks written in sci language to javascript.
Sci code explanation : sci code for each block is divided into 2 parts for most of the
blocks, “set” and “define” . But, each block has “set”,”get” and “define” in javascript. So
parser divides the sci code into three parts (set is divided into get and set and then each part
is parsed differently.
7.2 Implementation
7.2.1 Parsing DEFINE :
I extracted define part from “case define” of sci code. There are 3 types of
variables that are initialised in define.
a) LOCAL variables: These variables are initialised with constant values and are stored as
“this.[var] = [value]”. These variables are used to initialise other variables and are refrenced
in “get” functions. These variables are stored in exprvariables and their type
(“int”,”matrix”,”string”) is also stored. Derived variables are variables which uses local
variables in their initialisation these variables are stored in derivedvariables.
b) MODEL variables: For all blocks model is either initialised by function “scicos_model()”
or “scicos_diagram()”. Model stores 24 variables which are of different types.
 Model : scilabstring
 Sim : scilabstring
 In : scilabdouble
 In2 : scilabdouble
 Intyp : scilabdouble
 Out : scilabdouble
 Out2 : scilabdouble
 Outtyp : scilabdouble
 Evtin : scilabdouble
 Evtout : scilabdouble
 State : scilabdouble
 Dstate : scilabdouble
 Odstate : list
 Ipar : scilabdouble
 Rpar : scilabdouble
 Opar : list
 Blocktype : scilabstring
 Firing : scilabdouble
 Dep_ut : scilabboolean
 Label : scilabstring
 Nzcross : scilabdouble
 Nmode : scilabdouble
 Equations : list
 Uid : scilabstring
NOTE : This classification is different in scialb 6.0.0
C)VAR variables : Some variables are initialised as var as these are immediately stored in
one of the model variables. E.g “exprs” is stored in this.x.graphics
Since this type variable classification is not followed in scilab code. I identified a pattern, all
variables which are initialised before declaration of model are “local” variables, all variables
that are stored as “model.[var] = [value]” are “model” variables while others are var variable.
Bool isinitfinished stores the above discussed information.
Use of this Classification : Local variables are stored as simple data types already present
in javascript. Model and var variables are stored as scialbdouble, scialbstring, scilabboolean
or list. Hence, value is parsed differently for each type of variable.
For parsing I used regex to classify lines ( each line of the code ) on the basis of [value] i.e.
Everything that is present after “=” in a line
Each line is identified as [var] = [value]
Regex used:
1. Initlist = value is an array/matrix/complete/incomplete
2. Initnum = value is a number
3. Initfuncn = value is a function call
4. Initstring = value is not identified by previous regex expression but line is an
assignment
Depending on the classification under which each line falls it will be processed by different
functions. E.g. Updatefunction, updatenum, updatelist, updatestring.
Two important functions are:
A) Changelist(): this function parses values of type list.

1. Pattern - integers are parsed into [this.value], arrays are parsed into ...this.value
and matrix are parsed into colon_operator(this.value). Other regex expressions
are used to classify each element of value of type list/array.
B) FuncnCall(): this function parses values which are function calls. For each function
parameters need to be parsed into different forms.For e.g. Jetcolormap(n) ->
jetcolormap(this.n)
“exprs” : All parameters that can be changed by user are stored in exprs. Hence all variables
that are present in array assigned to “exprs” are stored as exprvariables and the form in
which these variables are stored in array is stored in getlist.
7.2.2 Parsing GET :

There is a function call to scicos_getvalue() in beginning of “case set” in sci
code. I used a regex to parse this line to get labels, exprlist, typelist.
a. Labels : it stores the strings which explains the use of variable
b. Exprlist : variable names is stored in this list.
c. Typelist : It stores the dimension and data type of each variable.
[ok,var1,var2,var3,...,exprs] = scicos_getvalue(“string”,[],list(),exprs)
a. Var1,var2,var3,... : are variables to which values are assigned by the user. Initial value
for each variable is taken from exprs, in parsed code it is stored in getlist.
b. List() : stores data type and dimension for each variable. After user has entered values,
it has to be parsed into float or matrix by calling functions parsefloat() or inverse().
7.2.3 Parsing SET :

All values that are assigned by user are passed as parameter to set. Depending
on the datatype of each variable respective function has to be called for each line in the code.
The code is further divided into two parts:
a. Validation Code : It consist of validation part of “case set”. Since I did not parsed
validation code hence, validation is still remaining in the javascript files.
b. Set Code : It is easy to know datatype of a variable now as all variables are stored in
exprvariables and derivedvariables .Hence line can be parsed easily using functions of define
parser but it doesn’t update any list in this part.
Important Functions:
A) Set_io() : This function sets variables which are related to ports.
B) check_io() : It first check if given number of ports agree with block connection and then
changes block structure.
However in the javascript code of check_io I have not implemented the validation part of the
sci code.

7.3 Implemented Functions :
1. Jetcolormap() : This function is implemented to copy the function jetcolormap() of

scilab.
A) Pupose : to get the usual classic colormap which goes from blue - lightblue - green
- yellow - orange then red
B) Parameters :
N - size of the colormap
C)Returns : a matrix of size n*3
2. Linspace() :
a. Purpose : to get a vector of linearly spaced numbers from a to b of size n.
b. Parameters:
1. a : first value
2. b : second value
3. n : size of vector
3. Interpolation : This function is implemented to copy the interpln function of scilab.
a. Purpose : Given a matrix of x coordinates and corresponding y coordinates, it returns y

coordinate vector for a x coordinate vector.
b. Parameters
1. Color : a matrix of size n*2 which stores x and corresponding y values
2. X : a vector of size n for which y coordinates has to be calculated.
4. Set_io : This function is same as set_io() function of scilab except that validation has not
been implemented.
a. Purpose - Change the structure of model depending on the on parameters passed.
b. Parameters -
i.Model : initial and resulting block model structure
ii.Graphics: initial and resulting block graphics structure
iii.Inp : new input ports sizes
iv.Out : new output ports sizes
v.Clkin : new event input ports sizes
vi.Clkout : new event output ports sizes
vii.In_implicit : index of implicit input ports, the other ports are supposed to be explicit
viii.Out_implicit : index of implicit output ports, the other ports are supposed to be explicit
5. Check_io : It is implementation of check_io function of scilab in javascript.
Purpose : check_io first check if given number of ports agree
With block connection and then changes block structure
Parameters : same as that of set_io
Correction in Functions :
While testing I found that some functions have some error in the implementation.

1. Standard_define() - variables like pin, pout, pein, peout were assigned incorrect values
inside if() blocks.
2. Inverse() - Argument “[]” was parsed incorrectly
3. Size() - Cases 1 and 2 were not implemented.
7.4 Result :
Define, Set and Get are implemented for all blocks except 22 blocks.
7.4.1 Response by get() function:
7.4.2 Response by set function: Change in number of input ports

from 2 to 3

Number of input ports is 2
Number of Input ports is 3

8. Modification and implementation of function
8.1 Introduction
The implementation of some functions and changes were needed in the previous block in
order to allow the complete functioning of the functions being implemented. The errors of
the previous blocks are mentioned in the following section. All of these are now completely
functioning.
8.2 Errors in the Previous Blockss
Underfunction_ commonlyusedblocks(){
CMSCOPE: Error After submission, image is getting lost;
DEMUX: Error Seems to have no image:But no submit button
MUX: Error Seems to have no image:But no submit button
NRMSOM_f: Error Seems to have no image:But no submit button
PRODUCT: Error Not except replica of the image shown
RELATIONALOP: Error The image displayed is different from the image supposed to be
there
SWITCH2_m: Error No image being displayed.Must have an error!
}
Underfunction_ continoustime(){
CLR: Error in the image being displayed
PDE: Error No image being displayed.
}
Underfunction_ discretetimesystems(){
DLR : Error in image that is being displayed
DLSS: Error in the size being displayed
}
Underfunction_ eventhandling(){
CLOCK_c: Error in losing the image on submission
ANDBLK: Error in the exact replica of the image not shown

CLKFROM : Error - wrong image being displayed
CLKGOTO: Error - wrong image being displayed
Clkgototagvisibility: Error - wrong image being displayed
CLKOUTV_f: Error - wrong image being displayed
EVTDLY_c: Error - wrong image being displayed
EVTGEN_f: Error - wrong image being displayed
}
Underfunction_ mathematicaloperations(){
GAINBLK_f: Error - wrong image being displayed
GAINBLK: Error - wrong image being displayed
GAIN_f: Error - wrong image being displayed
MAXMIN: Error - wrong image being displayed
PRODUCT: Error - wrong image being displayed
PROD_f: Error - no image being displayed
SQRT: Error - no image being displayed
SUMMATION: Error - wrong image being displayed
SUM_f: Error - no image being displayed and ports also wrong
TANBLK_f: Error- unable to drag the block
}
Underfunction_ Matrix(){
EXTRACT: Error- Image not being displayed
MATMUL: Error- image not being displayed
MATSUM: Error- image not being displayed
MATTRAN: Error- image not being displayed
RICC: Error- image not being displayed
SQRT: Error- image not being displayed
SUBMAT: Error- image not being displayed
}

Underfunction_ Electrical(){
Capacitor: Error-Image size not as expected
Diode: Error-Image size not as expected
Sinevoltage: Error- Wrong image being displayed
Vvsourceac: Error- Wrong image being displayed
Vsourceac: Error- Wrong image being displayed
}
Underfunction_ Integer(){
BITCLEAR: Error- Wrong image being displayed
BITSET: Error- Wrong image being displayed
DFLIPFLOP: Error- Improper way of image being displayed
DLATCH: Error- Unable to drop the image
EXTRACTBITS: Error- Wrong image being displayed
JKFLIPFLOP: Error- Unable to drop the image
SHIFT: Error- Wrong image being displayed
}
Underfunction_ Port&Subsystem(){
CLKINV_f: Error- No image being displayed
CLKOUTV_f: Error- No image being displayed
INIMPL_f: Error- wrong image being displayed
OUT_f: Error- No image being displayed
}
Underfunction_ signalrouting(){
DEMUX: Error-Image size not as expected
DEMUX_f: Error-Image size not as expected
FROM: Error- wrong image being displayed
FROMMO: Error- wrong image being displayed
GOTO: Error- wrong image being displayed
GOTOMO: Error- wrong image being displayed

CLKFROM: Error- wrong image being displayed

CLKGOTO: Error- wrong image being displayed
Gototagvisibility: Error- wrong image being displayed
Gototagvisibilitymo: Error- wrong image being displayed
MUX: Error-Image size not as expected
MUX_f: Error-Image size not as expected
M_SWITCH: Error-No image is displayed
NRMSOM_f: Error-Image size not as expected
SWITCH2_m: Error-Image size not as expected
SWITCH_f: Error-Image size not as expected and name is wrongly written
SELF_SWITCH: Error- Very much wrong in dropping
}
Underfunction_ Implicit(){
CONSTRAINT_c: Error- wrong image being displayed
CONSTRAINT2_c: Error- wrong image being displayed
}
Underfunction_ Sinks(){
AFFICH_m: Error- no image being displayed
CLKOUTV_f: Error- wrong image being displayed
CMAT3D: Error-Unable to drop the image
CMATVIEW: Error-Unable to drop the image
CMSCOPE: Error-image lost on submission
OUT_f: Error- wrong image being displayed
TOWS_c: Error- wrong image being displayed
}
Underfunction_ Sources(){
CLKINV_f: Error- no image being displayed
CLOCK_c : Error-Image lost on submission
CONST: Error- wrong image being displayed

CONST_f: Error- wrong image being displayed

CURV_f : Not getting the window on double click
Counter: Error- wrong image being displayed
IN_f: Error- wrong image being displayed
Modulo_Count: Error- wrong image being displayed
PULSE_SC: Error-Unable to drop the block
}
8.3. Modification of Errors
8.3.1 Image lost on submission:
The error observed above was modified by changing the code for submit onclick function by
re-loading the image and calling it.
The code for the on-click submit is as follows:

8.3.2 Wrong display to the blocks having dynamic display:

The error shown below was modified by making modification in the define() function of
those blocks and modification in the xml-style sheet
8.3.3 Implementation of set function to CMSCOPE:

The changes made in the submit function were not compatable with the set function of
CMSCOPE. Hence the set function of CMSCOPE was rewritten to reflect the changes in
port and parameters.

Even after submission to three ports, changes were not shown. Hence modified to a new set
function.
The above code was writte to the CMSCOPE set function.
8.3.4 Modifications in code for drag-drop
The blocks which weren’t draggable/droppable were modified by changing the syntax and
logical errors in the previous block implementations as well as the display -html function.

9. References
[1] https://www.scilab.org/content/download/390/2810/file/scilabtec_Xcos.pdf
[2] https://www.cs.mtu.edu/~shene/COURSES/cs201/NOTES/chap05/format.html
[3] https://www.highcharts.com

Xcos On Web

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Xcos On Web

Uploaded by

Copyright:

Available Formats

IITB SUMMER INTERNSHIP 2017

Indian Institute Of Technology, Bombay 2

Summer Internship 2017

Project Approval Certificate

Department of Computer Science and Engineering,

Indian Institute of Technology, Bombay

The project entitled “Xcos-On-Web” submitted by Dattatreya Sarma, Jayaprakash Akula,

Place: IIT Bombay

Indian Institute Of Technology, Bombay 3

Indian Institute Of Technology, Bombay 5

Numerical simulation is nowadays essential in system design process. Simulation of

Xcos on web is a project to port the core functionalities of Xcos to a browser-only

Indian Institute Of Technology, Bombay 6

2. Using Xcos on web

2.1 Building Scilab from Source on Linux :

● Download Scilab source folder:

Indian Institute Of Technology, Bombay 7

2.2 Installing Other Requirements :

Indian Institute Of Technology, Bombay 8

3. Limitations with earlier version

Fig. Block could not be dragged.

v. The images for blocks were disappearing on setting any parameter.

Indian Institute Of Technology, Bombay 9

4.Two way communication for TKSCALE block

TK Scale is a ‘Slider Widget’ used to choose a numeric value through sliders.

Fig 4.1: TKSCALE block diagram

4.2.1 Creating the sliders for TKSCALE block

Indian Institute Of Technology, Bombay 10

Get Details of TK Scale, CLOCK_c, Splits:

Indian Institute Of Technology, Bombay 11

Indian Institute Of Technology, Bombay 12

--> find whether source or targets belong to any of the splits.

---> if both source and target belong to any of the splits:

Indian Institute Of Technology, Bombay 14

And the url should passed with the parameters

4.2.2 Logging the values of TKSCALE to file

Updating the data to the file:

Indian Institute Of Technology, Bombay 16

By the return value initialization or updation or stopping is done.

4.2.3 Generating graph from values of TKSCALE.

Indian Institute Of Technology, Bombay 18

Indian Institute Of Technology, Bombay 19

4.3.1 Experimental setup having a single TKSCALE block

Fig.4.3.1.1 Experimental setup with its corresponding output

Indian Institute Of Technology, Bombay 20

4.3.2 Experimental setup having two TKSCALE blocks

Fig.4.3.2.1 Experimental setup with its corresponding output

Indian Institute Of Technology, Bombay 21

5. Xcos for Textbook Companion

5.2 Features / Requirements

1. Each .xcos file should have a unique id

5.3 The Diagram generation

This method includes the following steps -

Indian Institute Of Technology, Bombay 22

c) Edit the index.html using beautifulsoup.

d) Find the viewexample (‘p’) id

E) replace innerhtml with Xcos file contents in soup

G) In index.html check the innerhtml value and call the function

Indian Institute Of Technology, Bombay 23

5.4 Replacing the innerhtml

5.5 Future development

1) All the Xcos files should be stored in database

Indian Institute Of Technology, Bombay 24