Shulou(Shulou.com)06/01 Report--

This article mainly introduces "how ServerSuperIO forms loop control". In daily operation, I believe many people have doubts about how ServerSuperIO forms loop control. The editor consulted all kinds of data and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts about "how ServerSuperIO forms loop control". Next, please follow the editor to study!

21.1 Overview

The previous work done by ServerSuperIO gradually lays the foundation for the formation of loop control or cascade control, such as the development and application of service connectors and device-driven connectors. In short, it is through a variety of forms to issue commands to control the device (drive) or sensor, cloud control station or monitoring point sensor, App or other terminal control sensor, according to the sensor data collected by the sensor to control another sensor and so on.

Here's how the cloud, App, or other terminals control sensor devices (similar to sensor control sensors, see: 12. The development of service interfaces and two-way interaction with the cloud. According to the communication protocol, the structured scheme does not need too much code to complete the corresponding function. The effect is as follows:

21.2 structural schematic diagram

The control side initiates the control command, develops a simple proxy service with the ServerSuperIO service interface, and interacts with the device driver through the service connector IServiceConnector interface. After receiving the control command, the device driver sends it to the device or sensor, waits for the confirmation message returned by the control, and then returns to the control side.

21.3 communication protocol

Some people ask why not use the MQTT protocol, and how can it be compatible with the protocols of different devices and sensors? In view of the actual situation in China, it is obvious that it can not reach the level of a unified standard, and in a bad economy, it is impossible for enterprises to invest in replacing the original hardware equipment. It is also not in line with the principle of ServerSuperIO design, that is, protocol independence, and any standard or non-standard protocol can be integrated. If you want to cross a river, repair the bridge, set up the ropeway, set up the boat. It's up to you to decide how to cross the river.

Someone asked what protocols have been integrated into ServerSuperIO? The answer has been given above, and what I want to say is that there is no framework that can cure all diseases. From the opposite point of view, if any protocol is added like configuration, how much value the enterprise wants to give for peer-to-peer exchange, so the protocol driver should be written by everyone.

The protocol we demonstrate is shown in the following figure:

21.4 control terminal

There are many kinds of control side: sending control commands to subordinates in the cloud, sending control commands to App or PC software connection service, and so on. Send control commands as shown below:

21.5 proxy service (SSIO service interface)

The proxy service is implemented through ServerSuperIO's IService interface. In the inheritance class, the proxy service is developed using the singleton pattern of the ServerSuperIO framework itself. The code is as follows:

+ View Code

The dev.ReceiveRequestInfos event is the event interface that the control driver inherits the extension of the RunDevice driver class in the ServerSuperIO framework. The ServerSuperIO singleton pattern receives the data information, and if it conforms to the protocol standard, it will feedback the data information to the driver's Communicate interface, and the ReceiveRequestInfos event will transmit the data information to the Dev_ReceiveRequestInfos function of the proxy service subscribing to the event. The code is shown below:

The Dev_ReceiveRequestInfos function in the proxy service passes the information to the corresponding device driver according to DeviceCode (addr) through the service connector interface IServiceConnector. The code is shown below:

The proxy service receives the result information feedback from the device driver through the ServiceConnectorCallback and ServiceConnectorCallbackError function interfaces. If there is an exception in the middle, ServiceConnectorCallbackError will be called, and if the ServiceConnectorCallback function is called normally, the ServiceConnectorCallback function interface will send the result to the controller according to the corresponding relationship between the recorded command and the IO channel. The ServiceConnectorCallback code is shown below:

There is a note in this, that is, the device driver does not feedback the confirmation of the control command within a specified period of time, that is, the sensor does not feedback the corresponding information. In this case, a timing detection service is added. If there is no feedback on the timeout, the corresponding message is sent to the controller. The code is shown below:

21.6 device driver

The device driver corresponds to the sensor and interacts with each other. The device-driven RunServiceConnector interface is responsible for receiving the command information passed by the proxy service Dev_ReceiveRequestInfos (OnServiceConnector) function. The code is shown below:

There are two points: 1. After receiving the command data, you can immediately send the data information through the OnSendData function to find the corresponding IO channel with the set IP, which is suitable for the automatic control mode. two。 After receiving the command data, put it in the this.Protocol.SendCache protocol cache and wait for the command to be issued, which is suitable for polling and concurrent mode.

For the isAsyn parameter of the returned result object ServiceConnectorCallbackResult, if it is true, the result information is returned through AsyncServiceConnectorCallback callback, that is, you have to wait for the sensor to return the confirmation information, and the device driver receives it and then feedback it to the proxy service; if it is false, the description will immediately feedback to the proxy service, which is suitable for transmitting data information regardless of whether the interaction with the sensor is successful or not.

You can temporarily save the callback parameter in this function, wait for the sensor to return a confirmation message, and then trigger an asynchronous callback to the proxy service in the Communicate function. The code is shown below:

21.7 Demo description

Open two TestDevice programs, one as the device sensor and the other as the control side, the DeviceCode should respond; TestDeviceDriver is the device driver, loaded in the service instance, I use the automatic control mode, using the TestSelfMain project; ControlDeviceService is the proxy service, loaded in the TestSelfMain.

At this point, the study of "how ServerSuperIO forms loop control" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.