The raise_for_status function waits for the response.<\/p>\n
r.raise_for_status()\r\nversion_json = r.json()\r\nversion = version_json[\u2018apiVersion\u2019]<\/pre>\nThe version number is important because it is used in all endpoint requests. Fortunately, WebDAQs currently have only one version, \u2018v1.0\u2019. So, our URLs will always begin with the IP address followed by \/api\/v1.0\/:<\/p>\n
basel_url = \u2018http:\/\/\u2019 + \u2018192.168.100.100\/api\/v1.0\/\u2019<\/pre>\nIf you are wondering how to obtain the IP address, Python makes this easy with the socket module.<\/p>\n
import socket\r\nip_address = socket.gethostbyname(\u2018webdaq-xxxxxx\u2019)<\/pre>\nwhere xxxxxx are the lower six digits of the factory-assigned MAC address. This works with the factory-assigned name as long as it is unchanged. If it was changed in the Browser UI, then use the new name.<\/p>\n
A more meaningful WebDAQ operation is to get the schedule because it contains the job name(s) that will be used to request the job JSON.<\/p>\n
request_response = s.get(base_url + \u2018\/schedule\/descriptor\u2019)\r\nrequest_response.raise_for_status()\r\nschedule_json = request_response.json()\r\njobs = schedule_json[\u2018jobs\u2019]<\/pre>\nHowever, when the WebDAQ is powered on, its schedule may not be set for auto-start, which means it is not in memory. Therefore, before retrieving the JSON code for the job, we must check the status and, if necessary, load the schedule.<\/p>\n
schedule_status_endpoint = base_url + \u2018\/schedule\/status\u2019\r\nschedule_status_response = s.get(schedule_status_endpoint)\r\nschedule_status_response.raise_for_status()\r\nschedule_status_json = schedule_status_response.json()\r\n<\/pre>\nAn empty status means the schedule must be started to load it into memory:<\/p>\n
if schedule_status_response[\u2018statusCode\u2019] == ScheduleStatus[\u2018empty\u2019]:\r\n r = s.post(schedule_status_endpoint, json={\u201crun\u201d:True})<\/pre>\nIf you wish to modify a job configuration, such as the number of samples to acquire, get the job JSON code and access the appropriate property. For example, to change the number of samples to acquire we can do this:<\/p>\n
jobs = schedule_status_json[\u2018jobs\u2019]\r\njob_name = jobs[0]\r\njob_descriptor_endpoint = base_url + \/schedule\/jobs\/\u2019 + job_name + \u2018\/descriptor\u2019\r\njob_descriptor_response = s.get(job_descriptor_endpoint)\r\njob_descriptor_response.raise_for_status()\r\njob = job_descriptor_response.json()\r\njob[\u2018acquisition\u2019][\u2018stopTrigger\u2019][\u2018sampleCount\u2019] = new_count\r\n<\/pre>\nWe can also modify the channel list besides changing acquisition settings. The following is an example of the JSON descriptor from a WebDAQ 504 IEPE channel, typically used with dynamic sensors such as an accelerometer.<\/p>\n
IEPE = [{'number': 0,\r\n 'type': 'acceleration',\r\n 'www': {'productId': 316,\r\n 'color': '#DD3222',\r\n 'dashboardScalar': True,\r\n 'dashboardStripChart': True,\r\n 'dashboardFFT': True,\r\n 'showFFTPeak': True,\r\n 'fftWindowType': 'none',\r\n 'fftIntegration': 'none'},\r\n 'name': 'Camshaft',\r\n 'range': '12',\r\n 'unit': 'psi',\r\n 'couplingMode': 'ac',\r\n 'iepe': True,\r\n 'sensorSensitivity': 1,\r\n 'customScaling': {'type': 'linear', 'linear': {'multiplier': 1000, 'offset': 0}}}]\r\n<\/pre>\nWe can use it as a template to rewrite the channel list. First, we delete the items from the list using the pop() method.<\/p>\n
While len( job[\u2018channels\u2019] ):\r\n\tDummy = job[\u2018channels'].pop()\r\n<\/pre>\nThen, we can make a copy of the template. We want a completely independent copy of the template object, so we use the Python deepcopy method like this:<\/p>\n
Accelerometer0 = copy.deepcopy(IEPE)\r\nAccelerometer1 = copy.deepcopy(IEPE)\r\n<\/pre>\nThe channels must be assigned a number beginning with zero and have a unique name.<\/p>\n
Accelerometer0 [0][\u2018number\u2019] = 0\r\nAccelerometer0 [0][\u2018name\u2019] = \u2018Camshaft sensor\u2019\r\n\r\nAccelerometer1 [0][\u2018number\u2019] = 1\r\nAccelerometer1 [0][\u2018name\u2019] = \u2018Crankshaft sensor\u2019\r\n\r\njob[\u2018channels\u2019].extend(Accelerometer0)\r\njob[\u2018channels\u2019].extend(Accelerometer1)\r\n<\/pre>\nUpload the modified job descriptor.<\/p>\n
r = s.post(base_url + \/jobs\/job1\/descriptor\u2019, json=job)\r\nprint(\u2018Status response = \u2018 + str(r.status_code)\r\n<\/pre>\nThe WebDAQ will check the uploaded JSON job descriptor and return 200 if no errors are found. So, ensure that the status response indicates 200 and not 400.<\/p>\n
Next, now that we made the changes we want to the job descriptor, we can request the WebDAQ send back data from the current job. This could be helpful for automatic monitoring. For instance, you could need to monitor many WebDAQs to ensure the measurements align with expectations.<\/p>\n
The data request URL format for our job named \u2018job1\u2019 is:<\/p>\n
base_url + \u2018\/schedule\/jobs\/job1\/samples\/index\/max_count\/bin\u2019<\/pre>\nThe index parameter starts at zero and advances with each request. The max_count is the amount of data to request and must not exceed 10000. Here, we set the index to zero and use GET to request data:<\/p>\n
index = 0\r\ndata_request = base_url + \u2018\/schedule\/jobs\/job1\/samples\/\u2019 + str(int(index)) + \u2018\/100\/bin\u2019\r\ndata = s.get(data_request)\r\ndata.raise_for_status()\r\n<\/pre>\nNow that data contains data, we must determine how much data it gave us. This is done by dividing the buffer length by the number of channels times the data type size, which is eight bytes for the double data type.<\/p>\n
num_of_samples = len( data.content ) \/ 8 * len( job[\u2018channels\u2019] )<\/pre>\nNext, we need to convert the string of binary codes to meaningful numbers. To do this, we use calcsize and unpack from the Struct module. First, we create a format string specifying ‘d\u2019 for the double data type. We then get the size and use it to unpack the string of binary codes into an array of usable numbers.<\/p>\n
read_format = str( int(num_of_samples * num_of_channels ) + \u2018d\u2019 )\r\nread_size = calcsize(read_format)\r\nnumpy_data = array( unpack( read_format, data.content[0: read_size] ))\r\n<\/pre>\nMore data can be read with another request, but we must advance the index by num_of_samples. It is also good to check the job status after each read to ensure it has stopped.<\/p>\n
read_format = str( int(num_of_samples * num_of_channels ) + \u2018d\u2019 )\r\nread_size = calcsize(read_format)\r\nnumpy_data = array( unpack( read_format, data.content[0: read_size] ))\r\nfor chan, item in enumerate(channels):\r\n print('{:2.5f}'.format(numpy_data[int(chan)]), item['unit'], ' ', end='')\r\n<\/pre>\nDepending on the WebDAQ and the rate at which data is being acquired, you could get old data. The WebDAQ 504 can acquire data quickly; by the time you have requested 100 samples, it may have recorded several thousand. To minimize this, query the job status for \u2018samplesAcquired\u2019 and subtract 100 to get the most recent data.<\/p>\n
The purpose of this article was to give you an idea of what is possible with the REST API. The code samples were not meant to be pasted into a program; they were provided merely for demonstration. We covered only the minimum necessary for control. We began by requesting its API version and finished by retrieving live data. In between, we modified a single property in the job JSON code called \u2018sampleCount\u2019, and showed how to modify the channel list. We used Python for the demonstration but could have used C#, VB.NET, and LabVIEW. For a complete example program, go to the support page for any WebDAQ to download Digilent\u2019s suite of REST API example programs. The read_data.py example provides all the checking necessary when reading data.<\/p>\n
