Неожиданные ответы устройств Zaber в LabVIEW

Причина

Наиболее распространенная причина этой проблемы заключается в том, что вы использовали ВП Write Command для отправки команды, но никогда не читали ответ. Этот ответ находится в приемном буфере последовательного порта, пока вы его не прочитаете. Если позже вы воспользуетесь ВП Request Command, он запишет новую команду, а затем прочитает ответ от старой команды, которая все еще находится в буфере.

Это может запутать ваш код, если вы используете значения данных ответа для выполнения вычислений, но может быть еще хуже, когда вы запрашиваете команду перемещения. Способ, которым ВП Request Command узнает о завершении движения, заключается в том, что устройство отправляет ответ. Если в буфере уже есть ответ, то похоже, что движение закончилось сразу. Ваш ВП будет выглядеть так, как будто он пропускает команды движения.

Вот неправильный пример, показывающий, как может возникнуть проблема. Команда Move Relative не завершится до отправки команды Move To Stored Position. Все три следующих примера можно загрузить с нашего веб-сайта.

Другой способ вызвать такого рода проблемы — отправить команду нескольким устройствам с нулевым номером устройства и прочитать только первый ответ. (Каждое устройство отправит свой собственный ответ.) Вы также можете вызвать проблемы, если используете ручку ручного управления или джойстик во время работы ВП. Это движение будет генерировать кучу ответов, когда ваш ВП ничего не отправлял.

Решение 1. Запрос команды VI

Самое простое решение — убедиться, что вы читаете каждый ответ на каждую команду. Если вы используете ВП Request Command для каждой команды, он будет корректно обрабатывать большинство ситуаций.

Вот исправленная версия предыдущего примера, в которой теперь используется ВП Request Command.

Если вы отправляете команду на все устройства, используя нулевой номер устройства, вам придется настроить счетчик ответов, чтобы он знал, сколько ответов ждать.

В более сложных сценариях, таких как одновременное перемещение двух устройств, вы можете использовать ВП Write Command в сочетании с ВП Blocking Read Response, чтобы гарантировать получение всех ответов. Дополнительные сведения см. в примере одновременных запросов.

Это решение не поможет, если вы используете ручку ручного управления или джойстик во время работы ВП.

Решение 2. Очистка буфера

Возможно, у вас есть сложный ВП, в котором уже есть множество операций записи, и вы не хотите очищать их все, или, может быть, вы хотите использовать ручку ручного управления или джойстик во время работы ВП. Возможно, шаблон ответа не является полностью предсказуемым по какой-то другой причине. Если вы не можете избежать появления лишних ответов в буфере, вы можете очистить их, когда сумасшествие закончится. Просто используйте ВП Read Response (не блокирующий) и продолжайте читать, пока он находит ответы.

Вот тот же пример, который теперь очищает буфер. Он делает паузу на десять секунд, чтобы вы могли использовать ручку ручного управления для создания дополнительных ответов.

Одна хитрость с этим решением заключается в том, чтобы знать, когда сумасшествие закончилось. В идеале устройства не должны двигаться, и вы должны подождать не менее 20 миллисекунд, прежде чем начать очистку буфера. Это дает устройствам время обработать последнюю команду и отправить ответ. Если устройства все еще движутся, вы получите дополнительный ответ, когда они, наконец, закончат работу.

Решение 3. Конечный автомат

Если ваш ВП действительно сложен или непредсказуем, шаблон конечного автомата может быть надежный подход. Вместо того, чтобы тесно связывать каждый запрос с его ответом, ВП отслеживает глобальное состояние и обрабатывает каждый ответ отдельно. См. другой пример в Write Commands and Read Responses VI Zaber.

Этот подход также полезен, если у вас есть параллельные циклы, отправляющие команды. У вас не может быть двух циклов чтения из последовательного порта одновременно.