Москва: +7(495) 984-3499
Новосибирск: (383) 230-0255
ICQ Отдела продаж: 673-700-787, 635-877-793, 612-931-528, 623-036-077
Москва: (495) 984-3499
(495) 742-1790
 
(495) 742-1789
(495) 742-1791
Call Free: 8 (800) 333-0313
Новосибирск: (383) 230-0255
(383) 209-0488
(903) 901-3695

Как программно проверить доступность EM100 перед началом работы?

Страницы: 1 2 След.
RSS
Как программно проверить доступность EM100 перед началом работы?, Обсуждение: Как программно проверить доступность EM100 перед началом работы?
 
Распределённая система сбора данных состоит из единственного ПК (сервер, постоянно рядом с ним никто не находится) и пяти удалённых устройств, подключенных с помощью виртуальных 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-порта?
 
Для чистоты эксперимента перенёс процедуру приема из таймера в отдельный поток. К сожалению, это не дало никакого эффекта. Поток со стандартным приоритетом останавливается при "зависании" в момент передачи байта в виртуальный COM-порт, если соответствующая ему плата TIBBO с модулем ЕМ100 в момент передачи обесточена. :(

Хелп, плеазе!... :(
Заказчики давят, уже сожалею, что не пошли по пути прокладки отдельной сети телеконтроля и связи по RS-485...:(
 
Доброго времени суток.
К сожалению, я давно не практиковал программирование под ПК, но попробую описать в чем скорее всего ваша проблема.

Итак, если модуль EM100 включен, то работает все отлично. При отключении питания - возникают зависания и задержки. Логично предположить, что из-за отсутствия ответов.
Все это логично и драйвер тут не при чем, так же как и сам модуль.

При посылке данных в ком порт - программа пытается "действительно передать" ваш байт. Это тоже - что принять данные из несуществующего соединения. Таймауты выставлены по умолчанию и они большие, следовательно возникают зависания.

В общем чтобы исправить ситуацию - передавайте данные в отдельном потоке, так же как и принимайте данные в отдельном потоке.
Т.е. один поток - ваша программа, второй поток - слушаем данные. При необходимости отправки - создаем третий поток, который отдельно от основной программы разбирается сам - передаются данные или нет.

Второй вариант. При открытии ком порта была такая структура... TIMEOUTS, кажется, называется. В ней можно задавать таймауты на прием/передачу. Выставьте мизерные значения этих таймаутов (в пределах разумного) и момент "зависания" будет не заметен для пользователя.

Если не получится - пишите, будем разбираться дальше.
 
typedef struct _COMMTIMEOUTS {
DWORD ReadIntervalTimeout;
DWORD ReadTotalTimeoutMultiplier;
DWORD ReadTotalTimeoutConstant;
DWORD WriteTotalTimeoutMultiplier;
DWORD WriteTotalTimeoutConstant;
} COMMTIMEOUTS,*LPCOMMTIMEOUTS;
Полное описание приложил.

Мало того, что нужно работу с портом распараллелить (кстати, не обязательно запись/чтение в разных потоках. Если запрос/ответ, то можно и в одном, но отдельном от основного потока), так еще и нужно выделить процессорное время: SetThreadPriority(nProcess, THREAD_PRIORITY_TIME_CRITICAL). Иначе будет обрыв в обмене.

4133_Работа с коммуникационными портами COM .rar

 
ага, спасибо!

попробую для начала уменьшит таймаут
действительно логично, должен сократиться период зависания
распараллелить опрос и обмен байтами - также логично, если не поможет первый вариант - согласен, выход
вот тока я уже пробовал с TThread
WriteFile в порт с обесточенным модулем подвешивает все потоки приложения, даже не связанные портом, если тока не задать им сумасшедший приоритет
а сумасшедший приоритет потоков приведёт к конфликту с другими приложениями сервера

а разве у TIBBO нет какой-нибудь dll c функцией, позволяющей контролировать наличие-отсутсвие удалённых клиентов? чтобы даже не открывать тот вирутальный порт, модуль которого обесточен
это, мне кажется, было бы как-то грамотней и красивей, чем обходить проблему огородами...
и в этом случае можно было бы отличить потерю связи с контролируемым объектом (аварию сети) от аварии самого объекта
DS Manager это делает моментом...
 
[quote author=Олег link=topic/7/820/1/#4133 date=30.03.2011 15:39]___[quote]

спасибо, скачал статью
полезная и интересная: разобраться с каждым нюансом работы драйвера порта самому вечно недосуг)
 
Я конечно слаб в Тиббо, но... почему бы просто не пингануть??? Ведь у любого устройства есть IP. Хуже с динамическим, но тоже придумать можно. Хотя реализация самого пинга не так проста как кажется, с программной точки зрения, но в сети полно бесплатных компонент для пинга. Качаем, вставляем, пользуемся.
 
Цитата
Я конечно слаб в Тиббо, но... почему бы просто не пингануть??? Ведь у любого устройства есть IP. Хуже с динамическим, но тоже придумать можно. Хотя реализация самого пинга не так проста как кажется, с программной точки зрения, но в сети полно бесплатных компонент для пинга. Качаем, вставляем, пользуемся.

да уже пробую по сокету) собсна работает...
у TIBBO EM100 статический айпи, всё намана

но сие - последний вариант
проблемную прогу писал не я сам, писала девочка, которая у нас уже не работает
убедить её на серьёзные переработки дорогого стоит)
и с сокеты она никогда не юзала: придётся учить

другое дело - в общем цикле опроса, скажем, проверять порт перед открытием
ну делает же это DS Manager
 
Цитата
Логично предположить, что из-за отсутствия ответов.
Все это логично и драйвер тут не при чем, так же как и сам модуль.

увы, позволю себе усомниться:(
зависание происходит при выполнении единственной стандартной API функции WriteFile
даже в упрощённой программе, которая не требует никакого ответа, просто передаёт в порт один единственный байт

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

вообще, мне вот представляется логичным предположение, что программисты TIBBO заложили в своих библиотеках все функции контроля удалённых модулей, включая чтение конфигурации
только я на сайте TIBBO их описания, к сожалению, не нашёл, а ответа от TIBBO не дождался
видимо мой английский оставляет желать лучшего)))
 
Цитата

другое дело - в общем цикле опроса, скажем, проверять порт перед открытием
ну делает же это DS Manager
Спешу Вас огорчить. Поиск модуля делается широковещательным опросом. А проверка наличия - его пингом. Перехватите трафик и убедитесь. Через открытие СОМ-порта, посылом туда чего-то, ожиданием ответа и последующим закрытием несколько кхм... геморройно.

Цитата

увы, позволю себе усомниться:(
зависание происходит при выполнении единственной стандартной API функции WriteFile
даже в упрощённой программе, которая не требует никакого ответа, просто передаёт в порт один единственный байт

скажем, при работе с виртуальным портом, подключенным по USB такого не происходит, даже если его нагло выдернуть в процессе работы из ПК (можете сами убедиться, я сейчас специально перепроверил это со стандартным пролификом)
Тут уж вопросы к Мелкомягким. Эта АПИ функция хоть и делает все для всех устройств и файлов, однако очень по-разному. Точнее 3 функции CreateFile(), WriteFile(), ReadFile().

Цитата

вообще, мне вот представляется логичным предположение, что программисты TIBBO заложили в своих библиотеках все функции контроля удалённых модулей, включая чтение конфигурации
только я на сайте TIBBO их описания, к сожалению, не нашёл, а ответа от TIBBO не дождался
видимо мой английский оставляет желать лучшего)))
А зачем? Ведь модули идут в большинстве своем как некий конструктор. Вы сами собираете, программируете и настраиваете как нужно. Конечное устройство идет уже со своим ПО. Какое-то даже платное. Получается, что написав что-то для ПК в одном случае использовать не нужно, т.к. программа управления Тиббо будет написана пользователем, а в другом случае уже есть под конкретную реализацию. Для управления и первоначальной настройки ПО есть.
Страницы: 1 2 След.

Яндекс.Метрика