Object-oriented communication implementation method and device and electronic equipment
Through object-oriented programming, communication objects are created for slave machines, and the host traverses data entries to obtain and process data. This solves the problem of scattered data processing functions in the traditional Modbus protocol, and realizes the unification of functions and the simplification of maintenance.
Patent Information
- Application Number
- CN202411914848.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-24
- Publication Date
- 2025-01-24
- Estimated Expiration
- Not applicable · inactive patent
AI Technical Summary
In the communication scenario of the traditional Modbus protocol, the host needs to store slave data first and then process it, resulting in scattered and different data processing functions, and inconsistent entrances and exits, making it difficult to maintain.
Use object-oriented programming to create communication objects for slave machines. The communication objects contain multiple data entries, and each data entry includes multiple fields. The host traverses the data entries in the slave communication object, obtains the target data, and processes and updates the data based on the fields.
Unification of data processing is achieved, and the logical processing unit does not need to pay attention to data differences provided by different merchant devices, simplifying maintenance and expansion.
Smart Images

Figure CN119356910A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of communication technology, and in particular to an object-oriented communication implementation method, device and electronic device. Background Art
[0002] Modbus protocol is commonly used in industrial control. Modbus protocol has the advantages of simplicity, openness and easy implementation. However, in the traditional Modbus protocol communication scenario, after the host reads data from each slave, it generally stores the data first and then processes the stored data. Due to the differences in data types, data transmission types, data units, etc. of the same type of equipment from different merchants, the data processing functions are usually scattered and different, and there are inconsistencies in the entrances and exits of data processing. This means that when providing data to other logical processing units for processing, it is necessary to pay attention to the specific circumstances of the data of different merchants, and there are problems such as scattered and different functions, which makes it difficult to maintain. Summary of the invention
[0003] One or more embodiments of the present application provide an object-oriented communication implementation method, device, and electronic device to achieve unified functional implementation.
[0004] In a first aspect, one or more embodiments of the present application provide an object-oriented communication implementation method, the method is applied to a host, the host is communicatively connected with multiple slaves, the host stores communication objects created for each of the slaves in an object-oriented manner, each of the communication objects includes multiple data entries, each of the data entries includes multiple fields, the method includes: For a target slave among the multiple slaves, traverse each data entry in the communication object of the target slave, and obtain corresponding target data according to the traversed data entry; Processing the target data based on the fields in the data entry; The corresponding original data in the locally stored data table is updated according to the processed target data, wherein the locally stored data table provides the required data to the logic processing unit through a unified interface.
[0005] In an optional implementation manner, the step of acquiring corresponding target data according to the traversed data entries includes: A data read request is sent to the target slave based on the traversed data entries, and target data fed back by the target slave in response to the data read request is obtained.
[0006] In an optional embodiment, the plurality of fields include a register address field and a register quantity field; The step of acquiring corresponding target data according to the traversed data entries includes: Obtaining the register start address of the required data in the target slave according to the register address field in the traversed data entry, and obtaining the number of consecutive registers required to read the required data according to the register number field; A data read request is generated based on the register start address and the required number of consecutive registers, the data read request is sent to the target slave, and target data fed back by the target slave in response to the data read request is obtained.
[0007] In an optional implementation manner, the step of acquiring corresponding target data according to the traversed data entries includes: According to the traversed data entries, the target data is calculated based on the locally saved data and the preset formula.
[0008] In an optional embodiment, the plurality of fields include a calculation formula field; The step of acquiring the corresponding target data according to the traversed data entry includes: determining the data required for calculation from the locally stored data according to the information in the calculation formula field in the traversed data entry; The target data is calculated based on the data required for the calculation and the preset formula in the calculation formula field.
[0009] In an optional implementation, the multiple fields include a data type field and a byte order field, and the data type field supports multiple data type settings; The step of processing the target data based on the fields in the data entry includes: Converting the byte order of the target data based on the byte arrangement pattern in the byte order field in the data entry; The data type of the target data after the conversion process is converted into the data type in the data type field.
[0010] In an optional embodiment, the plurality of fields further include a scaling factor field and an offset field; The step of processing the target data based on the fields in the data entry further includes: Scaling the target data according to the scaling factor in the scaling factor field in the data entry; The scaled target data is subjected to an offset process according to the offset in the offset field to obtain standardized target data.
[0011] In an optional implementation manner, after the step of processing the target data based on the fields in the data entry, the method further includes: Detecting whether an abnormality detection function is triggered, and if the abnormality detection function is triggered, executing the abnormality detection function to compare the target data with the corresponding original data in the locally stored data table to obtain a comparison result; When the comparison result indicates that an abnormality exists, an abnormality alarm message is triggered.
[0012] In an optional implementation manner, the communication object further includes device identification information and communication parameters of the slave; The device identification information includes the communication address, device name and communication mode of the slave; The communication parameters include a minimum communication cycle for communicating with the slave, a timeout period for a single communication, and a number of retries after a communication failure.
[0013] In a second aspect, one or more embodiments of the present application provide an object-oriented communication implementation device, the device is applied to a host, the host is communicatively connected with multiple slaves, the host stores communication objects created for each of the slaves in an object-oriented manner, each of the communication objects includes multiple data entries, each of the data entries includes multiple fields, and the device includes: A data acquisition module, for traversing each data entry in the communication object of a target slave among the multiple slaves, and acquiring corresponding target data according to the traversed data entry; A data processing module, used for processing the target data based on the fields in the data entry; The data storage module is used to update the corresponding original data in the locally stored data table according to the processed target data, wherein the locally stored data table provides the required data to the logic processing unit through a unified interface.
[0014] In a third aspect, one or more embodiments of the present application provide an electronic device, comprising a memory and a processor, wherein the memory stores a computer program that can be executed on the processor, and when the processor executes the computer program, the steps of the method described in any of the aforementioned implementation methods are implemented.
[0015] The present application provides an object-oriented communication implementation method, device and electronic device, in which communication objects created for each slave in an object-oriented manner are stored in the host, each communication object includes multiple data entries, each data entry includes multiple fields, and for a target slave among multiple slaves, the host traverses each data entry in the communication object of the target slave, and obtains the corresponding target data according to the traversed data entry. The target data is processed based on the fields in the data entry, and the corresponding original data in the locally stored data table is updated according to the processed target data. The locally stored data table provides the required data to the logic processing unit through a unified interface. In this solution, the data is first processed and then stored based on the pre-created communication object. In this way, a unified interface is provided to provide data to the logic processing unit, and the logic processing unit does not need to pay attention to the differences in the original data provided by each slave, thereby achieving unified function implementation. BRIEF DESCRIPTION OF THE DRAWINGS
[0016] In order to more clearly illustrate the technical solutions of one or more embodiments of the present application, the drawings required for use in the embodiments of the present application will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.
[0017] Figure 1 A schematic diagram of an application scenario of the object-oriented communication implementation method provided in an embodiment of the present application; Figure 2 A flowchart of an object-oriented communication implementation method provided in an embodiment of the present application; Figure 3 Another flow chart of the object-oriented communication implementation method provided in the embodiment of the present application; Figure 4 for Figure 2 A flowchart of the sub-steps included in S12; Figure 5 for Figure 2 Another flow chart of the sub-steps included in S12; Figure 6 for Figure 2 A flowchart of the sub-steps included in S13; Figure 7 for Figure 2 Another flow chart of the sub-steps included in S13; Figure 8 A functional module block diagram of an object-oriented communication implementation device provided in an embodiment of the present application; Fig. 9 A structural block diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0018] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.
[0019] See also Figure 1 , is a schematic diagram of an application scenario of the object-oriented communication implementation method provided in an embodiment of the present application, the application scenario includes a host and multiple slaves, the host is communicatively connected with each slave, specifically, the host and each slave can communicate using the Modbus protocol.
[0020] The application scenarios of this embodiment may include energy management system scenarios, industrial automation control scenarios, etc.
[0021] The host can obtain the required data from each slave, and after processing the data, provide it to the logic processing unit to perform other related logic processing.
[0022] Each slave may include devices from different manufacturers, such as inverters, analog-to-digital converters, and other devices.
[0023] In this embodiment, the host stores communication objects created for each slave in an object-oriented manner. In object-oriented programming, objects are the basic building blocks of a program, which encapsulate data (attributes) and methods (functions) for operating data. The communication objects constructed for each slave include multiple data entries, and each data entry includes multiple fields. Each data entry can be understood as a specific data item of data required to be obtained when interacting with the slave, and these data items are described by specific information under each field. For example, the fields in the data entry can describe information such as register address, data type, unit conversion parameters, etc.
[0024] In addition to data entries, the communication object also includes other information required for communication with the slave, such as the slave's device identification, communication parameters, etc. This information and data entries are encapsulated together to form the communication object. When the host and the slave interact with each other, the host will perform data interaction based on the pre-built communication object of the slave.
[0025] See also Figure 2 , is a flow chart of an object-oriented communication implementation method provided in an embodiment of the present application. The object-oriented communication implementation method can be executed by an object-oriented communication implementation device. The object-oriented communication implementation device can be implemented by software and / or hardware and can be configured in an electronic device. The electronic device can be the above-mentioned host, a computer device, a server, a programmable logic controller, etc. The detailed steps of the object-oriented communication implementation method are described as follows.
[0026] S11, for a target slave among the multiple slaves, traverse each data entry in the communication object of the target slave.
[0027] S12, obtaining corresponding target data according to the traversed data entries.
[0028] S13, processing the target data based on the fields in the data entry.
[0029] S14, updating the corresponding original data in the locally stored data table according to the processed target data, wherein the locally stored data table provides the required data to the logic processing unit through a unified interface.
[0030] In this embodiment, the target slave may be any slave among a plurality of slaves communicating with the host, and the host stores the communication object of the target slave.
[0031] According to each data entry in the pre-built communication object of the target slave, it can be determined which data needs to be obtained from the target slave. It can be understood that each data entry is a related description of each required data.
[0032] In implementation, the host usually actively obtains the required data from each slave at a certain frequency. Specifically, each data entry in the communication object of the slave can be traversed at a certain frequency, and each data entry indicates the corresponding required data. Therefore, the corresponding target data can be obtained according to the traversed data entry. The target data can be, for example, voltage data, current data, power data, etc.
[0033] Each data entry includes multiple fields, and the information under each field indicates the relevant processing of the target data, such as the data type to which the target data is converted, the byte order processing of the target data, the conversion of the unit of the target data into a unified unit, etc.
[0034] Therefore, after acquiring the target data, the target data can be processed according to the indicated related processing based on the fields in the data entry. In this way, it is possible to achieve data processing supporting multiple data types, unification of data units, and standardization of data byte order.
[0035] The host continuously obtains various data of the target slave, and the obtained data is saved locally in the form of a data table. Therefore, after obtaining the latest target data and processing it, the corresponding original data in the data table can be updated according to the processed target data to ensure that the latest data is saved in the data table.
[0036] In this embodiment, the locally stored data table provides the required data to the logic processing unit through a unified interface, wherein the unified interface can be understood as providing the logic processing unit with a unified standard format for each slave and for each different data of the slave. The logic processing unit can be a unit that performs other specific logic processing in the system, such as a specific logic processing unit for power analysis, current analysis, voltage analysis, etc.
[0037] In this way, when facing different types of slaves, different slaves for the same data of different data types, different units and other processing scenarios, because the host has processed the data obtained from each slave according to the pre-built communication object and then saved it in the data table, the data table is used to provide the required data to the logic processing unit through a unified interface. Therefore, the logic processing unit does not need to pay attention to the differences in the original data provided by each slave, thereby realizing the unification of function implementation.
[0038] In this embodiment, the communication object constructed in the host also includes the device identification information and communication parameters of the slave. In an object-oriented manner, the device identification information, communication parameters, data entries and other information are encapsulated in the communication object, which is convenient for unified management. When a new slave needs to be connected to the system, it is only necessary to create a corresponding communication object and fill in the required attribute information without modifying the underlying communication code. In the prior art, a large amount of code modification is required when adding a new slave, and the scalability is poor.
[0039] As shown in Table 1, the device identification information includes the communication address, device name and communication mode of the slave. The communication address can be the Modbus communication address of the device, the device name can reflect the name and device type identification, etc., and the communication mode includes Modbus RTU, Modbus TCP, etc.
[0040] Table 1 Equipment identification information table
[0041] As shown in Table 2, the communication parameters include the minimum communication cycle for communicating with the slave, the timeout time of a single communication, and the number of retries after communication failure. Among them, the minimum communication cycle represents the minimum time interval for communicating with the slave, and the unit can be milliseconds. The timeout time represents the maximum duration of a single communication, and the unit can be milliseconds. The number of retries represents the maximum number of retries in the event of communication failure.
[0042] Table 2 Communication parameters
[0043] In addition, the communication parameters may also include a data entry list item, which includes the collection information of all data entries of the constructed slave, which can be used as an index of the data entry. When traversing each data entry, the traversal can be performed based on the collection information in the data entry list item, and then indexed to each traversed data entry.
[0044] In the traditional Modbus protocol communication method, only basic data types are usually supported, such as 16-bit and 32-bit integers, and floating-point numbers and more complex data types are not supported enough. Different devices may use different physical units. For example, voltage may be expressed in volts (V) or kilovolts (kV), which cannot be directly compared and processed in the system. The data items and formats provided by the devices may vary. Traditional programs need to write specific codes for each device, which lacks versatility. When new devices need to be added or device parameters need to be changed, the code often needs to be modified, resulting in high maintenance and upgrade costs.
[0045] In view of the above problems, there are currently many ways in the prior art to improve the above problems. For example, the problem is improved by enhanced Modbus, that is, some open source or commercial Modbus libraries add support for multiple data types, such as floating point numbers and 64-bit integers. However, these libraries usually only support the underlying communication and fail to provide a unified data processing and management mechanism.
[0046] In addition, there is also a way to use protocol converters or gateway devices to convert the communication protocols and data formats of different devices into a unified format for use by management or monitoring systems. However, this method increases the complexity and cost of the system, and the processing of data types still requires additional work.
[0047] Some systems also develop customized communication modules for each device and manually handle data type conversion and unit conversion. This approach is feasible but inefficient and not scalable.
[0048] In addition, some developers try to use object-oriented programming ideas to create device objects to encapsulate device communication and data processing. However, these implementations often only focus on the communication process, and lack support for data type processing and unit standardization, and cannot completely solve compatibility issues.
[0049] It can be seen that the methods in the prior art have improved the flexibility and compatibility of Modbus communication to a certain extent, but there are still defects such as lack of a unified data processing mechanism, insufficient scalability, and imperfect data difference processing. Specifically, it is impossible to uniformly parse and standardize multiple data types and units, resulting in complex and difficult to maintain code. Adding new devices or changing device parameters requires a lot of code modifications, which cannot quickly adapt to changes in system requirements. There is no flexible mechanism to handle the differences in data items provided by the devices, especially for data items that need to be calculated, and there is insufficient support.
[0050] In view of the problems existing in the above-mentioned prior art, in this embodiment, a communication object is constructed for each slave, and a data entry is encapsulated in the communication object, so as to improve the above-mentioned problems by setting the fields in the data entry.
[0051] As shown in Table 3, the multiple fields in each data entry include a data transmission type field, and the data transmission type field includes a transparent transmission type and a local calculation type. Among them, the data required for the transparent transmission type representation can be directly provided by the slave, and the data required for the local calculation type representation needs to be calculated from other related data.
[0052] Please refer to Figure 3 In a possible implementation, the above step of obtaining the corresponding target data according to the traversed data entries can be implemented in the following way: S12A, sending a data read request to a target slave based on the traversed data entry, and obtaining target data fed back by the target slave in response to the data read request.
[0053] In this embodiment, when the data transmission type is the transparent transmission type, it indicates that the required target data can be directly provided by the target slave machine, and therefore, a data read request can be sent to the target slave machine to request to obtain the target data.
[0054] Table 3 Data entry table
[0055] As shown in Table 3, the multiple fields of the data entry further include a register address field and a register quantity field. The information in the register address field and the register quantity field is used to indicate how to obtain the required target data from the target slave.
[0056] See also Figure 4 Specifically, in this embodiment, the step of obtaining the corresponding target data according to the traversed data entries can be implemented in the following way: S121A, obtain the register start address of the required data in the target slave according to the register address field in the traversed data entry, and obtain the number of consecutive registers required to read the required data according to the register number field.
[0057] S122A, generating a data read request based on the register start address and the required number of consecutive registers, sending the data read request to the target slave, and obtaining the target data returned by the target slave in response to the data read request.
[0058] In this embodiment, the required data is the target data. In this way, a data read request carrying the register starting address and the number of consecutive registers is sent to the target slave. The target slave can read the target data based on the register starting address and the number of consecutive registers in the data read request, and feed the target data back to the host.
[0059] In this process, after the host sends a data read request to the target slave, it can monitor whether the target slave has a response timeout problem, and can determine whether there is a timeout problem based on the timeout time in the communication parameters. If there is a response timeout problem, a communication timeout exception message can be triggered to indicate the existence of a timeout exception.
[0060] In order to ensure data integrity, the host may also verify the received target data, for example, using a CRC verification method.
[0061] In addition, when the data transmission type field in the data entry is the local calculation type, the target slave cannot directly provide the required target data, but needs to calculate the target data based on other data obtained. For example, when the required target data is power data, some slaves do not need to directly provide power data, but need to calculate the power data based on voltage data and current data.
[0062] Based on this, please refer to Figure 3 In another possible implementation, the step of obtaining the corresponding target data according to the traversed data entries can be implemented in the following way: S12B, according to the traversed data entries, the target data is calculated based on the locally stored data and according to the preset formula.
[0063] For this situation, as shown in Table 3, multiple fields of the data entry also include a calculation formula field. Figure 5 , according to the steps of traversing the data entries to obtain the corresponding target data, which can be implemented in the following ways: S121B, determining data required for calculation from locally stored data according to information in a calculation formula field in the traversed data entry.
[0064] S122B, obtaining target data based on the data required for calculation and the preset formula in the calculation formula field.
[0065] Taking the calculation formula fields shown in Table 3 as an example, the required target data needs to be calculated through relevant calculation methods based on data A and data B. Therefore, data A and data B can be determined from the data saved locally.
[0066] The specific calculation method is data A multiplied by data B. Therefore, data A multiplied by data B can be used to obtain the required target data.
[0067] The solution provided in this embodiment supports data transmission methods such as transparent transmission type and local calculation type, which can flexibly cope with the differences in device data provision and ensure that the system is compatible with various devices. Even if the device fails to directly provide certain data, the required data can be obtained through local calculation and other methods, reducing the dependence on device hardware.
[0068] After obtaining the target data by any of the above methods, the target data is processed according to the attribute information pre-configured in the fields of the data entry, wherein the fields of the data entry include a data type field and a byte order field, and the data type field supports multiple data type devices. Figure 6 , the step of processing the target data may include the following sub-steps: S131, converting the byte order of the target data based on the byte arrangement pattern in the byte order field in the data entry.
[0069] S132, converting the data type of the converted target data into the data type in the data type field.
[0070] Byte order refers to the order in which bytes of multi-byte data are arranged in registers, mainly including big-endian mode and little-endian mode. In big-endian mode, the highest-order byte of a data is stored at the lowest memory address, and the lowest-order byte is stored at the highest memory address. In other words, the byte order of the data is consistent with the growth of the memory address. In little-endian mode, the lowest-order byte of a data is stored at the lowest memory address, and the highest-order byte is stored at the highest memory address. Contrary to big-endian mode, the byte order of the data is opposite to the growth direction of the memory address.
[0071] Different computer architectures may use different byte orders, so the specific byte order in the byte order field can be determined based on the host computer architecture.
[0072] After acquiring the target data, the byte order of the target data is converted according to the byte arrangement mode in the byte order field to ensure the accuracy of the target data parsing.
[0073] Considering that the same type of devices from different manufacturers transmit different data types, when each slave transmits data to the host, during the data transmission process, according to the Modbus communication standard, in the message frame, the data format will be converted to uint16 or uint8 for transmission. This is a mandatory requirement of the protocol standard.
[0074] Therefore, in order to support data processing of different data types on different devices, multiple data types can be set in the data type field, such as integer types: int16, uint16, int32, uint32, int64, uint64, etc., floating-point types: float (32-bit IEEE 754 floating-point number), double (64-bit IEEE 754 floating-point number), etc.
[0075] The host converts the data type of the target data after the byte order conversion processing into the data type in the data type field according to the data type in the data type field.
[0076] For example, for data a of the target slave, the data type of the data a in the local target slave is float type. Therefore, when constructing a communication object for the target slave, the data type in the data entry related to data a is set to float type.
[0077] When the host needs to obtain data a from the target slave, the target slave converts the local float type data a into uint16 or uint8 type according to the Modbus standard requirements and transmits it to the host. After obtaining the data a and performing byte order conversion and other processing, the host converts the data type of the obtained data a according to the data type in the data entry, that is, converts the uint16 or uint8 type into the float type.
[0078] In this embodiment, a data type field is introduced in the communication object, supporting multiple data types such as double, float, uint64_t, int64_t, etc., and can automatically parse and process according to the data type returned by the device. Compared with the defects of the prior art that usually only supports basic data types, cannot adapt to complex data requirements, and limits the compatibility and flexibility of the system, this solution can handle multiple data types, meet the data requirements of different devices, and improve the compatibility of the system.
[0079] Considering that the data units sent by devices from different manufacturers may be different, for example, some devices send voltage data in volts (V), while some devices send voltage data in kilovolts (kV), which makes it impossible to directly compare and process them in the system.
[0080] In addition, the data sent by different devices may have different zero offsets, so the multiple fields of the data entry also include the scaling factor field and the offset field. Figure 7 In the step of processing the target data based on the fields in the data entry, the following sub-steps may also be included: S133, scaling the target data according to the scaling factor in the scaling factor field in the data entry.
[0081] S134, performing an offset process on the scaled target data according to the offset in the offset field to obtain standardized target data.
[0082] In this embodiment, the target data is voltage data as an example, assuming that the system uses volts as the standard unit. If the unit of the voltage data of the target slave is kilovolts, the scaling factor in the scaling factor field in the data entry of the voltage data in the communication object of the target device is 1000. That is, after the host obtains the voltage data from the target slave, it multiplies the obtained voltage data by 1000 to convert its unit kilovolts into the standard unit volts.
[0083] In addition, in addition to the difference in units, different devices may also send data with different zero offsets. For example, for temperature data, some devices have temperature data in Celsius, while others have temperature data in Fahrenheit. If Celsius is the standard unit, the unit of the received temperature data in Fahrenheit needs to be converted to Celsius. When converting Fahrenheit to Celsius, there is a zero offset, such as Celsius = (Fahrenheit-32)×5 / 9, where 32 is the zero offset.
[0084] In this way, data with different units sent by different slaves can be converted into a unified standard unit, and considering the possible difference in zero offset between different units, the calculation of zero offset is added in the conversion process. In this way, the unified conversion of physical quantity units can be achieved, which is convenient for comparison and analysis of data in the system.
[0085] Considering that some types of data may indicate abnormal situations if they are significantly different from historical data, anomaly detection can be set for such data. In this way, after processing the target data in the above way, the target data can be further detected for anomalies by the following steps: Detect whether the anomaly detection function is triggered. If the anomaly detection function is triggered, execute the anomaly detection function to compare the target data with the corresponding original data in the locally saved data table to obtain a comparison result; if the comparison result indicates that an anomaly exists, trigger an abnormal alarm information.
[0086] As can be seen from the above, the host obtains data from each slave at a certain frequency, and the acquired data is stored locally in the form of a data table. After the new target data is acquired, the original data corresponding to the target data in the data table is compared. If the difference between the newly acquired target data and the original data is too large, it indicates that there may be an abnormal situation, and an abnormal alarm information can be triggered at this time.
[0087] In this embodiment, all abnormal information can also be recorded in the log to facilitate subsequent analysis and troubleshooting.
[0088] After the data in the data table locally saved in the host is processed by the above-mentioned byte order conversion, unit uniform conversion, zero offset processing, etc., the standardization and uniformity of the data can be guaranteed. In addition, based on the setting of the data type field and the data transmission type field, it can support the processing of multiple data types and flexible data transmission types. Finally, the required data is provided to the logic processing unit through a unified interface, and the logic processing unit does not need to pay attention to the differences in the original data provided by each slave, so as to achieve the unification of function implementation.
[0089] In summary, the object-oriented communication implementation method provided in this embodiment introduces a data type field in the communication object, supports multiple data types such as double, float, uint64_t, int64_t, etc., and can automatically parse and process according to the data type returned by the device. In contrast, the existing technology usually only supports basic data types and cannot adapt to complex data requirements, limiting the compatibility and flexibility of the system.
[0090] By adding scaling factors to data entries, unified conversion of physical units is achieved, solving the problem of inconsistent physical units of equipment from different manufacturers. This makes data comparison and analysis more convenient. Existing technologies are not adequate in this regard, resulting in increased complexity in data processing and increased development and maintenance costs.
[0091] This solution supports data transmission types such as transparent transmission type and local calculation type, and can flexibly deal with the differences in device data provision, ensuring that the system is compatible with various devices. Even if the device does not directly provide certain data, it can obtain the required data through local calculation and other methods. In addition, unnecessary device communication is reduced, reducing communication overhead. Existing technologies usually lack this flexibility and require specific code to be written for each device, reducing the scalability of the system.
[0092] Object-oriented design improves the scalability of the system. By building communication objects, unified management of device communication configuration is achieved. The access of new devices only requires the creation of corresponding communication objects and the filling of necessary attribute information, without modifying the underlying communication code. In contrast, existing technologies require a lot of code modifications when adding new devices, and have poor scalability.
[0093] A unified data reading, byte order conversion, data type parsing, unit conversion and data storage process has been established, which simplifies the code structure, reduces duplicate code, and improves the readability and maintainability of the system. The existing technology lacks a unified processing mechanism, and the code is redundant and difficult to maintain.
[0094] A unified exception handling mechanism is designed to improve the stability and reliability of the system. Existing technologies have deficiencies in communication efficiency and error handling, which may lead to system performance degradation or data inconsistency.
[0095] The design of this application reduces the workload of writing specific codes for different devices and reduces development costs. Due to the modularity and uniformity of the code, maintenance and upgrades become more convenient, further reducing maintenance costs. In contrast, the existing technology has high development and maintenance costs due to complex and scattered codes.
[0096] This solution is compatible with multiple manufacturers and multiple models of equipment. Through configurable management and flexible data processing mechanisms, it can adapt to equipment of different manufacturers and models, reducing dependence on specific equipment and improving system compatibility. Existing technologies are insufficient in this regard, limiting the scope of application of the system.
[0097] The Modbus communication solution that supports multiple data types and unit standardization provided in this embodiment solves the problems of insufficient data type support and inconsistent units in the prior art by introducing data types and unit conversion parameters in the communication objects. The object-oriented design and flexible data transmission method are adopted to enhance the compatibility, flexibility and scalability of the system and reduce the development and maintenance costs. This communication method can be widely used in energy management systems, industrial automation control and other fields, and has significant technical advantages and practical application value.
[0098] Based on the same application idea, please refer to Figure 8 , the embodiment of the present application also provides a functional module schematic diagram of an object-oriented communication implementation device. This embodiment can divide the functional modules of the object-oriented communication implementation device according to the above method embodiment. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing module. The above integrated module can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiment of the present application is schematic, which is only a logical function division, and there may be other division methods in actual implementation.
[0099] For example, when each functional module is divided into corresponding functional modules, Figure 8The object-oriented communication implementation device shown is only a schematic diagram of the device. The object-oriented communication implementation device may include a data acquisition module, a data processing module and a data storage module. The functions of each functional module of the object-oriented communication implementation device are described in detail below.
[0100] A data acquisition module is used for traversing each data entry in the communication object of a target slave among the multiple slaves, and acquiring corresponding target data according to the traversed data entry; A data processing module, used for processing target data based on fields in data entries; The data storage module is used to update the corresponding original data in the locally stored data table according to the processed target data, wherein the locally stored data table provides the required data to the logic processing unit through a unified interface.
[0101] It can be understood that the above-mentioned data acquisition module, data processing module and data storage module can be used to execute the above-mentioned S11 to S14. The detailed implementation method of the data acquisition module, data processing module and data storage module can refer to the relevant content of the above-mentioned S11 to S14.
[0102] In a possible implementation, the data acquisition module is used to: A data read request is sent to a target slave based on the traversed data entries, and target data fed back by the target slave in response to the data read request is obtained.
[0103] In a possible implementation, the multiple fields include a register address field and a register quantity field; and the data acquisition module is used to: Obtain the register start address of the required data in the target slave according to the register address field in the traversed data entry, and obtain the number of consecutive registers required to read the required data according to the register quantity field; A data read request is generated based on the register start address and the required number of consecutive registers, the data read request is sent to the target slave, and the target data fed back by the target slave in response to the data read request is obtained.
[0104] In a possible implementation, the data acquisition module is used to: According to the traversed data entries, the target data is calculated based on the locally saved data and the preset formula.
[0105] In a possible implementation, the multiple fields include a calculation formula field; and the data acquisition module is used to: Determine the data required for calculation from the locally stored data according to the information in the calculation formula field in the traversed data entry; The target data is calculated based on the data required for calculation and the preset formula in the calculation formula field.
[0106] In a possible implementation, the multiple fields include a data type field and a byte order field, and the data type field supports multiple data type settings; the above-mentioned data processing module is used to: Convert the byte order of the target data based on the byte arrangement pattern in the byte order field in the data entry; Convert the data type of the target data after conversion processing to the data type in the data type field.
[0107] In a possible implementation, the multiple fields further include a scaling factor field and an offset field; and the data processing module is further configured to: Scale the target data according to the scaling factor in the scaling factor field in the data entry; The scaled target data is offset according to the offset in the offset field to obtain standardized target data.
[0108] In a possible implementation, the data processing module may also be used to: Detect whether an anomaly detection function is triggered. If the anomaly detection function is triggered, execute the anomaly detection function to compare the target data with the corresponding original data in the locally saved data table to obtain a comparison result; When the comparison result indicates that an abnormality exists, an abnormality alarm message is triggered.
[0109] In a possible implementation, the communication object also includes device identification information and communication parameters of the slave; The device identification information includes the communication address, device name and communication method of the slave; The communication parameters include the minimum communication cycle with the slave, the timeout of a single communication, and the number of retries after communication failure.
[0110] See also Fig. 9 , is a block diagram of an electronic device provided in an embodiment of the present application, the electronic device may be a computer device, etc., and the electronic device includes a memory, a processor, and a communication module. The memory, the processor, and the communication module are electrically connected to each other directly or indirectly to achieve data transmission or interaction. For example, these components can be electrically connected to each other via one or more communication buses or signal lines.
[0111] The memory is used to store computer programs or data. The memory can be, but is not limited to, random access memory (RAM), read only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.
[0112] The processor is used to read / write data or programs stored in the memory and execute the object-oriented communication implementation method provided in any embodiment of the present application.
[0113] The communication module is used to establish a communication connection between the electronic device and other communication terminals through the network, and is used to send and receive data through the network.
[0114] It should be understood that Fig. 9 The structure shown is only a schematic diagram of the structure of the electronic device. The electronic device may also include Fig. 9 More or fewer components as shown, or with Fig. 9 Different configurations are shown.
[0115] Furthermore, an embodiment of the present application also provides a computer-readable storage medium, which stores machine-executable instructions. When the machine-executable instructions are executed, the object-oriented communication implementation method provided in the above embodiment is implemented.
[0116] Specifically, the computer-readable storage medium can be a general storage medium, such as a mobile disk, a hard disk, etc. When the computer program on the computer-readable storage medium is executed, the above-mentioned object-oriented communication implementation method can be executed. Regarding the process involved when the computer-readable storage medium and its executable instructions are executed, reference can be made to the relevant description in the above-mentioned method embodiment, which will not be described in detail here.
[0117] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some communication interfaces, and the indirect coupling or communication connection of the devices or units can be electrical, mechanical or other forms.
[0118] In addition, the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
[0119] Furthermore, the functional modules in the various embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.
[0120] It should be noted that if the function is implemented in the form of a software function module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, and other media that can store program codes.
[0121] In this document, relational terms such as first and second, etc. are used merely to distinguish one entity or operation from another entity or operation, but do not necessarily require or imply any such actual relationship or order between these entities or operations.
[0122] The above description is only an embodiment of the present application and is not intended to limit the protection scope of the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.
Claims
1. A communication implementation method based on object-oriented, characterized in that: The method is applied to a host, the host is in communication connection with a plurality of slaves, the host stores communication objects created for each of the slaves in an object-oriented manner, each of the communication objects includes a plurality of data entries, each of the data entries includes a plurality of fields, and the method includes: For a target slave among the multiple slaves, traverse each data entry in the communication object of the target slave, and obtain corresponding target data according to the traversed data entry; Processing the target data based on the fields in the data entry; The corresponding original data in the locally stored data table is updated according to the processed target data, wherein the locally stored data table provides the required data to the logic processing unit through a unified interface.
2. The object-oriented communication implementation method according to claim 1, characterized in that: The step of acquiring corresponding target data according to the traversed data entries includes: A data read request is sent to the target slave based on the traversed data entries, and target data fed back by the target slave in response to the data read request is obtained.
3. The object-oriented communication implementation method according to claim 1 or 2, characterized in that: The plurality of fields include a register address field and a register quantity field; The step of acquiring corresponding target data according to the traversed data entries includes: Obtaining the register start address of the required data in the target slave according to the register address field in the traversed data entry, and obtaining the number of consecutive registers required to read the required data according to the register number field; A data read request is generated based on the register start address and the required number of consecutive registers, the data read request is sent to the target slave, and target data fed back by the target slave in response to the data read request is obtained.
4. The object-oriented communication implementation method according to claim 1, characterized in that: The step of acquiring corresponding target data according to the traversed data entries includes: According to the traversed data entries, the target data is calculated based on the locally saved data and the preset formula.
5. The object-oriented communication implementation method according to claim 1 or 4, characterized in that: The plurality of fields include a calculation formula field; The step of acquiring corresponding target data according to the traversed data entries includes: Determine the data required for calculation from the locally stored data according to the information in the calculation formula field described in the traversed data entry; The target data is calculated based on the data required for the calculation and the preset formula in the calculation formula field.
6. The object-oriented communication implementation method according to claim 1, characterized in that: The multiple fields include a data type field and a byte order field, and the data type field supports multiple data type settings; The step of processing the target data based on the fields in the data entry includes: Converting the byte order of the target data based on the byte arrangement pattern in the byte order field in the data entry; The data type of the target data after the conversion process is converted into the data type in the data type field.
7. The object-oriented communication implementation method according to claim 6, characterized in that: The plurality of fields also include a scaling factor field and an offset field; The step of processing the target data based on the fields in the data entry further includes: Scaling the target data according to the scaling factor in the scaling factor field in the data entry; The scaled target data is subjected to an offset process according to the offset in the offset field to obtain standardized target data.
8. The object-oriented communication implementation method according to claim 1, characterized in that: After the step of processing the target data based on the fields in the data entry, the method further includes: Detecting whether an abnormality detection function is triggered, and if the abnormality detection function is triggered, executing the abnormality detection function to compare the target data with the corresponding original data in the locally stored data table to obtain a comparison result; When the comparison result indicates that an abnormality exists, an abnormality alarm message is triggered.
9. The object-oriented communication implementation method according to claim 1, characterized in that: The communication object also includes device identification information and communication parameters of the slave; The device identification information includes the communication address, device name and communication mode of the slave; The communication parameters include a minimum communication cycle for communicating with the slave, a timeout period for a single communication, and a number of retries after a communication failure.
10. A communication implementation device based on object-oriented, characterized in that: The device is applied to a host, the host is connected to multiple slaves for communication, the host stores communication objects created for each of the slaves in an object-oriented manner, each of the communication objects includes multiple data entries, each of the data entries includes multiple fields, and the device includes: A data acquisition module, for traversing each data entry in the communication object of a target slave among the multiple slaves, and acquiring corresponding target data according to the traversed data entry; A data processing module, used for processing the target data based on the fields in the data entry; The data storage module is used to update the corresponding original data in the locally stored data table according to the processed target data, wherein the locally stored data table provides the required data to the logic processing unit through a unified interface.
11. An electronic device comprising a memory and a processor, wherein the memory stores a computer program that can be run on the processor, characterized in that: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 9 are implemented.
Citation Information
Patent Citations
Cross-platform byte order processing method, device and byte code running platform
CN101645017A
Method and device for communication between different processes
CN106354568A
A data processing and fusion method and application thereof
CN109711479A
ICD byte sequence automatic conversion method
CN112052010A
Data sending method, data receiving method and communication terminal
CN112463706A