Variable pitch servo driver fault recording method

Abstract

The invention discloses a fault recording method for a variable pitch servo driver, and the method can accurately record fault information generated by three chips in the driver, transmits the fault information to a main controller through communication, and stores the fault information in a fault snapshot. The situation that part of fault information is missed when a plurality of faults are generated at the same moment or in one communication period of the main controller and the ARM is avoided, and the accuracy of relevant fault diagnosis of the driver is improved.

Description

Technical Field

[0001] The invention belongs to the technical field of wind turbine control systems, and in particular relates to a fault recording method for a variable pitch servo driver. Background Art

[0002] The pitch control system is the core control system of the wind turbine, which is directly related to the safety of the unit, and the servo drive is the core of the entire pitch control system.

[0003] Driver-related failures are the highest level of pitch control failures. When a general failure occurs in the driver, the pitch control system needs to perform a safe pitch-feathering action to drive the blades back to a safe position. If a serious failure occurs in the driver, the output is shut down and the blade cannot be driven to pitch.

[0004] The main control board of the driver contains multiple chips such as ARM, DSP, ARM chip (CHG) for charger and rectifier control, etc. The chips communicate with each other through the serial port; ARM communicates with the fan main controller through CANOpen, and communicates with the HMI through Modbus. Each chip has a fault judgment based on its own IO and operating status data. Each fault has a corresponding unique fault code. The driver may trigger multiple faults at the same time. However, due to the periodic CANOpen communication characteristics between ARM and the main controller, only one fault code can be sent in each communication cycle. All fault information of the driver needs to be recorded and sent to the main controller through CAN communication. Otherwise, some fault codes will be omitted and cannot be sent to the main controller and saved in the fault snapshot, which cannot truly reflect the fault status of the driver and is not conducive to the fault analysis and troubleshooting of the driver.

[0005] The existing patent (201210393341.0) discloses a system and method for sequentially recording faults of wind turbine generator sets, including multiple microsecond fault recording devices distributed on the PLC controller and peripheral devices of the wind turbine generator set, multiple microsecond fault recording devices connected to the wireless gateway through the fault recording processing system, and the wireless gateway connected to the PC with SCADA software on the monitoring platform of the central control room through the router. Among them, each distributed microsecond fault recording device is associated with the key tripping and shutdown signal of the key equipment, and the fault is recorded independently. When a fault occurs, the fault is recorded by the independent fault recording device to form a corresponding report, and the fault recording processing system transmits it to the wireless gateway, and the wireless gateway transmits it to the PC far away on the monitoring platform of the central control room through the router via the optical cable, so that the fault of the wind turbine generator set can be timely understood remotely, reducing safety hazards. However, the patent scheme does not involve the specific judgment, storage and sending process of fault record information. Summary of the invention

[0006] The purpose of the present invention is to address the problem mentioned in the background technology that the variable pitch drive cannot accurately record and send all fault information to the main controller through CAN communication. The present invention proposes a variable pitch servo drive fault recording method, which can accurately record the fault information generated by the three chips in the drive, send it to the main controller through communication and save it in a fault snapshot, so as to avoid missing some fault information when multiple faults occur at the same time or within a communication cycle between the main controller and ARM, and improve the accuracy of drive-related fault diagnosis.

[0007] The object of the present invention is achieved through the following technical solutions:

[0008] A method for recording faults of a variable pitch servo drive, the variable pitch servo drive comprising: a control board, a drive board, and a power board, wherein the control board comprises an ARM chip for system IO processing, system state management, system-level control logic, and system external interaction, a DSP chip for motor motion control, and a CHG chip for charger and half-controlled rectifier bridge control;

[0009] Among them, the ARM chip communicates with the DSP chip and the CHG chip through the serial port, and the pitch drive feeds back data including but not limited to fault code, current, voltage, and system status data to the main controller through the ARM chip, and the main controller records the fault code fed back by the drive in the fault snapshot;

[0010] The pitch servo drive fault recording method comprises the following steps:

[0011] Step 1: The program starts executing and initializes counters Counter1 and Counter2 to 0;

[0012] Step 2: The storage pointer SavePointer and the sending pointer SendPointer both point to the historical fault record array HistoryErrRecord[]. The elements in HistoryErrRecord[] are the structure ErrStruct. The structure ErrStruct contains two elements, namely the fault code Code and the corresponding fault trigger time Time;

[0013] Step 3: Wait for the timer to trigger. If the 1ms timer interrupt is triggered, go to step 4.

[0014] Step 4: Enter the interruption step, enter step 4.1, step 4.2 and step 4.3 in sequence, and enter the exit interruption step after step 4.1, step 4.2 and step 4.3 are all completed, return to step 3, and enter the next timing cycle;

[0015] Step 4.1: Go to step 5 for quick troubleshooting;

[0016] Step 4.2: Add 1 to the count value Counter1. If Counter1 is greater than 100, clear Counter1 to 0 and enter step 6 for slow fault handling. Otherwise, wait until step 4.1 and step 4.3 are completed and exit the interruption step.

[0017] Step 4.3: Add 1 to the count value Counter2. If Counter2 is greater than 20, clear Counter2 to 0 and proceed to step 7 to send the historical fault communication. Otherwise, wait until step 4.1 and step 4.2 are completed and exit the interrupt step.

[0018] According to a preferred embodiment, step 5, a rapid fault handling step, includes:

[0019] Step 5.1: Initialize the loop index i to 0, i.e., determine the first fault state;

[0020] Step 5.2: Assign the DSP fault information DSP_ErrState[] and the ARM fault information ARM_ErrState[] bit by bit to the driver fast fault state array FastDriverErrBit[];

[0021] Step 5.3: Copy the fault code FastDriverErrCode[i] corresponding to the current fault to ErrCode;

[0022] Step 5.4: Determine whether the current fault is triggered. If FastDriverErrBit[i]=1, it means the fault is triggered, and go to step 5.5. If FastDriverErrBit[i]=0, it means the corresponding fault is not triggered, and go to step 5.6.

[0023] Step 5.5: Determine whether ErrCode exists in the current fault list CurrentErrList[]. If so, jump to step 5.9 to avoid repeated records in the historical fault record array when the fault persists. If not, it is considered that the current fault is newly triggered and go to step 5.7.

[0024] Step 5.6: Determine whether ErrCode exists in the current fault list CurrentErrList[]. If so, it means the fault has been reset, and go to step 5.8; if not, it means the corresponding fault has not been triggered, and go to step 5.9;

[0025] Step 5.7: Insert the fault code ErrCode of the current fault to the end of CurrentErrList[] of the current fault list, enter step 7 historical fault processing step, and jump to step 5.9 after step 7 is completed;

[0026] Step 5.8: Delete ErrCode from the current fault list CurrentErrList[] and go to step 5.9;

[0027] Step 5.9: Compare loop index i and execute +1 to point to the next fault information, and compare whether i reaches the preset maximum fast fault number constant MaxFastErrNum. If it does, it means that all fault information has been processed, then exit the fast fault processing step and wait for the other two branch steps 4.2. After step 4.3 is completed, return to step 3; otherwise, return to step 5.3.

[0028] According to a preferred embodiment, the step 6, entering the slow fault processing step, includes:

[0029] Step 6.1: Initialize the loop index j to 0, i.e., determine the first fault state;

[0030] Step 6.2: Assign the CHG fault information CHG_ErrState[] bit by bit to the driver fast fault state array SlowDriverErrBit[];

[0031] Step 6.3: Copy the fault code SlowDriverErrCode[j] corresponding to the current fault to ErrCode;

[0032] Step 6.4: Determine whether the current fault is triggered. If SlowDriverErrCode[j]=1, it means the fault is triggered, and go to step 6.5. If SlowDriverErrCode[j]=0, it means the corresponding fault is not triggered, and go to step 6.6.

[0033] Step 6.5: Determine whether ErrCode exists in the current fault list CurrentErrList[]. If so, jump to step 6.9 to avoid repeated records in the historical fault record array when the fault persists. If not, it is considered that the current fault is newly triggered and go to step 6.7.

[0034] Step 6.6: Determine whether ErrCode exists in the current fault list CurrentErrList[]. If so, it means the fault has been reset, and go to step 6.8; if not, it means the corresponding fault has not been triggered, and go to step 6.9;

[0035] Step 6.7: Insert the fault code ErrCode of the current fault to the end of CurrentErrList[] of the current fault list, enter step 7 historical fault processing step, and jump to step 6.9 after step 7 is completed;

[0036] Step 6.8: Delete ErrCode from the current fault list CurrentErrList[] and go to step 6.9;

[0037] Step 6.9: Compare loop index j and execute +1 to point to the next fault information, and compare whether j reaches the preset maximum fast fault number constant MaxFastErrNum. If it does, it means that all fault information has been processed, then exit the fast fault processing step and wait for the other two branch steps 4.1. After step 4.3 is completed, return to step 3; otherwise, return to step 6.3.

[0038] According to a preferred embodiment, the step 7, the historical fault processing step, includes:

[0039] Step 7.1: Get the current system time SysTime and go to step 7.2;

[0040] Step 7.2: store the fault code ErrCode and the corresponding system time SysTime into the element in the historical fault record array HistoryErrRecord[] pointed to by the storage pointer SavePointer, wait to be sent to the main controller through the sending pointer SendPointer in the historical fault communication sending step of step 8, and enter step 7.3;

[0041] Step 7.3: Determine whether the storage pointer SavePointer points to the last element in the historical fault record array HistoryErrRecord[]. If so, it means that the current historical fault storage array has stored the preset maximum number of fault information, and go to step 7.5; otherwise, it means that the current historical fault storage array has not reached the storage data upper limit, and go to step 7.4;

[0042] Step 7.4: Store the pointer SavePointer+1 to point to the next fault record, exit the historical fault processing step, and return to step 5.9;

[0043] Step 7.5: The storage pointer SavePointer points to the first address of the historical fault storage array HistoryErrRecord[]. That is, if a new fault is triggered, the longest fault record will be gradually overwritten through the storage pointer SavePointer, exit the historical fault processing step, and return to step 5.9.

[0044] According to a preferred embodiment, step 8, the historical fault communication sending step, includes:

[0045] Step 8.1: Determine whether the flags DiffRoundFlag of the sending pointer SendPointer and the storage pointer SavePointer are in the same loop. If DiffRoundFlag = 1, it means that the two pointers are in different loops, and go to step 8.3; if DiffRoundFlag = 0, it means that the two pointers are in the same loop, and go to step 8.2;

[0046] Step 8.2: Determine whether the address pointed to by the sending pointer SendPointer catches up with the address pointed to by the storage pointer SavePointer. If SendPointer < SavePointer, it means that not all the faults that have occurred currently have been sent to the master controller through CAN communication, and go to step 8.3; otherwise, it means that all the faults that have occurred currently have been sent, wait for a new fault to be triggered, exit the historical fault communication sending step, and wait to return to step 3 after the other two branch steps 4.1 and 4.2 are executed;

[0047] Step 8.3: Assign the fault time and fault code stored in the element pointed to by the current sending pointer SendPointer to the CANOpen channel variables PDO_Time and PDO_Code respectively, and go to step 8.4;

[0048] Step 8.4: Send PDO_Time and PDO_Code to the master controller for storage through CANOpen communication, and go to step 8.5;

[0049] Step 8.5: Determine whether the sending pointer SendPointer points to the last element of HistoryErrRecord[]. If so, it means that the current complete loop of sending the fault information from the first to the last in the historical fault record array HistoryErrRecord[] is completed, and go to step 8.7; otherwise, it means that a loop sending is not completed, and go to step 8.6;

[0050] Step 8.6: Increment the sending pointer SendPointer by 1 to point to the next fault record information. After 20 ms, enter the next sending cycle, and send the next fault record information to the master controller for storage through communication; exit the historical fault communication sending step, and wait to return to step 3 after the other two branch steps 4.1 and 4.2 are executed;

[0051] Step 8.7: Point the send pointer SendPointer to the first address of the historical fault record array HistoryErrRecord[], start sending the fault information of the next cycle, and set the flag DiffRoundFlag, which indicates whether they are in the same cycle, to 0, indicating that the send pointer SendPointer and the storage pointer SavePointer are in the same cycle, exit the historical fault communication sending step, and wait for the other two branch steps 4.1. After step 4.2 is executed, return to step 3.

[0052] According to a preferred implementation, the communication cycle between the ARM chip and the DSP chip is set to 1 ms, and the communication cycle between the ARM chip and the CHG chip is set to 10 ms.

[0053] According to a preferred implementation, the ARM chip and the wind turbine main controller exchange information via CANOpen, and the communication cycle is 20ms.

[0054] According to a preferred implementation, the fault snapshot includes complete operation information of the wind turbine generator set when the fault is triggered, which is used to troubleshoot and analyze the fault of the wind turbine generator set and formulate corresponding maintenance measures accordingly.

[0055] According to a preferred embodiment, the fault information generated in the DSP chip and the CHG chip is sent to the ARM chip via serial communication, and the data format of the transmission is Uint16;

[0056] After receiving the fault information through the serial port communication, the ARM chip parses the fault information according to the preset communication protocol. If the corresponding bit is 1, it means that the fault is triggered, otherwise it means that the fault is not triggered.

[0057] According to a preferred embodiment, the fault information sent by the DSP chip and the CHG chip to the ARM chip is one or more Uint16, and the ARM chip receives the fault information T1 of the DSP chip and updates it once, and stores the fault status in the array DSP_ErrState[].

[0058] The ARM chip updates the information uploaded by the CHG chip every T1, uploading a Uint16-sized data each time; the CHG chip uses polling to send fault information, power grid information, charger information, and status information to the ARM chip, and stores the fault status in the array CHG_ErrState[]. If the amount of data to be sent is A, the update period T2 of the fault information received by the ARM from CHG is: T2=A*T1.

[0059] The aforementioned main scheme of the present invention and its further options can be freely combined to form multiple schemes, all of which are schemes that can be adopted and claimed for protection by the present invention. After understanding the scheme of the present invention, those skilled in the art can understand that there are multiple combinations based on the prior art and common knowledge, all of which are technical schemes to be protected by the present invention, and they are not exhaustively listed here.

[0060] Beneficial effects of the present invention:

[0061] This application can completely record the fault information inside the variable pitch drive and send it to the main controller for storage through CANOpen communication, which is conducive to accurately locating the variable pitch drive fault through the fault snapshot recorded by the main controller; the fault judgment is divided into fast and slow categories to reduce unnecessary waste of CPU computing resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] Figure 1 This is the communication architecture diagram of the pitch control system;

[0063] Figure 2 It is the flow chart of pitch system fault interruption;

[0064] Figure 3 It is a flowchart of the quick troubleshooting steps of the pitch drive;

[0065] Figure 4 It is a flowchart of the steps for handling the slow speed fault of the pitch drive;

[0066] Figure 5 It is a flow chart of the steps for troubleshooting the historical faults of the pitch drive;

[0067] Figure 6 It is a flow chart of the steps for sending historical fault communication of the pitch drive. DETAILED DESCRIPTION

[0068] The following describes the embodiments of the present invention by specific examples, and those skilled in the art can easily understand other advantages and effects of the present invention from the contents disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that the following embodiments and features in the embodiments can be combined with each other without conflict.

[0069] It should be noted that similar reference numerals and letters represent similar items in the following drawings, so once an item is defined in one drawing, it does not need to be further defined and explained in the subsequent drawings. In addition, the present invention should point out that in the present invention, if the specific structure, connection relationship, position relationship, power source relationship, etc. are not specifically written, the structure, connection relationship, position relationship, power source relationship, etc. involved in the present invention are all known to those skilled in the art based on the existing technology without creative work.

[0070] Figure 1 This is the communication architecture diagram of the pitch control system. Figure 2 This is the fault interruption flow chart of the pitch system. Figure 3 This is a flowchart of the quick troubleshooting steps for the pitch drive. Figure 4 This is a flowchart of the troubleshooting steps for the pitch drive slow speed fault. Figure 5 This is a flowchart of the historical fault handling steps of the variable pitch drive. Figure 6 It is a flow chart of the steps for sending historical fault communication of the pitch drive.

[0071] Figure 2 Counter1 and Counter2 are the count values ​​used to determine whether to enter the slow fault handling program and the historical fault communication sending program respectively; HistoryErrRecord[] is an array used to store historical fault information in the ARM chip, and its elements are the structure ErrStruct. ErrStruct contains two elements, namely the fault code Code and the corresponding fault trigger time Time; the storage pointer SavePointer and the sending pointer SendPointer are pointers to the structure ErrStruct, which are used to write the latest fault information into HistoryErrRecord[] and send the fault information index to the main controller.

[0072] Figure 3The i in the table is the index used to traverse the fast fault information; DSP_ErrState[] stores the fault information sent by DSP to ARM through serial communication, and ARM_ErrState[] is the fault information judged by the ARM chip according to internal conditions. The elements of DSP_ErrState[] and ARM_ErrState[] are Uint16 unsigned integer data; FastDriverErrBit[] is used to store the array of fast fault status. The element type is Uint16 unsigned integer data with a limited length of 1 bit. The element value in FastDriverErrBit[] is 1 represents fault triggering, 0 represents fault not triggering; FastDriverErrCode[] stores fault codes that correspond one-to-one to the elements in FastDriverErrBit[], which are used to quickly determine the specific fault of the driver, where the elements are Uint16 unsigned integer data; CurrentErrList[] stores fault codes that exist in the current system, where the elements are Uint16 unsigned integer data. If ErrCode already exists, HistoryErrRecord[] will not be inserted repeatedly; MaxFastErrNum is the preset maximum number of fast faults constant.

[0073] Figure 4 The variables in Figure 3 The correspondence in .

[0074] Figure 5 SysTime is the current system time, Uint16 unsigned integer data; DiffRoundFlag is the next cycle flag, used to indicate whether the storage pointer and the send pointer are in the same cycle, bool type variable. Figure 5In the historical fault processing flow chart shown, the historical fault information stored needs to return to the first element of the array each time the storage pointer points to the last element of the historical fault record array, and set the next cycle flag DiffRoundFlag to 1, which is used by the historical fault communication sending program to determine whether the currently sent information and the written information are in the same cycle. Because if the preset upper limit of the number of historical fault storage elements is reached, the storage array pointer SavePointer will point to the first address of HistoryErrRecord[]. At this time, SendPointer is still in the previous cycle, SendPointer>SavePointer, and the conditions for continuing to send fault information are not met. The remaining unsent information cannot be sent to the main controller, resulting in data omission. When SendPointer points to the last element of the historical fault record array, it is also necessary to return to the first element of the array. At this time, the storage pointer SavePointer and the sending pointer SendPointer are in the same cycle, and the flag DiffRoundFlag is set to 0. When designing the historical fault record array HistoryErrRecord[], ensure that its length is long enough to ensure that the storage pointer SavePointer will not exceed the sending pointer SendPointer by two cycles. Furthermore, the length of the history fault record array HistoryErrRecord[] can be set to 1000.

[0075] Figure 6 PDO_Time and PDO_Code are CANOpen communication channel variables. Data is sent to the main controller once in each communication cycle. They are Uint16 unsigned integer data.

[0076] The invention discloses a fault recording method for a variable pitch servo driver. The variable pitch servo driver comprises: a control board, a drive board and a power board. The control board comprises an ARM chip for system IO processing, system state management, system-level control logic and system external interaction, a DSP chip for motor motion control, and a CHG chip for charger and half-controlled rectifier bridge control.

[0077] ARM communicates with DSP and CHG through the serial port. Since DSP information is more critical, CHG's interactive information does not affect the safety of the variable pitch system, especially the wind turbine. In order to reduce the CPU occupancy of the ARM chip, the communication cycle between ARM and DSP is set to 1ms, and the communication cycle between ARM and CHG is set to 10ms. ARM and the wind turbine main controller exchange information through CANOpen, with a communication cycle of 20ms. The communication architecture is as follows: Figure 1The pitch drive needs to feedback key operating data including but not limited to fault code, current, voltage, and system status to the main controller through ARM. The main controller will record the fault code fed back by the drive in the fault snapshot.

[0078] The fault snapshot contains the complete operating information of the wind turbine when the fault is triggered. It is used to troubleshoot and analyze the fault of the wind turbine and formulate corresponding maintenance measures accordingly. It is an important basis for the operation and maintenance of the wind turbine. Generally speaking, the more comprehensive the fault information recorded in the fault snapshot, the more accurate the location of the fault cause.

[0079] ARM, DSP and CHG each have their own application programs, and all of them will determine driver-related faults based on certain trigger conditions. The fault information generated in DSP and CHG is sent to ARM via serial communication. The data format is Uint16, i.e., 16-bit unsigned integer data. Each Uint16 contains two bytes, i.e., 16 bits. Each bit corresponds to a specific fault and has a corresponding fault code, for example: 1234. After receiving the fault information through serial communication, ARM parses the fault information according to the agreed communication protocol. If the corresponding bit is 1, it means that the fault is triggered, otherwise it means that the fault is not triggered.

[0080] The fault information sent by DSP and CHG to ARM is one or more Uint16. The fault information received from DSP in ARM is updated every T1=1ms, and the fault status is stored in the array DSP_ErrState[]. Due to the limitation of the amount of data per data frame in the serial communication between ARM and CHG, the information uploaded by CHG is updated in ARM every 10ms, and a Uint16 size of data is uploaded each time; in addition to fault information, CHG also needs to send power grid, charger, status information, etc. to ARM, so these data are sent in a polling manner, that is, the data exchanged between CHG and ARM is sent in a certain order, and a Uint16 is sent every 10ms, and the fault status is stored in the array CHG_ErrState[]. If the amount of data to be sent is A, the update cycle T2 of the fault information received by ARM from CHG is:

[0081] T2=A×10ms

[0082] In addition to the driver fault information sent by CHG and DSP through serial port communication, the ARM chip also has relevant driver operation status information. It determines the driver fault based on certain trigger conditions and writes the corresponding fault status into the fault status array ARM_ErrState[].

[0083] DSP_ErrState[], CHG_ErrState[], and ARM_ErrState[] in the ARM application are arrays whose element data types are Uint16 unsigned integers, which are used to store the fault status generated by different chips. The interrupt has been configured and initialized in the ARM application. The interrupt triggers the fault handling program to process the fault information through the following steps and send it to the main controller through CANOpen communication.

[0084] refer to Figure 2 As shown, the pitch servo drive fault recording method of the present invention comprises the following steps:

[0085] Step 1: The program starts executing and initializes counters Counter1 and Counter2 to 0.

[0086] Step 2: The storage pointer SavePointer and the sending pointer SendPointer both point to the historical fault record array HistoryErrRecord[]. The elements in HistoryErrRecord[] are the structure ErrStruct. The structure ErrStruct contains two elements, namely the fault code Code and the corresponding fault trigger time Time;

[0087] Step 3: Wait for the timer to trigger. If the 1ms timer interrupt is triggered, go to step 4.

[0088] Step 4: Enter the interruption step, enter step 4.1, step 4.2 and step 4.3 in sequence, and enter the exit interruption step after step 4.1, step 4.2 and step 4.3 are all completed, return to step 3, and enter the next timing cycle;

[0089] Step 4.1: Go to step 5 for quick troubleshooting;

[0090] Step 4.2: Add 1 to the count value Counter1. If Counter1 is greater than 100, clear Counter1 to 0 and enter step 6 for slow fault handling. Otherwise, wait until step 4.1 and step 4.3 are completed and exit the interruption step.

[0091] Step 4.3: Add 1 to the count value Counter2. If Counter2 is greater than 20, clear Counter2 to 0 and proceed to step 7 to send the historical fault communication. Otherwise, wait until step 4.1 and step 4.2 are completed and exit the interrupt step.

[0092] Preferably, reference Figure 3 As shown in the figure, step 5 is a quick troubleshooting step, including:

[0093] Step 5.1: Initialize the loop index i to 0, i.e., determine the first fault state;

[0094] Step 5.2: Assign the DSP fault information DSP_ErrState[] and the ARM fault information ARM_ErrState[] bit by bit to the driver fast fault state array FastDriverErrBit[];

[0095] Step 5.3: Copy the fault code FastDriverErrCode[i] corresponding to the current fault to ErrCode;

[0096] Step 5.4: Determine whether the current fault is triggered. If FastDriverErrBit[i]=1, it means the fault is triggered, and go to step 5.5. If FastDriverErrBit[i]=0, it means the corresponding fault is not triggered, and go to step 5.6.

[0097] Step 5.5: Determine whether ErrCode exists in the current fault list CurrentErrList[]. If so, jump to step 5.9 to avoid repeated records in the historical fault record array when the fault persists. If not, it is considered that the current fault is newly triggered and go to step 5.7.

[0098] Step 5.6: Determine whether ErrCode exists in the current fault list CurrentErrList[]. If so, it means the fault has been reset, and go to step 5.8; if not, it means the corresponding fault has not been triggered, and go to step 5.9;

[0099] Step 5.7: Insert the fault code ErrCode of the current fault to the end of CurrentErrList[] of the current fault list, enter step 7 historical fault processing step, and jump to step 5.9 after step 7 is completed;

[0100] Step 5.8: Delete ErrCode from the current fault list CurrentErrList[] and go to step 5.9;

[0101] Step 5.9: Compare loop index i and execute +1 to point to the next fault information, and compare whether i reaches the preset maximum fast fault number constant MaxFastErrNum. If it does, it means that all fault information has been processed, then exit the fast fault processing flow and wait for the other two branches of step 4.2. After step 4.3 is completed, return to step 3; otherwise, return to step 5.3.

[0102] Preferably, reference Figure 4 As shown, step 6, entering the slow fault processing step, includes:

[0103] Step 6.1: Initialize the loop index j to 0, i.e., determine the first fault state;

[0104] Step 6.2: Assign the CHG fault information CHG_ErrState[] bit by bit to the driver fast fault state array SlowDriverErrBit[];

[0105] Step 6.3: Copy the fault code SlowDriverErrCode[j] corresponding to the current fault to ErrCode;

[0106] Step 6.4: Determine whether the current fault is triggered. If SlowDriverErrCode[j]=1, it means the fault is triggered, and go to step 6.5. If SlowDriverErrCode[j]=0, it means the corresponding fault is not triggered, and go to step 6.6.

[0107] Step 6.5: Determine whether ErrCode exists in the current fault list CurrentErrList[]. If so, jump to step 6.9 to avoid repeated records in the historical fault record array when the fault persists. If not, it is considered that the current fault is newly triggered and go to step 6.7.

[0108] Step 6.6: Determine whether ErrCode exists in the current fault list CurrentErrList[]. If so, it means the fault has been reset, and go to step 6.8; if not, it means the corresponding fault has not been triggered, and go to step 6.9;

[0109] Step 6.7: Insert the fault code ErrCode of the current fault to the end of CurrentErrList[] of the current fault list, enter step 7 historical fault processing step, and jump to step 6.9 after step 7 is completed;

[0110] Step 6.8: Delete ErrCode from the current fault list CurrentErrList[] and go to step 6.9;

[0111] Step 6.9: Compare loop index j and execute +1 to point to the next fault information, and compare whether j reaches the preset maximum fast fault number constant MaxFastErrNum. If it does, it means that all fault information has been processed, then exit the fast fault processing flow and wait for the other two branch steps 4.1. After step 4.3 is completed, return to step 3; otherwise, return to step 6.3.

[0112] Preferably, reference Figure 5 As shown, step 7, the historical fault handling step, includes:

[0113] Step 7.1: Get the current system time SysTime and go to step 7.2;

[0114] Furthermore, the ARM chip program execution cycle is measured in microseconds, and the error of the actual trigger time of the fast fault with a judgment period of 1ms obtained in the system time in step 7.1 can be ignored. For the slow fault with a judgment period of 100ms, since it does not affect the safety of the system and the drive, it is approximated here, which does not affect the accuracy of analyzing the drive fault through the fault snapshot recorded by the main control.

[0115] Step 7.2: store the fault code ErrCode and the corresponding system time SysTime into the element in the historical fault record array HistoryErrRecord[] pointed to by the storage pointer SavePointer, wait to be sent to the main controller through the sending pointer SendPointer in the historical fault communication sending step of step 8, and enter step 7.3;

[0116] Step 7.3: Determine whether the storage pointer SavePointer points to the last element in the historical fault record array HistoryErrRecord[]. If so, it means that the current historical fault storage array has stored the preset maximum number of fault information, and go to step 7.5; otherwise, it means that the current historical fault storage array has not reached the storage data upper limit, and go to step 7.4;

[0117] Step 7.4: Store the pointer SavePointer+1 to point to the next fault record, exit the historical fault handling process, and return to step 5.9;

[0118] Step 7.5: The storage pointer SavePointer points to the first address of the historical fault storage array HistoryErrRecord[]. That is, if a new fault is triggered, the longest fault record will be gradually overwritten through the storage pointer SavePointer, exiting the historical fault processing process and returning to step 5.9.

[0119] Preferably, reference Figure 6 As shown, the step 8, the historical fault communication sending step, includes:

[0120] Step 8.1: Determine whether the send pointer SendPointer and the save pointer SavePointer are in the flag bit DiffRoundFlag state of the same loop. If DiffRoundFlag = 1, it means the two pointers are in different loops, and go to Step 8.3; if DiffRoundFlag = 0, it means the two pointers are in the same loop, and go to Step 8.2;

[0121] Step 8.2: Determine whether the address pointed to by the send pointer SendPointer catches up with the address pointed to by the save pointer SavePointer. If SendPointer < SavePointer, it means that not all the currently generated faults have been sent to the master controller through CAN communication, and go to Step 8.3; otherwise, it means that all the currently generated faults have been sent, wait for a new fault to be triggered, exit the historical fault communication sending process, and wait to return to Step 3 after the other two branch steps 4.1 and 4.2 are executed;

[0122] Step 8.3: Assign the fault time and fault code stored in the element pointed to by the current send pointer SendPointer to the CANOpen channel variables PDO_Time and PDO_Code respectively, and go to Step 8.4;

[0123] Step 8.4: Send PDO_Time and PDO_Code to the master controller for storage through CANOpen communication, and go to Step 8.5;

[0124] Step 8.5: Determine whether the send pointer SendPointer points to the last element of HistoryErrRecord[]. If so, it means that the current complete loop of sending the historical fault record array HistoryErrRecord[] from the first to the last fault information is completed, and go to Step 8.7; otherwise, it means that a loop has not been completed, and go to Step 8.6;

[0125] Step 8.6: Increment the send pointer SendPointer by 1 to point to the next fault record information. After 20 ms, enter the next sending cycle, and send the next fault record information to the master controller for storage through communication; exit the historical fault communication sending step, and wait to return to Step 3 after the other two branch steps 4.1 and 4.2 are executed;

[0126] Step 8.7: Point the send pointer SendPointer to the first address of the historical fault record array HistoryErrRecord[], start sending the fault information of the next cycle, and set the flag DiffRoundFlag, which indicates whether they are in the same cycle, to 0, indicating that the send pointer SendPointer and the storage pointer SavePointer are in the same cycle, exit the historical fault communication sending step, and wait for the other two branch steps 4.1. After step 4.2 is executed, return to step 3.

[0127] The method of the present invention can completely record the fault information inside the variable pitch drive, and send it to the main controller for storage through CANOpen communication, which is conducive to accurately locating the variable pitch drive fault through the fault snapshot recorded by the main controller; the fault judgment is divided into two categories: fast and slow, reducing unnecessary waste of CPU computing resources. In addition, the variable pitch servo drive fault recording method accurately records the fault information generated by the three chips in the drive, sends it to the main controller through communication and saves it in the fault snapshot, avoiding the omission of part of the fault information when multiple faults occur at the same time or within a communication cycle between the main controller and ARM, and improving the accuracy of the drive-related fault diagnosis.

[0128] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the protection scope of the present invention.

Claims

1. A method for recording faults of a variable pitch servo drive, It is characterized in that The pitch servo driver includes: a control board, a drive board, and a power board, wherein the control board includes an ARM chip for system IO processing, system state management, system-level control logic, and system external interaction, a DSP chip for motor motion control, and a CHG chip for charger and half-controlled rectifier bridge control; Among them, the ARM chip communicates with the DSP chip and the CHG chip through the serial port, and the pitch drive feeds back data including but not limited to fault code, current, voltage, and system status data to the main controller through the ARM chip, and the main controller records the fault code fed back by the drive in the fault snapshot; The pitch servo drive fault recording method comprises the following steps: Step 1: The program starts executing and initializes counters Counter1 and Counter2 to 0; Step 2: The storage pointer SavePointer and the sending pointer SendPointer both point to the historical fault record array HistoryErrRecord[]. The elements in HistoryErrRecord[] are the structure ErrStruct. The structure ErrStruct contains two elements, namely the fault code Code and the corresponding fault trigger time Time; Step 3: Wait for the timer to trigger. If the 1ms timer interrupt is triggered, go to step 4. Step 4: Enter the interruption step, enter step 4.1, step 4.2 and step 4.3 in sequence, and enter the exit interruption step after step 4.1, step 4.2 and step 4.3 are all completed, return to step 3, and enter the next timing cycle; Step 4.1: Go to step 5 for quick troubleshooting; Step 4.2: Add 1 to the count value Counter1. If Counter1 is greater than 100, clear Counter1 to 0 and enter step 6 for slow fault handling. Otherwise, wait until step 4.1 and step 4.3 are completed and exit the interruption step. Step 4.3: Add 1 to the count value Counter2. If Counter2 is greater than 20, clear Counter2 to 0 and proceed to step 7 to send the historical fault communication. Otherwise, wait until step 4.1 and step 4.2 are completed and exit the interrupt step.

2. The pitch servo drive fault recording method according to claim 1, It is characterized in that Step 5: Quick troubleshooting steps, including: Step 5.1: Initialize the loop index i to 0, i.e., determine the first fault state; Step 5.2: Assign the DSP fault information DSP_ErrState[] and the ARM fault information ARM_ErrState[] bit by bit to the driver fast fault state array FastDriverErrBit[]; Step 5.3: Copy the fault code FastDriverErrCode[i] corresponding to the current fault to ErrCode; Step 5.4: Determine whether the current fault is triggered. If FastDriverErrBit[i]=1, it means the fault is triggered, and go to step 5.

5. If FastDriverErrBit[i]=0, it means the corresponding fault is not triggered, and go to step 5.

6. Step 5.5: Determine whether ErrCode exists in the current fault list CurrentErrList[]. If so, jump to step 5.9 to avoid repeated records in the historical fault record array when the fault persists. If not, it is considered that the current fault is newly triggered and go to step 5.

7. Step 5.6: Determine whether ErrCode exists in the current fault list CurrentErrList[]. If so, it means the fault has been reset, and go to step 5.8; if not, it means the corresponding fault has not been triggered, and go to step 5.9; Step 5.7: Insert the fault code ErrCode of the current fault to the end of CurrentErrList[] of the current fault list, enter step 7 historical fault processing step, and jump to step 5.9 after step 7 is completed; Step 5.8: Delete ErrCode from the current fault list CurrentErrList[] and go to step 5.9; Step 5.9: Compare loop index i and execute +1 to point to the next fault information, and compare whether i reaches the preset maximum fast fault number constant MaxFastErrNum. If it does, it means that all fault information has been processed, then exit the fast fault processing step and wait for the other two branch steps 4.

2. After step 4.3 is completed, return to step 3; otherwise, return to step 5.

3.

3. The pitch servo drive fault recording method according to claim 1, It is characterized in that The step 6, entering the slow fault handling step, includes: Step 6.1: Initialize the loop index j to 0, i.e., determine the first fault state; Step 6.2: Assign the CHG fault information CHG_ErrState[] bit by bit to the driver fast fault state array SlowDriverErrBit[]; Step 6.3: Copy the fault code SlowDriverErrCode[j] corresponding to the current fault to ErrCode; Step 6.4: Determine whether the current fault is triggered. If SlowDriverErrCode[j]=1, it means the fault is triggered, and go to step 6.

5. If SlowDriverErrCode[j]=0, it means the corresponding fault is not triggered, and go to step 6.

6. Step 6.5: Determine whether ErrCode exists in the current fault list CurrentErrList[]. If so, jump to step 6.9 to avoid repeated records in the historical fault record array when the fault persists. If not, it is considered that the current fault is newly triggered and go to step 6.

7. Step 6.6: Determine whether ErrCode exists in the current fault list CurrentErrList[]. If so, it means the fault has been reset, and go to step 6.8; if not, it means the corresponding fault has not been triggered, and go to step 6.9; Step 6.7: Insert the fault code ErrCode of the current fault to the end of CurrentErrList[] of the current fault list, enter step 7 historical fault processing step, and jump to step 6.9 after step 7 is completed; Step 6.8: Delete ErrCode from the current fault list CurrentErrList[] and go to step 6.9; Step 6.9: Compare loop index j and execute +1 to point to the next fault information, and compare whether j reaches the preset maximum fast fault number constant MaxFastErrNum. If it does, it means that all fault information has been processed, then exit the fast fault processing step and wait for the other two branch steps 4.

1. After step 4.3 is completed, return to step 3; otherwise, return to step 6.

3.

4. The pitch servo drive fault recording method according to claim 1, It is characterized in that The step 7, historical fault handling step, includes: Step 7.1: Get the current system time SysTime and go to step 7.2; Step 7.2: store the fault code ErrCode and the corresponding system time SysTime into the element in the historical fault record array HistoryErrRecord[] pointed to by the storage pointer SavePointer, wait to be sent to the main controller through the sending pointer SendPointer in the historical fault communication sending step of step 8, and enter step 7.3; Step 7.3: Determine whether the storage pointer SavePointer points to the last element in the historical fault record array HistoryErrRecord[]. If so, it means that the current historical fault storage array has stored the preset maximum number of fault information, and go to step 7.5; otherwise, it means that the current historical fault storage array has not reached the storage data upper limit, and go to step 7.4; Step 7.4: Store the pointer SavePointer+1 to point to the next fault record, exit the historical fault processing step, and return to step 5.9; Step 7.5: The storage pointer SavePointer points to the first address of the historical fault storage array HistoryErrRecord[]. That is, if a new fault is triggered, the longest fault record will be gradually overwritten through the storage pointer SavePointer, exit the historical fault processing step, and return to step 5.

9.

5. The pitch servo drive fault recording method according to claim 4, It is characterized in that The step 8, the step of sending historical fault communication, comprises: Step 8.1: Determine whether the send pointer SendPointer and the storage pointer SavePointer are in the flag bit DiffRoundFlag state of the same loop. If DiffRoundFlag = 1, it means the two pointers are in different loops, and go to Step 8.3; if DiffRoundFlag = 0, it means the two pointers are in the same loop, and go to Step 8.2; Step 8.2: Determine whether the address pointed to by the send pointer SendPointer catches up with the address pointed to by the storage pointer SavePointer. If SendPointer < SavePointer, it means that not all the currently generated faults have been sent to the master controller through CAN communication, and go to Step 8.3; otherwise, it means that all the currently generated faults have been sent, wait for a new fault to be triggered, exit the historical fault communication sending step, and wait to return to Step 3 after the other two branch steps 4.1 and 4.2 are executed; Step 8.3: Assign the fault time and fault code stored in the element pointed to by the current send pointer SendPointer to the CANOpen channel variables PDO_Time and PDO_Code respectively, and go to Step 8.4; Step 8.4: Send PDO_Time and PDO_Code to the master controller for storage through CANOpen communication, and go to Step 8.5; Step 8.5: Determine whether the send pointer SendPointer points to the last element of HistoryErrRecord[]. If so, it means that the current complete loop of sending the fault information from the first to the last in the historical fault record array HistoryErrRecord[] is completed, and go to Step 8.7; otherwise, it means that a loop sending is not completed, and go to Step 8.6; Step 8.6: Increment the send pointer SendPointer by 1 to point to the next fault record information. After 20 ms, enter the next sending cycle, and send the next fault record information to the master controller for storage through communication; exit the historical fault communication sending step, and wait to return to Step 3 after the other two branch steps 4.1 and 4.2 are executed; Step 8.7: Point the send pointer SendPointer to the starting address of the historical fault record array HistoryErrRecord[], start sending the fault information in the next loop, and set the flag bit DiffRoundFlag indicating whether it is in the same loop to 0, which means the send pointer SendPointer and the storage pointer SavePointer are in the same loop, exit the historical fault communication sending step, and wait to return to Step 3 after the other two branch steps 4.1 and 4.2 are executed.

6. The pitch servo driver fault recording method according to claim 1, characterized in that, the communication cycle between the ARM chip and the DSP chip is set to 1 ms, and the communication cycle between the ARM chip and the CHG chip is set to 10 ms.

7. The pitch servo drive fault recording method according to claim 1, It is characterized in that The ARM chip and the wind turbine main controller exchange information via CANOpen, and the communication cycle is 20ms.

8. The pitch servo drive fault recording method according to claim 1, It is characterized in that The fault snapshot contains complete operating information of the wind turbine when the fault is triggered, and is used to troubleshoot and analyze the fault of the wind turbine and formulate corresponding maintenance measures accordingly.

9. The pitch servo drive fault recording method according to claim 1, It is characterized in that The fault information generated in the DSP chip and the CHG chip is sent to the ARM chip via serial communication, and the data format is Uint16; After receiving the fault information through the serial port communication, the ARM chip parses the fault information according to the preset communication protocol. If the corresponding bit is 1, it means that the fault is triggered, otherwise it means that the fault is not triggered.

10. The pitch servo drive fault recording method according to claim 9, It is characterized in that The fault information sent by the DSP chip and the CHG chip to the ARM chip is one or more Uint16. The fault information T received by the DSP chip in the ARM chip 1 Update once and store the fault status in the array DSP_ErrState[]; Each T in ARM chip 1 Update the information uploaded by the CHG chip once, and upload a Uint16 size data each time; the CHG chip uses polling to send fault information, power grid information, charger information, and status information to the ARM chip, and stores the fault status in the array CHG_ErrState[]. If the amount of data to be sent is A, the update cycle of the fault information received by ARM is T 2 =T 2 =A*T 1 .

Images