Отправлено: 10.11.15 09:06. Заголовок: Televic D-Cerno CUR
Всем доброе утро. Реализовываю наведение камеры на активный пульт. Контроллер D-Cerno CUR может только отправлять фидбеки по UDP. Послать на контроллер команды для получения информации об активных пультах, очереди и т. д. нельзя. В настройках количество пультов 2. Активация пульта 1: {"serial":"102046ba","status":1,"totalMicOn":1,"totalMicReq":0} Активация пульта 2: {"serial":"102045dd","status":1,"totalMicOn":2,"totalMicReq":0} Активация пульта 3: {"serial":"1020469b","status":2,"totalMicOn":2,"totalMicReq":1} При включении пульта 3 видим, что он попал в список Request. Если, допустим, выключить пульт 1, то наблюдается следующая картина: Выключение пульта 1: {"serial":"102046ba","status":0,"totalMicOn":1,"totalMicReq":1} {"serial":"1020469b","status":0,"totalMicOn":1,"totalMicReq":0} {"serial":"1020469b","status":1,"totalMicOn":2,"totalMicReq":0} Сначала пульт 1 удаляется из списка активных пультов, затем пульт из списка Request удаляется из своего списка, и, наконец, этот пульт активируется и попадает в список активных пультов. Первые 2 посылки дают нам информацию для изменения списков пультов. Информацию о последнем активном пульте содержится в последней посылке. После этого должна формироваться команда на срабатывание нужного пресета. Как это сделать? Эти 3 посылки укладываются в очень короткий временной промежуток. Думаю задействовать функцию GETHSECONDS(). При простом выключении пульта (очереди нет) с телевика приходит одна команда. На основании разницы во времени между предыдущим событием можно отследить это действие и активировать пресет на предыдущий пульт. В случае, когда приходит последовательность посылок пока не знаю как обработать. Есть идеи?
Логику наведения камер использую такую: Если активирован микрофон N, то загрузить preset N и изменить очередь состоящую из номеров активных микрофонов: Последний активированный номер поместить в позицию [1] очереди, остальные сдвинуть вправо по очереди. Предварительно проверяем было ли вхождение этого номера в очереди (т.е. актировался ли ранее) и удаляем его из очереди (вырезаем со сдвигом влево, последний элемент очереди заполняем 0)Это удаление для предотвращения потери информации об активных микрофонах при выталкивании их из очереди при превышении кол-ва активных микрофонов. Если микрофон отключается, удаляем его из очереди активных микрофонов, проверяем был ли он включен последним (т.е. находился в позиции [1] очереди), если это так то ищем предпоследний включенный, но всё еще активный микрофон ([2]) и наводим камеру на него. Если активных микрофонов не осталось (номер в позиции [2]=0),то активируем zero пресет(общий вид зала) Для использования нескольких камер, есть еще часть сохранения в результате которой в массиве хранится номер камеры и номер её пресета соответствующие каждому номеру микрофона.
По вашему конкретному вопросу по последовательности посылок: Обрабатывайте последовательно накапливая во входе объявленном в SIMPL+ как BUFFER_INPUT from_televic В цикле каждый раз вырезая часть буфера по разделитель "}" Пример кода SIMPL+: BUFFER_INPUT from_televic [3000]
.. //тут ищем признак активации .. if (find("\x22status\x22:1",tmp_str)>0) .. { .. //статус нужного микрофона в 1 .. }
.. //тут ищем признак выключения .. if (find("\x22status\x22:0",tmp_str)>0) .. { .. //статус нужного микрофона в 0 .. } . }//while }//change Нет ничего страшного,что 3 пульт активируется (статус) из очереди через промежуточный статус выключения. {"serial":"1020469b","status":0,"totalMicOn":1,"totalMicReq":0}
Вячеслав, спасибо за ответ. Что даёт накапливание данных в буфере? После каждого вырезания из буфера содержимое будет пустым.
При статусе 0 возможны ситуации: Вариант 1 (при заполнении списка активных пультов следующие пульты помещаются в список ожидания) 1. Список активных пультов заполнен, в списке ожидания есть пульты. Какой-то из активных пультов выключается. От телевика идут 3 посылки, которые выше описывал. Первая из них со статусом 0. 2. В списке ожидания пультов нет. При выключении активного пульта от телевика идёт одна посылка со статусом 0. Вариант 2 (FIFO). В этом режиме при заполнении активного списка каждый последующий вытесняет первый в списке. 2 посылки от телевика. выключение 1 в списке, включение нового пульта. Опять 2 ситуации со статусом 0. Но здесь сложнее, чем в 1 варианте. Там в первой посылке со статусом 0 количество пультов в списке ожидание ненулевое. Здесь же посылки никак не отличаются.
Отправлено: 10.11.15 15:34. Заголовок: Если я правильно пон..
Если я правильно понял, то надо реализовать классический стек (LIFO), но с возможностью удаления (только удаления) элементов из середины стека. Делал я такой модуль...
Отправлено: 10.11.15 17:10. Заголовок: Ввёл народ в заблужд..
Ввёл народ в заблуждение. Параллельно другими задачами занимаюсь. Алгоритм правильно описал Вячеслав.
При выключении пульта из середины стека, удаляем пульт, сдвигаем очередь. Камера стоит на месте. Из примера Вячеслава непонятна процедура обработки последовательности посылок. В случае перевода из списка ожидания в активный список подряд идут 3 посылки.
Отправлено: 10.11.15 20:10. Заголовок: Как я и сказал предл..
Как я и сказал предложенный пример кода не противоречит вашему заданию, просто 2-я посылка обработается как выключение микрофона (который на самом деле и не был включен а стоял в очереди ожидания). А по третей посылке он перейдет в состояние включен.
Модуль логики наведения есть,но он был написан как некое универсальное дополнение к модулю какой либо конгресс системы (т.е. у него на входах лишь статусы микрофонов с другого модуля, который собственно и обрабатывает протокол). В моем случае это был BOSCH, в качестве управления коммутацией DM матрица, а пресетами камерами рулил модуль для SONY. На выходах управление пресетами камер. Блоком объявления входов / выходов поделюсь. Модулем даром, простите нет. В нем еще есть входы, выходы сохранения пресетов и привязки их к микрофонам,а так же переключение ручного/автоматического режима наведения и смешанный режим. #DEFINE_CONSTANT MICS_NUM 27
DIGITAL_INPUT _SKIP_,mode_manual,save_preset_state,active_mic[MICS_NUM];//статус с модуля конгресс системы ANALOG_INPUT active_mic_manual,CAM_active_input_number;//наведение по активации микрофона с пульта оператора в смешанном режиме либо выбор микрофона в режиме записи пресета
DIGITAL_OUTPUT _SKIP_,_SKIP_,save_cam_preset,active_mic_preset[MICS_NUM];//сохраняет на модуле управления камерами пресет с указанным номером совпадающим с номером выбранного микрофона ANALOG_OUTPUT CAM_input_num; //переключает входы матрицы
/******************************************************************************************* Parameters (Uncomment and declare parameters as needed) *******************************************************************************************/ INTEGER_PARAMETER zero_preset; //позволяет через параметр в качестве базового пресета указать любой из имеющихся
пояснения cam_for_mic[active_mic]=CAM_active_input_number;//сохраняет для активируемого микрофона номер текущего активного входа камеры на матрице DM. Т.е.алгоритм чуть упрощен пресет рассылается на все камеры,но предварительно на матрице коммутируется нужная.
Алгоритм(режим) сохранения пресетов выглядел так: Садимся на первое сохраняемое место докладчика. Выбираем микрофон с панели управления ipad( подключение конгресс системы не требуется), коммутируем нужную (ближайшую удобную) камеру, наводим как надо, нажимаем сохранить пресет. В модуле камеры сохраняется пресет с номером активного микрофона. В нашем модуле сохраняем привязку камеры (входа матрицы) к номеру микрофона. Садимся на следующее место и т.д.
Отправлено: 10.11.15 21:46. Заголовок: vtsay пишет: Что да..
vtsay пишет:
цитата:
Что даёт накапливание данных в буфере? После каждого вырезания из буфера содержимое будет пустым.
BUFFER это само по себе средство накопления. Самые старые сообщения в начале, самые новые в конце. Объявив BUFFER_INPUT from_televic [3000] У вас появляется serial вход в модуле с размерностью в 3000 символов Функция RemoveByLength(position,from_televic); вырезает часть буфера по первое вхождение символа } Т.е. подрезает его динамическую длину от его начала (самые старые сообщения) Цикл While повторяет эту процедуру подрезания блоками оканчивающимися на } сохраняет отрезанный блок в переменную tmp_str и сразу обрабатывает этот блок на предмет искомых в нем фраз означающих включение или отключение микрофона и т.д. Если не одна искомая нами фраза не найдена блок просто перезапишется новой вырезкой. Так цикл переработает весь буфер блоками разделенными } пока в буфере не останется символов } Т.е. операция перейдет в ожидание следующего события CHANGE from_televic (т.е. ожидает поступления новых посылок от televic).
Отправлено: 10.11.15 21:53. Заголовок: Раньше televic не пр..
Раньше televic не присылал статус по нажатию кнопки приоритета председателя т.е. вообще никакого сообщения. Можно было лишь косвенно понять по отключению всех микрофонов. Сейчас что то изменилось?
Отправлено: 11.11.15 06:32. Заголовок: Вячеслав, всё также ..
Вячеслав, всё также осталось. При кратковременном нажатии кнопки приоритета все пульты делегатов отключаются. При нажатии и удерживании приоритета пульты делегатов гасятся, а при отпускании кнопки возвращаются в активное состояние. При этом, если пульт председателя до этого был выключен, то не включается при удерживании приоритета. Статус приоритета не передаётся.
Отправлено: 11.11.15 07:05. Заголовок: Забыл добавить, при ..
Забыл добавить, при нажатии кнопки приоритет контроллер выплёвывает последовательно посылки о выключенном пульте.
По поводу буфера. Из вашего примера выходит, что будет обрабатываться всегда только одна посылка. Ппри получении от контроллера посылки срабатывает событие Change. В буфер from_televic записывается посылка, а далее в цикле происходит обработка. Первая же команда Removebylength вырезает посылку, а поскольку других посылок нет в буфере нет, то в буфере from_televic будет пусто. Следующее событие Change даст тот же результат. В примере с 3 пультами (2 активных, 1 в списке ожидания) при отключении активного пульта 3 посылки идут от телевика не в один момент времени. Это 3 разных события. Вот скриншот с wireshark http://shot.qip.ru/00OflN-41HDgF0Ng/.
Отправлено: 11.11.15 19:42. Заголовок: Вы не правы. 1.Буфер..
Вы не правы. 1.Буфер может пополняться одновременно с обработкой первой посылки 2.Тем более нет проблем если посылки придут по очереди. 3.Removebylength не очищает буфер полностью, а берет из него информацию частями, удаляя из него последовательно ту часть которую функция забрала для обработки. Т.е. если буфер изначально содержит {1}{2}{3} То в первый проход цикла While в tmp_str окажется {1} при этом в буфере все еще останется {2}{3} Не путайте с Remove которая бы вырезала все целиком{1}{2}{3} и ошибочно обработался только блок{1}. На самом деле все немного хуже,так как каждое новое событие CHANGE порождает новый параллельный процесс который тоже пытается работать с общим для этих процессов буфером. Как правило это не приводит к ошибкам в программе, видимо потому что он встает в очередь за первым процессом. А в тот момент когда первый из этих процессов обработает все посылки накопленные в буфере,остальным останется опустошенный буфер и параллельный процесс просто сразу завершится не найдя в буфере ничего.
Есть варианты блокировать вход в обработчик переменной busy но это решение имеет побочные эффекты. Есть еще THREAD CHANGE но я ему не очень доверяю,потому как не до конца ясен его алгоритм.Возможно в случае THREAD CHANGE буфер не будет пополняться,а это проблема, которая может привести к потере данных.
Уж даже не знаю как еще разъяснить понятнее. Просто поверьте человеку,который съел на этом не одну собаку. Прелесть буфера в том что вы не потеряете данные, которые могут приходить не только целиком, но и частями Например сначала прилетит {"serial":"102046ba","sta //по событию CHANGE ничего кроме пополнения буфера не происходит,так как не найден символ } потом прилетит tus":0,"totalMicOn":1,"totalMicReq":1}{"serial":"1020469b","status":0,"totalMic //по событию CHANGE запустится цикл обработки так как найден } Removebylength отрежет из буфера часть {"serial":"102046ba","status":0,"totalMicOn":1,"totalMicReq":1} и начнет ее обрабатывать, тем временем в буфере остается {"serial":"1020469b","status":0,"totalMic вэто же время может прилететь и все остальное On":1,"totalMicReq":0} {"serial":"1020469b","status":1,"totalMicOn":2,"totalMicReq":0} В итоге цикл while выполнится 3 раза,обработав все три посылки и это все в первом событии CHANGE. CHANGE приславшие 2 и 3 куски завершаться обнаружив пустой буфер полностью разобраный первым CHANGE То что вы описываете как 3 отдельных пакета содержащих каждый свою команду целиком просто идеальный вариант для обработчика. Или вы видите какую то проблему в том кто 3 пакета обработаются отдельно? Это же не сериал, каждый пакет это полноценное руководство к действию 1.Статус микрофона 102046ba выставляем в 0 2.Статус микрофона 1020469b подтверждаем 0 //покинул очередь 3.Статус микрофона 1020469b выставляем в 1
Вячеслав, спасибо за разбор. Я исходил из того, что телевик формирует посылку вида {"serial":"102046ba","status":1,"totalMicOn":1,"totalMicReq":0} и отдаёт контроллеру. При активации или выключении пультов формируется 1 такая посылка, вызывая 1 событие CHANGE. В остальных случаях формируется от 2 до 3 посылок, вызывая, соответственно, 2 и 3 события CHANGE. Поэтому я полагал, что после выполнения RemoveByLength(position,from_televic) буфер всегда будет пустым. В S+ есть функция поиска значения в массиве?
Отправлено: 12.11.15 18:45. Заголовок: Про какой массив иде..
Про какой массив идет речь? Поиск осуществляется обычно с использованием циклов for или while реже until В вашем случае советую объявить количество параметров равное максимальному количеству микрофонов в проекте. #DEFINE_CONSTANT MAX_MIC 30 ... DIGITAL_OUTPUT mic_fb[MAX_MIC]; ......... STRING_PARAMETER mic_ID[MAX_MIC][8]; ... В строки параметров вписать id микрофонов в порядке их очередности.
Потом опишите функцию поиска которая будет активировать или деактивировать выход mic_fb соответствующий найденному ID микрофона Function Manage_mic_status(integer state, string ID) { . integer i;
. for(i=1 to MAX_MIC) . { . if(mic_ID(i)=ID){mic_fb(i)=state;break;}//тип скобки замените,форум не пропускает . } }
Эту функцию выбудете вызывать в описанном ранее цикле while события CHANGE в качестве параметров ей надо будет передать статус микрофона и его ID номер Например .. integer position,sp; .. string tmp_str[3000],current_mic_id[8];
.. if (find("\x22status\x22:1",tmp_str)>0) .. { .. //статус нужного микрофона в 1 .. sp=find("\x22:\x22",tmp_str); .. current_mic_id=mid(tmp_str,sp+3,8); .. Manage_mic_status(1,current_mic_id); .. }
Не забывайте про _SKIP_ перед входом модуля from_televic количество которых равно кол-ву микрофонов
Отправлено: 17.01.16 19:37. Заголовок: Igor, спасибо. Еще н..
Igor, спасибо. Еще не встречался с этой железкой. Очень странно, что D-Cerno так "неразговорчив". Та же Confidea очень дружелюбна и никаких проблем с получением обратной связи нет.
Отправлено: 17.01.16 21:47. Заголовок: ph1l74, так и с D-Ce..
ph1l74, так и с D-Cerno проблем нет. Автор темы столкнулся с несколько нетривиальной задачей. Помнится, я сам перематерил все на свете пока решал нечто подобное. Кстати, если планируете использовать данный девайс, обеспечьте ему стабильное бесперебойное электропитание. У нас есть объект где в D-Cerno происходят мистические события вроде сброса настроек в дефолтные и очистке как раз пунктов конфига, отвечающих за взаимодействие с Crestron. Мы с коллегой видим два варианта объяснения - скончавшийся UPS в условиях переодического отключения электропитания объекта или очумелые ручки пользователей.
Отправлено: 18.01.16 16:21. Заголовок: vtsay, а где Вы нашл..
vtsay, а где Вы нашли такой протокол? У меня совершенно другая документация. Протокол D-Cerno CUR
Igor , проблемы все же возникли. В документации не указано, на какой порт подключаться. Следовал Вашему совету и зашел в настройки в веб-сервисе. Выбрал вкладку "Настройки подключения камеры", так как только в этом разделе были настройки порта. Указал адрес контроллера, поставил нужный порт. Увы, коннекта нет. Как быть? Может быть не то настраиваю?
Отправлено: 18.01.16 18:30. Заголовок: ph1l74, креативы с н..
ph1l74, креативы с настройками Televic и Crestron прилагаются. Разумеется, подозреваемые должны жить в одной сети. В данном случае Crestron 192.168.1.113, Televic - 192.168.1.20
Отправлено: 19.01.16 00:16. Заголовок: Ну, на мой взгляд ту..
Ну, на мой взгляд тут либо какая-то банальщина вроде неправильной адресации/параметризации, либо контроллеру Televic плохо. Обновите ему прошивку при возможности. Хотя, все в нашей практике работали out of the box. Что значит "нет коннекта"? Запустите систему и посмотрите статус подключения по IP ID, присвоенному Televic, в таблице адресов IP контроллера Crestron - что написано в статусе? Сама конгресс-система нормально работает? На кпопку нажимаем - микрофон подсвечивается и свой голос из других микрофонных станций слышим? Все станции работают? Какой порт в итоге выбрали для UDP-подключения? Должен быть не ниже 3000.
Отправлено: 21.01.16 08:17. Заголовок: ph1l74, в документе ..
ph1l74, в документе D-Cerno Installation and user manual есть раздел Camera protocol. Им и руководствовался.
Вот описание раздела. First set the correct destination IP address and port. The port number has to be higher than 3000. For example 9050 is a valid port. The content is sent using the UDP packet protocol and it is given in the following format (the * are substitute for the real values, see further examples): {“serial”: “********”,“status”: *,“totalMicOn”: *,“totalMicReq”,*} “serial” contains the serial code of the delegate unit. This code is shown at the back of each delegate unit, as the 8-digit number just under the barcode. The “serial” data of a D-Cerno D delegate unit starts with “10……” The “serial” data of a D-Cerno C chairman unit starts with “11……” “status” has several options: 0 = off 1 = on 2 = request 4 = next in line 8 = prior “totalMicOn” = total number of active microphones. “totalMicReq” = total number of microphones in request. So for example if the microphone with serial “101008D2” goes into request mode the following command is send: {“serial”: “101008D2”,“status”: 2,“totalMicOn”: 1,“totalMicReq”,0} After a microphone conference mode change the following string is sent: {“serial”: “00000000”,“status”: 0,“totalMicOn”: 0,“totalMicReq”,0}
Документ, который вы привели, в первый раз вижу. Собственно, проблемы у меня возникли в обработке фидбеков.
Отправлено: 21.01.16 11:12. Заголовок: vtsay, нет. Пректы, ..
vtsay, нет. Пректы, в которых мы использовали Televic, весьма просты - поднимали за день-два, не было ни времени на поиски Шамбалы в программировании, ни повода заниматься этим. Отслеживание предпоследней, предпредпоследней и т.д. микрофонных станций делал на Bosch.
Отправлено: 21.01.16 12:22. Заголовок: ph1l74, различные EC..
ph1l74, различные ECO-режимы - это вообще наши враги, уводят управляемое оборудование в спячку, из которой его надо извлекать совсем не интеграторскими методами. Управление микрофонными станциями не документировано.
lexalexalexa, имхо нет смысла писать модуль - там настолько все банально, просто не стоит того. К тому же, как верно процитировал vtsay два года назад, микрофонная станция высылает свой серийный номер - по нему и происходит идентификация станции на стороне Crestron. И что - написать модуль с кучей параметров, в каждое поле модуля на каждом последующем объекте вписывать серийник? Нет, не устаю повторять - если есть непреодолимая тяга к творчеству, свободное время (надо будет у пацанов на Кордоне спросить, что это за напасть такая - "свободное время") и щедрый бюджет - протокол в свободном доступе. Но я рекомендую настроить Televic, понажимать клавиши на микрофонных станциях, отловить сырую ОС на стороне Crestron и вбить нужные строки в Serial IO.
Отправлено: 17.07.18 17:57. Заголовок: Всем привет. Попытаю..
Всем привет. Попытаюсь собрать инфу в один какой-то логичный текст. Железка - Televic D-Cerno CUR. Варианты управления: протокол - UDP, порт - назначается в самом устройстве. Функционал - только отлавливать статусы с микрофонов. протокол TCP порт 5011. Функционал полный, согласно мануалу https://yadi.sk/i/XoVzeTu93ZGtyP. За исключением команд hlp и dis ('это то что я нашел как не работающие и производитель подтвердил) После соединения по TCP необходимо сначала отправить команду Connect. Выглядит она вот так: \x0202:con0000029O00000C00000000000000:{"typ":"Application","nam":"DU","ver":"1.01","inf":"0","svr":0}\x03 Согласно протокола на ее примере без труда можно сделать остальные. Мне нужны были только микрофоны, так что я только их и делал. Если будет когда-нибудь время - можно будет сделать модуль.
Отправлено: 19.07.18 01:07. Заголовок: Посмотришь на эти кр..
Посмотришь на эти кракозябры, вспомнишь и вздрогнешь про бош и понимаешь какая же няшка DIS CCU-E. Хоть описание протола ущербное и лежит почему то в user manual на пульты, но такой простой и понятный синтаксис непременно надо модуль запилить, пока под руками.
Отправлено: 23.07.18 05:59. Заголовок: Вячеслав, тоже часте..
Вячеслав, тоже частенько добрым словом поминаю протокол управления последних DIS. Недавно имел радость управлять Confidea WCAP G3 (без центрального блока управления) - вот ведь фантазия у их программистов... Система управляется по http (и только на эту часть есть мануал), фидбэки об изменениях статусов микрофонов шлет через отдельное соединение по udp, а если нужны фидбэки по настройкам системы или, к примеру, первоначальный статус микрофоном опросить, то это снова http, но непременно тоже отдельным от управления соединением.
Варианты управления: протокол - UDP, порт - назначается в самом устройстве. Функционал - только отлавливать статусы с микрофонов. протокол TCP порт 5011. Функционал полный, согласно мануалу https://yadi.sk/i/XoVzeTu93ZGtyP. За исключением команд hlp и dis ('это то что я нашел как не работающие и производитель подтвердил)
На текущий момент dis работает: \x0202:dis0000029O00000C00000000000000:{"id":"01","inf":"System shutting down","svr":0}\x03. На всякий случай версия протокола D-Cerno 1.5 https://disk.yandex.ru/i/jtmQg9dLqOjBmQ.
Варианты управления: протокол - UDP, порт - назначается в самом устройстве. Функционал - только отлавливать статусы с микрофонов. протокол TCP порт 5011. Функционал полный, согласно мануалу https://yadi.sk/i/XoVzeTu93ZGtyP. За исключением команд hlp и dis ('это то что я нашел как не работающие и производитель подтвердил)
На текущий момент dis работает: \x0202:dis0000029O00000C00000000000000:{"id":"01","inf":"System shutting down","svr":0}\x03. На всякий случай версия протокола D-Cerno 1.5 https://disk.yandex.ru/i/jtmQg9dLqOjBmQ.
Отправлено: 19.07.23 12:25. Заголовок: Просто открываете со..
Просто открываете соединение на порту 5011. Для установки связи нужно отправить команду '\x0202:con0000020O00000C00000000000000:{"typ":"Application","nam":"DU","ver":"1.01","inf":"0","svr":0,"tim":""}\x03'.
Все даты в формате GMT
3 час. Хитов сегодня: 2
Права: смайлы да, картинки да, шрифты да, голосования нет
аватары да, автозамена ссылок вкл, премодерация откл, правка нет
- участник сейчас на форуме
- участник вне форума