[razrab83 19]

  

13 часов назад, mantech сказал:

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

modbus rtu отличный протокол. мне нравится. выделение пакетов по паузам на МК - как 2 пальца об асфальт. Но тут спор не за modbus rtu в контроллере, а modbus rtu в ПК. выделение пакетов на ПК по паузам - пока ни кто не смог. Даже quark , топит за модбас, и не замечает как Федьку по матери величает периодически сам себе противоречит. то он пишет

17 часов назад, quark сказал:

17 часов назад, Ruslan1 сказал:

RTU в PC работает с кучей оговорок.

Работает точно по стандарту без всяких оговорок. С любыми стандартными устройствами.

то он пишет оговорки, типа

16 часов назад, quark сказал:

Для таких вещей MODBUS не очень подходит. При совместой работе внешних устройств с ПК в качестве мастера, его сфера применения - удаленная настройка устройств

то он пишет "Работает точно по стандарту" (т.е. по стандарту, значит выделение пакета по паузе), то он пишет "У вас при приеме в ПК все паузы потеряются."

 

15 часов назад, quark сказал:

MODBUS-RTU, COM-порт, RS-485 периодически "хоронят" приверженцы более "прогрессивных" технологий.

ни кто его не хоронит. Действительно, на МК его реализовать не сложно. Для очень мелких МК он самое то. эти всякие ваши стеки LwIP и т.п. просто не зайдут в 8 кб флеша (а то и меньше). очень часто используем modbus rtu. заходим на объект, там куча автоматики (всякие счетчики, регуляторы, реле, датчики....), почти у всех есть modbus rtu. ставим свой контроллер. по modbus rtu всех опрашиваем и контролируем работу объекта. диспетчеру/оператору по радиоканалу/tcp скидываем информацию о состоянии всего объекта. Но в радиоканале/tcp протокол уже другой. уже нет такого интенсивного обмена. Да даже если надо напрямую в этот ваш ОРС (госсспади, прости меня за это слово) прокинуть инфу... т.е. дать удаленному ПК ПРЯМОЙ доступ к конечному датчику и почитать регистры датчика - прокинем через tcp modbus. Но ни как не rtu. modbus rtu - это удел низкоуровневой автоматики, МК. Пихать его в ПК - это геморрой.

Конечно, мы также приезжаем на объект, напрямую тычемся ноутом через китайский эфтидиайный usb-свисток в шину и прямо через modbus rtu что-то там налаживаем. Прочитать/записать регистр... или на столе, до монтажа, сконфигурировать электросчетчик, да ещё и штатной виндовой утилитой - почему бы нет. 9600 (или 115200) по дефорлту, черепаший темп... всё записалось. Но делать мастером ПК в работающей системе... modbus rtu не для этого предназначен. 

Изменено 25 мая, 2023 пользователем razrab83

[ericN 3]

В 24.05.2023 в 20:21, tonyk_av сказал:

Хотя бы парочку примеров можно? Штоб с доками, с ОРС-сервером.

что то вы зациклились на ОРС. Да кому он нужен, этот ваш ОРС? Вот вам парочка, куда более лучших протоколов для ОРС и для систем телемеханики: МЭК-101 и МЭК-104.

[quark 48]

3 часа назад, razrab83 сказал:

  ... тут спор не за modbus rtu в контроллере, а modbus rtu в ПК. выделение пакетов на ПК по паузам - пока ни кто не смог. Даже quark , топит за модбас, и не замечает как периодически сам себе противоречит...

В этой теме, похоже, уже стало "стандартом" не читать, что пишет оппонент. А если читать, то даже не пытаться разобраться в написанном. Ладно. Попробую еще раз. По пунктам:

1)Когда устройство является ведомым, то оно может наблюдать на линии поток фреймов - как ведущий обменивается информацией с другими ведомыми. Ему необходимо выделять все фреймы из потока и анализировать их, чтобы не пропустить обращение ведущего непосредственно к данному устройству. В этом случае, выделение фреймов производится путем анализа пауз.

2)Когда устройство является ведущим, то ни какого "стороннего" потока фреймов на линии, принципиально, быть не может. Прямой обмен информацией между ведомыми устройствами, без участия ведущего, этот протокол запрещает. Весь поток создается только при непосредственном участии ведущего. Ведущий отправил Запрос устройству - устройство отправило Ответ. Все. Ни каких других вариантов протокол не разрешает. Поэтому, у ведущего нет задачи выделять какой-то фрейм из какого-то "мифического" потока, путем анализа пауз.

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

4)Ведущее устройство (ПК) должно выдерживать все требования протокола по допустимым паузам при отправке запроса ведомому:
- Допустимая пауза внутри фрейма обеспечивается "неразрывностью" пакета запроса при его передаче драйвером. Это достигается правильной настройкой буферов ввода/вывода и ограничением максимальной длины запроса в управляющей программе ведущего.
- Межфреймовая пауза между окончанием приема очередного ответа и отправкой очередного запроса от ведущего выдерживается, непосредственно, управляющей программой ведущего. При передаче, реальная пауза может увеличиться из-за возможных задержек (иногда значительно), однако, она всегда будет не менее программно отработанной. То есть, в полном соответствии со стандартом.

Итог: Любые внешние устройства, использующие протокол MODBUS, могут быть подключены, качестве ведомых устройств, к ПК как ведущему устройству. Все они будут корректно работать без каких-либо ограничений.

[_3m 4]

10 минут назад, quark сказал:

2)Когда устройство является ведущим, то ни какого "стороннего" потока фреймов на линии, принципиально, быть не может. Прямой обмен информацией между ведомыми устройствами, без участия ведущего, этот протокол запрещает. Весь поток создается только при непосредственном участии ведущего. Ведущий отправил Запрос устройству - устройство отправило Ответ. Все. Ни каких других вариантов протокол не разрешает. Поэтому, у ведущего нет задачи выделять какой-то фрейм из какого-то "мифического" потока, путем анализа пауз.

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

4)Ведущее устройство (ПК) должно выдерживать все требования протокола по допустимым паузам при отправке запроса ведомому:
- Допустимая пауза внутри фрейма обеспечивается "неразрывностью" пакета запроса при его передаче драйвером. Это достигается правильной настройкой буферов ввода/вывода и ограничением максимальной длины запроса в управляющей программе ведущего.
- Межфреймовая пауза между окончанием приема очередного ответа и отправкой очередного запроса от ведущего выдерживается, непосредственно, управляющей программой ведущего. При передаче, реальная пауза может увеличиться из-за возможных задержек (иногда значительно), однако, она всегда будет не менее программно отработанной. То есть, в полном соответствии со стандартом.

Итог: Любые внешние устройства, использующие протокол MODBUS, могут быть подключены, качестве ведомых устройств, к ПК как ведущему устройству. Все они будут корректно работать без каких-либо ограничений.

Заблуждаетесь по большинству пунктов относящихся к ведущему устройству.
По 2):
Линия RS485 в состоянии покоя когда все передатчики выключены болтается в Z состоянии и на неё влияет наводка. Для ведущего это выглядит как непрерывный поток мусорных символов. Этот поток прекратится когда ведомый в ответ на запрос включит передатчик и в течение 3.5T обеспечит тишину удерживая шину в Idle. Это время ведущий должен распознавать при честной реализации протокола RTU что для ПК со стандартным оборудованием невозможно. Работает все исключительно за счет растяжек но это кривой костыль который сильно снижает устойчивость к помехам по сравнению с "честной" реализацией. О распознавалии интервала 1.5T ведущим даже речи нет потому что это недостижимо в принципе.

По 4):
Неразрывность пакета не гарантируется вообще при использовании переходников USB-UART. При использовании внутренних портов неразрывность как правило есть но это опять же ничем не гарантируется.

Межфреймовые паузы перед отправкой запроса обеспечивается а между окончанием запроса и началом приема ответа - нет. Там тоже надо 3.5T причем это время нужно выдержать точно иначе потеряем начало ответа если ведомый ответит быстро.

 

Таким образом из за ограниченности стандартного оборудования и драйверов критически важные положения протокола RTU никаким образом не могут быть реализованы если ведущее устройство ПК или SOC с линуксом. (внутри SOC большинство чипмейкеров пихают говно мамонта - 16550 UART и еще прерывание по transmit complete не подключают).

[tonyk_av 36]

3 hours ago, ericN said:

Да кому он нужен, этот ваш ОРС?

Всем, кто использует СКАДА.

3 minutes ago, _3m said:

Линия RS485 в состоянии покоя когда все передатчики выключены болтается в Z состоянии и на неё влияет наводка

Это с какого перепугу она вдруг стала болтать в воздухе? Обычно есть растяжка, некоторые оставляют на плате места под дополнительные резисторы.

10 minutes ago, _3m said:

При использовании внутренних портов неразрывность как правило есть но это опять же ничем не гарантируется.

Выше приводил пример платы с FIFO на 256 байт.

[tonyk_av 36]

18 minutes ago, _3m said:

Межфреймовые паузы перед отправкой запроса обеспечивается а между окончанием запроса и началом приема ответа - нет

Так ведь по паузе в 3.5 символа слэйв и определяет окончание запроса. Разве нет?

19 minutes ago, _3m said:

Там тоже надо 3.5T причем это время нужно выдержать точно иначе потеряем начало ответа если ведомый ответит быстро.

Быстро- это сколько? Слэйв начнёт отвечать не раньше, чем через 3.5 символа.

[quark 48]

25 минут назад, _3m сказал:

По 2):
Линия RS485 в состоянии покоя когда все передатчики выключены болтается в Z состоянии и на неё влияет наводка.

В реальности, только отдельные "'эстеты" используют "мусорные линии", болтающиеся в воздухе. Все остальные используют защитное смещение.

25 минут назад, _3m сказал:

По 4):
Неразрывность пакета не гарантируется вообще при использовании переходников USB-UART. При использовании внутренних портов неразрывность как правило есть но это опять же ничем не гарантируется.

Гарантия в 100% не нужна. В реальности, при правильной настройке - "разрыв" происходит очень редко. Штучные случаи.
Это не страшно - устройство не ответит и мастер повторит запрос, не получив ответа.

25 минут назад, _3m сказал:

Межфреймовые паузы перед отправкой запроса обеспечивается а между окончанием запроса и началом приема ответа - нет. Там тоже надо 3.5T причем это время нужно выдержать точно иначе потеряем начало ответа если ведомый ответит быстро.

Межфреймовая пауза между окончанием запроса и началом ответа обеспечивается ведомым устройством, которое работает по стандарту. Эта пауза принципиально не контролируется ведущим, за ненадобностью. Уже объяснял почему. Контроль нужен только на максимальную паузу, чтобы решить, что устройство уже не ответит.

26 минут назад, _3m сказал:

Таким образом из за ограниченности стандартного оборудования и драйверов критически важные положения протокола RTU никаким образом не могут быть реализованы если ведущее устройство ПК или SOC с линуксом.

Неверный вывод. Все стандартные ведомые устройства будут работать. Для них все будет строго по стандарту. А как все устроено в ПК - их не касается.

[tonyk_av 36]

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

[ericN 3]

В 25.05.2023 в 12:50, tonyk_av сказал:

Всем, кто использует СКАДА.

ну я так и сказал - "да кому нужен эта ваш ОРС". Т.е. никому. Или почти ни кому.

Вы наверно варитесь в соку телемеханики... скады, орс и т.п. Почет и уважение. Успехов вам в работе. Но кто ещё? ОРС нужен далеко и очень очень далеко не всем, кто занимается разработкой систем автоматики. Когда я работал в компании, которая разрабатывала свою систему телемеханики по радиоканалу, то мы писали свою скаду. ни каких ОРС не было. С каким зоопарком приборов только не стыковались, какие протоколы только не поднимали... и стандартные, и проприаритарные, и вообще неизвестные, а "хакнутые", и ни каких ОРС в помине....  

 

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

ну и чтобы в этой теме по поводу совместимости протокола с ОРС поставить точку - читаем ТЗ от ТС. Ни каких упоминаний об ОРС нет.  

Изменено 25 мая, 2023 пользователем ericN

[jcxz 199]

53 минуты назад, tonyk_av сказал:

Так ведь по паузе в 3.5 символа слэйв и определяет окончание запроса. Разве нет?

И вся печалька в том, что мастер на win-ПК (как уже выяснили в этом топике ранее) в общем случае - не может обеспечить отсутствие непредусмотренных разрывов в своём пакете. А значит и слэйв в общем случае не сможет корректно принять запрос от мастера. И другие слэйвы - тоже не смогут определить границы кадра.

Такое точно будет происходить в случаях, если COM-порт на мастере реализован на базе USB-CDC-свистка. Возможно - и в других случаях тоже будут такие непредусмотренные разрывы.

1 час назад, quark сказал:

Итог: Любые внешние устройства, использующие протокол MODBUS, могут быть подключены, качестве ведомых устройств, к ПК как ведущему устройству. Все они будут корректно работать без каких-либо ограничений.

Ложь!

см. выше.

[razrab83 19]

1 час назад, quark сказал:

- Допустимая пауза внутри фрейма обеспечивается "неразрывностью" пакета запроса при его передаче драйвером. Это достигается правильной настройкой буферов ввода/вывода и ограничением максимальной длины запроса в управляющей программе ведущего.

 

1 час назад, quark сказал:

Контролировать соблюдение этих пауз, при приеме ответа, в  программе ведущего на ПК - невозможно и не нужно.

 

16 минут назад, quark сказал:

В реальности, при правильной настройке - "разрыв" происходит очень редко. Штучные случаи.

вот куча противоречий.....

1. вот у вас ПК есть мастер. Состряпали ПО на ПК.... винда... воткнули usb-485 свисток.... подождали минутку - увидели сообщение "Xi Me Chao готово к использованию как COM23". Что там про настройку буфера ввода/вывода? 

2. "ограничением максимальной длины запроса в управляющей программе ведущего" - ухты!!! это как? пакет не более 10 байт? а это разве не Modbus с "оговоркой"? вы подключили стороннее устройство, а ему нужно 120 регистров обновить. вы их будете делить на пакеты по 10 байт и писать по 2-3 регистра? а это разве не Modbus с "оговоркой"?

3. "Гарантия в 100% не нужна." - не, ну если 100% гарантия не нужна, то расходимся.

26 минут назад, quark сказал:

Гарантия в 100% не нужна. В реальности, при правильной настройке - "разрыв" происходит очень редко. Штучные случаи.
Это не страшно - устройство не ответит и мастер повторит запрос, не получив ответа.

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

[mantech 38]

Только что, razrab83 сказал:

3. "Гарантия в 100% не нужна." - не, ну если 100% гарантия не нужна, то расходимся.

Тоже не надо так с плеча. 100% гарантия - требование для объектов повышенной опасности и критически важных. Если у вас что-то простенькое, то можно и немного понизить планку, все-таки винда и линукс - это ОС для бытовых настольных ПК, не гарантирующие такие требования, НО т.к. в модбасе заложена проверка по КС, то ничего страшного не произойдет, если 1 из 100 пакетов придет с ошибкой, то же самое может случится на суперпупер надежном ПЛК, просто помеха в линии, так что, если программа на ПК написана максимально корректно, то все будет норм...

А по правилам, конечно нужен нормальный ПЛК в качестве мастера.

5 минут назад, razrab83 сказал:

Но если вы ПК делает мастером в работающей системе - то тут слейв не ответил, мастер принял решение что слейт умер и вывел его из опроса. 

Эт где такие требования, что после одного опроса и сразу из списка? А если помеха, тогда что? Чет тут явно что-то мутное...

[quark 48]

15 минут назад, jcxz сказал:

Ложь!

Ответ себе вы сами уже написали:

20 часов назад, jcxz сказал:

Пи$%^ть - не мешки ворочать!  

[jcxz 199]

13 минут назад, mantech сказал:

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

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

Холодильник и сортир ведь - не "объекты повышенной опасности". Подумаешь - мимо толчка промахнулись!    И мясо с молоком в холодильнике протухло. Надо же понимать, что там не совсем modbus, а что уж получилось. В сортире и подтереть можно, и за мясом новым в магаз сгонять.

 

Вам как - понравится такое? Классный "умный дом"?

[tonyk_av 36]

18 minutes ago, jcxz said:

мастер на win-ПК (как уже выяснили в этом топике ранее) в общем случае - не может обеспечить отсутствие непредусмотренных разрывов в своём пакете

Может. Я же приводил ссылки на платы последовательных интерфейсов с FIFO в 256 байт. Специально сделано, чтобы передавать без разрывов.