CN116346531B

CN116346531B - Adaptation method based on CANBUS communication protocol

Info

Publication number: CN116346531B
Application number: CN202310603337.0A
Authority: CN
Inventors: 邹欣珏; 黄渊海; 刘强; 王正
Original assignee: Yunnan Free Trade Zone Weihang Intelligent Technology Co ltd
Current assignee: Yunnan Free Trade Zone Weihang Intelligent Technology Co ltd
Priority date: 2023-05-26
Filing date: 2023-05-26
Publication date: 2023-09-22
Anticipated expiration: 2043-05-26
Also published as: CN116346531A

Abstract

The application provides an adaptation method based on CANBUS communication protocol, comprising the following steps: the integrated electronic equipment using CANBUS as a communication protocol specifically comprises: writing CANBUS protocol of parameter configuration attribute, function execution attribute and feedback parameter attribute related to electronic equipment control into configuration file according to abstract rule, and automatically analyzing configuration file by abstract configuration mechanism; the user only needs to write the parameter configuration attribute, the function execution attribute and the feedback parameter attribute related to the control of the electronic equipment into the configuration file according to the abstract rule, the abstract configuration mechanism automatically analyzes the configuration file and organizes the protocol command, thereby realizing the corresponding control of the function provided by the electronic equipment and the collection of related feedback information, and one mechanism is suitable for various protocols and has strong adaptability.

Description

Adaptation method based on CANBUS communication protocol

Technical Field

The application relates to the technical field of electric digital data processing, in particular to an adaptation method based on a CANBUS communication protocol.

Background

The CAN bus is a bus standard intended to allow a microcontroller and a device to communicate with each other's applications without a host. It is a message-based protocol originally designed for multiplexing and parallel communication and control within automobiles, and is now widely used in many electronic devices.

For each device, the data in the frame is serial transmission, and the length of the data carried by each frame of communication packet is 8 bytes;

different manufacturers have respective communication protocols due to the difference of technical paths, and if the casbus protocol equipment products of a plurality of manufacturers are used for an integrator, the protocol definition and rules of each equipment need to be understood, codes are written for adaptation, and extra workload is added.

Disclosure of Invention

In view of the foregoing, it is desirable to provide an adaptation method based on CANBUS communication protocol, so as to solve or alleviate the technical problems existing in the prior art, and at least provide a beneficial choice.

The technical scheme of the embodiment of the application is realized as follows: an adaptation method based on CANBUS communication protocol, comprising:

the integrated electronic equipment using CANBUS as a communication protocol specifically comprises:

writing the CANBUS protocol of the parameter configuration attribute, the function execution attribute and the feedback parameter attribute related to the control of the electronic equipment into a configuration file according to abstract rules, automatically analyzing the configuration file by adopting an abstract configuration mechanism, organizing a protocol command, and meeting the function control of the CANBUS communication protocol electronic equipment;

wherein, the data scope of abstract configuration is defined to 8Bytes of the data packet, and a single Byte is defined as metadata;

the abstract process of writing the CANBUS protocol of the parameter configuration attribute, the function execution attribute and the feedback parameter attribute related to the control of the electronic equipment into the configuration file according to the abstract rule comprises the following steps:

setting general rules: and uniformly disassembling different communication protocols corresponding to different manufacturers, brands and models into metadata, namely abstracting the metadata by a rule with commonality, disassembling the metadata into the metadata of a general rule defined by the mechanism, wherein the metadata has corresponding attribute of the rule, and reversely organizing the metadata based on the metadata and the corresponding rule attribute thereof to form a complete corresponding communication protocol when a specific protocol is used.

Further preferred is: the configuration file is stored in a yaml form, and hierarchical relations among all levels of entries are achieved in a retracted mode.

Further preferred is: the abstract rule definition comprises an instruction classification, a data format definition, a basic abstract unit structure definition, an init_commands/deactive_commands definition, a command definition and a feedback definition;

the instruction classification comprises sending an instruction class to the electronic equipment and receiving a driver feedback instruction class;

the basic abstract element structure definition includes a condition structure, a shift structure, a static instruction structure, a dynamic instruction structure, a feedback byte structure, and a feedback parameter structure.

Further preferred is: the init_commands/deactive_commands/static_commands definitions are used for different device control logic, providing a clearer protocol configuration;

the method specifically comprises the steps of initializing the electronic equipment, and executing operation when the equipment system exits or is closed, and sending a conventional periodic instruction of the electronic equipment.

Further preferred is: the command defines a real-time instruction for controlling the device to execute functions, the data content comprises each function operation instruction defined by the controlled device, the electronic device can be a motor, a motor driver is taken as an example, the group of instructions are used for controlling the real-time instruction for motor movement, the data content can comprise a motor movement direction, a motor movement rotating speed, motor movement acceleration/deceleration, motor enabling and the like, the real-time instruction for motor movement has the largest change among various manufacturers, brands and models, and each Byte has a dependency relationship, so that each Byte in 8Bytes is defined by rules.

Further preferred is: the feedback defines real-time feedback parameters for receiving the electronic equipment;

the reading of the feedback parameters is based on a feedback parameter segment configured by a user, the feedback parameter segment supports the user to configure any number of parameters, and starts with a "-parameter" keyword, including a base address attribute, and a shift attribute of each byte in 8bytes of feedback data, and taking a motor driver as an example, the feedback parameters can be defined as:

"read_rpm" motor real-time speed feedback, "read_encoder" motor encoder real-time feedback, "read_state" motor or drive status real-time feedback, "read_soc" battery power information real-time feedback.

Further preferred is: the abstract rules include predefined parameters, protocol to abstract configuration, and abstract configuration reorganization into protocols.

Further preferred is: the protocol-to-abstract configuration comprises a configuration instruction of the equipment, a dynamic execution instruction of the equipment and a real-time feedback instruction of the equipment;

wherein:

the configuration instructions of the device are configured using the static abstract instruction "init_commands"/"static_commands" definition;

the dynamic execution instructions of the device are configured using dynamic abstract instruction "commands" definitions;

the real-time feedback instructions of the device are configured using a feedback abstract instruction "feedback" definition.

Further preferred is: the reorganization of the abstract configuration into a protocol comprises:

the protocol reorganization of the mechanism comprises reverse operation on the rules by defining the data structures stored in the definition units in the form of rules through the basic abstract unit structure, and reorganizing the communication data frames specified for the specific CANBUS equipment according to the data structure field attribute of each definition unit.

Further preferred is: the reverse operation of the rule, according to the data structure field attribute of each definition unit, reorganizes and reconstructs the communication data frame specified by the specific CANBUS equipment, and specifically includes:

s1, determining whether the value is of a numerical value type, and executing the following operations according to a determination result:

if yes, reconstructing a communication data frame;

if not, entering the next step;

s2, determining whether the parameter is a predefined parameter, and executing the following operations according to a determination result:

if not, searching corresponding parameters according to the name, and executing the following operations according to the searching result:

if yes, entering the next step;

the corresponding parameters are not existed, and the abnormal termination is carried out;

s3, determining whether the attribute is a condition attribute, and executing the following operations according to a determination result:

if not, entering the next step;

comparing the communication data frame with the target data, and reconstructing the communication data frame after comparing the communication data frame with the target data;

s4, determining whether the attribute is a movement attribute, and executing the following operations according to a determination result:

moving a specified bit number to a specified direction according to bits and dir to reconstruct a communication data frame;

and if not, reconstructing the communication data frame.

By adopting the technical scheme, the embodiment of the application has the following advantages:

the mechanism of the abstract configuration file realizes the integration of the electronic equipment taking the CANBUS as the communication protocol, does not need to write codes, supports CAN and CANopen, and only needs to write parameter configuration attributes, function execution attributes and feedback parameter attributes related to the control of the electronic equipment into the configuration file according to abstract rules, so that the abstract configuration mechanism CAN automatically analyze the configuration file and organize protocol commands, thereby realizing the corresponding control of the functions provided by the electronic equipment and the acquisition of related feedback information.

The foregoing summary is for the purpose of the specification only and is not intended to be limiting in any way. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features of the present application will become apparent by reference to the drawings and the following detailed description.

Drawings

In order to more clearly illustrate the embodiments of the application or the technical solutions in the prior art, the drawings that are necessary for the description of the embodiments or the prior art will be briefly described, it being obvious that the drawings in the following description are only some embodiments of the application and that other drawings can be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a flow chart of an adaptation method of the present application;

FIG. 2 is a schematic diagram of the present application for organizing the content of data packets;

FIG. 3 is a flow chart of a communication protocol of the present application;

FIG. 4 is a schematic diagram of CANopen command control according to an embodiment of the present application;

FIG. 5 is a schematic diagram of PDO communication parameters according to an embodiment of the application;

FIG. 6 is a diagram illustrating PDO mapping parameters according to an embodiment of the application;

FIG. 7 is a schematic diagram of a TPDO0 configuration routine in accordance with an embodiment of the present application;

fig. 8 is a schematic diagram of NMT node status according to an embodiment of the present application;

fig. 9 is a schematic diagram of an NMT node status switch command according to an embodiment of the present application;

FIG. 10 is a schematic diagram of a speed mode configuration according to an embodiment of the present application;

fig. 11 is a schematic diagram of an SDO format definition and an explanation of a configuration into a speed mode in a communication protocol description according to an embodiment of the present application.

Detailed Description

Hereinafter, only certain exemplary embodiments are briefly described. As will be recognized by those of skill in the pertinent art, the described embodiments may be modified in various different ways without departing from the spirit or scope of the present application. Accordingly, the drawings and description are to be regarded as illustrative in nature and not as restrictive.

Embodiments of the present application will be described in detail below with reference to the accompanying drawings.

As shown in fig. 1-2, an embodiment of the present application provides an adaptation method based on CANBUS communication protocol, including:

the electronic device using CANBUS as a communication protocol is integrated, the electronic device such as a motor driver, and the adaptation method mechanism is not only adapted to the motor driver, but also can be applied to any device using CANBUS, and specifically comprises the following steps:

the electronic device may be a motor, which is described below in terms of a motor and a motor driver;

as shown in fig. 2, the packet length of the standard CAN2.0 is 64bits (8 Bytes), and other parts of data are automatically completed by the transmission layer, that is, communication between CANBUS devices is realized, and a user only needs to organize the content of the packet:

abstract configured data scope is defined to 8Bytes of the data packet, and single Byte is defined as metadata;

the abstract process of writing the CANBUS protocol of the motor control related parameter configuration attribute, the function execution attribute and the feedback parameter attribute into the configuration file according to the abstract rule comprises the following steps:

setting general rules: the abstract process is to set a general rule, uniformly disassemble different communication protocols corresponding to different manufacturers, brands and models into metadata, wherein the metadata has corresponding attributes of the rule, and reversely organize the metadata based on the metadata and the corresponding rule attributes thereof to form a complete corresponding communication protocol when a specific protocol is used.

The motor control related parameter configuration attributes, function execution attributes, feedback parameter attributes may include, for example, control attributes, motor rotation, motor encoder position feedback, motor speed feedback.

Specific: the abstract general rule configuration file is stored in a yaml form, and the form realizes the hierarchical relation among the items of each level in a retracting way; while supporting data types: the application relates to a vector, map, which can completely cover the logical organization of data, and the application refers to a yaml file for storing general rules, which is collectively named as can_protocol.

Specific: abstract rule definitions include instruction classification, data format definition, basic abstract element structure definition, init_commands/reactive_commands/static_commands definition, command definition, and feedback definition;

the instruction classification comprises sending an instruction class to the motor and receiving a feedback instruction class of the driver;

the data format definition is as follows:

the basic abstract unit structure definition includes a condition structure, a shift structure, a static instruction structure, a dynamic instruction structure, a feedback byte structure, and a feedback parameter structure:

specifically, the condition structure is responsible for comparing the predefined data specified by the user or the numerical data specified by the user with the target data, and taking the data corresponding to the comparison result interval as a result, wherein the combination comparison interval for the instruction is divided into three sections: the set value is smaller than the target data, equal to the target data and larger than the target data, and each interval is provided with the corresponding set value, and the set value is set by a user through a rule configuration file. The data structure is defined as:

structCondition

{

Condition()=default;

int8_t target_{0};

std::shared_ptr<uint8_t>less_{nullptr};

std::shared_ptr<uint8_t>equal_{nullptr};

std::shared_ptr<uint8_t>great_{nullptr};

};

the shift structure is responsible for setting shift operation attributes corresponding to data bytes and is used for analyzing and reconstructing the data 'size end' in the instruction combination process, and the data structure is defined as follows:

structShift

{

Shift()=default;

enum{SHIFT_LEFT=0,SHIFT_RIGHT};

uint8_t bits_{0};

uint8_t dir_{SHIFT_LEFT};

};

wherein "bits_" sets the number of bits moved, such as 8 bits, 16 bits, etc., and "dir_" sets the direction of movement, the higher bit moves to the left before, and vice versa;

the static instruction structure is responsible for the configuration of the attribute and data of the static instruction: name, CANBUS complete 8bytes data, base address, absolute base address, data segment variation variable, inter-instruction delay. The data structure is defined as:

classStaticCommand

{

public:

StaticCommand()=default;

~StaticCommand()=default;

public:

std::stringname_;

std::vector<uint8_t>data_;

uint32_tbase_addr_{0};

boolis_absolute_base_{false};

std::map<std::string,uint8_t>variables_map_;

uint16_tdelay_{0};

};

if the base address is an absolute base address, the identification address is base address data configured by a user; if the relative base address is the relative base address, the identification address is the sum of the base address data configured by the user and the device ID;

the dynamic instruction structure is responsible for the configuration of the attributes and data of the dynamic instructions: a data source, a condition unit of data bytes (bytes), a shift unit of data bytes (bytes), whether absolute value data is present or not. The data structure is defined as:

classCommandByte

{

public:

CommandByte()=default;

~CommandByte()=default;

public:

std::anysource_;

std::shared_ptr<Condition>cond_{nullptr};

std::shared_ptr<Shift>shift_{nullptr};

boolis_absolute_{false};

};

wherein the "data source" uses generic data, which can be configured as numeric data (integer, floating point) and also as string type data, which is used to specify a data name predefined by an abstract mechanism;

the feedback byte structure is responsible for attribute configuration of the feedback data bytes: byte sequence number, byte shift unit. The data structure is defined as:

class FeebackByte

{

public:

FeebackByte() = default;

~FeebackByte() = default;

public:

uint8_t index_{ 0 };

Shift shift_;

};

the feedback parameter structure is responsible for supporting the configuration of the attributes and data of the parameters fed back by the CANBUS protocol device: base address, absolute base address, data segment of 8bytes at maximum, multiplication factor, addition factor. The data structure is defined as:

class FeedbackParam

{

public:

FeedbackParam() = default;

~FeedbackParam() = default;

public:

uint32_t base_addr_{ 0 };

bool is_absolute_base_{ false };

std::vector<FeebackByte> bytes_;

double multiplier_{ 1.0 };

double additioner_{ 0.0 };

};

init_commands/deactive_commands/static_commands define that the 3 sets of instructions have the same field definition, differing only in their respective presence in the different device control logic for providing a clearer protocol configuration;

an initialization command set (init_commands) is responsible for the initialization work of the motor, and is commonly used for CANopen, and if a brand driver exists, a user needs to control the switching of the NMT state by himself; some feedback commands of the driver need to be implemented after being configured by PDO. Both NMT and PDO instructions typically have variables to enable configuration of specified variables, such as switching of states in NMT requires the variables to store a particular variable, while also requiring a corresponding state's slave ID number. Thus, the 3 sets of instructions need to be able to configure an all static protocol, as well as to accommodate a dynamic protocol with variables. The deactive_commands are responsible for operations performed when the equipment system is exited or shut down, such as setting the motor speed to 0, disabling the motor, etc. The static_commands are responsible for regular periodic instruction transmission of the motor, for example, the SOC information is usually transmitted after the request instruction is received, in this case, the instruction configuration of the request SOC can be classified to the static_commands, and the abstract mechanism automatically and periodically executes the instruction;

the field definition is as follows:

the command defines a real-time instruction for controlling the device to execute functions, and the data content comprises various function operation instructions defined by the controlled device, and takes a motor driver as an example, the motor movement direction, the motor movement rotating speed, the motor movement acceleration/deceleration, motor enabling and the like; the real-time instruction of the motor in motion has the largest change among various manufacturers, brands and models, and the various Bytes have dependency relations, so that each Byte in 8Bytes is defined and acted on by rules;

the fields are defined as:

the feedback defines real-time feedback parameters for receiving the motor, the feedback parameters are predefined for 4 variables, namely real-time rotational speed feedback of the motor of 'read_rpm', real-time feedback of the motor encoder of 'read_encoder', real-time feedback of the state of the motor or the driver, and real-time feedback of the battery power information of 'read_soc', meanwhile, the parameters are just the predefined parameters built in the embodiment, when the mechanism is extended to other devices, the parameters beyond the predefined parameters appear, after the user adds new predefined parameters in the configuration file, the software of the mechanism still supports reading and communication without rewriting the codes of the mechanism, but the software of an application layer needs to be developed, but the development is only limited to extracting corresponding data from the mechanism data by using the new predefined parameter name as key;

the fields are defined as:

in this embodiment, specific: the abstract rules include predefined parameters, protocol-to-abstract configuration, and abstract configuration reorganization into protocols.

In this embodiment, specific: the protocol-to-abstract configuration comprises configuration instructions of the equipment, dynamic execution instructions of the equipment and real-time feedback instructions of the equipment;

wherein:

device protocols can generally be divided into three general categories: configuration instructions of equipment, dynamic execution instructions of the equipment and real-time feedback instructions of the equipment;

the configuration instruction of the device is configured by using the definition of a static abstract instruction 'init_commands' and 'static_commands', and 8bytes of a data segment of a protocol can be completely configured into the data segment (data) of the static abstract instruction; if the protocol involves a change in device ID, then a variable control segment (variables) of the static abstract instruction is used to set the change in the corresponding byte-setting device's dynamic execution instruction is configured using the dynamic abstract instruction "commands" definition, which requires that 8bytes of the CANBUS data segment be configured one by one, unlike the static abstract instruction. If the byte data is the data predefined by the mechanism, configuring a corresponding predefined data name in a field 'source', and configuring the compared target data with the specified target data through a condition field 'condition'; if the byte data is of a numerical value type, directly configuring the numerical value data in a field source; for predefined data, when the number of bytes is more than 1 byte, the data size end shift attribute corresponding to the device protocol is configured through a field 'shift', the real-time feedback instruction of the device is configured by using the definition of a feedback abstract instruction 'feedback', the feedback instruction configuration focuses on the sequence number in 8bytes of the data segment specified by the corresponding CANBUS device protocol, the sequence number is configured into a field 'bytes', and meanwhile, the identification address of the feedback data is configured into a field 'base_addr', and the absolute and relative identification addresses can be configured by using the field 'absolute_base'.

Specific: the reorganization of abstract configuration into a protocol includes:

The reverse operation of the rule, according to the data structure field attribute of each definition unit, reorganizes and reconstructs the communication data frame specified by the specific CANBUS device, as shown in fig. 3, specifically including:

if yes, reconstructing a communication data frame;

if not, entering the next step;

if yes, entering the next step;

if not, entering the next step;

and if not, reconstructing the communication data frame.

Examples

The application also provides an embodiment for applying the method based on the embodiment, which is as follows:

CANopen driver

The CANopen driver protocol is mostly changed in a static instruction part, and the model ZLAC8030L of the CANopen driver of the Mitsubishi technology is taken as an example for the example, so that NMT state machine control, PDO event triggering feedback setting, real-time motor control instruction and feedback parameters are mainly described;

1.1NMT State and mode setting

Fig. 11 is a schematic diagram illustrating SDO format definition and speed mode configuration in the driver communication protocol specification:

for example, the motor is rotated according to parameters (acceleration time 100ms, deceleration time 100ms, target speed 60 r/min). Assuming that the driver slave station number is 1, the CANopen instruction control is as shown in FIG. 4;

the state machine is started, the mode setting can be all static instructions, and the acceleration/deceleration of the motor in most use scenes can be set to be a fixed value, so that the speed mode configuration instruction of fig. 10 can be used as an initialization instruction group; also according to the SDO definition, the base address is 0x600, the device ID can be set by the user through the dial switch on the drive, the dial switch is set to 1 in FIG. 4, so the master address is 0x601

1.1.1 abstract configuration files can be correspondingly organized into

init_commands:

- param: 'init state machine'

data: [0x2b, 0x40, 0x60, 0x00, 0x00, 0x00, 0x00, 0x00]

base_addr: 0x600

absolute_base: false

delay: 1 # ms

- param: 'acc time'

data: [0x23, 0x83, 0x60, 0x00, 0x64, 0x00, 0x00, 0x00] # 100 ms

base_addr: 0x600

absolute_base: false

delay: 1 # ms

- param: 'dec time'WHI

data: [0x23, 0x84, 0x60, 0x00, 0x64, 0x00, 0x00, 0x00] # 100 ms

base_addr: 0x600

absolute_base: false

delay: 1 # ms

- param: 'velocity mode'

data: [0x2f, 0x60, 0x60, 0x00, 0x03, 0x00, 0x00, 0x00]

base_addr: 0x600

absolute_base: false

delay: 1 # ms

- param: 'release motor'

data: [0x2b, 0x40, 0x60, 0x00, 0x06, 0x00, 0x00, 0x00]

base_addr: 0x600

absolute_base: false

delay: 1 # ms

- param: 'enable motor'

data: [0x2b, 0x40, 0x60, 0x00, 0x07, 0x00, 0x00, 0x00]

base_addr: 0x600

absolute_base: false

delay: 1 # ms

- param: 'activate mode'

data: [0x2b, 0x40, 0x60, 0x00, 0x0f, 0x00, 0x00, 0x00]

base_addr: 0x600

absolute_base: false

delay: 1 # ms

1.1.2 Abstract configuration description

The data part is 8Bytes, each Byte corresponds to data in the protocol description screenshot, and since a configuration instruction acts on each independent driver, when a plurality of drivers exist, a target address is determined through a base value and a device ID, the base_addr in the protocol organization is set to be uniform 0x600, and the absorber_base is set to be false, namely, a relative address mode.

1.2 PDO event-triggered feedback settings

Driver PDO definition, configuration definition of PDO:

PDO communication parameters define COB-IDs, transmission types, timing periods, etc. used by the device. The RPDO communication parameters are located at 0x1400 to 0x15FF of the object dictionary index and the TPDO communication parameters are located at 0x1800 to 0x19FF of the object dictionary index. Each index represents a set of communication parameters of a PDO, where the sub-indices point to specific parameters, as shown in fig. 5, and in fig. 5:

the number of sub-indexes is the number of sub-indexes under the index, and the COB-ID is the CANID corresponding to the PDO when transmitting or receiving;

the transmission type is that the product only supports two PDO triggering modes at present;

production prohibition time, which is to restrict the minimum interval of PDO transmission to avoid causing a dramatic increase in bus load:

the timer triggering time is the time of the timer triggering mode of the PDO transmission form defined by the parameter;

fig. 6 is a schematic diagram of PDO mapping parameters, where:

the PDO mapping number is the number of objects mapped under the current index and is the sum mapped under the sub-index 1/2/3/4;

PDO1/2/3/4 is filled in the information of the object dictionary to be mapped, such as index, sub-index and data type;

FIG. 7 is a schematic diagram of a TPDO0 configuration routine;

the event trigger uses TPDO commands, the type of driver can support up to 4 TPDO, each TPDO corresponds to a configuration command address of 0x1800 to 0x1803 (fig. 5), each TPDO addresses 0x1a00 to 0x1a03 (fig. 6) based on the configuration routine in the drive specification, can be automatically uploaded when the configuration motor encoder changes, and the parameter address in the illustrated example is changed from 0x2048 to 0x6064.

1.2.1 The abstract configuration file can be correspondingly organized into

- param: 'clear PD0'

data: [0x2f, 0x00, 0x1a, 0x00, 0x00, 0x00, 0x00, 0x00]

base_addr: 0x600

absolute_base: false

delay: 1 # ms

- param: 'map to PD0' # encoder value register 6064

data: [0x23, 0x00, 0x1a, 0x01, 0x20, 0x00, 0x64, 0x60]

base_addr: 0x600

absolute_base: false

delay: 1 # ms

- param: 'set PD0 ID' # 18x

data: [0x23, 0x00, 0x18, 0x01, 0x80, 0x01, 0x00, 0x00]

variables: { 4: 'device_addr' }

base_addr: 0x600

absolute_base: false

delay: 1 # ms

- param: 'event trigger mode'

data: [0x2f, 0x00, 0x18, 0x02, 0xfe, 0x00, 0x00, 0x00]

base_addr: 0x600

absolute_base: false

delay: 1 # ms

- param: 'activate PD0'

data: [0x2f, 0x00, 0x1a, 0x00, 0x01, 0x00, 0x00, 0x00]

base_addr: 0x600

absolute_base: false

delay: 1 # ms

- param: 'NMT to operational state'

data: [0x01, 0x00, 0x60]

variables: { 1: 'device_addr' }

base_addr: 0x00

absolute_base: true

delay: 1 # ms

1.2.2 Abstract configuration description

The data portion is 8Bytes, each Byte corresponds to the data in the example screenshot, and since the configuration instruction acts on each independent driver, when there are multiple drivers, the destination address is determined by the base value+the device ID, so in the above protocol organization, except for the last parameter "NMT to operational state", the rest base_addr is set to be uniform 0x600, and the active_base is set to false, that is, the opposite address mode.

NOTE: the parameter "set PD0 ID' # 18x" is also different from the screenshot example in which the ID of TPDO is set to be fixed 0x181, and when we have multiple devices all feeding back at the same time, one ID cannot satisfy the corresponding feedback value that distinguishes between the different devices, so in this example we set TPDO to be the form that the base address 0x180 is added to the driver device ID, and use the "variable" field to input the device ID as a variable, its sequence bit is 4, and the variable is the predefined device ID "device_addr" NOTE: the last parameter in the example, "NMT to operational state", is to initiate the NMT to an operational state, and only after this state is entered, the event trigger mapping PDO can be validated. Fig. 8 and 9 illustrate the state switching of the driver NMT, where the address is 0x00, the start instruction data is 0x01, and the high byte follows the node address (base address+device ID). Under the requirement, the data is 3Bytes, the first Byte is NMT starting instruction 0x01, and the second two are node addresses, 0x600+ device ID; to be able to distinguish between multiple drives, a self-segment "variable" is introduced to add a device ID that is ordered 1 in the "variable" field because of the high byte preceding provision; the field "base_addr" is set to 0x00 based on the address that is transmitted by the NMT being specified to be 0x0, and the absolute address, i.e., the field "absolute_base", is set to true;

1.3 Motor real-time control Command

Reviewing the speed mode configuration in the NMT state and mode setting, setting a target speed of 60rpm, and controlling the motor in real time by the instruction;

for example, the motor is rotated according to parameters (acceleration time 100ms, deceleration time 100ms, target speed 60 r/min). Assuming that the driver slave station number is 1, the canopen instruction control is as described in fig. 10;

1.3.1 The abstract configuration file can be correspondingly organized into

base_addr_command: 0x600

command:

- byte: 0

source: 0x23

- byte: 1

source: 0xff

- byte: 2

source: 0x60

- byte: 3

source: 0x00

- byte: 4

source: 'rpm'

- byte: 5

source: 'rpm'

shift:

bits: 8

dir: 'right' # or 'left'

- byte: 6

source: 'rpm'

shift:

bits: 16

dir: 'right' # or 'left'

- byte: 7

source: 'rpm'

shift:

bits: 24

dir: 'right' # or 'left'

1.3.2 Abstract configuration description

The definition of command refers to that the real-time control instruction uses each Byte as one metadata to abstract the protocol, and the first 4Bytes in the 8Bytes data are fixed values based on the protocol description: the first four Bytes of the abstract protocol of the organization are directly of a numerical value type, 4Bytes are of a target rotating speed controlled in real time after the source is filled with corresponding data, the rotating speed is a predefined variable of rpm after the source is filled with high Bytes, the moving bits through shift and the moving direction dir are set in a shifting mode, and the high Bytes sequentially move the high bits of the rotating speed of rpm to the right by the bit number of the corresponding Bytes after the high Bytes are filled with the predefined variable of rpm.

1.4 Real-time feedback parameters of motor

The dynamic driving layer predefines 4 feedback variables, namely 'read_rpm' motor real-time rotating speed feedback, 'read_encoder' motor encoder real-time feedback, 'read_state' motor or driver state real-time feedback, 'read_soc' battery power information real-time feedback, in the example, only encoder values need to be read, so that only the predefined variable 'read_encoder' is configured, namely, the position of the motor encoder is set as event change trigger in the section 'PDO event trigger feedback setting', the node address is set as 0x180+ equipment ID, when the encoder values change, the node address of returned data is 0x180+ equipment ID, and the encoder data occupies 4Bytes and is positioned at the back.

1.4.1 The abstract configuration file can be correspondingly organized as:

feedback:

- param: 'read_encoder'

base_addr: 0x180

absolute_base: false

bytes: { 0: 0, 1: 8, 2: 16, 3: 24 }

1.4.2 Abstract configuration description

The field "param" fills out the predefined variable "read_encoder", the field "base_addr" is 0x180 and is in the form of base address+device ID, so the field "buffer_base" is set to false, the encoder data occupies 4bytes, and the field "bytes" is set with the corresponding bit number corresponding to the corresponding bit sequence and its shifted Byte using map format after the high order.

The mechanism of the abstract configuration file realizes the integration of the motor using the CANBUS as a communication protocol, does not need to write codes, and supports CAN and CANopen. The user only needs to write the parameter configuration attribute, the function execution attribute and the feedback parameter attribute related to the motor control into the configuration file according to the abstract rule. The abstract configuration mechanism automatically analyzes the configuration file and organizes the protocol commands, thereby realizing the corresponding control of the functions provided by the motor and the collection of relevant feedback information.

The foregoing is merely illustrative of the present application, and the present application is not limited thereto, and any person skilled in the art will readily recognize that various changes and substitutions are possible within the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. An adaptation method based on CANBUS communication protocol, comprising:

writing parameter configuration attributes, function execution attributes and feedback parameter attributes related to electronic equipment control into configuration files according to abstract rules, automatically analyzing the configuration files by adopting an abstract configuration mechanism, organizing protocol commands, and meeting the function control of CANBUS communication protocol electronic equipment;

writing the parameter configuration attribute, the function execution attribute and the feedback parameter attribute related to the control of the electronic equipment into the configuration file according to the abstract rule comprises the following steps:

setting general rules: the method comprises the steps of uniformly disassembling CANBUS communication protocol data frames corresponding to different manufacturers, brands or models into metadata, wherein the metadata have regular corresponding attributes, and reversely organizing the metadata based on the metadata and the corresponding regular attributes to form a complete corresponding communication protocol data frame when the metadata are used specifically;

abstract rule definitions include instruction classification, data format definition, basic abstract element structure definition, init_commands/reactive_commands/static_commands definition, command definition, and feedback definition;

the basic abstract unit structure definition comprises a condition structure, a shift structure, a static instruction structure, a dynamic instruction structure, a feedback byte structure and a feedback parameter structure;

the condition structure is responsible for comparing the predefined data specified by the user or the numerical data specified by the user with the target data, and taking the data corresponding to the comparison result interval as a result;

the shift structure is responsible for setting shift operation attributes of corresponding data bytes;

the static instruction structure is responsible for the attribute of the static instruction and the configuration of the data of the static instruction;

the dynamic instruction structure is responsible for the attribute of the dynamic instruction and the configuration of the data of the dynamic instruction;

the feedback byte structure is responsible for attribute configuration of feedback data bytes;

the feedback parameter structure is responsible for supporting the attribute of the feedback parameter of the CANBUS protocol equipment and the configuration of the data thereof;

the init_commands are an initialization instruction group;

the deactive_commands are an ending instruction group;

the static_commands are static instruction groups;

the init_ commands, deactive _commands and the static_commands define the initialization work of the electronic device, the operation executed when the device system exits or is closed and the conventional periodic command transmission of the electronic device;

the command defines a real-time instruction for controlling the device to execute a function, and the data content comprises each function operation instruction defined by the controlled device;

the feedback defines real-time feedback parameters for receiving the electronic equipment;

the reading of the feedback parameters is based on a feedback parameter segment configured by a user, and the feedback parameter segment supports the user to configure any number of parameters, and starts with a param keyword, wherein the parameter keyword comprises a base address attribute and a shift attribute of each byte in 8bytes of feedback data.

2. A CANBUS communication protocol based adaptation method according to claim 1, characterized in that: the configuration file is stored in a yaml form, and hierarchical relations among all levels of entries are achieved in a retracted mode.

3. A CANBUS communication protocol based adaptation method according to claim 1, characterized in that: the abstract rules include predefined parameters, protocol-to-abstract configurations, and abstract configuration reorganization into protocols.

4. A CANBUS communication protocol based adaptation method according to claim 3, characterized in that: the protocol-to-abstract configuration comprises configuration instructions of equipment, dynamic execution instructions of the equipment and real-time feedback instructions of the equipment;

wherein:

the configuration instructions of the device are configured by using static abstract instruction init_commands/static_commands definitions;

the dynamic execution instruction of the device is configured by using a dynamic abstract instruction command definition;

the real-time feedback instructions of the device are configured using a feedback abstract instruction feedback definition.

5. A CANBUS communication protocol based adaptation method according to claim 3, characterized in that: the reorganization of the abstract configuration into a protocol comprises:

the metadata is stored in the data structure of each definition unit in the form of rules through the definition of the basic abstract unit structure, the protocol reorganization of the mechanism comprises the reverse operation on the rules, and the metadata reorganization is reconstructed into communication data frames specified by specific CANBUS equipment according to the data structure field attribute of each definition unit.

6. The method for adapting CANBUS-based communication protocol according to claim 5, wherein: the reverse operation of the rule, according to the data structure field attribute of each definition unit, reconstructs the metadata into the communication data frame specified by the specific CANBUS equipment, and specifically comprises the following steps:

if yes, reconstructing a communication data frame;

if not, entering the next step;

if yes, entering the next step;

if not, entering the next step;

and if not, reconstructing the communication data frame.