Thank you for sharing your comments.
Original address:
Http://www.cnblogs.com/lsjwq/
Contents
5. Polling communication model development and precautions... 2
4.1 overview... 2
4.2 communication mechanism description... 2
4.3 precautions for device driver development
4.3.1 send data in real time... 3
4.3.2 sending other data first... 3
4.4 host program service instance configuration considerations... 4
4.5 polling running results... 4
5. Polling communication model development and precautions
4.1 Overview
The polling communication mode is the earliest and only communication mode of superio. On this basis, the self-control mode and concurrency mode are added. In addition to the three communication modes, the serversuperio framework also provides the singleton mode, which will be described in detail later.
I didn't know any communication modes when I first joined the work. However, at that time, the communication environment in the industrial field was very complex. The communication link for modulation and demodulation had a transmission rate of 300 baud rates, due to strong electromagnetic interference such as geology and cables, data is often disturbed. At that time, there was no so-called Internet technology. To ensure the stability of communication, only polling communication modes were allowed.
4.2 communication mechanism description
This is the earliest operating mode of the framework. This control mode can be used for serial and network communication. When multiple devices are connected to the communication platform, the communication platform polls the scheduling device for communication tasks. At a certain time point, only one device can send a request command and wait for receiving the returned data. After the device completes sending and receiving (if timeout occurs, it will automatically return, the next device performs the communication task and polls the device in turn.
The application scenario is as follows: when the Server communicates with the device in a call response mode, that is, when the IO is available, the server initiates a communication command request first, and the device sends a communication command request according to the command information, after the verification is passed, the data is returned to the server. This communication mode is easy to understand. Communication between each device follows the queuing principle. But what if a device's Command needs to be sent in time? The serversuperio framework supports priority-based device scheduling. For example, if you want to perform real-time detection on a device and send commands continuously, You need to configure a high-level device, send the request data command.
The communication structure is as follows:
4.3 precautions for device driver development 4.3.1 send data in real time
The serversuperio framework polls and schedules all devices, and sends real-time request data commands to devices in the form of call responses. The real-time request data commands for 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:
1234567 |
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.
4.3.2 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.
- Add the command to the sending data cache. The framework automatically deletes the data obtained from the cache. The Code is as follows:
1 |
this .Protocol.SendCache.Add( "Read Parameters" ,readParaBytes); |
2. Set the priority attribute of the device. The Code is as follows:
1 |
this .DevicePriority=DevicePriority.Priority; |
4.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 polling communication mode, start the service instance, and add the instantiated device driver to the service instance. The Code is as follows:
12345678910111213141516171819 |
DeviceDriver dev1 = new DeviceDriver(); dev1.DeviceParameter.DeviceName = "Serial port device 1" ; dev1.DeviceParameter.DeviceAddr = 0; dev1.DeviceParameter.DeviceID = "0" ; dev1.DeviceDynamic.DeviceID = "0" ; dev1.DeviceParameter.COM.Port = 1; dev1.DeviceParameter.COM.Baud = 9600; dev1.CommunicateType = CommunicateType.COM; dev1.Initialize( "0" ); IServer server = new ServerFactory().CreateServer( new ServerConfig() { ServerName = "Service instance 1" , SocketMode = SocketMode.Tcp, ControlMode = ControlMode.Loop, CheckSameSocketSession = false , StartCheckPackageLength = false , }); server.Start(); server.AddDevice(dev1); |
ControlMode = ControlMode. Loop code is used to set the scheduling device of a service instance to the polling control mode.
4.5 polling Running Effect
1. Images
2. Video
Appendix: Class Library created by netizens in the group (CHM). Netizen name: norman33, QQ: 235936468. Thanks to norman33 for building a wonderful community. : Http://pan.baidu.com/s/1qXDVIvq
Serialization | Iot framework serversuperio tutorial-5. Polling communication mode development and precautions. Appendix: Class Library created by netizens (CHM)