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

This article mainly explains the "what are the characteristics of the ServerSuperIO of C#". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what are the characteristics of the ServerSuperIO of C#"?

I. characteristics of SSIO

Lightweight high-performance communication framework, suitable for a variety of application fields, polling mode, automatic control mode, concurrent mode and singleton mode.

The scene of device driver, IO channel and control mode is coordinated and unified.

Device driver Neixuan command driver, command buffer, custom parameters and real-time data elements.

The framework platform supports scheduling according to the priority of device commands to ensure that high-level commands are sent in time.

A device driver supports both serial port and network communication, and can monitor IO channel data.

A device driver that can support both TCP Server and TCP Client working modes when communicating over the network.

Built-in display view interface to meet different display needs.

Built-in service component interface, you can customize to complete OPC service, 4-20mA output, LED large screen display, short message service, and multi-function gateway service.

You can create multi-service instances to split different businesses.

Supports cross-platform deployment and can run on Linux and Windows systems.

II. Overview of SSIO

The design idea of SSIO communication framework is developed on the basis of SuperIO (SIO), and there is no high-end technology, mainly the accumulation of work experience, which is suitable for data acquisition and interaction of the Internet of things in different application scenarios. SSIO and SIO are not simple high-performance operations for IO, but the coordination mechanism among device drivers, IO channels, control modes and actual hardware devices, seamless connection and operation between all aspects, but also to solve some pain points in real work and application scenarios.

The data interaction between software and hardware, and faced with a complex field environment:

(1) complex and diverse communication protocols. There are standard protocols, such as Modbus, etc., and there are also many protocol formats modified according to standard protocols, as well as custom protocol formats, which vary widely. For bad software architecture, struggling to deal with, adding devices or protocols to sort out the whole software, new problems or BUG often arise in the process.

(2) according to the different users' requirements for the software interface or function, the data display interface can be customized to meet the display requirements of different users. Then it is necessary to provide a display view interface to interact with the device driver.

(3) since the data of the field equipment has been collected, it needs to be processed, not only saving, querying, reporting, etc., but also: data forwarding, data output (OPC, analog, large screen, etc.). Then you need to provide a service interface to interact with the device driver.

(4) due to the variety of communication links, it may be necessary to support RS232/RS485/RS422, RJ45, 3G/4G and other communication modes for the same device, so for a device to correspond to multiple communication modes (serial port and network), it also causes great obstacles to our development.

(5) the link between device driver, IO channel and actual field hardware terminal is complex, it is possible that one device driver corresponds to one IO channel, one device driver corresponds to multiple IO channels, and multiple device drivers correspond to one IO channel.

(6) since the equipment exchanges data with the server, the communication status of the device, the IO status, and the status of the device itself should be monitored so that the equipment can be maintained.

(7) the compatibility between the software versions and the software and hardware is very poor, and the management is complicated. When the framework platform is stable, only the device driver needs to be updated.

In order to solve the above problems, a software framework is developed to support secondary development. Without changing the software framework, it can easily access the equipment, maintain the equipment, integrate the equipment, process the business data of the equipment and so on. The software framework is relatively stable and the parts that are easy to change are designed flexibly.

III. The difference between SSIO and SIO

Serial number

Attribute

SSIO

SIO

one

Application scenario

Suitable for high-frequency data acquisition and control, can be deployed on the server side.

It is suitable for general upper computer data acquisition, such as factory-level server applications in local area network.

two

Control mode

Polling mode, automatic control mode, concurrent mode, singleton mode

Polling mode, automatic control mode, concurrent mode,

three

Performance

High performance

The performance is not as good as SSIO.

four

Service instance

A process can create multiple service instances

A process can only create one service instance

five

Cross platform

Support for Linux and Windows

Only all versions of Windows operating system are supported.

six

Secondary development

Convenient (excluding interface)

You only need inheritance to create a complete application.

seven

Code structure

More appropriate

More singleton patterns are used

eight

Serial port component

SerialPort

PCOMM

nine

Network component

SocketAsyncEventArgs

Socket

ten

Open source

Open source

No open source

eleven

OPC

Not supported

Support

twelve

Analogue quantity

Not supported

Support

thirteen

Plug-in

You need your own secondary development.

Fully support plug-in deployment

four。 Control mode

(1) polling mode: this control mode can be used when serial port and network communication. When multiple devices are connected to the communication platform, the communication platform will poll the scheduling equipment for communication tasks. At a certain time, only one device can send a request command and wait for the return data to be received. after the device completes sending and receiving (if it encounters a timeout, it will return automatically), the next device will carry out the communication task and poll the device in turn. As shown below:

(2) concurrent mode: this control mode can only be used in network communication. The concurrent communication mode is to send request instructions of all devices centrally, and the framework is to send request commands in the way of cyclic synchronization. There is also an opportunity to further improve the ability to send request commands centrally in a parallel and asynchronous manner. After receiving the instruction, the hardware device verifies and returns the data of the corresponding instruction after the verification is successful. after the communication platform monitors the data information asynchronously, it receives the operation, and then distributes and processes the data. As shown below:

(3) automatic control mode: this control mode can only be used in network communication. The automatic communication mode is similar to the concurrent communication mode, except that the instruction operation is handed over to the device driver itself for control, or to the secondary developer, the secondary developer can send instruction data through the clock timing and event-driven mode. After receiving the instruction, the hardware device verifies and returns the data of the corresponding instruction after the verification is successful. after the communication platform monitors the data information asynchronously, it receives the operation, and then distributes and processes the data.

Automatic communication mode can provide accurate timing request real-time data mechanism for secondary developers, making the communication mechanism more flexible and autonomous. If multiple device drivers use the same IO channel, the time control will be biased. As shown below:

(4) singleton mode: this control mode can only be used in network communication. There can be only one device driver in a service instance, which is equivalent to one device driver corresponding to N hardware device terminals. Data protocols that are more suitable for communication have fixed standards to handle different data with command keywords. It is suitable for highly concurrent hardware terminal devices to upload data actively, and the server processes and returns the corresponding data according to the data information. As shown below:

five。 Cross-platform Windows and Linux

(1) Windows operation effect

(2) running effect of Linux

Thank you for your reading, the above is the content of "what are the characteristics of the ServerSuperIO of C#". After the study of this article, I believe you have a deeper understanding of the characteristics of the ServerSuperIO of C#, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.