Universal upper computer debugging method for debugging electric power meter

Abstract

The invention discloses a universal upper computer debugging method for debugging an electric power meter, and the method completes the debugging of the electric power meter through the design of a standardized address table and the operation of the standardized address table. The standardized address table at least comprises comprehensive attribute information such as parameter names, units, register addresses, data types, byte orders, decimal digits, function codes and instructions. Through the technical means of editing, exporting, importing, analyzing, data reading and data writing of a standardized address table, intelligent partitioning and merging, universal upper computer software architecture template drive development, self-adaptive analysis algorithm, efficient data processing flow and the like, the redundancy of repeated development of the upper computer is remarkably reduced, and the data processing efficiency is improved. Therefore, the consistency and accuracy of the data are improved, and the equipment testing process is accelerated, so that the overall period of project engineering is effectively shortened.

Description

Technical Field

[0001] The present invention relates to the technical field of power meter debugging, and particularly to a general upper computer debugging method for power meter debugging. Background Art

[0002] Currently, when developing power meters based on the Modbus communication protocol, it is necessary to customize an address table for each type of meter and remake the upper computer software to complete the debugging and testing work of the power meter. This leads to a large amount of repetitive development work, wasting human, time, and technical resources. Moreover, the address tables and software for different projects lack a unified standard, resulting in chaotic data management, making it difficult to ensure data consistency, accuracy, and interoperability, and being inefficient in the process of equipment testing and project promotion. Summary of the Invention

[0003] The purpose of the present invention is to overcome the defects existing in the prior art. By designing and implementing a standardized address table format and dynamically parsing a unified data structure, a set of general upper computer software architectures are developed, which can adapt to the configurations of different power meters, thus laying the basic conditions for efficiently completing the automatic testing of power meters.

[0004] To achieve the above purpose, the present invention designs a general upper computer debugging method for power meter debugging. The debugging method completes the power meter debugging work by designing a brand-new standardized address table and operating on the standardized address table. The standardized address table at least includes comprehensive attribute information such as parameter name, unit, register address, data type, byte order, decimal places, function code, and description (used to explain and describe 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 generalization, in sharp contrast to the previous address table designs that only meet the debugging needs of a single meter and have no unified standard. The operations include editing, importing, exporting, parsing, etc. The function code identifies the read-only partition ReadInfo and the readable and writable 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 currently tested power meter; S4. Parse the content of the address table csv file. According to the function code of each row of the address table, automatically divide the file into two structure dictionaries, the read-only partition ReadInfo and the readable and writable partition WriteInfo, Dictionary<class_info>. A new data attribute is added to the dictionary to store the read data; S5. For the read-only partition ReadInfo, a dictionary ReadAddressList<class_addr> needs to be created for background data reading. The class_addr contains two attributes: starting address (class_addr1 and class_addr2), and data length length. Repeat the above step S5 until all information is parsed. S6. For the read-write partition WriteInfo, a dictionary WriteAddressList<class_addr> needs to be created, and the WriteInfo data is parsed and stored in WriteAddressList. S7. Parameter reading: Through the starting address and data length stored in WriteAddressList and / or ReadAddressList, each group is read individually once, and the execution is repeated until all information is read. Generally, parameter reading is performed according to the address and data length of WriteAddressList and / or ReadAddressList. S8. Parameter setting: Reverse-parsing the data type, byte order, decimal places, and unit in the current WriteAddressList address table, restoring them to communication data, and setting them into the power meter, so that the commissioning work of the power meter can be completed according to the parameters of the facility as planned. Steps S5 and S6 have no sequence.

[0005] Furthermore, the adjacent register addresses are consecutive.

[0006] Furthermore, the creation step of the ReadAddressList (i.e., the efficient address grouping algorithm) includes: First, create the 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, distinguish the number of bytes occupied by the register data type, determine the data length length. Assume that the data type of para1 is uint, which occupies 4 bytes and two addresses (two bytes per address), and the length of class_addr1 is 2. Continue to obtain the next parameter para2 in the read-only partition, and determine whether the length + 1 of class_addr1 is equal to 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, 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, keep the length of class_addr1 unchanged and store class_addr1 in ReadAddressList. At the same time, create a new class_addr as 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 obtain the next data in ReadInfo and repeat the above operations for judgment; If the length + 1 of class_addr1 is not the same as the register address of para2, store class_addr1 in ReadAddressList, recreate a class_addr as 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 obtain the next data in ReadInfo and repeat the above operations for judgment; Repeat this process until all the data in ReadInfo is parsed and stored in ReadAddressList.

[0007] Further, the creation step of the WriteAddressList includes: First, create an initial address dictionary class_addr as class_addr1. Obtain the first parameter para1, assign the register address of para1 to the starting address of class_addr1, obtain the register data type of para1, distinguish the number of bytes occupied by the register data type, and determine the data length length. Assume that the data type of para1 is uint, which occupies 4 bytes and two addresses (two bytes per address), and the length of class_addr1 is 2; Continue to fetch the next parameter para2 in the read-only partition, and determine whether the length + 1 of class_addr1 is equal to 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, 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, keep the length of class_addr1 unchanged and store class_addr1 in WriteAddressList. At the same time, create a new class_addr as 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 fetch the next data in WriteInfo and repeat the above operations for judgment; If the length + 1 of class_addr1 is not the same as the register address of para2, store class_addr1 in ReadAddressList, re-create a class_addr as 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 fetch the next data in WriteInfo and repeat the above operations for judgment; Repeat this process until all the data in WriteInfo is parsed and stored in WriteAddressList.

[0008] Further, the communication address length a <= 100.

[0009] Further, the method for reading the WriteAddressList parameter includes: For the first class_addr, taking the first class_addr in WriteAddressList as an example, record the starting address as m, the data length as n, read n addresses and 2n bytes of data (one address stores two bytes), and store them in ushort[] buffer. Traverse all the structs class_info in WriteInfo, and judge one by one whether addr + length of class_info is within n + m. If it is, it means the currently read data is among them. Take the data from buffer[m - addr] to buffer[m - addr + 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 then adjust according to the decimal places. The obtained data is stored in the data of class_info. If it is not, ignore it; Execute in a loop until all of WriteAddressList is read and parsed one by one and stored in WriteInfo is completed; The method for reading the parameters of the ReadAddressList is the same as that of the WriteAddressList. Repeat the reading to update the data in ReadInfo in real time and update the display on the interface in real time.

[0010] Furthermore, the standardized address table further includes description information, and the content of the parameter setting also includes description information.

[0011] Furthermore, the debugging method further includes generating a general upper 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 (big endian or little endian mode), decimal places dcm, function code fun_num, and description disc.

[0012] The advantages and beneficial effects of the present invention are as follows: 1. Design and implementation of the standardized address table format: Design 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. This requires an in-depth understanding of the communication protocols and data structures between different devices. Implement this standardized format and ensure that it can be applied to various types of power meters, which requires a wide understanding and precise grasp of the communication protocols and data formats of various meters.

[0013] 2. Dynamic Parsing of Unified Data Structure: Automatically divide the address table into "read-only" and "read-write" partitions according to the function code, which requires the development of an intelligent partitioning algorithm. The present invention can accurately identify and classify different data regions by defining the function code. Dynamically merge the data structure through the continuity of register addresses, such as merging into ReadAddressList / WriteAddressList, which requires the algorithm to be highly flexible and adaptable to handle 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 configurations of different instruments, which requires in-depth understanding and practical experience in the development of host computer software; by importing standard templates, automatically divide them into two major modules according to the read-write attributes of the template parameters, and then display two panels on the interface according to the address sorting, that is, generate the host computer software for the current device template, which requires the design of an efficient and flexible template system that can support the rapid generation and configuration of software.

[0015] 4. Adaptive Parsing Algorithm: Based on the register data type (such as Uint16, Float, ASCII, etc.) and byte order, automatically parse the raw data and convert it into the actual physical quantity (for example, for parameter A, read data B according to the address of A, then adjust the high and low bits of B according to the byte order attribute of A, then parse the corresponding data according to the data type attribute, and then perform division conversion on the data according to the decimal point attribute), which requires the algorithm to have strong data processing capabilities and compatibility; adjust according to the number of decimal places to ensure the accuracy of the data, which requires precise control over the precision and format of the data.

[0016] 5. Efficient Data Processing Process and Dynamic Address Grouping: Intelligently group consecutive register addresses, such as using 90 bytes as the threshold, to optimize the data reading efficiency, which requires the development of an efficient address grouping algorithm that can be flexibly adjusted according to the communication characteristics and requirements of different devices. Achieve real-time data update and display to ensure that users can obtain the latest device status and data at any time, which requires the system to have a high degree of real-time performance and response speed.

[0017] 6. Reverse Parsing Mechanism: Support reverse parsing the parameter values input by users into communication data and writing them into the device to achieve the automation of two-way interaction, which requires the development of a reverse parsing algorithm (for example, for parameter A, when writing data B, first perform multiplication conversion on the data according to the decimal point attribute, parse 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, that is, obtain the transmission data), which can accurately convert the user input into communication data recognizable by the device. Description of the Drawings

[0018] Figure 1It is a flowchart of the general host computer debugging method; Figure 2 It is a detailed flowchart of software reading and writing; Figure 3 It is a detailed flowchart of partition data polling. Specific implementation manners

[0019] The following combines the accompanying drawings and embodiments to further describe the specific implementation manners of the present invention. The following embodiments are only used to more clearly illustrate the technical solutions of the present invention, and cannot be used to limit the protection scope of the present invention.

[0020] Embodiment 1: A general host computer debugging method for power meter debugging according to the present invention, as Figure 1 and Figure 2 shown, the debugging method completes the power meter debugging work by designing a new standardized address table and operating on the standardized address table. The standardized address table at least 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 a foundation for subsequent efficient processing and generalization, in sharp contrast to the previous address table design that only meets the debugging needs of a single meter and has no unified standard. The operations include editing, importing, exporting, parsing, etc. The function code identifies the read-only partition ReadInfo and the readable and writable 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 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. The attributes of each row of data class_info include parameter name, parameter unit, register address, register data type, byte order (big-endian or little-endian mode), decimal places, function code, and description; S2. Export the address table file. For example, after editing the required addresses, export the template. The different attributes of each row of data are separated by ",", and each row of data is a line to generate a csv file (a pure text file used to store table and spreadsheet information); S3. Select the parse template function and import the address table file, that is, import the csv file corresponding to the current test power meter; S4. Analyze the content of the address table csv file. According to 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, Dictionary<class_info>. A new data attribute "data" is added to the dictionary to store the read data. S5. For the read-only partition ReadInfo, a dictionary ReadAddressList<class_addr> needs to be created for background data reading. The class_addr contains two attributes, the starting address (class_addr1 and class_addr2), and the data length length. Repeat the above step S5 until all information is parsed. S6. For the read-write partition WriteInfo, a dictionary WriteAddressList<class_addr> needs to be created, and the WriteInfo data is parsed and stored in WriteAddressList. S7. Parameter reading. In this embodiment, a "parameter reading" button is set. Clicking this button, through the starting address and data length stored in WriteAddressList and / or ReadAddressList, each group is read one by one once, and the execution is repeated until all information is read. Generally, 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, reverse parsing is performed on the data type, byte order, decimal places, and unit in the current WriteAddressList address table, restored to communication data, and set into the power meter, so that the commissioning work of the power meter can be completed according to the parameters of the facility as planned. Steps S5 and S6 have no order. In this embodiment, the execution is in the order of S1, S2, S3, S4, S5, S6, S7, S8.

[0021] Preferably, the adjacent register addresses are continuous. In the present invention, the continuity of the register addresses facilitates the dynamic merging of data structures, which can significantly reduce data redundancy. The continuity of the register addresses makes the lengths of ReadAddressList and WriteAddressList shorter, reduces the number of modbus communications executed during subsequent read and write operations, and speeds up the communication timeliness and data real-time update speed. For example, 10 parameters with continuous addresses can be obtained by 10 communication instructions to get the data, but after merging the addresses into a data structure, the data can be obtained by 1 instruction.

[0022] Preferably, as Figure 3 shown, the step of creating the ReadAddressList (i.e., the partition data polling process) includes: First, create the 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, distinguish the number of bytes occupied by the register data type, determine the data length length. Assume the data type of para1 is uint, which occupies 4 bytes and two addresses (one address is two bytes), and the length of class_addr1 is 2; Continue to take the next parameter para2 in the read-only partition, and judge whether length + 1 of class_addr1 is equal to the register address of para2. If they are the same, then 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, where a is the communication address length, then assign length + n / 2 to the length of class_addr1 and store it in the ReadAddressList; if length + n / 2 > a, then keep the length of class_addr1 unchanged and store class_addr1 in the ReadAddressList. At the same time, create a new class_addr as 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 take the next data in ReadInfo and repeat the above operations for judgment; If length + 1 of class_addr1 is not the same as the register address of para2, then store class_addr1 in the ReadAddressList, recreate a class_addr as 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 take the next data in ReadInfo and repeat the above operations for judgment; Repeat this process until all the data in ReadInfo is parsed and stored in the ReadAddressList.

[0023] Preferably, as Figure 3 shown, the step of creating the WriteAddressList includes: First, create the 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, distinguish the number of bytes occupied by the register data type, and determine the data length length. Assume the data type of para1 is uint, which occupies 4 bytes and two addresses (two bytes per address), so the length of class_addr1 is 2; Continue to take the next parameter para2 in the read-only partition. Determine whether the length + 1 of class_addr1 is equal to the register address of para2. If they are the same, then 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 WriteAddressList; if length + n / 2 > a, where a is the communication address length, then keep the length of class_addr1 unchanged and store class_addr1 in WriteAddressList. At the same time, create a new class_addr as 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 take the next data in WriteInfo and repeat the above operations for judgment; If the length + 1 of class_addr1 is not the same as the register address of para2, then store class_addr1 in ReadAddressList, re-create a class_addr as 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 take the next data in WriteInfo and repeat the above operations for judgment; Repeat this process until all the data in WriteInfo is parsed and stored in WriteAddressList.

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

[0025] Preferably, the method for reading the WriteAddressList parameter includes: For the first class_addr, taking the first class_addr in WriteAddressList as an example, record the starting address as m, the data length as n, read n addresses and 2n bytes of data (each address stores two bytes), and store them in ushort[] buffer; traverse all the structs class_info in WriteInfo, and judge one by one whether addr+length of class_info is within n+m. If it is, it means the currently read data is among them. Take the data from buffer[m-addr] to buffer[m-addr+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 then adjust according to the decimal places. The obtained data is stored in the data of class_info; if not, ignore it. Execute in a loop until all of WriteAddressList is read and parsed one by one and stored in WriteInfo is completed; The method for reading the parameters of the ReadAddressList is the same as that of the WriteAddressList. Repeat the reading to update the data in ReadInfo in real time and update the display on the interface in real time.

[0026] Preferably, the standardized address table further includes description information, and the content of the parameter setting also includes description information.

[0027] Preferably, the debugging method further includes generating a general upper 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 (big-endian or little-endian mode), decimal places dcm, and function code fun_num.

[0028] Embodiment 2: The difference from Embodiment 1 is that the communication address length a = 100 in this embodiment.

[0029] Embodiment 3: The difference from Embodiment 1 is that this embodiment is executed in the order of S1, S2, S3, S4, S6, S5, S7, S8.

[0030] Embodiment 4: The difference from Embodiment 1 is that the standardized address table further includes description information, and the content of the parameter setting also includes description information.

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

[0032] The basic principle of the present invention is: The present invention proposes a general-purpose host computer debugging method for power meter debugging, and its working principle 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) including attributes such as parameter name, register address, data type, and endian is defined to solve the problem of inconsistent address table formats in the past.

[0034] In practical applications, the user opens the standardized address table through a dedicated host computer software and edits the address table according to the standard format. After editing, the address table is exported as a CSV file.

[0035] Next, the host computer software selects the parsing template function and imports the CSV file. The software parses the content of the CSV file, automatically divides the address table into two partitions, "read-only" (ReadInfo) and "read-write" (WriteInfo), according to the function code of each row, and realizes dynamic merging of the data structure through register address continuity and data type consistency, significantly reducing data redundancy.

[0036] In the data reading stage, the host computer software performs single reads one by one through dynamically generated address lists (such as ReadAddressList and WriteAddressList), and automatically parses the original data into actual physical quantities according to the register data type and endian, and updates the data display on the interface in real time.

[0037] In the data writing stage, the user can reverse-parsing the current data according to the data type, endian, decimal places, unit, and description in the address table through the host computer software, restore it to communication data, and set it into the meter to achieve the automation of two-way interaction.

[0038] This general-purpose host computer debugging method significantly reduces the redundancy of repeated development of the host computer, improves the consistency and accuracy of data, accelerates the device testing process, and effectively shortens the overall cycle of the project through technical means such as standardized address table format, intelligent partitioning and merging, general-purpose host computer software architecture template-driven development, adaptive parsing algorithm, and efficient data processing flow.

[0039] The above are only the preferred embodiments of the present invention. It should be noted that for those of ordinary skill in the art, without departing from the technical principles of the present invention, including the partition division method, the composition of the attribute information of the standard template, the dynamic parsing method, etc., several improvements and refinements can still be made, and these improvements and refinements should also be regarded as the protection scope of the present invention.

Claims

1. A general host computer debugging method for power meter debugging, as shown in Figure 1, characterized in that, The debugging method completes the debugging work 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, number of 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 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; S2. Export the address table file; S3. Select the parsing template function and import the address table file; S4. Parse the content of the address table file. According to the function code of each row of the address table, automatically divide the file into two structure dictionaries, the read-only partition ReadInfo and the read-write partition WriteInfo, Dictionary<class_info>. A new data property named data is added to the dictionary to store the read data; S5. For the read-only partition ReadInfo, a dictionary ReadAddressList<class_addr> needs to be created for background data reading. The class_addr contains two attributes, start address and data length length; Repeat the above step S5 until all information is parsed; S6. For the read-write partition WriteInfo, a dictionary WriteAddressList<class_addr> needs to be created, and the WriteInfo data is parsed and stored in WriteAddressList; Repeat the above step S6 until all information is parsed; S7. Parameter reading: Perform single reading one by one for each group through the start address and data length stored in WriteAddressList and / or ReadAddressList, and repeat the execution until all information is read; S8. Parameter setting: Reverse-parsing the data type, byte order, number of decimal places, and unit in the current WriteAddressList address table, restoring them to communication data, and setting them into the power meter; Steps S5 and S6 have no sequence; 2. The general host computer debugging method for power meter debugging according to claim 1, characterized in that, Adjacent register addresses are consecutive; 3. A general host computer debugging method for power meter debugging according to claim 1, characterized in that The steps for creating the ReadAddressList include: First, create the start address dictionary class_addr as class_addr1, take the first parameter para1, assign the register address of para1 to the start address of class_addr1, take the register data type of para1, distinguish the number of bytes occupied by the register data type, and determine the data length length; Continue to obtain the next parameter para2 in the read-only partition, and determine whether the length + 1 of class_addr1 is equal to 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, 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, keep the length of class_addr1 unchanged and store class_addr1 in ReadAddressList. At the same time, create a new class_addr as 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 obtain the next data in ReadInfo and repeat the above operations for judgment; If the length + 1 of class_addr1 is not the same as the register address of para2, store class_addr1 in ReadAddressList, recreate a class_addr as 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 obtain the next data in ReadInfo and repeat the above operations for judgment; Repeat this process until all the data in ReadInfo is parsed and stored in ReadAddressList.

4. A general host computer debugging method for power meter debugging according to claim 1, characterized in that, The steps for creating the WriteAddressList include: First, create a starting address dictionary class_addr as class_addr1, obtain the first parameter para1, assign the register address of para1 to the starting address of class_addr1, obtain the register data type of para1, distinguish the number of bytes occupied by the register data type, and determine the data length length; Continue to take the next parameter para2 in the read-only partition, and determine whether the length + 1 of class_addr1 is equal to the register address of para2. If they are the same, then 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 WriteAddressList; if length + n / 2 > a, where a is the communication address length, then keep the length of class_addr1 unchanged and store class_addr1 in WriteAddressList. At the same time, create a new class_addr as 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 take the next data in WriteInfo and repeat the above operations for judgment; If the length + 1 of class_addr1 is not the same as the register address of para2, then store class_addr1 in ReadAddressList, re-create a class_addr as 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 take the next data in WriteInfo and repeat the above operations for judgment; Repeat this process until all the data in WriteInfo is parsed and stored in WriteAddressList.

5. A general upper computer debugging method for power meter debugging according to claim 3 or 4, characterized in that, The communication address length a <= 100.

6. The general host computer debugging method for power meter debugging according to claim 1, characterized in that The method for reading the WriteAddressList parameter includes: For the first class_addr, record the starting address as m and the data length as n. Read n addresses and 2n bytes of data and store them in ushort[] buffer; traverse all the structure class_info in WriteInfo, and judge one by one whether addr + length of class_info is within n + m. If it is, it means the currently read data is among them. Take the data from buffer[m - addr] to buffer[m - addr + 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 then adjust according to the decimal places. The obtained data is stored in the data of class_info; if not, ignore it; Execute in a loop until all of WriteAddressList is read and parsed one by one and stored in WriteInfo is completed; The method for reading the ReadAddressList parameter is the same as the method for reading the WriteAddressList parameter.

7. A general host computer debugging method for power meter debugging according to claim 1, characterized in that, The standardized address table further includes description information, and the content of the parameter setting also includes description information.

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

Images