Отправлено: 22.04.20 20:47. Заголовок: Странная работа камер Sony SRG по UDP

Добрый день!

Может кто в курсе. Есть две камеры - Sony SRG-300H и 120DH. Переключатели снизу установлены в режим LAN (не serial). Подключены через компоненты UDP, порт 52381.
Так вот управляются они как-то странно. При вращении могут сами продолжать движение, до упора, когда кнопка в интерфейсе уже отпущена. В основном приходится ряботать короткими нажатиями.
И еще, судя по всему, пресеты запоминаются один раз на 10 попыток, не меньше. Появляется фидбек, что камера в режиме сохранения пресета, выбираем пресет, фидбек гаснет. При вызове пресета
камера переходит в какое-то другое положение, похоже, "Hоме".

Пробовал модуль с маркета - Sony SRG-300SE IP v1.0. Если я правильно понял, стандартные команды Visca здесь не работают. Т.е. нельзя просто их взять и перенаправить на TCP и порт 1259, как для камер Minnray
например. Во всяком случае, Sony с стандартным модулем Visca не заработала.

 Отправлено: 22.04.20 23:45. Заголовок: Надо проверять как в..

Надо проверять как в драйвере обрабатываются события нажатия (push) и отпускания (release). Первому обычно сопоставляется команда начала движения камеры по наклону/повороту, второму - остановка. Не закрывается ли подключение по UDP после отработки события push? Что же касается обратной связи (feedback) о нахождении камеры в режиме сохранения preset, то во всех известных мне драйверах камер она эмулируется.

 Отправлено: 23.04.20 00:54. Заголовок: Смутно припоминаю, к..

Смутно припоминаю, коллега тоже говорил что модуль с маркета не заработал. Пришлось допиливать, так как команды отличались немного (не хватало какого то параметра)
То что не стопится при команде остановки отправляемой по релизу, это болезнь какая я то IP камер (с панасом такая же фигня бывает). Пробуйте дублировать команду останова, тем более что UDP

 Отправлено: 23.04.20 10:06. Заголовок: http://crestron-cons..

Никогда не было проблем с управлением камерами такого типа.
Проверьте настройки, ping, загрузку коммутатора.
Скрин настроек рабочей программы ниже. Модуль без изменений из Appmarket.

 Отправлено: 23.04.20 12:58. Заголовок: Спасибо за ответы. ..

Спасибо за ответы.

Пока сбоит, к сожалению. Позиционирование работает более или менее нормально. А вот пресеты - как повезет. Просто не записыватся, как правило. Сам склоняюсь, что нужно сеть проверить для начала.

IP модули камер подключены к общему модулю наведения камер. Сначала выдается импульс (0.15 сек), который переводит IP-модуль нужной камеры в режим сохранения пресета. А потом подается такой же примерно
импульс на вход нужного пресета этого же модуля. Фидбек режима сохранения пресета тут же выключается. Вроде все штатно. Пробовал менять длительность импульсов в неких пределах, но явно не этом дело. Описанная логика до этого работала с другими Visca камерами годами. Драйвер камеры был, конечно, другой.

 Отправлено: 23.04.20 13:07. Заголовок: O la-la, а попробуйт..

O la-la, а попробуйте для каждой камеры свой драйвер, как в примере выше.
Пресеты сохраняются внутри камеры.

 Отправлено: 23.04.20 13:52. Заголовок: Вероятно, я не совсе..

Вероятно, я не совсем подробно объяснил. Драйверов - три. По числу камер. Каждый драйвер подключен через индивидуальный компонент UDP со своим адресом. А модуль наведения - просто коммутатор сигналов Вверх, Вниз...
и пресетов. После него управляющие воздействия попадают на драйвер нужной камеры. Пробовал кстати на UDP делать Enable=1 - не помогает. Выше была интересная версия, что разрывается соединение.

 Отправлено: 23.04.20 14:01. Заголовок: По UDP нет никаких с..

По UDP нет никаких соединений. Отправили цепочку данных по адресу и порту и все, что на том конце - нас не волнует.
СКорее всего, не соблюдаются таймауты или сетевые настройки мешают.

 Отправлено: 23.04.20 14:50. Заголовок: С проблемой при сохр..

С проблемой при сохранении пресетов я сталкивался, модуль запрашивает сначала позицию по наклону и повороту, а после получения ответа мгновенно запрашивает зум. Нужно добавить небольшую задержку на запрос зума и все заработает.

 Отправлено: 23.04.20 14:57. Заголовок: Вот так: https://i.p..

Вот так:

 Отправлено: 23.04.20 15:03. Заголовок: PG, у вас про класси..

PG, у вас про классическую VISCA история, справедливо ли такое решение для UDP?

 Отправлено: 23.04.20 15:28. Заголовок: Admin пишет: PG, у ..

Admin пишет:

цитата:

PG, у вас про классическую VISCA история, справедливо ли такое решение для UDP?

На скриншоте модуль Sony SRG-300SE IP v1.0.umc. Пока не добавил задержку камера не отвечала на запрос по зуму, а без этого модуль соответственно не сохранял пресет.

 Отправлено: 23.04.20 16:58. Заголовок: PG пишет: а после п..

PG пишет:

цитата:

а после получения ответа мгновенно запрашивает зум

Вот спасибо!

А я еще с утра сохранил вот этот кусочек из лога, но ничего подозрительного не заметил.:

00:00:01.625 \x01\x00\x00\x05\x00\x00\x00\x38\x81\x09\x06\x12\xFF To_Cam_2
00:00:01.625 \x01\x11\x00\x0B\x00\x00\x00\x38\x90\x50\x0F\x0E\x00\x00\x00\x02\x07\x07\xFF From_Cam_2
00:00:01.625 \x01\x00\x00\x05\x00\x00\x00\x39\x81\x09\x04\x47\xFF To_Cam_2
00:00:01.641 \x01\x11\x00\x07\x00\x00\x00\x39\x90\x50\x00\x00\x00\x00\xFF From_Cam_2


Камера вроде отвечает. Но возможно ответ не правильный! Сейчас для начала попробую задержку.

 Отправлено: 23.04.20 17:45. Заголовок: Вполне возможно, на ..

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

 Отправлено: 23.04.20 20:06. Заголовок: Добавил задерку от P..

Добавил задержку от PG - заработало. Спасибо!

Хотя причина мне пока до конца не ясна. Камера же отвечала? Отвечала. Но первые три посылки (на камеру, от камеры, и опять на камеру) происходили по отладчику практически "в один момент времени" Модуль, что ли, не успевал обработать первый или второй возврат от камеры....

 Отправлено: 24.04.20 07:22. Заголовок: В моем случае ответа..

В моем случае ответа на второй запрос не было вообще:
00:01:47.203: ZAL_SNY_Cam_tx$ -> \x01\x00\x00\x05\x00\x00\x00\x0E\x81\x09\x06\x12\xFF //pan-tilp pos inq
00:01:47.219: ZAL_SNY_Cam_rx$ -> \x01\x11\x00\x0B\x00\x00\x00\x0E\x90\x50\x00\x08\x0E\x05\x00\x00\x00\x00\xFF //pan-tilt pos
00:01:47.219: ZAL_SNY_Cam_tx$ -> \x01\x00\x00\x05\x00\x00\x00\x0F\x81\x09\x04\x47\xFF //zoom pos inq

У вас ответ приходит, но с нулевыми координатами: \x90\x50\x00\x00\x00\x00\xFF From_Cam_2 - они должны быть тут вместо нулей.

 Отправлено: 24.04.20 10:59. Заголовок: Много лет назад, ког..

Много лет назад, когда еще небыло камер с управлением по http & UDP занимался VISCA, со шлейфовым включением.
При доводке драйвера внимание пришлось уделять:
1. Ожиданию ответов от камер на выдачу команды от контроллера, пока не приходило два ответа ACK/Completion Messages (правильности команды и ее исполнения).
если подавать следующую команду до приема этих ответов приходила ошибка и команда не исполнялась.
2. Минимальная пауза для отправки команды после получения всех подтверждений от камеры - 20 msec (указано в Timing Chart разделе описания)
Это значит, что ко времени отработки камеры прибавляются еще эти 20 msec, если модуль не отрабатывает прием ответов камеры и получает ошибку или пустой ответ.
Наиболее вероятно, в нашем случае происходит именно это - в модуле с Appmarket не обрабатываются ответы от камеры и тайминг не соблюдается на 100%
В случае с UDP скорость работы не намного выше, и камера не успевает сформировать ответ с данными о текущем zoom-e.

 Отправлено: 25.04.20 23:05. Заголовок: Подтверждаю вышесказ..

Подтверждаю вышесказанное.
Недавно писал модуль для VISCA Over IP под Иридиум, как раз глядя на этот модуль с апп-маркета.

Логика в нем заложена, в целом, верная, но очень "оптимистичная".
Нет вообще никаких задержек между командами.
Автор думал, что сетевая карта и камера сами разрулят.
Например в режиме "Proportional Pan-Tilt" вместе с каждой командой Pan-Tilt отправляется команда Inquiry Zoom для получения текущего зума и расчёта скорости Pan-Tilt. И между ними никакой задержки.
Мало того, что камера может не успеть обработать эти команды, так более того, сетевая карта процессора вообще может отбросить один из UDP-пакетов, если их отправляется одновременно несколько. Я, кажется, даже сталкивался с таким именно на Крестроне.
Это же UDP - нет никакой гарантии доставки. Никто не обязан разруливать коллизии. Можно просто выкинуть пакет.

Поэтому я, когда писал свой модуль, во-первых, делал задержки, а, во-вторых, команды Inquiry Zoom отправлял не перед каждым Pan Tilt, чтобы не "засорять эфир", а только после изменения Zoom-а.