Сеть сбора данных

Hello Gena,


GG>   На закате своей кар'еры в небольшой, но малоизвестной :-)
GG> фирме сподобился я изваять небольшую гамму приборов,

GG>     Вопрос такой у меня : есть ли у кого успешный опыт
GG> практического внедрения сабжа с примененем обычной
GG> винды на верхнем уровне (не реал-тайм ОС) и бинарной
GG> передачей данных (не ASCII ) ? Конечно, это не панацея,
GG> переход на RTU даст ускорение максимум процентов на 45
GG> только чистого времени передачи, но даже в ASCII это
GG> надо умудриться : связь с 2 десятками дивайсов на уровне
GG> запросов "КТО ТАМ?" устанавливать минут 18  Ж-(

  Слухи о не "релтаймовости" винды 9X сильно преувеличены
  (имею основания так заявить - как-то написал мерялку interrupt
  latency). W2K/XP немного помедленнее (в смысле среднее
  latency у них побольше, но зато и абсолютное максимальное
  - небольшое), но тоже ничего.
  
  В свое время мы разрабатывали протокол на RS-485 для
  сети ЭККА (до 30-ти на сегмент) - (как я сейчас понимаю -
  почти копия протокола USB :-) - в этом протоколе перерыв в 3
  байта тоже считается за окончание пакета. Так вот - много
  чего было перепробовано из опасений "глючный Windows не даст
  каналу нормально жить - и драйверы свои писались, и железо
  (ISA/PCI485 платы) делалось. В итоге все это заменено простой DLL,
  использующей Win32 API - CreateFile/WriteFile/ReadFile. (Ну, правда
  только для нескоростных решений - все-таки тайминги точно выдержать
  нельзя - они сделаны из Win32 с "большим запасом" - 1 мс вместо
  100 мкс, например).

  Родные виндовые порт-драйверы под классический 550-ый UART написаны
  довольно хорошо, умеют использовать FIFO (как для NT так и 9X), так что
  перерывов в потоке байтов почти не бывает, так что можно спокойно
  использовать Win32 API.

  ЗЫ: а протокол должен быть "дуракоустойчивым" - допускающим потери
  пакетов, с нумерацией пакетов, с автоповторами и автосинхронизацией
  начала/конца пакета, тогда редкие проявления нереалтаймовости ОС
  не будут играть никакой роли.

Hello,Vyacheslav !

VO>   Слухи о не "релтаймовости" винды 9X сильно преувеличены
VO>   (имею основания так заявить - как-то написал мерялку interrupt
VO>   latency). W2K/XP немного помедленнее (в смысле среднее
VO>   latency у них побольше, но зато и абсолютное максимальное
VO>   - небольшое), но тоже ничего.

<skip>

Да, похоже, перестраховался я. Но теперь на верхнем уровне уже не 9Х,
а ХР.


VO>   ЗЫ: а протокол должен быть "дуракоустойчивым" - допускающим потери
VO>   пакетов, с нумерацией пакетов, с автоповторами и
автосинхронизацией
VO>   начала/конца пакета,

Ну, автосинхронизация,imho, - это и есть пауза в 2-3 байта, а если
использовать для синхронизации какую-нибудь зарезервированную
последовательность, то она не должна встречаться в передаваемых
данных - и опять плавно перетекаем в текстовый режим, где один символ
отвечает только за начало, другой - за конец, а третья группа
товарищей - за передаваемые данные. Хотя, конечно, если отслеживать
и тайминги, и эту последовательность, то ее в непрерывном потоке
не воспринимать как синхропосылку - можно. Только сейчас,на ходу
сообразил. Эх, рано они меня выперли ! :-))
А автоповтор - этим и должна заниматься прога верхнего уровня, за это
ей и деньги плачены. Хотя идеальным решением был бы, imho, связной
контроллер вместо Фаствела-Адама, когда наверх он гнал бы инфу
дуплексом на 115200, а вниз - сообразно протоколу, совмещая во
времени запрос с ответом (для разных дивайсов, само собой).
Я не поклонник самопала, но если он обеспечивает лучшее качество -
почему бы и нет ?
И мне не кажется крамолой, если бы с дальними дивайсами он беседовал
на 2400, с ближними - на 19200. В текстовом режиме, разумеется.
Тогда на другой скорости дивайсы не уловили бы стартовый символ ':',
его поняли бы только дивайсы , настроенные на эту скорость. Хотя,
кажется, это уже из области бреда - нет гарантии, что какая-нибудь
комбинация бит не прозвучит на другой скорости как стартовая
0x3A (':') .
Идея бредовая - патентовать не буду, дарю всем на халяву :-)

VO> тогда редкие проявления нереалтаймовости ОС  <skip>
VO> не будут играть никакой роли.

Конечно. Тем боле что система МАСТЕР - остальные СЛЕЙВЫ,
если не ответил вызванный - повтори. Задача в общем-то не из
суперсложных, дивайсы с "зачатками интеллекта", сами ведут журналы
аварийных отключений и осциллограммы предаварийных событий, так что
реалтайм в чистом виде и на фиг не нужен, эти сведения дивайс отдаст
когда хошь, не обязательно сию секунду. Надо было бы бинарную
передачу - и пакеты короче, и код с иправлнением ошибок влимонить
проще - но это было бы отступление от букваря - шаг влево ...
 
Но посыпаю бошку этим самым только процентов на 15 - что на НОНЕШНЕМ
протоколе невозможно сделать устойчивую сеть... "Не верю" !
                        (К.С.Станиславский)

WBR Eugene

Привет, 18 февраля 2004 г., 12:01:00, ты писал(а):

GG> Конечно, это не панацея,
GG> переход на RTU даст ускорение максимум процентов на 45
GG> только чистого времени передачи, но даже в ASCII это
GG> надо умудриться : связь с 2 десятками дивайсов на уровне
GG> запросов "КТО ТАМ?" устанавливать минут 18  Ж-(

По-моему, не все в порядке в "королевстве датском" и следует сменить
программиста.

Всего хорошего.

Hello Gena.

18 Feb 04 19:20, you wrote to Vyacheslav Ovsiyenko:

 GG> если
 GG> использовать для синхронизации какую-нибудь зарезервированную
 GG> последовательность, то она не должна встречаться в передаваемых
 GG> данных

Это элементарно - посмотри, как сделано в протоколе SLIP или PPP.

Alexey

Hi Gena !

 Совсем недавно 18 Feb 04 12:01, Gena Gutnicky писал к  All:

 GG>     Вопрос такой у меня : есть ли у кого успешный опыт
 GG> практического внедрения сабжа с примененем обычной
 GG> винды на верхнем уровне (не реал-тайм ОС) и бинарной
 GG> передачей данных (не ASCII ) ?
Да, есть.
Hу, раньше свой протокол применяли. Там чужая каналообразующая аппаратура,
каналы 100 бод, много помех. Все работало.

Сейчас Modbus-RTU применяем. 4800-19200. RS-485.
Да нет никаких проблем.
Что с юниксами, что с виндами.
В-общем, любой бинарный протокол много где работает без проблем. Просто нужно
нормально продумать логику выхода из нештатных ситуаций (таймауты, контроль
корректности принимаемого пакета...)

 GG> переход на RTU даст ускорение максимум процентов на 45
 GG> только чистого времени передачи, но даже в ASCII это
 GG> надо умудриться : связь с 2 десятками дивайсов на уровне
 GG> запросов "КТО ТАМ?" устанавливать минут 18  Ж-(
Hу, тут вообще неясно. Скорость какая?



         WBRgrds
                   Ruslan

Hello, Ruslan !

RM> Сейчас Modbus-RTU применяем. 4800-19200. RS-485.
RM> Да нет никаких проблем.
RM> Что с юниксами, что с виндами.

Понял, сенкс.

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

Корректность - это штатно по RTU - CRC16.
 
RM> Hу, тут вообще неясно. Скорость какая?

Да бис его знает - это уже после моего отбытия. Шеф плевался и
топал ногами - и я его понимаю. Но анализа никакого нет.
Я предлагал сварганить мониторчик сети - выделить нотебуку,
прицепить ее к сети, и чтоб только принимал весь трафик,
фиксируя время поступления - и сразу было бы видно ,
кто "задумчивый" - комп или дивайсы, битый пакет ушел или
дивайс его плохо принял и т.д. А так - черный ящик. 1 бит
информации - "НЕ РАБОТАЕТ" .

WBR Eugene Gavruk ( ex G.G. :-)