TMS320F28379D: Using problem of Tamagawa encoder.

Hi,

There is no interference between SDFM and T-format encoder function.
Please make sure the GPIOs being used by T-Format function are not overwritten when SDFM is enabled.

Hi Subrahmanya:

My customer feedback:

In the project file, the parts related to the encoder and SD sampling are provided by ti. 

And he found that when BUILDLEVEL is set to FCL_LEVEL2 in the evaluation project, the compatibility of T-format and SD_CURRENT_SENSE current sampling mode can be realized. But when BUILDLEVEL is set to other FCL_LEVELx, the absolute encoder will be abnormal. 

This should prove that FCL_LEVEL2 is not covered, other FCL_LEVELx may be covered by IO functions or not initialized completely, because this problem is not mentioned in the FCL project reference document.

Are there other possible problems?

Hi,

I'll loop in the FCL expert to respond to this.

Green,

Are you referring to the old controlsuite example?

Hi Ramesh:

I haven't asked the customer about the version of controlSUITE. Are the program codes of different versions different?

Best regards

The T-format encoder can work with SDFM current sense if customer is using the example project in MotorControlSDK.

Green Deng said:

But when BUILDLEVEL is set to other FCL_LEVELx, the absolute encoder will be abnormal. 

Could you please ask your customer to have a detailed description of this? Any changes in the example code?

Hi Yanming:

HW vision: IDDK2.2.1

SW vision: C:\ti\c2000\C2000Ware_MotorControl_SDK_3_02_00_00\solutions\tmdxiddk379d\f2837x\fcl_f2838x_tmdxiddk_cpu1

Under the condition of using SD_CURRENT_SENS current sampling method and T-format absolute encoder, there is no problem in running FCL_LEVEL2, 6 stage; Other FCL_LEVEL1, 3~5 do not seem to work.

In the FCL_LEVEL1 stage, the customer repeatedly reset, restart, and run, most of the probability is that the encoder verification fails, causing the runMortor to be forcibly set to MOTOR_STOP. Observe that the "position" and "turns" are abnormal data, so the motor cannot run normally. Repeated test Occasionally, the encoder can read the "position" and "turns" data normally at a certain time. At this time, there will be no verification error, and the motor can run and run for a long time.

In the FCL_LEVEL1 stage, when enableFlag is set to 1, the encoder initialization probability is abnormal. He observes Enc_DO (green, encoder return data), Enc_DI (blue, IDDK issued a start command), TxEn ( Red, send enable) signal, the abnormal point is at the second TxEn at startup, and the data sent by Enc_DI is ahead of TxEn.

Looking at the normal signal again, the second TxEn and Enc_DI basically act at the same time.
Under normal circumstances, TxEn is handled like this: Before sending data, TxEn is valid first, delay 1~2us before sending data to buffer. After the sending buffer is empty, delay 1~2us to clear TxEn and wait for acceptance.

If the level 6 works well, the other levels should work as well, except level 3 if using SDFM without setting a right reference torque current.

Did the customer follow the reference guide to set the 5V power supply?

Replace capacitor C5 to 1 0 nF (from 330 pF)

Bypass this switch U4 by directly connecting '5V0' and '5V0-Enc' test points on this macro. This will lead to encoder being powered up when ever the IDDK is powered.

Hi Yanming:

Thank you for following up on the issue.

Regarding the power supply of the encoder, the customer replied that he has directly short-circuited "5V0" and "5V0 Enc" in accordance with the requirements of the user guide, which can eliminate the power supply factor.

According to customer analysis, the encoder's abnormality is directly related to the second timing abnormality between Txen and Enc_DI. After repeated tests by the customer, after starting, as long as the second Txen lags behind Enc_DI, the subsequent reading of the encoder is abnormal.

He monitors the D+ and D- of the encoder interface RS485 on the serial debugging assistant of the PC. After continuous observation and analysis, the actual encoder data read is normal. This shows that Tamagawa correctly recognized the encoder read command issued by CLB 28397, but the data received by SPI 28379 is abnormal.

Could it be a problem with the initialization of the CLB program that caused the SPI to be in a misaligned state? 

In addition, the abnormal operation under level 3 should not be the problem of the size of iq_ref, but the encoder can't recognize it correctly and can't run to the next step.

Best regards

Can you confirm with customer if the build level 6 works well as you mentioned above? And the CLB and SPI should be configured correctly since all of the build levels work well with LEM current sensor and T-Format encoder. The build level 6 includes all functions of the build level 4. 

Can you check if customer is using the example project without any changes?

Hi Yanming:

My customer reinstalled the MCSDK and made sure that the operation was performed under the original TI hardware (except for the encoder power flying lead indicated in the manual) and the original fcl_f2837x_tmdxiddk project file. The compilation conditions are as follows:

// User can select choices from available control configurations
//
#define CGND COLD
#define BUILDLEVEL                           FCL_LEVEL2 //Changing this to FCL_LEVEL2 & 6 is no problem, other levels will be wrong.
#define SAMPLING_METHOD            SINGLE_SAMPLING // DOUBLE_SAMPLING //
#define FCL_CNTLR                           PI_CNTLR // CMPLX_CNTLR //
#define CURRENT_SENSE                SD_CURRENT_SENSE // LEM_CURRENT_SENSE //
#define POSITION_ENCODER           T_FORMAT_ENCODER // QEP_POS_ENCODER //

The servo motor is a 4-pair 400W servo motor with Tamagawa encoder purchased by the customer. The correct operation of FCL_LEVEL2 & 6 should eliminate motor problems.

The customer is puzzled that FCL_LEVEL6 only adds SFRA on the basis of FCL_LEVEL4, but FCL_LEVEL6 runs normally but FCL_LEVEL4 does not work.

The customer guessed that this problem only occurs under certain combinations. It may be that TXEn and Enc_DI have not reached synchronization and will continue to be affected. Conversely, if the second point circled in the waveform diagram is correctly synchronized, the encoder error problem will not occur.

When an error occurs, observe through the high-speed RS485 serial port: After the initialization is completed, manually rotate the motor shaft, and the observed command transmission and encoder data feedback are actually normal. Can it be understood that the unsuccessful initialization affects the subsequent data reading and recognition? How to solve this problem?

Best regards

The initialization and execution codes of T-format encoder are the same in all of the build levels and the current sensors. Build level 6 and level 4 share the same ISR function, so if the build level 6 works, the build level 4 should work as well as mentioned above. 

Please check if the settings parameters are the same for level 6 and level 4 in tmdxiddk_settings.h

Hi Yanming:

My customer confirmed that the settings parameters are the same for level 6 and level 4 in tmdxiddk_settings.h.

In addition, he suspects:

Under the same compiling conditions and different BUILDLEVEL, is it possible that the initialization process of the encoder may be interrupted by other interrupts, causing the initialization process to be misaligned? This in turn causes the encoder to report errors during verification.

Best regards

We dont see this issue, let me check one more time. Are they using the same projectspec and linker cmd settings as in the example project?

Hi Ramesh:

The customer uses the original code without adding additional code, and uses the on-board emulator on IDDK2.2.1. That means they are using the same projectspec and linker cmd settings as in the example project.

Customers recommend testing between FCL_LEVEL1 and FCL_LEVEL2 (other compilation conditions remain unchanged), FCL_LEVEL1 can run normally occasionally, and FCL_LEVEL2 can run normally all the time, this is very representative

Best regards

Green,

I tried it in the lab today and cant reproduce the problem your customer mentioned. Can you ask them to check SDK v3.01 or earlier versions instead of 3.02?

Hi Ramesh:

HW: IDDK2.2.1; SW: IDE CCS10.4.0.00006; MCSDK 3.0.1/3.0.0

The compilation conditions are as follows:

#define CGND COLD
#define BUILDLEVEL                           FCL_LEVELx     // "x" is the only item that has been changed.  
#define SAMPLING_METHOD            SINGLE_SAMPLING          // DOUBLE_SAMPLING //
#define FCL_CNTLR                           PI_CNTLR        // CMPLX_CNTLR //
#define CURRENT_SENSE                SD_CURRENT_SENSE       // LEM_CURRENT_SENSE //
#define POSITION_ENCODER           T_FORMAT_ENCODER         // QEP_POS_ENCODER //

My customer tested the SDK and found that the same problem would still occur. That is, FCL_LEVEL2 can always run normally, and other FCL_LEVEL1, 3~6 have encoder verification errors to varying degrees.

But the older version 3.0.0 and 3.0.1 will be much better, and the encoder will check correctly with a higher probability.

In addition, these three versions have a feature: once the encoder is checked correctly or incorrectly, as long as it is not reset, this state will be maintained, and no new conditions will appear until after the reset.

Best Regards

Not sure if it is due to any compiler settings. Let me pool in additional people to look into this. Give us a few days.