Отправлено: 28.06.16 16:16. Заголовок: Simpl+ connect status: -65528

Коллеги, подскажите, пожалуйста, что за ошибка может быть? Проблема явно в коде, но она не очевидная - перелопатил всю программу и не нашёл причину.
В общем кусок программы такой:
TCP_CLIENT Dune [65534];
SIGNED_INTEGER Status;
Status=SocketConnectClient(Dune,"172.16.87.33",80,0);
if(Status<0)
Debug[1]="connect status: "+"-"+itoa(Status);
else
Debug[1]="connect status: "+itoa(Status);

И в дебагере вначале: ""connect status: 0", но после очередного вызова модуля вижу это: "connect status: -65528"
Вначале коннект проходит, но через несколько раз перестаёт проходить. Не понимаю, как он может вначале работать, а потом нет? Ведь параметры SocketConnectClient(Dune,"172.16.87.33",80,0) неизменные!

 Отправлено: 28.06.16 18:51. Заголовок: Если верить хэлпу 0 ..

Если верить хэлпу 0 это тоже плохой статус (not connected). Удачный 2.
Получается как в анекдоте то потухнет то погаснет.
Т.е. коннекта как не было, так и нет. Проверяйте доступность устройства (ping) по сети из командной строки контроллера. Может с маской ошиблись в настройках какого то устройства(обычно для такого класса сетей она 255.255.0.0)
Главное чтобы маска была одинаковой для устройств из одной подсети.

 Отправлено: 29.06.16 10:01. Заголовок: Вячеслав, это Вы нап..

Вячеслав, это Вы написали для SocketGetStatus
Вячеслав пишет:

цитата:

Если верить хэлпу 0 это тоже плохой статус (not connected). Удачный 2.

А для SocketConnectClient из хелпа такие статусы:

цитата:

Return Value: 0: Success <0: Error -1: ClientVariable is not a TCP/IP client variable. -2: Could not create the connection task -3: Port not in range of 0-65535.

В том и дело, что SocketGetStatus у меня в программе есть вначале выполнения SOCKETSTATUS. Так вот до него не доходит! Т.е. не изменяется SOCKETSTATUS потому, что SocketConnectClient не начинает конектиться, а вылетает с ошибкой при том, что вначале коннектится. Подозреваю, правда, что проблема не в нём, а в остальном тексте программы.
Пока встречался с глюками Simpl+ когда индекс переменной делался больше максимального, а второй раз, когда зацикливание устроил. Ничего такого сейчас нет.

 Отправлено: 29.06.16 10:33. Заголовок: Меня больше смущает ..

Меня больше смущает сам статус -65528
если учесть что:
SIGNED_INTEGER values are 16-bit quantities ranging from -32678 to 32767

 Отправлено: 29.06.16 11:18. Заголовок: DmitriiP пишет: -32..

DmitriiP пишет:

цитата:

-32678 to 32767

Ага, меня это тоже смутило!
Нашёл: в дебрях кода был повторный SocketConnectClient. Он стоял при SOCKETDISCONNECT, поэтому он больше всего не смущал меня, но, видимо, он часто пересекался с другим SocketConnectClient, поэтому и становился вылет в ошибку, а потом и зацикливание.

 Отправлено: 29.06.16 19:20. Заголовок: Ну а ping то проходи..

Ну а ping то проходит на дюну, проверяли с контроллера?
Или подключите на веревку контроллера ноутбук с теже адресом и выполните из браузера одну из доступных команд. Так будет вернее всего. А то может айтишники 80 порт прикрыли
Хотите ещё быстрее, и грешите на модуль, то добавьте стандартный TCP/IP клиент и посмотрите на его статус

 Отправлено: 30.06.16 14:19. Заголовок: Вячеслав пишет: Ну ..

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

цитата:

Ну а ping то проходит на дюну, проверяли с контроллера?

Конечно ping пройдёт, если я написал, что
СергейК пишет:

цитата:

Вначале коннект проходит

В общем я сделал буфер на 8 команд, чтобы если в момент передачи одной команды поступали ещё другие, то вместо коннекта команды записывались в буфер и после дисконнекта, если буфер не пустой, происходил новый коннект:

цитата:

SOCKETDISCONNECT Dune { IF (i_buf) Status=SocketConnectClient(Dune,Dune_IP,80,0); }

Наполнение буфера происходит при появлении новой команды, а опустошение - при передаче команды первой в списке.

 Отправлено: 30.06.16 23:12. Заголовок: Последний пост про б..

Последний пост про буфер как то увел тему в сторону. Но наводит на определенные мысли:
1.Если процедуру socketsend вынести в функцию - типа Function SendDATA(string data) Название для примера исключительно.
То организация буфера не потребуется, за вас это сделает сама программа порождая параллельные процессы. Не говоря уж про удобство кода. Неужели у Вас не так?
2.Естественно для процедуры соединения (после выполнения SocketConnectClient которую так же лучше вынести в функцию Connect) требуется время до того как вы можете воспользоваться SocketSend, для этого в теле функции SendDATA
я использую цикл ожидания соединения порядка 10с с шагом проверки этого статуса каждую 0.1с. как только соединение устанавливается выполняется SocketSend. Если за 10с оно так и не было установлено или SocketSend вернуло <0, то в дебаг пишем что команда строковая переменная data не отправлена.
3.Естественно SocketConnectClient не следует вызывать, если соединение уже установлено. Для это просто делаете проверку if и при установленном соединении сразу пытаетесь отправить команду SocketSend. (хотя тут бывают свои приколы с ненавистной ошибкой -7 даже отслеживая -5)
4. И последнее но не в последнюю очередь 65528 это на самом деле -8. АТОI и дебагер не знает, что вы работаете с отрицательными числами (используйте %d в makestring) Т.е. соединение в статусе progress - устанавливается. Налицо попытка отправить пулеметную очередь команд не дождавшись соединения. (см.п2)

 Отправлено: 01.07.16 01:13. Заголовок: Я фигею, как вы на т..

Я фигею, как вы на такое натыкаетесь?
Базовые понятия и мануалы где?

 Отправлено: 05.07.16 13:03. Заголовок: Наверное, я не прав,..

Наверное, я не прав, что не объяснил заранее и породил кучу вопросов. В данном случае соединение http, поэтому...
Вячеслав пишет:

цитата:

"Последний пост про буфер как то увел тему в сторону." - Это решило вопрос: изначально в скаченном для Дюны модуле действие не происходило, если шла отправка другой команды. Я сделал отправку в любом случае, что в принципе частично помогло, но при опросе раз в секунду проц уходил в затык с таким номером ошибки. После организации буфера и отправки команд по очереди всё решилось "Но наводит на определенные мысли: 1.Если процедуру socketsend вынести в функцию - типа Function SendDATA(string data) Название для примера исключительно. То организация буфера не потребуется, за вас это сделает сама программа порождая параллельные процессы. Не говоря уж про удобство кода. Неужели у Вас не так?" - это всё хорошо, если работаешь с постоянным соединением. В моём случае это - http, и его нужно перед каждой командой восстанавливать, а после каждой команды оно рвётся. "2.Естественно для процедуры соединения (после выполнения SocketConnectClient которую так же лучше вынести в функцию Connect) требуется время до того как вы можете воспользоваться SocketSend, для этого в теле функции SendDATA я использую цикл ожидания соединения порядка 10с с шагом проверки этого статуса каждую 0.1с. как только соединение устанавливается выполняется SocketSend. Если за 10с оно так и не было установлено или SocketSend вернуло <0, то в дебаг пишем что команда строковая переменная data не отправлена." - Можно проще, чем раз в 0.1с проверять соединилось ли? Просто если соединение прошло успешно - отправлять команду: SOCKETSTATUS Dune { TCPS = SocketGetStatus(); SWITCH (TCPS) { CASE (2): // We're connected { SocketSend(... "3.Естественно SocketConnectClient не следует вызывать, если соединение уже установлено. Для это просто делаете проверку if и при установленном соединении сразу пытаетесь отправить команду SocketSend. (хотя тут бывают свои приколы с ненавистной ошибкой -7 даже отслеживая -5)" - Метод хороший, хотя не в случае http, где соединение есть смысл открывать только чтобы отправлять команду сразу. "4. И последнее но не в последнюю очередь 65528 это на самом деле -8. АТОI и дебагер не знает, что вы работаете с отрицательными числами (используйте %d в makestring) Т.е. соединение в статусе progress - устанавливается. Налицо попытка отправить пулеметную очередь команд не дождавшись соединения. (см.п2)" - После публикации поста я это понял. Но вот где найти описание ощибки "-8" я не понял?

 Отправлено: 05.07.16 14:09. Заголовок: 1.На дюне я собаку ..

1.На дюне я собаку съел уже или 2 (обе были крайне невкусными), не помню чтоб она разрывала соединение.
Вопрос в выносе процедуры установления соединения в отдельную функцию по крайней мере сократит код программы, не говоря про буфер команд и никоим образом не связана с удержанием соединения.

2."Просто если соединение прошло" - чтоб это ПРОСТО узнать как раз и требуется проверять глобальную переменную, которая формируется в событиях SOCKETCONNECT (var=1) и SOCKETDISCONNECT (var=0), отправка в событии SOCKETSTATUS привязывает вас к организации буфера команд. Вероятно при отправке команды, вы помещаете её в буфер и выполняете connect? Что не сделать повторное подключение все равно его проверять надо. Причем первую надо отправить сразу не дожидаясь первого дисконекта. Это конечно лишь мои догадки.

3.Если нужна отзывчивость интерфейса и устройство не рвет соединение сразу после приема любой команды, соединение лучше поддерживать. Иначе при отправке каждой команды получите задержку на его установление.

4.В help по SocketConnectClient щелкаете на первую ссылку в NOTE: Return values that are negative numbers are errors. More information on error codes for Direct Socket functions can be found here.

P.S. C другой стороны, если Ваш модуль для DUNE выполняет возложенные на него задачи не оставляет при этом сыроватый осадок "да чтоб я с этим Г... еще раз", то честь Вам и хвала.

 Отправлено: 05.07.16 15:01. Заголовок: Вячеслав пишет: не ..

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

цитата:

не помню чтоб она разрывала соединение.

Для написания своего модуля я использовал модуль: DuneHD_IP_Control_V2c Там, даже, заложено, что при неразрыве соединения через 20милисек после соединения разорвать принудительно!
А Вы какой модуль можете порекомендовать? Или можете поделиться своим? Буду признателен!
Вячеслав пишет:

цитата:

чтоб это ПРОСТО узнать как раз и требуется проверять глобальную переменную, которая формируется в событиях SOCKETCONNECT (var=1) и SOCKETDISCONNECT (var=0), отправка в событии SOCKETSTATUS привязывает вас к организации буфера команд.

- изменение состояния проверяется программой автоматически с помощью: SOCKETSTATUS Dune. Не уловил, зачем каждые 0.1с проверять?
Вячеслав, поделитесь, если не трудно, с основными проблемами при поедании дюны.

 Отправлено: 05.07.16 15:40. Заголовок: Можете не проверять ..

Можете не проверять каждые 0.1с, подход у Вас другой и он тоже допустим и даже еще более точен, но имеет "недостаток" - организация буфера команд.
Просто подход иной. Я чтоб не потерять команду(ы) ожидаю соединения, вы наполняете буфер и ждете дисконекта. Мне просто не понятно, как вы первую команду отправляете если буфер пуст. Можно конечно поместить её сразу в буфер и выполнить последовательно connect disconnect.
А откуда взялся DuneHD_IP_Control_V2c ? По наследству?
Основная проблема в некорректности данных fb:
1.Статус playing, а длительность 0с (всегда в начале воспроизведения, может даже несколько раз вернуть 0)
2.Не верная длительность композиции (уж как она умудряется ее из тега считывать неверно х.з) - иногда
+
3.Неработоспособность прямых команд случайного выбора и повтора композиций в плей листе (пришлось макрос городить)
4.При воспроизведении потокового вещания имеется неуправляемый буфер (неудобство реализации трансляции, либо тишину передавать не прерывая поток)
В итоге она очень не отзывчива к командам получается, чтоб чего нить не подвесить надо нажимать кнопки с чувством-расстановкой.

 Отправлено: 05.07.16 16:34. Заголовок: Вячеслав пишет: как..

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

цитата:

как вы первую команду отправляете если буфер пуст.

- Просто запускаю единственный в моём модуле SocketConnectClient в таком же "Function SendDATA(string data)". Т.е.:Вячеслав пишет:
1) При нажатии на кнопку, или дисконекте(если буфер не пуст), или проверке статуса (которая раз в секунду), происходит запуск этой функции.
2) В ней идёт проверка: соединение запущено, или нет. Если нет, то запускается, если да, то команда записываетя в буфер и (см. п.1.)

цитата:

А откуда взялся DuneHD_IP_Control_V2c

- наследие предков yahoo групп
Вячеслав пишет:

цитата:

1.Статус playing... 2.Не верная длительность...

- пока не наблюдал такого, хотя усиленно тестировал на открытии файлов до 10Гб типа avi и mpg - модуль всегда длину правильно указывал. Я, даже, сделал в своём модуле возможность перемотки фильма (путём тыкания в барграф на crestron панели) - работает как часы, а там, естественно, необходима длительность.
Пункты 3, 4 усиленно не тестировал. Всё делал на Dune HD 4K Solo с последней прошивкой.

 Отправлено: 05.07.16 20:02. Заголовок: А что за команда для..

А что за команда для перехода на нужную позицию? (может сразу свежий api cкините чтоб не рыть сайт)
В моих уже стареньких шпаргалках такого нет.
И что у вас в функции между SocketConnectClient и SocketSend никаких даже delay? Раз не используете цикл ожидания соединения. Функцию disconnect вообще используете или как проверяете что соединение уже не установлено дабы повторно не ткнуть сonnect?

 Отправлено: 06.07.16 09:07. Заголовок: Вячеслав пишет: А ч..

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

цитата:

(может сразу свежий api cкините чтоб не рыть сайт)

http://dune-hd.com/support/ip_control/
Вячеслав пишет:

цитата:

А что за команда для перехода на нужную позицию?

Я использовал мануал по командам дюны "GET /cgi-bin/do?cmd=set_playback_state&speed=256&position="+КАКУЮ ХОТИТЕ ПОЗИЦИЮ+"&black_screen=0&action_on_finish=restart_playback HTTP/1.0\n\n"
Но "КАКУЮ ХОТИТЕ ПОЗИЦИЮ" - вычисляется сложно, с умножением на максимальное значение и сдвигом. Если интересно - скину.
Вячеслав пишет:

цитата:

И что у вас в функции между SocketConnectClient и SocketSend никаких даже delay

А зачем? Если я отправляю команду по успешному соединению, ведь - когда SocketGetStatus() = 2. Ещё в прошлой фирме начальник научил, что "delay" - костыль, который можно вставить исключительно временно, пока не перепишешь на нормальный код.
Вячеслав пишет:

цитата:

Раз не используете цикл ожидания соединения. Функцию disconnect вообще используете или как проверяете что соединение уже не установлено дабы повторно не ткнуть сonnect?

SocketDisconnectClient использую в функции "Function SendDATA(string data)" сразу после SocketConnectClient и WAIT(Timeout,CmdTimeout). Timeout в коротких командах = 80 (хотя, надо ещё будет потестировать: в зависимости от команд Дюна может и подтормаживать). Т.е. в штатной ситуации Дюна сама разрывает соединение (SocketGetStatus() = 4). Тогда я отправляю
"SOCKETDISCONNECT Dune
{
CANCELWAIT(CmdTimeout);"
Но если дюна тормозит, то разрываю принудительно по WAIT. 80 взял, т.к. 20 было мало, а при 30 то срабатывала команда, а то - нет. Поэтому взял с запасом на успешное получение результата.
Ну а...Вячеслав пишет:

цитата:

как проверяете что соединение уже не установлено дабы повторно не ткнуть сonnect

- уже писал выше. Т.е. использую флаги: если флаг говорит "1", то значит SOCKETDISCONNECT ещё не прошёл, и ставлю команду в очередь, которая проходит когда...СергейК пишет:

цитата:

дисконекте(если буфер не пуст), или проверке статуса (которая раз в секунду), происходит запуск этой функции

Вячеслав, но меня всё-таки не покидает один вопрос: Вячеслав пишет:

цитата:

не помню чтоб она разрывала соединение.

Как это при http-запросе не разрывается соединение? Даже, если ставить "Connection: Keep-Alive" - всё-равно сразу после получения ответа происходит разрыв и новые команды не проходят, приходится восстанавливать соединение - в своё время на нескольких железках перепробовал. Так и дюна соединение сама рвёт. Как у Вас она не рвёт?

 Отправлено: 06.07.16 14:36. Заголовок: Может и рвет. Просто..

Может и рвет. Просто мне не бросалось это в глаза. Сейчас некогда проверять. Таймер неактивности определенно какой то должен быть. Вот с bosch у меня 60с висит соединение неактивное, только потом он его разрывает, если обмен идет то соединение не разрывается сколь угодно долго.

Интересный подход конечно. Так до конца нюансы и не понятны по описанию.
1.SocketSend только в событии SOCKETSTATUS Dune? И первая команда тоже в буфер идет сразу?
2.Если 0,8с приходит еще одна команда то получаем ошибку повторного подключения. Неужели за 0,8с успевает соединение подняться и отправится команда. Хотя может и успевает, раз я дисконекта особо не замечал у себя.

А без delay иногда никуда. Тот же bosch удивлял: Отправляешь команду активировать микрофон - микрофон включается. Отправляешь запрос на список включенных - а в ответ= его там еще нет. Пришлось небольшой delay таки сделать перед запросом статуса.

ScaleTime интересный вариант, никогда не приходило использовать множители кратные 2. Удобно. Но не понял из каких соображений 65200 автор взял.

 Отправлено: 06.07.16 15:42. Заголовок: По поводу СергейК ..

По поводу СергейК Как это при http-запросе не разрывается соединение?

Непомню что за чудо-устройство было: при попытке ввести его в stand-by, соединение не закрывалось. Както неправильно оно обрубало выполнене cgi, устройство отвечало статусом, засыпало а соединение висело открытым.

 Отправлено: 06.07.16 17:12. Заголовок: Так происходит, напр..

Так происходит, например если с Dune после работы с NAS Synopogy не закрывать сеанс. Плеер уже выключен, а на сервере висит соединение и он не уходит в спящий режим.

 Отправлено: 07.07.16 10:40. Заголовок: Вячеслав пишет: Вот..

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

цитата:

Вот с bosch у меня 60с висит соединение неактивное, только потом он его разрывает

Так Бош же другими командами по другому протоколу общается, поэтому и висит соединение. А чтобы оно не обрывалось я использовал модуль для боша, который отправлял ему каждые 30сек спец.сообщение.

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

цитата:

1.SocketSend только в событии SOCKETSTATUS Dune? И первая команда тоже в буфер идет сразу?

Да. Ведь, отправка команды только в одном месте, а значит надо брать из буфера. На мой взгляд - упрощение кода.

цитата:

2.Если 0,8с приходит еще одна команда то получаем ошибку повторного подключения.

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

цитата:

Неужели за 0,8с успевает соединение подняться и отправится команда.

Опытным путём - примерно за 0,3с +/-. 0,8с - чтобы дать вволю времени ещё и на получение ответа и возможность дюне самой разорвать соединение. На самом деле 0,3с для меня показалось очень долго. На AMX когда кодил, дисконнект делал через 0,2с и ВСЕГДА ВСЁ РАБОТАЛО: хватало на коннект, отправку команды и получение ответа. Crestron какой-то медленный по сравнению с AMX. Но это, может быть, потому что я не на s#, а на s+ пока кодю?

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

цитата:

ScaleTime интересный вариант

Уже успели изучить модуль Да, меня тоже очень удивила эта цифра 65200. У меня была мысль, что методом проб и ошибок автор понял, что значение больше - вылетает в неправильное значение, поэтому делает его автоматически максимальным. Ну а округление такое из-за сдвига.

 Отправлено: 07.07.16 10:49. Заголовок: DmitriiP, Игорь K., ..

DmitriiP, Игорь K., на сколько я понял ваши слова, не закрытие соединения в описанном вами случае - ошибка. Я тут в википедию залез: https://ru.wikipedia.org/wiki/Постоянное_HTTP-соединение
В связи с чем возник вопрос: а пробовал ли кто-нибудь отправлять несколько команд в одном HTTP-соединении? На сколько я понял из статьи, HTTP1.1 и HTTP/2 это позволяют.