Форум » » ADA Cinema Rapture У кого есть протокол? » Ответить
ADA Cinema Rapture У кого есть протокол?
Zerberus: Собственно, сабж. Есть ли у кого-нибудь протокол управления для ADA Cinema Rapture по IP. Куда у него стучаться и прочее. Буду премного благодарен.
Ответов - 31, стр:
1 2 All
Igor: Zerberus, а есть ли уверенность что данное изделие вообще управляемо по IP? С ADA работал давно, тогда все было как-то неоднозначно - приходилось использовать нигде не дешевый шлюз с RS232 на их шину. Можно посканить прибор на предмет открытых портов. Если открыт Telnet, можно постучать туда известными командами.
Zerberus: Есть, однозначно. Они в этой железяке используют плату NetBurner SBL2e. Это такой мост из ethernet на UART. В принципе, я нашёл уже протокол, который, естественно, совпадает с протоколом по RS 232. Собственно, через UDP работает и их программа для конфигурации. Другая проблема вылезла. Crestron как-то криво работает с UDP. Точнее, совсем не работает. Я открыл порт для UDP на ПК и попытался слушать, что будет слать крестрон. Услышал тишину. Вайршарк тоже не показывает никаких пакетов UDP исходящих из него. Отправил всё это дело со скриншотами в наше представительство крестрона. Пока жду результаты. Возможно, где-то я туплю.
Zerberus: Upd: Удалось всё-таки поженить две железки. По какой-то причине UDP/IP символ не работает. Всё завелось в SIMPL+.
Вячеслав: Блоком UDP/IP Communication ни когда не сталкивался, по описанию вообще непонятно что это за сторона сервер или клиент или определяется IP адресом. Хотя описание параметра Port намекает скорее на сторону клиента (The port number of the target device) Но вот в simpl+ UDP_SOCKET я использовал исключительно как сторону сервера и это работает. Так что есть вероятность, что вы расцениваете сторону Crestron как клиент, который должен подключаться к серверу на ПК, а надо наоборот делать. Может Crestron и не умеет клиентом UDP выступать. Впрочем это лишь предположения и коллеги поправят.
Zerberus: <zanudamode> Не очень правильно называть что-либо связанное с протоколом UDP сервером или клиентом. Правильнее - получателем или отправителем, так как нет установки соединения (рукопожатия) и отправителю всё равно, получил ли правильно или вообще не получил получатель данные. Вспоминаем, как устроен заголовок у UDP: [порт отправителя]; порт получателя; длинна датаграммы; [контрольная сумма] , в квадратных скобках - необязательные поля. Крестроновский символ UDP/IP - есть отправитель, так как тот самый the target device - как раз получатель, на который посылать данные. Есть один момент. Так как в заголовке всё-таки есть хоть и необязательное поле [порт отправителя], а в псевдозаголовке IP есть адрес отправителя, получатель что-то всё-же может отправить в обратку отправителю. Скорее всего этим и обуславливается сериальный выход RX символа UDP. Но обычно, для двухсторонней связи просто берут пару портов - один чётный, другой - следующий за ним нечётный. В чётный кидают команды, из нечётного получают данные. То есть, в случае с крестроном, нужно два символа - один кидает данные на тот порт, который открыт у устройства, второй символ слушает свой собственный порт на собственном интерфейсе. </zanudamode> Но символы не работают, или я ими не правильно пользуюсь. В любом случае, подождём официального ответа от крестрон раша. Напомню, что в SIMPL+ всё завелось.
Igor: UDP на стороне Crestron работает отлично, например, управление аудиопроцессорами Symetrix.
Игорь K.: Символ SIMPL UDP/IP работает как надо, проверьте его установки с учётом особенностей протокола. Никогда небыло с ним проблем, крайний случай - Christie Syder Vista.
Вячеслав: Может ошибаюсь, но у меня вроде сторона сервера не работала с 127.0.0.1, но при указании реального ip процессора, удалось наконец принимать команды. Управлять же чем то по UDP еще не приходилось.
Игорь K.: Кстати, Zerberus, если не поперёк вашим убеждениям, поделитесь протоколом на девайс, плиз, UDP - самый подходящий для задач управления протокол. Минимум лишних данных, висячих подключений, аутентификаций и тд. Команды напрямую, от одного адреса к другому. Почти как RS232, но по стандартной сетевой инфраструктуре.
gosha: Вячеслав пишет: Может ошибаюсь, но у меня вроде сторона сервера не работала с 127.0.0.1, но при указании реального ip процессора, удалось наконец принимать команды. Интересно, а чего этим вы хотели добиться? Что касается символа UDP/IP: 1. Работает он хорошо. Документирован - архиплохо 2. Порт, указанный параметром в модуле, имеет несколько смыслов: 2а: Модуль "слушает" на этом порту входящие UDP-пакеты 2б: При отсылке пакетов этот порт является и source и destination портом. 3. Отсылка идет на адрес, прописанный в IP table. Принимаются пакеты только с адреса, прописанного в IP table. Перед прочтением следующего пункта отодвиньте в сторону все, что вы знаете о классических sockets 4. В системе могут существовать несколько символов с одинаковым портом. Дифференциация - по адресу в IP table. Я так в одном проекте несколькими камерами Sony SRG-300SE рулю по IP - удобно, включил кабель в ближайший коммутатор, и не надо пачку кабелей тащить от процессора к камере.
Игорь K.: gosha, полностью согласен. А от решения Sony SRG-300SE перейти на UDP тоже доволен, очень надежно управляются. Профессиональные вещательные девайсы тоже переводятся на UDP управление вместо RS422. Протокол Visca под UDP модернизировали, но на appmarket модуль появился.
Вячеслав: Поднимая сокет с адресом 127.0.0.1 я намеревался организовать "сторону сервера" на crestron процессоре. И неважно кто будет присылать ему команды (это может быть любой DHCP клиент с заранее неизвестным адресом, тем более он может быть ни один) С IP процессора это работает. С локал хост нет. Впрочем может надо было 0.0.0.0 как в TCP. Про IP table ничего не понял. Какая IP table из тулбокса что ли? В неё адреса для UDP подключений вручную добавлять что ли? Что прописывать в IP Net Address? Или вы свойства элемента UDP/IP имеете ввиду (IP Net Address)? Давайте на примере IP камер чтоб стало понятно, какой адрес и порт куда прописывать. )
Игорь K.: Вячеслав, забейте вы на locahost. Скрины живого проекта, три камеры, разные IP. Кроме всего, еще коммутатор Kramer там по UDP тоже неплохо управляется. Для упрочения знаний - настройки для Christie Spyder:
Вячеслав: В примере это типа клиента. понятно. FB камера присылает на адрес и порт процессора с которого пришла команда стало быть (предполагаю порт отправителя выбирается динамически)? Если слушать хотим UDP порт, соответственно IP самого процессора указываем и желаемый порт? И вот тут логично, что 2 одинаковых порта поднять уже не даст А бродкаст или мультикаст адрес кто то пробовал для udp использовать? IGMP подписка/запрос осуществляется корректно или снупинг надо выключать на свитче?
Игорь K.: Схема Клиент- сервер в классическом определении здесь уместна, да. Команда (сигнал) уходит в указанный адрес и порт. После чего сеанс закрывается. Обратная передача идёт если это запрограммировано, это значит, что в пакете передаётся адрес источника и его порт. Порт процессора 17, никакой динамики. Никаких двух одинаковых портов не подразумевается, вопрос не ясен. Вещание - основное назначение UDP. В Wiki базовые понятия отлично описаны.
Вячеслав: Игорь K. пишет: Порт процессора 17, никакой динамики. Странно было бы так поступать. А если 2 разных прибора управляются. Куда FB будет приходить (точнее как процессор поймет какому модулю принадлежит ответ) По адресу прибора это как то с ног на голову. Впрочем если FB нет, то можно начать сразу со 2 вопроса. Игорь K. пишет: Обратная передача идёт если это запрограммировано, это значит, что в пакете передаётся адрес источника и его порт. В смысле запрограммирована? Протокол устройства подразумевает FB, это считается запрограммировано? Процессор получит этот FB в тот же UDP/IP блок, который использовался для отправки команды? И все таки, если мы хотим принимать команды от устройства (т.е. слушать порт) какой адрес надо прописывать в свойства UDP/IP? А то все вокруг да около, так никто и не подтвердил адрес процессора.
Игорь K.: Вячеслав пишет: Странно было бы так поступать. А если 2 разных прибора управляются. Куда FB будет приходить (точнее как процессор поймет какому модулю принадлежит ответ) По адресу прибора это как то с ног на голову. Впрочем если FB нет, то можно начать сразу со 2 вопроса. Все очень логично. Странно так называть то, что является сетевым с 1980 г. и промышленным стандартом примерно с тех же времен. Если управляются два и более устройств от одного процессора, то прием данных идет с разных IP, это и является меткой для распознавания внутри принимаемых UDP пакетов. И для меня странно, что при программировании Crestron такие вопросы вообще всплывают. Вячеслав пишет: В смысле запрограммирована? Протокол устройства подразумевает FB, это считается запрограммировано? В протоколе не обязательно есть безусловная отправка т.н. FBack. Например в VISCA все запрашивается отдельной командой. Например, KRAMER сразу отвечает состоянием выхода, без запроса, видеокамеры Sony - нет. Зависит от реализации протокола. Вячеслав пишет: И все таки, если мы хотим принимать команды от устройства (т.е. слушать порт) какой адрес надо прописывать в свойства UDP/IP? Нужно прописывать IP адрес устройства, данные с которого нужно принять процессором Crestron. На картинке в моем посте выше все показано, это адреса управляемых устройств, которые с таким же успехом присылали ответные посылки. В этой ветке много мусора, насколько я вижу, завтра прочищу.
Вячеслав: Мое понимание сетевых технологий подразумевало, что меткой для распознавания приложения(процесса), которое должно обрабатывать ответ, является порт. А адрес как раз у ПК/crestron один для всех процессов. Не говоря уж про то, что IP адрес лишь средство маршрутизации данных. Непосредственный обмен данными осуществляется по MAC адресам. Да и UDP не содержит IP адресов т.к. является транспортным протоколом, IP адреса добавляются на сетевом уровне IP. Но скорее мы все таки не поняли друг друга. Я про сторону crestron говорю. Для каждого нового подключения к удаленному устройству, на стороне crestron должен быть использован уникальный номер порта в диапазоне 1024-65535. Поэтому утверждение про фиксированный 17 порт в отправляемых дейтаграммах меня озадачил и до сих пор вызывает недоверие. Вот номер протокола UDP действительно равен 17, но этот номер не имеет отношения к номеру порта отправителя и получателя. Игорь K. пишет: Нужно прописывать IP адрес устройства, данные с которого нужно принять процессором Crestron. Не вариант, для подключения с заранее неизвестного устройства, которое получает адрес по DHCP. Все ж таки я за то, чтобы адрес контроллера прописать )
DmitriiP: Вячеслав пишет: Для каждого нового подключения к удаленному устройству, на стороне crestron должен быть использован уникальный номер порта UDP это не TCP у него нет понятия подключения TCP — ориентированный на соединение протокол UDP — более простой, основанный на сообщениях протокол без установления соединения Игорь K. пишет: Порт процессора 17, никакой динамики. порт процессор открывает тот что вы указали в [Port] проверить это очень просто в консоли процессора команда CP3>netstat Proto Local Address Foreign Address State ..... UDP 0.0.0.0:4023 *:* UDP 0.0.0.0:41794 *:* UDP 0.0.0.0:50501 *:* UDP 0.0.0.0:50502 *:* ..... TCP 192.168.1.180:22 192.168.1.2:52493 ESTABLISHED Вячеслав пишет: Все ж таки я за то, чтобы адрес контроллера прописать ) Serial input: <TX$> Sends the corresponding string to the LAN port for transmission to a target device, broadcast address or multicast address. The IP address of the UDP/IP Communications symbol should be set accordingly.
Zerberus: Игорь K. пишет: Кстати, Zerberus, если не поперёк вашим убеждениям, поделитесь протоколом на девайс, плиз Игорь, я не знаю, могу ли я дать Вам тот документ, который я получил. С одной стороны, никакого NDA я не подписывал, но с другой - чисто доверительные человеческие отношения. Я могу дать Вам команды, которые собственноручно снял с программы конфигурирования ADA Cinema Rapture (там есть специальное окно с для вывода команд для программирования контроллеров и прочей автоматики) и фидбеки - за это, я думаю, меня никто не осудит. Подождите до вечера я подготовлю файлик.
полная версия страницы