labview - LabVIEW中Zaber设备的意外响应

Question

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

Answer 1

原因

此问题的最常见原因是您使用了写入命令 VI 发送命令，但从未读取响应。该响应位于串行端口的接收缓冲区中，直到您读取它。如果您稍后使用请求命令 VI，它将写入新命令，然后从仍在缓冲区中的旧命令读取响应。

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

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

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

解决方案 1：请求命令 VI

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

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

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

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

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

解决方案 2：清除缓冲区

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

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

One trick with this solution is knowing when the craziness has ended. Ideally, the devices should not be moving, and you should wait at least 20 milliseconds before you start clearing out the buffer. That gives time for the devices to process the last command and send a response. If the devices are still moving, then you'll get an extra response when they finally finish.

Solution 3: State Machine

If your VI is really complicated or unpredictable, the state machine pattern can be a robust approach. Instead of closely tying each request with its response, the VI keeps track of a global state, and deals with each response separately. See Zaber's Write Commands and Read Responses VI for another example.

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