support_ tibbo (Все сообщения пользователя)

Напишите письмо на support@tibbo.ru с контактным телефоном для связи и более подробным описанием проблемы. Возможно, нашим специалистам потребуется удаленное подключение к вашему ПК.

TR515EF может считывать оба кода (Code39 и Code128 ).

ПО на компьютере лишь единожды (при нажатии на кнопку) посылает команду "помигать" светодиодами. Так что оно не при чем.
Если мигание теперь постоянно, то варианта два:
1. Перед нажатием кнопки buzz, вы меняли настройки модули, и новые параметры оказались некорректными, о чем модуль пытается сообщить светодиодами. Посмотреть статус ошибки в этом случае можно [url=http://soi.tibbo.com/extras/leds.html]здесь[/url].
2. "Зависла" прошивка модуля, в этом случае нужно перепрошить устройство. Файл прошивки можно скачать [url=http://tibbo.com/downloads.html]здесь[/url].

Итак, ваши действия: открываете первую ссылку, смотрите, соответствует ли ваша светодиодная индикация какой-либо ошибке. Если да - ищем в документации решение проблемы или пишем мне. Если соответствия не нашли - качаем по-второй ссылке файл прошивки и обновляем модуль.

В принципе, второе решение более быстрое и надежное, но вы так и не поймете в чем была проблема.

Добрый день! Вы все сделали правильно (DHCP выставили в Enable). Возможно неккоректны другие параметры устройства. Скиньте мне на почту (support собачко tibbo.ru) принт-скрины всех вкладок параметров конвертера (вкладки DS Manager'a).

Если я правильно понял по приведенной схеме: одна машина постоянно находится в режиме прослушивания сокета по определенному порту и, если какой-либо из тиббо модулей высылает данные - то они должны придти как раз на эту машину. Второй компьютер сам обращается к tibbo модулям по мере необходимости с помощью виртуального COM-порта. Если все так - то да, так настроить можно.

Только следует помнить, что вам еще придется настраивать маршрутизацию на локальном шлюзе на входящие соединения.

Доброго времени суток.
К сожалению, я давно не практиковал программирование под ПК, но попробую описать в чем скорее всего ваша проблема.

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

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

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

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

Если не получится - пишите, будем разбираться дальше.

В каком режиме работают Tibbo модули - сервер или клиент?

Если в режиме сервера (это когда вы с компьютера обращаетесь к вашим устройствам за данными, т.к. компьютер провоцирует соединение), то проблем нет. Настраиваете виртуальные порты на соседних машинах и ведете опрос с них. Конвертеры будут обрабатывать запросы последовательно - сначала от первой машины, потом от второй и т.д., но как правило это очень быстрая обработка и можно считать ее параллельной (полностью распараллелить в данном режиме все равно не удастся).

Если модуль работает в режиме клиента (когда соединение провоцируется вашим устройством, а компьютер его принимает), то тут стандартными средствами не получится получить данные сразу на нескольких машинах. Связано это с тем, что в настройках тиббо модуля указывается параметр target ip - это адрес машины, на которую следует передавать данные, если они появились на последовательном интерфейсе. Этот параметр может нести лишь один адрес и соответственно данные смогут направляться только на один хост.
Тут решить проблему сложнее - либо качать исходники прошивки с сайта производителя и дорабатывать ее, либо реализовывать вариант с аппаратным или программным демультиплескором (когда данные с одного входа поступают на несколько выходов).

Добрый день!
[url=http://blog.tibbo.com/post/721175115][u]Вот ссылка[/u][/url], не информативная, но показывающая что Tibbo работали над этой проблемой и ускорили работу TiOS'а.
Как видно из ссылки ускоренные версии TiOS начинаются с 3.0
[url=http://tibbo.com/downloads/basic/firmware.html][u]На странице загрузок с сайта производителя[/u][/url] видим, что данная версия TiOS поддерживается всеми программируемыми модулями Tibbo, кроме устарешвего модуля EM202 (DS202) и его замены EM203 (DS203).

Соответственно взяв любой другой модуль - вы можете воспользоваться более быстрой операционкой.

Извините за долгий ответ.

По-поводу вашего вопроса.
Да, вы все правильно написали. Единственное примечание - это по поводу внешнего (белого) ip адерса. Дело в том, что этот адрес (в вашем примере 73.54.*.*) как правило динамический и выдается автоматически провайдером. Соответственно, при "пере-подключении" роутера к внешней сети, данный адрес может поменяться (т.е. был 73.54.101.11, стал 73.54.101.12) и удаленно узнать вы его уже не сможете.

Тут варианта два. Первое - это купить статический белый ip адрес у провайдера (если он предоставляет такую услугу) - в итоге за абонентскую плату вы получите свой собственный ip адрес, реально существующий в интернете, который меняться не будет!

Второй способ - если я не ошибаюсь, у dLink'a есть собственная служба DNS. Вы можете попробовать зарегистрироваться в ней. И обращаться будете тогда не по ip адресу, а по имени. Далее данное имя через службу dns d'link'a разрешиться в текущий Ip адрес и ваш запрос направится на роутер.

Более подробно о втором способе нужно посмотреть на сайте d'link. Но мне более перспективным кажется первый вариант.

[quote author=DiiMBass link=topic/7/715/1/#3730 date=17.01.2011 12:47]То есть к устройству можно удаленно обращаться через доменное имя, а не только через номерной ip?
Изначально планировалось заказывать у провайдера статический адрес, но в ветке форума d-link посоветовали, как вариант, воспользоваться службой dyndns.com[/quote]

Так, давайте чтобы не путаться введем терминологию. Под устройством будем понимать модули Tibbo, под маршрутизатором d-link.

Теперь собственно ответ: к устройству (т.е. к модулям тиббо) можно обращаться по имени для их настройки (правда не во всех моделях и при таком обращении вы будете попадать в веб-интерфейс управления), НО! не в вашем случае (т.к. у вас будет идти обращение через маршрутизатор). Также можно обращаться по имени и к маршрутизатору. То, что вам посоветовали на форуме - это видимо и есть второй вариант, про который я вам написал.
Т.е. следуя второму варианту схема соединения будет такой:
Вы провоцируете соединение по доменному имени. Ваш запрос обрабатывается службой dyndns, имя разрешается в текущий ip адрес вашего маршрутизатора и запрос передается на него. Маршрутизатор по созданному правилу (форвард портов) направляет запрос в локальную подсеть на конвертер тиббо. Тиббо в свою очередь преобразует полученные команды в RS232 протокол и передает управляемому устройству.

Теперь немного о плюсах и минусах. Используя такую схему, вам не придется платить абонентку за белый ip. Это, конечно, плюс. Ну и вам не нужно запоминать ip, запомнить придется лишь имя (все таки это проще чем запоминать кучу цифр :) ).

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

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

Если ваш софт работает только с com-портами, то вам придется ставить тиббовский драйвер виртуального com-порта. А драйвер работает только с ip-адресами. Т.е. в данном случае вариант будет только через статический белый ip...

В общем нужно исходить из конкретных условий. И взвешивать за и против. Мое мнение прежнее - лучше взять белый статический ip у провайдера.