ICQ Отдела продаж: 282-104-241, 492-711-783, 623-036-077
Форум» Техподдержка по товарам компании» Оборудование компании Tibbo» Как программно проверить доступность EM100 перед началом работы?
Как программно проверить доступность EM100 перед началом работы?
| Автор | Сообщение |
|---|---|
|
fiatik fiatik
Регистрация: 29.03.2011
Кол-во сообщений: 13
|
Распределённая система сбора данных состоит из единственного ПК (сервер, постоянно рядом с ним никто не находится) и пяти удалённых устройств, подключенных с помощью виртуальных COM-портов (драйвер TIBBO) и стандартных плат с модулем EM100. Питание плат осуществляется от блоков питания контролируемых устройств. Программа ПК помимо сбора данных раз в десять секунд отправляет каждому устройству короткую посылку с целью проверки связи. Когда все устройства включены – никаких проблем не возникает. Если хотя бы одно обесточено в момент запуска программы на ПК, то соответствующий ему виртуальный порт открывается нормально, но при первой передаче в этот порт хотя бы одного байта, программа «зависает» секунд на 12-15. Это весьма раздражает пользователей и периодически приводит к потерям информации от остальных устройств. Приложение для ПК написано в Delphi. С целью исключения подозрений на ошибку программиста или протокола обмена с контролируемыми устройствами и т.д., поставлен эксперимент: короткая программа отправляет в единственный порт единственный байт по нажатию кнопки. Увы, эффект сохранился. Останавливается таймер, не отжимается кнопка и т.д. Причём, увы, даже не возникает аварийной ситуации, которую можно было бы отследить программно в блоке try … except… После первой неудачной попытки передачи эффект исчезает и задержек больше не происходит до следующего закрытия и открытия этого порта. Если после этого включить питание обесточенного устройства, то через несколько секунд всё опять начинает работать без проблем. Процедура передачи в порт (вызывается нажатием кнопки на форме): procedure TFormMain.Trans2MyCommand; var btb:byte; ActualSent:dword; begin try if MyOnWorking then begin btb:=$31; WriteFile(RMyComm.MyPortH,btb,1,ActualSent,NIL); end; except ShowMessage('Ошибка передачи!!!') end; end; Процедура приёма вызывается в системном таймере. Ещё раз подчёркиваю: когда плата с модулем EM100 включена, то никаких проблем не возникает с любым количеством контролируемых устройств. Мы были бы очень благодарны, если бы нам подсказали пути борьбы с обнаруженным эффектом. Быть может можно соответственным образом изменить настройки виртуального порта? (Если честно, я сегодня, как мне кажется, уже перебрал все возможные варианты настройки…) Быть может драйвер позволяет контролировать состояние платы, соответствующей виртуальному порту каким-либо запросом? Быть может есть возможность производить диагностику плат до открытия виртуального COM-порта? |
|
fiatik fiatik
Регистрация: 29.03.2011
Кол-во сообщений: 13
|
Для чистоты эксперимента перенёс процедуру приема из таймера в отдельный поток. К сожалению, это не дало никакого эффекта. Поток со стандартным приоритетом останавливается при "зависании" в момент передачи байта в виртуальный COM-порт, если соответствующая ему плата TIBBO с модулем ЕМ100 в момент передачи обесточена.  Хелп, плеазе!... Заказчики давят, уже сожалею, что не пошли по пути прокладки отдельной сети телеконтроля и связи по RS-485...
|
|
support_tibbo
Регистрация: 02.06.2008
Кол-во сообщений: 69
|
Доброго времени суток. К сожалению, я давно не практиковал программирование под ПК, но попробую описать в чем скорее всего ваша проблема. Итак, если модуль EM100 включен, то работает все отлично. При отключении питания - возникают зависания и задержки. Логично предположить, что из-за отсутствия ответов. Все это логично и драйвер тут не при чем, так же как и сам модуль. При посылке данных в ком порт - программа пытается "действительно передать" ваш байт. Это тоже - что принять данные из несуществующего соединения. Таймауты выставлены по умолчанию и они большие, следовательно возникают зависания. В общем чтобы исправить ситуацию - передавайте данные в отдельном потоке, так же как и принимайте данные в отдельном потоке. Т.е. один поток - ваша программа, второй поток - слушаем данные. При необходимости отправки - создаем третий поток, который отдельно от основной программы разбирается сам - передаются данные или нет. Второй вариант. При открытии ком порта была такая структура... TIMEOUTS, кажется, называется. В ней можно задавать таймауты на прием/передачу. Выставьте мизерные значения этих таймаутов (в пределах разумного) и момент "зависания" будет не заметен для пользователя. Если не получится - пишите, будем разбираться дальше. Отредактировано: support_tibbo 30.03.2011 15:34
|
Олег Плюснин
Регистрация: 28.05.2008
Кол-во сообщений: 2045
|
typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; DWORD ReadTotalTimeoutMultiplier; DWORD ReadTotalTimeoutConstant; DWORD WriteTotalTimeoutMultiplier; DWORD WriteTotalTimeoutConstant; } COMMTIMEOUTS,*LPCOMMTIMEOUTS; Полное описание приложил. Мало того, что нужно работу с портом распараллелить (кстати, не обязательно запись/чтение в разных потоках. Если запрос/ответ, то можно и в одном, но отдельном от основного потока), так еще и нужно выделить процессорное время: SetThreadPriority(nProcess, THREAD_PRIORITY_TIME_CRITICAL). Иначе будет обрыв в обмене. Отредактировано: Олег Плюснин 30.03.2011 15:44
|
|
fiatik fiatik
Регистрация: 29.03.2011
Кол-во сообщений: 13
|
ага, спасибо! попробую для начала уменьшит таймаут действительно логично, должен сократиться период зависания распараллелить опрос и обмен байтами - также логично, если не поможет первый вариант - согласен, выход вот тока я уже пробовал с TThread WriteFile в порт с обесточенным модулем подвешивает все потоки приложения, даже не связанные портом, если тока не задать им сумасшедший приоритет а сумасшедший приоритет потоков приведёт к конфликту с другими приложениями сервера а разве у TIBBO нет какой-нибудь dll c функцией, позволяющей контролировать наличие-отсутсвие удалённых клиентов? чтобы даже не открывать тот вирутальный порт, модуль которого обесточен это, мне кажется, было бы как-то грамотней и красивей, чем обходить проблему огородами... и в этом случае можно было бы отличить потерю связи с контролируемым объектом (аварию сети) от аварии самого объекта DS Manager это делает моментом... Отредактировано: fiatik fiatik 31.03.2011 10:35
|
|
fiatik fiatik
Регистрация: 29.03.2011
Кол-во сообщений: 13
|
Цитата: Олег 30.03.2011 15:39 ___ |
|
Олег Плюснин
Регистрация: 28.05.2008
Кол-во сообщений: 2045
|
Я конечно слаб в Тиббо, но... почему бы просто не пингануть Ведь у любого устройства есть IP. Хуже с динамическим, но тоже придумать можно. Хотя реализация самого пинга не так проста как кажется, с программной точки зрения, но в сети полно бесплатных компонент для пинга. Качаем, вставляем, пользуемся.
|
|
fiatik fiatik
Регистрация: 29.03.2011
Кол-во сообщений: 13
|
Цитата: Олег 31.03.2011 10:38 Я конечно слаб в Тиббо, но... почему бы просто не пингануть да уже пробую по сокету) собсна работает... у TIBBO EM100 статический айпи, всё намана но сие - последний вариант проблемную прогу писал не я сам, писала девочка, которая у нас уже не работает убедить её на серьёзные переработки дорогого стоит) и с сокеты она никогда не юзала: придётся учить другое дело - в общем цикле опроса, скажем, проверять порт перед открытием ну делает же это DS Manager |
|
fiatik fiatik
Регистрация: 29.03.2011
Кол-во сообщений: 13
|
Цитата: support_tibbo 30.03.2011 15:32 Логично предположить, что из-за отсутствия ответов. увы, позволю себе усомниться зависание происходит при выполнении единственной стандартной API функции WriteFile даже в упрощённой программе, которая не требует никакого ответа, просто передаёт в порт один единственный байт скажем, при работе с виртуальным портом, подключенным по USB такого не происходит, даже если его нагло выдернуть в процессе работы из ПК (можете сами убедиться, я сейчас специально перепроверил это со стандартным пролификом) вообще, мне вот представляется логичным предположение, что программисты TIBBO заложили в своих библиотеках все функции контроля удалённых модулей, включая чтение конфигурации только я на сайте TIBBO их описания, к сожалению, не нашёл, а ответа от TIBBO не дождался видимо мой английский оставляет желать лучшего))) |
|
Олег Плюснин
Регистрация: 28.05.2008
Кол-во сообщений: 2045
|
Цитата: fiatik 31.03.2011 10:45
Спешу Вас огорчить. Поиск модуля делается широковещательным опросом. А проверка наличия - его пингом. Перехватите трафик и убедитесь. Через открытие СОМ-порта, посылом туда чего-то, ожиданием ответа и последующим закрытием несколько кхм... геморройно. Цитата: fiatik 31.03.2011 11:14
Тут уж вопросы к Мелкомягким. Эта АПИ функция хоть и делает все для всех устройств и файлов, однако очень по-разному. Точнее 3 функции CreateFile(), WriteFile(), ReadFile(). Цитата: fiatik 31.03.2011 11:14
А зачем? Ведь модули идут в большинстве своем как некий конструктор. Вы сами собираете, программируете и настраиваете как нужно. Конечное устройство идет уже со своим ПО. Какое-то даже платное. Получается, что написав что-то для ПК в одном случае использовать не нужно, т.к. программа управления Тиббо будет написана пользователем, а в другом случае уже есть под конкретную реализацию. Для управления и первоначальной настройки ПО есть. Отредактировано: Олег Плюснин 31.03.2011 11:51
|
|
fiatik fiatik
Регистрация: 29.03.2011
Кол-во сообщений: 13
|
Цитата: Олег 31.03.2011 11:51 Спешу Вас огорчить. Поиск модуля делается широковещательным опросом. А проверка наличия - его пингом. ага, спасип ясно, это собсна и неплохо а протокол опроса известен? хотя, собсна при обращении по сокету так и так ничего не зависает, ошибки 10053 или 10060 легко отслеживаются |
|
fiatik fiatik
Регистрация: 29.03.2011
Кол-во сообщений: 13
|
Цитата: Олег 31.03.2011 11:51
ахм ну, тут позволю себе согласиться не полностью собсна то, что я сейчас, судя по всему, буду вынужден реализовывать под сокет, уже, скорее всего, реализовано разработчиками в DLL, которой комплектуется стандартное ПО для настройки TIBBO и тот же широкополосный опрос, и тот же пинг, и запрос конфигурации както далёк от мысли, что программисты TIBBO всё это реализуют в самих экзешниках DS Manager и т.д. эти DLL свободны для скачивания и распространиения и, так или иначе, устанавливаются вместе с драйвером вот мне какта и надеялось избежать лишней дурной работы) ну и потом, это дало бы дополнительные возможности системе для самоконтроля а если бы была возможность избежать программирования сокетов - было бы вообще замечательно я вот сейчас чешу затылок: сколько времени пройдёт, пока программистка освоит непривычные концепции и переделает прежнюю программу... и скока сил и времени уйдёт на проверки и отладки... впрочем, не настаиваю: голимое имхо на нет - суда нет) так или иначе спасибо |
|
fiatik fiatik
Регистрация: 29.03.2011
Кол-во сообщений: 13
|
Цитата: Олег 31.03.2011 11:51 Перехватите трафик и убедитесь. вау, а этого я не умею, честно говоря но - смотрите - это опять метод научного тыка вместо чтения документации) |
|
Олег Плюснин
Регистрация: 28.05.2008
Кол-во сообщений: 2045
|
Если разработчик закрыл протокол и не публикует его, значит для чего-то это сделал. Мы тут не в силах повлиять. С нуля написать пинг займет день-два. Лучше использовать компоненту. Тогда 2-3 часа. Ну а то, что программист не знает сокеты... я промолчу. Году в 2000 это было бы простительно. А вот избежать сокетов при программировании сетевого устройства тяжко и как показала практика - неэффективно. Отредактировано: Олег Плюснин 31.03.2011 13:50
|
|
fiatik fiatik
Регистрация: 29.03.2011
Кол-во сообщений: 13
|
Цитата: Олег 31.03.2011 13:48 Ну а то, что программист не знает сокеты... я промолчу. хе)) а как тогда программисты, не знающие, что целочисленные типы данных таки имеют отличия от чисел с плавающей точкой? или ваще не отличающие процедуру от функции? люди сидят всю жизнь в своей галактике, 1С или фоксе, на проблемы заявляют - это мы не проходили) зато прекрасно умеют намекать на оплату сверхурочных по устранению собственных хомутов) а как они любят тестировать продукты сторонних производителей (то бишь нас, этаких гадких) на предмет отысканий поводов недоплатить за работу)! да могу научить... и так я её два года мона сказать учил по мере необходимости, ещё студенткой что |
|
fiatik fiatik
Регистрация: 29.03.2011
Кол-во сообщений: 13
|
Цитата: Олег 31.03.2011 13:48 С нуля написать пинг займет день-два. Лучше использовать компоненту. Тогда 2-3 часа. ахм.. лана, хоть меня тута и упрекнули в склонности к ужасному флуду.. с использованием стандартного Indy 15 минут: procedure TFormMain.IdIcmpClient1Reply(ASender: TComponent; const AReplyStatus: TReplyStatus); begin if AReplyStatus.FromIpAddress'0.0.0.0' then Memo1.Lines.Add('Есть ответ от '+AReplyStatus.FromIpAddress +' '+IntToStr(AReplyStatus.MsRoundTripTime)) else Memo1.Lines.Add('Истёк таймаут ожидания ответа '+IntToStr(AReplyStatus.MsRoundTripTime)); end; procedure TFormMain.SBPingClick(Sender: TObject); begin IdIcmpClient1.Host:='192.168.0.145'; IdIcmpClient1.ReceiveTimeout:=1000;//таймаут ожидания ответа - секунда IdIcmpClient1.Port:=1001; IdIcmpClient1.Ping(); end; с использованием API - полчаса-час ---------- но - это всё неграмотный и некорректный подход, имхо правильней использовать функции DLL разработчика никто и никогда их не держит в тайне специально отсутствие информации об оборудовании - однозначная недоработка службы поддержки Отредактировано: Олег Плюснин 19.04.2011 09:57
|
