A first look at how to use the S7–1500 Web API to interact with a CPU using JSON RPC2.0 and HTTP Requests
As of firmware version 2.8, the S7–1500’s web server is expanded to include a new ‘Web API’. This Web API allows an authenticated user to interact with the CPU via a web application. Using the Web API, a user can;
In this post, we’ll discuss the benefits of the new Web API and look at a demo of the Web API working with an S7–1500 Controller
The most powerful aspect of the new Web API is that it uses JSON RPC2.0. You may not know what this protocol is, but most web developers do.
JSON RPC2.0 is a standardized way to request remote devices to execute procedures and retrieve the results. That means that a web developer will be able to create web pages for a PLC without any knowledge of programming in TIA Portal or what a PLC really is.
Thanks to the Web API, Automation Web Programming (AWP) commands are no longer required to access data on the CPU. Even more importantly, there are no dependencies between custom web pages and the PLC program — SFC 99 does not need to be called to synchronize the user program and the webserver.
Thanks to the use of JSON data (instead of HTML, which was used previously), the data packets exchanged between the PLC and web pages are smaller. This helps to reduce the communication time between the PLC and web page and means that there is less load on the CPU while it is generating data and making it available. Overall, the Web API performs much better than the previous custom web pages.
To use the Web API to interact with an S7–1500, the Web Server of the CPU must be activated.
You can activate the Web Server in the hardware configuration of the CPU under Web server > General > Activate web server on this module
The Web Server only accepts secure access using the HTTPS protocol by default. Leave this box checked since the Web API only works using the HTTPS protocol.
Before interacting with the data of a CPU, a web application user must first authenticate themselves. Web server users are managed in the Web Server settings on the CPU.
For this demonstration, I’ll create a user ‘admin’ with the password ‘admin’.
In the Access Level configuration, I’ll give all authorizations to the admin user.
Save the project and download the Hardware Configuration to the PLC.
Now the Web Server is activated, a Web Server User is defined, and we can begin to interact with the PLC using the Web API.
On my computer, I’ll launch an example web page to demonstrate the Web API features.
After the web page opens in Chrome, I’ll also open the Developer Tools so that we can monitor the data exchange between the web page and the PLC.
After launching the web page, we are prompted to log in. In order for a user to interact with the CPU, they must be authenticated with the Web Server and they must have the correct authorizations.
I’ll click Submit to login and switch to the Network tab of the Developer Tools to see the data that was exchanged with the PLC.
In the Network tab, we can see that the web page sent a HTTP POST request to the PLC. In that request, we called the method ‘Api.Login’ and passed the username and password as parameters.
The Web Server responds with JSON data. When we inspect the data sent by the Web Server, we see that it includes a token.
This token must be sent with every subsequent request that requires authentication. If the token is not sent with the request, then the Web Server rejects the request and responds with an error code.
Each token expires after 2.5 minutes of inactivity. After that time, a user must login again.
If you want, you can use the method, Api.Ping to prevent the token from expiring.
Once authenticated, the Web API can be used to write data to PLC tags.
In my example web page, I fill out values for the turbine speed, turbine acceleration and, turbine jerk tags. I click the ‘Update with desired values’ button to send a request with this information to the PLC.
If we examine the request, we can see that the method PlcProgram.Write is used to write tags in the PLC. The tag and the value are passed to the method as parameters.
The Web Server responds and indicates if the writing operation was successful.
In the same way, we can read tag values from the PLC using the method PlcProgram.Read. We pass the symbolic name of the tag to be read to the method as a parameter.
Upon receiving the request, the Web Server responds with the actual value of the tag.
In the Network tab of the Developer Tools window, you can see the loading times of each request and reply.
If you’ve worked with AWP commands before, you should immediately notice that the loading times of the Web API requests and responses are much shorter.
This improvement comes from the fact that lightweight JSON data is exchanged with the Web Server instead of HTML (as with AWP commands).
The examples we’ve looked at so far used a pre-defined web application to exchange data with the Web Server via the Web API. However, since the Web API uses JSON RPC2.0 you can paste requests directly into the Developer Tools console and execute them immediately.
This is very useful for testing code fragments to find mistakes in, for example, tag identifiers.
In the example below, I create a read request with an incorrect tag identifier into the Developer Tools Console. The Web Server responds with an error code indicating that the tag I am trying to read doesn’t exist.
The new S7–1500 Web API makes it easy to link a CPU to a web API for control and data acquisition.
By using an open and standard interface, the Web API makes it easy for web developers to access information in a CPU without any knowledge of TIA Portal or PLCs. This is a big improvement over the previous Automation Web Programming web interface.
The Web API can be used to easily create web-based dashboards, HMIs, and commissioning tools. Outside of creating standalone tools, the Web API can be used to connect a PLC to web data consumers such as SCADA and MES systems.
The best part about the new S7–1500 Web API is that it's available for free in all S7–1500s using firmware 2.8 or greater — that means that you start experimenting with it today without worrying about licenses or options.
We help OEMs to get the most out of their engineering teams using systems, standards and automation.
See how you can reduce costs and increase quality by working with us:
As teams grow, they become chaotic. Different team members have different needs, knowledge is tribal, and everyone has their own ideas about best practices and processes.
How can you get everyone to follow the same playbook and ensure that best practices are being used?
End users are becoming more sophisticated. They expect increasingly complex machines delivered faster and with less mistakes.
How can your team meet and exceed the demands of your customers?
Your most expensive resource is under-utilized. Engineers waste countless hours on projects doing repetitive, low-value add tasks.
Learn how to automate the boring stuff to reduce your costs and reclaim your team's time.