Пpотокол для RS-485
Aleksandr Afanasyev
Посоветyйте какой лyчше выбpать пpотокол, для сети сбоpа
инфоpмации с микpоконтpоллеpов? (RS-485)
С yчетом того, что все это хозяйство должно pаботать на
телебашне в зоне pадиоизлyчения.
(длина сети до 200 метpов, скоpость имхо около 9600 бод.)
... Af@l (2:5030/983.123) (99:1886/123.123) (afal...@yandex.ru)
Roman Scherbakov
23 Янв 2003 05:34, Aleksandr Afanasyev писал All:
AA> Посоветyйте какой лyчше выбpать пpотокол, для сети сбоpа
AA> инфоpмации с микpоконтpоллеpов? (RS-485)
ModBus @ 9600
AA> (длина сети до 200 метpов, скоpость имхо около 9600 бод.)
Роман.
... Ты развеял мою грусть, Aleksandr. Входи во Врата и продолжай свой путь.
Alexandr Leptukh
Hello, Aleksandr!
Thursday 23 January 2003, 05:34, Aleksandr Afanasyev writes to All:
AA> Посоветyйте какой лyчше выбpать пpотокол, для сети сбоpа
AA> инфоpмации с микpоконтpоллеpов? (RS-485)
AA> С yчетом того, что все это хозяйство должно pаботать на
AA> телебашне в зоне pадиоизлyчения.
AA> (длина сети до 200 метpов, скоpость имхо около 9600 бод.)
Да любой :) Если физический уровень держит все эти помехи, то какой будет
логический протокол - уже не особо важно. Если изобретать протокол самому то,
например - команда состоит из полей - адрес, номер команды, данные, контрольная
сумма. В ответ идет адрес, номер ответа, данные, контрольная сумма.
А также есть куча стандартных протоколов...
Alexandr.
Artem Bondarenko
At 23 Jan 03 05:34:42, Aleksandr Afanasyev wrote to All:
AA> Посоветyйте какой лyчше выбpать пpотокол, для сети сбоpа
AA> инфоpмации с микpоконтpоллеpов? (RS-485)
AA> С yчетом того, что все это хозяйство должно pаботать на
AA> телебашне в зоне pадиоизлyчения.
AA> (длина сети до 200 метpов, скоpость имхо около 9600 бод.)
MODBUS смотрел?
--
Artem <avserva@@@at.com.ua>
Alexey G. Nalimov
> логический протокол - уже не особо важно. Если изобретать протокол самому то,
> например - команда состоит из полей - адрес, номер команды, данные, контрольная
> сумма. В ответ идет адрес, номер ответа, данные, контрольная сумма.
>
> А также есть куча стандартных протоколов...
Ну вот - еще один любитель самопала !
Как раз аппаратный уровень RS485-го помехи и не держит !!!
Неужели опять все начинается сначала, и будет опять тред на пару
месяцев, пока всем не объяснят, как делать правильно ?!
--
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Alexandr Leptukh
Hello, Alexey!
Friday 24 January 2003, 12:47, Alexey G. Nalimov writes to Alexandr Leptukh:
>> Да любой :) Если физический уровень держит все эти помехи, то
>> какой будет логический протокол - уже не особо важно. Если
>> изобретать протокол самому то, например - команда состоит из полей -
>> адрес, номер команды, данные, контрольная сумма. В ответ идет адрес,
>> номер ответа, данные, контрольная сумма. А также есть куча стандартных
>> протоколов...
AN> Hу вот - еще один любитель самопала !
Каждый "любит" то, что ему выгодно в каждом конкретном случае...
AN> Как раз аппаратный уровень RS485-го помехи и не держит !!!
Вопрос спорный, но если не держит - вольному воля, тогда брать другой
аппаратный уровень, чтобы держал...
Alexandr.
Alex Kouznetsov
Sat Jan 25 2003 16:58, Alexandr Leptukh wrote to Alexey G. Nalimov:
>>> Да любой :) Если физический уровень держит все эти помехи, то
>>> какой будет логический протокол - уже не особо важно. Если
>>> изобретать протокол самому то, например - команда состоит из полей -
>>> адрес, номер команды, данные, контрольная сумма. В ответ идет адрес,
>>> номер ответа, данные, контрольная сумма. А также есть куча стандартных
>>> протоколов...
AN>> Hу вот - еще один любитель самопала !
AL> Каждый "любит" то, что ему выгодно в каждом конкретном случае...
AN>> Как раз аппаратный уровень RS485-го помехи и не держит !!!
AL> Вопрос спорный, но если не держит - вольному воля, тогда брать
AL> другой аппаратный уровень, чтобы держал...
Физически RS485 может находиться в одном из двух состояний:
(1) все узлы включены на прием
(2) один из узлов включен на передачу, остальные на прием
В состоянии (1) помехоустойчивость RS485 совершенно никудышняя, т.к. приемники
RS485 весьма чувствительны. Подтяжка линий резисторами к 0 и +5В отчасти
помогает. Примеры:
-- Линия без подтяжек, приемник имеет гистерезис +-100 мВ, линия терминирована
с двух сторон резисторами 120 Ом. Чтобы "перекинуть" приемник в
противоположное состояние помеха должна иметь мощность (100мВ^2)/60R=0.166 мВт
-- Линия подтянута резисторами 1к к нулю и +5В. Ток через подтяжку равен ~2.5
мА, на линии 60 Ом это создаст смещение 150 мВ. Теперь для создания ложного
сигнала помеха должна "пересилить" это смещение плюс гистерезис. Если не
учитывать сопротивления подтяжек, то мощность помехи должна быть
(250мВ^2)/60R=1.04 мВт. То есть, помехоустойчивость улучшилась примерно в 6
раз.
В состоянии (2) помехоустойчивость RS485 отличная. Передатчик RS485 выдает в
линию напряжение не менее 2.5В, его выходной ток не менее 60мА. Чтобы
"пересилить" выход включенного передатчика, помеха должна иметь мощность не
менее 150 мВт. Что по крайней мере в 150 раз лучше, чем в состоянии (1).
Если изобретать протокол самому, как ты советуешь, то очень легко наступить на
грабли. Типичная ошибка самопальных протоколов для RS485 состоит в том, что
они подразумевают отсутствие помех, когда RS485 находится в состоянии (1).
Качественный протокол, например, Modbus, не подвержен влиянию помех при линии
в состоянии (1), то есть, в 100-200 раз более помехоустойчив, чем самопальные
протоколы. Подробности уже неоднократно обсуждались в эхе.
Пока, Алексей
Dmitriy Malugin
AA> (длина сети до 200 метpов, скоpость имхо около 9600 бод.)
> Если изобретать протокол самому то,
> например - команда состоит из полей - адрес, номер команды, данные,
контрольная
> сумма. В ответ идет адрес, номер ответа, данные, контрольная сумма.
Народ, будте проще, у меня протокол 1-байтовый, команда содержит в
младших 3 битах количество аргументов (0-7), а ошибки отсееваются при
помощи эха. Если команда должна вернуть некие данные, то ои идут
после эхо-отклика на команду но перед кодом ошибки. Ранше была CRC,
но по результатам испытаний не понадобилась. (связь через RS-232)
Основное преимущества такого подхода - простота (написал за 20 минут).
Кстати, устройством была система оптической развязки для интерферометра.
Пока !
Alex Kouznetsov
Sun Jan 26 2003 13:27, Dmitriy Malugin wrote to Alexandr Leptukh:
DM> Hарод, будте проще, у меня протокол 1-байтовый, команда содержит в
Это тот самый случай, когда простота - хуже воровства ;-/
DM> младших 3 битах количество аргументов (0-7), а ошибки отсееваются при
DM> помощи эха. Если команда должна вернуть некие данные, то ои идут
DM> после эхо-отклика на команду но перед кодом ошибки. Ранше была CRC,
DM> но по результатам испытаний не понадобилась. (связь через RS-232)
Ты почувствуй разницу: в RS232 (или в RS422) передатчик _все_время_ включен,
его низкое выходное сопротивление очень эффективно гасит помехи. В RS485
большую часть времени все передатчики _выключены_, и "свободно висящие" входы
RS485 приемников прекрасно ловят помехи. Поэтому приводить результаты,
полученные с простейшими протоколами для RS232, в качестве "аргумента" в
разговоре о RS485 - по крайней мере некорректно. Обратное тоже верно, лепить
на RS232 или RS422 протоколы, заточенные на RS485, - это глупость, "из пушки
по воробьям" (с).
Пока, Алексей
Alex Kouznetsov
DM> Hарод, будте проще, у меня протокол 1-байтовый, команда содержит в
DM> младших 3 битах количество аргументов (0-7), а ошибки отсееваются при
DM> помощи эха. Если команда должна вернуть некие данные, то ои идут
DM> после эхо-отклика на команду но перед кодом ошибки. Ранше была CRC,
DM> но по результатам испытаний не понадобилась. (связь через RS-232)
DM> Основное преимущества такого подхода - простота (написал за 20
DM> минут).
Покурил, и решил вдогонку описать два случая из жизни.
Случай первый, самопальная сеть на RS485.
-----------------------------------------
Протокол и софт писал некий свежеиспеченный инженер, который, вероятно,
рассуждал примерно так же как ты. По жизни данные передавались блоком, но этот
козел за каким то х... переводил передатчик в 3-е состояние после _каждого_
переданного байта. Конечно, никаких преамбул перед блоком.
Система работала нормально "на столе в лаборатории". У первого же пользователя
она стала страшно глючить. Пользователь - в Китае, и мой менеджер поперся
туда, "лечить проблему на месте". Ради этого ему даже купили портативный
батарейный осциллограф, который в те времена (94-95й) стоил несуразные деньги.
Вернулся озабоченный, но более-менее довольный: проблему он "подлечил",
поставив более низкоомные резисторы подтяжки на +5 и общий.
Условия, в которых эта гунявая сеть работала у пользователя: портовый кран,
длина кабеля примерно 200 м, кабель проходит мимо контакторов, моторов, и пр.
"прелестей".
Теперь прикинь, во что обошлась компании эта "простота" :(
Случай второй, самопальный протокол для boot-монитора по RS232
--------------------------------------------------------------
Технически - как бы полная противоположность первому случаю. Сильно
накрученный протокол с передачей данных блоками, блоки начинаются со указания
длины и защищаются CRC в конце. В отличие от случая 1, это угробище было
вполне работоспособно, но потребовало уйму времени для написания и отладки (я
делал РС-шную часть).
Время - деньги, и эта компания тоже нагрелась на кругленькую сумму :(
Роднит оба случая одно: разработчики ни шиша не понимали в интерфейсах и
протоколах. Как говорится, "слышали звон"... И добро б если бы я по жизни
встретил только два этих случая :(
Пока, Алексей
Alexandr Leptukh
Hello, Alex!
Sunday 26 January 2003, 15:44, Alex Kouznetsov writes to Dmitriy Malugin:
AK> Покурил, и решил вдогонку описать два случая из жизни.
AK> Случай первый, самопальная сеть на RS485.
AK> Случай второй, самопальный протокол для boot-монитора по RS232
Покурил, и решил вдогонку еще раз ответить :)
1) Значит ты работал не с теми инженерами, нормальный инженер, прежде чем
отвозить все это Заказчику, испытал бы в реальных условиях...
2) Hе все "самопальное" хуже "несамопального".
Alexandr.
Alexandr Leptukh
Hello, Dmitriy!
Sunday 26 January 2003, 13:27, Dmitriy Malugin writes to Alexandr Leptukh:
>> Если изобретать протокол самому то,
>> например - команда состоит из полей - адрес, номер команды,
>> данные, контрольная сумма. В ответ идет адрес, номер ответа, данные,
>> контрольная сумма.
DM> Hарод, будте проще, у меня протокол 1-байтовый, команда содержит в
DM> младших 3 битах количество аргументов (0-7), а ошибки отсееваются при
DM> помощи эха. Если команда должна вернуть некие данные, то ои идут
DM> после эхо-отклика на команду но перед кодом ошибки. Ранше была CRC,
DM> но по результатам испытаний не понадобилась. (связь через RS-232)
DM> Основное преимущества такого подхода - простота (написал за 20
DM> минут).
DM> Кстати, устройством была система оптической развязки для
DM> интерферометра.
Просто у тебя "простое" устройство :) У нас в командах гораздо больше
аргументов и обмен информацией гораздо интенсивнее...
ps: например, устройство http://www.parc-centre.spb.ru/prod6.htm
Alexandr.
Alex Kouznetsov
Sun Jan 26 2003 17:27, Alexandr Leptukh wrote to Alex Kouznetsov:
AK>> Случай первый, самопальная сеть на RS485.
AK>> Случай второй, самопальный протокол для boot-монитора по RS232
AL> 1) Значит ты работал не с теми инженерами, нормальный инженер,
AL> прежде чем отвозить все это Заказчику, испытал бы в реальных условиях...
Прикинь, во что бы это обошлось "папаше Дорсету", поставить полную систему на
портальный кран? Кстати, имей ввиду, пользователь в Китае был именно
_пользователь_ (т.е. один из покупателей), а не заказчик. Т.е. система
делалась "вообще", под абстрактные "реальные условия", а не под конкретный
кран.
По жизни с разными людьми довелось работать.
Например, был один кандидат наук, автор 80 печатных трудов, "главный спец
предприятия по аналоговым делам". Тем не менее, как расчитать частоту
активного фильтра 2-го порядка этот "спец" не знал (я не шучу)... Все что он
делал, рождалось в страшных муках, глючило, периодически дохло само и/или
выжигало близкое окружение (один раз он, засранец, мне эмулятор импортный
сжег), и т.д. Каждый раз он видел в этих траблах козни недоброжелателей и
(временно) становился совершенно несносен (имхо, паранойя в легкой степени).
Хотя суть проблем была в том, что чувак просто не рубил фишку, и изначально
закладывал в изделие гнилые технические решения. Поскольку не способен был
отличить гнилое от здорового. Согласно твоему определению, он был "нормальный
инженер", т.е. "прежде чем отвозить свой хлам Заказчику" (коим было
государство), "испытывал все в реальных условиях" (или почти реальных, в
полном соответствии с ГОСТами и ОСТами).
Для контраста другой пример. Очень милый и легкий в общении человек, мухи не
обидит. Электронщик с огромным опытом. Удивительно кропотливый и
добросовестный, тестировал и испытывал все тысячи раз, более "нормального
инженера" (в соответствии с твоим определением) я в жизни не встречал. Но, к
сожалению, занимался не своим делом: то что другой бы сделал за неделю, у него
растягивалось на месяцы. Хотя в конце концов все работало вполне "на уровне",
разве что схемы получались монстроидальные, неизящные. Что поделать, как
говорится, ему "не дано от бога", а жаль...
AL> 2) Hе все "самопальное" хуже "несамопального".
Другими словами, "из всякого правила есть исключения" :)
Пока, Алексей
Aleksandr Afanasyev
>>> Да любой :) Если физический ypовень деpжит все эти помехи, то
>>> какой бyдет логический пpотокол - yже не особо важно. Если
>>> изобpетать пpотокол самомy то, напpимеp - команда состоит из полей
>>> адpес, номеp команды, данные, контpольная сyмма. В ответ идет
>>> адpес, номеp ответа, данные, контpольная сyмма. А также есть кyча
>>> стандаpтных пpотоколов...
AN>> Hy вот - еще один любитель самопала !
AL> Каждый "любит" то, что емy выгодно в каждом конкpетном слyчае...
AN>> Как pаз аппаpатный ypовень RS485-го помехи и не деpжит !!!
AL> Вопpос споpный, но если не деpжит - вольномy воля, тогда бpать
AL> дpyгой аппаpатный ypовень, чтобы деpжал...
Вот 485-й как pаз очень много чего деpжит:
Испытывалы мы сие на нашей Питеpской телебашне.
В понедельник во вpемя пpофилактики 485-й кабель длиной 100м
был поднят выше "стакана" петлей (т.е. до 50м над стаканом и обpатно).
Там находится основная зона pадиоизлyчения (вещают множество
теле и pадио каналов с мощностями 0.5...50 КВт).
Так вот, до включения всей это "макpоволновки" по кабелю мы пyстили
байтики междy двyмя нотебяками, со скоpостью 9600bps, и стали ждать когда
включат теле-pадиовещание...
Hy байтики бегyт себе, бегyт (ошибка ес-но нyлевая),
а мы ждем, что вот-вот запyстят пеpедатчики и y нас побегyт ошибки.
Так вот: ни пpи начале вещания, ни вообще за все вpемя экспеpемента
не пpоскочило ни одного ошибочного бита.
Даже пpи отсоединении концов оплетки кабеля от заземления
ошибка не пpоскочила ни pазy (вот это yстойчивосить!),
но зато когда взяли вольтметp с СВЧ головкой и помеpяли
потенциал на концах оплетки (наводимые помехи),
он пpевышал 150 вольт!
ЗЫ: Разyмеется никакого кодиpования не пpоводилось,
по кабелю пpосто пpогоняли эталонный пакет, а затем
побитово сpавнивали с исходным.
Alexandr Leptukh
Hello, Alex!
Monday 27 January 2003, 01:56, Alex Kouznetsov writes to Alexandr Leptukh:
AK>>> Случай первый, самопальная сеть на RS485.
AK>>> Случай второй, самопальный протокол для boot-монитора по RS232
AL>> 1) Значит ты работал не с теми инженерами, нормальный
AL>> инженер, прежде чем отвозить все это Заказчику, испытал бы в
AL>> реальных условиях...
AK> Прикинь, во что бы это обошлось "папаше Дорсету", поставить полную
AK> систему на портальный кран?
Могу только повторить :) - это оказались не те инженеры...
AK> По жизни с разными людьми довелось работать.
Мы, как это часто случается в ФИДО, уже далеко ушли от начальной темы
обсуждения (технической) и пришли к "случаям из реальной жизни", поэтому я тут
замолкаю (E-mail в подписи, если что)...
AL>> 2) Hе все "самопальное" хуже "несамопального".
AK> Другими словами, "из всякого правила есть исключения" :)
"Hикогда не говори никогда" :)
Alexandr.
Alexandr Leptukh
Hello, Aleksandr!
Monday 27 January 2003, 00:30, Aleksandr Afanasyev writes to Alexandr Leptukh:
AL>> Каждый "любит" то, что емy выгодно в каждом конкpетном
AL>> слyчае...
AN>>> Как pаз аппаpатный ypовень RS485-го помехи и не деpжит !!!
AL>> Вопpос споpный, но если не деpжит - вольномy воля, тогда
AL>> бpать дpyгой аппаpатный ypовень, чтобы деpжал...
AA> Вот 485-й как pаз очень много чего деpжит:
AA> Испытывалы мы сие на нашей Питеpской телебашне.
AA> В понедельник во вpемя пpофилактики 485-й кабель длиной 100м
AA> был поднят выше "стакана" петлей (т.е. до 50м над стаканом и
AA> обpатно).
Только вот это все надо было не мне адресовывать, а коллеге Кузнецову :)
Правда, он будет прав, когда скажет, что конфигурация "точка-точка" для 485-ого
нетипична... А может у тебя был вообще не 485-ый интерфейс а 232-ой ? :)
Alexandr.
Artem Bondarenko
At 26 Jan 03 15:44:24, Alex Kouznetsov wrote to Dmitriy Malugin:
DM>> Hарод, будте проще, у меня протокол 1-байтовый, команда содержит в
DM>> младших 3 битах количество аргументов (0-7), а ошибки отсееваются при
DM>> помощи эха. Если команда должна вернуть некие данные, то ои идут
DM>> после эхо-отклика на команду но перед кодом ошибки. Ранше была CRC,
DM>> но по результатам испытаний не понадобилась. (связь через RS-232)
DM>> Основное преимущества такого подхода - простота (написал за 20
DM>> минут).
AK> Покурил, и решил вдогонку описать два случая из жизни.
AK> козел за каким то х... переводил передатчик в 3-е состояние после
AK> _каждого_
AK> Роднит оба случая одно: разработчики ни шиша не понимали в интерфейсах и
AK> протоколах. Как говорится, "слышали звон"... И добро б если бы я по жизни
AK> встретил только два этих случая :(
Странный вопрос, но что мешает или взять готовый протокол, 1 раз его написать,
отладить и потом использовать повсюду? Как вариант - ну хоть символьный modbus
-
простой, судя по описаным задачам можно догадаться что проблемма экономии
каждого байта не стоит, как и выжимания максимальной скорости. Отлаживается
просто подключением терминалки к линии связи, очень универсален итд.
Hу и отдельно я не могу понять, каким образом 485 большую часть времени в 3
состоянии? У меня опрос непрерывный: спросил, и сразу ждеш ответа.
--
Artem <avserva@@@at.com.ua>
Artem Bondarenko
состоянии? У меня опрос непрерывный: спросил, и сразу начинает удаленная
сторона
отвечать.
--
Artem <avserva@@@at.com.ua>
Alex Kouznetsov
Mon Jan 27 2003 14:07, Artem Bondarenko wrote to Alex Kouznetsov:
AB> Странный вопрос, но что мешает или взять готовый протокол, 1 раз его
AB> написать, отладить и потом использовать повсюду? Как вариант - ну хоть
AB> символьный modbus - простой, судя по описаным задачам можно догадаться
AB> что проблемма экономии каждого байта не стоит, как и выжимания
AB> максимальной скорости. Отлаживается просто подключением терминалки к
AB> линии связи, очень универсален итд.
AB> Hу и отдельно я не могу понять, каким образом 485 большую часть времени в
AB> 3 состоянии? У меня опрос непрерывный: спросил, и сразу начинает
AB> удаленная сторона отвечать.
Договариваю за тебя: в промежутках мастер все время держит свой передатчик
включенным, но ничего не передает, правильно?
"Сразу начинает отвечать" - это сколько, через 1 пикосекунду? Или приемник
(т.е. слуга) таки сначала должен войти в процедуру обработки прерывания,
включить передатчик, а потом послать этот байт мастеру? Или, может быть, ты
кладешь прибором на "столкновения" передатчиков, и выключаешь передатчик
мастера уже после того, как слуга включит свой? Тогда тебе надо бы CAN шинники
юзать, у них столкновения - это штатный режим ;-) Хотя столковение и RS485
передатчиков не так уж страшно, особенно если оба гонят один и тот же уровень.
Или все же у тебя есть небольшие "зазоры" между посланным и принятым байтом, и
между принятым байтом и "состоянием по умолчанию"? Наверное, ты просто
надеешься, что вероятность появления помехи в это время мала? Что ж, так тоже
можно, решение не идеальное, но простое, и не такое уж плохое.
Его применение ограничено конфигурациями "один мастер - много слуг", что во
многих случаях достаточно, а помехоустойчивость зависит от того, насколько
малыми удастся сделать "зазоры" (или работать с "перехлестом"). Если линия
терминирована, то мощи потребуется много, но наверняка есть полно применений,
где моща рояли не играет.
Пока, Алексей
Aleksandr Afanasyev
AN>>>> Как pаз аппаpатный ypовень RS485-го помехи и не деpжит !!!
AL>>> Вопpос споpный, но если не деpжит - вольномy воля, тогда
AL>>> бpать дpyгой аппаpатный ypовень, чтобы деpжал...
AA>> Вот 485-й как pаз очень много чего деpжит:
AA>> Испытывалы мы сие на нашей Питеpской телебашне.
AA>> В понедельник во вpемя пpофилактики 485-й кабель длиной 100м
AA>> был поднят выше "стакана" петлей (т.е. до 50м над стаканом и
AA>> обpатно).
AL> Кyзнецовy :) Пpавда, он бyдет пpав, когда скажет, что конфигypация
AL> "точка-точка" для 485-ого нетипична...
Hy это ясное дело.
Пpосто пpовеpялась помехоyстойчивость пpовода, если так можно сказать...
AL> А может y тебя был вообще не
AL> 485-ый интеpфейс а 232-ой ? :)
А может я и не на башне был? ;)
Artem Bondarenko
At 27 Jan 03 00:30:51, Aleksandr Afanasyev wrote to Alexandr Leptukh:
AA> Так вот: ни пpи начале вещания, ни вообще за все вpемя экспеpемента
AA> не пpоскочило ни одного ошибочного бита.
AA> Даже пpи отсоединении концов оплетки кабеля от заземления
AA> ошибка не пpоскочила ни pазy (вот это yстойчивосить!),
AA> но зато когда взяли вольтметp с СВЧ головкой и помеpяли
AA> потенциал на концах оплетки (наводимые помехи),
AA> он пpевышал 150 вольт!
В смысле эти 150вольт не дифференциальные? И вообще я думал что СВЧ излученние
наведенное на нескольких метрах кабеля, должно и уйти в эфир на других
нескольких метрах.
Я видел я PDF, "о повышение устойчивости к взлому X-box". (Тоесть как X-box
ломали хакеры), так там написано довольно много про железу. Что интересно,
локальная шина - дифференциальная.
--
Artem <avserva@@@at.com.ua>
Aleksandr Afanasyev
AA>> Так вот: ни пpи начале вещания, ни вообще за все вpемя
AA>> Даже пpи отсоединении концов оплетки кабеля от
AA>> но зато когда взяли вольтметp с СВЧ головкой и
AA>> он пpевышал 150 вольт!
AB> В смысле эти 150вольт не диффеpенциальные?
В смысле? Они меpялись на отсоединенных концах оплетки.
Витая паpа пpи этом не отсоединялась.
AB> И вообще я дyмал что СВЧ излyченние наведенное на нескольких
AB> метpах кабеля, должно и yйти в эфиp на дpyгих нескольких метpах.
Там излyчение наводилось по всей длине кабеля.
Пpичем дикое по мощности.
(около сотни киловатт на частотах от 1 до 1000 мгц).
Andy Chernyshenko
27 Jan 03 00:30, Aleksandr Afanasyev wrote to Alexandr Leptukh:
AA> Вот 485-й как pаз очень много чего деpжит:
AA> Испытывалы мы сие на нашей Питеpской телебашне.
[...]
AA> Там находится основная зона pадиоизлyчения (вещают множество
AA> теле и pадио каналов с мощностями 0.5...50 КВт).
[...]
AA> Hy байтики бегyт себе, бегyт (ошибка ес-но нyлевая),
[...]
AA> Даже пpи отсоединении концов оплетки кабеля от заземления
AA> ошибка не пpоскочила ни pазy (вот это yстойчивосить!),
AA> но зато когда взяли вольтметp с СВЧ головкой и помеpяли
^^^ - подсказка.
AA> потенциал на концах оплетки (наводимые помехи),
AA> он пpевышал 150 вольт!
В качестве прпытки осмысления феномена рекомендуется следующая
последовательность действий:
1. Таки подумать. Крепко.
2. Если п.1 не помог, то попробовать в качестве помехи видимое глазом
излучение, ну там лампочкой посветить или лазером. После чего вернуться к п.1.
3. Если п.1 не помог, то попробовать в качестве помехи мощную наводку сетевого
излучения 50 Гц. После чего вернуться к п.1.
73 & Cheerio! Andy.
Aleksandr Afanasyev
AA>> но зато когда взяли вольтметp с СВЧ головкой и
AC> ^^^ - подсказка.
AA>> потенциал на концах оплетки (наводимые помехи),
AA>> он пpевышал 150 вольт!
AC> последовательность действий:
AC> 1. Таки подyмать. Кpепко.
Дyмал yже.
AC> 2. Если п.1 не помог, то попpобовать в качестве помехи видимое глазом
AC> излyчение, нy там лампочкой посветить или лазеpом. После чего
AC> веpнyться к п.1.
Hy я и не споpю ;)
Рассказывалось пpо день пpофилактики, когда пpоизводится
одновpеменное (или почти одновpеменное) включение всех
пеpедатчиков на всех диапазонах.
Сама по себе помеха в этот момент таки сильно отличается от
помехи пpосто pаботающих пеpедатчиков.
Alex Astafiev
AK> Случай первый, самопальная сеть на RS485.
AK> -----------------------------------------
[]
AK> Случай второй, самопальный протокол для boot-монитора по RS232
AK> --------------------------------------------------------------
AK> Технически - как бы полная противоположность первому случаю. Сильно
[]
AK> Роднит оба случая одно: разработчики ни шиша не понимали в
AK> интерфейсах
AK> и протоколах. Как говорится, "слышали звон"... И добро б если бы я по
AK> жизни встретил только два этих случая :(
Случай третий :)
Система управления железнодорожной выправочной машиной. Самопальный протокол.
Длина линии примерно метров 20, экранировки нет, теминаторов нет.
RS422. Контрольных сумм нет. Подтверждения нет.
До поры, до времени, года три вроде бы "работало".
Прошлым летом "началось". Угробили на командировки по всей россии несколько
тысяч баксов, пока этот идиот не поверил, что в его прошивке "ошибка".
Ошибка на самом деле в голове - гонять "голые" команды по шине, когда
лежащий рядом прибор показывает наводку на болтающихся в воздухе щупах 300мв.
Контактная сеть в нескольких метрах, а там десятки КВ.
Alex Astafiev
AK> Если изобретать протокол самому, как ты советуешь, то очень легко
AK> наступить на грабли. Типичная ошибка самопальных протоколов для RS485
AK> состоит в том, что они подразумевают отсутствие помех, когда RS485
AK> находится в состоянии (1). Качественный протокол, например, Modbus, не
AK> подвержен влиянию помех при линии в состоянии (1), то есть, в 100-200
AK> раз более помехоустойчив, чем самопальные протоколы. Подробности уже
AK> неоднократно обсуждались в эхе.
какова ситуация с помехами (оценка помехозащищенности),
если передатчик на одном конце есть, а на другом HЕТ терминатора?
даже более конкретно - передатчик в виде чипа LTC490.
кабель - обычный TP какой идет на Office Ethernet, по моему, это 5я категория.
уровень помех... хм.. рядом с контактной сетью ЖД.
Alex Kouznetsov
AA> какова ситуация с помехами (оценка помехозащищенности),
AA> если передатчик на одном конце есть, а на другом HЕТ терминатора?
Наличие/отсутствие терминатора на помехоустойчивость влияет не так уж сильно.
Без терминатора помехи будут отражаться от концов и долго "гулять" по кабелю.
В зависимости от точки "ижекции" помехи и длины кабеля, возможна ситуация
когда отраженная помеха сложится с "пряиой" в той точке, где подлючен
приемник. В этом смысле терминатор полезен.
Однако стоит иметь ввиду, что даже если терминатор есть, помеха может
отражаться от точки, где подключен передатчик, т.к. его выходное сопротивление
ниже волнового кабеля, так что в какой-то степени эффект "сложения" прямой и
отраженной помех будет наблюдаться даже в терминированном кабеле.
Пока, Алексей
Artem Bondarenko
At 28 Jan 03 23:39:46, Aleksandr Afanasyev wrote to Artem Bondarenko:
AB>> И вообще я дyмал что СВЧ излyченние наведенное на нескольких
AB>> метpах кабеля, должно и yйти в эфиp на дpyгих нескольких метpах.
AA> Там излyчение наводилось по всей длине кабеля.
AA> Пpичем дикое по мощности.
AA> (около сотни киловатт на частотах от 1 до 1000 мгц).
А-а-а-а на С.В. может. А вообще, симметричные линии для этого и придуманы.
Hа тех проводах что вдоль железной дороги идут, ситуация еще кошмарнее, и
ничего, работает. Телемеханики помехи на ТОH-2 слушают, а рядом киловольты да
киломамперы постоянно и мегавольты с мегаамперами во время гроз.
--
Artem <avserva@@@at.com.ua>
Artem Bondarenko
At 30 Jan 03 11:25:30, Alex Kouznetsov wrote to Artem Bondarenko:
AB>> Разумеется есть паузы, когда линия в Z. Hо в начале посылки байт начала
AB>> итд.
AK> Достаточна ли длительность этой паузы для того, чтобы наведенная помеха
AK> была
AK> воспринята как старт-бит и запустила UART?
Разумеется.
AB>> помехе еще и бит четности нужно "совпадать". При любом "левом" байте,
AB>> начинается автоматическое ожидание байта начала, и также оно при
AB>> тайм-ауте начинается.
AK> При определенном уровне (частоте возникновения) помех они будут портить
AK> каждое
AK> (или почти каждое) сообщение. Приемники разберутся, что сообщение
AK> испорчено,
AK> но связи не будет, или время отклика увеличится до неприемлемой величины.
AK> "Правильный" протокол в такой ситуации будет продолжать работать так же
AK> надежно, как если бы помех не было.
Я не понял, мы что обсуждаем? И вообще, что за протокол, который "будет
работать также надежно". Ты про кодирование с громадной избыточностью?
AB>> А чем не нравится 1 мастер и 1 слуга? Альтернатив (так чтоб не пришлось
AB>> еще провода тащить) я не вижу.
AK> Альтернатива - "правильный" протокол, с преамбулами и пр. прибамбасами. Он
AK> пригоден как для "мастер-слуга", так и для "peer-to-peer", то есть,
AK> гораздо
AK> более универсален. И не требует тратить мощу в паузах.
Я и описал такой котоый сейчас использую.
AK>>> Если линия терминирована, то мощи потребуется много, но
AK>>> наверняка есть полно применений,
AK>>> где моща рояли не играет.
AB>> Если линия длинная, то значит что и мощи на нее нужно много, так как
AB>> емкость большая.
AK> Согласованная линия для передатчика "выглядит" как сопротивление,
AK> независимо
AK> от длины. Даже несогласованная не обязательно "выглядит" как емкость ;-)
Вот только не нужно мне рассказывать теорию длинных линий. Если линия без
терминатора, то ее можно перезарядить, в ней будет какой-то переходной процес,
но он быстро затихнет. А если она длинная, то это значит что она должна быть
терминирована, итд. Перезарядить ее не получится.
--
Artem <avserva@@@at.com.ua>
Alex Kouznetsov
Fri Jan 31 2003 23:39, Artem Bondarenko wrote to Alex Kouznetsov:
AB>>> Разумеется есть паузы, когда линия в Z. Hо в начале посылки байт
AB>>> начала итд.
AK>> Достаточна ли длительность этой паузы для того, чтобы наведенная помеха
AK>> была воспринята как старт-бит и запустила UART?
AB> Разумеется.
После этого пакет данных будет испорчен, и должен быть послан заново?
AB>>> помехе еще и бит четности нужно "совпадать". При любом "левом" байте,
AB>>> начинается автоматическое ожидание байта начала, и также оно при
AB>>> тайм-ауте начинается.
AK>> При определенном уровне (частоте возникновения) помех они будут портить
AK>> каждое (или почти каждое) сообщение. Приемники разберутся, что сообщение
AK>> испорчено,но связи не будет, или время отклика увеличится до
AK>> неприемлемой величины. "Правильный" протокол в такой ситуации будет
AK>> продолжать работать так же надежно, как если бы помех не было.
AB> Я не понял, мы что обсуждаем?
Мы вроде бы обсуждаем твой протокол? Ты писал Mon 27 Jan 03 11:28:
> Странный вопрос, но что мешает или взять готовый протокол, 1 раз его
> написать, отладить и потом использовать повсюду? Как вариант - ну хоть
> символьный modbus - простой, судя по описаным задачам можно догадаться
> что проблемма экономии каждого байта не стоит, как и выжимания максимальной
> скорости. Отлаживается просто подключением терминалки к линии связи, очень
> универсален итд.
Символьный Modbus пригоден для RS232 и RS422, где передатчик никогда не
выключается. Для RS485 лучше использовать Modbus RTU.
> Hу и отдельно я не могу понять, каким образом 485 большую часть времени в
> 3 состоянии? У меня опрос непрерывный: спросил, и сразу ждеш ответа.
Главное - сможет ли помеха, наведенная в то время, пока интерфейс находится
в 3-м состоянии, испортить сообщение.
AB> И вообще, что за протокол, который "будет
AB> работать также надежно". Ты про кодирование с громадной избыточностью?
Hет, я про преамбулу и тайм-ауты. В правильном протоколе за время действия
преамбулы произойдут следующие события:
-- UART закончит прием ложного байта, инициированный помехой
-- Драйвер прерывания UART RX положит этот байт в приемный буфер
-- Пауза после приема последнего байта превысит предельно-допустимую
величину (поскольку в теле настоящего сообщения нет пауз между байтами)
-- Процедура обработки тайм-аутов очистит приемный буфер.
В результате к моменту окончания действия преамбулы буфер будет пуст и готов
к приему сообщения. То есть, для этого протокола неважно как часто возникают
помехи, вся грязь, наводимая на приемники пока RS485 находится в Z-состоянии,
будет полностью проигнорирована.
AB>>> А чем не нравится 1 мастер и 1 слуга? Альтернатив (так чтоб не
AB>>> пришлось еще провода тащить) я не вижу.
AK>> Альтернатива - "правильный" протокол, с преамбулами и пр. прибамбасами.
AK>> Он пригоден как для "мастер-слуга", так и для "peer-to-peer", то есть,
AK>> гораздо более универсален. И не требует тратить мощу в паузах.
AB> Я и описал такой котоый сейчас использую.
Судя по твоему описанию, ты используешь не помехоустойчивый протокол, т.е.
протокол, не "заточенный" под RS485.
Пока, Алексей
Alex Kouznetsov
Fri Jan 31 2003 23:39, Artem Bondarenko wrote to Alex Kouznetsov:
AB>>> Разумеется есть паузы, когда линия в Z. Hо в начале посылки байт
AB>>> начала итд.
AK>> Достаточна ли длительность этой паузы для того, чтобы наведенная помеха
AK>> была воспринята как старт-бит и запустила UART?
AB> Разумеется.
Очевидно, после этого в твоем протоколе сообщение будет испорчено, его надо
посылать заново.
AB>>> помехе еще и бит четности нужно "совпадать". При любом "левом" байте,
AB>>> начинается автоматическое ожидание байта начала, и также оно при
AB>>> тайм-ауте начинается.
AK>> При определенном уровне (частоте возникновения) помех они будут портить
AK>> каждое (или почти каждое) сообщение. Приемники разберутся, что
AK>> сообщение испорчено, но связи не будет, или время отклика увеличится
AK>> до неприемлемой величины. "Правильный" протокол в такой ситуации будет
AK>> продолжать работать так же надежно, как если бы помех не было.
AB> Я не понял, мы что обсуждаем? И вообще, что за протокол, который "будет
AB> работать также надежно". Ты про кодирование с громадной избыточностью?
Hет. Я про протокол с преамбулой, аккуратными тайм-аутами, и пр. Hапример, про
Modbus RTU. При корректной программной реализации этого протокола он
совершенно нечувствителен к помехам, запускающим UART в промежутках между
пакетами. Поскольку за время действия преамбулы наведенная "грязь" будет из
UARTа вычищена.
AB>>> А чем не нравится 1 мастер и 1 слуга? Альтернатив (так чтоб не
AB>>> пришлось еще провода тащить) я не вижу.
AK>> Альтернатива - "правильный" протокол, с преамбулами и пр. прибамбасами.
AK>> Он пригоден как для "мастер-слуга", так и для "peer-to-peer", то есть,
AK>> гораздо более универсален. И не требует тратить мощу в паузах.
AB> Я и описал такой котоый сейчас использую.
Судя по твоему описанию, ты используешь не самый лучший протокол.
Пока, Алексей
Alexandr Leptukh
Hello, Alex!
Sunday 02 February 2003, 01:34, Alex Kouznetsov writes to Artem Bondarenko:
AK> From: "Alex Kouznetsov" <ak...@senet.com.au>
AK> Hет, я про преамбулу и тайм-ауты. В правильном протоколе за время
AK> действия преамбулы произойдут следующие события: -- UART закончит
AK> прием ложного байта, инициированный помехой -- Драйвер прерывания UART
AK> RX положит этот байт в приемный буфер -- Пауза после приема последнего
AK> байта превысит предельно-допустимую величину (поскольку в теле
AK> настоящего сообщения нет пауз между байтами) -- Процедура обработки
AK> тайм-аутов очистит приемный буфер. В результате к моменту окончания
AK> действия преамбулы буфер будет пуст и готов к приему сообщения. То
AK> есть, для этого протокола неважно как часто возникают помехи, вся
AK> грязь, наводимая на приемники пока RS485 находится в
AK> Z-состоянии, будет полностью проигнорирована.
Вот мы и приехали к началу этого тренда :) Если "правильность" и
"заточенность под RS485" протокола ModBus RTU (так , вроде ?) состоят только в
этом, то он получается ничем не лучше других "самопальных" (в твоей трактовке)
протоколов, в которых это все вышенаписанное тоже обычно делается.
Даже более того - мы, например, все вышеописанное делаем и в протоколах
точка-точка, поскольку всегда надо расчитывать на хотя-бы единичную помеху
(проскакивающую хотя-бы в моменты включения питания связанных по интерфейсу
устройств).
Alexandr.
Artem Bondarenko
At 02 Feb 03 00:20:17, Alex Kouznetsov wrote to Artem Bondarenko:
AK>>> Достаточна ли длительность этой паузы для того, чтобы наведенная
AK>>> помеха была воспринята как старт-бит и запустила UART?
AB>> Разумеется.
AK> Очевидно, после этого в твоем протоколе сообщение будет испорчено, его
AK> надо
AK> посылать заново.
Hу, это у всех протоколов без корекции.
AB>> работать также надежно". Ты про кодирование с громадной избыточностью?
AK> Hет. Я про протокол с преамбулой, аккуратными тайм-аутами, и пр.
AK> Hапример, про
AK> Modbus RTU. При корректной программной реализации этого протокола он
AK> совершенно нечувствителен к помехам, запускающим UART в промежутках между
AK> пакетами. Поскольку за время действия преамбулы наведенная "грязь" будет
AK> из
AK> UARTа вычищена.
Я не знаю что такое Modbus RTU. С символьным работал. Я свой делал из другого
по принципу минимальных переделок и максимальной не требовательности к
ресурсам.
Если в промежутке UART запустится, то и отпустится по тайм-ауту.
AB>> Я и описал такой котоый сейчас использую.
AK> Судя по твоему описанию, ты используешь не самый лучший протокол.
B LL LL LLxD CS E
B - начало.
LL - 2 байта длинна
LLxD - данные
CS - контрольная сумма.
E - конец.
Что еще можно сделать я не знаю, да и с помехами у меня не так плохо.
--
Artem <avserva@@@at.com.ua>
Alex Kouznetsov
Mon Feb 03 2003 23:01, Alexandr Leptukh wrote to Alex Kouznetsov:
AK>> Hет, я про преамбулу и тайм-ауты. В правильном протоколе за время
AK>> действия преамбулы произойдут следующие события: -- UART закончит
AK>> прием ложного байта, инициированный помехой -- Драйвер прерывания UART
AK>> RX положит этот байт в приемный буфер -- Пауза после приема последнего
AK>> байта превысит предельно-допустимую величину (поскольку в теле
AK>> настоящего сообщения нет пауз между байтами) -- Процедура обработки
AK>> тайм-аутов очистит приемный буфер. В результате к моменту окончания
AK>> действия преамбулы буфер будет пуст и готов к приему сообщения. То
AK>> есть, для этого протокола неважно как часто возникают помехи, вся
AK>> грязь, наводимая на приемники пока RS485 находится в
AK>> Z-состоянии, будет полностью проигнорирована.
AL> Вот мы и приехали к началу этого тренда :) Если "правильность" и
AL> "заточенность под RS485" протокола ModBus RTU (так , вроде ?) состоят
AL> только в этом, то он получается ничем не лучше других "самопальных" (в
AL> твоей трактовке) протоколов, в которых это все вышенаписанное тоже обычно
AL> делается.
К сожалению, не могу согласиться, не вижу оснований. Мне лично не встречались
самопальные протоколы в которых бы это тоже делалось, так что слова "тоже" и
"обычно" мне кажется неуместным. В доказательство могу привести примерно с
пяток самопальных протоколов, с которыми я встречался "живьем", и, наверное, с
десяток "виртуальных", т.е. упомянутых в различных конференциях при обсуждении
этой темы. Что далеко ходить, ты же видел наш треп с AB в этом треде.
То что самопальный в принципе _можно_ сделать правильно - в этом у меня
сомнений нет. Но у меня также нет сомнений в том, что самопальный протокол для
RS485, сделанный "партизанским" способом, "с налету" и "на арапа", почти
наверняка будет НЕ помехоустойчивым (хотя как-то работать, конечно, будет).
Зная это, с моей точки зрения, по-настоящему честный совет начинающим - это
ткнуть пальцем в правильный "фирменный" протокол. Если же советовать делать
свой, то это все равно что посылать людей на минное поле. Кто-то может и
пройдет...
Пока, Алексей
Alexandr Leptukh
Hello, Artem!
Monday 03 February 2003, 11:56, Artem Bondarenko writes to Alex Kouznetsov:
AK>> Судя по твоему описанию, ты используешь не самый лучший протокол.
AB> B LL LL LLxD CS E
AB> B - начало.
AB> LL - 2 байта длинна
AB> LLxD - данные
AB> CS - контрольная сумма.
AB> E - конец.
О, и мы такой же давно используем, даже без "конца"...
AB> Что еще можно сделать я не знаю, да и с помехами у меня не так плохо.
А помехи отфильтровываются следующим уровнем протокола, т.е. если помеха
была и контрольная сумма не совпала - сообщение игнорируются приемной стороной,
а передающая, не получив реакции - повторяет.
Alexandr.
Alexandr Leptukh
Hello, Alex!
Tuesday 04 February 2003, 15:24, Alex Kouznetsov writes to Alexandr Leptukh:
AK>>> Hет, я про преамбулу и тайм-ауты. В правильном протоколе за
AK>>> время действия преамбулы произойдут следующие события: -- UART
AL>> Вот мы и приехали к началу этого тренда :) Если
AL>> "правильность" и "заточенность под RS485" протокола ModBus RTU
AL>> (так , вроде ?) состоят только в этом, то он получается ничем не
AL>> лучше других "самопальных" (в твоей трактовке) протоколов, в
AL>> которых это все вышенаписанное тоже обычно делается.
AK> К сожалению, не могу согласиться, не вижу оснований. Мне лично не
AK> встречались самопальные протоколы в которых бы это тоже делалось, так
AK> что слова "тоже" и "обычно" мне кажется неуместным. В доказательство
AK> могу привести примерно с пяток самопальных протоколов, с которыми я
AK> встречался "живьем", и, наверное, с десяток "виртуальных", т.е.
AK> упомянутых в различных конференциях при обсуждении этой темы.
Значит мне повезло :) - и нашим программистам удалось (и не один раз)
написать самопальные протоколы, которые, на мой взгляд, нормально работают. Да
и
у других коллег (а также см. мой ответ коллеге Бондаренко) тоже работает...
AK> То что самопальный в принципе _можно_ сделать правильно - в этом у
AK> меня сомнений нет. Hо у меня также нет сомнений в том, что
AK> самопальный протокол для RS485, сделанный "партизанским" способом, "с
AK> налету" и "на арапа", почти наверняка будет HЕ помехоустойчивым (хотя
AK> как-то работать, конечно, будет).
Серьезные работы не делаются "с налету" и "на арапа". Если же работа "не
серьезная" - тогда ей "серьезный" протокол и не нужен в принципе.
AK> Зная это, с моей точки зрения,
AK> по-настоящему честный совет начинающим - это ткнуть пальцем в
AK> правильный "фирменный" протокол. Если же советовать делать свой, то
AK> это все равно что посылать людей на минное поле. Кто-то может и
AK> пройдет...
Из моего опыта многие "фирменные" протоколы закрытые, т.е. данных не
найти, может любимый тобой Modbus исключение, не знаю...
Если вспомнить исходное письмо, с которого все началось, то там не было
упоминания - "начинающий" спрашивает или нет :) Hа "просто" заданный вопрос был
дан "простой" ответ.
ps: вообще, обсуждение этой темы оказалось вполне полезным для меня,
спасибо всем участникам :)
Alexandr.
Gerasimov Gerasim
AL>>> Вот мы и приехали к началу этого тренда :) Если
AL>>> "правильность" и "заточенность под RS485" протокола ModBus RTU
AL>>> (так , вроде ?) состоят только в этом, то он получается ничем не
AL>>> лучше других "самопальных" (в твоей трактовке) протоколов, в
AL>>> которых это все вышенаписанное тоже обычно делается.
AL> Значит мне повезло :) - и нашим программистам удалось (и не один
AL> раз) написать самопальные протоколы, которые, на мой взгляд, нормально
AL> работают. Да и у других коллег (а также см. мой ответ коллеге
AL> Бондаренко) тоже работает...
Любая SCADА система умеет общаться с устройствами имеющими ModBUS RTU потому,
что он стандарт де факто среди протоколов для промышленности.
Одно дело, когда ваши устройства общаются только между собой в изолированной от
устройств других производителей сети, тогда дальше можешь не читать .
А если ваш клиент захочет сделать визуализацию данных обрабатываемых вашими
устройствами? Или вытянуть данные из ваших устройств в корпоративную сеть,
чтобы
любой наделённый полномочиями человек (главный инженер например) смог в своём
кабинете из браузера посмотреть за работой прибора находящегося где нибудь у
чёрта на куличках в самом грязном цехе. Что делать будете?
О да, конечно, у вас классные программисты, они потратят год-полтора, на
сопряжение вашего протокола со СКАДОй используемой клиентом, напишут OPC и DDE
сервера, или (если они Воистину Крутые Программеры) напишут с нуля скаду со
всеми наворотами для визуализации. Ембеддеры в свою очередь сделают переходник
СамопалBUS-Ethernet.
ModBUS RTU - он не хуже, и не лучше самопальных протоколов использующих CRC, ОH
СТАHДАРТHЫЙ!!! и его использование экономит значительные средства при
разработке
и главное сопровождении продукта.
Hужна визуализация - нет проблем, передай проектной службе клиента перечень
доступных регистров и формат данных в них, и они сами, прикрутят ваши девайсы к
своей скаде т.к. необходимый для ModBUS`а OPC сервер доступен бесплатно. В
случае с главным инженером осматривающим свои владения через браузер, нужен DDE
сервер, который также распостраняется бесплатно. Вашим Ембеддерам не нужно
напрягать мозги для изготовления переходников ModBUS->Ethernet, их выпускают
почти все конторы так или иначе связанные с автоматизацией производства.
Ты скажешь достали со своим модбасом, чтож, есть альтернатива, существуют ещё
несколько протоколов реально работающих по RS485 и поддерживаемые (наверное)
всеми распространёнными скада системами:
Siemens: ProfiBUS //вроде открый но лучше использовать спец микрахи
AllenBradly: DH+ //за очень отдельные деньги
Wago: FildBUS (боюсь что написал с ошибкой)//доступен за деньги
.....
AL> Из моего опыта многие "фирменные" протоколы закрытые, т.е.
AL> данных
AL> не найти, может любимый тобой Modbus исключение, не знаю...
Очень даже открытый протокол, инет просто засорён информацией о нём, в том
числе и на русском языке.
С уважением. Gerasimov_Gerasim
ЗЫ Я прикручиваю к своим бахарайкам МодБАС, и сплю очень спокойно, благодаря
ТОТАЛЬHОЙ поддержке этого протокола компаниями производящими железо и софт для
автоматизации производства.
ЗЗЫ Когда я связался с ребятами занимающихся визуализацией промышленных
процессов (на скадах Iconix и WinCC) глубоко проникся процессом интеграции
нового устройства в скаду и узнал, что нужно (знать,уметь,сделать,прочитать на
языке потенциального противника) чтобы мои устройства стали полноценным
объектом
автоматизации (а МодБАС я уже запрограммил) то долго благодарил Бога, за то,
что
сразу указал мне верный путь.
Alexandr Leptukh
Hello, Gerasimov!
Thursday 06 February 2003, 09:26, Gerasimov Gerasim writes to Alexandr Leptukh:
GG> Любая SCADА система умеет общаться с устройствами имеющими ModBUS RTU
GG> потому, что он стандарт де факто среди протоколов для промышленности.
GG> Одно дело, когда ваши устройства общаются только между собой в
GG> изолированной от устройств других производителей сети, тогда дальше
GG> можешь не читать .
С тем, что ты написал ниже я абсолютно согласен :) Если обстоятельства
позволяют использовать некоторое стандарное средство, то грех его не
использовать. Если же начинается некоторая специфика - стандартные средства
могут оказаться не совсем годными. Примеров можно много привести, и не только в
embedded области.
Мы занимаемся многоканальными измерительными системами среднего
быстродействия, измеряющими несколько сотен каналов за десятые доли секунды. Я
разговаривал с нашими программистами по поводу MODBUSa - по их словам, его
использование было вполне возможно, но за счет стандартизованного в нем формата
сообщений (просьба сильно не пинать, т.к. со слов) мы бы сильно потеряли,
например, в скорости передачи информации по интерфейсу. Т.е. если сейчас мы,
например, одним сообщением передаем сразу сотню параметров, то в случае MODBUSa
(так мне было объяснено) пришлось бы слать сотню коротких сообщений с
результатом измерения конкретного параметра. Есть, видимо, и другие причины.
Естественно, что наличие своего своеобразного протокола привело к
необходимости написать и свой DDE-сервер, чтобы работать с покупной
SCADA-системой и т.п. Hо это не является какой-либо серьезной проблемой.
Так что я не настолько консерватор, чтобы не понимать недостатки
нестандартизованных устройств и протоколов :), но мы начинали эти работы более
10 лет назад, тогда еще с импортной комплектацией и покупными SCADAми было,
мягко говоря, плохо. А потом было проще использовать готовые наработки своего
протокола, чем переходить на какой-нибудь новый без веской на то причины.
GG> ModBUS RTU - он не хуже, и не лучше самопальных протоколов
GG> использующих CRC, ОH СТАHДАРТHЫЙ!!! и его использование экономит
GG> значительные средства при разработке и главное сопровождении продукта.
Да, все правильно, но стандартность имеет часто и отрицательные качества.
Заниматься инженерной работой в наше время вообще нестандартное занятие :)
Alexandr.
Sergei Tuchinski
06 Feb 03 21:41, Alexandr Leptukh написал для Gerasimov Gerasim:
AL> сейчас мы, напpимеp, одним сообщением пеpедаем сpазy сотню паpаметpов, то
AL> в
AL> слyчае MODBUSa (так мне было объяснено) пpишлось бы слать сотню коpотких
AL> сообщений с pезyльтатом измеpения конкpетного паpаметpа. Есть, видимо, и
коpотко говоpя - тебя... гм... ввели в заблyждение
WBR, Сеpгей. ICQ: 101347299
Oleg Tkachenko
> Очень даже открытый протокол, инет просто засорён информацией о нём, в том
> числе и на русском языке.
Уже уговорили.:-)
Можно ссылочки на его описание(лучше на русском), а также на шаровые OPC
и DDE сервер.
И если совсем хорошо, на примеры его реализации в исходниках на "чем
угодно" в МК Атмел(можно и других).
Ткаченко Олег
Alexander Golov
Thu, 06 Feb 2003 09:26:40 +0300, Gerasimov Gerasim писал:
...
> AL>>> Вот мы и приехали к началу этого тренда :) Если
> AL>>> "правильность" и "заточенность под RS485" протокола ModBus RTU
> AL>>> (так , вроде ?) состоят только в этом, то он получается ничем не
> AL>>> лучше других "самопальных" (в твоей трактовке) протоколов, в
> AL>>> которых это все вышенаписанное тоже обычно делается.
Получился какой-то совершенно беспредметный спор. Изначальный вопрос
был: "Какой протокол подходит для RS-485"? Modbus RTU подходит? Да,
вполне, если есть желание (или потребность) тратить силы на вписывание
в какой-то стандарт. Но с равным успехом подходит и море других, как
их тут обзывают "самопальных" протоколов.
Уже наверное все знают, что есть _конкретная_ проблема при
использовании RS-485 совместно с UART: несанкционированные запуски
последнего от шума линии и, как следствие, рассинхронизация приёмных
автоматов. Но сама эта формулировка легко даёт понять, что тут главное
не протокол, а программные реализации драйверов линии и приёмного
автомата, потому как "продувка" каналов это чистая драйверная функция
и связана лишь с особенностями конкретного железа, вопросы же
синхронизации начала сообщений могут решаться несколькими способами,
от аппаратных до программных и не обязательно прямо связаными с
протоколом. Конечно можно, как в Modbus RTU, решить элементом
протокола и "продувку" и синхронизацию, но это имеет и свою обратную
сторону, о чём ниже.
...
>Любая SCADА система умеет общаться с устройствами имеющими ModBUS RTU потому,
>что он стандарт де факто среди протоколов для промышленности.
>
>Одно дело, когда ваши устройства общаются только между собой в изолированной от
>устройств других производителей сети, тогда дальше можешь не читать .
Всё, возможно, было бы абсолютно замечательно, если бы Modbus RTU был
идеален и применим везде. Но что мне толку от возможности сразу
работать на моём базовом протоколе с какой-то SCADA'ой если я не могу
на нём полностью работать внутри моей системы? Попробуй присоединить
свой UART к телефонному модему и посвязываться на Modbus RTU.
ВременнЫе маркеры из преамбул T1-T2-T3-T4 на которых тот базируется
здесь уже не будут работать и связь развалится. Или, скажем, передача
через радиостанции требует довольно громоздкой "продувки" канала, для
которой совершенно недостаточно преамбулы T1-T2-T3-T4, а значит всё
таки нужна специальная драйверная функция в возможности применения
которой мы, почему-то, изначально отказывали "самопальным" протоколам.
И наконец, всё те же временнЫе маркеры мешают тащить Modbus RTU поверх
другого транспорта, скажем CAN или TCP/IP.
>А если ваш клиент захочет сделать визуализацию данных обрабатываемых вашими
>устройствами? Или вытянуть данные из ваших устройств в корпоративную сеть,
>чтобы
>любой наделённый полномочиями человек (главный инженер например) смог в своём
>кабинете из браузера посмотреть за работой прибора находящегося где нибудь у
>чёрта на куличках в самом грязном цехе. Что делать будете?
Если это так принципиально, я могу реализовать Modbus RTU как второй
протокол, специально для этой SCADA'а. Весь фокус в том, что мне в
случае использования Modbus RTU всё равно понадобится два протокола,
чтобы дореализовать то, что тот не позволяет делать. Но всегда
практичнее во взаимодействии внутренних узлов всё делать однотипно, а
все внешние интересы на главном узле или выделенных шлюзах.
>О да, конечно, у вас классные программисты, они потратят год-полтора, на
>сопряжение вашего протокола со СКАДОй используемой клиентом, напишут OPC и DDE
>сервера, или (если они Воистину Крутые Программеры) напишут с нуля скаду со
>всеми наворотами для визуализации. Ембеддеры в свою очередь сделают переходник
>СамопалBUS-Ethernet.
>ModBUS RTU - он не хуже, и не лучше самопальных протоколов использующих CRC, ОH
>СТАHДАРТHЫЙ!!! и его использование экономит значительные средства при
>разработке и главное сопровождении продукта.
Он во многом хуже, например, Modbus ASCII, который хотя и существенно
увеличивает трафик, но легко решает все упоминавшиеся мной задачи.
Таким образом, любой самопальный протокол, не использующий временнЫе
маркеры, имеющий предопределённый формат пакета и защищённый CRC, с
моей точки зрения, лучше Modbus RTU. Конечно, принципиально, я могу
построить автомат приёма сообщений Modbus RTU без временнЫх маркеров,
но из-за особенностей его формата (отсутствия символа начала пакета и
значения длины пакета), эта реализация будет требовать очень больших
затрат машинного времени на анализ структуры пакета и форматов данных,
поэтому, я думаю, это не слишком хороший путь.
>Hужна визуализация - нет проблем, передай проектной службе клиента перечень
>доступных регистров и формат данных в них, и они сами, прикрутят ваши девайсы к
>своей скаде т.к. необходимый для ModBUS`а OPC сервер доступен бесплатно. В
>случае с главным инженером осматривающим свои владения через браузер, нужен DDE
>сервер, который также распостраняется бесплатно. Вашим Ембеддерам не нужно
>напрягать мозги для изготовления переходников ModBUS->Ethernet, их выпускают
>почти все конторы так или иначе связанные с автоматизацией производства.
Это всё понятно и унификация это замечательно, только не надо пытаться
здесь представить, что вся проблема состоит в отсутствии Modbus RTU в
моём (твоём и т.д.) устройстве. На самом деле тут никакой унификацией
и близко не пахнет и особенного движения в эту сторону не заметно. В
реальной практике данные приходится собирать с массы различных
устройств с кучей самопальных протоколов открытых, закрытых и чуть
приоткрытых с причудливыми, а иногда и форменно извращёнными
реализациями и хочешь ты или нет, тебе (или кому-то) регулярно
придётся реализовывать эти протоколы в рамках SCADA'ы или на базе
Блоков согласования интерфейсов.
>Ты скажешь достали со своим модбасом, чтож, есть альтернатива, существуют ещё
>несколько протоколов реально работающих по RS485 и поддерживаемые (наверное)
>всеми распространёнными скада системами:
>Siemens: ProfiBUS //вроде открый но лучше использовать спец микрахи
>AllenBradly: DH+ //за очень отдельные деньги
>Wago: FildBUS (боюсь что написал с ошибкой)//доступен за деньги
>.....
Да какие это альтернативы? Или закрыто, или нереализуемо без спец-ИС.
Реальная альтернатива -- CAN и единственное, что поддерживается во
многих МК, но лично я воспринимаю CAN не как транспорт, а также как
UART.
Александр Голов, Москва, Alex....@mtu-net.ru