Share terminal control sensors or devices to form loop control instances

21.1 Overview

ServerSuperIO’s previous work has gradually laid the foundation for the formation of loop control or cascade control, such as the development and application of service connectors and device driver connectors. In short, commands are issued through various forms to control devices (drivers) or sensors. The cloud controls the sensors at sites or monitoring points, the App or other terminals control the sensors, and controls another sensor based on the data collected by the sensor.

The following describes how the cloud, App or other terminals control sensor devices (sensors control sensors are similar, please see: 12. Development of service interfaces and two-way interaction with the cloud). According to the communication protocol, the structured solution does not require too much code to complete the corresponding functions. The effect is as follows:

21.2 Structural diagram

The control terminal initiates a control command and uses the ServerSuperIO service interface to develop a simple The proxy service 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 it to the control terminal.

21.3 Communication Protocol

Some people ask why not use the MQTT protocol. How can it be compatible with the protocols of different devices and sensors? Based on the actual situation in China, it is obvious that it has not yet reached the level of unified standards. Under economic conditions, it is impossible for companies to invest in replacing the original hardware equipment. It also does not conform to the principle of ServerSuperIO design, which is to achieve protocol independence, and any standard or non-standard protocol can be integrated. If you want to cross a river, you need to repair the bridge, set up the ropeway, and arrange the boat...it is up to you to decide how to cross the river.

Someone asked what protocols ServerSuperIO is integrated with? The answer has been given above, and what I want to say is that no framework can cure all problems. Thinking from the opposite perspective, if any protocol is added like configuration, how much value does the enterprise want to give for peer-to-peer exchange, so the protocol driver is left to everyone to write by themselves.

The protocol we demonstrated is as follows:

21.4 Control end

The control end includes many types: the cloud sends control commands to the lower level, App or PC software connects to the service to send control commands, etc. Send control commands as shown below:

21.5 Proxy service (SSIO service interface)

Proxy service is implemented through the IService interface of ServerSuperIO and is used in inherited classes The ServerSuperIO framework itself develops proxy services in singleton mode. The code is as follows:

public override void StartService()
        {
            string devId = "ControlDeviceService";
            Driver dev = new Driver();
            dev.ReceiveRequestInfos += Dev_ReceiveRequestInfos;
            dev.DeviceParameter.DeviceName = "控制设备驱动器";
            dev.DeviceParameter.DeviceAddr = 0;
            dev.DeviceParameter.DeviceID = devId;
            dev.DeviceParameter.DeviceCode = "";
            dev.DeviceDynamic.DeviceID = devId;
            dev.DeviceParameter.NET.RemoteIP = "127.0.0.1";
            dev.DeviceParameter.NET.RemotePort = 9600;
            dev.DeviceParameter.NET.ControllerGroup = "LocalGroup";
            dev.CommunicateType = CommunicateType.NET;
            dev.Initialize(devId);

            IServer server = new ServerManager().CreateServer(new ServerConfig()
            {
                ServerName = "控制设备服务",
                ListenPort=6670,
                ComReadTimeout = 1000,
                ComWriteTimeout = 1000,
                NetReceiveTimeout = 1000,
                NetSendTimeout = 1000,
                ControlMode = ControlMode.Singleton,
                SocketMode = SocketMode.Tcp,
                StartReceiveDataFliter = false,
                ClearSocketSession = false,
                StartCheckPackageLength = false,
                CheckSameSocketSession = false,
            });

            server.AddDeviceCompleted += server_AddDeviceCompleted;
            server.DeleteDeviceCompleted += server_DeleteDeviceCompleted;
            server.SocketConnected += server_SocketConnected;
            server.SocketClosed += server_SocketClosed;
            server.Start();

            server.AddDevice(dev);
        }

The dev.ReceiveRequestInfos event is an event interface extended by the control driver inheriting the RunDevice driver class in the ServerSuperIO framework. ServerSuperIO singleton mode receives data information. If it meets the protocol standards, the data information will be fed back to the driver's Communicate interface. The ReceiveRequestInfos event The data information is passed to the Dev_ReceiveRequestInfos function of the proxy service that subscribes to the event. The code is as shown below:

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

The proxy service receives the result information fed back by the device driver through the ServiceConnectorCallback and ServiceConnectorCallbackError function interfaces. If an exception occurs, the ServiceConnectorCallbackError will be called. If it is normal, the ServiceConnectorCallback function will be called. The ServiceConnectorCallback function interface sends the result to the control end based on the corresponding relationship between the recorded command and the IO channel. The ServiceConnectorCallback code is as shown below:

There is one thing to note here, that is, the device driver does not feedback the confirmation information of the control command within the specified time, that is, the sensor does not feedback corresponding information. In this case, a timing detection service needs to be added. If there is no feedback information after timeout, a corresponding message will be sent to the control end. The code is as shown below:

21.6 Device driver

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

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

For the isAsyn parameter of the returned result object ServiceConnectorCallbackResult, if it is true, it means that the result information is returned through the AsyncServiceConnectorCallback callback, which means that you need to wait for the sensor to return confirmation information, and the device driver receives it before feeding it back to the proxy service; If false, the description will be immediately fed back to the proxy service, suitable for passing data information regardless of whether the interaction with the sensor is successful.

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

21.7 Demo description

Open two TestDevice programs, one as the device sensor and the other as the control end. DeviceCode must match; TestDeviceDriver It is a device driver and is loaded in the service instance. I use the self-control mode and use the TestSelfMain project; ControlDeviceService is a proxy service and is loaded in TestSelfMain. For details, please refer to the project code: .

# Note: In the future, our big data platform can also issue control commands to the site through this mode.

---

1. [Serial] "Design and Implementation of C# Communication (Serial Port and Network) Framework"

2. [Open Source] C# Cross Introduction to the platform IoT communication framework ServerSuperIO (SSIO)

2. The overall solution for building a system using SuperIO (SIO) and the open source cross-platform IoT framework ServerSuperIO (SSIO)

3.C# Industrial Things Technical route for networking and integrated system solutions (data source, data collection, data upload and reception, ActiveMQ, Mongodb, WebApi, mobile App)

5. ServerSuperIO open source address:

IoT&Integrated Technology (.NET) QQ Group: 54256083

## Download address:

---

1.C# Cross-platform Internet of Things communication framework ServerSuperIO (SSIO) introduces

"Serial | Internet of Things Framework ServerSuperIO Tutorial" 1.4 communication mode mechanisms.

"Serial | Internet of Things Framework ServerSuperIO Tutorial" 2. Configuration parameter description of service instance

"Serial | Internet of Things Framework ServerSuperIO Tutorial" - 3. Device driver introduction

"Serial | Internet of Things Framework ServerSuperIO Tutorial"-4. For example, develop a set of device drivers that support both serial port and network communication.

"Serial | Internet of Things Framework ServerSuperIO Tutorial" - 5. Polling communication mode development and precautions.

"Serial | Internet of Things Framework ServerSuperIO Tutorial" - 6. Concurrent communication mode development and precautions

"Serial | Internet of Things Framework ServerSuperIO Tutorial" - 7. Self-control communication mode development and precautions

"Serial | Internet of Things Framework ServerSuperIO Tutorial" - 8. Singleton communication mode development and precautions

"Serial | Internet of Things Framework ServerSuperIO Tutorial" - 9. Protocol filter, solve a problem Multiple packets, sticky packets, redundant data

《Serial | Internet of Things Framework ServerSuperIO Tutorial》- 10. Two ways to continuously transmit large data streams (such as files)

《Serial | Internet of Things Framework ServerSuperIO Tutorial" - 11. Implement device (driver) and device (driver) interaction and cascade control.

"Serial | Internet of Things Framework ServerSuperIO Tutorial" - 12. Development of service interfaces and two-way interaction with the cloud

"Serial | Internet of Things Framework ServerSuperIO Tutorial" - 13. Development of custom view display interface to meet different display needs

"Serial | Internet of Things Framework ServerSuperIO Tutorial" - 14. Introduction to configuration tools, and mounting of device drivers, view drivers, and service instances

"Serial | Internet of Things Framework ServerSuperIO Tutorial" - 15. Usage of data persistence interface

"Serialization | Internet of Things Framework ServerSuperIO Tutorial" - 16. Steps for using OPC Server

"Serialization | Internet of Things Framework ServerSuperIO Tutorial" - 17. Support real-time database , Save measurement point data with high concurrency

"Serial | Internet of Things Framework ServerSuperIO Tutorial" - 18. Integrate OPC Client, and use steps

"Serial | Internet of Things Framework ServerSuperIO Tutorial"-19. Device driver and OPC Client support the persistence of mysql, oracle, sqlite, sqlserver

"Internet of Things Framework ServerSuperIO Tutorial"-20. Network communication controllers are grouped to improve interactive load balancing capabilities. v3.6.6 version released

The above is the detailed content of Share terminal control sensors or devices to form loop control instances. For more information, please follow other related articles on the PHP Chinese website!