LabVIEW中Zaber设备的意外响应

Question

当使用Zaber's LabVIEW driver来控制他们的设备时，它有时会返回奇怪的命令响应。例如，发送“移动绝对”命令可能会返回“设置目标速度”响应或“手动移动跟踪”响应，而不是预期的“移动绝对”响应。是什么导致的，以及如何避免？

Answer 1

原因

此问题的最常见原因是您使用写命令VI发送命令，但从未读取响应。在您阅读之前，该响应位于串行端口的接收缓冲区中。如果您以后使用Request Command VI，它将编写新命令，然后从仍然位于缓冲区中的旧命令中读取响应。

如果您使用响应数据值执行计算，这可能会使您的代码混淆，但是当您请求移动命令时可能会更糟。请求命令VI知道移动何时完成的方式是设备发回响应。如果缓冲区中已经存在响应，则看起来运动立即完成。你的VI看起来好像是在跳过动作命令。

这是一个不正确的示例，它显示了问题是如何发生的。在发送“移动到存储位置”命令之前，“移动相对”命令将不会完成。以下所有三个示例都可以从our web site下载。

导致此类问题的另一种方法是使用设备编号零向多个设备发送命令，并仅读取第一个响应。 （每个设备都会发送自己的响应。）如果在VI运行时使用手动控制旋钮或操纵杆，也可能会出现问题。当您的VI没有发送任何内容时，该动作将产生一堆响应。

解决方案1：请求命令VI

最简单的解决方案是确保您阅读每个命令的每个响应。如果对每个命令使用Request Command VI，它将正确处理大多数情况。

这是上一个示例的更正版本，现在使用请求命令VI。

如果您使用设备编号零向所有设备发送命令，那么您必须调整响应计数，以便它知道要等待多少响应。

在更复杂的情况下，例如同时移动两个设备，您可以将Write Command VI与Blocking Read Response VI结合使用，以确保您收到所有响应。有关详细信息，请参阅simultaneous requests example。

如果您在VI运行时使用手动控制旋钮或操纵杆，此解决方案将无济于事。

解决方案2：清除缓冲区

也许你有一个复杂的VI，已经有一堆写，你不想全部清理它们，或者你想在VI运行时使用手动控制旋钮或操纵杆。由于某些其他原因，可能无法完全预测响应模式。如果您无法避免在缓冲区中获得额外响应，则可以在疯狂结束时将其清除。只需使用读取响应VI（不是阻塞响应VI），只要找到响应就继续读取。

这是现在清除缓冲区的相同示例。它会暂停十秒钟，因此您可以使用手动控制旋钮产生一些额外的响应。

这个解决方案的一个技巧是知道什么时候结束了疯狂。理想情况下，设备不应移动，您应该在开始清除缓冲区之前至少等待20毫秒。这为设备提供了处理最后一个命令并发送响应的时间。如果设备仍在移动，那么当它们最终完成时你会得到额外的响应。

解决方案3：状态机

如果您的VI非常复杂或不可预测，state machine pattern可能是一种强有力的方法。 VI不是将每个请求与其响应紧密联系在一起，而是跟踪全局状态，并分别处理每个响应。有关另一个例子，请参阅Zaber的Write Commands and Read Responses VI。

如果您有并行循环发送命令，这种方法也很有用。您不能同时从串行端口读取两个循环。