[参考译文] TMS320F28379D：Tamagawa 编码器的使用问题。

您好！

SDFM 和 T-format 编码器功能之间不存在干扰。
请确保在启用 SDFM 时、T-Format 函数使用的 GPIO 不会被覆盖。

您好 、Subrahmanya：

我的客户反馈：

在项目文件中、与编码器和 SD 采样相关的器件由 ti 提供。  

他发现、当在评估项目中将 BUILDLEVEL 设置为 FCL_LEVEL2时、可以实现 T-format 和 SD_CURRENT_SENSE 电流采样模式的兼容性。  但是、当 BUILDLEVEL 设置为其他 FCL_LEVELx 时、绝对编码器将异常。  

这应该证明 FCL_LEVEL2未涵盖、其他 FCL_LEVELx 可能会被 IO 函数涵盖或未完全初始化、因为 FCL 项目参考文档中未提及此问题。

还有其他可能的问题吗？

您好！

我将在 FCL 专家的帮助下对此做出回应。

绿色、

您提到的是旧版 controlSUITE 示例吗？

您好 Ramesh：

我没有向客户询问有关 controlSUITE 版本的信息。 不同版本的程序代码是否不同？

此致

 如果客户使用 MotorControlSDK 中的示例项目、则 T-format 编码器可以与 SDFM 电流感应配合使用。

您能否要求您的客户对此进行详细描述？ 示例代码中是否有任何更改？

您好、Yanming：

硬件愿景： IDDK2.2.1

软件视觉： C：\ti\c2000\C2000Ware_MotorControl_SDK_3_02_00_00\solutions\tmdxiddk379d\f2837x\f2837x\fCL_f2838x_tmdxiddk_CPU1

  在使用 SD_CURRENT_SENS 电流采样方法和 T-format 绝对编码器的情况下、运行 FCL_LEVEL2 6级没有问题；其他 FCL_LEVEL1、3~5似乎不起作用。

在 FCL_LEVEL1阶段、客户反复复位、重新启动并运行、大多数情况下、编码器验证失败、导致 runMortor 被强制设置为 MOTOR_STOP。 观察"位置"和"匝数"是异常数据、因此电机无法正常运行。 有时重复测试、编码器可以在特定时间正常读取"位置"和"转弯"数据。 此时将不会出现验证错误、电机可以长时间运行。

在 FCL_LEVEL1级、当 enableFlag 被设定为1时、编码器初始化概率为异常。 他观察 Enc_do (绿色、编码器返回数据)、Enc_DI (蓝色、IDDK 发出启动命令)、TxEn (红色、发送使能)信号、异常点在启动时的第二个 TxEn 上、并且 Enc_DI 发送的数据在 TxEn 之前。

再看一下正常信号、第二个 TxEn 和 Enc_DI 基本上同时运行。
在正常情况下、TxEn 的处理方式如下：在发送数据之前、TxEn 首先有效、在将数据发送到缓冲区之前延迟1~2us。 发送缓冲区为空后、延迟1~2us 以清除 TxEn 并等待接受。

如果6级运行良好、其他级别也应工作、但使用 SDFM 而未设置正确的基准扭矩电流时、则3级除外。

客户是否按照参考指南设置5V 电源？

将电容器 C5更换为1 0 nF (从330pF 开始)

通过在此宏上直接连接'5V0'和'5V0-Enc'测试点来绕过此开关 U4。 这将导致在 IDDK 通电时为编码器加电。

您好、Yanming：

感谢您跟进此问题。

关于编码器的电源、客户告知按照用户指南的要求直接短路了"5V0"和"5V0 Enc"、这样就省去了电源因素。

根据客户分析、编码器的异常与 Txen 和 Enc_DI 之间的第二个时序异常直接相关。 在客户重复测试后、启动后、只要第二个 Txen 滞后于 Enc_DI、编码器的后续读取就会异常。

他在 PC 的串行调试助手上监控编码器接口 RS485的 D+和 D-。 连续观察和分析后、实际读取的编码器数据正常。 这表明 Tamagawa 正确识别了 CLB 28397发出的编码器读取命令、但 SPI 28379接收到的数据异常。

CLB 程序的初始化是否会导致 SPI 处于未对齐状态？  

此外、3级下的异常操作不应是 IQ_ref 大小的问题、但编码器无法正确识别它、无法运行到下一步。

此致

您能否与客户确认构建级别6是否如您上文所述正常工作？ 并且 CLB 和 SPI 应该被正确配置、这是因为所有构建级与 LEM 电流传感器和 T-Format 编码器一起工作正常。  编译层6包括编译层4的所有函数。  

您能否在不做任何更改的情况下检查客户是否正在使用示例项目？

您好、Yanming：

我的客户重新安装了 MCSDK、并确保在原始 TI 硬件(手册中指示的编码器电源飞线除外)和原始 FCL_f2837x_tmsxiddk 项目文件下执行该操作。 编译条件如下：

// 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 //

伺服电机是一款带有客户购买的 Tamagawa 编码器的4线对400W 伺服电机。 FCL_LEVEL2和6的正确运行应该能够消除电机问题。

客户感到困惑的是、FCL_LEVEL6仅根据 FCL_LEVEL4添加了 SFRA、但 FCL_LEVEL6正常运行、但 FCL_LEVEL4不起作用。

客户猜测这个问题只在某些组合下出现。 TXEn 和 Enc_DI 可能尚未达到同步、并且将继续受到影响。 相反、如果波形图中圈出的第二个点正确同步、则不会出现编码器错误问题。

发生错误时、通过高速 RS485串行端口进行观察：初始化完成后、手动旋转电机轴、观察到的命令传输和编码器数据反馈实际上正常。 是否可以理解初始化失败会影响后续数据读取和识别？  如何解决此问题？

此致

T-format 编码器的初始化和执行代码在所有构建级别和电流传感器中都是相同的。 编译层6和编译层4共享相同的 ISR 函数、因此如果编译层6正常工作、编译层4也应如上所述工作。  

请检查 tmdxiddk_settings.h 中6级和4级的设置参数是否相同

您好、Yanming：

我的客户确认  tmdxiddk_settings.h 中的6级和4级设置参数相同

此外，他怀疑：

在相同的编译条件和不同的 BUILDLEVEL 下、编码器的初始化过程是否可能会被其他中断中断中断、从而导致初始化过程未对齐？ 这反过来会导致编码器在验证期间报告错误。

此致

我们没有看到这个问题，让我再检查一次。 它们是否使用与示例工程中相同的 projectspec 和链接器 cmd 设置？

您好 Ramesh：

客户使用原始代码而不添加其他代码、并使用 IDDK2.2.1上的板载仿真器。 这意味着 它们使用与示例工程中相同的 projectspec 和链接器 cmd 设置。

客户建议在 FCL_LEVEL1和 FCL_LEVEL2之间进行测试(其他编译条件保持不变)、FCL_LEVEL1可以偶尔正常运行、而 FCL_LEVEL2可以始终正常运行、这非常具有代表性

此致

绿色、

我今天在实验室里试过、无法再现客户提到的问题。 您能否让他们检查 SDK v3.01或更早版本、而不是3.02？

您好 Ramesh：

硬件： IDDK2.2.1；软件：IDE CCS10.4.0.00006； MCSDK 3.0.1/3.0.0

编译条件如下：

#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 //

我的客户测试了 SDK、发现仍然会出现相同的问题。  也就是说、FCL_LEVEL2可以一直正常运行、而其他 FCL_LEVEL1、3~6具有不同度的编码器验证错误。

但较旧版本3.0.0和3.0.1会好得多、编码器将以较高的概率进行正确检查。

此外、这三个版本具有以下特性：正确或错误地检查编码器后、只要编码器未复位、就会保持该状态、并且在复位后才会出现新的情况。

此致

不确定是否是由于任何编译器设置所致。 让我加入其他人来研究这个问题。 请给我们几天时间。