A general-purpose host computer debugging method for power meter debugging

Abstract

The application discloses a general host computer debugging method for power meter debugging, which completes power meter debugging work through designing a standardized address table and operating the standardized address table. The standardized address table at least includes comprehensive attribute information such as parameter name, unit, register address, data type, byte sequence, decimal place, function code and explanation. Through editing, exporting, importing, analyzing, data reading and data writing of the standardized address table, intelligent partition and merging, general host computer software architecture template driven development, self-adaptive analysis algorithm and efficient data processing flow and other technical means, the redundancy of repeated development of the host computer is significantly reduced, the consistency and accuracy of data are improved, and the equipment testing process is accelerated, so that the overall cycle of the project engineering is effectively shortened.

Description

Technical Field

[0001] This invention relates to the field of power instrument debugging technology, specifically to a general host computer debugging method for power instrument debugging. Background Technology

[0002] Currently, developing power meters based on the Modbus communication protocol requires customizing address tables and remaking host computer software for each type of meter to complete the debugging and testing of the power meters. This results in a large amount of repetitive development work, wasting manpower, time, and technical resources. Furthermore, the lack of a unified standard for address tables and software across different projects leads to chaotic data management, making it difficult to guarantee data consistency, accuracy, and interoperability, and resulting in low efficiency during equipment testing and project progress. Summary of the Invention

[0003] The purpose of this invention is to overcome the shortcomings of the existing technology by designing and implementing a standardized address table format and dynamically parsing a unified data structure to develop a universal host computer software architecture that can adapt to the configuration of different power meters, thus providing the basic conditions for efficiently completing the automatic testing of power meters.

[0004] To achieve the above objectives, this invention designs a general-purpose host computer debugging method for power meters. This debugging method completes the power meter debugging work by designing a novel standardized address table and operating on the standardized address table. The standardized address table includes comprehensive attribute information such as parameter name, unit, register address, data type, byte order, decimal places, function code, and description (used to explain the parameter). That is, the attributes of each row of data cover the above fields, which solves the problem of inconsistent address table formats in the past. This format lays the foundation for subsequent efficient processing and universality, in stark contrast to previous address table designs that only met the debugging needs of individual meters and lacked a unified standard. The operations include editing, importing, exporting, and parsing. The function code identifies the read-only partition (ReadInfo) and the readable-write partition (WriteInfo) of the address table. The debugging method includes the following steps: S1. Create a template, open the standardized address table, and edit the address table information; S2. Export the address table file; S3. Select the parsing template function and import the address table file, that is, import the CSV file corresponding to the current power meter being tested; S4. Parse the contents of the address table CSV file. Based on the function code of each row in the address table, automatically divide the file into two structure dictionaries: a read-only partition (ReadInfo) and a read-write partition (WriteInfo).<class_info> The dictionary adds a new data attribute to store the read data; S5. For read-only partitions (ReadInfo), a dictionary (ReadAddressList) needs to be created.<class_addr> Used for background data reading, the class_addr contains two attributes: starting address (class_addr1 and class_addr2) and data length. Repeat step S5 above until all information has been parsed; S6. For the readable and writable partition WriteInfo, a dictionary WriteAddressList needs to be created.<class_addr> The WriteInfo data is parsed and stored in WriteAddressList; S7. Parameter reading: Each group is read one by one using the starting address and data length stored in WriteAddressList and / or ReadAddressList. This process is repeated until all information is read. Generally, parameters are read based on the address and data length of WriteAddressList and / or ReadAddressList. S8. Parameter setting: Reversely parse the data type, byte order, decimal places and unit in the current WriteAddressList address table, restore it to communication data, and set it in the power meter. This allows the power meter to be debugged according to the facility parameters as planned. Steps S5 and S6 have no specific order.

[0005] Furthermore, adjacent register addresses are consecutive.

[0006] Furthermore, the ReadAddressList creation step (i.e., the efficient address grouping algorithm) includes: First, create a starting address dictionary class_addr1. Take the first parameter para1 and assign the register address of para1 to the starting address of class_addr1. Take the register data type of para1, identify the number of bytes occupied by the register data type, and determine the data length. Assuming that the data type of para1 is uint, it occupies 4 bytes and two addresses (one address is two bytes). The length of class_addr1 is 2. Continue retrieving the next parameter para2 from the read-only partition. Check if the starting address of class_addr1 + length equals the register address of para2. If they are the same, parse the number of bytes n occupied by the register data type of para2, and the address length is n / 2. If length + n / 2 <= a, then assign length + n / 2 to the length of class_addr1 and store it in ReadAddressList. If length + n / 2 > a, where a is the communication address length, then keep the length of class_addr1 as is and store class_addr1 in ReadAddressList. At the same time, create a new class_addr named class_addr2, assign the register address of para2 to the starting address addr of class_addr2, and assign the address length n / 2 to the length of class_addr2. Then retrieve the next data from ReadInfo and repeat the above operation to check. If the starting address + length of class_addr1 is different from the register address of para2, then store class_addr1 in ReadAddressList, create a new class_addr named class_addr2, assign the register address of para2 to the starting address addr of class_addr2, assign the address length n / 2 to the length of class_addr2, then retrieve the next data of ReadInfo, and repeat the above operation to make the judgment. This process is repeated until all data in ReadInfo is parsed and stored in ReadAddressList.

[0007] Furthermore, the WriteAddressList creation steps include: First, create a starting address dictionary class_addr1. Take the first parameter para1 and assign the register address of para1 to the starting address of class_addr1. Take the register data type of para1, identify the number of bytes occupied by the register data type, and determine the data length. Assuming that the data type of para1 is uint, it occupies 4 bytes and two addresses (one address is two bytes). The length of class_addr1 is 2. Continuing with the next parameter para2 from the readable and writable partition, we check if the starting address of class_addr1 + length equals the register address of para2. If they are the same, we parse the number of bytes n occupied by the register data type of para2, and the address length is n / 2. If length + n / 2 <= a, we assign length + n / 2 to the length of class_addr1 and store it in WriteAddressList. If length + n / 2 > a, where a is the communication address length, we keep the length of class_addr1 unchanged and store class_addr1 in WriteAddressList. At the same time, we create a new class_addr named class_addr2, assign the register address of para2 to the starting address addr of class_addr2, and assign the address length n / 2 to the length of class_addr2. Then we retrieve the next data from WriteInfo and repeat the above operations to check. If the starting address + length of class_addr1 is different from the register address of para2, then store class_addr1 in WriteAddressList, create a new class_addr named class_addr2, assign the register address of para2 to the starting address addr of class_addr2, assign the address length n / 2 to the length of class_addr2, then retrieve the next data of WriteInfo, and repeat the above operation to make the judgment. This process is repeated until all data in WriteInfo is parsed and stored in WriteAddressList.

[0008] Furthermore, the length of the communication address a is less than or equal to 100.

[0009] Furthermore, the method for reading the WriteAddressList parameters includes: For the first class_addr, taking the first class_addr in WriteAddressList as an example, let the starting address be m and the data length be n. Read n addresses, 2n bytes of data (one address stores two bytes), and store them in ushort[] buffer; traverse all the class_info structures in WriteInfo, and check whether the addr+length of class_info is within n+m. If it is, it means that the data being read is in the buffer, take the data from buffer[addr-m] to buffer[addr-m+n-1], adjust the byte order according to the byte order of class_info, then parse the data according to the register data type, and adjust it according to the decimal places. The obtained data is stored in the data of class_info; if not, ignore it. The process continues in a loop until all WriteAddressList entries are read, parsed, and stored in WriteInfo. The method for reading parameters in ReadAddressList is the same as that for reading parameters in WriteAddressList, repeatedly reading real-time updated data into ReadInfo and updating and displaying it on the interface in real time.

[0010] Furthermore, the standardized address table also includes explanatory information, and the parameter settings also include explanatory information.

[0011] Furthermore, the debugging method also includes generating general host computer software through a standard template. The standard template includes attribute information such as parameter name (data_name), parameter unit (unit), register address (reg_add), register data type (reg_type), byte order (endian), decimal places (dcm), function code (fun_num), and description (disc).

[0012] The advantages and beneficial effects of this invention are as follows: 1. Design and Implementation of a Standardized Address Table Format: Designing a comprehensive and standardized address table format, covering attributes such as parameter name, unit, register address, data type, byte order, decimal places, function code, and description, requires a deep understanding of the communication protocols and data structures between different devices. Implementing this standardized format and ensuring its applicability to various types of power meters requires a broad understanding and precise grasp of the communication protocols and data formats of various instruments.

[0013] 2. Dynamically Parsing a Unified Data Structure: The address table is automatically divided into "read-only" and "read-write" partitions based on function codes. This requires developing an intelligent partitioning algorithm. This invention accurately identifies and classifies different data regions by defining function codes. Dynamic merging of data structures is achieved through register address continuity, such as merging into ReadAddressList / WriteAddressList. This requires the algorithm to have high flexibility and adaptability, capable of handling various complex data structures.

[0014] 3. Generalized Host Computer Software Architecture and Template-Driven Development: Develop a general host computer software architecture that can adapt to the configuration of different instruments. This requires a deep understanding and practical experience in host computer software development. By importing standard templates, the software is automatically divided into two main modules based on the read and write attributes of the template parameters. Then, based on the address sorting, the two modules are displayed on the interface, thus generating the host computer software template for the current device. This requires designing an efficient and flexible template system that can support rapid software generation and configuration.

[0015] 4. Adaptive parsing algorithm: Based on register data types (such as Uint16, Float, ASCII, etc.) and byte order, it automatically parses the original data and converts it into actual physical quantities (e.g., parameter A, data B is read according to the address of A, the high and low bits of B are adjusted according to the byte order attribute of A, the corresponding data is parsed according to the data type attribute, and the data is converted by division according to the decimal point attribute). This requires the algorithm to have strong data processing capabilities and compatibility; adjusting according to the decimal places ensures the accuracy of the data, which requires precise control over the precision and format of the data.

[0016] 5. Efficient Data Processing Flow and Dynamic Address Grouping: Intelligent grouping of consecutive register addresses, such as using a 90-byte threshold, optimizes data reading efficiency. This requires developing an efficient address grouping algorithm that can be flexibly adjusted according to the communication characteristics and needs of different devices. Real-time data updates and display ensure that users can obtain the latest device status and data at any time, requiring the system to have high real-time performance and response speed.

[0017] 6. Reverse parsing mechanism: Supports the reverse parsing of user-input parameter values ​​into communication data and writing them into the device, realizing automated two-way interaction. This requires the development of a reverse parsing algorithm (for example, when writing data B to parameter A, first perform multiplication and conversion on the data according to the decimal point attribute, parse out the corresponding data according to the data type attribute, and then adjust the high and low bits of B according to the byte order attribute of A to obtain the transmitted data), which can accurately convert user input into communication data that the device can recognize. Attached Figure Description

[0018] Figure 1 This is a flowchart of a general host computer debugging method; Figure 2 This is a detailed flowchart of the software read / write process; Figure 3 This is a detailed flowchart of the partitioned data polling process. Detailed Implementation

[0019] The specific embodiments of the present invention will be further described below with reference to the accompanying drawings and examples. The following examples are only used to more clearly illustrate the technical solutions of the present invention and should not be construed as limiting the scope of protection of the present invention. Example 1:

[0020] This invention provides a general host computer debugging method for power instrument debugging, such as... Figure 1 and Figure 2 As shown, the debugging method completes the debugging of power meters by designing a new standardized address table and operating on the standardized address table. The standardized address table includes comprehensive attribute information such as parameter name, unit, register address, data type, byte order, decimal places, function code, and description (used to explain the parameter). That is, the attributes of each row of data cover the above fields, which can solve the problem of inconsistent address table formats in the past. This format lays the foundation for subsequent efficient processing and universality, which is in stark contrast to the previous address table design that only met the debugging needs of a single meter and had no unified standard. The operations include editing, importing, exporting, parsing, etc. The function code identifies the read-only partition ReadInfo and the read-write partition WriteInfo of the address table. The debugging method includes the following steps: S1. Create a template, open the standardized address table and edit the address table information. In this embodiment, according to the model and specifications of the power meter to be debugged, relevant information is edited into the address table. For example, open it with Excel software, select the edit template function, and edit the address table according to the standard format. Each row of data attribute class_info includes parameter name, parameter unit, register address, register data type, byte order (endian mode), decimal places, function code, and description. S2. Export the address table file. After editing the required addresses, export the template. The different attributes of each row of data are separated by commas. Each row of data is a separate line and generates a CSV file (a plain text file used to store table and spreadsheet information). S3. Select the parsing template function and import the address table file, that is, import the CSV file corresponding to the current power meter being tested; S4. Parse the contents of the address table CSV file. Based on the function code of each row in the address table, automatically divide the file into two structure dictionaries: a read-only partition (ReadInfo) and a read-write partition (WriteInfo).<class_info> The dictionary adds a new data attribute to store the read data; S5. For read-only partitions (ReadInfo), a dictionary (ReadAddressList) needs to be created.<class_addr> Used for background data reading, the class_addr contains two attributes: starting address (class_addr1 and class_addr2) and data length. Repeat step S5 above until all information has been parsed; S6. For the readable and writable partition WriteInfo, a dictionary WriteAddressList needs to be created.<class_addr> The WriteInfo data is parsed and stored in WriteAddressList; S7. Parameter reading: In this embodiment, a "Parameter reading" button is set. Clicking this button will read each group one by one according to the starting address and data length stored in WriteAddressList and / or ReadAddressList. This process is repeated until all information is read. Generally, the parameter reading is performed according to the address and data length of WriteAddressList and / or ReadAddressList. S8. Parameter setting: In this embodiment, a "Parameter setting" button is set. Clicking this button will reverse the data type, byte order, decimal places and unit in the current WriteAddressList address table, restore it to communication data, and set it in the power meter. Thus, the power meter can be debugged according to the facility parameters as planned. Steps S5 and S6 have no specific order; in this embodiment, they are executed in the order of S1, S2, S3, S4, S5, S6, S7, and S8.

[0021] Preferably, adjacent register addresses are contiguous. This invention facilitates dynamic merging of data structures through register address contiguousness, significantly reducing data redundancy. Register address contiguousness shortens the length of the generated ReadAddressList and WriteAddressList, reducing the number of Modbus communications executed during subsequent read and write operations, thus accelerating communication timeliness and real-time data update speed. For example, 10 parameters with contiguous addresses could require 10 communication instructions to retrieve data, but by merging the addresses into a single data structure, the data can be retrieved with just one instruction.

[0022] Preferred, such as Figure 3 As shown, the ReadAddressList creation steps (i.e., the partitioned data polling process) include: First, create a starting address dictionary class_addr1. Take the first parameter para1 and assign the register address of para1 to the starting address of class_addr1. Take the register data type of para1, identify the number of bytes occupied by the register data type, and determine the data length. Assuming that the data type of para1 is uint, it occupies 4 bytes and two addresses (one address is two bytes). The length of class_addr1 is 2. Continue retrieving the next parameter para2 from the read-only partition. Check if the starting address of class_addr1 + length equals the register address of para2. If they are the same, parse the number of bytes n occupied by the register data type of para2, and the address length is n / 2. If length + n / 2 <= a, then assign length + n / 2 to the length of class_addr1 and store it in ReadAddressList. If length + n / 2 > a, where a is the communication address length, then keep the length of class_addr1 as is and store class_addr1 in ReadAddressList. At the same time, create a new class_addr named class_addr2, assign the register address of para2 to the starting address addr of class_addr2, and assign the address length n / 2 to the length of class_addr2. Then retrieve the next data from ReadInfo and repeat the above operation to check. If the starting address + length of class_addr1 is different from the register address of para2, then store class_addr1 in ReadAddressList, create a new class_addr named class_addr2, assign the register address of para2 to the starting address addr of class_addr2, assign the address length n / 2 to the length of class_addr2, then retrieve the next data of ReadInfo, and repeat the above operation to make the judgment. This process is repeated until all data in ReadInfo is parsed and stored in ReadAddressList.

[0023] Preferred, such as Figure 3 As shown, the WriteAddressList creation steps include: First, create a starting address dictionary class_addr1. Take the first parameter para1 and assign the register address of para1 to the starting address of class_addr1. Take the register data type of para1, identify the number of bytes occupied by the register data type, and determine the data length. Assuming that the data type of para1 is uint, it occupies 4 bytes and two addresses (one address is two bytes). The length of class_addr1 is 2. Continuing with the next parameter para2 from the readable and writable partition, we check if the starting address of class_addr1 + length equals the register address of para2. If they are the same, we parse the number of bytes n occupied by the register data type of para2, and the address length is n / 2. If length + n / 2 <= a, we assign length + n / 2 to the length of class_addr1 and store it in WriteAddressList. If length + n / 2 > a, where a is the communication address length, we keep the length of class_addr1 unchanged and store class_addr1 in WriteAddressList. At the same time, we create a new class_addr named class_addr2, assign the register address of para2 to the starting address addr of class_addr2, and assign the address length n / 2 to the length of class_addr2. Then we retrieve the next data from WriteInfo and repeat the above operations to check. If the starting address + length of class_addr1 is different from the register address of para2, then store class_addr1 in WriteAddressList, create a new class_addr named class_addr2, assign the register address of para2 to the starting address addr of class_addr2, assign the address length n / 2 to the length of class_addr2, then retrieve the next data of WriteInfo, and repeat the above operation to make the judgment. This process is repeated until all data in WriteInfo is parsed and stored in WriteAddressList.

[0024] Preferably, the communication address length a <= 100; in this embodiment, a = 90 is used because the conventional Modbus communication address length is less than 100, and 90 is used here to avoid abnormal situations caused by communication lag.

[0025] Preferably, the method for reading the WriteAddressList parameters includes: For the first class_addr, taking the first class_addr in WriteAddressList as an example, let the starting address be m and the data length be n. Read n addresses, 2n bytes of data (one address stores two bytes), and store them in ushort[] buffer; traverse all the class_info structures in WriteInfo, and check whether the addr+length of class_info is within n+m. If it is, it means that the data being read is in the buffer, take the data from buffer[addr-m] to buffer[addr-m+n-1], adjust the byte order according to the byte order of class_info, then parse the data according to the register data type, and adjust it according to the decimal places. The obtained data is stored in the data of class_info; if not, ignore it. The process continues in a loop until all WriteAddressList entries are read, parsed, and stored in WriteInfo. The method for reading parameters in ReadAddressList is the same as that for reading parameters in WriteAddressList, repeatedly reading real-time updated data into ReadInfo and updating and displaying it on the interface in real time.

[0026] Preferably, the standardized address table also includes explanatory information, and the parameter settings also include explanatory information.

[0027] Preferably, the debugging method further includes generating general host computer software through a standard template, wherein the standard template includes attribute information such as parameter name data_name, parameter unit unit, register address reg_add, register data type reg_type, byte order endian (big-endian mode), decimal places dcm, and function code fun_num. Example 2:

[0028] The difference from Example 1 is that the communication address length a=100 in this example. Example 3:

[0029] The difference from Example 1 is that this example is executed in the order of S1, S2, S3, S4, S6, S5, S7, and S8. Example 4:

[0030] The difference from Embodiment 1 is that the standardized address table described in this embodiment also includes explanatory information, and the parameter settings also include explanatory information.

[0031] Preferably, the debugging method further includes generating general host computer software through a standard template, wherein the standard template includes attribute information such as parameter name (data_name), parameter unit (unit), register address (reg_add), register data type (reg_type), byte order (endian), decimal places (dcm), function code (fun_num), and description (disc).

[0032] The basic principle of this invention is: This invention proposes a general host computer debugging method for power instrument debugging, the working principle of which is mainly based on a standardized address table format and a dynamic parsing unified data structure.

[0033] First, a standardized address table format (CSV file) containing attributes such as parameter name, register address, data type, and byte order is defined to solve the problem of inconsistent address table formats in the past.

[0034] In practical applications, users open the standardized address table using dedicated host computer software and edit it according to the standard format. After editing, the address table is exported as a CSV file.

[0035] Next, the host computer software selects the template parsing function and imports the CSV file. The software parses the contents of the CSV file and automatically divides the address table into two partitions, "Read-only" (ReadInfo) and "Read-write" (WriteInfo), based on the function code of each line. It also dynamically merges the data structures by ensuring register address continuity and data type consistency, significantly reducing data redundancy.

[0036] During the data reading phase, the host computer software reads the data one by one from the dynamically generated address list (such as ReadAddressList and WriteAddressList), and automatically parses the original data into actual physical quantities according to the register data type and byte order, and updates the data on the interface in real time.

[0037] During the data writing phase, users can use the host computer software to reverse-parse the current data according to the data type, byte order, decimal places, unit, and description in the address table, restore it to communication data, and set it into the instrument to realize the automation of two-way interaction.

[0038] This universal host computer debugging method significantly reduces the redundancy of repetitive host computer development, improves data consistency and accuracy, and accelerates the equipment testing process through standardized address table format, intelligent partitioning and merging, template-driven development of universal host computer software architecture, adaptive parsing algorithm, and efficient data processing flow, thereby effectively shortening the overall project cycle.

[0039] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, without departing from the technical principles of the present invention, various improvements and modifications can be made, including the partitioning method, the composition of attribute information of the standard template, and the dynamic parsing method. These improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A general host computer debugging method for power instrument debugging, characterized in that, The debugging method completes the debugging of power meters by designing a standardized address table and operating on the standardized address table. The standardized address table includes at least parameter name, unit, register address, data type, byte order, decimal places, and function code. The operations include editing, importing, exporting, and parsing operations. The function code identifies the read-only partition ReadInfo and the readable-write partition WriteInfo of the address table. The debugging method includes the following steps: S1. Create a template, open the standardized address table, and edit the address table information; S2. Export the address table file; S3. Select the parsing template function and import the address table file; S4. Parse the contents of the address table file, and automatically divide the file into two structure dictionaries, namely, a read-only partition (ReadInfo) and a read-write partition (WriteInfo), based on the function codes of each line in the address table.<class_info> The dictionary adds a new data attribute to store the read data; S5. For read-only partitions (ReadInfo), a dictionary (ReadAddressList) needs to be created.<class_addr> Used for background data reading, the class_addr contains two attributes: starting address addr and data length length; Repeat step S5 above until all information has been parsed; S6. For the readable and writable partition WriteInfo, a dictionary WriteAddressList needs to be created.<class_addr> The WriteInfo data is parsed and stored in WriteAddressList; Repeat step S6 above until all information has been parsed; S7. Parameter reading: Using the starting address and data length stored in WriteAddressList and / or ReadAddressList, each group is read one by one, and the process is repeated until all information is read. S8. Parameter settings: Reverse-parse the data type, byte order, decimal places and units in the current WriteAddressList address table, restore it to communication data, and set it in the power meter. Steps S5 and S6 have no specific order; The steps for creating the ReadAddressList include: First, create a starting address dictionary class_addr as class_addr1, take the first parameter para1, assign the register address of para1 to the starting address of class_addr1, take the register data type of para1, identify the number of bytes occupied by the register data type, and determine the data length. Continue retrieving the next parameter para2 from the read-only partition. Check if the starting address of class_addr1 + length equals the register address of para2. If they are the same, parse the number of bytes n occupied by the register data type of para2, and the address length is n / 2. If length + n / 2 <= a, then assign length + n / 2 to the length of class_addr1 and store it in ReadAddressList. If length + n / 2 > a, where a is the communication address length, then keep the length of class_addr1 as is and store class_addr1 in ReadAddressList. At the same time, create a new class_addr named class_addr2, assign the register address of para2 to the starting address addr of class_addr2, and assign the address length n / 2 to the length of class_addr2. Then retrieve the next data from ReadInfo and repeat the above operation to check. If the starting address + length of class_addr1 is different from the register address of para2, then store class_addr1 in ReadAddressList, create a new class_addr named class_addr2, assign the register address of para2 to the starting address addr of class_addr2, assign the address length n / 2 to the length of class_addr2, then retrieve the next data of ReadInfo, and repeat the above operation to make the judgment. Repeat this process until all data in ReadInfo is parsed and stored in ReadAddressList; The WriteAddressList creation steps include: First, create a starting address dictionary class_addr as class_addr1, take the first parameter para1, assign the register address of para1 to the starting address of class_addr1, take the register data type of para1, identify the number of bytes occupied by the register data type, and determine the data length. Continuing with the next parameter para2 from the readable and writable partition, we check if the starting address of class_addr1 + length equals the register address of para2. If they are the same, we parse the number of bytes n occupied by the register data type of para2, and the address length is n / 2. If length + n / 2 <= a, we assign length + n / 2 to the length of class_addr1 and store it in WriteAddressList. If length + n / 2 > a, where a is the communication address length, we keep the length of class_addr1 unchanged and store class_addr1 in WriteAddressList. At the same time, we create a new class_addr named class_addr2, assign the register address of para2 to the starting address addr of class_addr2, and assign the address length n / 2 to the length of class_addr2. Then we retrieve the next data from WriteInfo and repeat the above operations to check. If the starting address + length of class_addr1 is different from the register address of para2, then store class_addr1 in WriteAddressList, create a new class_addr named class_addr2, assign the register address of para2 to the starting address addr of class_addr2, assign the address length n / 2 to the length of class_addr2, then retrieve the next data of WriteInfo, and repeat the above operation to make the judgment. This process is repeated until all data in WriteInfo is parsed and stored in WriteAddressList; The communication address length a<=100, and different data areas can be accurately identified and classified by defining function codes.

2. The universal host computer debugging method for power instrument debugging according to claim 1, characterized in that, Adjacent register addresses are consecutive.

3. The universal host computer debugging method for power instrument debugging according to claim 1, characterized in that, The WriteAddressList parameter reading method includes: For the first class_addr, let the starting address be m and the data length be n. Read n addresses, 2n bytes of data, and store them in the ushort[] buffer. Traverse all class_infos in the WriteInfo structure, and check whether the addr+length of class_info is within n+m. If it is, it means that the data being read is in the buffer. Take the data from buffer[addr-m] to buffer[addr-m+n-1], adjust the byte order according to the byte order of class_info, parse the data according to the register data type, and adjust it according to the decimal places. Store the obtained data in the data of class_info. If it is not, ignore it. The process continues in a loop until all WriteAddressList entries are read, parsed, and stored in WriteInfo. The method for reading parameters from ReadAddressList is the same as the method for reading parameters from WriteAddressList.

4. The universal host computer debugging method for power instrument debugging according to claim 1, characterized in that, The standardized address table also includes explanatory information, and the parameter settings also include explanatory information.

5. The universal host computer debugging method for power instrument debugging according to claim 1, characterized in that, The debugging method also includes generating general host computer software through a standard template. The standard template includes parameter name data_name, parameter unit unit, register address reg_add, register data type reg_type, byte order endian, decimal places dcm, function code fun_num, and description disc attribute information.

Images