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

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> - небольшое), но тоже ничего.

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

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

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

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

VO> не будут играть никакой роли.

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

WBR Eugene

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

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

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

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

Hello Gena.

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. :-)