[参考译文] AM3356：TI 和 TO 的 ISR 经常在 PROFINET IRT 上丢失

TMG 是 TMG 技术和工程有限公司(TMG TE)  

Andy、您好！

我们将  最后进行测试以重现此问题、并将在明天之前提供更新。

此致、
拉克斯曼

Andy、您好！

很抱歉耽误你的时间。

我们试图在我们这边重现此问题、但我们面临一些设置问题。 将解决这些问题并在星期一之前提供相关的更新。


感谢您的耐心等待、
拉克斯曼  

Andy、您好！

我们正在观察到 ISOM ISR 缺失的一些问题。 我们将就此积极开展工作，并将在下周前提供最新进展情况。

同时、您可以回答以下问题、以 确保没有设置差异：

1) 1)您对 TI 和 TO 都使用 ISOM 中断模式？ 或者您是否也在使用 ISOM GPIO 模式？

2) 2) 您是否观察到 TI 和 TO 上的 ISR 缺失？ 如何检查 ISR 命中和缺失？

3) 3) 传递给"PN_ISO_initGPIOEven"的参数是什么？ 主要是 TI 和 TO 的"计时值"和"持续时间"。

感谢您的耐心。

此致、
拉克斯曼

1) 1)您对 TI 和 TO 都使用 ISOM 中断模式？ 或者您是否也在使用 ISOM GPIO 模式？

ISOM 中断模式

2) 2) 您是否观察到 TI 和 TO 上的 ISR 缺失？ 如何检查 ISR 命中和缺失？

我监控了 2 TDC 之间的 ISOM 中断计数。 当 CACF 为1时，正常 计数应为2。 我发现它通常不是2。

3) 3) 传递给"PN_ISO_initGPIOEven"的参数是什么？ 主要是 TI 和 TO 的"计时值"和"持续时间"。

To_IsoMHandle=PN_ISO_initGPIOEvent(appPnHandle,PNISO_MODE_GPIO,to_ns,1000); //If duration is set too low ,it will cause loss of Ti/To interrupt
Ti_IsoMHandle=PN_ISO_initGPIOEvent(appPnHandle,PNISO_MODE_INTERRUPT,ti_delay_ns,1000);

TI 时间 和时间来自 PLC。 TI 时间=250ns、到时间=375ns、TDC 时间=1ms。

TO_ns =至时间= 375。

TI_DELAY_ns = TDC 时间- TI 时间= 1000 - 250 = 750。

Andy、您好！

感谢您的答复。

您能否尝试 使用大于10us 的值设置"ti_delay_ns"和"to_ns"。 这是因为在每个周期的开始时、SYNC 信号需要一段时间来进行配置。

我监测了 2 TDC 之间的 ISOM 中断计数。 当 CACF 为1时，正常 计数应为2。 我发现它通常不是2。

在本例中、计数值是多少？ 您收到的是至少1个中断还是没有中断？

TI 时间 和时间来自 PLC。 TI 时间=250ns、到时间=375ns、TDC 时间=1ms。

TO_ns =至时间= 375。

TI_DELAY_ns = TDC 时间- TI 时间= 1000 - 250 = 750。

[/报价]

t_dc 是1ms 对吧？ 因此 ti_delay_ns = 1,000,000 - 250 = 999,750ns。 根据该计算结果、ISR 的发送可能会有一些延迟。 因此、如果新周期开始、则此 ISR 可能会丢失。 您能否尝试减小 ti_delay_ns 并 重复该实验一次？

谢谢。此致、
拉克斯曼

尊敬的 Laxman：

感谢您的回复！

1."   现在、尝试使用大于10us"的值设置"ti_delay_ns"和"to_ns"、它是关键。 我会继续测试很长时间。

当 ISR 未命中时、计数值为1。

3.很抱歉,我在上一篇文章中错误地描述了它。 我的实际配置是正确的、从未改变。

对说明进行更正：

TI 时间 和时间来自 PLC。 TI 时间=250us、到时间=375us、TDC 时间=1ms。

TO_ns =至时间= 375000。

TI_DELAY_ns = TDC 时间- TI 时间= 1000000 - 250000 = 750000。

此致、

安迪

尊敬的 Laxman：

当 RT 和 IRT 器件都在网络上工作时，PLC 在2-3小时后出现"生命信号丢失"错误。 但是，当只有 IRT 设备在网络上工作时，就可以了。

此致、

安迪

Andy、您好！

感谢您提供长期测试结果。 您能否回答几个问题、以确认我是否正确理解了错误？

1) 1)在出现"生命周期信号丢失"错误之前、您是否没有观察到任何 ISR 缺失？

2) 2)您说的"生命信号丢失"错误是什么意思？ 您是否在 TIA 门户中观察到"生命信号丢失"错误？ 如果是、在错误发生后、您是否在两个器件上都能看到绿色勾号？ 您能否提供一些背景截图？

此致、
拉克斯曼

尊敬的 Laxman：

1）我没有观察到任何 ISR 缺失。 因此、我怀疑 TI 和损失是故事的一部分、而不是整个故事。 现在、当持续时间更改为20000时、不会错过 TI 和至。

可能是 PRU 转发了 RT 数据包导致了 IRT 处理错误。 我只是在猜测。

2）是在 PLC 诊断缓冲器和 PLC 的 PositioningAxis 技术对象中。 但是、该 器件没有 生命体征故障、器件也在进行监控。 出现错误时、两个设备上的勾号始终为绿色。

此致、

安迪

Andy、您好！

很高兴知道、当持续时间更改为20us 时、您没有观察到任何 ISR 缺失。 我们将进行长期测试、以检查我们是否在 TIA 门户上获得类似的输出。
此外、我们还将研究更改持续时间如何影响 ISR 下降。  

关于"定位轴技术"的几个问题：

1)它看起来该对象默认情况下不存在,您是否在 TIA 门户中添加此对象? 如果是、您能否告诉我们您为该对象设置了哪些参数以便我们一方重现问题？

2) 2) 您是否能够在不添加对象的情况下观察 PLC 诊断中的任何日志？

此致、
拉克斯曼

尊敬的 Laxman：

1）我添加了"TO_PositioningAxis"

2)应添加 TO_PositioningAxis。 我将其删除、然后重新编译该项目。 它有错误。

我认为 PROFIDRIVE 中的生命体征监测机制信号相对于 PROFINET IO 对于数据包丢失的容差较低。

可能您无法重现该错误、因为仅添加了 PROFINET IRT IO 应用。

此致、

安迪

Andy、您好！

感谢您的操作。 我们将在不添加对象的情况下检查问题是否可重现。

在我们这边、我们已经实现了设置工作、并测试了具有不同配置的设置。

1) 1)我们观察到、只有一个 IRT 器件连接到 PLC、我们没有观察到 TI 和 TO 出现任何 ISR 缺失。

2) 2)但是、当两个 IRT 器件连接到 PLC 时、直接连接到 PLC 的 DUT 没有任何 ISR 缺失、但第二个 DUT 确实有 ISR 缺失。 如果我们将持续时间更改为20000ns、那么我们在两个器件中都不会看到任何 ISR 缺失。

3) 3)同样对于一个 IRT 和 RT 器件、也会发生到 ISR 的缺失。 如果我们将持续时间更改为20,000ns、则不会发生 ISR 缺失  

我们目前正在调查此行为、下周将向您汇报有关此问题的进展。

感谢您的耐心等待、
拉克斯曼

尊敬的 Laxman：

我发现了一些新东西。 当 IRT 和 RT 混合时、IRT 器件中的 PN_cpmIsrHandler 偶尔会缺失。 因此 PLC 没有接收到 它预期的生命值信号。 "持续时间"为20000ns、对于 TI 或 TO、不应出现 ISR 缺失。

此致、

安迪

Andy、您好！

我们将在我们身边测试一次、并在本周结束时与您联系。

与此同时、您能否确认一次、对于上述阈值、您看不到 ISOM ISR 缺失有任何问题？
此外、当 Pn_cpmIsrHandler 缺失时、您是否观察到任何 ISOM ISR 缺失？

此致、
拉克斯曼

尊敬的 Laxman：

ISOM ISR 正常、未错过。

此致、

安迪

Andy、您好！

感谢您的及时响应。

由于此问题已修复、因此请创建一个 单独的 E2E 主题、详细讨论 CPM ISR 缺失。  

此致、
拉克斯曼