Обсуждение:Modbus

структурировать

отдельно Modbus RTU/ASCII и ModBus TCP/IP ибо порядок следования байт разный. — Эта реплика добавлена участником Андрей Рыжков (о • в) 11:22, 1 апреля 2008 (UTC)

семиуровневая модель

Наверно модель OSI больше вносит путаницы, чем объясняет. Но Modbus описывает адресацию в сети, делит данные на пакеты, и определяет примитивную сессию вопрос-ответ. При этом он не стандартизирует назначение регистров а значит относится к сетевому, транспортному, сессионному уровням и, возможно, к уровню представления. --213.191.11.173 09:54, 5 октября 2009 (UTC)

• Там где модель ОSI применима - соответствие уровней прописано в стандарте, придумывать ничего не надо. ASDFS 15:08, 12 июля 2011 (UTC)

О термине клиент-сервер

Насколько правомерно применять здесь термин клиент-сервер, если больше подходит мастер-слэйв? --Владимир Грызлов 21:20, 17 декабря 2009 (UTC)

Согласен. Нет тут ни каких клиен-сервер. Тут мастер-слэйв.--Juvf 07:38, 6 августа 2014 (UTC)juvf

В официальной документации на modbus оперирует "clien-server". Дословный перевод клиент-сервер. Но на самом деле в русском языке в данном контексте это нужно понимать как мастер-слейв. Как правило в системах клиет-сервер есть один сервер и у него много клиентов. В протоколе modbus один мастер(клиент) и много слейвов(серверов). — Эта реплика добавлена участником Juvf (о • в) 02:56, 7 августа 2014 (UTC)

О недостатках

"Стандарт не предусматривает никакой оперативной сигнализации от конечного устройства к мастеру в случае необходимости (прерывания). Устройство должно ждать своей очереди в опросе периферийных устройств мастером. Это существенно ограничивает применимость MODBUS-решений в системах управления реального времени."

Зачем тут упоминание про реальное время. Не путайте людей. Modbus это реалтаймовый протокол. Если мастер послал в шину запрос, то можно с большой точностью предсказать когда слэйв получит этот запрос. Всё! Вот вам весь реалтайм. А то что слэйв может вообще не дождаться ни когда запроса - реалтайм тут не причем. Если мастер опрашивает счетчик электроэнергии по модбусу на определённой скорости, то время ответа равно ВремяПередечиЗапроса + 3,5 символа + время обработки слэйвом + время передачи ответа + 3,5 символа. Протокол реалтаймовый. Время передачи запроса и ответа фиксировано и не может быть то больше, то меньше. Если слэйв реалтаймовый, т.е. обработает ответ за фиксированное время, то мастер после начала передачи запроса получит ответ через определённое время. В TCP/IP например время передачи по каналу разное и поэтому тсп не реалтаймовый. в тсп пакет послал..... он может прийти черел 1 мс, а может через 5 сек. А модбус раелтаймовы протокол. в передаче не может быть задержек. −

"Стандарт не предусматривает обмен данными между периферийными устройствами друг с другом без участия мастера. Это также ограничивает применимость MODBUS-решений в системах регулирования реального времени." Опять про реалтайм... ну про реалтайм я сказал выше. что касается обмена данными....

"Стандарт не предусматривает обмен данными между периферийными устройствами друг с другом без участия мастера." во первых - стандарт не предусматривает обмен данными между переферией и с участием мастера. во вторых... что такое "периферийные устройства"? Стандарт предусматривает устройства ведущий и ведомый (master/slave). Стандарт не предусматривает перефирийные устройства. Что такое переферийное устройство? В системе сборщик данных может быть основным, а датчики периферийными. Но датчик на шине может быть мастером. Получается что датчик перефериное устройство, но при этом мастер. Кто запрещает?

То что вы называете обмен данными между периферийными устройствами друг с другом с участием мастера - это что-то типа.... мастер спрашивает слэйва1 "Есть у тебя данные для слэйва 2?". Слэйв 1 отвечает что есть. мастер тащит из слэйва 1 данные и передает их слэйву 2. Но это обмен не на уровне протокола. Это уже надстройка над модбусом. Т.е. если опуститься на уровень протокола модбус, то там нет ни каких "Есть у тебя данные для слэйва 2?".... там это выглядит так

мастер читает регистр 0х0100 ("Есть у тебя данные для слэйва 2?") Слэйв1 отвечает 0х0001 (это означает что есть) мастер читает три регистра с адреса 0х200 (вычитывает адреса сообщения, где лежит инфа для слэйва 2. в первом регистре нач адрес, во втором длинна, в 3-ем нач адрес в слеэве 2, куда данные положить) слэйв1 отвечает мастер пишет данные в слэйв2.

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

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

Модбус - это чтение регистров, не более. Запрос/ответ. Запрос только мастер, на адресный запрос всегда ответ. А так кто переферия, орбитр, куда что передавать и реали тайм не реалтайм... это уже всё надстройки над модбусам. — Эта реплика добавлена участником Juvf (о • в) 11:34, 5 августа 2014 (UTC)

• Нет протоколов реального времени. Есть системы реального времени, которые отрабатывают заданный набор задач в заданных временных рамках. Часть системы - это протокол. Если протокол позволяет уложиться по времени - он применим в конкретной системе реального времени. Естественно, продвинутые протоколы применимы чаще за счет, например, возможностей оперативной сигнализации мастеру и прямого обмена данными между узлами. Значит отсутствие таких возможностей можно считать недостатком, ограничивающим применимость протокола в системах реального времени. ASDFS 14:41, 5 августа 2014 (UTC)

несогласен. есть разные понятия систем реального времени. Нас учили, и я придерживаюсь такого понятия: Ситема реального времени - эта система, в которой предсказуемо время реакции системы на воздействие. Т.е. если пришло прерывание в процессор и реакция на него, например изменение логического уровня на пине, предсказуема, т.е. строго через t уровень на выходе изменится - это СРВ. t может быть равно 1 нс, а может 1 мс... а может 1234567 секунд и 17 нс. Взять модбус - передача по модбусу - предсказуема. Передача пакета от мастера к слэйву в 10 байт равна времени передачи 13,5 байт. допустим на скорости 921600 бит в сек это составит 146,484375 мкс. Если вашей системе эта задержка приемлема - это вам подходит. Если не приемлема, нужно быстрее, то вам это не подходит. Либо увеличите скорость, либо снизьте кол-во данных... либо как-то систему перестройте. Но это по любому будем СРВ. Уберите слово модбус. Вставьте любое другое:

Взять %имя_протокола/интерфейса% - передача по %имя_протокола/интерфейса%- предсказуема. Передача пакета от источника к приемнику в n байт равна времени 146,484375 мкс. Если вашей системе эта задержка приемлема - это вам подходит. Если не приемлема, нужно быстрее, то вам это не подходит. В любом случае это СРВ.

С модбус-ом легко делается синхронизация времени. если мастер передал время в пакете, то слэйв получив этот пакет может отнять длительность прохождения пакета и получить точное время. Это и есть система реального времени. TCP/IP такого не позволит. Каждый раз время прохождения пакета будет разное (нужны более сложные алгоритмы).

Если вы настаиваете на своём, на своем "часть системы - это протокол. Если протокол позволяет уложиться по времени - он применим в конкретной системе реального времени." - назовите мне протокол который не усложняет использование в СРВ? этот протокол сможет передать 1000 Тбайт за 0,01 пс секунд? НЕТ!!! Ну значит этот протокол тоже неприменим в СРВ.

"Естественно, продвинутые протоколы применимы чаще за счет, например, возможностей оперативной сигнализации мастеру и прямого обмена данными между узлами." - какие возможности оперативной сигнализации? какой прямой обмен между узлами? Это модбус! Не нужно ни кого путать и сбивать с толку вашими надеждами на что-то там, на какой-то оперативный отклик. Это протокол мастер-слэйв. Этим все сказано. Нужно строит систему с учетом того, что слэйву не нужно ни кому ни чего сообщать.

"Стандарт не предусматривает никакой оперативной сигнализации от конечного устройства к мастеру в случае необходимости (прерывания). Устройство должно ждать своей очереди в опросе периферийных устройств мастером." Это я тоже удалил. Вы вообще работали с модбусом? какая очередь? какой опрос? Нету в модбусе ни каких очередей и опросов. Есть чтение и запись регистров. Это в каком нибудь Token ring гоняют маркер и ждут своей очереди, или в разделённых по времени протоколах устройство ждёт своего слота времени, чтобы занять шину. Здесь слэйв вообще ни чего не ждёт. У слэйва нет задачи что-то сообщить мастеру. Если систему строить на том принципе, что слэйв должен что-то сообщать - выбирайте др протокол или надстраивайте что-то своё над модбусом. В этом протоколе у слэйвов задача своя, например датчик тока - задача датчика преобразовать силу тока в код АЦП(или в цифровое значение тока) и положить в регистр. Всё! на этом его задача ограничена. Если мастеру нужно - он сам прочитает этот регистр за фиксированное время. Или очень распространены устройства - это счетчик электрической энергии. Задача счетчика измерять ток и напряжение, вычислять потребляемую мощность, вести журнал/статистику по получасовкам, считать тариф день/ночь. Вылазить в шину модбус, ждать опроса, что-то сообщать мастеру - это не его задача. И уж тем более гнать данные другому слэйву на шине. Мастеру нужно - он сам опросит счетчик. Где тут трудность с реальным временем?

Или привод манипулятора.... записали в его регистр управления 0х100 - он повернул шаговый двигатель на 256 шагов. Запросили координаты - он выдал. НИ чего манипулятор не должен сам сообщать мастеру. Это модбус. Не нравиться - организовывай свои опросы или используй протокол, например МЭК-101 или CAN. Опять же, привод вакуумного выключателя - мастер записал в регистры управления команду включить, подождал исполнение (предсказуемое время) - прочитал регистры состояния. Для контроля опросил ещё другой концевик, а также опросил датчик напряжения. Нет тут ни каких сложностей с реалтаймом. т.е. если послать команду "Включить", то через 209 мкс привод начнет исполнять команду. Не через 200, и не через 215, а через 209 ±допустимый джитер.

А допустим привод вакуумного выкл на TCP/IP, подал команду, и она пошла по уровням протокола гулять, 1 сек, 2, 10 сек

--Juvf 17:51, 5 августа 2014 (UTC)juvf

• Вы только что признали что в модбасе есть указанные недостатки. Однако почему то посчитали, что ежели исходная концепция протокола изначально упрощена, то о недостатках можно не упоминать. По вашей логике люди по умолчанию должны понимать что модбас примитивен и потому не нужно от него чего то ожидать. Уточню: википедия пишется для широкого круга читателей, в том числе для тех кто не понимает разницы между модбасом, профибасом, филдбасом и прочими промышленными сетками. Они могут не знать что бывает иначе, и нет ничего зазорного в том чтобы рассказать им об этом.

Что касается концепции модбаса, то вы вполне можете написать вступление к достоинствам и недостаткам, показав что они являются неизбежным следствием этой концепции. Я бы только попросил вас больше внимания уделить академичному стилю изложения.

Вместо постскриптума: предсказуемость времени реакции как признак систем РВ конечно безумно приятна и красива, но, к сожалению, морально устаревшая. В наше время господства микропроцессоров с кэшами и очередями, многозадачных ОС, сетей с коллизиями такую роскошь имеешь нечасто. В жизни все чаще приходится оперировать вероятностью что время реакции не будет превышать требуемое. ASDFS 19:39, 5 августа 2014 (UTC)

На счет РВ спорить не буду.

Но насчет модбуса - я не признавал ни каких его недостатков. Да, именно, статья для широкого круга читателей. В спецификации протокола НЕТ ОЧЕРЕДЕЙ, нет опросов. Нет периферийных устройств. На уровне протокола модбус есть мастер/слэйв, и есть чтение и запись регистров. Всё! Зачем вы (или кто-то) пишет что периферийному устройству нужно ждать очередь? Это не токен ринг. Не нужно путать читателя. Нет ни каких задержек при обмене в рамках этого протокола - т.е. этот протокол с лёгкостью можно использовать в РВ.

А начались мои посты сюда после того, как мне подошел программист высокого уровня (ПО пишет для пк под линукс) которому поставили задачу опросить устройства по модбус-у, он сказал что этот протокол нам не подходит, т.к. он не реалтаймовый. И ткнул меня носом в вики. Он не знаком с этим протоколом, через вики он узнал что в протоколе есть очередь и есть какой-то опрос. Нет тут ни каких опросов. Есть чтение регистров.

Опять же, на Token Ring строят СРВ. Один из протоколов, который это позволяет. Глянул в вики "..делают сеть Token Ring идеальной для применений, где задержка должна быть предсказуема и важна устойчивость функционирования сети. - Вот это свойство, задержка должна быть предсказуема и позволяет делать СРВ. В модбусе задержка чтение/запись регистра предсказуема.

Какие недостатки у модбуса в РАМКАХ ЕГО СПЕЦИФИКАЦИИ? Я не говорю что их нет. Возможно они и есть.... например нельзя сделать пакет больше 256 байт (если не ошибаюсь), ещё недостаток, который люто ненавидят прогеры высокого уровня - это то что в посылке нет размера кадра. На мк выявить паузу в 3,5 символа легко. На ПК, да ещё и под управлением Windows, разделить 2 пакета разделённых паузой в 3,5 символа - практически нереаольно. А также есть такое, что если внутри кадра между байтами есть пауза в 1,5 символа - этот пакет считается бракованным. 1,5 символа, да ещё на какой-нить скорости 921600 - это не подсилу вообще ни каким ОС, даже РТОС-ам. Вот это можно внести в недостатки, т.е. сложность (или невозможность) реализации на ПК под управлением ОС на прикладном уровне (да и на уровне ядра нелегко, если вообще возможно).

А то что там очереди, опросы, нет оповещения.... так это не недостаток, это спецификация.

Вы только что признали что в модбасе есть указанные недостатки. Однако почему то посчитали, что ежели исходная концепция протокола изначально упрощена, то о недостатках можно не упоминать. По вашей логике люди по умолчанию должны понимать что модбас примитивен и потому не нужно от него чего то ожидать. - вот топор.... состоит из топора и топорища. Служит для рубки дров. Вы же не пишите в недостатки топора "Топор не плавает, топор не может принимать и отправлять sms, топором очень сложно сделать операцию на сердце, из топора кашу не сваришь,... И ПОЭТОМУ ТОПОР ОЧЕНЬ СЛОЖНО ИСПОЛЬЗОВАТЬ В ДОМАШНЕМ ХОЗЯЙСТВЕ!" или "Топор не пилит, поэтому его трудно использовать в заготовке дров". А почему? Раз концепция топора упрощена, то о его недостатках можно не упоминать? Вот и с модбусом также. Почему вы подобное пишите про модбус. Вы раскройте сущность топора модбуса, а читатель сам решит использовать ли ему топор в кардиохирургии модбус в его системе.

Модбус по моему мнению не примитивен. Это отличный протокол. Отлично пишет и читает регистры. Отлично подходит для систем сбора данных, причем в РВ. Он и разрабатывался для мастер/слэйв. Конечно, кто-то пожелает на этом протоколе организовать какую нибудь сеть VoIP, или дрова рубить систему телемеханики РВ со спорадическими сообщениями. Теоретически это возможно, но практически достаточно трудоёмко, т.к. модбус для этих целей не предназначен.

ps про академически стиль невзначайте... я это пишу не в статью вики, а в обсуждение, где цель моих постов является донести до автора статьи о мобдусе свою точку зрения. В статьи вики естесно все будет в академическом стиле, мы же не на лурке ;)

--Juvf 03:23, 6 августа 2014 (UTC)juvf

• Модбас имеет вполне четкую сферу применения, а значит его достоинства и недостатки не сфероконны а проистекают из сравнения с аналогичными продуктами. Я еще раз предлагаю вам переписать раздел достоинства и недостатки в выбранном вами ключе: покажите концепцию Модбаса и ее положение на фоне продуктов аналогичного назначения. Это правильнее текущего текста но требует некоторых трудозатрат от вас. Пока этого не сделано считаю что должно быть хоть какое то указание на положение модбаса среди промышленных протоколов, хотя бы в том виде который вы удалили. Заодно можно поправить терминологию и сказать что протокол не может быть реалтайм или не реалтайм, это свойство только системы. ASDFS 13:11, 6 августа 2014 (UTC)

1. я не знаю широко известных аналогичных продуктов. Могу сравнить только с CAN, но это не аналогичный протокол. Я знаю подобные протоколы на разных предприятиях сами разрабатывают (также как когда-то Modicon разработал) - вот с ними я могу сравнить. Но эти протоколы закрыты.
2. а зачем вообще эти недостатки и сравнения с др протоколами? по ссылкам в той же вики погулял по профибас, ика, по др протоколам. там нет недостатков или преимуществ.
3. Пока этого не сделано считаю что должно быть хоть какое то указание на положение модбаса среди промышленных протоколов да пожалуйста, кто против. но захламлять головы читателям мусором и всякими небылицами про модбус, типа периферийные устройства и очереди, которых там нет и в помине - это недопустимо. Зачем вы пихнули туда этот мусор, да ещё пытаетесь защитить что "должно быть хоть что-то"? Вам нужна масса текста? Вам за строки деньги платят? Как влияет этот мусор на "неокрепшие" умы, я вам писал.
4. протокол не может быть реалтайм или не реалтайм, это свойство только системы. и тут я не соглашусь, но спорить не буду. Мы часто, при проектировании систем и при выборе протокола смотрим на то, какая должна быть система? Если ситема РВ, то выбираем реалтаймовый протокол, если ситема не РВ, то можем использовать любой протокол. И часто звучит "Протокол TCP/IP нам не подходит, это не реалтаймовый протокол".
5. Да там вообще все недостатки можно удалить. ещё недостаток Стандарт не регламентирует начальную инициализацию системы. Назначение сетевых адресов и прописывание в системе параметров каждого конкретного устройства выполняются вручную на этапе адаптации и программирования системы. - ну во первых у какого протокола это настраивается не в ручную? У TCP/IP? Там также в ручную прописываются мак адреса и адрес ip. Есть ещё протокол DHCP который позволяет автоматом назначить ip адреса, маски, гэйты... но это отдельный протокол. В модбусе тоже можно организовать динамическую настройку адресов. Кто мешает? Можно на лету менять сетевой адрес, скорость, битность, четность, что мы и делали в одной системе.В другой системе адреса вообще не назначались, они были жёстко привязаны к месту платы в устройстве (к слоту). Ни чего не нужно вводить на этапе адаптации системы. Да и вообще, сколько встречал промышленные узлы, мультимедийные, бытовую технику на том же TCP/IP - ВЕЗДЕ РУКАМИ НУЖНО ВВОДИТЬ IP адлрес. или хотя бы включить DHCP. Но "изкоробки" работать сеть не будет.
6. Внизу таблица Контроллеры 8250 UART • 16550 UART Драйверы MAX232 Что за бред? Опять так, для массы строки накидали? MAX232 - это драйвер RS-232, но не модбуса. А что за контроллеры? который из них модбус? Это контроллеры уарта, но не модбуса. Я не встречал в природе контроллер модбуса, но я делал такой контроллер на ПЛИС. Он сам считает црц, добавляет адрес, проверяет адрес, выявляет паузы в 3,5 и 1,5 символов. процессору практически не чего не остается делать. только данные подсовывай. Если выпускает кто такой контроллер - озвучите, интересно послушать. И эти ваши 8250 UART и MAX232 ,даже МАХ485 - это не модбус. Не нужно путать сырое с кошкой.
7. Это правильнее текущего текста но требует некоторых трудозатрат от вас. вот только не нужно выставлять меня лентяем. Это автор статьи лентяй, коли не изучив модбус пишет подобный бред и 8250 UART называет контроллером модбус. Я и так много труда вложил, чтобы обосновать, что моя правка правильная. Изучите модбус, это требует некоторых трудозатрат от вас.
   ps про недостатки, если уж вам так важен объём текста, ещё можно упомянуть, что ограничено максимальное число узлов в сети 1 ведущий и 247 ведомых. Но это скорее всего не недостаток, а ограничение. --Juvf 17:52, 6 августа 2014 (UTC)juvf

   • Читатели Википедии будут рады если вы доведете эту статью до состояния избранной. Но не забывайте о вежливости. Подавляющее большинство статей имеет не одного автора. Например эта редактировалась двумя сотнями разных авторов. Возможно, именно это усложнило для вас восприятие статьи.

   Рекомендую подтянуть познания о стеке протоколов TCP/IP и узнать что методы автонастройки IP адресов давно уже не только стандартная часть стека, но и массы гаджетов. Настолько, что большинство пользователей планшетов и мобилок вряд ли знают что такое IP адрес. Равно как и методы контроля времени доставки. И все это стандартизовано, в отличие от модбаса. Недаром Ethernet с TCP уже давно стал промышленным интерфейсом номер один, и даже модбас обзавелся портом под TCP.

   Хохмы ради замечу что в рамках стандарта модбас никак не может отвечать понятию реалтаймового. Хотя бы потому что в стандарте никак не регламентировано время ожидания ответа на запрос. Это всё «надстройки». ASDFS 19:47, 6 августа 2014 (UTC)

   
   Вы или меня не слышите или не хотите слышать, не сказать ещё хужей. Я вам в сотый раз говою что ВРЕМЯ ПЕРЕДАЧИ ИНФОРМАЦИИ ПО МОБДАСУ ВЫЧИСЛЯЕТСЯ С ВЫСОКОЙ ТОЧНОСТЬЮ. Поэтому этот протокол легко применим в РВ. Это реалтаймовы протокол. Да, время ожидания ответа не регламентировано, но оно задается, и оно зависит от времени обработки информации слейвом. Мы в своих системах это время всегда задаём. Если слейв РВ, и он гарантировано обработает запрос через 10 мс и ответит, то время ожидания ответа прогнозируемо. Это и есть РВ. Если связать РВ мастера и РВ слейва - их обмен по модбасу прогнозируем с высокой точностью. И время ожидания заранее известно. Если слэйв крутится на Вынь ХР, и слейв может то через 10 мс, то через 100 см, то через 5 сек, то такая система не РВ. И модбус тут не причем. Модбус за гарантированное время доставляет от мастера слейу запрос, и за гарантированное время доставляет от слейва мастеру ответ. Всё! Вся реалтаймовость.
   Настолько, что большинство пользователей планшетов и мобилок вряд ли знают что такое IP адрес. ггг МОБИЛОК!!! Вы ещё скажите что пользователи вконтакте врят ли знают о ip. Причем тут мобилки? Опять вы путаете сырое с кошкой. Мы с вами говорим о промышленном протоколе. У меня на столе стоит анализатор спектра подключенный к локальной сети. Чтобы он заработал через сеть, мне нужно было в ручную задать ему айпи, маску и шлюз. Но и этого не достаточно, ещё мне потребовалось сделать поход к сисадмину, чтобы тот на сервере разрешил работу в сети данному анализатору. Назовите мне станок или вакуумный выключатель, который внес в цэх или в трансформаторную подстанцию и без настроек он оказался в сети и стал виден оператору/мастеру цэха или энергодиспетчеру?
   Читатели Википедии будут рады если я или кто-то уберёт мусор из статьи. Я часть мусора убрал. Хорошо, выделю время и остальной мусор уберу.
   Возможно, именно это усложнило для вас восприятие статьи. Кто вам сказал что мне что-то усложнило восприятие статьи? Мне ни чего не усложнило. Я вижу что статья напичкана небылицами. Ни какой сложности нет. В статье написано что контроллер модбаса 8250 UART, но на самом деле 8250 UART есть контроллер UART-a, - это не значит что мне сложно воспринять статью. --Juvf 02:51, 7 августа 2014 (UTC) juvf
   • Вы сами себя загнали в угол буквоедства. Так будьте последовательны: время обмена по модбасу вообще не вычисляется, никак. Ибо этого понятия нет в стандарте. Любые оценки времени обмена - это ваши личные домыслы и ничего более, как бы точны они ни были. ASDFS 18:16, 7 августа 2014 (UTC)
   
   в какой угол? Где вы видите про время ОБМЕНА по модбасу? Какие домыслы? Вы хоть что-нибудь по теме правок сказали? Хоть на какой-нибудь мой вопрос ответили? Я убрал про периферию и очереди. Есть в мобдасе очереди и периферия? Вы можете без абстракций ответить? Если нет там периферии, то и нечего тут спорить. Убрать это из описания и точка.
   Я с лёгкостью использую это протокол в РВ. Со всеми с кем я работал, работаю, сотрудничал и сотрудничаю.... все без каких либо ограничений и трудностей используют этот протокол в СРВ.
   Вы толком ни чего не говорите а только всякие "загнали в угол буквоедства" Вы -ТРОЛЬ!
   Вы только что признали что в модбасе есть указанные недостатки. - где я признал указанные недостатки? Где я признал, что периферии приходится ждать очереди? Пруф или трепло?
   Рекомендую подтянуть познания о протоколе Modbus — Эта реплика добавлена участником Juvf (о • в) 04:24, 8 августа 2014 (UTC)

   • Мне кажется, вам надо успокоиться, перестать хамить и почитать правила Википедии, например начать вот с этого. Также Википедию не интересует ваше личное мнение и мнение ваших друзей. Чтобы вас услышали вам надо указать где именно в стандарте Модбаса даются правила вычисления времени передачи информации. Остальные ваши вопросы я увидеть не смог. ASDFS 17:43, 8 августа 2014 (UTC)

   Мне кажется, вам надо успокоиться, перестать хамить и почитать правила Википедии, например начать вот с этого. Про мои вопросы.... вопросы оканчиваются вопросительным знаком. Если вы их не видите, то вам не стоит за текстом сидеть.
   Также Википедию не интересует ваше личное мнение и мнение ваших друзей. Ну я же говорю вы троль. Это вы к чему сказали? Где вы видите мнение моих друзей? Где вы вообще видите что я говорю что-то о моих друзьях? Мои друзья слово Modbus не слышали ни когда. Моё мнение что протокол хорош. Но это моё мнение и в статью я его не предлагаю внести. Я предлагаю в статью внести описание протокола, а читатель сам решит хорош он или нет.
   где именно в стандарте Модбаса даются правила вычисления времени передачи информации. так если по 485/422/232-му интерфейсу передается информация, известен размер сообщения и скорость передачи, то это расчитывается легко. Если вам это трудно, то советую подтянуть свои знания по 232/485/422 интерфейсам. Также в документе "Modicon Modbus Protocol Reference Guide PI–MBUS–300 Rev. J" говориться "In RTU mode, messages start with a silent interval of at least 3.5 character times. This is most easily implemented as a multiple of character times at the baud rate that is being used on the network"
   Также Википедию не интересует ваше личное мнение о том, что MODBUS-решения существенно ограничивает применимость в СРВ.
   Чтобы вас услышали вам надо указать где именно в стандарте Модбаса говориться, что устройство должно ждать своей очереди в опросе периферийных устройств мастером, и что MODBUS-решения существенно ограничивает применимость в системах управления реального времени. — Эта реплика добавлена участником Juvf (о • в) 13:29, 12 августа 2014 (UTC)

   • at least переводится «как минимум». То есть максимум времени на задержку не оговаривается, оставляя на усмотрение разработчиков, а значит и вычислить его невозможно ни с какой точностью. Можно только надеяться что разработчики устройств укажут это время в своей документации, но к стандарту это уже не имеет никакого отношения.

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

   В очередной раз призываю вас вспомнить о правилах приличия, прекратить личные нападки и начать подписывать свои изречения. ASDFS 08:03, 13 августа 2014 (UTC)

   Какая задержка? Где вы видите задержку? Я вам выделил что нужно читать. Длительность 3,5 символов легко рассчитать зная baud rate. Зная размер сообщения и baud rate легко рассчитать время передачи пакета. Я вас ещё раз призываю подтянуть познания по 232/485/422 интерфейсам и по протоколу Modbus. --Juvf 12:04, 13 августа 2014 (UTC)juvf

   • Если вам все еще непонятен перевод слов at least, воспользуйтесь онлайн переводчиком. Тогда, надеюсь, вы поймете что выделенное вами никак не относится к теме. А тема, напоминаю, в следующем: Модбас не регламентирует максимальную задержку от окончания запроса мастером до начала ответа ведомым. Только минимальную и то только для RTU. ASDFS 19:00, 13 августа 2014 (UTC)

   А тема, напоминаю, в следующем: Модбас не регламентирует максимальную задержку от окончания запроса мастером до начала ответа ведомым.ггггг... Это вы только что придумали? Вы откройте новую тему, и дайте ей своё название, тогда она так и будет называться. А говорим мы с вами о том, что есть мусор в статье, есть чьи-то личные мнения о том, что модбас сложно применять в СРВ.
   Опять 25. Я с вами согласен. Модбас не регламентирует максимальную задержку от окончания запроса мастером до начала ответа ведомым. Давайте мы за это с вами спорить не будем. Точка. Я утверждаю, что МОДБАС РЕГЛАМЕНТИРУЕТ ВРЕМЯ ДОСТАВКИ СООБЩЕНИЯ ОТ МАСТЕРА ДО СЛЭЕЙВА. Также мобдас регламентирует время доставки от слэйва к мастеру. Время, необходимое слейву для обработки запроса модбас не регламентирует. Если у вас слеэйв РВ и вы знаете сколько времени потребуется слейву для обработки, то вы будете точно знать сколько времени пройдет от запроса мастера до получение ответа. В чем тут сложность? Почему здесь возникнит сложность использовать этот протокол в СРВ?
   Если вам все еще непонятен перевод слов at least, воспользуйтесь онлайн переводчиком.Ну яже говорю, вы здесь троллингом занимаетесь. Это вы мне зачем сказали? Подьеб@уть решили? Я где-то не правильно перевёл слово at least? Вы меня призываете вспомнить о правилах приличия, прекратить личные нападки, а сами продолжаете подколи всякие вкидывать (наверно ради... как вы там писали... а, вот... Хохмы ради). Перевод этого слова мне известно, только это не относится к теме. Я вам выделил то, что модбас легко рассчитывает длительность символов, а следовательно можно расчитать и интервалы в 3,5 симовлов, а также и длительность всего сообщения.
   
   Решите задачку, по СРВ: Мастер опросил слейва. Чтение одного регистра. слейву для обработки этого запроса требуется 1 мс после получения всех байт запроса. Через сколько времени мастер получит ответ при условии:
   a) мастер и слейв связан по modbus rtu(rs232), 115200 b/s, 8-bit, нет дополнений, нет чет/нечет, 1 старт, 1стоп,
   b)мастер и слейв связан по modbus tcp?
   сложно?,
   --Juvf 08:14, 14 августа 2014 (UTC)juvf

   ASDFS

   Год назад спорил с ASDFS на тему недостатков модбаса, бесполезно. Этот человек не признаёт других мнений и нарушает основные правила вики.

   Википедия — это энциклопедия, и поэтому статьи должны быть по возможности нейтральными.

   Если вы пишете статью по спорному вопросу, постарайтесь представить все известные вам точки зрения.

   По истории правки статьи эти нарушения прекрасно видны. Обсуждение на странице ASDFS.

   --78.153.133.93 07:47, 14 ноября 2014 (UTC)

   • Напоминаю: это страница обсуждения статьи а не участников. Если хотите привлечь внимание к проблеме широкого круга участников, напишите на Википедия:Форум/Вниманию участников или Википедия:Запросы к администраторам. Просьба также не отсылать к истории статьи, а развернуто излагать свою позицию, прилагая ссылки на конкретные проблемные правки в качестве аргументов. ASDFS 11:15, 14 ноября 2014 (UTC)
   • • А смысл? Вы ведь упорно не обращаете внимание на другие мнения. У многих, кто прочитал эту статью, и реально "офигел" от непрофессиональных рассуждений, просто нет времени с Вами бороться. Хоть таким образом привлечь внимание тех кто читает статью. Читатели ведь не пойдут искать по форуму или изучать историю правок, но в обсуждение заглянуть могут.

   --78.153.133.93 14:17, 25 ноября 2014 (UTC)

   Господа, ну что за спор, говорите о разных вещах. А все из-за неправильного термина, которым вы перекидываетесь. Когда мы говорим о протоколе, нужно говорить не о реальном времени, а о детерминированности. Вот детерминированный протокол позволяет заранее знать время прохождения запроса к слэйву. Однако когда мы говорим о применимости в РТ системах мы должны понимать, что нам не известно, КОГДА мастер сможет обратиться в слэйву. А обратится он к нему в порядке очереди. Например, слэйв с адресом 32 выложил в своем регистре критичную информацию,реакция мастера на которую должна наступить не позднее 1 сек. А мастер в это время опрашивает слэйв с адресом 1. Предположим, что коммуникация с каждым слэйвом занимает 100мсек. Итого, мастер не успеет опросить в заданный критичный временной интервал слэйв с адресом 32. Вот об этом и говорит топик-стартер. В других протоколах, например CAN, слэйв(точнее там нет слэйвов, скажем модуль переферии) уложится, потому как начнет передачу с высоким приоритетом,и через арбитраж пробъется к контроллеру. — Эта реплика добавлена с IP 193.19.168.163 (о) 08:47, 11 июня 2015 (UTC)

   P.S. А протокол действительно не может быть реалтайм, это свойство системы. Другое дело, что только детерминированный протокол может быть применим в РТ системах, как сказано выше это условие необходимо, но не достаточно. А насчет очередей - да, есть последовательность обращения мастера к слэйвам, это не свойство протокола, это свойство системы, построенной на этом протоколе, так сказать производное от классического подхода "мастер-слэйв". — Эта реплика добавлена с IP 37.147.83.245 (о) 04:46, 12 июня 2015 (UTC)

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

   Ещё один недостаток придумали... Для справки, автор слейва сам решает, обнаруживать это или нет. В основном не заморачиваются, но в инверторах яскавы и хитачи (думаю что и во многих других устройствах), предусмотрена настройка поведения частотника в случае потери связи с мастером. Ещё в стандарте модбаса не предусмотрена возможность мастером или слейвом баб вызвать. Это естественно является одним из главных недостатков, затрудняющих применение протокола. Испортили статью за пару лет, полезную инфу разбавили водой и домыслами. --78.153.133.93 06:25, 5 августа 2015 (UTC)

   Отсутствие прерываний - недостаток

   Был задан вопрос "Где в [7] говорится, что это недостаток?" Говорится в разделе "Drawbacks": "Requires polling architecture". Наличие других протоколов с таким же недостатком не доказывает, что это не недостаток. — SergV (обс.) 17:35, 21 апреля 2021 (UTC)