 Hello, everyone. Me and my teammates worked on XCOS on web project this summer. XCOS is a silab tool, which is dedicated to simulation of dynamic hybrid system. XCOS is equivalent to semulink of MATLAB. So XCOS on web is a project which puts the core functionalities of XCOS to a browser-only version so that anyone who has an internet connectivity can use XCOS and its functionalities without further installations. But there were some limitations in the previous version of XCOS on web. Like there was no two-way communication for TK scales and dynamic graph generation was not there for 3D graphs. And modification of block parameters was not there for the blocks. So the user cannot change the parameters. And some blocks were not draggable to the graph area. Block images were getting disappeared after dragging or setting the parameters. And some 3D graphs were not available. And there was no option to download the XCOS file so that user can download the XCOS file and run that file in the XCOS desktop version of silab. So we try to overcome these limitations. Now Shishank will continue. We try to overcome all the limitations. So these were the features we implemented. So there are some syncs block. Syncs block are those which give output to the user. So we implemented the following syncs block, these which are listed here. And the change in block parameters, which was not reflected earlier, we made that to reflect in the output. Also, we maximize the size of output if the user wanted that the size of the output should be maximized. That was not done, but we did that. And the 3D charts was implemented. We used high charts 3D for that. And for implementing the 2D charts and all, we used high charts. We added the zoom and exporting feature through which if the user wants a particular chart to be printed for him in PDF format or JPG or PNG, he could get that. He or she could get that. And the dynamic output generation was also done. So earlier it was like the whole XCOS file was simulated in the silab version. And then the output was given to the user. So imagine if for a short amount of time, it doesn't matter if for 60 milliseconds or somewhat. But if the simulation time is too long, like one lakh millisecond or one lakh seconds or so, then the user would have to wait so much long for that. But we have overcome that thing. So we have implemented that feature. So these were some more syncs block which we implemented. And block identification was also added. So if the user wanted to, if we want to know that the XCOS file contains some blocks in before simulating, we could know that now. And functionality for file download, like for binary files, for audio files, that was also added. And access to workspace. Basically XCOS contains a workspace also. So where we can save a variables. So we added that feature too. And now multiple graphs could be displayed. Like previously, no matter how many output blocks was there, only one output was given. Now the output is given for all the blocks. And we can even differentiate between different blocks of the same type. I will show you that in demo. So this is a sample output. I will just show the demo. Because we were having lack of time. In lunchtime, we prepared a video for this demo. If you want, we can show, but there will be unnecessarily time lag between the block connections. So we have made a video in lunch. If you want, so this is a video of outputting a C-scope. So this file contains a CM-scope block and two C-scope blocks. So here the output has come. And in the original version, we cannot see the points which comes. Like user sees a simulation, but he cannot hover over the point to see the values. We can do that through high charts or GS. Now I have changed the parameter to change the simulation time from to 600. So it will show the feature we implemented that we will show dynamic generation. Like the user did not have to wait for such long time 600 to get it simulated. It is being simulated simultaneously in the server as well as here. I just cross that to Kilsa-Cyler. This is the bar XY diagram. And I've shown the parameters. Now the parameters change will be reflected here. This is also done in a dynamic passion. Now we can zoom also and we can see the points too. So one last 3D diagram. This is a 3D block. Earlier the graph that will be generated is a 3D graph. Earlier only a PNG image was transferred from the server. So you cannot see the dynamic generation of the 3D graph. So 3D graph was also implemented. And we can also hover over the points. In original X-Cos we can't do that. Now Dutta will continue further. Doesn't that increase the server communication? Yes sir. So your dynamic is implemented by talking to your server? Yes sir, server. Thus simultaneously the thing is getting executed on server also and here also. Simultaneous execution or just transfer of data? So transfer the file is simulated there. It is executed once and then Dutta is only done. We implemented two way communication for TK scale. Let us first I will explain about what is TK scale block. TK scale block is a scale widget which allows user to choose a numeric value to the slider. And user can change the input during simulation or runtime. Mainly TK scale has three parameters. Minimum maximum normalization. Minimum maximum represent the input range and the output of the block is determined by the slider current value divided by the normalization factor. And the two way communication. Generally the two way communication is done by taking the values from the slider and generating the graph. And for this we first will generate the sliders based on the number of TK scale blocks. Also the plotting of the graph is dependent on the period parameter of the clock. So we found all the connections between TK scales and clock. That is the means TK scale means the clock one is the clock which has a parameter period. So the plotting of the graph is dependent on the period parameter. So we found in an experiment we found all the connections between TK scale and clock we found the parameters and used it and we create and we generate the slider. When the slider generates, we will take the value from the slider and we store in the file. So we will update every, we will update the file every time. Means whenever user changes the slider, we will update a new value, else the present value will be updated. Now for the two-way communication, the second phase will be plotting of the graph from these values. Basically the plotting of the graph should be done by taking values from the TK. Means the TK will send the values to the connected block. But we actually do not know how TK scale will send the values. Means we do not know the sending part. We only know about the receiving part. So we implemented in the backend which user cannot see. We replace the TK block by the, by another new block called R file read block which will take the input file and send it to the connected block. So this way means we are updating the values to a file and we'll send the file to the read block and it will send the values to the connected blocks like CM scope and CScope which will generate the graph. And this is the sample photo of our experiment and we'll show the demo. Means there are, we used in, considered this experiment. We used two CK blocks, one clock and CM scope. CM scope we generate the graph. We generate the sliders according to the count of TK scale. We used two TK scales so we generated two sliders. So whenever user changes the slider it should generate, it should reflect to the graph. This is how the two-way communication is done. Means we are changing, we are changing the values. Change in the values and TK scale are reflected in the graph that is written. Actually we are doing simultaneously read and write from the file for TK school. See in the, in the seconds, in the, in the second TK, in the TK scale too the present value is minus 3.8 and the output is minus 1.94 because it is because of the normalization factor. The output of the slider will be the input to the graph. Since it's a website, so how much time to render of the client's data? Sir, actually we are writing the whole data to the slider and we, and the file should be read, read and it should, and we should plot. So it will, it will take whole time. Means for writing, we are taking 0.1 second and for reading we calculated. Sir, it has to send the reference data to the scale scope. Yes, sir. Sir, no sir, what we are doing is actually when the user changes the slider, then only we'll update the data. Otherwise, we use the whole same data present in the file. Present, static, I can understand. That you don't have to do anything. But, that dynamic data is the same for when the moment you move the slider, the graph is changing, whatever is happening. That is great dynamic data. Yes, sir. Sir, it has to send the data from the server. Because the single user it is there. You must see any difference. But it has a number of users. It doesn't work. From 1 to 10. That's it will lag. But. We have to instantiate the users based on the session, session idea. So different users will, means, it will function. No. It will come to the same data what we have here. The session area is not up to. Sir, that data is just, it's just a logging of, logging to a file and reading. So I don't think it would take much lag. Yeah, we tried on two, means three simultaneous things. So, okay, we'll try for more, about 10. So we can try for at least five. Because we are six members, we can try for six. We'll definitely try and see what time lag is. In another new feature we implemented is XCOS for textbook companion. For this, we implemented a genetic method through which we will take the file contents and we'll directly generate a diagram without dragging and dropping the blocks. And, means, for this we have some features or specifications like each XCOS file should have a unique ID. And, we implemented a method called import XCOS which will make the, which will take the file contents and directly import on the web page. So, this can be further implemented or we can say that the future scope means implementing all the storing of files in the database and fetching the data directly from the database so that any user can view the examples on the server, on the cloud. And, this can be implemented. Thank you. There are 230 blocks in XCOS and there's defined get and set functionality for all these blocks which is written in SyLab language. Now, for the web version, we have to make code for all the blocks in JavaScript, but it was very difficult to manually write the JavaScript files for all 230 blocks. So, I developed a parser which directly converts the SyLab code which is already written into JavaScript file. And, so, now after the parser, after I made parser, the JavaScript files has been made and get and set functionalities are there for all the blocks. And, for the set and get functionalities, I had to implement some SyLab functions which are written in SyLab language into JavaScript language. And now, do we? So, adding to what my friends have done, after we set the parameters to change the block, to change the block parameters, this is how we submit them. So, after we click the submit button to the previous implementation, you can see that in the CM scope block, it shows that there are three input ports, but actually there are two input ports and the image is also getting lost. So, the previous implementation wasn't compatible with all kinds of blocks and moreover, image was getting lost. So, we have implemented it in order to reflect the correct changes which is to be expected. And the other problem we have faced is in the previous implementation, dynamic display of blocks were like, if the, this is constant, the value on the block keeps changing, but then the value is displayed as percentages. So, we have modified it so that the dynamic display of blocks will have the proper numericals. Then, like my friend has previously told that before, like, there were some blocks which weren't draggable. So, you can see that here, the block wasn't droppable on the graph. So, we have changed these blocks such that they are properly dragg and droppable and moreover, 73 blocks of the previous implementations were modified to.