TI中文支持网Part Number:TMS320F28379DOther Parts Discussed in Thread:CONTROLSUITE, C2000WARE, TMDXIDDK379D, SFRA
IDDK2.2.1 FCL快速电流环项目中电机编码器采用了多摩川的多圈绝对值，电流采样使用LEM_CURRENT_SENSE方式时是正常 使用SD_CURRENT_SENSE方式时，编码器校验报错，是哪里冲突了吗？
Green Deng：
你好，报错内容是什么？编码器型号方便发过来一下吗？
,
David Lew：
感谢你的回复！这个型号是多摩川的17bit 多圈绝对式 。在lem 电流传感模式下可以正常工作，应该可以排除编码器的问题。问题是切换成SDFM模式后发生的编码器校验错误，SDFM模式下会和T-format功能有什么干涉吗？
,
David Lew：
Hi Green Deng，
新的发现 在评估项目中 将BUILDLEVEL 设置成 FCL_LEVEL2时 可以实现T-format与SD_CURRENT_SENSE电流采样模式的兼容！ 但当BUILDLEVEL 设置成 其它FCL_LEVELX时 就会出现绝对值编码器异常的现象。项目是从Ti MCSDK的 solution下导入的。
等待你的回复，谢谢！
,
Green Deng：
SDFM 和 T-format功能之间没有什么干涉。需要确保在启用 SDFM 时不会覆盖 T-Format 功能正在使用的 GPIO。
,
David Lew：
感谢Green Deng的答复！
项目文件与编码器和SD采样相关的部分都是ti提供的，FCL_LEVEL2正确工作可以证明在这个2阶段是没有覆盖的，其它FCL_LEVELX阶段有可能IO功能覆盖了或者没有初始化完整，因为这个FCL项目参考说明文件中没有提到这个问题，你们如果有IDDK套件可以验证一下我碰到的这个问题。
,
Green Deng：
你好，你的工程使用的是controlSUITE中的库还是C2000WARE？对应的软件版本是多少？
这个似乎跟软件和库的版本也有关系，还请提供一下具体工程路径信息
,
David Lew：
硬件是IDDK2.2.1,软件项目是C2000Ware_MotorControl_SDK_3_02_00_00\solutions\tmdxiddk379d\f2837x\下的fcl_f2838x_tmdxiddk_cpu1项目。
,
David Lew：
硬件版本IDDK2.2.1 软件采用了C:\ti\c2000\C2000Ware_MotorControl_SDK_3_02_00_00\solutions\tmdxiddk379d\f2837x\下的fcl_f2838x_tmdxiddk_cpu1项目，谢谢！
,
Green Deng：
收到，我会将你的问题反馈给美国负责这款套件的工程师看一下。
另外你的程序有做过哪些修改吗？如果使用最新版SDK的话应该是T-format编码器和SDFM应该是可以兼容的。
,
David Lew：
感谢Green Deng的协助！我软件使用的是MCSDK3.0.2、C2000ware3.0.4，硬件使用的是IDDK2.2.1.
在SD_CURRENT_SENS电流采样方式下，T-format绝对值编码器条件下，
FCL_LEVEL2阶段下是没有问题的；
其它FCL_LEVEL1、3~6似乎都不行；
在FCL_LEVEL1阶段下，发现一个奇怪的现象，我反复reset、restart、run，大部分概率是编码器校验失败，导致runMortor强制设置为MOTOR_STOP，观察position和turns是不正常的数据，因此马达不能正常运转。重复测试偶尔某次编码器能够正常读取position和turns数据，这个时候是不会发生校验错误，马达能够运转起来，并且可以长时间运转。是否在FCL_LEVEL1阶段，当enableFlag设置成1时，编码器的初始化大部分概率是不正常的，我观察M12区域的Enc_DO（绿色编码器返回数据）、Enc_DI（蓝色、IDDK发出启动命令）、TxEn（红色、发送使能）信
号，异常点在启动时的第二个TxEn处，Enc_DI发送数据超前于TxEn了。再看看正常时的信号，第二个TxEn和Enc_DI基本是同时动作的。TxEn我们常规都是这样处理的：发送数据前，TxEn先有效 延时1~2us 再发送数据至buffer，待发送buffer空后再延时1~2us清除TxEn，等待接受。以上分析供Ti参考，希望能够尽快解决这个问题。
,
David Lew：
这个是不正常波形
,
David Lew：
FCL_LEVEL6先前没有测试，现经测试发现也是正常的
,
Green Deng：
收到，我会尽快转述你的问题。另外之前问了一下可能你没看见，就是你的代码大概更改过哪些？
因为这类问题通常跟代码也有很大关系，所以方便的话还是说明一下代码的改动。
,
David Lew：
谢谢Green Deng！为了排除修改代码的影响，我删除了后重新安装了MCSDK，也就是所有的代码都是TI原有的项目文件了，上述现象是这种情况下测试的。
,
Green Deng：
你好，工程师回复：
如果level 6 运行良好，则其他level也应该可以正常工作。但如果使用 SDFM 且未设置正确的参考转矩电流的话，level 3可能会运行不正常。
你是否按照参考指南设置5V电源？
将电容器 C5 更换为10nF（原330pF）
通过直接连接此macro上的“5V0”和“5V0 Enc”测试点绕过此开关U4。这将导致编码器在IDDK通电时也上电。
,
David Lew：
Hi Green Deng，
我在英文网站上看到了您的咨询，非常感谢您耐心的解答协助！
关于编码器的电源我已经按照user guide 直接“5V0”和“5V0 Enc”短接处理，可以排除电源的因素。编码器的异常和Txen与Enc_DI间的第二个时序异常有直接关联，这个我已经反复尝试，只要启动后第二个Txen滞后于Enc_DI，编码器的后续读取就不正常，我在PC机的串口调试助手上监听编码器接口的RS485的D+、D-，经过持续观察和分析，实际读取到的编码器数据是正常的，这说明多摩川正确的识别了28397CLB发出的读编码器命令，但是28379 SPI接受的数据是不正常，感觉是CLB程序初始化的问题，SPI处于一个错位状态，这个需要CLB工程师来进一步分析。
level 3下不正常不是iq_ref设置大小的问题，是编码器不能正确识别，走不到下一步。
感谢您的回复！
,
Green Deng：
你好，问题我已经转述至E2E，E2E上的Yanming Luo是电机控制方面的专家，但是不知道他对CLB了解多少。我加粗标注了你在意的CLB初始化问题，看看工程师的判断是怎样的。
https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1026122/tms320f28379d-using-problem-of-tamagawa-encoder
,
David Lew：
感谢Green Deng的跟进，发现问题后为了避免自己修改代码造成的误判，我重新安装了MCSDK，我确信是在Ti原版的硬件（除了手册上提示的编码器电源飞线）、原版的fcl_f2837x_tmdxiddk项目文件下进行的操作，编译条件如下：
// User can select choices from available control configurations//#define CGND COLD#define BUILDLEVEL FCL_LEVEL2 //仅更换此定义 2、6没问题，其它的都有问题。#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 //
伺服电机我是自购的配置多摩川编码器的4对极400W伺服电机。FCL_LEVEL2或者FCL_LEVEL6正确应该可以排除电机的问题。
我仅仅更换#define BUILDLEVEL FCL_LEVELX 发生了前述相关问题，即FCL_LEVEL2 、FCL_LEVEL6 正常，其它不正常，而FCL_LEVEL6 是在FCL_LEVEL4 基础上增加了SFRA而已，FCL_LEVEL4 却不行，这个也是令我迷惑的。
我觉得这个问题非常隐蔽，在某种组合下才会发生，可能是TXEn和Enc_DI没有达成同步，一旦发生会一直影响下去，反之第二个点一旦正确同步就一直不发生编码器错误。当错误发生时，经过高速RS485串口观察，启动初始化完成后，手动旋转电机轴，观测到的命令发送、编码器数据反馈其实都是正常的。可以理解为不成功的初始化影响到了后续数据的读取及识别。
你们是否可以在同样的条件下测试一下，帮助找到问题根源，谢谢！
,
Green Deng：
你好，问题已经转述。但是我们这边目前没有这个套件的硬件，没办法做测试。不知道英文E2E那边有没有条件
,
David Lew：
我看到英文网站的回复了 ，感谢Green Deng的跟进。 Yanming Luo 说的逻辑上是我能理解的。每个问题都存在根源，我分析代码执行的时机是否存在这样的冲突？分析如下：
目前原版的项目文件在LEVEL2或者 LEVEL6编译条件下（其它配置环境FCL_CNTLR、CURRENT_SENSE、POSITION_ENCODER等如前所述不变），代码经编译器生成代码后，编码器初始化这段正好没有被其它中断或高级别任务打断错位，并不是LEVEL2或者 LEVEL6一定不出现问题，或者其它的LEVELX一定会出问题，当我在不断添加修改代码后，如果编码器初始化代码的运行时机赶上了高级别的中断，是不是后会出现同样的问题，这个是我最担心的，所以按照目前的线索，Ti工程师可以验证一下我描述的这个现象，看能不能找到问题的源头。
，
,
Green Deng：
你好，我把你的问题简化了一下，你看看是否能正确表达你的意思：
在相同的编译条件下，编码器初始化的过程有没有可能被其它中断打断，导致初始化过程出现错位？进而导致编码器校验报错。
,
David Lew：
是的 谢谢！
,
David Lew：
应该是BUILDLEVEL不同 其它编译条件相同
,
Green Deng：
看到昨晚E2E没人回复，我更新了一下回复内容。
,
Green Deng：
你好，E2E反馈没有碰到类似问题，他会再测试一下。
,
David Lew：
我看到了 感谢Green Deng ！
项目环境是原版条件，没有额外代码，我使用的是IDDK2.2.1上的板载仿真器。推荐在FCL_LEVEL1、FCL_LEVEL2之间测试（其他编译条件保持），FCL_LEVEL1偶尔可以，FCL_LEVEL2一直可以，这个很有代表性，一定能发现，希望能够找到问题根源，谢谢！
,
Green Deng：
不客气，应该的
已经更新你的回复了，留意查看哈
,
David Lew：
Hi Green Deng，
感谢跟进，我在MCSDK 3.0.1、3.0.0版本下均做了测试
硬件条件 IDDK2.2.1 软件环境 IDE CCS10.4.0.00006
编译条件如下：#define CGND COLD#define BUILDLEVEL FCL_LEVELX？ //仅更换此定义 #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 //
经测试MCSDK3.0.1、3.0.0仍存在前述症状，即FCL_LEVEL2总是可以，其它FCL_LEVEL1,3~6都不同程度的存在编码器校验错误，但是比3.0.2要好一些，FCL_LEVEL1,3~6偶尔是正确的，而更旧的3.0.0此3.0.1情况更好，较大概率编码器校验正确。
这三个版本都有一个特征，就是一旦编码器正确或错误，只要不复位，这个状态会一直保持，直至复位重新运行会有新的结果出现。
谢谢GreenDeng！期待你们进一步分析反馈！
,
Green Deng：
好的，已经更新了
另外我再贴一下链接，方便你查看：e2e.ti.com/…/tms320f28379d-using-problem-of-tamagawa-encoder
