我觉得可能是你的理解和我不一样。

这个功能块的EN是调用这个功能，每次调用，就与CM模块“打交道”。

（可以是每个扫描周期都调用它，也可以是定时调用它。）

每次当DONE完成时（是CM模块通讯完成，接收到了响应报文。），下次将传送该功能块的参数（这时你的参数已经换成新的地址，数据。）

而REQ是需要一个上升沿（可以是一个扫描周期的P脉冲，或者是0 -> 1，直到DONE / ERR都可以。）

每次上升沿出现，就传送一套接口的参数给CM模块，参数化启动通讯。所以，不可以在通讯未完成、还在发送或等待接收或正在接收时，出现REQ上升沿（这样就通讯失败了）。

如果你只有初始有一个上升沿REQ（一直置一，在首次调用时，实际上原来的0变成1，也是上升沿。），那么当BUSY一直置一，而其他=0时，即便超时，它再次传送的还是原来的接口参数。所以你就卡在那里了！

其实，如果你关注一下功能块的背景数据块，可以看到它正在做第几次重试。可以据此，判断通讯状态，或者选择第二次重试后，抛弃该站。做报警处理。