слушать модбас реально.

модбас, прослушка, невозможно...

а если многоканальные слейвы всегда отвечают пакетом? т.е. в одной посылке данные по всем каналам, даже если канал не используется. данные дискретных каналов передавать как один регистр.
того кто слушает настраиваем на адрес того кого слушать и длину пакета в байтах. всё остальное игнорируем, игнорируем и посылки с чётным количеством байтов, реагируем только если выполняется условия:
1. адрес.
2. код ответа с данными.
3. количество байт соответствует ожидаемым каналам с адреса.
4. общее кол-во байт нечётное

кто приведёт пример посылки мастера который шпион примет за ответ слейва?

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

если функция шпиона понадобится, то следить нужно только за данными каналов слейвов.
вопрос с кодом 03 перепутать с ответом с кодом 03 невозможно,
в запросе чётное количество байтов в ответе нечётное.

если связь плохая, то для контроля ощибок существует контрольная сумма, если ответы слейвов наложились друг на друга, то здесь и мастер не разберёт.

приведите пример где запрос 03 соответствует ответу 03.(crc не обязательно)

кстати, при использовании пакетных протоколов, мне в голову даже не приходит опрашивать по одному регистру.

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

Цитата:

---

Сообщение от Филоненко Владислав

"При необходимости реализуется программно не напрягаясь." - Общие слова говорят о Вашем незнакомстве с протоколом ModBus. Реализовать невозможно.

---

Владислав, Вы и Ваши коллеги были очень неправы...
Ну ещё развеян последний миф в пользу овеновского протокола.

Вот и слушайте на здоровье. Разве мы обязаны Вам раскрывать глаза?
Или будем компенсировать потери от 17 тон осетрины, испорченной из-за супер новой технологии прослушивания ModBus?
Какие доказательства. Проблема не решаема, я это выяснил 2 года назад и забыл о выкладках, т.к. не интересно. Мне абсолютно не интересен ни протокол ModBus, ни попытки сделать из мухи дирижабель. Надуть ее можно, но ведь лопнет :) Напишите а РАН, пусть докажут, что 2+2=4.
Только в России, спустя 30 лет с разработки ModBus была открыта страшная тайна - его можно прослушивать. Вот все автоматчики обалдуи. Это-ж золотое дно!

Чуть сбавьте обороты пожалуйста - закрою тему...

А мне никогда не приходится слушать сеть, ни разу не сталкивался с такой необходимостью.
Вся проблема в Ваших неверных высказываниях по поводу форматов чисел (в теме о ПР110) и других "недостатках" этого протокола.
Меня задело то, что вы искажаете информацию и выдаёте людям её за истину, я даже поверил Вам что прослушивание сети с модбасом связано с ужасными трудностями и очень велика вероятность ошибок. Но неделю назад просматривал мануал на протокол одного частотника и вспомнил про прослушку, задумался, оказалось что проще некуда.

т.е. в посте о ПР110 я уже приводил доказательства о форматах, в этом посте простейший алгоритм прослушки. От Вас ожидалось, что Вы приведёте доказательства, что алгоритм неверный или признаете что ошибались. Если бы проигнорировали пост, я бы тоже воспринял это как признание ошибки.

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

Мне конечно будет очень приятно, если вдруг окажется что я первый за 30 лет,

Врятли я ошибусь, если предположу что именно Вы один из авторов овеновского протокола.

Вы мне льстите :) Я был слишком мал, когда создавался протокол ОВЕН :)
У Вас доказательств Ваших слов нету, но Вы их требуете от нас. Начните с себя. Приведите доказательства.
Или Вы доверяете экспертному мнению, либо сами пробуете доказать Ваши утверждения.

Сколько раз нужно повторится?

Вы писали используя мою цитату:

Цитата:

---

Сообщение от Филоненко Владислав

"Модбас пакетный протокол, для самого протокола не имеет значения в каком формате передаются данные, лишь бы указание длины и колв-во байтов соответствовало. - Вот это расскажите всем пользователям и производителям SCADA - ну совсем не важно как передает. :)

---

Ваши высказывания о том что мобас плохо дружит с разными форматами неверно,
Простое доказательство на русском языке: Lectus Modbus OPC/DDE сервер http://www.lectussoft.com/ опрбован не только мною на разных форматах.

И про прослушку:

Цитата:

---

Сообщение от Филоненко Владислав

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

---

Доказательсво простое:
По стандарту модбаса в запросе на чтение данных всегда чётное кол-во байтов, в ответе нечётное, если это условие не выполняется, то это уже не модбас.
Естественно Вы не сможете привести пример где запрос 03 сответствует ответу 03.

Будем отрицать используя аргументы про рыбу?

Цитата:

---

Сообщение от BETEP

По стандарту модбаса в запросе на чтение данных всегда чётное кол-во байтов, в ответе нечётное, если это условие не выполняется, то это уже не модбас.

---

Это утверждение не совсем верно.
Можно привести пример чтения дискретных выходов
(чтение 19 регистров начиная с 0x0300):
Tx: 01 01 03 00 00 13 7D 83
Rx: 01 01 03 00 00 13 7D 83

Речь идёт о чтении регистра, код 03 (длина регистра естественно два байта)
В начале поста для чтения битов предлагалось использовать тоже 03, а не 01.

Я и сам читая состояние дискретных входов частотника (любого от яскавы) использую код 03, т.е читаю полностью слово (16 бит) а уже в полученном слове использую биты на своё усмотрение

т.е. требуется пример именно для
(0x03) — чтение значений из нескольких регистров хранения (Read Holding Registers)

так что Lectus, извините, но Ваш пример с кодом 01, не в тему. требуется пример с кодом 03

Предлагаю ВСЕМ согласится с тов. ВЕТЕР если будет приведен хотя бы одного коммерческого устройства или OPC сервера, который работает на прослушивание протокола модбас. Самопалы не предлагать.
При отсутствии ответа предлагаю закрыть тему.
Условием работы устройства/OPC предполагается работа с любым слейвом модбас.

Ну это уже слишком, не опровергнув моих доводов требовать от меня ещё доказательств?

а программируемые коммуникационные модули для контролеров омрона (SCU), которые настраиваются практически на любой протокол, (кроме овена) подойдут? Вся прога для этого модуля займёт две строчки, первая- шаблон для 8 слов аналогово модуля ввода, вторая для 1 слова дискретного модуля ввода. Ну если очень хочется, можно добавить пару строк чтобы знать что на модули выходов передаётся.

Предлагаю ВСЕМ согласится с тов. ВЕТЕР если будет приведен хотя бы одного коммерческого устройства или OPC сервера, который работает на прослушивание протокола модбас.
Условием работы устройства/OPC предполагается работа с любым слейвом модбас.

P.S. Вы же у нас доказательств требуете?:D

Я прошу опровергнуть мои высказвания по поводу форматов и посылки с кодом 03 на чтение регистров. Не имея возможности доказать что я неправ, Вы начинаете требовать с меня новые доказательства. Офигительный способ ведения спора.

Цитата:

---

Сообщение от Филоненко Владислав

Условием работы устройства/OPC предполагается работа с любым слейвом модбас.

---

Продолжим?
У МВА8 для опроса всех каналов одной посылкой нужно 48 регистров запросить? а он точно ответит на такой вопрос? (в мануале re_MVA_679.pdf ни слова об ограничении длины посылки) и зачем мне столько регистров со служебными данными? чтобы знать куда запятую поставить? Любому пользователю в первую очередь важны данные по каналам, есть ли ошибки, и скорость связи. Представляете, некоторые производители запихивают данные по 8 каналам в 16 байтов, место для запятой фиксированное, а при ошибке входа вместо измеренного значения передаётся например 7FFF.

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

Может быть закончим спор с формулировкой "При использовании модбас нельзя прослушивать сеть с приборами ОВЕН, но прослушивание возможно с приборами других производителей, например прослушке поддаются модули M-7000 от ICP DAC, т.к данные по всем каналам можно передать в одной посылке"

ну и в заключение:
Модули последовательного интерфейса CS1W-SCU21-V1 и CJ1W-SCU21/41 от омрона.
Устройство коммерческое,
На модбас настраивается, в зависимости от прог.пользователя может быть и мастером, и слейвом.
Перехватить данные с каналов и ошибки с модулей M-7000 по шаблону, как два пальца о... С модулей МВА8 только при условии если передадут все 48 регистров в одной посылке.

У Вас ТРМ-138 с поддержкой модбаса выходит? ну я очень удивлюсь если вы номера для регистров данных каналов не раскидаете с интервалом в 5-10 слов.
Удивительно, сколько приборов с модбасом не смотрю всегда выясняется что нужные мне данные лежат подряд, причём рассортированы по приоритету, который почти всегда совпадает с моей задачей, беру МВА8 и... откладываю в сторону и пишу заявку на ICP DAC.(ещё и из-за скорости АЦП)

Цитата:

---

Сообщение от Филоненко Владислав

Только в России, спустя 30 лет с разработки ModBus была открыта страшная тайна - его можно прослушивать. Вот все автоматчики обалдуи. Это-ж золотое дно!

---

Смешно. Учитывая то, что сами разработчики приборов Овен узнали о существовании протокола модбас всего три года назад... :)
На самом деле, просто нафиг никому не нужно слушать протокол. Любой (хоть овен - хоть модбас - хоть xxxprotokol). Я не смог придумать реально востребованную задачу, которую на модбасе нельзя реализовать без использования режима прослушки. Может, Владислав подскажет? ;)

В догонку:
может для ТРМ-138 предусмотрите нормальный ответ на запрос данных с каналов?

Например запрашиваем данне 8 регистров,
в ответе получаем 8 регистров с шестнадцатиричными данными каналов, если ошибка входа пишем в регистр 7FFF, для разрешения этого прибора два байта выше крыши. запятая не нужна, тот кто настраивает запрос обычно знает где запятая находится.
после основных регистров с данными уже можно добавлять дополнительные, но обязательно с соблюдением приоритета, т.е. то что менее важно в конец.
Я как-то работал с одним чешским одноканальным прибором, тот в одной посылке сразу мог передать заданное значение, измеренное,значение на выходе, состояние дискретных выходов и ещё немного о своём состоянии.
Достаточно удобно если запросив штук 20 регистров пользователь получит всё состояние прибора.


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

Цитата:

---

Сообщение от SMH

Смешно. Учитывая то, что сами разработчики приборов Овен узнали о существовании протокола модбас всего три года назад... :)
На самом деле, просто нафиг никому не нужно слушать протокол. Любой (хоть овен - хоть модбас - хоть xxxprotokol). Я не смог придумать реально востребованную задачу, которую на модбасе нельзя реализовать без использования режима прослушки. Может, Владислав подскажет? ;)

---

От только не надо. Тема стремительно превращается в ринг.
И про ModBus мы, естественно, знали, и не 3 года.
И про его достоинства/недостатки. Недостатков, ИМХО, существенно больше.
А режим прослушки был создан и реально кое-где используется, если надо добавить регулятор/инт. устройство в уже существующую систему, НЕ МЕНЯЯ ее работы, не имея доступа к мастеру сети, если связь уже работает близко к пределу ПСШ и лишние запросы мастер-славе нельзя вставить. Ситуация не типичная, но существующая.

ВЕТЕР, В конкретном случае с конкрентыми данными прослушать ModBus можно. Но т.к. это именно конкретные условия - метод не применим для серийной автоматизации. И не стандартизирован.
Только для спецрешений, и потом те, кто будет за Вами расширять/модернизировать систему очень наплачутся пытаясь выяснить, что это за недокументированная фича в сети ModBus?

Можно сказать что я доволен Вашим ответом, надеюсь смог заставить Вашу фирму задуматься о правильности некоторых ваших решений по поводу протоколов и связи.
------------------
Для того кто будет копать мою АСУ после меня, я пишу всякие инструкции, комментирую тексты программ (скорее для себя). Правда мои инструкции операторы и киповцы не читают... Бесится начинаю вплоть до матов когда десятый по счёту человек задаёт вопрос, ответ на который в инструкциях которые я писал...

И не в тему:
Покопал инет на фразу "недостатки modbus", на точную фразу поиска гугль и рамблер предлагают только один результат, но там недостатки не перечисляются. Яндекс предложил то-же самое и Ваш форум.

т.е. всё что я смог найти из недостатков модбаса, это:
1. недостатки самой 485(422/232) сети, естественно к протоколу это не имеет отношкения.
2. В сети один мастер, вот с этим недостатком трудно согласится, у модбаса своё назначение, и он не претендует на роль протокола на все случаи жизни как например профибас.(но возможно есть производители которые в своих устройствах реализовали передачу прав мастера через пользовательские коды)
3. Ограниченное число регистров 65535, типа маловато для различных приборов! файл больше 128 кб. не передать.

Вот никак понять не могу почему протокол с такими недостатками стал стандартом де-факто и ещё отпрыска породил (TCP)?

С некоторых времён стал поклонником использования сетей в проектах, сейчас если что-то значительное сочиняю, в проекте обязательно несколько сетей разных типов и обязательно эзернет на самом верху, т.е. каждый используемый тип сети выполняет то, для чего он предназначен. Кто-то может сказать что это зоопарк и плохо. Я же могу связаться с частотником подключенным по модбасу к контроллеру из дома через интернет, точнее переодически это делаю когда возникает необходимость.

И мне всё ещё нужен ответ о длине пакета для МВА8, или ткните в инструкцию где это описано.

Цитата:

---

Сообщение от BETEP

Вот никак понять не могу почему протокол с такими недостатками стал стандартом де-факто и ещё отпрыска породил (TCP)?

---

Просто так получилось. И таких примеров во всех отраслях - масса.
Возьмем классику - архитектура IBM PC при ее создании в 1981г была пожалуй самой "кривой" из всех компьютерных архитектур. Результат ее развития и выдавливания других - все мы видим.

Вот именно, так получилось (де-факто). и модикон (если не путаю) никого не выдавливал в отличии от сименса с профибасом. Вся прелесть модбаса в его простоте, пакетности, и отказе от любых форматов. и ещё он позволяет добавлять не стандартизированные коды функций производителям разных устройств. Это как в анекдоте, не любите модбас? да вы просто не умеете его готовить!

В догонку.
Запускал на прошедшей неделе сеть из 6 МДВВ и 3 SMH2010, которых опрашивает SMH2010 мастер, испытал некоторые трудности.
Один из модулей МДВВ упорно не хотел отвечать на запросы о состоянии своих входов. Проблему решил, изменив количество стоп битов с двух на один. Стал отвечать. Чей это глюк, интересно?

Цитата:

---

Сообщение от SMH

В догонку.
Запускал на прошедшей неделе сеть из 6 МДВВ и 3 SMH2010, которых опрашивает SMH2010 мастер, испытал некоторые трудности.
Один из модулей МДВВ упорно не хотел отвечать на запросы о состоянии своих входов. Проблему решил, изменив количество стоп битов с двух на один. Стал отвечать. Чей это глюк, интересно?

---

Вы же понимаете, что вопрос риторический.
А что произошло, когда вы отключили питание с других МДВВ и SMH?

Цитата:

---

Сообщение от ASo

Вы же понимаете, что вопрос риторический.
А что произошло, когда вы отключили питание с других МДВВ и SMH?

---

Я отрезал линию (RS-485) от трёх SMH. МДВВ стал отвечать.