Проблема с запуском VISA-контроля в сеансе tmux, в Gotty - PullRequest
0 голосов
/ 15 января 2020

Я создал тестовую настройку, которая управляется Raspberry Pi 3, работающей под управлением Raspbian Buster. Основная цель состоит в том, чтобы взять последовательность испытаний из другой системы, управлять определенными тестерами RF, контролировать тестируемое устройство и сообщать результаты обратно в другую систему.

Одним из контролируемых тестовых устройств RF является генератор сигналов Agilent N5181A, который управляется через USB-кабель с использованием команд libvisa и vi sh из репозиториев Raspbian. Мне пришлось создать следующее правило udev, чтобы можно было использовать vi sh без sudo:

SUBSYSTEM=="usb", ATTRS{idVendor}=="0957", ATTRS{idProduct}=="1f01", GROUP="plugdev", MODE="0666"

Управляющий сценарий (фактически, набор bash сценариев) может быть успешно выполнен в tmux. Сначала я запускал эти сценарии из crontab, и это было успешно:

/usr/bin/tmux new -d -s rf_tester /home/user/scripts/test_runner.sh

Затем я хотел иметь возможность удаленного мониторинга этих сценариев, поэтому я попытался выполнить сценарий в «gotty» ( https://github.com/yudai/gotty/ - v2.0.0-alpha.3). Если я сначала запускаю сеанс tmux, как описано выше, а затем создаю новый сеанс tmux, в котором я присоединяю существующий сеанс, который будет выполняться с помощью gotty, все работает нормально.

/usr/bin/tmux new -d -s gotty_session /home/user/bin/gotty /usr/bin/tmux attach-session -t rf_tester

Однако , если я запускаю сценарий непосредственно в сеансе gotty, то контроль VISA не работает. Он ведет себя так, как если бы он выполнялся без использования правил udev, то есть он просто не может получить доступ к генератору сигналов Agilent. Не имеет значения, даже если команда vi sh вызывается с использованием sudo.

Здесь интересно то, что я выделил элемент управления VISA так, что он вызывается через curl, например:

curl -s "http://localhost/set_siggen.php?frequency=800&level=-10"

И соответствующий скрипт php:

<?php
$freq=$_GET['frequency'];
$level=$_GET['level'];
$mycmd = "sudo -u user ssh localhost \"/home/user/scripts/set_siggen.sh ".$freq." ".$level."\"";
$output = shell_exec($mycmd);
?>

Окончательный сценарий управления VISA выглядит следующим образом:

#!/bin/bash
freq=$1
level=$2
cat /home/user/scripts/agilent_n5181a_commands.txt | sed "s/frequency/$freq/" | sed "s/level/$level/" | vish USB1::0x0957::0x1f01::MY47421271 > /dev/null

У меня есть похожие контрольные URL-адреса и скрипты для других тестеров, так что я могу контролировать их по сети. Управление другими тестерами работает нормально.

Есть ли у кого-нибудь идеи, почему не работает аппаратный доступ (то есть команда "vi sh"), когда основной скрипт выполняется непосредственно под gotty, но это работает нормально, если скрипт сначала запускается в tmux, а затем передается для выполнения в gotty?

Это не имеет смысла для меня, поскольку скрипт управления аппаратным обеспечением VISA выполняется в совершенно другой оболочке (S SH looping), чем там, где выполняется сценарий управления фактическими измерениями.

...