[参考译文] AM6442：IND-Comms-SDK：Profinet 警报数据

尊敬的 Kamil：

用户结构标识符= 0x8320（带通道编码的处理警报）是否也是如此？ 据我所知、预计会有一组特定的数据、其中包括 channelNumber、PCAL_channelProperties、PRAL_Reason、PRAL_ExtReason 和 PRAL_ReasonAddValue。 抱歉、我想我的初始问题中缺少该部分。  

如果是这种情况、只是尝试将其序列化到某个字节数组中会感到有点不稳定性、并希望字节顺序和数据大小对所有内容都是正确的。

此致
Philip

您好 Philip：

我只是看了一下标准。 流程警报的 USI 字段似乎可以是“生产特定“或“规范“（例如 0x8320）、因此您的陈述是正确的。

根据快速查看、我没有看到该字段的栈内有任何特殊处理、因此您可能可以在应用中创建一个结构（等效于 PRAL_AlarmItem）并将其用作此函数的输入。 您已经尝试过吗？ 工作正常吗？

只是一个小提示、请确保不超过进程警报有效载荷允许的最大大小 (PN_API_IOD_MAX_PROJECT_ALARM_LEN)。

此致、
Kamil

尊敬的 Kamil：

还没有,我还处于收集 关于如何实施它的信息的早期阶段。 我会在未来的几天尝试,让你知道。

谢谢！

您好、Kamil、很抱歉更新延迟。 我终于来实施并测试了它。  

在 USI = 0x8320 的特定情况下、栈似乎不接受进程警报请求。  

例如、 “Profinet 的 IO 链路集成“规范要求此 USI、因此根据本文档、我使用了一组应有效的输入：

通道编号= 0x8000
属性= 0
原因= 0x9500
ExtReason = 0x6321
AddValue = 0

USI = 0x8320

我将它们序列化到从 Profinet 标准调用到 PRAL_alarmItem 的缓冲区中、并 使用它调用 PN_API_IOD_sendProcessAlarm ()。
对 PN API 的初始调用将返回 PN_API_OK、但在几毫秒后、栈停止并打印一条错误消息、指出是致命错误、没有更多信息。 不向 PLC 发送警报（使用 Wireshark 检查）

如果我执行相同操作、但 USI 设置为低于 0x8000 的值（例如 5）、它将按预期工作。 我也可以在 Wireshark 的警报通知中查看缓冲区中的数据。  

此致
Philip