Serialization | Iot framework ServerSuperIO tutorial-7. Self-control communication mode development and precautions, building self-control Iot

Serialization | Iot framework ServerSuperIO tutorial-7. Self-control communication mode development and precautions, building self-control Iot

1. C # Introduction to cross-platform Iot communication framework ServerSuperIO (SSIO)

Serialization | Iot framework ServerSuperIO tutorial 1.4 communication modes and mechanisms.

Serialization | Iot framework ServerSuperIO tutorial 2. service instance configuration parameters

Serialization | Iot framework ServerSuperIO tutorial-3. Device Driver Introduction

Serialization | Iot framework ServerSuperIO tutorial-4. For example, you can develop a device driver that supports both serial and network communication.

Serialization | Iot framework ServerSuperIO tutorial-5. Polling communication mode development and precautions.

Serialization | Iot framework ServerSuperIO tutorial-6. concurrent communication mode development and precautions

 

Contents

7. Self-control communication mode development and precautions... 2

7.1 overview... 2

7.2 communication mechanism description... 2

7.3 precautions for device driver development

7.3.1 send data in real time... 3

7.3.2 send fixed Real-time request data command... 4

7.3.3 sending other data first... 4

7.3.4 how to select the IO channel to send data... 5

7.3.5 how to allocate data with DeviceCode... 5

7.3.6 how to change the device driver status... 6

7.4 host program service instance configuration considerations... 6

7.5 Automatic Control Mode running effect... 8

7. Self-control communication mode development and precautions  
7.1 Overview

The self-controlled communication mode is similar to the concurrent communication mode. The only difference is that the request data command can be sent. In the self-controlled communication mode, the timer can be used to send the request data command regularly, instead of sending the command in a centralized manner like the concurrent communication mode.

In the construction of industrial IoT, devices, protocols, and scenarios are different. The frequency of regularly  varies with different devices, high-frequency  is also a waste of resources, so it provides secondary developers with a more autonomous control mode when developing device drivers.

7.2 communication mechanism description

This control mode can be used only for network communication. The self-controlled communication mode is similar to the concurrent communication mode. The difference is that the sending command operation is handed over to the device driver for control, or to the secondary developer, secondary developers can send instruction data in an event-driven manner through clock timing. After the hardware device receives the command, it verifies it. After the verification succeeds, it returns the data of the corresponding command. After the communication platform asynchronously listens to the data information, it receives the data, then, data is distributed and processed.

The self-controlled communication mode can provide secondary developers with a precise Real-time Data mechanism for scheduled requests, making the communication mechanism more flexible and autonomous. If multiple device drivers share the same I/O channel, there will be deviations in time control.

Data distribution is also involved, and the concurrency mode is the same. The communication structure is as follows:

 

 

7.3 precautions for device driver development 7.3.1 send data in real time

The IRunDevice driver interface of the ServerSuperIO framework has a GetSendBytes function, which calls the GetConstantCommand fixed request data interface and the SendCache data sending cache at the same time, and sets the priority of the device for scheduling.

You can inherit the previously written device drivers and add the code to regularly send data. The Code is as follows:

public class DeviceSelfDriver:DeviceDriver {        public DeviceSelfDriver() : base()        {        }        public override void Initialize(string devid)        {            base.Initialize(devid);            this.RunTimerInterval = 5000;            this.IsRunTimer = true;        }        public override void OnRunTimer()        {            byte[] data = this.GetSendBytes();            OnSendData(data);            base.OnRunTimer();        }  }

7.3.2 commands for sending fixed Real-time request data

The automatic communication mode regularly sends request data commands, and also sends request Real-time Data commands to devices in the form of call responses. The real-time data commands for requests from the same device are generally relatively fixed. When a specific device driver is scheduled, a fixed call to the GetConstantCommand function of the IRunDevice driver interface is called to obtain the command to request real-time data. The Code is as follows:

Public override byte [] GetConstantCommand () {byte [] data = this. protocol. driverPackage <String> ("0", "61", null); string hexs = BinaryUtil. byteToHex (data); OnDeviceRuningLog ("Send >>" + hexs); return data ;}

This. Protocol. DriverPackage driver calls the 61 command to obtain the command to be sent and returns the byte [] array. After ServerSuperIO obtains the data, it will automatically issue the command data through the IO Interface. If the return value belongs to the null type, the system does not issue the data.

7.3.3 sending other data preferentially

A device cannot have only one command to read Real-time Data. Other commands may interact with each other, such as read parameters and real-time calibration. In this case, priority scheduling is required to send data information. The ServerSuperIO framework can prioritize the scheduling of the device driver in two ways.

This. Protocol. SendCache. Add ("read parameter", readParaBytes );

2. Set the priority attribute of the device. The Code is as follows:

this.DevicePriority=DevicePriority.Priority;

7.3.4 how to select an I/O channel to send data

When sending data in a centralized manner, how to associate the device driver with the I/O channel is involved. The framework selects the I/O channel to send data using the terminal IP parameter set by DeviceParameter. NET. RemoteIP. However, if the terminal device is a dynamic IP address, the RemoteIP parameter should also be changed. In this case, you need to set the service instance to distribute data to the device driver in the form of DeviceCode. The terminal device first sends simple verification data to ensure that the sent DeviceCode corresponds to the device driver, after the device driver receives the verification data, it needs to save the temporary RemoteIP information, so that when sending the data, the parameter can accurately find the I/O channel to request the data to the terminal device.

For example, the following code:

public override void Communicate(ServerSuperIO.Communicate.IRequestInfo info){            this.DeviceParameter.NET.RemoteIP = info.Channel.Key;            this.DeviceParameter.Save(this.DeviceParameter);            ……}

7.3.5 how to allocate data with DeviceCode

If the service instance is set to allocate data in DeliveryMode. DeviceCode mode, you need to implement the DeviceCode filtering interface in the communication protocol interface.

For example, the following code:

  internal class DeviceProtocol:ProtocolDriver    {        public override string GetCode(byte[] data)        {            byte[] head = new byte[] {0x55, 0xaa};            int codeIndex = data.Mark(0, data.Length, head);            if (codeIndex == -1)            {                return String.Empty;            }            else            {                return data[codeIndex + head.Length].ToString();            }        }}

7.3.6 how to change the driver status

Unlike the round-robin communication mode, sending and receiving data is a cycle. After receiving the data, the device drives the device. The device executes the entire lifecycle process based on the received data, the status of the device driver is automatically changed.

The self-controlled communication mode and the concurrent communication mode emphasize that the method of request data is different. Therefore, the request data command cannot be sent all the time, but the device status remains unchanged. For example: communication becomes normal, and communication becomes normal. The sending and receiving processes of these two communication modes have a coordination mechanism to send three data request commands without receiving any data. The device-driven interfaces are automatically called, the entire execution process to drive the device, so that the device status will automatically change, without the need for secondary development to write the corresponding code.

7.4 host program service instance configuration considerations

When creating a service instance in the Host Program, you need to set the configuration parameters of the service instance to self-control communication mode, start the service instance, and add the instantiated device driver to the service instance. The Code is as follows:

 

Static void Main (string [] args) {DeviceDriver dev1 = new DeviceDriver (); dev1.DeviceParameter. deviceName = "serial device"; dev1.DeviceParameter. deviceAddr = 0; dev1.DeviceParameter. deviceID = "0"; dev1.DeviceDynamic. deviceID = "0"; dev1.DeviceParameter. deviceCode = "0"; dev1.DeviceParameter. COM. port = 1; dev1.DeviceParameter. COM. baud = 9600; dev1.CommunicateType = CommunicateType. COM; dev1.Initialize ("0"); DeviceSelfDriver dev2 = new DeviceSelfDriver (); dev2.DeviceParameter. deviceName = "network device"; dev2.DeviceParameter. deviceAddr = 1; dev2.DeviceParameter. deviceID = "1"; dev2.DeviceDynamic. deviceID = "1"; dev2.DeviceParameter. deviceCode = "1"; dev2.DeviceParameter. NET. remoteIP = "127.0.0.1"; dev2.DeviceParameter. NET. remotePort = 9600; dev2.CommunicateType = CommunicateType. NET; dev2.Initialize ("1"); IServer server = new ServerManager (). createServer (new ServerConfig () {ServerName = "Service 1", ComReadTimeout = 1000, ComWriteTimeout = 1000, NetReceiveTimeout = 1000, NetSendTimeout = 1000, ControlMode = ControlMode. self, SocketMode = SocketMode. tcp, StartReceiveDataFliter = false, ClearSocketSession = false, StartCheckPackageLength = false, CheckSameSocketSession = false, DeliveryMode = DeliveryMode. deviceCode,}); server. addDeviceCompleted + = server_AddDeviceCompleted; server. deleteDeviceCompleted + = server_DeleteDeviceCompleted; server. start (); server. addDevice (dev1); server. addDevice (dev2); while ("exit" = Console. readLine () {server. stop ();}}

ControlMode = ControlMode. The Self Code sets the scheduling device of the service instance as the concurrency control mode. It distributes data using DeliveryMode = DeliveryMode. DeviceCode. Of course, I am simulating a fixed terminal IP address.

7.5 running effect of Automatic Control Mode

1. Images

 

2. Video

 

1. [serialization] C # communication (Serial Port and network) Framework Design and Implementation

2. [Open Source] C # cross-platform Iot communication framework ServerSuperIO (SSIO) Introduction

2. Overall system construction solution using SuperIO and open-source cross-platform Iot framework ServerSuperIO

5. ServerSuperIO Open Source Address: https://github.com/wxzz/ServerSuperIO

Internet of Things & integrated technology (. NET) QQ Group:54256083