[参考译文] THVD1450：在短时间内作为从器件连接到 Modbus 网络后、不接收数据包！

THVD1450没有任何此类状态。

请在 R 和/RE 引脚处使用示波器或逻辑分析仪检查数据是否来自 THVD1450。

您好、Jabir、

提到的 A s Clemens 器件实际上并不是您所说的模式-您是否根据相关器件上的 Rx 表验证了电压：

这决定了"R"引脚状态(接收到的数据流)。 这将是发行时 A/B//RE 和 R 的度量。  

系统中还有多少个节点(总线上有多少个 RS-485收发器)？

系统是否已终止？ 如果是-什么是端接、系统中哪里有端接电阻器？

使用了哪种电缆或传输线路？

所需的应用数据速率是多少？

根据上述问题的答案、可以帮助我了解它是否只是应用问题(即如何使用所有内容)、或者是否存在更大的问题。 从您完成的初始测试来看、长度似乎是一个很大的影响因素-但我不确定其程度。  

请告诉我、以便我可以帮助我尝试找到问题的最根本！

最棒的

Parker Dodson

大家好、Clemens 和 Parker、

非常感谢您抽出时间回答我的问题。

如有疑问、请在下面找到答案、

这决定了"R"引脚状态(接收到的数据流)。 这将是发行时 A/B//RE 和 R 的度量。 - R 始终读为高电平

系统中还有多少个节点(总线上有多少个 RS-485收发器)？ －专为21个系统设计，但仅对3-4个系统测试此问题

系统是否已终止？ 如果是-什么是端接、系统中哪里有端接电阻器？ －已尝试使用和不使用终端。 120欧姆。 误码率并不是我们的全部问题、因为在这个问题发生之前、我们没有任何单个数据包丢失

使用了哪种电缆或传输线路？ －CAT 6三芯电缆

所需的应用数据速率是多少？ －仅9600。

让我再次强调一下有关该系统的信息。 在实验中、我们迄今尚未发现此问题。 在现场、系统正在进行完美通信、直至出现此问题。 在现场正常工作的持续时间可以随机为3到10分钟。 此外、如果我们重新接通电源、则器件会立即开始通信。 但是、如果在 MCU 停止时保持电源不变、则通信仍处于相同的未接收状态。

谢谢、此致

-Jabir

请检查/re 是否为低电平。 如何控制它？

是否可能存在大于±18V 的噪声？ 电路是否具有针对这种情况的保护？

大家好、Clemens、

RE 由微控制器控制、并在我们将调试器连接到系统时确保其保持低电平。  

对于您的评论- 是否可能存在大于±18V 的噪声？ 电路是否具有针对这种情况的保护？

1) 1)如果是这种情况、其他系统也会停止 RT 工作。 在四个测试设备中、每个设备将在完全不同的时间点(随机持续时间为2到15分钟)丢失通信。

2) 2)为了保护-我们在此不讨论损坏情况。 当我们对系统进行下电上电时、它非常健康、 并且对我们的主器件发送的命令做出响应。

我想提请大家注意这个电源循环场景、以便我们能够了解实际情况。

谢谢、此致

-Jabir

此器件没有任何内部状态；它不应锁定。

我唯一的解释是总线或电源引脚上的某些电压超出范围。 您能否现场显示这些引脚的示波器迹线？

您好、Jabir、

我不认为它首先是一个损坏问题-这似乎不是基于你所分享的一切。

话虽如此-如果 R 变为高电平并一直保持这种状态-则可能是器件响应"故障"条件(开路总线、短路总线、 或空闲总线)、并将输出高电平(这实际上与器件的状态不同-其内部阈值将电压计数为-20mV 或更高的逻辑高电平、从而防止空闲/短路/开路情况可能发生振荡)  

如果在现场发生这种情况、我的问题是实验室测试和现场测试之间有什么不同-是长度还是有更多变化？

确定问题的下一步是测量相关接收器处的 A/B 总线。 我想您将看到的是、系统运行几分钟后、电压将下降、并且可能始终错误地读取逻辑高电平。 此测试将告诉您/客户和我是否是实际的接收器问题、或者系统中是否存在导致衰减的某些事件-这可能是可变的、但此时可能是100%系统级问题、与收发器无关 本身-我不能说、如果情况确实如此、100%确定、但了解接收器 A/B 引脚的电压电平是隔离所发现问题的下一个最佳步骤。

请告诉我是否可以从现场收集这些结果、因为问题似乎是现场特定的、我不确定在这种情况下实验室是否能够充分捕获真实系统。

最棒的

Parker Dodson

您好、Parker、  

感谢您的详细分析。 我想您已经提到了 Clemens 以及 viz 提到的一点："该器件没有任何内部状态"、数据表页号19第9.3节第2段中提到了这一点。  

我还同意器件可能处于数据表中提到的状态之一。 这为我们留下了两个选项、如下所示：

1) 1)如果出现此状态是由于原因之一或 Parker 提到的原因、那么为什么不会发生在同一系统附近的另一个器件上

 在以上各点添加观察结果

A. 我们在总线上启用了多个系统(例如4个数字、最远、最短、中间2个相对于主器件)。 这些设备中的任何一个都不能随机响应。有时我们会先丢失最短的数据，有时会丢失中间和最远的数据。 希望这会点亮总线的电压状态。

B. 如果总线的电压电平是问题、为什么没有两个器件在同一时刻停止响应。

2) 2)我不想得出接收器有问题的结论。 但我们几乎可以确定接收器将进入其故障状态之一、即除空闲条件外、不是短路或开路(理论上)。 如果我们假设它假定为空闲状态、那么我的主要问题是如何以编程方式使驱动器脱离空闲故障状态。 解决此问题的方法可能是解决我当前提出的问题的一个很好的方法。 稍后可以正确确定问题的特征、以便进一步分析。

注意：实验室和归档差异仅是对长度的细微增加。 实验室我们使用300米(仿真限值时最坏的导线长度)进行了测试、在存档中、使用 CAT6电缆时的长度仅超过400米。

将器件从空闲故障状态中退出的解决方案本身将有助于制定更多测试用例、从而确定问题的特征。 那么、我们来看看这方面的一些提示。

谢谢、此致

-Jabir

在分享了这么多信息后、似乎没有足够的信息。 考虑到这种测试情况、系统的 VCC 情况以及所有情况 都可以很容易地理解。

Jabir

您好、Jabir、

我不认为它的长度- 400m 时9600bps 在正常情况下不应该成为问题-由于有问题的单元是独立于长度的、我怀疑它是一个衰减问题(它不应该基于运行规格)

如前所述、没有内部状态-因此接收器的总线空闲模式只是一个逻辑高电压。 除非 A/B 电压寄存器为低电平状态、否则不会导致它切换到低电压。 了解1.如果这实际上是问题；2.对于通信失败的器件、A/B 信号的外观对于查找解决方案至关重要。 根据 我现在掌握的信息、我实际上只能假设设计正常(在实验室中进行了测试-稍短的长度可能不会产生如此大的影响) 因此、来自现场系统的信息非常重要、因为当我不确定问题时、我没有解决方案-我可以猜测、但这不会更有帮助、因为只有我列出了示波器快照将为我提供更多信息时的所有可能结果 我们将提供足够的信息来深入探讨这一问题。

最棒的

Parker Dodson