[Tutorial on industrial serial port and network software communication platform (SuperIO)] 4. Develop device drivers and network software superio

[Tutorial on industrial serial port and network software communication platform (SuperIO)] 4. Develop device drivers and network software superio
SuperIO-related information download: http://pan.baidu.com/s/1pJ7lZWf1.1 Development Preparation

Copy all files in the "Development Kit" to the "bin" directory of the project, or a dedicated generated directory under the project. The Development Kit files include:

SuperIO. dll is the core module of the software platform, and the SuperIO directory is the parameter preparation and data storage directory of the software platform.

1.2 Project Preparation

1) Select Framework4.0 as the target framework.

2) The generated target platform uses x86

The target platform of all case programs uses x86. It mainly takes into account the compatibility between 32-bit and 64-bit operating systems.

1.3 assume that communication protocol 1.3.1 sends and reads real-time data Command Protocol

The 0x61 Command sent by the computer is a real-time data read command. A total of 6 bytes are sent, and the checksum is the sum starting from the "Slave address, does not include "Data Header", "checksum", and "protocol termination ".

The data frame of the sending command is as follows:

1.3.2 parse Real-time Data Protocol

After receiving the command for reading real-time data, the lower computer verifies the data and returns the real-time data. The sum is the sum starting from the "Slave address, does not include "Data Header", "checksum", and "protocol termination ".

The received data frame is as follows:

 

1.3.3 sending and receiving data example

Sending (hexadecimal): 0x55 0xaa 0x00 0x61 0x61 0x0d

Receive (hexadecimal): 0x55 0xaa 0x00 0x61 0x43 0x7a 0x00 0x00 0x43 0xb4 0x15 0x0d

Traffic Data: 250.00

Signal data: 360.00

1.4 create a device module

For example:

Add a reference to SuperIO. dll, such:

For details about project preparation, see 1.2 project preparation.

1.5 build protocol-driven

Create two classes: MySendProtocol and MyReceiveProtocol. MySendProtocol inherit from the base class of Cl. Device. DeviceSendProtocol and MyReceiveProtocol inherit from the base class of Cl. Device. DeviceReceiveProtocol.

Both the MySendProtocol and MyReceiveProtocol classes override the "Function61" function. The Function61 function in the MySendProtocol class completes the packaging and sending command operation, and the Function61 function in the MyReceiveProtocol class completes data parsing, functionXX will appear in pairs in both classes, mainly for the sake of note.

In the MySendProtocol instance, you can call the DriverFunction and input the corresponding command, for example, 0x61. The "Function61" function is automatically called as the driver interface for calling the corresponding command function. The GetSendCmdBytes function interface is encapsulated on the basis of the DriverFunction and can also be used. However, you must set "isbox" to "false". Otherwise, special processing will be performed on the sent data.

In the MyReceiveProtocol instance, you can call the DriverFunction and input the corresponding command, for example, 0x61. The "Function61" function is automatically called as the driver interface for calling the corresponding command function. The GetAnalysisData function is encapsulated on the basis of the DriverFunction function. It can also be used. It only calls one more GetCommand function interface.

For specific code, see the DeviceDemo project.

1.6 construct parameters and real-time data instance types

Two new classes are created: MyDeviceParameter and MyDeviceRTDataMyDeviceParameter inherit from the class of SCL. Device. DeviceParameter, which is used to save the backup parameters. You can add new Device parameters to this class.

MyDeviceRTData inherits the class "maid. Device. DeviceRealTimeData" and is used to save real-time Device data. You can customize real-time Device data based on communication protocols.

After the two classes inherit the base classes, they will automatically inherit the two generic functions SaveSerialize and GetSerialize. The SaveSerialize function serializes the current object into XML, and GetSerialize generates object instances in reverse order for the serialized XML.

The SCL. Device. DeviceParameter class and the SCL. Device. DeviceRealTimeData class inherit from the SerializeOperation class. Their interfaces are IserializeOperation, and SerializeOperation is just a simple class library for serialized XML operations.

If developers want to completely customize a data persistence file, they can inherit the IserializeOperation interface, rewrite the corresponding interface functions, and customize the way to store data.

 

1.7 build Device Drivers

Both "build protocol driver" and "build parameters and real-time data instance class" are preparations for building a running device and will be used as the properties of the running device.

Create a new Device class: MyDevice, which is inherited from SCL. Device. RunSCLDevice1.

The developer notices that there is another issue with the check mark ("SCL. device. runSCLDevice class, which is a relatively early running device class. Considering the platform compatibility, it is still being used in succession. However, we do not recommend that you use the SCL for the newly developed device model. device. runSCLDevice class.

They are all inherited from the IRunSCLDevice interface.

1.7.1 common interfaces

1) public overridecl. ProtocolDriver. ISendProtocol SendProtocol

After instantiating the sent protocol class, return here. For example, the MySendProtocol class.

 

2) public overridecl. ProtocolDriver. IReceiveProtocol ReceiveProtocol

After the received Protocol Class is instantiated, return here. For example, MyReceiveProtocol class.

 

3) public overrideSCL. Device. IDeviceParameter DeviceParameter

After the device parameter class is instantiated, return here. For example, MyDeviceParameter class.

 

4) public overridecl. Device. IDeviceRealTimeData DeviceRealTimeData

After the real-time data class is instantiated, return here. For example, MyDeviceRTData class.

 

5) public override voidInitDevice (int devid)

Initialize the device. You can initialize the sending protocol, receiving protocol, device parameters, and real-time data.

 

6) public override byte [] GetRealTimeCommand ()

This class returns the read Real-time Data command. When the CommandCache command buffer contains commands that can be sent, the command data in the command buffer is preferentially read and sent. If the CommandCache command buffer has no data, the software platform automatically calls the GetRealTimeCommand function interface, returns the read Real-time Data command, and sends it.

 

7) public override voidDealData (byte [] data)

When the communication is normal, the software platform automatically transmits the received data to this function. You can call the ReceiveProtocol attribute to parse, process, analyze, and save the data. Whether the communication is normal or not depends on the CheckData function interface in the receiving protocol class.

 

8) public override voidUnRegDevice ()

When the software platform is not registered, the software platform calls this function.

 

9) public override void UnknownIO ()

When the communication link is null, the software platform calls this function. For example, the serial port is not opened or the network is not connected.

 

10) public override voidCommunicateChanged (SCL. Device. IOState ioState)

When the communication status changes, the software platform calls this function. The communication status includes normal communication, communication interruption, and communication interference.

 

11) public override voidCommunicateError ()

When communication interference occurs, the software platform calls this function. Whether the communication is normal or not depends on the CheckData function interface in the receiving protocol class.

 

12) public override voidCommunicateInterrupt ()

When communication is interrupted, the software platform calls this function. Whether the communication is normal or not depends on the CheckData function interface in the receiving protocol class.

 

13) public override voidCommunicateNone ()

When the communication status is unknown, the software platform calls this function. In general, this kind of situation does not occur.

 

14) public override void SaveData ()

Save the processed data.

 

15) public override void Alert ()

Determines whether the data is abnormal. If the data is abnormal, an alarm is triggered.

 

16) public override void ShowData ()

Display Data Processing, used to update device runners, as well as custom UI and export data.

 

17) public override voidDeviceTimer ()

Each device is assigned a timer, which is called once every second by default. You can call the IsStartTimer attribute to start and stop the timer, and use the TimerInterval attribute to set the timer execution interval.

 

18) public overridecl. Device. DeviceType

Return the device type. The device types include common devices, virtual devices, and others.

 

19) public overrides y s t e m. Windows. Forms. Control DeviceGraphics

Return to the graphical interface of the device.

 

20) public override voidShowContextMenu ()

Display context menu functions.

 

21) public override stringModelNumber

Return the device module number, that is, the device model. This number must be unique.

 

24) public void ShowMonitorIODialog ();

Display channel monitor window

 

25) public voidShowMonitorIOData (byte [] data, string desc );

Display data information to the running monitor

1.7.2 attribute description

The following describes the properties of a device. For more information, see.

1) UserLevel

User-level attributes, including unknown users, common users, low-level users, and advanced users.

 

2) IsStartTimer

Obtain or set whether to enable the clock of the current device. It is disabled by default.

 

3) TimerInterval

Obtains or sets the interval of the current device clock. The default value is 1 second.

 

4) IsRegLicense

Whether the current device is registered or not. It is not registered by default.

 

5) RunDevicePriority

Obtains or sets the running level of the current device. If this parameter is set to a priority level, the system first calls this parameter to send and receive data.

 

6) CommunicationType

Obtains or sets the communication type of the current device. Including: Serial Port and network.

 

7) CommandCache

Obtain or set the command buffer of the current device. If there is data to be sent, the command buffer data is preferentially called for sending.

 

8) IsRunDevice

Obtain or set whether to run the current device. If set to false, the current setting does not run (send and receive data ).

 

9) DeviceParameter. IsSaveOriginBytes

Indicates whether to save the original sent and received bytes. If yes, the default path is D.

 

10) object Tag

Temporarily tag attributes.

 

11) object SyncLock

Synchronization Lock Object

1.7.3 Event Description

The following device events are encapsulated functions based on the original events. developers can directly

The following functions are called to trigger events. These events are loaded by default when the software platform starts.

1) void OnReceiveDataHandler (byte [] revdata );

Trigger receiving data events

 

2) void OnSendDataHandler (byte [] senddata );

Trigger the data sending event. When the Self mode is applied during network communication, you can use this event to independently send data.

 

3) void OnDeviceRuningLogHandler (stringstatetext );

Output device running logs to the running monitor

 

4) void OnUpdateContainerHandler ();

Trigger update run monitor event

 

5) void OnCOMParameterExchangeHandler (javasldcom, int oldbaud, int newcom, int newbaud );

Serial Port change event.

 

6) void OnDeviceObjectChangeHandler (objectobj );

Object Data Change Events are used to drive modules such as display, export, and service.

 

7) void OnDeleteDeviceHandler ();

Delete device events

1.7.4 advanced applications

1) void RunIODevice (SCL. CommunicateController. IDeviceIO io)

You can rewrite this function to change the device running process. According to the communication type specified by the CommunicationType attribute, you can convert the io parameter to the network communication interface ISocket or the serial communication interface ICOM, then, you can perform secondary development on the sending and receiving operations. It is generally not recommended to rewrite this function.

 

2) void Send (SCL. CommunicateController. IDeviceIOio, byte [] sendbytes)

You can override this function. Based on the communication type specified by the CommunicationType attribute, you can convert the io parameter to the network communication interface ISocket or the serial communication interface ICOM for data sending. This function can be rewritten in a suitable application scenario without rewriting the RunDevice function.

 

3) byte [] Receive (SCL. CommunicateController. IDeviceIOio)

You can override this function. According to the communication type specified by the CommunicationType attribute, you can convert the io parameter to the network communication interface ISocket or the serial communication interface ICOM to receive data. This function can be rewritten in a suitable application scenario without rewriting the RunDevice function.

 

4) void SaveBytes (byte [] data, string desc)

You can rewrite this function to customize and save the sent and received data. By default, it is stored in the "d: raw data of the software platform" directory.

 

5) void SocketConnect (string ip, int port)

You can rewrite this function. When a client connects to the software platform during network communication, this function interface is called.

 

6) void SocketDisconnect (stringip, int port)

You can rewrite this function. When a client is disconnected from the software platform during network communication, this function interface is called.

1.8 device debugging 1.8.1 interface Scheduling

The Interface Test is mainly to build a main program to simulate real applications to perform Device

Test. This test method is recommended.

1)Reference component

It mainly references the DeviceDemo assembly. For example:

 

Test Device

The Interface Test has a form interface and must inherit the "SCL. UI. mainForm class, and set the software platform as the debugging mode "SuperIO. device. debugDevice. isDebug = true ;",

 

Initialize the instance in Form_Load and load and debug the device module. It is mainly used to create a device instance, initialize parameters, and debug the device, for example, this. DebugDevice (IRunDevice) _ myDevice) statement. For example:

3) The I/o monitor displays the original hexadecimal data sent and received to facilitate debugging. For example:

4) use VirtualSerialPortDriver to virtualize two serial ports on the local machine. The two serial ports implement virtual connections, such as COM1 and COM2. Open the serial Assistant Software and platform software (SuperIO platform ), set COM1 and COM2 respectively to send and receive data according to "1.3 assumed communication protocol. Related software is available in the "Auxiliary Tools" directory. For example:

For more information about the test code, see FormTest.

1.8.2 console debugging

The console is tested and there is no UI display interface. Some functions may not be completely tested. Need to pass

SCL. Device. IdebugDevicedebug = SCL. Device. DebugDevice. GetDebugInstance () to obtain the debugging instance. Other code is the same as "interface test. For example:

1.9 mount a device module

Find the "configtool.exe" application in the "Industrial serial port" and "network software communication platform" _ superiov "directory, select the" Device Configuration "tab, and click the" Attach device "button to mount the device driver module you just developed to the platform. For example:

1.10 run the device on the platform

After mounting the device driver, run the superio_run.exe application in the industrial serial port and network software communication platform. Select User Management> User Logon, select engineer or administrator, and enter the default password 123.

Log on to the software platform, choose device management> Add device, and select the mounted device driver module. For example:

The developed device driver module supports both COM (string product) and TCP (network) communication modes. TCP (network) communication supports Client and Server working modes.

 

Author: QQ: 504547114

QQ group: 54256083

Http://www.bmpj.net

Source Article address: http://www.bmpj.net/index.php? M = article & f = view & id = 4