Methods to Transmit LabView Data to Google Sheet

Size: px

Start display at page:

Download "Methods to Transmit LabView Data to Google Sheet"

Judith McDonald
5 years ago
Views:

1 American Society for Engineering Education (ASEE), Northeast Section Annual Conference, April 27-28, 2018 Methods to Transmit LabView Data to Google Sheet Tung Pham and Douglas E. Dow Abstract LabView is a high-level programming language used for the development of many applications, including data acquisition, monitoring, and simulation. In many situations, LabView generated data needs to be utilized by others, some on remote or mobile devices. Examples include internet of things, aggregation of multiple sensor network data, or decision makers by, stakeholders. A health application that monitors an individual's physiological state may need data accessible by clinical staff, caregivers or the patient themselves. One useful media that would be accessible by all stakeholders is the cloud data storage and analytics capability of Google Sheets. Google Sheets is capable of storing and analyzing data, creating graphs and sending alerts to multiple stakeholders. The goal of this project is to develop a pathway and document several methods to transmit data from LabView to Google Sheets, and then for Google Sheets to analyze, graph and send alerts as appropriate. Several methods have been tested, including using in between web servers, client JavaScript code, and the Google Apps Script. Development of robust methods to transmit data from LabView to Google Sheets would enhance the capabilities of many applications. Index Terms Google Apps Script, web service, data transfer I. Introduction Data acquired at remote nodes often needs to be sent to a central site for storage, analysis, and communication of results. Sensor networks in industrial or environmental applications need to aggregate the data. The data from medical sensors from personal health devices should be monitored by medical staff, caregivers, or the patient. Internet of things (IoT) includes similar issues, using internet communication and cloud storage for data gathering and analysis. One example is a health application, where a patient s physiologic measurements are monitored, stored in the cloud, and periodically analyzed, with the results communicated to medical staff, caregivers, or the patient [4]. Labview (National Instruments, Austin, TX) is a high-level programming language that is well suited for data acquisitions (DAQ), data analysis and simulation. Many companies use LabView as a tool to keep track of their data and predict outcomes, including MKS Instrument, Cytokinetics, and National Instrument [3]. LabView is designed to work with many DAQ modules, for signal processing, graphing, user interfaces, and connectivity. Many engineers and scientists consider LabView to have a more intuitive environment for the development of applications. One cloud-based site that is suitable for data storage, analysis, graphing and communication of results is Google Sheets. Google Sheets is a powerful tool for storage and analysis. It is simple to use, accessible and used for many small projects and developments, provides access to those that have permissions. With cybersecurity provided by Google, the data is secure and can be accessed as long as there is an internet connection. Besides the graphical user interface, a programming interface for Google Sheets is available with Google Apps Script. The Apps Script allows custom-algorithms to be developed for analysis and detection of alerts, that can then be sent to appropriate stakeholders, including by . Information is available on how to use the Google API to access Google Sheets from several platforms, including Java, JavaScript, PHP, Go,.NET, Ruby, and Python [5]. However, examples of how to access Google API from LabView could not be found. The goal of this project was to develop and document several methods to transfer data from a LabView program to Google Sheets. Such information should help many developers who use LabView to enhance their applications with cloud storage and communication. II. Methods Method 1: Local Storage and JavaScript On Google Drive, a Google Sheet was set up with 4 sheets, with each sheet named as follow: Main, da, db, and dc. Each sheet will later have data appended to the bottom of the sheet as described below. For the prototype, custom Google Apps Script code was developed and bound to a Google Sheet where the data was transferred into. The first step was to open a script code editor from the Google Sheet. In the sheet document on Google Drive, the menu Tools Script editor was selected to open a script editor for code that was then bound to this sheet (Fig.4). Fig.4: Graphical User Interface of Google Sheet showing how script editor was opened to write custom code that is bound to this sheet. Next, to allow the use of Google API, an API key and Client Key was then registered. In the Script just created, the menu Resource Cloud Platform Project was selected and a pop up appeared. The link was selected to go to Google API window (Fig.5)

6: Shows how to access the API & Services menu to create credentials and enable the API For setting up of credentials, the menu API & Services Credentials Create credentials was selected to create

2 var dcsensorval ; var time; Fig.5: Shows how Google API window was opened to enable the use of Sheet API. First, the API was enabled as follows, under Google Cloud Platform, the menu API & Services Library was selected and the Google Sheet API was selected to enable the API. Fig.6: Shows how to access the API & Services menu to create credentials and enable the API For setting up of credentials, the menu API & Services Credentials Create credentials was selected to create API Key. The string provided was saved for later use. Then the Create credentials option was clicked again followed by Create OAuth Key, and then Web Application. The key was renamed and the JavaScript server link was entered. The port was selected as localhost:8001 since 8001 is the port on the PC that was used. The Client ID was saved for later use, and the tab was closed. A HTML and JavaScript program was developed to transfer data from the local file to Google Sheet. The HTML file referred to the JavaScript code, file with the following link. <script src = "index.js" ></script> <script async defer src=" onload = "this.onload=function(){;handleclientload()" onreadystatechange = "if (this.readystate === 'complete') this.onload()"> In the JavaScript file, the following code was used to initialize the variables. var API_KEY = 'Insert the API key created' ; var CLIENT_ID = 'Insert the Client key created' ; var DISCOVERY_DOCS = [ " " ] ; var SCOPES = " " ; authorizebutton = document. getelementbyid ( 'signin-button' ); var signoutbutton = document. getelementbyid ( 'signout-button' ); var filename = "XML.xml" ; var intervaltimer = 5000 ; var dasensorval ; var dbsensorval ; In the above code segment, the variable intervaltimer set the amount of time of delay between updates to read the local file and send to Google Script. In this example, the delay period was 5 seconds. The codes took reference from the Google Developers guide page [7] with the following modification. function handleclientload() { gapi.load( client:auth2, setinterval(initclient,intervaltimer)); The API key and Client key that was created earlier was changed. The function handleclientload loads the API from Google library and executes the function inside the parentheses. In this case, since the function call was placed in this function, a callback was designed to create a loop using the built-in JavaScript function named setinterval to call the function after the designated delay time. Once the initclient function was called, the Client ID and API key were used to gain authentication to the document. The updatesigninstatus function determined whether the client has signed into their Google account associated with the document, and will ensure the user is signed in. The makeapicall function was used to append the value to the range that was passed as a parameter to the function [6]. The following code was used to do data collection from local file before the handleclientload function was called. function dohttprequestforsensorval (){ console. log ( "Timer done. Callback function called. Now prepare to send HTTP Get\n" ); reqw = new XMLHttpRequest (); // Make object to do this HTTP request reqw. onreadystatechange = cbhttpreqlistenergetsensorvalanddisplay ; // set callback function reqw. open ( "get", filename, true ); // Define as Get HTTP, and the URL reqw. send (); // send the msg over web The dohttprequestforsensorval function will initialize a HTTP GET method to get the value from the local file that contains the data from LabView. When initialized, the variable filename holds the file name of the storage that will be used. In this prototype, the file name of the local file was xml.xml and was located in the same folder with the html file and JavaScript file. Next, the cbhttpreqlistenergetsensorvalanddisplay function also does a xml parser to access the data stored and assign it to variables that were named as time, dasensorval, dbsensorval and dcsensorval using code took reference from W3Schools website [1]. The variable time held the timestamp of when the value was passed from LabView. The other variables were passed to the makeapicall function [5]. In Sheet s A1 notation, the sheet s name goes first then a! and then the range that the user wants to make a change. The sheet s name inside the quotation mark makes the Google API find the sheet with the exact name to make a change. The sheetid indicates which sheet to write the data to. For the prototype, the following LabView program was developed, as shown in Fig.7

$tmp file and return the data in XML format. <body> <? php // Use the same filepath as in the writeval.php file $filepath = "C:\WINDOWS\Temp\DataStorage.$ tmp" ; $filedatalst = file ( $filepath ); //print out the data in xml format printf ( "<p><time>%s</time>",( string ) $filedatalst [ 0 ]); printf ( "<da>%f</da>",( float ) $filedatalst [ 1 ]); printf

tmp" ; $filedatalst = file ( $filepath ); //print out the data in xml format printf ( "<p><time>%s</time>",( string ) $filedatalst [ 0 ]); printf ( "<da>%f</da>",( float ) $filedatalst [ 1 ]); printf

3 printf ( "<p> Wrote %s, %f, %f, and %f in the file %s </p>", $Val [ 0 ], $Val [ 1 ], $Val [ 2 ], $Val [ 3 ], $filepath );?>. In the read PHP file, the following custom code was developed to read the data stored in DataStorage.tmp file and return the data in XML format. <body> <? php // Use the same filepath as in the writeval.php file $filepath = "C:\WINDOWS\Temp\DataStorage.tmp" ; $filedatalst = file ( $filepath ); //print out the data in xml format printf ( "<p><time>%s</time>",( string ) $filedatalst [ 0 ]); printf ( "<da>%f</da>",( float ) $filedatalst [ 1 ]); printf ( "<db>%f</db>",( float ) $filedatalst [ 2 ]); printf ( "<dc>%f</dc></p>",( float ) $filedatalst [ 3 ]);?> < /body> Fig.7: LabView block diagram of a program that every 2 seconds, writes a timestamp and three data values to a local file. The associated HTML-JavaScript program then read the local file and send the data to Google Sheet. Using the POST method from the LabView, the data values were concatenated into the XML string. The Simple XML [8] function was then used to structured and update the XML file on the local PC. The computer running the LabView program and client HTML JavaScript program also needed a web server on the same computer. This allowed hosting of the client files and reading of the local file. In the prototype, a Python web server was installed on a Window PC [2]. Python was installed from The command prompt or PowerShell was run in the directory that the Python files were placed in. The following command was used to have the computer host the web app: $python -m http.server In an open web browser, the following URL was entered localhost:8000/name of the HTML File/ to open the locally hosted website of the HTML-JavaScript code that would read the local file of LabView data and send to Google API then run the LabView program. In the JavaScript code needed here is similar to that used in method 1. The variable filename was replaced with a variable name URL that has the link as string to the write PHP file. In this demonstration, the string would be In the JavaScript file, make the following modification to the cbhttpreqlistenergetsensorvalanddisplay function. var newdavalasstrg = findvalueinresponsexml ( this. responsetext, 1 ); var newdbvalasstrg = findvalueinresponsexml ( this. responsetext, 2 ); var newdcvalasstrg = findvalueinresponsexml ( this. responsetext, 3 ); var time = findvalueinresponsexml ( this. responsetext, 4 ); The PHP on the server returns XML formatted response to the JavaScript program. The XML response text can be analyzed with string comparators to isolate the four parameter values for time, da, db and dc. The response text is searched and the data values isolated. The LabView program used for the prototype was developed as shown in Fig. 8. Method 2: Web Storage and JavaScript A second method to transfer data from LabView to Google Sheets was also developed. This method passed data from LabView to an in between cloud HTTP web service. Then a JavaScript program passed the data on to Google Sheets. On the Google API credentials as described above, the Client key was edited. In the Authorized JavaScript origin section, the domain of the third party server that was to be used was added. In the prototype, a server provided by our institute, called MyWeb, was used. Two PHP files were developed. One PHP file handled the storage of data. The other PHP file handled the retrieval of data. In the Write PHP file, the following code was used to receive data sent from LabView and store in a data storage file. <? php $Val = array ( $_POST [ "time" ], $_POST [ "da" ], $_POST [ "db" ], $_POST [ "dc" ]); printf ( "<p> Write Value %s, %f, %f, and %f that is being passed in to a file </p>", $Val [ 0 ], $Val [ 1 ], $Val [ 2 ], $Val [ 3 ]); $filepath = "C:\WINDOWS\Temp\DataStorage.tmp" ; // Fixed path on myweb.wit.edu server // Write a value to the file $myfile = fopen ( $filepath, "w" ) or die ( "Unable to open file!" ); for ( $x = 0 ; $x <= count ( $Val ); $x ++){ fwrite ( $myfile, $Val [ $x ]); fwrite ( $myfile, "\n" ); Fig.8: LabView block diagram for Method 2 prototype program. Method 3: Direct Google Apps Script A third method was developed to directly transfer data from LabView to a custom Google API script that stored the data in Google

Sheets. On Google Drive, a new Google Apps Script was opened III. Results Fig. 10: Shows the result data in the Main sheet after a test run Fig.9: Shows how to open an independent Google Apps Script.

4 Sheets. On Google Drive, a new Google Apps Script was opened III. Results Fig. 10: Shows the result data in the Main sheet after a test run Fig.9: Shows how to open an independent Google Apps Script. The Spreadsheet API was enabled from Google Cloud Platform as described in method 1. The Script contained the following custom code for the prototype. function dopost ( e ){ // Parse out the URL parameters param = e. parameter ; time = param. time ; da = param. da ; db = param. db ; dc = param. dc ; sheet = SpreadsheetApp. openbyid ( '1pi7ffBCa6RuDz86BmXbxUIFb kzfe3kliuzybh4a 9nk' ); dasheet = sheet. getsheetbyname ( 'da' ). appendrow ([ time, da ]); dbsheet = sheet. getsheetbyname ( 'db' ). appendrow ([ time, db ]); dcsheet = sheet. getsheetbyname ( 'dc' ). appendrow ([ time, dc ]); Main = sheet. getsheetbyname ( 'Main' ). appendrow ([ time, da, db, dc ]); Fig.11: Shows the data result in the da sheet after a test run The dopost function is a function that handles any POST requests sent to the web app when deployed [10]. The SpreadsheetApp was used to access the Sheet API from Google Apps Script. In the prototype, a method called appendrow was used that added the data to a new row at the bottom of any existing data in the Sheet. The script was deployed as a web application. The menu Publish Deploy as Web App was selected [10]. A pop-up appeared, follow with an URL provided at the beginning that was noted for later use. The script was deployed as new [9]. In LabView, the previously described LavView vi was modified to use the Google App URL for the POST VI. Fig.12: Shows the data result in the db sheet after a test run

5 Fig.13: Shows the data result in the dc sheet after a test run Fig. 10 shows the result after the test run, the data was successfully appended to the existed table in the Main Sheet with 4 variables timestamp, da, db, and dc. Fig. 11, 12, and 13 shows the result of data being successfully sent and appended to the table in 3 sheets da, db and dc accordingly on the Sheet. IV. Discussion In Method 1 (Local Storage and JavaScript), the implementation process took less time since many examples and tutorials were found for developers of JavaScript, HTML, and XML. Information was also readily found on Google Developers site to connect to Google API without having to develop custom Google Apps Script code. Method 1 has four main components of LabView, a local web server, locally hosted client page ( HTML-JavaScript files) and the shared local file on the computer that the LabView program was running on. The process of updating the files and making changes was convenient during development, not having to upload the files to a remote web server. The method could be helpful for a website to collect data like a survey or creating a personal database to store data that the client code has access to. Method 1 may also be suitable for startup companies that want to set up their own website with dynamic features. However, the system has a greater risk in cybersecurity since JavaScript is accessing the file on the client machine. By accessing the files on the computer running the application, there may be a risk of some data being inadvertently accessed. Yet, Method 1 may still be most suitable as a method to access the Google API since developers increasingly use storage on the client side to help increase the speed of data transmitting. On the other hand, by using this method, some computation time is lost in executing the server and website component. The computer running LabView also needs to host the server and client website. In Method 2 (Web Storage and JavaScript), the implementation process was only a little more involved, many example and tutorial were also found for PHP and JavaScript developers. However, this method required a second server to host the client web files and to act as middlemen storage of data. This system does lower the cybersecurity risk of exposing the local computer s data by having a second server handle the storage and retrieval. Having a remote server may increase the risk of others maliciously attempting access. Therefore, finding a trustworthy and secure server to host the files is important, especially if the data flow is critical or sensitive. Since most companies have their own domain, to set up such a website within, the existing web services may be possible. If the LabView application has multiple remote sensor locations like an IoT sensor network, then having each LabView node send the data to a web-based server may be a good design. Since the files are hosted on a remote server, the function may be able to run even if the computers running the LabView applications become temporarily inactive. But the data path has an extra path segment to the remote server. Since the data would go from the client s computer to the PHP files on the server, then accessed by the JavaScript files and sent on to Google Sheet. This may also insert a delay. If any of the links has a problem, the whole data communication would become impaired. Every change or update would need to be uploaded to the server. In Method 3, there was no need for another server since LabView directly communicated to Google Apps Script as a server to host the web application. Method 3 may be considered faster for overall transmission, since the path was a 1-to-1 pathway. With less middleman software, the developers could focus on developing code for the two ends, LabView and Google Sheet. The data was sent by POST request, providing a level of security during the transmitting process. The system still has some risks. The Google API is published and may be inadvertently accessed. Therefore, it has a risk of attack by any DDoS, which may add data to overwhelm the storage capacity of Google Drive, or exceed the amount of data that can store in a spreadsheet document. Methods to counter this risk should be investigated prior to deployment. V. References [1] AJAX XML Example. W3Schools, [2] Browser Quickstart. Google Apps Script Developers, [3] C. Elliott et al, "National Instruments LabVIEW: A Programming Environment for Laboratory Automation and Measurement," Journal of the Association for Laboratory Automation, vol. 12, (1), pp , DOI: /j.jala [4] Douglas E. Dow, Yukio Horiguchi, Yoshiki Hirai, Isao Hayashi, "Monitoring of Respiratory Cycles Utilizing Sensors on Sleeping Mat", Proceedings of the ASME 2017 International Mechanical Engineering Congress and Exposition (IMECE2017), Nov. 3-9, 2017, Tampa, Florida, USA [5] Introduction to the Google Sheets API. Google Apps Script Developers, [6] Method: spreadsheets.values.append. Google Apps Script Developers, values/append. [7] Reading & Writing Cell Values. Google Apps Script Developers, [8] Simple XML Generation Reference Library. National Instruments, May 06, 2010, [9] Versions. Google Apps Script Developers, [10] Web Apps. Google Apps Script Developers,

Sticky Notes for Cognos Analytics by Tech Data BSP Software

Sticky Notes for Cognos Analytics by Tech Data BSP Software Installation Guide Sticky Notes for Cognos Analytics is an easy to install extension that allows report authors to record notes directly from