Systems, methods, and computer program products for programming actuator controllers

Abstract

A method for programming a drive of an actuator, the method including: (a) obtaining a modular code repository (MCR) from a nontangible memory module, the MCR including control instructions for controlling operation of different types of electric actuators, comprising at least: activation, stopping of operation, and / or activation level modification; (b) based on the MCR, generating an adapted modular code including at least: an executable control instruction of the MCR, suitable for the type of actuator; a parametric component for adapting the executable control instruction to the at least one actuator; and (c) providing the adapted modular code to the actuator controller which controls an operational actuator of the selected actuator type, for executing parts of the adapted modular code at least in order to: activate; modify activation level; and / or stop operation of the operational actuator.

Description

SYSTEMS, METHODS, AND COMPUTER PROGRAM PRODUCTS FOR PROGRAMMING ACTUATOR CONTROLLERSRELATED APPLICATIONS

[0001] This application claims priority from Israeli patent application serial number 314,737 filing date August 4, 2024.FIELD

[0002] This application relates to systems, methods, and computer program products for programming actuation unit controllers. Specifically, the application relates to systems, methods, and computer program products for programming actuation controllers of actuation units such as electric motors, sensors, valves, computer numerical control (CNC) machines, electric vehicle actuation units e.g., automated guided vehicles (AGVs) and autonomous mobile robots (AMRs), drive motors, steering actuators, braking systems, lifting mechanisms, and so on.BACKGROUND

[0003] The development of software to control actuators (e.g., electric motors) is a critical component in various industries, including robotics (e.g., AGVs and AMRs), automotive, manufacturing, and so on. However, the methods widely used in the field for creating such software are fraught with challenges. The traditional development process is lengthy due to the need for detailed coding, extensive debugging, and iterative testing to ensure the software meets stringent performance and safety standards. This results in substantial financial costs, as the development often requires highly specialized skills and sophisticated tools, which drive up expenses. The inefficiency of this traditional approach not only delays time-to-market but also places a significant economic burden on companies. The inability to thoroughly test control software before deployment to actual vehicles results in substantial development time, increased costs, and potential safety risks. There is a clear need for a more efficient, cost-effective solution to develop control software for actuators, which can mitigate these issues and streamline the entire process. In light of the cited prior art, thereremains a need for novel systems, methods, and computer program products implementing novel programming techniques for actuator controllers.GENERAL DESCRIPTION

[0004] The operation of many types of equipment such as robotic arms, computer numerical control (CNC) machines, motorized conveyors, automated manufacturing systems, and similar components in many industrial and non-industrial settings (e.g., healthcare, entertainment) is controlled by actuator controllers (e.g., “drives”, “drive systems”, “drive units”, “inverters”). In such complex systems, actuator controllers are specific components — incorporating a combination of hardware, software, and / or firmware — that interact with underlying hardware and intermediate units like servo drives. Actuator controllers — like servo drives, CNC drives, valve drives, and so on — are used in conjunction with motors, servos, and equivalent components. Such motors, servos, etc., receive commands from the actuator controllers and convert them into precise control signals to manage the operation of components such as servos, valves, motors, and sensors in CNC machines and other equipment. The drive code, executed by a processor, translates high-level instructions into tangible actions carried out by the hardware, facilitating communication between the operating system and various hardware devices. This interplay between drives, servo drives, and other components translates complex computations into precise mechanical actions, serving as a vital interface in industrial applications.

[0005] The development and modification of actuator controllers (e.g., drives, drive systems, inverters) are continual processes, necessitated by evolving hardware specifications, advancements in technology, changing regulatory standards, and emerging user needs. Updates to actuator controllers are frequently required to ensure compatibility with new hardware versions, to incorporate additional features, to improve performance and efficiency, or to rectify security or functionality issues. In industrial settings, the constant innovation in machinery and automation technologies often demands specialized actuator controllers tailored to unique specifications and performance criteria.

[0006] The complexity of actuator controllers varies widely based on factors such as the hardware they are intended to control, the operating system they must interact with,and the specific functions they must perform. Design, development, and maintenance of complex actuator controllers are sophisticated tasks requiring careful planning, in- depth knowledge, and robust testing. In the context of industrial components such as servos or valves, these tasks become even more challenging due to the high precision and reliability requirements.

[0007] In systems which include motors or actuators (or other equivalent apparatuses which cause mechanical movement in response to electric inputs; equivalents are also referred to implicitly whenever motors are discussed below), each motor can be controlled by an associated actuator controller. Such actuator controller includes a nontangible memory module which stores computer code which, when executed by a suitable circuitry of the respective actuator controller (e.g., one or more processors), send control signals to the associated motor, for controlling operation of the motor. In some configurations, one or more controllers (whether part of the same system or external thereto) issue commands to each of the different actuator controllers. Such commands may include, for example, a desired location of the robotic arm, a desired position or extension of the servo motor, and so on. It is noted that some actuator controllers may be used to control different types of motors or other controllable technical equipment such as valves, sensors, computer numerical control (CNC) machines, pumps, and so on. One example of such other types of controllable technical equipment includes drilling heads.

[0008] The development of software for actuator controllers (e.g., “drives”), such as actuator controller for servos or equivalent industrial components like valves, represents a critical yet notably cumbersome process in modem industrial automation. Traditionally marked by a protracted timeline and an array of intricate stages, the standard method of creation and implementation is fraught with complexities. Easily spanning over a year in some cases, the process necessitates meticulous planning, exhaustive customization, rigorous alignment with specific hardware, and an extensive testing regime. While these steps may be implemented to yield precise control and reliable performance, they inevitably render the procedure long-winded, resourceconsuming, and challenging to manage.

[0009] An example of a timeline for developing software for such an actuator controller using conventional actuator controller code development process isdiscussed below with respect to Fig. 2A. In short, such a timeline may include, for example: a) 6-12 months of programing features for the actuator controller (e.g., motor control, sensor data acquisition, communication, error handling, user interface, safety protocols, energetic efficiency, task management, real-time monitoring and reporting, and so on). b) About 1 more month of adding product specific features (e.g., identifying and integrating specific features for the targeted products, conducting focused tests on product-specific features). c) About 2 more months of adjusting the code to specific hardware (e.g., tailoring and adapting the code to the unique characteristics of a specific servo drive selected for the project). d) About 2 more months of testing the new actuator controller software with the specific hardware used, e.g., testing the performance of the specific hardware in the intended environment for real-world scenarios, using the developed software.

[0010] All in all, such a development process may routinely extend over a year to a year and a half. By comparison, the development of the hardware part of the system (e.g., specific servos, motors, or other electromechanical components) may only take 3 to 6 months. That is, in such an example development process, the overall delivery of such a development process is significantly extended by the software development, while the partly parallel process of hardware development may conclude months before that.

[0011] The systems, methods, and computer program products discussed below may be used to significantly reduce the development time of new or updated actuator controllers, while maintaining high code quality and versatility of the developed actuator controller. Such systems, methods, and computer program products utilize a novel modular code repository which include control instructions for controlling operation of different types of electric actuators (or other types of actuation units, e.g., as discussed below) by one or more types of actuator controllers. In the following description, the term “drive” is occasionally used, and it may pertain to anycombination of one or more of the software, firmware, or hardware of a drive system or any other actuator controller.

[0012] For example, a method for programming an actuator controller is disclosed, that includes the following steps: a) Obtaining a modular code repository stored on a nontangible memory module, the modular code repository including control instructions for controlling operation of different types of actuators by one or more types of drives. The term “modular code repository” within the context of the present disclosure pertains to a repository of modular code, which is a code that is structured in a modular way and which can be adapted for controlling different types of actuators by suitable drives. The adaptation of the modular code may take into account various considerations and requirements, such as the intended type of actuator, the intended use of the specific actuator, the tasks required from the specific actuator, the environment in which the specific actuator is intended to operate, and so forth. The adapting of the modular code may include, giving few nonlimiting examples, selecting specific models of the modular code to implement, providing parameter values according to which one or more code modules are executed, hooking into one or more of the modules using new coded instructions, and so on. Control instructions included in the modular code include instructions for causing the controlled actuator to perform one or more actions. For example, the control instructions included in the modular code repository may include control instructions for activation of the respective actuator, for stopping operation of the respective actuator, and / or for modification of an activation level of the respective actuator (e.g., modifying the motor speed, modifying the motor torque). For example, the different types of actuators may include different types according to any one or more of the following distinctions: different actuator families (e.g., electric motors, valves, pump, pneumatic actuator, hydraulic actuator), different types of actuators within a single such family (e.g., stepper motor, servo motor, switched reluctance motor), actuators by different manufacturers, different models of the same modelfamily (e.g., electric motors differing by power rating, voltage, current, speed, torque, size, dimensions, weight, control interface, and so on). b) Generating an adapted modular code — based on the modular code repository — for controlling at least one actuator of a selected type of actuator out of the different types of actuators. For example, the generating may include generating an adapted modular code that controls a specific type of stepper motor which is a part of a specific robotic arm which has a specific function in the assembly line of a specific manufacturing facility. Clearly, the same adapted code may be used for control of many actuators (e.g., many motors) of the same type (e.g., motors of a mass-produced product, or different motors having similar function in a larger machine). The adapted modular code generating in this step includes at least:1. At least one executable control instruction of the modular code repository, suitable for the type of actuator (e.g., suitable for the respective motor for which the modular code was adapted). Optionally, the at least one executable control instruction may be taken verbatim from the modular code repository. Optionally, the at least one executable control instruction may be somewhat adapted in the process of adaptation (e.g., parts of the instructions which are not required for the specific implementation may be omitted). The actual number of executable control instructions of the modular code repository may be much larger; for example, this number may be measured in thousands, tens of thousands, or even more lines of code.2. A parametric component which includes information for adapting the executable control instruction to the at least one actuator. For example, such a parametric component may pertain to any one or more of the following types of parameters: power-related parameters (e.g., pertaining to voltage, current, etc.), temporal parameters (e.g., duration, event timings, etc.), kinetic parameters (e.g., pertaining to speed, acceleration, deceleration, etc.),feedback parameters (such as position feedback, speed feedback, and current feedback, providing information about the system's current state), performance parameters (e.g., torque, representing the output capabilities of the motor), control parameters (e.g., Proportional-Integral-Derivative (PID) gains for adjusting the control response, fault detection thresholds for identifying abnormal conditions), and other relevant factors pertinent to the specific application. It is noted that such a parameter may list specific values, permitted ranges of values, and any other type of parameters which may be required for the adaptation of the code. The parametric component may be determined based on various considerations such as (but not limited to): type of actuator, specific parameters of intended actuator, intended tasks, interoperability with other system components, user preferences, user customization, and so on.Additionally, the modular code repository includes at least one other control instruction that is unexecutable by executing the adapted modular code. That is, at least one control instruction of the modular code repository which may be adapted into an executable instruction for controlling an actuator (e.g., of a different type) is nonetheless excluded from the group of executable instructions of the adapted modular code. Such a control instruction may either be excluded from the adapted modular code altogether (e.g., not copied or deleted), parametrically set for inexecution (e.g., setting an execution flag value to zero), not provided with parameter values required for execution, or rendered unexecutable in any other suitable fashion. For example, such one or more control instructions of the modular code repository may pertain to another type of actuator (e.g., to a stepper motor and not to the type of the specific actuator which is, for example, a servo motor), may pertain to an action not required in the specific intended implementation (for example, advanced speed feedback may be required for some CNC implementation, but not for controlling operation of a cooling fan), and so on. The actual number of control instructions of the modular coderepository that are unexecutable in the adapted modular code may range from one or a few instructions; for example, this number may be measured in thousands, tens of thousands, or even more lines of code. c) performing offline simulation of the adapted modular code e.g., to simulate at least one of behaviors of the different types of electric actuators when controlled by an actuator controller (e.g., the electronic components of the different types of electric actuators, electronic components of the drive, transmission gears, and / or electric cables connecting between the drive and the different types of electric actuators) , load simulation, and / or I / O simulation. d) Providing the adapted modular code (e.g., upon successful offline simulation thereof) to the drive which controls an operational actuator of the selected actuator type, for executing parts of the adapted modular code for operating the respective operational actuator (e.g., a specific electric motor). For example, the adapted modular code may be provided to the respective drive at least in order to execute any combination of one or more of the following: activate the operational actuator, modify activation level of the operational actuator; and stop operation of the operational actuator.

[0013] The modular code repository may include control instructions for controlling operation of different types of electric vehicle actuators by one or more types of drives. The modular code repository may include control modules for AGV and / or AMR e.g, synchronous control for multi-motor propulsion, coordinated control for steering and traction motors, and safety-critical functions like emergency braking and obstacle avoidance. The repository may also include comprehensive simulation models that enable offline testing of these control functions on a programmer's computer without requiring physical vehicle hardware.

[0014] An aspect of this disclosure is the capability to perform comprehensive offline simulation on a programmer's computer before deploying the adapted modular code to the actual electric vehicle. This offline simulation may be configured to simulate electronic components of the actuator / engine and / or of the control drive, transmissiongears (if any), and / or electric cables connecting between the control drive and the actuator, and suchlike.

[0015] As discussed below in greater detail, this method may be implemented not only for adapting the modular code of the modular code repository for a single drive of a single motor (or another kind of motor). For example, the aforementioned method may be adapted in different ways in order to efficiently adapt the modular code in various use cases such as: a) Writing code for a drive which controls an actuator before the specific hardware have been finally selected or developed. b) Writing code for drives of multiple types to control the same type of actuator (or even the same actuator). This may be useful, for example, in order to efficiently and quickly introduce a drive of another model to replace an existing model. c) Writing code for a drive of a certain type to control a different type of actuator to perform the same or similar task (e.g., in the case of replacing the model of motors used in a system).

[0016] The term “actuator” in the context of the present disclosure pertains to a mechanical or electromechanical component that is responsible for converting control signals into physical movement or actions. This includes devices such as electric motors, servo motors, stepper motors, valves, sensors, CNC Machines, drill heads, and pumps, which take specific commands from control systems and execute them through various mechanisms to perform tasks like positioning, exertion of force, exertion of torque, controlling the flow of fluids, regulating pressure, and other related functions.

[0017] The term “drive” (also occasionally referred to as “actuator controller”) in the context of the present disclosure pertains to a system, device, and / or software that directs and regulates the operations of an actuator (e.g., a motor, such as an electric motor). The drive receives high-level instructions from an automated system and translates them into precise low-level signals that control the actions of the actuator, such as movement, position, speed, and other operational parameters. The actuator controller may be implemented solely by software, firmware and / or hardware, or any combination thereof. This combination approach often includes the drive softwaretranslating high-level instructions and the drive unit amplifying or conditioning the control signals suitable for the specific actuation unit, such as Servo Motors, Stepper Motors, Valves, Sensors, CNC Machines, Pumps, etc. The specific combination of hardware, software, and / or firmware may depend on the specific application, system complexity, and requirements of the particular actuation unit being controlled and of the particular type of actuator controller. Since a plurality of terms such as “drive”, “drive system”, drive controller”, “motor controller”, “control software” are used in a somewhat overlapping manner in the art, it is noted that whenever any such term is used in the present disclosure, it may pertain to any specific combination of one or more of software, hardware, and / or firmware of the actuator controller, unless explicitly stated otherwise.

[0018] Referring to any of the systems, methods, and computer program products disclosed in the present disclosure, it is noted that such systems, methods, and computer program products may optionally be used for development and / or configuration of virtual drives. A virtual drive is a drive that is being developed and tested in a virtual environment (e.g., an environment which enables simulation of drive performance when controlling operations of an actuator in different scenarios). At a later stage, that virtual drive may be converted or otherwise used for programming of an actual drive, e.g., as discussed below in greater detail, e.g., in the detailed description section.

[0019] According to a further aspect, the generating may include importing a bulk of code of the modular code repository to the adapted modular code, and the importing may include excluding the other control instructions from the adapted modular code and keeping the executable control instruction.

[0020] According to a further aspect, the generating may include importing a bulk of code of the modular code repository to the adapted modular code, the importing may include disabling the other control instructions and enabling the executable control instruction by adding a control -instruction enablement parameter value to the imported bulk of code.

[0021] According to a further aspect, the modular code repository may include simulation code for simulating behaviors of the different types of actuation units (actuators) when controlled by actuator controller, and the generating may includeincluding in the adapted modular code simulation code for simulation of the type of actuator and / or rendering simulation code for simulating behavior of at least one other type of actuator unexecutable by the adapted modular code.

[0022] According to a further aspect, the modular code repository may include instructions for implementation of real time functionality in each of the different types of actuators, comprising instructions for: control loops, homing, and / or real time parts of fieldbus.

[0023] According to a further aspect, the modular code repository may include instructions for implementation of features including at least two features out of: fieldbus, commutation, motor feedback, hardware interfaces.

[0024] According to a further aspect, the parametric component may include hardware specific parameters not included in the modular code repository, pertaining to at least two out of: hardware specific timers, communication interface, encoder interface, memory management.

[0025] According to a further aspect, the parametric component may include product specific parameters that pertain to a specific type of actuator and which are not included in the modular code repository, the product specific parameters pertaining to at least two out of: chip reset procedure, product specific interfaces, adjustment to timing .

[0026] According to a further aspect, the generating may include including in the adapted modular code additional control instructions that are absent from the modular code repository, to implement actuator functions that are not enabled by the modular code repository, such that the additional control instructions implement interfaces comprised in the modular code repository.

[0027] According to a further aspect, the control instructions may include instructions for controlling operation of the actuator by the actuation unit controller to execute at least one of the following actions: powering an electric motor, moving a robotic arm, modifying rotation speed of a drilling head, and retracting a pneumatic piston. In possible embodiments, the generating comprises generating the adapted modular code for controlling an electric motor. Optionally, the adapted modular codeis unexecutable for controlling rotation speed of drilling heads and / or for retracting of a pneumatic piston.

[0028] According to a further aspect, the method may further include: (a) generating a second adapted modular code for controlling at least one second actuator of the selected type, the second adapted modular code including at least: (i) the executable control instruction; and (ii) a second parametric component which includes information for adapting the executable control instructions to the second actuator; such that at least one control instruction of the modular code repository is unexecutable by the second adapted modular code; and (b) providing the second adapted modular code to an actuator controller which controls a second actuator, for executing parts of the second adapted modular code at least in order to: (i) activate the second actuator; (ii) modify activation level of the second actuator; and / or (iii) stop operation of the second actuator.

[0029] Optionally, in such case, the second parametric component may include different parameter values than the parametric component. Optionally, in such case, the adapted modular code, when executed by a suitable actuator controller, causes the suitable actuator controller to emit a first electric signal for modifying a state of the actuator from a first state to a second state, and the second adapted modular code — when executed by a compatible actuator controller — causes the compatible actuator controller which controls said actuator to emit a second electric signal for modifying a state of the actuator from the first state to the second state. Optionally, but in some embodiments preferably, an electric magnitude of the first electric signal is at least 10% greater (or smaller) than and an electric magnitude of the second electric signal. Optionally, the electric magnitude is selected from a group of electric magnitudes consisting of: voltage, current, duty cycle, and pulse width.

[0030] According to a further aspect, the method may include: (a) controlling the actuator by executing instructions of the adapted modular code, the executing including executing the executable control instruction based on the parametric component to induce motion of an industrial equipment module mechanically connected to the actuator; (b) subsequently, disconnecting the mechanical coupling of the actuator from the industrial equipment module; (c) subsequently, mechanically coupling the second actuator to the industrial equipment module; and (d) afterwards,controlling the second actuator by executing the parts of the second adapted modular code including at least executing the executable control instruction based on the second parametric component to induce subsequent motion of the industrial equipment module.

[0031] The method may include one or more of the following: (a) performing offline simulation on a programmer's computer to validate the adapted modular code e.g., simulating electronic components of the actuator / engine and / or of the control drive, of transmission gears (if any), and / or of electric cables connecting between the control drive and the actuator, and suchlike; (b) generating performance metrics from the simulation e.g., power consumption and / or response times; (c) iteratively refining the adapted modular code based on simulation results before vehicle deployment; (d) generating a simulation report documenting tested scenarios and validation results; and / or (e) installing the validated adapted modular code after successful offline simulation.

[0032] According to a further aspect, a code instructory portion of the adapted modular code and a second code instructory portion of the second adapted modular code may have a level of similarity of at least 90%.

[0033] According to a further aspect, the method may include: (a) generating a second adapted modular code for controlling at least one second actuator of a second type out of actuator selected out of the different types of actuators, the second adapted modular code including at least: (i) a second executable control instruction of the modular code repository, suitable for the second type of actuator; and (ii) a second parametric component which includes information for adapting the executable control instructions to the second actuator, such that at least one second unrequired control instruction of the modular code repository is unexecutable by the second adapted modular code; and (b) providing the adapted modular code (e.g., upon successful offline simulation thereof) to an actuator controller which controls a second operational actuator of the second actuator type, for executing parts of the adapted modular code at least in order to: (i) activate the second operational actuator, (ii) modify activation level of the second operational actuator, and / or (iii) stop operation of the second operational actuator.

[0034] According to yet another aspect, there is disclosed a program storage device readable by an actuator controller, tangibly embodying a program of instructions executable by the actuator controller to perform a method for controlling an actuator, including the steps of: (a) activating the actuator using at least first one control instruction adapted from a source modular code that includes control instructions for controlling operation of different types of electric actuators by at least one type of drive, such that the different type of electric actuators include the type of the actuator and at least one other type of actuator that is not controlled by the control actuator; such that the activating of the actuator is executed utilizing a first parametric value of a first parameter, the first parametric value being absent from the source modular code; (b) modifying an activation level of the actuator using at least one second control instruction adapted from the source modular code; such that the modifying of the activation level of the actuator is executed utilizing a second parametric value of a second parameter, the second parametric value being absent from the source modular code; and / or (c) stopping operation of the actuator using at least one third control instruction adapted from the source modular code; such that the modifying of the activation level of the actuator is executed utilizing a third parametric value of a third parameter, the third parametric value being absent from the source modular code.

[0035] At least one of the first, second or third, control instructions can be further adapted based on offline simulation of at least one of the following: behaviors of the different types of electric actuators when controlled by an actuator controller, load simulation, and / or I / O simulation (e.g., to simulate electronic components of the different types of electric actuators, electronic components of the drive, transmission gears' and / or electric cables connecting between the drive and the different types of electric actuators).

[0036] According to a further aspect, the activating of the actuator, the modifying an activation level of the actuator, and / or the stopping of the operation of the actuator are based on control instructions adapted from the source modular code that excludes any parametric values for the first parameter, for the second parameter, and / or for the third parameter.

[0037] According to a further aspect, the program of instructions executable by the actuator controller to perform the method for controlling the actuator includes code of which at least 80% originates from the source modular code.

[0038] According to yet another aspect, there is disclosed a system that includes a plurality of movable parts, the system including: (a) a plurality of actuators that includes at least a first actuator of a first type of actuator and a second actuator of a second type of actuator; (b) a first actuator controller operable to control the first actuator to move a first movable part of the system, using a first program of instructions executable by the first actuator controller to perform a first method for controlling the first actuator, such that at least 80% of the first program of instructions originates from a source modular code; (c) a second actuator controller operable to control the second actuator to move a second movable part of the system, using a second program of instructions executable by the second actuator controller to perform a second method for controlling the second actuator, such that at least 80% of the second program of instructions originates from the source modular code. The first program of instructions in such case may include at least one first control instruction originating from the source modular code which is used for controlling moving of the first movable part by the first actuator and which has no corresponding executable control instruction in the second program of instructions; and the second program of instructions in such case may include at least one second control instruction originating from the source modular code which is used for controlling moving of the second movable part by the second actuator and which has no corresponding executable control instruction in the first program of instructions.BRIEF DESCRIPTION OF THE DRAWINGS

[0039] In order to understand the disclosed subject matter and to see how it may be carried out in practice, embodiments will now be described, by way of non-limiting examples only, with reference to the accompanying drawings, in which:

[0040] Figs. 1A, IB and 1C illustrate examples of a system that includes an actuator that is controlled by an actuator controller;

[0041] Figs. 2A and 2B illustrate exemplary timelines for development of code for drive systems according to two different code development schedules;

[0042] Figs. 3A and 3B are flow charts illustrating examples of a method for programming an actuator controller;

[0043] Fig. 4 illustrates a modular diagram illustrating an example of a modular code repository code;

[0044] Fig. 5A illustrates adaptation of control instructions of a modular code repository into adapted control instructions of an adapted modular code;

[0045] Fig. 5B illustrates keeping some control instructions of a modular code repository as control instructions of an adapted modular code while excluding others;

[0046] Fig. 5C illustrates including new control instructions to an adapted modular code using interfaces in a modular code repository;

[0047] Fig. 6 is a flow chart illustrating a method for programming an actuator controller;

[0048] Fig. 7 is a schematic diagram of a system that includes an actuator that is controlled by actuator controller;

[0049] Figs. 8 and 9 are flow charts illustrating examples of methods for programming a plurality of actuator controllers with different adapted modular codes that are generated based on modular code of a single modular code repository; and

[0050] Fig. 10 illustrates an exemplary timeline for development of code for drive systems according to examples of the methods, systems, and computer program products disclosed herein.

[0051] It will be appreciated that for simplicity and clarity of illustration and description, certain elements in the figures may not have been drawn to scale. This could include the exaggeration of certain element dimensions relative to others. Additionally, corresponding or analogous elements may be identified using repeated reference numerals in the figures.DETAILED DESCRIPTION OF EMBODIMENTS

[0052] In the following detailed description, numerous specific details are provided to ensure a comprehensive understanding of the invention. While these details aid in understanding, those skilled in the art will recognize that the invention can be implemented without these specific details. In addition, well-known methods, procedures, and components are not described in detail to avoid obscuring the invention. References to a method, system, or non-transitory computer readable medium should be interpreted inclusively, as including related aspects of the invention.

[0053] The functionality of the elements described herein may be implemented using circuitry or processing circuitry such as general -purpose processors, special purpose processors, integrated circuits, Application Specific Integrated Circuits (ASICs), and other conventional circuitries. Such circuitries and / or combinations thereof may be configured and / or programmed to perform the disclosed functionality. This also includes emerging technologies such as quantum processors and Al-driven systems. Processors, containing transistors and other components, are considered part of this circuitry. In this disclosure, the terms 'circuitry', 'units', or 'means' refer to hardware configured to perform the disclosed functions. Such processor may be implemented as purely hardware circuitry. In other possible implementations, processors, controllers, computers, units, or other means may be implemented using any combination of hardware with software and / or firmware.

[0054] The terms “computer”, “processor”, and “controller” should be expansively construed to cover any kind of electronic device with data processing capabilities, including, by way of non-limiting example, a personal computer, a server, a computing system, a communication device, a processor (e.g. digital signal processor, DSP), a microcontroller, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a smartphone, an electronic control unit (ECU) of a vehicle, cloud computing servers, an and so on. Unless stated otherwise, the terms “computer”, “processor”, and “controller” may also include a combination of several modules (e.g., several central processing units, CPUs), which operate together toward a goal. Unless specifically stated otherwise, as apparent from the following discussions, it is appreciated that throughout the specification discussions utilizing terms such as "processing", "calculating", “computing”, "determining", "generating", “setting”,“configuring”, “selecting”, “defining”, or the like, include actions and / or processes of a computer that manipulate and / or transform data into other data. That data is represented as physical quantities, e.g., such as electronic or electromagnetic quantities, and / or said data representing physical objects.

[0055] It is appreciated that certain features of the presently disclosed subject matter, which are, for the sake of clarity of description, described in the context of separate embodiments, may also be combined in a single embodiment. Conversely, various features of the presently disclosed subject matter, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable sub-combination. In embodiments of the presently disclosed subject matter one or more steps illustrated in the figures may be executed in a different order and / or one or more groups of steps may be executed simultaneously. The figures illustrate a general schematic of the system architecture in accordance with an embodiment of the presently disclosed subject matter. Each module in the figures can be made up of any combination of software, hardware and / or firmware that performs the functions as defined and explained herein. The modules in the figures may be centralized in one location or dispersed over more than one location.

[0056] Any reference in the specification to a method should be applied mutatis mutandis to a system capable of executing the method. Any reference in the specification to a method which can be executed by a computer should be applied mutatis mutandis to a non-transitory computer readable medium that stores instructions that once executed by a computer result in the execution of the method. All the details, variations, optional features, optional steps which are discussed with respect to a system are also applicable, mutatis mutandis, to such a corresponding method (and non-transitory computer readable medium, where applicable), and vice versa.

[0057] Figs. 1A, IB and 1C illustrate examples of system 100 that includes an actuator 110 (e.g., electric engine of an electric vehicle, such as AGV or AMR) that is controlled by an actuator controller 120, and an optional controller 220 whose instructions — if implemented — are usable by actuator controller 120 in order to generate corresponding control signals which control the operation of the actuator 110, in accordance with examples of the presently disclosed subject matter. For example,Fig. IB illustrates a robotic arm 100 which includes a plurality of servo motors 110 controlled by corresponding drive systems 120, in accordance with examples of the presently disclosed subject matter. Fig. 1C illustrates a part of a carton assembly line, in which a plurality of servo motors 110 are included, each being controlled by a corresponding drive system 120, in accordance with examples of the presently disclosed subject matter. Each one of a group of one or more actuators 110 (e.g., servo motor) of system 100 is controlled by an associated actuator controller 120 (e.g., servo drive). Actuator controller 120 includes nontangible memory module 122 which stores computer code which, when executed by a suitable circuitry 124 of actuator controller 120 (e.g., one or more processors), sends control signals to the associated actuator 110, for controlling operation of the actuator 110. In some configurations, one or more optional controllers 220 issue commands to each of the one or more different actuator controllers 120. For example, such commands by controller 220 may include a desired location of the robotic arm, a desired position or extension of one or more of the motors, and so on. It is noted that some drive systems 120 may be used to control different types of motors 110 or other controllable technical equipment such as stepper motors, valves, sensors, computer numerical control (CNC) machines, pumps, and so on. One example of such other types of controllable technical equipment includes drilling head 130. It is noted that many systems which are known in the art include such actuators 110, and the herein disclosed systems, methods, and computer program products may be implemented for any system which includes at least one actuator controller, and is not limited to any specific example.

[0058] Figs. 2A and 2B illustrate exemplary timelines for development of code for drive systems according to two different code development schedules; Fig. 2A demonstrates a potential timeline for developing code for drive system according to a prior art code development procedure, and Fig. 2B illustrates an example for developing code for drive system according to examples of the methods, systems, and computer program products disclosed herein.

[0059] Referring to Fig. 2A, the process of designing and developing hardware (HW), and manufacturing a prototype of the drive is expected to take about 3 to 6 months (denoted 821). For example, that process may include actions such as: requirement analysis and specification, concept design, component selection, electricaldesign, mechanical design, prototyping, integration, testing, verification and validation, documentation, and review. In comparison, as discussed above in greater detail, the timeline for developing software (SW) for such a system (including at least one actuator controller, and optionally also at least one actuator, controller, etc.) using conventional actuator controller code development process may span a much longer time period, such as one to one and a half years. This may include, for example, between half a year and a year for programing features for the actuator controller (denoted 811), about one more month of adding product specific features (denoted 812), about two months of adjusting the code to specific hardware (denoted 813), and about two months of testing the new actuator controller software with the specific hardware used (denoted 814).

[0060] It is noted that there are several software development processes which are used by others for developing code for actuator controllers. One example process is referenced in Fig. 2A, and it includes: a) The bulk of the traditional drive development described herein by way of example is dedicated to the programing of different features. This step (denoted 811) may take some 6-12 months (for example), and includes processes such as: initial design of software requirements, planning architecture; writing, reviewing, and optimizing code for basic functionality, including iterative design and testing cycles, integration of individual software components, addressing compatibility issues, and initial system-level testing. This step also includes creating comprehensive documentation, and executing preliminary tests to ensure stability and robustness. The features programed in this stage may vary, depending on the type of drive, intended use, etc., but may include for example any one or more of the following: motor control, sensor data acquisition, communication protocol management, error handling and diagnostics, user interface development, safety protocols implementation, energy efficiency management, multi -threading and task management, security measures, compliance and certification functions, automated calibration, real-time monitoring and reporting, fault tolerance and redundancy, remote access and control, and so on.b) Next, product-specific features are added if needed, depending on the developed product and its intended use. This step (denoted 812) is usually shorter (e.g., 3-4 weeks), and may include identifying and integrating specific features for the targeted products, conducting focused tests on the product-specific features, and making necessary adjustments. c) Once all the features are programed, the code need to be adjusted to specific hardware selected for the specific product. This step (denoted 813), which may take 6-8 weeks includes identifying unique characteristics in the specific servo drive (or equivalent component), modifying the existing codebase to align with hardware specifications, and ensuring that the code works seamlessly with the identified hardware. d) Finally, proper tests of the combined operation of hardware and software are required, including preparing the testing environment with actual hardware for real-world scenarios, assessing the functionality of the software within the actual hardware environment, and evaluating the software’s performance, scalability, and efficiency on the hardware. This step (denoted 814) may also take some 6-8 weeks in the traditional drive development described herein.

[0061] In comparison, the disclosed systems, methods, and computer program product facilitate a much faster software development process, e.g., as indicated in the nonlimiting example of Fig. 2B. According to the proposed process, the entire software development process can be achieved in five to six months.

[0062] This may include, for example, a few days to configure standard features and optionally to remove unneeded features from the code of the modular code repository (denoted 831), about a month to add product specific features (denoted 832, similar length to 812), about two months of adjusting the code to specific hardware (denoted 833, similar length to 813), about two weeks for testing the code with simulation (denoted 834, additional details below), and about two months for testing the new actuator controller software with the specific hardware used (denoted 835, similar length to 814). Additional details are provided, by way of example, with respect to method 500 of Fig. 3A.

[0063] Figs. 3A and 3B are flow charts illustrating examples of method 500, in accordance with the presently disclosed subject matter. Method 500 is a method for programming an actuator controller (also referred to as “actuation unit controller”, AUC), such as a drive, a drive system, inverter, and so on. The actuator controller may optionally control actuators of various types, such as different types of motors (e.g., stepper motor, servo motor, direct-current (DC) motor, brushless DC motor, linear motor, synchronous with surface mounted PM, asynchronous, switched reluctance) or other controllable technical equipment such as valves, sensors, CNC machines, pumps, and so on. The AUC may optionally control actuators used in wide variety of settings, such as but not limited to industrial automation equipment actuators, domestic equipment actuators, transportation system actuators, robotics, medical devices, consumer electronics, and so on and so forth.

[0064] Method 500 starts with step 510 of obtaining a modular code repository stored on a nontangible memory module, the modular code repository including, at minimum, control instructions for controlling operation of different types of actuators, by one or more types of actuator controllers (AUC). The modular code repository may be stored on any type of nontangible memory module(s), including, by way of non-limiting example, any suitable (e.g., reliable, accessible) technology of storing data in a nontangible way, both volatile and non-volatile. For example, such storage technologies include hard disk drives (HDD), solid state drives (SSD), optical media (e.g., CD, DVD), magnetic tape, and so on. Additionally, the repository can leverage network-attached storage (NAS) systems for centralized access and management across a local area network (LAN) or wide area network (WAN). Furthermore, cloud storage platforms, such as public, private, or hybrid clouds, provide scalable and distributed storage solutions for the code repository. The nontangible memory module may include one or more separate physical units, either local, remote, or a combination thereof. Referring to the examples set forth with respect to the other drawings, the modular code repository may be a modular code repository 300 shown in Fig. 4.

[0065] It is noted that the modular code repository includes modular code, which may be modular, for example, in at least one of the following senses:

[0066] Functional Modularity: In this interpretation, "modular code" refers to a design approach where the software is divided into independent modules, eachresponsible for a specific function or feature related to activating the drive. These modules can be developed, tested, and maintained separately, allowing for easier code management and scalability. For example, there might be separate modules for drive detection, authentication, encryption, and activation, each handling its respective functionality independently. Interoperability between the different functional modules may be programmed into the modular code repository.

[0067] Component Modularity: Here, "modular code" implies that the software is built using reusable components or building blocks that can be assembled and configured to create the desired functionality for actuator control. These components may encapsulate specific tasks or operations related to the activation process, such as user interface elements, communication protocols, or data processing algorithms. Utilizing component-based design facilitates code reuse, enhances maintainability, and promotes consistency across different parts of the software.

[0068] Structural Modularity: This interpretation focuses on the organization and structure of the codebase, emphasizing clear separation of concerns and well-defined interfaces between different parts of the software responsible for activating the drive. Modular code in this sense would employ architectural patterns such as layered architecture, where distinct layers handle specific aspects of the actuator control process. Such a structure may enable, for example, easier comprehension, debugging, and modification of the software by isolating changes within individual modules or layers.

[0069] The modular code repository may include, inter alia, control instructions for controlling actuators of different types to perform various actions, such as (but not limited to) any one or more of the following: (a) actuator activation (e.g., starting activity or starting operation of the actuator, such as starting movement) , (b) actuator stopping of operation (e.g., stopping physical movement, stopping idle rotation), (c) actuator activation level modification (e.g., rotation speed, movement speed, torque, etc.), and / or offline simulation of at least one of the following: behaviors of the different types of electric actuators when controlled by an actuator controller, load simulation, and / or I / O simulation e.g., to simulate electronic components of the different types of electric actuators, electronic components of the drive, transmission gears, and / or electric cables connecting between the drive and the different types ofelectric actuators). For example, for an actuator which is a motor (e.g., electric motor), the modular code repository may include code for execution of the following actions with respect to one or more types of motors, such as any one or more of the following: a) Torque Control: Instructions for adjusting the torque output of the motor, controlling the amount of rotational force exerted by the motor shaft to match the requirements of the load. b) Speed Control: Instructions for regulating the speed of the motor, controlling it to operate at specific rotational speeds or within defined speed ranges. c) Direction Control: Instructions for managing the direction of motor rotation, enabling forward, reverse, or bidirectional movement as required by the application. d) Acceleration and Deceleration Control: Instructions for ramping up or down the motor's speed to achieve desired acceleration and deceleration profiles, ensuring gradual changes in motion. e) Position Control: Instructions for positioning the motor's output shaft accurately, enabling precise movement to specific locations or angles as needed in positioning applications. f) Feedback Control: Instructions for incorporating feedback signals from sensors (e.g., encoders, Hall effect sensors) to maintain desired performance parameters such as speed, position, or torque. g) Safety Control: Instructions for implementing safety features and protocols to ensure safe operation of the motor, including overcurrent protection, overvoltage protection, and emergency stop functionality. h) Synchronization Control: Instructions for coordinating the operation of multiple motors or motor-driven mechanisms, ensuring synchronized movement in multi -axis systems. i) Energy Efficiency Control: Instructions for optimizing the motor's energy consumption and efficiency, including adjusting motor current based on load demand.j) Fault Detection and Diagnostics: Instructions for monitoring the motor's performance and detecting potential faults or abnormalities, as well as diagnostic routines for identifying and troubleshooting issues.

[0070] Similar or other control instructions may also be included in the modular code repository for other types of actuator, in addition and / or instead control instructions for motor, such as instructions for any combination of one or more of the following: activation / deactivation control, position control, state control, speed control, direction control, force / pressure control, feedback control, timing control, energy efficiency control, safety control, temperature control, flow control, damping control, adaptive control, diagnostic control.

[0071] Fig. 4 shows a modular diagram illustrating an example of the modular code repository code, in accordance with examples of the presently disclosed subject matter. Control software module 320 of modular code repository 300, in the illustrated example, includes control instructions for actuators of multiple types. The code in module 320 may itself include a plurality of modules. Such modules may be structured in different ways. For example, different modules may focus on different types of control instructions (e.g., real-time vs. not real time), on different types of products, on different types of actuators (e.g., servo motor, stepper motor, linear motor), characteristics required for operation and / or control of different types of actuators, and so on. While the methods, systems, and computer program product disclosed in the present disclosure are not limited to modular code repository, each of these methods, systems, and computer program product may optionally utilize modular code repository 300 as the modular code repository it uses.

[0072] For example, modular code repository 300 may include (e.g., as part of control software module 320) standard-features code module 322 that includes control instructions for implementing standard features which may be required for a wide range of uses, or even for basic operation of the controlled actuator. Standard-features code module 322 may include code pertaining to various types of software, hardware, and / or firmware associated with various types of actuators, of actuator controllers, and so on. Examples for code modules which may be included in standard features code module 322 may include any one or more of the following:a) Bus Voltage module that is responsible for managing the bus voltage, including for example inrush and regeneration. b) Commissioning Tool module, responsible for the motor commissioning. c) Commutation module, responsible for the motor commutation. d) Current Controller module, responsible for the current-loop control. e) Enable-Disable Manager module, responsible for enabling and disabling the drive. f) Fieldbus module, responsible for the fieldbus communication, including micro-interpolation and phase-locked loop. g) Homing module, responsible for the homing process. h) Input / Output Manager module, responsible for the operation of the inputs and outputs. i) Motor Simulation module, responsible for the virtual simulation of the motor. j) Overload module, responsible for the maximum time allowed for staying at maximum current. k) Plant Simulation module, responsible for the virtual simulation of the motor load. l) Point to Point Generator module, responsible for generating the trajectory of the motion profile. m) Position Velocity Controller module, responsible for the position and velocity loops control. n) Recorder module, responsible for the internal real time recording of drive parameters. o) Temperature module, responsible for monitoring and / or managing the temperature of the drive and motor. p) Terminal module, responsible for command handling. Flexible method for adding / removing user commands.

[0073] For example, modular code repository 300 may include (e.g., as part of control software module 320) product- specific code module 324. Product-specific code module 324 may include control instructions for implementing features which are relevant for relatively small number of actuators, actuator controllers, use cases, etc. Alternatively or additionally, product-specific code module 324 may include one or more interoperable computer code modules, designed to seamlessly interact and work with other code modules (which may be written at a later time, based on productspecific requirements). Such an interoperable computer code module ensures compatibility and communication between different software components, enabling them to exchange information and function together effectively. For example, the one or more interoperable computer code modules may include dedicated code components such as hooks, Application Programming Interfaces (APIs), libraries, frameworks, connectors, and middleware.

[0074] By way of example, the modular code repository may include hardwarespecific code modules which may be utilized and / or adapted for: a) Microprocessor reset procedure. b) Specific interfaces (e.g., safety related interfaces). c) Adjustment to timing.

[0075] For example, modular code repository 300 may include (e.g., as part of control software module 320) hardware-specific code module 326. Hardware-specific code module 326 may include control instructions for implementing features which are relevant for hardware aspects of a relatively small number of actuators, actuator controllers, use cases, etc. Alternatively or additionally, Hardware-specific code module 326 may include one or more interoperable computer code modules, designed to seamlessly interact and work with other hardware-oriented code modules (which may be written at a later time, based on hardware-specific requirements). Such an interoperable computer code module ensures compatibility and communication between different software components, enabling them to exchange information and function together effectively. For example, the one or more interoperable computer code modules may include dedicated code components such as hooks, Application Programming Interfaces (APIs), libraries, frameworks, connectors, and middleware.By way of example, the modular code repository may include hardware-specific code modules which may be utilized and / or adapted for: a) Specific timers. b) Communication interface. c) Encoder interface. d) Memory management.

[0076] Modular code repository 300 may optionally include (e.g., as part of control software module 320) real-time control module 340, which include computer code modules which are specific to real-time operation of actuator controllers (e.g., drives).

[0077] Real-Time code module 340 include code modules that are responsible for time-critical operations and control of the controlled actuator (e.g., the controlled electric motor). Optionally, these real-time modules may be executed in a deterministic manner, ensuring that the actuator control commands and responses are processed within strict timing constraints. The real-time code modules typically handle tasks such as reading sensor inputs, executing control algorithms, generating pulse-width modulation (PWM) signals for driving the actuator, and monitoring system conditions. These modules are designed to prioritize responsiveness and minimize latency, as any delay or inconsistency in their execution can adversely affect the motor's performance and stability. The real-time code modules are often optimized for efficient execution on microcontrollers or digital signal processors (DSPs) to achieve the required realtime performance. As suggested in the diagram, parts of the aforementioned modules (code modules 322, 324, 326) may include real-time components, which follow such criteria. Optionally, the modular code repository includes instructions for implementation of real time functionality in each of the different types of actuators for which it is suitable, including instructions for: control loops, homing, and / or real time parts of fieldbus. For example, the modular code repository may include any one or more of the following real-time code modules: a) Control loops — Real-time code modules for control loops continuously adjust operational parameters to maintain system stability and performance by processing feedback data and executing corrective actions instantaneously.b) Homing (capture) — Real-time code modules for homing capture the precise position of actuator components, moving them to a known reference point to ensure accurate positioning and reliable operation. c) Real-time parts of fieldbus — Real-time code modules for fieldbus handle time-critical communication between the drive software and peripheral devices, ensuring synchronized data exchange and coordinated control actions.

[0078] By comparison, modular code repository (e.g., code modules 310, 320, and / or 340) may also include non-real-time code modules. Such non-real-time code modules which may be adapted into drive software may be used to handle tasks with less stringent timing requirements. For example, these modules may be responsible for various supporting functions, such as user interface (UI) management, data logging, communication with external devices or systems, and configuration settings. The non- real-time code modules may execute at lower priorities or in a time-shared manner, allowing them to be preempted by higher-priority real-time tasks when necessary. These modules often interact with the real-time code modules by exchanging data or invoking specific functions, but they operate independently and do not directly influence the time-critical actuator control operations. While not necessarily so, non- real-time code modules can be more complex and may leverage higher-level programming languages or frameworks, as their execution timing is less critical compared to the real-time components.

[0079] Optionally, the modular code repository may include instructions for implementation of features including at least two features out of: fieldbus, commutation, motor feedback, hardware interfaces. For example, hardware interfaces features may include analog to digital (A2D) features, pulse width modulation (PWM) features, etc.

[0080] Optionally, modular code repository 300 may include simulation code module 330, which include computer code modules which may be used (e.g., in an adapted form) for simulation of the operation of any one or more of the following: actuators, actuator controller, loads, user interface, sensors, other system components (e.g., components moved by the motor, or components connected or otherwise affected by such components), environmental conditions, and so on. For example, simulationcode module 330 may include actuator simulation code module 332 that includes code that may be implemented (e.g., in an adapted or non-adapted form) for simulation of operation of the actuator (e.g., based on control instructions of drive instructions provided according to an adapted code of control software module 320 and in response to simulation of load or other simulated aspects, e.g., as discussed above). For example, simulation code module 330 may include load simulation code module 332 that includes code that may be implemented (e.g., in an adapted or non-adapted form) for simulation of behavior of the load affected by a respective actuator (e.g., based on control instructions of drive instructions provided according to an adapted code of control software module 320 and in response to simulation of actuator or other simulated aspects, e.g., as discussed above). For example, simulation code module 330 may include input / output (VO) simulation code module 332 that includes code that may be implemented (e.g., in an adapted or non-adapted form) for simulation of operation of the input / output component of the system (e.g., based on control instructions of drive instructions provided according to an adapted code of control software module 320 and in response to simulation of the actuator, the load, or other simulated aspects, e.g., as discussed above). For example, the simulation code modules may be implemented in order to simulate mechanical and / or electrical models of the respective modeled entities (e.g., electronic components of the drive, electronic components of the different types of electric actuators / motors, load, transmission gears; and / or electric cables connecting between the drive and the different types of electric actuators, etc.).

[0081] Thus, once code of control software module 320 has been adapted (e.g., for a specific actuator, actuator controller, use-case, etc.), as discussed below in greater detail, the code of simulation code module 330 may be used to verify that the adapted control code operates as intended. As control software module 320 may include code that is sufficiently developed so as to require limited and well-defined adaptation to be used with actual actuator controllers (as well as well-defined hooks, APIs, etc., for introduction of new control software interoperable with that existing code), the simulation code module 330 may include simulation code closely interconnected to the control code of control software module 320, allowing very efficient simulation of the control code. Thus, it is possible in such cases to test the adapted control code in an effective and efficient way even before the actual hardware of the actuator and / oractuator controller is finalized or available for testing, this way facilitating shorter code development process, e.g., as suggested in Fig. 2B.

[0082] Optionally, the Simulation may include mechanical and electrical models of the motor and / or load. Optionally, the simulation provides a high order plant identification that facilitates testing, tuning (e.g., auto tune) and validation of the plant’s response to control instructions and other inputs of the actuator controller in a virtual safe environment on the actual drive (drive-in-loop), which is to be connected to the plant rather than to an external mathematical simulation. The actuator controller may incorporate from the modular code repository (in either adapted or non-adapted format) multi-level adaptive control schemes that support a wide range of plants, including real time passive plant identification. In the context of the present disclosure, the term "plant" refers to the physical system or machinery being controlled. This includes all the mechanical components, such as motors, actuators, sensors, and other hardware that interact with the drive and actuator control systems. The plant is the real- world part of the system that the control algorithms and software modules are designed to manage and regulate. The "plant" encompasses the entire physical apparatus that performs the actual work in an industrial or mechanical process, under the direction of the actuator controller and optionally of other control systems.

[0083] Optionally, modular code repository 300 may include code configuration module 310, which include computer code modules which may be used for configuring or otherwise adapting code modules of modular code repository 300 for specific use cases, e.g., as discussed below (e.g., with respect to step 520 of method 500.

[0084] Each of the control instructions stored in the modular code repository (e.g., any of the examples provided above, such as those discussed with respect to modules 310, 320, 322, 324, 326, 330, 332, 334, 336, and 340) may optionally be adapted to match different types of actuators, different use cases, different loads, different environments, and so on.

[0085] Referring to the modular code repository as a whole, it is noted that building the modular code repository in advance — and not with respect to specific actuator, actuator controller, and / or user case — allows to implement the modular code repository in a very standardized way. That is, optionally, the interfaces between the different modules (also referred to as “building blocks”) of the modular coderepository (e.g., the inputs and outputs in the interaction between the different modules during operations) may be harmonized and / or standardized. Such an approach would also render the modular code repository relatively easy to adapt to different uses, and relatively easy to expand if needed (e.g., to specific use cases, for new types of actuator controllers, etc.). An example for standardization is that for the current loop, the current reading that is needed (and measured by a current sensor) is standardized as a value in Ampere.

[0086] Referring to the modular code repository as a whole, it is noted that building the modular code repository in advance — and not with respect to specific actuator, actuator controller, and / or user case — mean that the building blocks can be programmed, tested, and verified independently of a specific hardware.

[0087] Reverting to method 500, step 510 is followed by step 520 of generating an adapted modular code based on the modular code repository. The adapted modular code is usable for controlling at least one actuator of a selected type out of the different types of actuators. The adapting may be done in many different ways, and based on different factors, such as: user preferences; user parametrization, user configuration, user specification, user customization, actuator parameters, plant parameters, load parameters, system parameters, environment parameters, and so on. The adapting includes implementing parts of the modular code repository — some of which with changes or other forms of adaptations, and some with less or no changes. Additionally, the adapting may include adding new software code modules that interconnect with parts of the modular code derived from the modular code repository. Various ways of adaptation are discussed throughout the present disclosure, but other ways of adaptation may be implemented as well. Referring to the examples set forth with respect to the other drawings, the adapted modular code may be adapted modular code 400

[0088] Significantly, the adapted modular code generated in step 520 based on the modular code repository includes at least one executable control instruction of the modular code repository, suitable for the type of actuator for which the adapted modular code is generated (e.g., linear motor synchronous with surface mounted permanent magnet). Examples for executable code instructions of the adapted modular code which may originate from the modular code repository, e.g., after adaptation,include any one or more of the following: (a) actuator activation (e.g., starting activity or starting operation of the actuator, such as starting movement) , (b) actuator stopping of operation (e.g., stopping physical movement, stopping idle rotation), and / or (c) actuator activation level modification (e.g., rotation speed, movement speed, torque, etc.). The at least one executable control instruction of the adapted modular code that originates from the modular code repository may be taken from the modular code repository in various ways, such as any one or more of the following ways.

[0089] Optionally, the adapting of step 520 may include step 521 of incorporating into the adapted modular code a control instruction of the modular code repository without any significant changes (e.g., “as is”). This may be useful, for example, for relatively simple control instructions. Adapting the modular code of the modular code repository to include control instructions without change may be implemented, for example, by keeping one or more control instructions intact, and eliminating or disabling other control instructions. Elimination or disablement of control instructions of the modular code repository may be achieved, for example, by not copying such instructions, by deleting copied versions of these instructions from the generated adapted modular code, by setting a flag or another variable to zero or other value indicative of not operating, or in any other suitable way. Fig. 5B illustrates keeping some control instructions 350 of modular code repository 300 as control instructions 450 of adapted modular code 400, while deleting or disabling others, in accordance with examples of the presently disclosed subject matter. It is noted that optionally reference number 350 may be applied to groups of control instructions and / or to functions of the code, mutatis mutandis.

[0090] Optionally, the adapting of step 520 may include step 522 of modifying a control instruction of the modular code repository for adapting the respective control instruction into the adapted modular code. The degree of the modifying may vary significantly, from very slight to more significant. However, the essence of the control instruction is maintained throughout this adaptation, and the controlled action of the actuator controlled by the respective control instruction is not modified. For example, such modifications may include code conversion (in which the control instruction is translated to another instruction format recognized by the selected type of actuator), protocol adaptation (in which communication protocols are modified to ensurecompatibility with the actuator's interface requirements), command restructuring (in which the sequence of instructions is reorganized for compatibility with the actuator's execution process), abstraction layering (in which higher-level abstractions are introduced to interface with the actuator's lower-level functions), and interface adaptation (in which the control instruction is adjusted to align with the actuator's specific communication interface protocols).

[0091] Optionally, the adapting of step 520 may include a step 523 of configuring a control instruction of the modular code repository for adapting the respective control instruction into the adapted modular code. Some control instructions may be modified using variables, parameters, or other modifiable values. In such cases, the bulk of the respective control instruction is taken without meaningful changes (e.g., “as is”) from the modular code repository, but one or more variables, parameters, or other modifiable values are set or selected during the adaptation process of step 520, in order to adapt the respective control instruction to specific characteristics of one or more factors such as the actuator, actuator controller, load, plant, environment, etc. Fig. 5A illustrates adaptation of some control instructions 350 of modular code repository 300 into adapted control instructions 450 of adapted modular code 400 by setting values of one or more variables, parameters, or other modifiable values, in accordance with examples of the presently disclosed subject matter. Optionally, the adapted modular code may include a parametric component which includes information for adapting one or more of the executable control instructions to the at least one actuator for which the adapted modular code is intended. It is noted that optionally reference number 350 may be applied to groups of control instructions and / or to functions of the code, mutatis mutandis. The empty circles in control instructions 350 represent parts of the code in which parameter values may be included and / or parts of the code which refer to other locations to obtain such parameter values, and the numbers within the corresponding circles in control instructions 450 represent specific parameter values added as part of the adaptation of the modular code of the modular code repository into the adapted modular code.

[0092] Optionally, step 520 may include step 524 of generating for the adapted modular code a parametric component which includes information for adapting one or more executable control instructions, functions, and / or other code modules of themodular code repository to the at least one actuator. For example, step 524 may include including parameter values into the executable instructions directly. For example, step 524 may include generating a file (or another data structure) including a plurality of values, which are then used for adapting various executable control instructions (e.g., including timing parameter, electrical parameter, physical parameters, and so on and so forth).

[0093] In addition to keeping, modifying, deleting, disabling, parametrizing, and / or adapting in any other suitable way, the adapting of step 520 may also optionally include step 525 of generating the adapted modular code to include one or more control instructions, functions, and / or other code modules that are not included in the modular code repository. Optionally, this may include generating the adapted modular code to include one or more control instructions (or functions, other code modules) which are not included in the modular code repository, but which are interoperable with code that does exist in the modular code repository, e.g., using preexisting interfaces included in the modular code repository, such as hooks, APIs, libraries, frameworks, connectors, middleware, etc. Optionally, step 520 may include including in (e.g., writing into) the adapted modular code additional control instructions that are absent from the modular code repository, to implement actuator functions that are not enabled by the modular code repository. In such cases, the additional control instructions may optionally implement interfaces included in the modular code repository. This may be useful in order to add product specific features into product-specific code module 424 of adapted modular code 400, and / or to add hardware specific features into hardwarespecific code module 426 of adapted modular code 400, and so on.

[0094] Fig. 5C illustrates including new control instructions 460 and / or other new code modules to adapted modular code 400 using interfaces (denoted “H” in the diagram) in modular code repository 300 (e.g., interfaces included in control instructions 350, but not necessarily so), in accordance with examples of the presently disclosed subject matter. Step 525 may include, for example, writing a new function in the adapted modular code having a name which is referred to by an existing function of the modular code of the modular code repository, such that when the existing function is executed, it calls for the executing of the new function using the existing function name. Step 525 may include, for example, working in the opposite direction:e.g., using or joining to existing background loops of the ’’main code” of the modular code repository, without having to write such loops or functions anew. Optionally, step 525 may include adding a new command using the infrastructure of calling existing functions that already exists. This may include, for example, replacing an instruction of the modular code repository code with a new instruction, using the interfaces (e.g., hooks, connection point) of the replaced instructions for the new instructions of the adapted modular code. The aforementioned replaced instruction may be deleted or otherwise disabled, for example, in step 526. It is noted that optionally reference number 460 may be applied to groups of control instructions and / or to functions of the code, mutatis mutandis.

[0095] Optionally, the adapting of step 520 may include step 526 of rendering at least one control instruction, function, and / or another code module of the modular code repository unexecutable in the adapted modular code. Such a control instruction, function, or another code module rendered unexecutable may, for example, be excluded from the adapted modular code altogether (e.g., not copied or deleted), parametrically set for inexecution (e.g., setting an execution flag value to zero), not provided with parameter values required for execution, or rendered unexecutable in any other suitable fashion.

[0096] It is noted that any one of the control instructions, functions, or other code modules (or any groups of one or more thereof) of the modular code repository that are modified during the adapting of step 520 may be modified in more than one way, including any combination of any one or more of the ways discussed with respect to steps 521, 522, 523, 524, 525, and 526.

[0097] Referring to step 520 as a whole, it is noted that step 520 may optionally include using a pre-compilation tool. Such a pre-compilation tool may be included in the modular code repository. For example, using such a pre-compilation tool (or in any other suitable fashion), step 520 may include selecting one or more building blocks (e.g., each including one or more control instructions, functions, and / or other code modules of the modular code repository), and applying actions for the compilation of control software module 320 (e.g., “Common Core / Source” software) for a specific hardware of a specific actuator and / or specific actuator controller, use case, plant, etc.Such actions may include, for example, one or more of the following actions: add, remove, edit faults, command, features, errors.

[0098] Referring to the examples of Fig. 2B, it is noted that any combination of activities discussed with respect to the software development process (831, 832, 833, 834, 835) may be implemented as step 520. Likewise, step 520 may be implemented as the software development process of Fig. 2B. For example, step 831 of Fig. 2B (removing unneeded features from the code of the modular code repository) may correspond to step 526. For example, step 832 of Fig. 2B (adding product specific features) may correspond to steps 525 (as well as any one or more of the other steps of Fig. 3B, as needed). For example, step 833 of Fig. 2B (adjusting the code to specific hardware) may correspond to steps 525 (as well as any one or more of the other steps of Fig. 3B, as needed). Optionally, step 520 may include testing the adapted modular code with simulation (e.g., using simulation module 330 or in any other way), corresponding to step 834 of Fig. 2B. Optionally, step 520 may include testing the new actuator controller software (the adapted modular code) with the specific hardware used, corresponding to step 835 of Fig. 2B.

[0099] Step 520 is followed by step 530 of providing the adapted modular code (e.g. , upon successful offline simulation) to an actuator controller that controls an operational actuator of the selected actuator type, for executing parts of the adapted modular code. Referring to the examples set forth with respect to the other drawings, the actuator controller may be actuator controller 120. Optionally, step 530 may include providing the adapted modular code (e.g., upon successful offline simulation thereof) to an actuator controller that controls an operational actuator of the selected actuator type, for executing parts of the adapted modular code for controlling the respective operational actuator, e.g., in order to execute any one or more of the following actions: a) Activate the operational actuator. b) Modify activation level of the operational actuator. c) Stop operation of the operational actuator.

[0100] Method 500 may also include optional step 540 of executing at least a portion of the adapted modular code by the actuator controller, thereby controlling theoperation of the operational actuator. For example, optional step 540 may include executing at least a portion of the adapted modular code by the actuator controller for inducing any one or more of the following actions: (a) activating the operational actuator, (b) modifying activation level of the operational actuator, and / or (c) stopping operation of the operational actuator. Optional step 540 may include executing by the actuator controller at least a portion of the adapted modular code derived (e.g., directly adapted) from the modular code repository, for inducing any one or more of the following actions: (a) activating the operational actuator, (b) modifying activation level of the operational actuator, and / or (c) stopping operation of the operational actuator.

[0101] Fig. 6 is a flow chart illustrating an example of method 850, in accordance with the presently disclosed subject matter. Method 850 is a method for programming an actuator controller (also referred to as “actuation unit controller”, AUC), such as a drive, a drive system, inverter, and so on. The actuator controller may optionally control actuators of various types, such as different types of motors (e.g., stepper motor, servo motor, direct-current (DC) motor, brushless DC motor, linear motor, synchronous with surface mounted PM, asynchronous, switched reluctance) or other controllable technical equipment such as valves, sensors, CNC machines, pumps, and so on. The AUC may optionally control actuators used in a wide variety of settings, such as but not limited to industrial automation equipment actuators, domestic equipment actuators, transportation system actuators, robotics, medical devices, consumer electronics, and so on and so forth. Method 850 may be a variation of method 500, and vice versa. Any step, detail, alternative, option, combination, etc., discussed with respect to method 500 may be implemented as part of method 850, and vice versa (especially with respect to corresponding steps — as will be clear to a person who is of ordinary skill in the art — but not necessarily so). Some details which were discussed in detail above (e.g., with respect to method 500, to modular code repository 300, or in any other way) are not included in the interest of concision.

[0102] Method 850 starts may start with optional step 851 of obtaining product specification, which may include any data required for developing the actuator control software, such as: type of movement, intended use, physical parameters, environmental conditions, load characteristics, operational constraints, safetyrequirements, plant specification, regulatory compliance, system integration details, user interface preferences, diagnostic and monitoring capabilities, power supply specifications, and communication protocols.

[0103] Step 851 may optionally include processing received data pertaining to the product specification for defining the control algorithms required for the actuator controller. This may include determining the type of control (e.g., open-loop, closed- loop, PID control), selecting appropriate feedback mechanisms (e.g., encoders, tachometers, Hall sensors), specifying control parameters (e.g., gain values, sampling rates, filter characteristics), and so on.

[0104] Step 851 may optionally include processing received data pertaining to the product specification for determining the required software architecture (e.g., based on different options supported by the modular code of the modular code repository). This step may also involve deciding on the real-time operating system (RTOS) to be used, if any, and outlining the memory management strategy.

[0105] Step 852 of method 850 includes configuring features and optionally removing unneeded features. Step 852 may be executed based on the product specification obtained in step 851, as well as on any other available data. Pertaining to the examples set forth with respect to the previous drawings, step 852 may correspond to the aforementioned step 831.

[0106] Step 853 of method 850 includes adding product specific features. Step 853 may be executed based on the product specification obtained in step 851, as well as on any other available data, e.g., pertaining to the examples set forth with respect to the previous drawings, step 853 may correspond to the aforementioned step 832.

[0107] Step 854 of method 850 includes adjusting the code to the specific hardware. Step 854 may be executed based on the product specification obtained in step 851, as well as on any other available data, e.g., Pertaining to the examples set forth with respect to the previous drawings, step 854 may correspond to the aforementioned step 833.

[0108] Step 855 of method 850 includes compiling the adapted modular code.

[0109] Step 856 of method 850 includes testing the compiled adapted modular code with simulation, and improving the adapted modular code based on the output of thesimulation. Optionally, step 856 may include using simulation code that is at least partly derived from the modular code repository. Pertaining to the examples set forth with respect to the previous drawings, step 856 may correspond to the aforementioned step 834.

[0110] Step 857 of method 850 includes testing the improved adapted modular code on the actual hardware, and further improving the adapted modular code based on the output of the testing. Pertaining to the examples set forth with respect to the previous drawings, step 857 may correspond to the aforementioned step 835.

[0111] Optional step 858 of method 850 includes providing the adapted modular code (e.g., upon successful offline simulation thereof) to an actuator controller that controls an operational actuator of the selected actuator type, for executing parts of the adapted modular code. Pertaining to the examples set forth with respect to the previous drawings, step 858 may correspond to the aforementioned step 530.

[0112] Optional step 859 of method 850 includes executing at least a portion of the adapted modular code by the actuator controller, thereby controlling the operation of the operational actuator. Pertaining to the examples set forth with respect to the previous drawings, step 859 may correspond to the aforementioned step 540.

[0113] It is noted that while the steps of method 850 were discussed in a specific order, other implementations of method 850 may include executing the steps of method 850 in other order of steps, optionally also including concurrently or partially concurrently executing different steps.

[0114] Fig. 7 is a schematic diagram of system 100 that includes an actuator 110 that is controlled by actuator controller 120, in accordance with examples of the presently disclosed subject matter. Memory module 122 of actuator controller 120 may store, inter alia, adapted modular code 400, which is usable for controlling the actuator 110 via instructions and any other required communication transmitted via the actuator controller hardware (e.g., hard driver) for which the adapted modular code was adapted. Adapted modular code 400 may be constructed in any suitable way. For example, adapted modular code 400 may include any one or more of the following modules:a) Code configuration module 410 (e.g., an adapted version of code configuration module 310, mutatis mutandis). It is noted that in some cases it might be useful to retain the code configuration module as part of the adapted modular code, e.g., in case further modifications will be required, in order to configure the adapted modular code to new situations (e.g., changes in the load, in the plant, in the actuator, etc.). In other cases it may be useful to exclude the code configuration module from the adapted modular code (e.g., in order to save memory space, to prevent unauthorized modifications to the software, and so on). b) Control software module 420 (e.g., an adapted version of control software module 320, mutatis mutandis). Control software module 420 may optionally include any one or more of the following: Standard features module 422, product specific module 424, and hardware specific interfaces module 426 (e.g., adapted versions of the corresponding modules 322, 324, 326 respectively, mutatis mutandis). c) Simulation module 430 (e.g., an adapted version of simulation module 430, mutatis mutandis). Simulation module 430 may optionally include any one or more of the following: actuator simulation module control 432, load simulation module 434, and I / O simulation module 436 (e.g., adapted versions of the corresponding modules 332, 334, 336 respectively, mutatis mutandis, numbered 432, 434, 436, respectively). It is noted that in some cases it might be useful to retain the simulation module 430 as part of the adapted modular code, e.g., in case further modifications will be required, in order to simulate the adapted modular code when modified or in new situations (e.g., changes in the load, in the plant, in the actuator, etc.). In addition (or instead) of its use during development, simulation using simulation module 430 may also be useful during routine operation of the actuator controller, such as for in diagnostic (e.g., comparing actual performance to what is expected by simulation). In other cases, it may be useful to exclude the simulation module from the adapted modular code (e.g., in order to save memory space, to prevent unauthorized modifications to the software, and so on).d) Optional real-time control module 440, corresponding to real-time control module 340.

[0115] The adapted modular code 400 may include a parametric component 490 that includes information for adapting features of the adapted modular code (features originating from the modular code repository and / or newly developed features interconnected with the aforementioned modular code) to the at least one actuator for which adapted modular code 400 is generated. For example, the parametric component 490 may include parameter values associated with any combination of one or more of the following parts: a) Real time code (e.g., including control loops, homing, real time parts of fieldbus, and so on, as discussed above in greater detail). b) Features (e.g., including non-real-time parts of fieldbus, commutation, motor feedback, interfaces, and so on). c) Simulation (e.g., including simulated mechanical and electrical models of the motor). d) Hardware specific (e.g., including hardware-specific timers, communication interface, encoder interface, memory management, down to digital signal processing, DSP, and so on). e) Product specific (e.g., including chip reset procedure, specific interfaces e.g., for safety, adjustment to timing , non-standard communication if required by client, and so on).

[0116] Optionally, the parametric component 490 may include hardware specific parameters not included in the modular code repository, pertaining to at least two out of: hardware specific timers, communication interface, encoder interface, memory management. Optionally, the parametric component 490 may include product specific parameters that pertain to a specific type of AUC and which are not included in the modular code repository, the product specific parameters pertaining to at least two out of: chip reset procedure, product specific interfaces (e.g., for safety), adjustment to timing (e.g., if client wants some non-standard communication), and so on.

[0117] System 100 may also include feedback module 140, intended to provide actuator controller feedback information resulting from the performance of therespective actuator 100. Such feedback information may include, for example, position data, velocity data, acceleration data, torque measurements, temperature readings, vibration levels, power consumption, current draw, voltage levels, fault signals, error codes, operational status, performance metrics such as efficiency and response time, and so on. This feedback information can be used to adjust the control algorithms in real-time, perform diagnostics, predict maintenance needs, and optimize overall system performance. Feedback module 140 may employ various sensors to collect the aforementioned data, such as position encoders, tachometers, Hall effect sensors, strain gauges, thermocouples, accelerometers, current sensors, and voltage sensors. The feedback module 140 may also include signal conditioning circuits, analog-to- digital converters, and communication interfaces to relay the feedback information to the actuator controller 120. In addition to processing feedback, actuator controller 120 may also implement adapted code module 400 in order for storing and analyzing historical performance data, which can be used for trend analysis, predictive maintenance, and improving future iterations of the control software.

[0118] The interaction between actuator 110 and the plant is represented by load 190. It is noted that more nuanced and / or more complicated interactions may be implemented.

[0119] Actuator controller hardware 124 may also interact with users and / or auxiliary systems, e.g., for receiving commands, for receiving input data, for reporting conditions or any other data, etc. This may be achieved by an input and / or output unit 170 (which may also be used as user interface module, mutatis mutandis).

[0120] Considering method 500 as a whole, and the process of generating the adapted modular code used for controlling of one or more actuators (e.g., motor) by the disclosed actuator controller (e.g., drive) based on the aforementioned modular code of the modular code repository, it is noted that modular code (both the original and the adapted) may include any one or more of the following parts: f) Real time code (e.g., including control loops, homing, real time parts of fieldbus, and so on, as discussed above in greater detail). g) Features (e.g., including non-real-time parts of fieldbus, commutation, motor feedback, interfaces, and so on).h) Simulation (e.g., including simulated mechanical and electrical models of the motor ). It is noted that whenever the term “simulation” is used throughout the disclosure, its meaning should be construed to mean either simulation or emulation (or any combination of these meanings). i) Hardware specific (e.g., including hardware-specific timers, communication interface, encoder interface, memory management, down to digital signal processing, DSP, and so on). j) Product specific (e.g., including chip reset procedure, specific interfaces e.g., for safety, adjustment to timing, non-standard communication if required by client, and so on).

[0121] Optionally, the modular code repository may include extensive code module for Real Time code, Features, and possibly also Simulation, which enable efficient and quick development of high-quality modular code (e.g., by implementing step 520 above). The hardware-specific and / or product-specific code modules (e.g., modules 426 and 424, respectively) may be added to the bulk of the mostly pre-written code (including the real-time code, the features, and possibly also the simulation) in a quick, efficient, and high-quality fashion. Significantly, the hardware-specific and / or product-specific code modules may be added to the aforementioned bulk of the mostly pre-written code without messing-up the operation of the aforementioned bulk of the mostly pre-written code, e.g., using the aforementioned hooks, function names, APIs, libraries, or another suitable interfaces. As will discussed below in greater detail, this also allow to modify or even replace the hardware-specific and / or product-specific code modules without messing-up the operation of the aforementioned bulk of the mostly pre-written code, and thus in a quick, efficient, and high-quality manner.

[0122] Reverting to method 500, and especially to step 520, it is noted that the generating of the adapted modular code in step 520 may optionally include adding information into the parametric component, for adapting the executable control instructions to an actuator task that is a controllable task of the selected actuator type (i.e., task that is controlled by the controller actuator). That is, the parametric component includes information which is not only associated with the specific model of actuator and / or actuator controller, but also includes information useful for the specific task required from the actuator. For example, the added information mayinclude selection of task-related functions and / or task-related control instructions associated with the respective task out of the modular code repository, and discarding or disabling of task-related information associated with other tasks. The added information may include information required for the specific task (e.g., operational parameter, dimensional parameters, and so on), etc. The task may be a novel user- defined task, in which case new code, functions, control instructions etc., may be required. In such cases, such new code, functions, control instructions etc. may connect to the modular code originating from the modular code repository using interconnection such as hooks, functions names, APIs, etc. (e.g., as discussed above).

[0123] Reverting to step 520, e.g., to optional step 526, it is noted that optionally, method 500 may include importing a bulk of code of the modular code repository to the adapted modular code. During that importing, the importing may include excluding the at least aforementioned other control instruction from the modular code repository — a control instruction that is unexecutable in the adapted modular code, because it is excluded (i.e., it is non existing in the adapted modular code). In addition or instead, the importing may include excluding from the adapted modular code a function, code module, etc. of the modular code repository - which are therefore unexecutable in the adapted modular code. The importing in such cases includes keeping the executable control instruction (either unchanged or somewhat changed, e.g., as discussed above in greater detail) and including it within the adapted modular code. For example, the excluding of the unexecutable control instruction, unexecutable function, unexecutable code module, etc., may include deleting the respective code from a bulk of code copied from the modular code repository. For example, the excluding of the unexecutable control instruction, unexecutable function, unexecutable code module, etc., may include selecting not to copy or otherwise transfer (e.g., somewhat changed) the respective code from the modular code repository. It is noted that the excluding may include excluding a group of control instructions / functions / code blocks of a plurality of different modules of the modular code repository (e.g., 310, 320, 322, 324, 326, 330, 332, 334, 336, and / or 340) that are interconnected to one another. For example, modular code repository may include code blocks (including control instructions, functions, etc.) associated with certain capability of some actuator types in various modules of the modular code of the modular code repository (e.g., both in order to configure it in module 310, to executeit in module 320, and / or to simulate it in module 330) that are interconnected with one another. If the respective capability is not required for the specific implementation, several interconnected blocks of code may be excluded from the different modules of the modular code during the generating of the adapted modular code. A few examples for such capabilities which may spread over several modules (e.g., configuration, control execution, simulation) and which are not needed in all use cases include: Field- Oriented Control (FOC), regenerative braking, torque ripple minimization, adaptive control (adjusting control parameters in real-time based on operating conditions to maintain optimal performance), electrical harmonics suppression, some safety features, predictive maintenance, noise reduction, and so on.

[0124] Optionally, step 520 may include importing a bulk of code of the modular code repository to the adapted modular code (e.g., as discussed in the previous paragraph), and during the importing disabling the at least aforementioned other control instruction from the modular code repository — a control instruction that is unexecutable in the adapted modular code, because it is disabled (e.g., it is flagged not to execute in the adapted modular code, e.g., in the parametric portion of the adapted modular code). Optionally, the generating may include enabling at least one executable control instruction by adding a control-instruction enablement parameter value to the imported bulk of code (e.g., the respective function / control instruction is flagged in the adapted modular code to execute; e.g., in the parametric portion of the adapted modular code). Different ways may be implemented for indicating in the adapted modular code which functions, control instructions, or code block are to be executed and which are not. For example, the indication (e.g., flagging) may include indicating only control instructions, functions, etc. which should be available for execution in the adapted modular code. For example, the indication (e.g., flagging) may include indicating only control instructions, functions, etc. which should not be available for execution in the adapted modular code. For example, the indication (e.g., flagging) may include indicating in different ways control instructions, functions, etc. which should be available for execution and those which should not be available for execution.

[0125] Reverting to the topic of using code of the modular code repository for simulating operation of the actuator, actuator controller, and / or other components ofthe system. It is noted that optionally, the modular code repository may include simulation code for simulating behaviors of the different types of actuators when controlled by one or more respective actuator controller (e.g., drive), e.g., as part of simulation module 330. The generating of the adapted modular code in such cases may include including in the adapted modular code (e.g., adapted modular code 400) simulation code for simulation of one or more types of actuators (especially, the type of actuator for which the adapted modular code is generated). Optionally, the generating of the adapted modular code may also include rendering simulation code for simulating behavior of at least one other type of actuator unexecutable by the adapted modular code (e.g., another type of motor which is not controlled by the drive for which a specific adapted modular code is generated based on the modular code repository. The rendering of such simulation code may be done by deletion, exclusion, flagging, or in any other way which makes that code unexecutable. The relevant simulation code which is taken from the modular code repository to the adapted modular code (in either adapted or non-adapted form, optionally in a parameterized form) may be connected to information of the parametric component of the adapted modular code, e.g., associating it with specific parameter values pertaining to specific actuator, actuator controller, task, etc., for which the adapted modular code is developed. Such simulation code may be used, as discussed above, for simulating operation of the actuator (e.g., electric motor) when controlled using the adapted modular code without having access to the actual actuator - only to its simulation using the simulation code originating from the modular code repository. The simulation may be executed on a dedicated evaluation board (e.g., on dedicated evaluation board received from the manufacturer of the hardware), on a personal computer (without any dedicated hardware, e.g., simply using a tailored / parametrized version the pre-existing modular code of the modular code repository), or on any other computer.

[0126] Referring to method 500 as a whole as well as to adapted modular code 400 as a whole, it is noted that optionally the adapted modular code cannot be executed by the operational actuator controller to control actuators of the different types of actuators supported by the modular code of the modular code repository, other than one or more specific types of actuators for which the adapted modular code is generated. That is, the group of actuator types which may be controlled by the adapted modular code in such cases is a proper subgroup of the group of actuator types forwhich control instructions are included in the modular code repository, and there is at least one type of actuator which is not controllable using the adapted modular code. However, other adapted modular codes which can control that at least one type of actuator may be developed from the same modular code repository (e.g., in other instances of method 500). Referring to method 500 as a whole as well as to adapted modular code 400 as a whole, it is noted that in many cases, the modular code repository is not executable by the operational actuator, and it requires the process of adaptation (and possibly expansion) in order to control the respective actuator.

[0127] Referring to method 500 as a whole as well as to adapted modular code 400 as a whole, it is noted that optionally the modular code repository may include features and / or control instructions for execution of a wide variety of actions and use cases, while the adapted modular code does not support execution by the operational actuator controller of several of these actions. That is, the types of actions which may be controlled by the adapted modular code in such cases is a proper subgroup of the types of actions for which control instructions are included in the modular code repository, and there at least one type of action which is not achievable using the adapted modular code. However, other adapted modular codes may be developed from the same modular code repository (e.g., in other instances of method 500) which can control execution of that last type of action. For example, the modular code repository may include control instructions for controlling by actuation unit controllers operation of at least one type of actuator to execute at least one of the following actions: moving an electric motor, moving a robotic arm, modifying rotation speed of a drilling head, and retracting a pneumatic piston, while the adapted modular code can control an electric motor but the adapted modular code is unexecutable for controlling rotation speed of drilling heads and for retracting of a pneumatic piston.

[0128] Fig. 8 is a flow chart illustrating an example of method 600, in accordance with the presently disclosed subject matter. Method 600 is a method for programming a plurality of actuator controllers with different adapted modular codes that are generated based on modular code of a single modular code repository. The steps of method 600 are variations of corresponding steps of method 500 with some additional caveats. Therefore, any detail, variation, alternative, feature, and so forth, discussed with respect to method 500 as a whole or to any of its steps is also applicable, mutatismutandis with respect to method 600 and to its corresponding steps. Step 610 corresponds to step 510, steps 621 and 622 correspond to step 520, steps 631 and 632 correspond to step 530, and optional steps 641 and 642 correspond to optional step 540. Many details are not repeated, in the interest of concision.

[0129] Step 610 includes obtaining a modular code repository stored on a nontangible memory module, the modular code repository including control instructions for controlling operation of different types of actuators (e.g., motors) by at least one type of actuator unit controller (e.g., drive).

[0130] Step 621 includes generating a first adapted modular code based on the modular code repository. The first adapted modular code is usable for controlling at least one actuator of a first type of actuator out of the different types of actuators, and is unusable for controlling actuators of a second type other than the first type. Step 622 includes generating a second adapted modular code based on the modular code repository. The second adapted modular code is usable for controlling at least one actuator of a second type of actuator out of the different types of actuators, and is unusable for controlling actuators of a first type other than the second type. For example, the first type of actuator may be an electric motor, and the second type of actuator may be a hydroelectric valve. In another example, the first type of actuator may be a servo motor, and the second type of actuator may be a brushless DC motor.

[0131] Step 631 includes providing the first adapted modular code to a first actuator controller that controls a first operational actuator of the first actuator type, for executing parts of the first adapted modular code. Step 632 includes providing the second adapted modular code to a second actuator controller that controls a second operational actuator of the second actuator type, for executing parts of the second adapted modular code.

[0132] Optional step 641 includes executing at least a portion of the first adapted modular code by the first actuator controller, thereby controlling the operation of the first operational actuator. Optional step 642 includes Executing at least a portion of the second adapted modular code by the second actuator controller, thereby controlling the operation of the second operational actuator.

[0133] Pertaining to steps 631 and 632, and to steps 641 and 642, it is noted that the first actuator controller may control operation of the first actuator in parallel to control of the second actuator by the second actuator controller, but this is not necessarily so.

[0134] It is noted that in a variation of method 600, the two operational actuators may be of the same type of actuator, but put to different use. For example, the same model of actuator may be used on two different parts of the same plant, but the two actuators (e.g., actuators 110A and HOB of the example of Fig. 1A) may operate under different restriction (e.g., range of movement) and / or under different conditions (e.g., torque applied to the motor during operation), and therefore require different adapted modular codes, possibly including different features. For example, despite being the same type of actuator, actuator controller 120B may need to implement a control feature that is not needed for the operation of actuator controller 120A, and is therefore excluded from the adapted modular code generated for actuator controller 120A in method 600.

[0135] Fig. 9 is a flow chart illustrating an example of method 700, in accordance with the presently disclosed subject matter. Method 700 is a method for programming one or more actuator controllers with different adapted modular codes that are generated based on modular code of a single modular code repository. The steps of method 700 are variations of corresponding steps of method 500 with some additional caveats. Therefore, any detail, variation, alternative, feature, and so forth, discussed with respect to method 500 as a whole or to any of its steps is also applicable, mutatis mutandis with respect to method 700 and to its corresponding steps. Step 710 corresponds to step 510, steps 720 and 750 correspond to step 520, steps 730 and 760 correspond to step 530, and optional steps 740 and 770 correspond to optional step 540. Many details are not repeated, in the interest of concision.

[0136] Steps 710, 720, and 730, as well as optional step 740 are identical in essence to the corresponding steps 510, 520, 530, and 540 of method 500. It should be noted, however, that the first adapted modular code, the first actuator, the first type of actuator, and the first actuator controller of method 700 are different from those of method 600. Likewise, the second adapted modular code, the second actuator, the second type of actuator, and the second actuator controller of method 700 are differentfrom these of method 600. The same notations were used solely for the sake of the reader’s convenience.

[0137] Step 750 includes generating a second adapted modular code based on the first adapted modular code. The second adapted modular code is usable for controlling at least one actuator of a second selected type of actuator out of the different types of actuators. The second type may be different or similar to the first type. Optionally, the generating of the second adapted modular code may be further based on the modular code repository and / or on analysis of performance of the first adapted modular code.

[0138] Step 750 may optionally include any combination of any one or more of the following: a) Generating a parametric component for the second adapted modular code that is different from the parametric component of the first adapted modular code. b) Incorporating into the second adapted modular code at least one executable control instruction and / or executable feature from the modular code repository that is not executable in the first adapted modular code. c) Writing into the second adapted modular code at least one executable control instruction and / or executable feature that uses interconnections of the modular code of the modular code repository (e.g., hooks, APIs, function names) that are not used (or, alternatively, used in a different way) in the first adapted modular code. d) Excluding from the second adapted modular code at least one control instruction and / or feature originating from the modular code repository that is executable in the first adapted modular code. e) Excluding from the second adapted modular code at least one control instruction and / or feature that uses interconnections of the modular code of the modular code repository that are used in the first adapted modular code.

[0139] Step 760 includes providing the second adapted modular code to a second actuator controller that controls a second operational actuator of the selected actuator type, for executing parts of the second adapted modular code. The second operationalactuator may optionally differ from the first operational actuator. The second actuator controller may optionally differ from the first actuator controller.

[0140] Step 770 includes executing at least a portion of the second adapted modular code by the second actuator controller, thereby controlling the operation of the second operational actuator.

[0141] Method 700 may be useful for efficient code development in a wide range of scenarios, such as: a) In case a model of actuator in a specific use case needs to be replaced (e.g., it is no longer manufactured). b) In case the setting in which an actuator operates were changed (e.g., additional safety features are required, a different range of operation is required). c) In case a different component of the system is replaced (e.g., if the feedback sensor is replaced, and different type of feedback algorithm is required). d) In case a model of actuator for which adapted modular code was already developed needs to be put to a similar use.

[0142] Method 700 thus provides a way for efficient code development, based on the adapted modular code that was already developed for the first actuator. This may potentially utilize the modular structure of the modular code repository to an even greater effect than was discussed previously (e.g., with respect to method 500).

[0143] Pertaining to method 500, it is noted that optionally method 500 may further include: a) Generating a second adapted modular code for controlling at least one second actuator of the selected type (i.e., the same type as the in the first adapted modular code, e.g., a second servo, with servo being the one of the type of actuators supported by the respective modular code repository) such that the second adapted modular code comprises at least: (a) an executable control instruction included in the first adapted modular code, (b) a second parametric component which includes information foradapting the executable control instruction to the second actuator (which is likely different from the parametric component of the first adapted modular code; optionally, the second parametric component includes at least some different parameter values than the parametric component of the first adapted modular code). The generating of the second adapted modular code in this example is such that at least one control instruction of the modular code repository is unexecutable by the second adapted modular code (that is, the second adapted modular code is not usable by first actuator in the same way it operated before. Likely, the first code is not usable by the second actuator). b) Providing the second adapted modular code to an actuator controller which controls a second actuator, for executing parts of the second adapted modular code at least in order to: (a) activate the second actuator; (b) modify activation level of the second actuator; and / or (c) stop operation of the second actuator.

[0144] Referring to the any of the methods discussed above in which different adapted modular codes are developed to be used in the same use case but for different actuator controllers (e.g., drives) and / or for different actuators, it is noted that optionally the first adapted modular code — when executed by a suitable actuator controller — causes the respective first actuator controller to emit a first electric signal (e.g., characterized by certain voltage, duty cycle, PWM, etc.) for modifying a state of the actuator it controls from a first state (e.g., a first position of a robotic arm) to a second state (e.g., a second position of the robotic arm). In the same method, the second adapted modular code — when executed by a compatible actuator controller (could be the first actuator controller or another one) causes the compatible actuator controller which controls the second actuator (which could be the first actuator or a second one) to emit a second electric signal for modifying a state of the respective actuator from the first state to the second state. An electric magnitude of the first electric signal e.g., voltage, duty cycle, PWM) can be at least 10%, at least 20%, at least 30%, or at least 50% greater (or smaller) then an electric magnitude of the second electric signal. That is, using the modular code repository, as discussed throughout the present disclosure, various efficient methods are disclosed to overcome the need toreplace hardware in the system (e.g., drive, motor) while having to adapt only relatively small parts of the adapted modular code.

[0145] Referring to any of the methods discussed above in which different adapted modular codes are developed to be used to replace an actuator while using a similar adapted modular code as the one used to control the previous actuator, with the only (or at least, the main) change between the adapted modular codes is the parametric component of the respective adapted modular codes. Such a method may include (e.g., as part of method 500, 700), for example: a) Controlling the original actuator by executing instructions of the adapted modular code by the actuator controller, the executing including executing the executable control instruction based on the parametric component to induce motion (or otherwise operating) of a plant (e.g., an industrial equipment module) mechanically coupled to the original actuator. b) Subsequently, disconnecting the mechanical coupling of the original actuator from the industrial equipment module. c) Subsequently, mechanically coupling the second actuator to the industrial equipment module. d) Afterwards, controlling the second actuator by executing the parts of the second adapted modular code. This includes at least executing the executable control instruction based on the second parametric component to induce subsequent motion (or otherwise operating) of the respective plant.

[0146] That is, methods 500 and 700 may be used to replace hardware (e.g., in an industrial, commercial, transportational, domestic, etc. setting) while providing a quick and efficient process of software development, based on a modular code that was developed for the original actuator. The controlling of the actuator using the second adapted modular code may of course be preceded by generating the second code module, wherein the generating of the second code module is based on the first code instructory portion which includes the control instructions for the first actuator (e.g., as discussed above with respect to methods 500, 700).

[0147] Referring to the any of the methods discussed above in which different adapted modular codes are developed (e.g., methods 600, 700, and relevant instances of method 500) — a first adapted modular code and a second adapted modular code — a first code instructory portion (of the first adapted modular code) and a second code instructory portion (of the second adapted modular code) may be very similar to one another (e.g., at least 80% similar, at least 90% similar, at least 95% similar, at least 99% similar). Such degree of similarity between the different code instructory portion means not only that the codes can be developed rather quickly, efficiently, and in high quality, but also that the respective codes can be maintained in an efficient and relatively inexpensive way. In order to facilitate that, the modular code of the modular code repository (e.g., modular code repository 300) may include common userinterface (UI) components, common code development environment, and so on. It is noted that such common UI components and / or common code development environment in the modular code repository may also benefit development of code based on the modular code of the modular code repository in other use cases. For example, in method 600 in which the first adapted modular code and the second adapted modular code may be developed for completely different use cases, the structure, names conventions, interconnections, common simulation environment, and so on, may benefit a code developer using the system. It is noted that a common UI and associated practices is useful not only for the people developing and / or maintaining the control software, but also to the people who use the actuator and actuator controllers. For example, in an industrial setting it is possible to implement the systems, methods, and computer program products discussed above in order to develop code for hundreds, thousands, or even much more actuators and actuator controllers - all having unified user interface, thus greatly simplifying the control of the various hardware and software components by the operators of the industrial facility. The same, of course, holds for clients in many other fields of endeavor (e.g., mechanics of transportation systems, etc.).

[0148] Referring to the any of the methods discussed above in which different adapted modular codes are developed (e.g., methods 600, 700, and relevant instances of method 500) — it is noted that utilization of the modular code repository discussed above may be utilized (e.g., in any of the aforementioned methods) to develop control software for very different hardware (e.g., very different actuator controllers and / orvery different actuators), while working with and generating control software (the first adapted modular code and the second adapted modular code, for example) which is relatively very similar).

[0149] Fig. 10 illustrates an exemplary timeline for development of code for drive systems according to examples of the methods, systems, and computer program products disclosed herein. Steps 843, 844, and 845 correspond to steps 833, 834, and 835, respectively. Optional step 851 corresponds to step 821, if implemented. As can be seen, the development time for the second adapted modular code may optionally be even shorter than the development time of the first adapted modular code, and is definitely shorter than the code development schedule of Fig. 2A. The development of the second adapted modular code may be implemented by executing step 622, step 750, or another instance of step 520, or in any other way suggested above. Some examples for time savings in the development of the second adapted modular code with respect to the development of the first adapted modular code were discussed above. Another example pertains to the simulation (if implemented), as the simulation does not have to be repeated from scratch. Simulations pertaining to the first adapted modular code based on common code derived from the modular code repository may provide useful information for the development of the second adapted modular code.

[0150] Pertaining to the nonlimiting example of Fig. 1, a system is disclosed (e.g., some variations of system 100) that includes a plurality of movable parts. That system includes: a) A plurality of actuators 110 including at least a first actuator (e.g., actuator 110A) of a first type of actuator (e.g., servo motor) and a second actuator (e.g., actuator in charge or rotating drilling head 130) of a second type of actuator. b) A first actuator controller (e.g., 120A) operable to control the first actuator to move a first movable part of the system using a first program of instructions that is executable by the first actuator controller to perform a first method for controlling the first actuator. Most of the first program of instructions (e.g., at least 80%) originates from a source modular code (e.g., the modular code of the modular code repository, such as modular code repository 300). For example, the first program of instructions maybe the first adapted modular code generated in any of the relevant methods above, such as a first adapted modular code 400. c) A second actuator controller (e.g., 120C) operable to control the second actuator to move a second movable part of the system using a second program of instructions executable by the second actuator controller to perform a second method for controlling the second actuator. Most of the second program of instructions (e.g., at least 80%) originates from a source modular code (e.g., the modular code of the modular code repository, such as modular code repository 300). For example, the second program of instructions may be the second adapted modular code generated in any of the relevant methods above, such as a first adapted modular code 400.

[0151] Any feature, detail, variation, alternative, etc. discussed above with respect to any of the systems, methods, and computer program product discussed above may also be implemented with respect to such system including multiple movable parts, mutatis mutandis. Such details are not repeated for the sake of concision.

[0152] Optionally, the first program of instructions includes at least one first control instruction originating from the source modular code which is used for controlling moving of the first movable part by the first actuator and which has no corresponding executable control instruction in the second program of instructions. Additionally (or alternatively), the second program of instructions may optionally include at least one second control instruction originating from the source modular code which is used for controlling moving of the second movable part by the second actuator and which has no corresponding executable control instruction in the first program of instructions.

[0153] The program storage devices which store the adapted modular code (e.g., nontangible memory module 122) are usable by actuator controllers in order to actually control the actuators. A program storage device readable by an actuator controller is disclosed, tangibly embodying a program of instructions executable by the actuator controller to perform a method for controlling an actuator, including the steps of (a) activating the actuator using at least first one control instruction adapted from a source modular code that includes control instructions for controlling operation of different types of electric actuators by at least one type of drive, wherein the different type ofelectric actuators include the type of the actuator and at least one other type of actuator that is not controlled by the control actuator; wherein the activating of the actuator is executed utilizing a first parametric value of a first parameter, the first parametric value being absent from the source modular code; (b) modifying an activation level of the actuator using at least one second control instruction adapted from the source modular code; wherein the modifying of the activation level of the actuator is executed utilizing a second parametric value of a second parameter, the second parametric value being absent from the source modular code; and / or (c) stopping operation of the actuator using at least one third control instruction adapted from the source modular code; wherein the modifying of the activation level of the actuator is executed utilizing a third parametric value of a third parameter, the third parametric value being absent from the source modular code.

[0154] Optionally for such a program storage device, the activating of the actuator, the modifying an activation level of the actuator, and the stopping of the operation of the actuator may all be based on control instructions adapted from the source modular code that excludes any parametric values for the first parameter, for the second parameter, and for the third parameter.

[0155] Optionally for such a program storage device, the program of instructions executable by the actuator controller to perform the method for controlling the actuator includes code of which at least 80% originates from the source modular code.

[0156] Any feature, detail, variation, alternative, etc. discussed above with respect to any of the systems, methods, and computer program product discussed above may also be implemented with respect to such a program storage device, mutatis mutandis. Such details are not repeated for the sake of concision.

[0157] Referring to any of the systems, methods, and computer program products discussed above, it is noted that these systems, methods, and computer program products may be implemented for many reasons and in many use cases, such as (but not limited to): a) When short development time is needed for a specific actuator and / or actuator controller; e.g., while generating the adapted modular code, e.g., to a large degree, by customizing by selecting and / or blending common core / source code building blocks of the modular code repository.b) When higher software reliability is paramount (fewer bugs, higher test coverage); e.g., by adding and / or removing HW specific features without affecting the verified and validated Common Core / Source Code. c) When simulation is needed without the hardware being available, or when simulation is required as an integrated feature of the operational actuator controller. For example, simulation of mechanical load and / or simulated motor (electrical model), which allows running / testing the virtual motor controller / drive in a virtual environment in addition to real world test (i.e., real motor and load). d) When fast porting and adaptation to new hardware is required. e) When uniform user experience (e.g., same look and feel) is needed across different hardware platforms. For example, the same or similar command set, the same or similar graphic UI (GUI), and so on.

[0158] While the embodiments described above are provided as examples, it should be understood that various modifications and substitutions may be made without departing from the scope of the invention as defined in the appended claims.

Claims

CLAIMS1. A method for programming a drive of an actuator, the method comprising: obtaining a modular code repository stored on a nontangible memory module, the modular code repository comprising control instructions for controlling operation of different types of electric actuators by at least one type of drive; wherein the control instructions comprise at least instructions for: (a) actuator activation, (b) actuator stopping of operation, (c) actuator activation level modification, and (d) offline simulation for simulating on a computer one or more of the following without physical hardware: behaviors of the different types of electric actuators when controlled by an actuator controller, load simulation, and / or I / O simulation; based on the modular code repository, generating an adapted modular code for controlling at least one actuator of a selected type of actuator out of the different types of actuators, the adapted modular code comprises at least: an executable control instruction of the modular code repository, suitable for the type of actuator; a parametric component which includes information for adapting the executable control instruction to the at least one actuator; wherein at least one other control instruction of the modular code repository is unexecutable by executing the adapted modular code; and performing offline simulation of the adapted modular code, and upon successful offline simulation providing the adapted modular code to the actuator controller which controls an operational actuator of the selected actuator type, for executing parts of the adapted modular code at least in order to: (a) activate the operational actuator; (b) modify activation level of the operational actuator; and / or (c) stop operation of the operational actuator.

2. The method according to claim 1, wherein the generating comprises importing a bulk of code of the modular code repository to the adapted modular code, the importing comprising excluding the other control instructions from the adapted modular code and keeping the executable control instruction.

3. The method according to any one of the preceding claims, wherein the generating comprises importing a bulk of code of the modular code repository to the adaptedmodular code, the importing comprising disabling the other control instructions and enabling the executable control instruction by adding a control-instruction enablement parameter value to the imported bulk of code.

4. The method according to any one of the preceding claims, wherein the offline simulation comprises instructions for offline simulation of electronic components of the different types of electric actuators, electronic components of the drive, transmission gears, and / or electric cables connecting between the drive and the different types of electric actuators.

5. The method of claim 4 wherein the simulation module is configured for simulating behaviors of the different types of actuation units (actuators) when controlled by actuator controller, wherein the generating comprises including in the adapted modular code simulation code for simulation of the type of actuator and rendering simulation code for simulating behavior of at least one other type of actuator unexecutable by the adapted modular code.

6. The method of claim 4 or 5 wherein the simulation module is configured for simulating one or more of the following: electronic components of the actuator; electronic components of the control drive; transmission gears; and / or electric cables connecting between the control drive and the actuator.

7. The method according to any one of the preceding claims, wherein the modular code repository comprises instructions for implementation of real time functionality in each of the different types of actuators, comprising instructions for: control loops, homing, and real time parts of fieldbus.

8. The method according to any one of the preceding claims, wherein the modular code repository comprises instructions for implementation of features comprising at least two features out of: fieldbus, commutation, motor feedback, hardware interfaces.

9. The method according to any one of the preceding claims, wherein the parametric component comprises hardware specific parameters not included in the modular code repository, pertaining to at least two out of: hardware specific timers, communication interface, encoder interface, memory management.

10. The method according to any one of the preceding claims, wherein the parametric component comprises product specific parameters that pertain to a specific type of actuator and which are not included in the modular code repository, the productspecific parameters pertaining to at least two out of: chip reset procedure, product specific interfaces, adjustment to timing .

11. The method according to any one of the preceding claims, wherein the generating comprises including in the adapted modular code additional control instructions that are absent from the modular code repository, to implement actuator functions that are not enabled by the modular code repository, wherein the additional control instructions implement interfaces comprised in the modular code repository.

12. The method according to any one of the preceding claims, wherein the control instructions comprises instructions for controlling operation of the actuator by the actuation unit controller to execute at least one of the following actions: moving an electric motor, moving a robotic arm, modifying rotation speed of a drilling head, and retracting a pneumatic piston, wherein the generating comprises generating the adapted modular code for controlling an electric motor, wherein the adapted modular code is unexecutable for controlling rotation speed of drilling heads and for retracting of a pneumatic piston.

13. The method according to any one of the preceding claims, further comprising: generating a second adapted modular code for controlling at least one second actuator of the selected type, the second adapted modular code comprises at least: (a) the executable control instruction; and / or (b) a second parametric component which includes information for adapting the executable control instructions to the second actuator; wherein at least one control instruction of the modular code repository is unexecutable by the second adapted modular code; and providing the second adapted modular code to an actuator controller which controls a second actuator, for executing parts of the second adapted modular code at least in order to: (a) activate the second actuator; (b) modify activation level of the second actuator; and / or (c) stop operation of the second actuator.

14. The method of claim 13, wherein the second parametric component comprises different parameter values than the parametric component.

15. The method of claim 13 or 14, wherein the adapted modular code, when executed by a suitable actuator controller, causes the suitable actuator controller to emit a first electric signal for modifying a state of the actuator from a first state to a secondstate, wherein the second adapted modular code when executed by a compatible actuator controller causes the compatible actuator controller which controls the second actuator to emit a second electric signal for modifying a state of the actuator from the first state to the second state, wherein an electric magnitude of the first electric signal is at least 10% greater or smaller than an electric magnitude of the second electric signal, the electric magnitude selected from a group of electric magnitudes consisting of: voltage, current, duty cycle, and pulse width.

16. The method of any one of claims 13 to 15, comprising: controlling the actuator by executing instructions of the adapted modular code, the executing comprising executing the executable control instruction based on the parametric component to induce motion of an industrial equipment module mechanically coupled to the actuator; subsequently, disconnecting the mechanical coupling of the actuator from the industrial equipment module; subsequently, mechanically coupling the second actuator to the industrial equipment module; and afterwards, controlling the second actuator by executing the parts of the second adapted modular code comprising at least executing the executable control instruction based on the second parametric component to induce subsequent motion of the industrial equipment module.

17. The method of any one of claims 13 to 16, wherein a code instructory portion of the adapted modular code and a second code instructory portion of the second adapted modular code are at least 90% Similar.

18. The method according to any one of claims 1 to 12, further comprising: generating a second adapted modular code for controlling at least one second actuator of a second type out of actuator selected out of the different types of actuators, the second adapted modular code comprises at least: a second executable control instruction of the modular code repository, suitable for the second type of actuator; and / or a second parametric component which includes information for adapting the executable control instructions to the second actuator;wherein at least one second unrequired control instruction of the modular code repository is unexecutable by the second adapted modular code; and providing the adapted modular code to an actuator controller which controls a second operational actuator of the second actuator type, for executing parts of the adapted modular code at least in order to: (a) activate the second operational actuator, (b) modify activation level of the second operational actuator, and / or (c) stop operation of the second operational actuator.

19. A program storage device readable by an actuator controller, tangibly embodying a program of instructions executable by the actuator controller to perform a method for controlling an actuator, comprising the steps of: activating the actuator using at least first one control instruction adapted from a source modular code that comprises control instructions for controlling operation of different types of electric actuators by at least one type of drive, wherein the different type of electric actuators comprise the type of the actuator and at least one other type of actuator that is not controlled by the control actuator; wherein the activating of the actuator is executed utilizing a first parametric value of a first parameter, the first parametric value being absent from the source modular code; modifying an activation level of the actuator using at least one second control instruction adapted from the source modular code; wherein the modifying of the activation level of the actuator is executed utilizing a second parametric value of a second parameter, the second parametric value being absent from the source modular code; and stopping operation of the actuator using at least one third control instruction adapted from the source modular code; wherein the modifying of the activation level of the actuator is executed utilizing a third parametric value of a third parameter, the third parametric value being absent from the source modular code, wherein at least one of the first, second or third, control instructions is further adapted based on offline simulation of at least one of the following:behaviors of the different types of electric actuators when controlled by an actuator controller, load simulation, and / or I / O simulation.

20. The program storage device according to claim 19, wherein the activating of the actuator, the modifying of an activation level of the actuator, and the stopping of the operation of the actuator are based on control instructions adapted from the source modular code that excludes any parametric values for the first parameter, for the second parameter, and for the third parameter.

21. The program storage device of claim 19 or 20, wherein the program of instructions executable by the actuator controller to perform the method for controlling the actuator comprises code of which at least 80% originates from the source modular code.

22. A system comprising a plurality of movable parts, the system comprising: a plurality of actuators comprising at least a first actuator of a first type of actuator and a second actuator of a second type of actuator; a first actuator controller operable to control the first actuator to move a first movable part of the system, using a first program of instructions executable by the first actuator controller to perform a first method for controlling the first actuator, wherein at least 80% of the first program of instructions originates from a source modular code; a second actuator controller operable to control the second actuator to move a second movable part of the system, using a second program of instructions executable by the second actuator controller to perform a second method for controlling the second actuator, wherein at least 80% of the second program of instructions originates from the source modular code; wherein the first program of instructions comprises at least one first control instruction originating from the source modular code which is used for controlling moving of the first movable part by the first actuator and which has no corresponding executable control instruction in the second program of instructions; wherein the second program of instructions comprises at least one second control instruction originating from the source modular code which is used for controlling moving of the second movable part by the second actuator andwhich has no corresponding executable control instruction in the first program of instructions.

Images