Framework compatible with multi-manufacturer board cards and IO equipment and application thereof

Abstract

The invention discloses a framework compatible with multi-manufacturer board cards and IO equipment and application of the framework, and belongs to the technical field of data processing. The architecture comprises an abstract library and an application library, the abstraction library comprises an abstraction layer which is used for defining a unified motion control board card interface and an IO equipment interface; the application library is used for providing specific implementation examples for motion control board cards and IO equipment of different manufacturers and supporting motion control and IO operation through a unified API interface, and the application library inherits an interface defined by the abstraction layer; wherein the architecture dynamically loads a specific implementation instance of the application library according to hardware information during operation through a dynamic adaptation mechanism. According to the architecture compatible with the multi-manufacturer board card and the IO equipment and the application of the architecture, the hierarchical structure comprising the abstract library and the application library is constructed, and the unified interface and the dynamic adaptation mechanism are introduced, so that the targets of software and hardware decoupling, cross-manufacturer compatibility and interface standardization are achieved.

Description

Technical Field

[0001] The present invention belongs to the technical field of data processing, and particularly relates to an architecture compatible with multi-vendor boards and IO devices and its applications. Background Art

[0002] With the rapid development of industrial automation, robotics, and intelligent manufacturing, motion control technology has become a core component for achieving efficient and precise operation of equipment. Motion control boards, as key hardware in industrial automation systems, are widely used in fields such as robotics, numerical control machine tools, and automated production lines for precise axis control, motion trajectory planning, and IO operations. However, due to significant differences in the design and implementation of motion control boards and IO devices provided by different vendors in the market, developers face numerous challenges when developing applications compatible with multi-vendor hardware.

[0003] In the prior art, motion control boards from different vendors typically adopt their own unique hardware interfaces, communication protocols, and application programming interfaces (APIs). For example, some vendors may use proprietary bus protocols, while others may rely on pulse control or Ethernet protocols. This phenomenon of non-uniform interfaces requires developers to write specific driver codes and control logics for each vendor's board, increasing the development workload and precluding the realization of a general software solution.

[0004] Applications are usually tightly coupled with specific vendor's hardware, showing strong hardware dependence. Once the hardware model or vendor changes, existing codes are often difficult to directly transplant to other hardware platforms and require substantial modification or even rewriting. This high coupling not only limits the flexibility of the system but also increases the complexity of development and debugging, especially in scenarios where multi-vendor hardware needs to be supported.

[0005] In addition, due to the need to develop and maintain codes separately for each motion control board and IO device, the development efficiency is generally low. Developers must be familiar with the API and protocol specifications of different vendors, resulting in high learning costs and long development cycles. Meanwhile, with the update or addition of hardware, the cost of maintaining multiple sets of codes continues to rise, making it difficult to meet the rapidly iterative industrial demands.

[0006] Therefore, in view of the above technical problems, it is necessary to provide a new solution. Summary of the Invention

[0007] The purpose of the present invention is to provide an architecture compatible with multi-vendor boards and IO devices and its applications, which can support motion control boards and IO devices from multiple vendors and does not require modification of business codes for hardware switching.

[0008] To achieve the above purpose, the technical solution provided by the present invention is as follows: In a first aspect, the present invention provides an architecture that is compatible with multi-vendor boards and IO devices, which includes: an abstraction library and an application library; the abstraction library contains an abstraction layer for defining unified motion control board interfaces and IO device interfaces; the application library is used to provide specific implementation instances for motion control boards and IO devices of different vendors, and supports motion control and IO operations through a unified API interface, and the application library inherits the interfaces defined by the abstraction layer; wherein, the architecture dynamically loads specific implementation instances of the application library according to hardware information through a dynamic adaptation mechanism at runtime.

[0009] In one or more embodiments, the abstraction layer includes: interface classes for defining standardized methods for motion control boards and IO devices, and the standardized methods include initialization, axis control, IO control, and status query; abstract classes that inherit the interface classes and are used to provide default interface methods, and the abstract classes include a motion control abstract class and an IO control abstract class.

[0010] In one or more embodiments, the abstraction library further includes an adaptation layer that defines a factory interface for returning implementation class instances of specific vendors according to the abstract classes defined by the abstraction layer.

[0011] In one or more embodiments, the abstraction library further includes an attribute layer for defining unified property parameter interfaces for motion control boards and IO devices, and the property parameters include vendor name and model.

[0012] In one or more embodiments, the application library includes: implementation classes that inherit the abstract classes of the abstraction layer and implement the standardized methods defined by the interface classes according to specific vendors; attribute classes that inherit the property parameter interfaces of the attribute layer and store information about motion control boards or IO devices of specific vendors; factory classes for implementing the factory interface of the adaptation layer according to the dynamic adaptation mechanism to return instances of the implementation classes and attribute classes.

[0013] In one or more embodiments, the dynamic adaptation mechanism loads vendor information supported by the application library through reflection, and calls the factory class according to the vendor or model information specified by the user to return corresponding implementation class and attribute class instances.

[0014] In one or more embodiments, the abstraction library further includes a default adapter that defines a default class inheriting the abstract class and provides a default instance through a static attribute for providing basic function support when there is no preset hardware adaptation.

[0015] In a second aspect, the present invention provides a zero-code platform that includes the architecture described above.

[0016] In a third aspect, the present invention provides an electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the program, the functions of the architecture described above are implemented.

[0017] In a fourth aspect, the present invention provides a computer-readable medium carrying computer-executable instructions. When the computer-executable instructions are executed by a processor, they are used to implement the functions of the architecture described above.

[0018] Compared with the prior art, the architecture for compatible multi-vendor boards and IO devices provided by the present invention and its applications achieve the goals of software-hardware decoupling, cross-vendor compatibility, and interface standardization by constructing a hierarchical structure including an abstract library and an application library and introducing a unified interface and a dynamic adaptation mechanism. The abstract library in this architecture defines unified interfaces for motion control boards and IO devices, shielding the underlying differences. The application library provides specific implementations for devices of each vendor based on these interfaces. At runtime, according to the vendor or model information configured by the user, the corresponding application library can be dynamically loaded and the corresponding control object can be instantiated, ensuring that device replacement or expansion can be completed without modifying the business code. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings described below are only some embodiments recorded in the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0020] Figure 1 It is a schematic diagram of the architecture for compatible multi-vendor boards and IO devices in an embodiment of the present invention; Figure 2 It is a schematic diagram of the interface for initializing the motion control card operator in an embodiment of the present invention; Figure 3 It is a schematic diagram of the interface for initializing the IO object operator in an embodiment of the present invention; Figure 4 It is a schematic diagram of the electronic device in an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0021] To enable those skilled in the art to better understand the technical solutions in the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0022] In the fields of industrial automation and motion control, motion control boards and IO devices are the core components for achieving precise operation of equipment. However, in the prior art, there are significant differences in hardware interfaces, communication protocols, and API designs among boards and IO devices from different manufacturers. This difference requires developers to write specific code for each piece of hardware, resulting in a tight coupling between the application program and the hardware, making it difficult to port and incurring high development and maintenance costs.

[0023] In addition, the inconsistency in functions and performance among different hardware further exacerbates the compatibility issues, posing challenges to system integration and device interchange. Through in-depth analysis of the prior art, the inventors found the following core drawbacks: First, the lack of a unified interface standard leads to repetitive development work; second, hardware dependence restricts the flexibility of the system; finally, insufficient compatibility reduces the reliability and generality of the system. These drawbacks stem from the failure of the prior art to effectively abstract hardware differences in design and the lack of a general and dynamically adaptable software architecture.

[0024] Based on the above analysis, the present invention proposes a brand-new technical implementation idea aimed at solving the multi-vendor hardware compatibility problem through software architecture design. Its core idea is to separate the hardware control logic from the business logic and achieve unified management and seamless switching of cross-vendor hardware through a highly abstract and dynamically adaptable mechanism. Specifically, the implementation path of the present invention includes: establishing an abstract interface layer for defining general control instructions and operation specifications to shield the underlying hardware differences; designing an implementation layer to provide specific control logics for different manufacturers but maintaining consistency by inheriting the general interface; introducing a runtime dynamic adaptation mechanism to automatically select the appropriate implementation logic according to the hardware characteristics, thereby eliminating the dependence on specific hardware. This idea ensures that developers only need to program based on a unified interface, and hardware replacement does not require modifying the core code, while also guaranteeing the behavioral consistency of the system on different hardware through layered decoupling and dynamic configuration.

[0025] Please refer to Figure 1As shown in the figure, it is a schematic diagram of the architecture for compatible multi-vendor board cards and IO devices in an embodiment of the present invention. The architecture for compatible multi-vendor board cards and IO devices includes an abstraction library and an application library; the abstraction library contains an abstraction layer for defining unified motion control board card interfaces and IO device interfaces; the application library is used to provide specific implementation instances for motion control board cards and IO devices of different vendors, and supports motion control and IO operations through a unified API interface, and the application library inherits the interfaces defined by the abstraction layer. Among them, the architecture dynamically loads specific implementation instances of the application library according to hardware information at runtime through a dynamic adaptation mechanism.

[0026] As the core component of the architecture of the present invention, the abstraction library defines unified interfaces for multi-vendor motion control board cards and IO devices through the abstraction layer it contains, aiming to shield hardware differences and provide a standardized operation entry. The essence of the abstraction library is a general logical framework. Through its highly abstract design, it extracts the commonalities of hardware control into a standardized set of interfaces, thus providing a consistent programming experience for upper-layer applications.

[0027] The implementation of the abstraction library mainly relies on the abstraction layer, and its core is to build a unified control specification through interface classes and abstract classes. In a possible implementation manner, the abstraction layer first defines interface classes. For example, it designs an interface for the motion control board card, including method signatures such as initializing the device, performing axis motion (such as point-to-point motion or interpolation), and querying the status; it designs another interface for the IO device, covering method signatures such as initializing the IO, reading and writing digital quantities, and querying the IO status. These interface classes only specify method signatures and do not contain specific implementations, ensuring hardware independence.

[0028] Furthermore, the abstraction layer introduces abstract classes that inherit the above interface classes and provide partial default implementations. For example, the abstract class for motion control may contain a general initialization process (such as checking the device connection status) or status query logic (such as returning whether the device is ready), while the abstract class for IO control may provide a basic read / write operation template. These default implementations not only provide a basis for the adaptation of specific hardware but also allow vendor-specific implementations to be extended through the polymorphism mechanism. In addition, the abstraction library can support the dynamic extension of interfaces through a configuration mechanism, for example, allowing users to add new control methods at runtime to meet special hardware requirements.

[0029] The design purpose of the abstraction library is to decouple the control logic from the device implementation and form a unified device capability modeling standard. The abstraction library ensures the consistency of interfaces and the unity of the platform, avoiding the introduction of messy interface structures by devices of different vendors; through the default implementations provided by abstract classes, it reduces the development threshold and improves the implementation efficiency; at the system deployment level, the abstraction library provides a unified interface dependency, enabling upper-layer business logic to require no changes when facing hardware switching, thus achieving software-hardware decoupling and flexible adaptation at runtime.

[0030] In an exemplary embodiment, the abstraction library further includes an adaptation layer that defines a factory interface for returning an instance of an implementation class of a specific manufacturer according to the abstract class defined by the abstract layer.

[0031] The adaptation layer undertakes the tasks of dynamic mapping and object generation between the abstract interface and the specific implementation. Its core goal is to delay the binding of the interface and the implementation class until runtime, and to implement a configuration-oriented and dynamically generated hardware adaptation mechanism by introducing the factory interface, thereby further enhancing the flexibility, scalability, and decoupling ability of the system.

[0032] A set of interfaces or abstract mechanisms introduced in the abstraction library, with the factory interface as the core, define a standard method or entry for returning an instance of the corresponding implementation class according to device identification information (such as manufacturer name, model identification, etc.). In this layer, no specific manufacturer's implementation logic is involved, but a general object construction protocol is built as an intermediary bridge for system runtime adaptation.

[0033] For example, define a factory interface for a motion control board, which contains a method for returning an instance of the corresponding implementation class according to hardware information (such as manufacturer name and model); similarly, define another factory interface for IO devices, responsible for returning IO-related implementation class instances. These interfaces do not directly implement the logic, but stipulate the contract for creating instances. The implementation classes of the factory interface are provided by the application library, and each implementation class corresponds to a specific manufacturer's hardware.

[0034] For a certain manufacturer's motion control board, the factory implementation class may instantiate a subclass that inherits the abstract class according to the input model parameters, containing the specific control logic of the board. The factory interface can also support configuration-driven, for example, obtaining hardware information through a configuration file or runtime detection, and dynamically selecting the appropriate implementation class. In addition, the adaptation layer can integrate reflection technology to scan the set of implementation classes in the application library, and automatically match and create instances according to the hardware attributes. This design ensures the generality and scalability of the adaptation layer, and at the same time maintains the code standardization through interface constraints.

[0035] In the actual implementation, the adaptation layer usually includes two core interfaces: one is oriented to the motion control board card, such as IGMotionBoardCardCreator; the other is oriented to the IO control device, such as IGIOCardCreator. These two interfaces respectively define methods for creating instances of subclasses of the corresponding abstract classes, such as CreateMotionBoard() or CreateIOCard(), and their parameters can be device identification strings, device property class instances, configuration file paths, etc. When the system runs, to create a control card object of a certain manufacturer, only need to call these factory interface methods and pass in relevant identifications, then the corresponding implementation class object can be automatically returned without explicitly referring to the specific class name.

[0036] To achieve this goal, there is usually a factory class corresponding to the above factory interface in each application library module. These classes will be bound to the system through registration or scanning mechanisms at runtime, and when the user selects a device of a certain manufacturer, the creation method will be automatically called by the adaptation layer interface, thus returning instances of the implementation class and the property class. The whole process is different from traditional static programming and has significant runtime dynamic characteristics.

[0037] The role of the adaptation layer is to provide dynamic instantiation support for multi-vendor hardware while maintaining the decoupling and consistency of the system. The factory interface separates the creation process of the implementation class instance from the upper-layer application. Developers do not need to directly reference the implementation classes of specific manufacturers, but only need to obtain instances through the factory interface. This decoupled design reduces the coupling degree of the code and improves the flexibility of the system. The adaptation layer ensures that all implementation classes of manufacturers follow the contract defined by the abstract layer through standardized interface constraints, thus guaranteeing the consistency of function calls. For example, regardless of the protocol of the board card, the instance returned by the factory interface can respond to the same motion control instructions.

[0038] In an exemplary embodiment, the abstract library further includes a property layer, and the property layer is used to define a unified interface for property parameters of the motion control board card and the IO device, and the property parameters include the manufacturer name and model.

[0039] The property layer of the abstract library provides data support for the compatibility of multi-vendor hardware by defining a unified interface for property parameters of the motion control board card and the IO device. The core function of the property layer is to standardize the description information of the hardware, such as the manufacturer name and model, to ensure that the system can identify and manage the characteristics of different devices in a consistent format. This design transforms the differences of the hardware into a structured parameter set, laying a foundation for dynamic adaptation and system integration.

[0040] The implementation of the property layer mainly focuses on the design and application of the property parameter interface, aiming to provide a unified access method for hardware information. In possible implementation manners, the property layer defines one or a set of "property parameter interfaces", which do not involve control logic and only focus on the static property data related to the device itself. For example, for a motion control board, its typical properties include but are not limited to: manufacturer name, device model, number of supported axes, whether it is pulse type or bus type, supported communication protocols (such as EtherCAT or CANopen), resources required for initialization, device characteristic tags (such as whether it supports synchronous interpolation, acceleration and deceleration control, etc.). For an IO device, its properties may include the number of input and output points, whether it supports analog signals, communication method, response time, power supply specification, etc. These parameters constitute an abstract description of the device's function and structure and are important bases for the system to perform automatic identification and adaptation.

[0041] In actual implementation manners, the property layer can be constructed by means of interface programming. For example, in the abstract library, two interfaces, IMotionBoardCardInfo and IIOCardInfo, are defined to describe the property information of the motion control card and the IO device respectively. These interfaces can define a series of standard property fields (in the form of read-only properties) to form a unified description template. In each specific application library, these interfaces are then implemented for devices of different manufacturers, and specific data contents are filled in. For example, in the implementation class GogaoCardInfo of the "Gogao" card, VendorName is "Gogao", Model is "GTS-400", AxisCount is 4, and IsBusBased is false, indicating that this card is a 4-axis pulse type control card.

[0042] The property layer can provide accurate information support for the dynamic adaptation mechanism. Before the system loads the adaptation class during operation, it often needs to locate the target device based on user configuration or system query results. At this time, comparison and matching can be uniformly performed through the standard fields defined by the property layer. In addition, the property information can also be used for front-end graphical interface display. For example, the device selection interface in the zero-code platform can automatically list all supported manufacturers and models for the user to choose by reading the property classes of all registered devices, avoiding manual hard-coding configuration.

[0043] In an exemplary embodiment, the abstract library further includes a default adapter, which defines a default class that inherits the abstract class and provides a default instance through static properties for providing basic function support when there is no preset hardware adaptation.

[0044] The main function of the default adapter is to provide a set of basic functional logics even when the preset specific hardware adaptation implementations cannot be recognized or configured during runtime. Through predefined general implementations, it fills the gaps in hardware adaptation to ensure that the basic operation process of the system is not interrupted, or it is used in special scenarios such as debugging, simulation, and testing. The design of the default adapter provides a fallback mechanism for the system by defining a default class that inherits from an abstract class and providing a globally accessible default instance in the form of a static attribute, making the entire control system more fault-tolerant and functionally sustainable.

[0045] The default class inherits the abstract class defined in the abstract layer and implements all necessary interface methods. For example, for a motion control board, the default class may implement basic initialization methods (such as returning a success status without performing actual hardware operations), point-to-point motion methods (such as simulating a motion completion signal), and status query methods (such as returning default status values); for an IO device, the default class may implement basic read and write operations (such as returning fixed values or empty responses). The default class exposes a single instance through a static attribute and uses the singleton pattern to ensure global uniqueness. The application can directly access this instance through a static call without the need for an instantiation process. To enhance flexibility, the default adapter supports configuration options that allow users to specify certain default behaviors, such as setting the speed range of simulated motion or the default return values of IO read and write operations.

[0046] The application library is a bridge module in the architecture of the present invention that connects the abstract interface and the actual hardware control. Its core function is to provide specific implementation instances that conform to the interface definitions of the abstract layer for motion control boards and IO devices from different manufacturers, and to convert the unified control logic into execution instructions for various types of devices. The application library is constrained by the interfaces or abstract classes defined in the abstract library and constructs an implementation system closely related to functions such as communicating with manufacturer hardware, instruction parsing, and protocol adaptation, ensuring that the system can adapt to a variety of different types of hardware resources under a unified API framework.

[0047] The application library provides customized implementation instances for hardware from different manufacturers by inheriting the abstract layer interfaces and supports motion control and IO operations through a unified API interface. Its core goal is to encapsulate hardware-specific control logic while maintaining consistency with the abstract layer interfaces, thereby achieving flexible adaptation and efficient development of cross-manufacturer hardware.

[0048] In an exemplary embodiment, the application library includes: an implementation class, an attribute class, and a factory class; the implementation class inherits the abstract class of the abstract layer and implements the standardized methods defined in the interface class according to the specific manufacturer; the attribute class inherits the attribute parameter interface of the attribute layer and stores information about the motion control board or IO device of the specific manufacturer; the factory class is used to implement the factory interface of the adaptation layer according to the dynamic adaptation mechanism to return instances of the implementation class and the attribute class.

[0049] The implementation classes are the functional core of the application library. For each manufacturer's motion control board or IO device, independent subclasses are developed, inheriting the abstract classes defined in the abstract layer, and specifically implementing standardized control methods. For example, for a motion control board, the implementation class may contain initialization logic, point-to-point motion, multi-axis interpolation, or status query code for a certain manufacturer's protocol (such as Ethernet or pulse); for an IO device, the implementation class may implement read and write operations for digital input and output, adapting to the response speed or port configuration of the hardware. These implementation classes ensure that the functions conform to the unified interface specifications by overriding the methods of the abstract class. Taking the motion control board as an example, standardized methods such as Open(), HomeMove(), and MoveP2P() are defined in the abstract library, and the implementation class needs to fill these methods based on the specific manufacturer's SDK or communication protocol.

[0050] The property classes inherit the parameter interfaces of the property layer and store specific information of the hardware, such as the model of the board, the number of supported axes, the protocol version, or the number of ports and communication rate of the IO device, for implementing the function of describing the static information of the device. The property classes provide data access through standardized getter and setter methods, supporting querying or modification at runtime.

[0051] The factory class is responsible for dynamically creating instances of the implementation classes and property classes, implementing the factory interface of the adaptation layer. For example, the factory class may instantiate the corresponding implementation classes and property classes according to the input hardware model and return them to the upper-layer application. The factory class can also dynamically load the list of supported hardware through reflection technology or configuration files, improving the automation degree of the creation process. This modular design ensures the independence and extensibility of the application library while maintaining consistency with the interfaces of the abstract layer. At runtime, the system calls the methods of the factory class to return the corresponding implementation objects and property objects according to the manufacturer information passed in the configuration.

[0052] Specifically, the dynamic adaptation mechanism loads the manufacturer information supported by the application library through reflection, and calls the factory class according to the manufacturer or model information specified by the user to return the corresponding implementation class and property class instances.

[0053] The dynamic adaptation mechanism relies on the Reflection mechanism. Reflection is a mechanism for inspecting and operating on type information at runtime, which can dynamically obtain information such as types, methods, and properties in an assembly during program execution and instantiate objects. In the scenario of the present invention, the implementation classes, property classes, and factory classes of control cards from all manufacturers are compiled into separate application library assemblies (such as DLL files). The system does not directly reference these assemblies during the initialization phase, but loads libraries that conform to the naming rules in the specified directory or configuration path through reflection. For example, if the user selects the "Gogao" manufacturer, the system will search for the assembly named "Gogao.Motion.dll" and use reflection to load the GogaoCardFactory factory class defined therein.

[0054] After successful reflection loading, based on a predefined factory interface (such as IGMotionBoardCardCreator), find the implementation class and instantiate the factory object, and then call methods (such as CreateMotionBoard() or CreateCardInfo()) in the factory object to generate corresponding instances of the control card implementation class (such as GogaoCardImpl) and property class (such as GogaoCardInfo). These instances will be injected into the upper-layer control module in the form of a unified interface, enabling the entire system to avoid hard-coding adaptation logic separately for each manufacturer, thus achieving on-demand loading and runtime adaptation.

[0055] To ensure that the system can correctly identify and bind to the target device during the dynamic adaptation process, a device identification information can be maintained in each factory class or application library, including the supported manufacturer name, device model, fully qualified name of the implementation class, etc. The system determines the final loaded object by matching the manufacturer or model information selected by the user with these identification items.

[0056] In summary, the architecture for compatible multi-vendor boards and IO devices provided by the present invention realizes the goals of software-hardware decoupling, cross-vendor compatibility, and interface standardization by constructing a hierarchical structure including an abstract library and an application library and introducing a unified interface and a dynamic adaptation mechanism; the abstract library in this architecture defines unified interfaces for motion control boards and IO devices, shielding the underlying differences, and the application library provides specific implementations for devices of each manufacturer based on these interfaces; at runtime, according to the manufacturer or model information configured by the user, the corresponding application library can be dynamically loaded and the corresponding control object can be instantiated to ensure that device replacement or expansion can be completed without modifying the business code.

[0057] The present invention also provides a zero-code platform, which includes the architecture described above. The platform takes the unified interface and dynamic adaptation mechanism as the technical core, defines standard control behaviors through the abstraction library, encapsulates various vendor implementations through the application library, describes device meta-information through the attribute layer, and realizes the dynamic loading and binding of device instances by using the factory class and reflection mechanism. Please refer to Figure 2 and Figure 3 As shown, the user only needs to drag and drop operator components such as "initialize motion control card" and "initialize IO object" in the platform, select the target vendor and model, and the system will automatically load the corresponding implementation class and attribute class through the reflection mechanism to complete device docking and control function injection.

[0058] Please refer to Figure 4 As shown, an embodiment of the present invention also provides an electronic device 400, which includes at least one processor 401, a memory 402 (such as a non-volatile memory), a memory 403, and a communication interface 404, and at least one processor 401, the memory 402, the memory 403, and the communication interface 404 are connected together via an internal bus 405. At least one processor 401 is configured to call at least one program instruction (architecture code) stored or encoded in the memory 402, so that at least one processor 401 executes various functions of the architecture described in the various embodiments of this specification.

[0059] In the embodiments of this specification, the electronic device 400 may include, but is not limited to: personal computers, server computers, workstations, desktop computers, laptop computers, notebook computers, mobile electronic devices, smart phones, tablet computers, cellular phones, personal digital assistants (PDAs), handheld devices, messaging devices, wearable electronic devices, consumer electronic devices, and the like.

[0060] An embodiment of the present invention also provides a computer-readable medium, on which computer-executable instructions are carried. When the computer-executable instructions are executed by a processor, they can be used to implement various functions of the architecture described in the various embodiments of this specification.

[0061] The computer-readable medium in the present invention can be a computer-readable signal medium, a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples of the computer-readable storage medium can include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present invention, the computer-readable storage medium can be any tangible medium that contains or stores a program, which can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0062] In the present invention, a computer-readable signal medium can include a data signal propagated in a baseband or as part of a carrier wave, which carries computer-readable program code. Such a propagated data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any appropriate medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination of the above.

[0063] Those skilled in the art should understand that the embodiments of the present invention can be provided as a method, a system, or a computer program product. Therefore, the present invention can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk memory, CD-ROM, optical memory, etc.) that contain computer-usable program code.

[0064] The present invention is described with reference to the flowcharts and / or block diagrams of methods, apparatuses, systems, and computer program products according to the embodiments of the present invention. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, as well as the combination of flows and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing devices generate for implementing the processFigure 1 one process or multiple processes and / or blocks Figure 1 a device for the functions specified in one block or multiple blocks.

[0065] It is obvious to those skilled in the art that the present invention is not limited to the details of the above-described exemplary embodiments, and the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention. Therefore, in any sense, the embodiments should be regarded as exemplary and non-limiting. The scope of the present invention is defined by the appended claims rather than the above description. Therefore, all changes falling within the meaning and scope of the equivalent elements of the claims are intended to be embraced within the present invention. Any reference signs in the claims should not be construed as limiting the claims involved.

[0066] In addition, it should be understood that although this specification is described in terms of embodiments, not every embodiment only contains an independent technical solution. This narrative manner of the specification is only for clarity. Those skilled in the art should regard the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. An architecture compatible with boards and IO devices from multiple vendors, characterized in that: include: Abstract library, including abstract layer, used to define unified motion control board interface and IO device interface; An application library is used to provide specific implementation examples for motion control boards and IO devices from different manufacturers, and to support motion control and IO operations through a unified API interface. The application library inherits the interface defined by the abstract layer; The architecture dynamically loads the specific implementation instance of the application library according to the hardware information at runtime through a dynamic adaptation mechanism.

2. The architecture compatible with boards and IO devices from multiple vendors according to claim 1, characterized in that: The abstraction layer includes: Interface class, used to define standardized methods for motion control boards and IO devices, including initialization, axis control, IO control and status query; An abstract class inherits the interface class and is used to provide a default interface method. The abstract class includes a motion control abstract class and an IO control abstract class.

3. The architecture compatible with boards and IO devices from multiple vendors according to claim 2, characterized in that: The abstract library also includes an adaptation layer, which defines a factory interface for returning an implementation class instance of a specific manufacturer according to the abstract class defined by the abstract layer.

4. The architecture compatible with boards and IO devices from multiple vendors according to claim 3, characterized in that: The abstract library also includes an attribute layer, which is used to define a unified motion control board and IO device attribute parameter interface, and the attribute parameters include manufacturer name and model.

5. The architecture compatible with boards and IO devices from multiple vendors according to claim 4, characterized in that: The application library includes: An implementation class, which inherits the abstract class of the abstract layer and implements the standardized method defined by the interface class according to the specific manufacturer; Attribute class, inheriting the attribute parameter interface of the attribute layer, storing the motion control board or IO device information of a specific manufacturer; The factory class is used to implement the factory interface of the adaptation layer according to the dynamic adaptation mechanism to return instances of the implementation class and the attribute class.

6. The architecture compatible with boards and IO devices from multiple vendors according to claim 5, characterized in that: The dynamic adaptation mechanism loads the vendor information supported by the application library through reflection, and calls the factory class according to the vendor or model information specified by the user to return the corresponding implementation class and attribute class instances.

7. The architecture compatible with boards and IO devices from multiple vendors according to claim 2, characterized in that: The abstract library also includes a default adapter, which defines a default class that inherits the abstract class and provides a default instance through static properties to provide basic function support when there is no preset hardware adaptation.

8. A zero-code platform, characterized in that: Comprising the architecture as described in any one of claims 1 to 7.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the function of the architecture according to any one of claims 1 to 7 is realized.

10. A computer-readable medium, characterized in that The computer-readable medium carries computer-executable instructions, and when the computer-executable instructions are executed by a processor, they are used to implement the functions of the architecture according to any one of claims 1 to 7.

Images