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

Привет, всезнающий All !

На закате своей кар'еры в небольшой, но малоизвестной :-) фирме сподобился я изваять небольшую гамму приборов, имеющих интерфейс и выпускаемых до сих пор с общим тиражом уже в тысячах штук. Опыта интерфейсного было немного, мне положили плохонький перевод описания Modbus фирмы Шнайдер Электрик :"Вот тебе букварь, по нему и дуй". Шаг влево, шаг вправо - сами понимаете. Выбор был небольшой : Modbus ASCII mode и он же RTU mode. Опасаясь, что от Винды необходимой для второго варианта непрерывности пакета я не дождусь ( а там пауза в 2 байта воспринимается как конец сообщения) , я выбрал первый. Физический и-фейс RS485. Скорости вполне хватало для опроса в разумных временных пределах 2-3 десятков точек. Сделали, разложили по цеху с десяток дивайсов даже не на витой паре, а на самокрутках - работает. С тем я и отбыл восвояси по независящим причинам. Потом выясняется - не идут сети на об'ектах. Приз- ванный на спасение софтописатель верхнего уровня ( 5-й по счету, первым дело начинал на FoxPro юноша, до этого автоматизировавший на Клиппере под ДОСом исполкомы, морги и загсы) - изрек вердикт : протокол ни в дугу. И хоть теперь мне это до фонаря, обидно стало ( не за себя даже, за старика Шнайдера - его ведь протокол :-) . Из того, что я узнал, выяснялись любопытные вещи : идет, допустим, на 9600, а на 1200 через пень-колоду, короткие сообщения еще так-сяк, а длинные затыкали систему. Единственно разумное об'я - снение я вижу такое : ребята тупо нарезают времянку по таймеру, и не дождавшись не то что отклика, а даже конца своей посылки, догоняют ей в хвост новой. Дивайсы, ес-сно, молчат - они ничего понять не могут. Вопрос такой у меня : есть ли у кого успешный опыт практического внедрения сабжа с примененем обычной винды на верхнем уровне (не реал-тайм ОС) и бинарной передачей данных (не ASCII ) ? Конечно, это не панацея, переход на RTU даст ускорение максимум процентов на 45 только чистого времени передачи, но даже в ASCII это надо умудриться : связь с 2 десятками дивайсов на уровне запросов "КТО ТАМ?" устанавливать минут 18 Ж-(

WBR Eugene

Reply to
Gena Gutnicky
Loading thread data ...

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.

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

Reply to
Vyacheslav Ovsiyenko

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

Reply to
Gena Gutnicky

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

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

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

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

Reply to
Alexey Krasnov

Hello Gena.

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

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

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

Alexey

Reply to
Alexey Boyko

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

Reply to
Ruslan Mohniuc

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

Reply to
Eugene Gavruk

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.