Отправлено: 23.03.17 11:34. Заголовок: ADA Cinema Rapture У кого есть протокол?

Собственно, сабж. Есть ли у кого-нибудь протокол управления для ADA Cinema Rapture по IP. Куда у него стучаться и прочее. Буду премного благодарен.

 Отправлено: 24.03.17 15:56. Заголовок: Zerberus, а есть ли ..

Zerberus, а есть ли уверенность что данное изделие вообще управляемо по IP? С ADA работал давно, тогда все было как-то неоднозначно - приходилось использовать нигде не дешевый шлюз с RS232 на их шину. Можно посканить прибор на предмет открытых портов. Если открыт Telnet, можно постучать туда известными командами.

 Отправлено: 24.03.17 18:51. Заголовок: Есть, однозначно. Он..

Есть, однозначно. Они в этой железяке используют плату NetBurner SBL2e. Это такой мост из ethernet на UART. В принципе, я нашёл уже протокол, который, естественно, совпадает с протоколом по RS 232. Собственно, через UDP работает и их программа для конфигурации. Другая проблема вылезла. Crestron как-то криво работает с UDP. Точнее, совсем не работает. Я открыл порт для UDP на ПК и попытался слушать, что будет слать крестрон. Услышал тишину. Вайршарк тоже не показывает никаких пакетов UDP исходящих из него. Отправил всё это дело со скриншотами в наше представительство крестрона. Пока жду результаты. Возможно, где-то я туплю.

 Отправлено: 24.03.17 21:30. Заголовок: Upd: Удалось всё-так..

Upd: Удалось всё-таки поженить две железки. По какой-то причине UDP/IP символ не работает. Всё завелось в SIMPL+.

 Отправлено: 24.03.17 21:35. Заголовок: Блоком UDP/IP Commun..

Блоком UDP/IP Communication ни когда не сталкивался, по описанию вообще непонятно что это за сторона сервер или клиент или определяется IP адресом. Хотя описание параметра Port намекает скорее на сторону клиента (The port number of the target device)
Но вот в simpl+ UDP_SOCKET я использовал исключительно как сторону сервера и это работает.
Так что есть вероятность, что вы расцениваете сторону Crestron как клиент, который должен подключаться к серверу на ПК, а надо наоборот делать. Может Crestron и не умеет клиентом UDP выступать. Впрочем это лишь предположения и коллеги поправят.

 Отправлено: 24.03.17 22:25. Заголовок: <zanudamode>..

<zanudamode>
Не очень правильно называть что-либо связанное с протоколом UDP сервером или клиентом. Правильнее - получателем или отправителем, так как нет установки соединения (рукопожатия) и отправителю всё равно, получил ли правильно или вообще не получил получатель данные.

Вспоминаем, как устроен заголовок у UDP: [порт отправителя]; порт получателя; длинна датаграммы; [контрольная сумма] , в квадратных скобках - необязательные поля.
Крестроновский символ UDP/IP - есть отправитель, так как тот самый the target device - как раз получатель, на который посылать данные.

Есть один момент. Так как в заголовке всё-таки есть хоть и необязательное поле [порт отправителя], а в псевдозаголовке IP есть адрес отправителя, получатель что-то всё-же может отправить в обратку отправителю. Скорее всего этим и обуславливается сериальный выход RX символа UDP. Но обычно, для двухсторонней связи просто берут пару портов - один чётный, другой - следующий за ним нечётный. В чётный кидают команды, из нечётного получают данные. То есть, в случае с крестроном, нужно два символа - один кидает данные на тот порт, который открыт у устройства, второй символ слушает свой собственный порт на собственном интерфейсе.
</zanudamode>

Но символы не работают, или я ими не правильно пользуюсь. В любом случае, подождём официального ответа от крестрон раша. Напомню, что в SIMPL+ всё завелось.

 Отправлено: 24.03.17 22:45. Заголовок: UDP на стороне Crest..

UDP на стороне Crestron работает отлично, например, управление аудиопроцессорами Symetrix.

 Отправлено: 24.03.17 23:44. Заголовок: Символ SIMPL UDP/IP ..

Символ SIMPL UDP/IP работает как надо, проверьте его установки с учётом особенностей протокола.
Никогда небыло с ним проблем, крайний случай - Christie Syder Vista.

 Отправлено: 25.03.17 00:18. Заголовок: Может ошибаюсь, но у..

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

 Отправлено: 25.03.17 00:31. Заголовок: Кстати, Zerberus, ес..

Кстати, Zerberus, если не поперёк вашим убеждениям, поделитесь протоколом на девайс, плиз,
UDP - самый подходящий для задач управления протокол. Минимум лишних данных, висячих подключений, аутентификаций и тд. Команды напрямую, от одного адреса к другому.
Почти как RS232, но по стандартной сетевой инфраструктуре.

 Отправлено: 25.03.17 08:26. Заголовок: Вячеслав пишет: Мож..

Вячеслав пишет:

цитата:

Может ошибаюсь, но у меня вроде сторона сервера не работала с 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 - удобно, включил кабель в ближайший коммутатор, и не надо пачку кабелей тащить от процессора к камере.

 Отправлено: 25.03.17 11:45. Заголовок: gosha, полностью сог..

gosha, полностью согласен.
А от решения Sony SRG-300SE перейти на UDP тоже доволен, очень надежно управляются.
Профессиональные вещательные девайсы тоже переводятся на UDP управление вместо RS422.
Протокол Visca под UDP модернизировали, но на appmarket модуль появился.

 Отправлено: 25.03.17 17:29. Заголовок: Поднимая сокет с ад..

Поднимая сокет с адресом 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 камер чтоб стало понятно, какой адрес и порт куда прописывать. )

 Отправлено: 25.03.17 18:15. Заголовок: http://f5.s.qip.r..

Вячеслав, забейте вы на locahost.

Скрины живого проекта, три камеры, разные IP.
Кроме всего, еще коммутатор Kramer там по UDP тоже неплохо управляется.





Для упрочения знаний - настройки для Christie Spyder:

 Отправлено: 26.03.17 14:25. Заголовок: В примере это типа к..

В примере это типа клиента. понятно.
FB камера присылает на адрес и порт процессора с которого пришла команда стало быть (предполагаю порт отправителя выбирается динамически)?
Если слушать хотим UDP порт, соответственно IP самого процессора указываем и желаемый порт? И вот тут логично, что 2 одинаковых порта поднять уже не даст

А бродкаст или мультикаст адрес кто то пробовал для udp использовать? IGMP подписка/запрос осуществляется корректно или снупинг надо выключать на свитче?

 Отправлено: 26.03.17 15:00. Заголовок: Схема Клиент- сервер..

Схема Клиент- сервер в классическом определении здесь уместна, да.
Команда (сигнал) уходит в указанный адрес и порт. После чего сеанс закрывается.
Обратная передача идёт если это запрограммировано, это значит, что в пакете
передаётся адрес источника и его порт.
Порт процессора 17, никакой динамики.
Никаких двух одинаковых портов не подразумевается, вопрос не ясен.
Вещание - основное назначение UDP. В Wiki базовые понятия отлично описаны.

 Отправлено: 26.03.17 22:43. Заголовок: Игорь K. пишет: По..

Игорь K. пишет:

цитата:

Порт процессора 17, никакой динамики.

Странно было бы так поступать. А если 2 разных прибора управляются. Куда FB будет приходить (точнее как процессор поймет какому модулю принадлежит ответ) По адресу прибора это как то с ног на голову.
Впрочем если FB нет, то можно начать сразу со 2 вопроса.

Игорь K. пишет:

цитата:

Обратная передача идёт если это запрограммировано, это значит, что в пакете передаётся адрес источника и его порт.

В смысле запрограммирована? Протокол устройства подразумевает FB, это считается запрограммировано? Процессор получит этот FB в тот же UDP/IP блок, который использовался для отправки команды?

И все таки, если мы хотим принимать команды от устройства (т.е. слушать порт) какой адрес надо прописывать в свойства UDP/IP? А то все вокруг да около, так никто и не подтвердил адрес процессора.

 Отправлено: 26.03.17 23:07. Заголовок: Вячеслав пишет: Стр..

Вячеслав пишет:

цитата:

Странно было бы так поступать. А если 2 разных прибора управляются. Куда FB будет приходить (точнее как процессор поймет какому модулю принадлежит ответ) По адресу прибора это как то с ног на голову. Впрочем если FB нет, то можно начать сразу со 2 вопроса.

Все очень логично. Странно так называть то, что является сетевым с 1980 г. и промышленным стандартом примерно с тех же времен.
Если управляются два и более устройств от одного процессора, то прием данных идет с разных IP, это и является меткой для распознавания внутри принимаемых UDP пакетов.
И для меня странно, что при программировании Crestron такие вопросы вообще всплывают.

Вячеслав пишет:

цитата:

В смысле запрограммирована? Протокол устройства подразумевает FB, это считается запрограммировано?

В протоколе не обязательно есть безусловная отправка т.н. FBack. Например в VISCA все запрашивается отдельной командой.
Например, KRAMER сразу отвечает состоянием выхода, без запроса, видеокамеры Sony - нет. Зависит от реализации протокола.

Вячеслав пишет:

цитата:

И все таки, если мы хотим принимать команды от устройства (т.е. слушать порт) какой адрес надо прописывать в свойства UDP/IP?

Нужно прописывать IP адрес устройства, данные с которого нужно принять процессором Crestron.

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

 Отправлено: 27.03.17 01:50. Заголовок: Мое понимание сетевы..

Мое понимание сетевых технологий подразумевало, что меткой для распознавания приложения(процесса), которое должно обрабатывать ответ, является порт. А адрес как раз у ПК/crestron один для всех процессов. Не говоря уж про то, что IP адрес лишь средство маршрутизации данных. Непосредственный обмен данными осуществляется по MAC адресам. Да и UDP не содержит IP адресов т.к. является транспортным протоколом, IP адреса добавляются на сетевом уровне IP.
Но скорее мы все таки не поняли друг друга. Я про сторону crestron говорю. Для каждого нового подключения к удаленному устройству, на стороне crestron должен быть использован уникальный номер порта в диапазоне 1024-65535. Поэтому утверждение про фиксированный 17 порт в отправляемых дейтаграммах меня озадачил и до сих пор вызывает недоверие. Вот номер протокола UDP действительно равен 17, но этот номер не имеет отношения к номеру порта отправителя и получателя.
Игорь K. пишет:

цитата:

Нужно прописывать IP адрес устройства, данные с которого нужно принять процессором Crestron.

Не вариант, для подключения с заранее неизвестного устройства, которое получает адрес по DHCP. Все ж таки я за то, чтобы адрес контроллера прописать )

 Отправлено: 27.03.17 02:42. Заголовок: Вячеслав пишет: Для..

Вячеслав пишет:

цитата:

Для каждого нового подключения к удаленному устройству, на стороне 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.

 Отправлено: 27.03.17 11:25. Заголовок: Игорь K. пишет: Кст..

Игорь K. пишет:

цитата:

Кстати, Zerberus, если не поперёк вашим убеждениям, поделитесь протоколом на девайс, плиз

Игорь, я не знаю, могу ли я дать Вам тот документ, который я получил. С одной стороны, никакого NDA я не подписывал, но с другой - чисто доверительные человеческие отношения. Я могу дать Вам команды, которые собственноручно снял с программы конфигурирования ADA Cinema Rapture (там есть специальное окно с для вывода команд для программирования контроллеров и прочей автоматики) и фидбеки - за это, я думаю, меня никто не осудит. Подождите до вечера я подготовлю файлик.