[razrab83 21]

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

А при том, что раз делается устройство используемое в какой-то системе управления и/или мониторинга, то вопрос интеграции этого девайса с другими стоит не на последнем месте.

оно не то что стоит на последнем месте, оно не стоит не на каком месте, от слова совсем. Сколько за карьеру было сделано мной систем... в скольких учавствовал... и скаду свою писали, и кучу АСКУЭ всяких делали... свои эл.счетчики, водосчетчики... И Modbus был, и МЭК-104, и куча Проприетарных протоколов. И даже был сторонний датчик ветра, на который не было описание протокола - сами его реинженерили. Сколько автоматики для себя наделал.... ОРС даже на горизонте не было. 

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

документации внятной нет

на мои протоколы документация более внятная, чем на Modbus. Протокол пишется с описания. Через 1-2 мес я уже сам его забуду. Даже так - вышел из офиса и забыл свой же протокол. Зачем помнить константы. Единственное что помню - описание лежит там и называется так. После хорошего описания и сам ошибок не наделаешь и тот, кто будет сопрягаться мне ни одного вопроса не задаст, не будет отвлекать. 

 

ps был случай.... купили датчик ветра. по RS232 его можно читать. Описания протокола нет. Звоним на завод изготовитель:

-А можно описание протокола?

-А его нет.

-А как ваша программа на ПК с ним работает?

-А её написал один инженер и уволился. исходников нет. описания протокола нет.

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

[tonyk_av 45]

6 minutes ago, razrab83 said:

и скаду свою писали, и кучу АСКУЭ всяких делали... свои эл.счетчики, водосчетчики...

Никогда не понимал, зачем повторять то, что уже сделано? Тратить на это время? Мне своей жизни на такую фигню жалко.

7 minutes ago, razrab83 said:

ОРС даже на горизонте не было

Если СКАДА "из коробки" поддерживает Модбас, то, да, ОРС не нужен.

8 minutes ago, razrab83 said:

Описания протокола нет

Вот поэтому устройства со стандартными протоколами не требуют его описания. Достаточно в характеристиках указать поддерживаемый протокол(ы). И всё.

[Михась 4]

Да да, подключали один прибор с самописным протоколом. Что, пишутся в базу сбойные значения с него иногда. Потом выяснилось что гениальный разработчик протокола сделал так. Например есть поле команды 01 - запись значения. При этом проверяется КС фрейма. А если например 11 - то запись значения проводится без проверки КС.  И эту ахинею разработчики пропихивали как удобство и лучшесть  протокола.

[mantech 53]

31 минуту назад, ericN сказал:

Пруф?

Прямь сейчас не вспомню, но в посл. документе, который я видел было сказано "Modbus-устройство обязательно должно поддерживать скорости обмена 9600 бит/с и 19200 бит/с, из них 19200 бит/с устанавливается "по умолчанию""

Т.е это рекомендованные скорости, остальные выбираете на свой страх и риск...

[ericN 3]

В 24.05.2023 в 13:38, tonyk_av сказал:

Стандарт пробовали читать?

пробовал. а вы пробовали? Что это за фотошопная картинка? "Пруф" - это Proof link. Извините за сленг. Префразирую: Кто может поделиться трушной рабочей ссылкой на текущиый действующий стандарт протокола Modbus, в котором есть ограничение на битрейт?

 

А вы пробовали прочитать то, что я дал в ссылках? Вы мне дали картинку неизвестного документа (на картинке нет заголовка документа), датированного от 12 фев 2002 (или 2 дек 2002). В моей ссылке "MODBUS APPLICATION PROTOCOL SPECIFICATION V1.1b3" от 26 апреля 2012г. Там такой картинки нет. Ещё на модбас.орг есть "Modicon Modbus Protocol Reference Guide PI–MBUS–300 Rev. J" в котором описано 3.5 и 1.5, но там тоже нет таких ограничений на битрейт. Я не спорю, может они и есть, а может были... но сейчас актуальная спецификация - 26.04.12. Не свежая, но тем не менее это не 2002. От куда ноги растут в ограничение 19200? Более того, в текущей спецификации есть 

Цитата

 

MODBUS is an application layer messaging protocol for client/server communication between devices connected on different types of buses or networks.

It is currently implemented using:

 TCP/IP over Ethernet. See MODBUS Messaging Implementation Guide V1.0a.

 Asynchronous serial transmission over a variety of media (wire : EIA/TIA-232-E, EIA-422, EIA/TIA-485-A; fiber, radio, etc.)

 MODBUS PLUS, a high speed token passing network.

 

Показать  

fiber - вот это точно не моё поле... но по оптики тоже ограничение 19200?

 

[jcxz 242]

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

В итоге разрабов слейвов заставили убрать контроль 1.5. Перешли на нечестный Modbus.

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

Я это всё к тому, что тащить Modbus в ПК - это геморрой. Если Modbus тащится для того, чтобы "быть как все", т.е. что-бы в будущем было сопряжение с другими, то нужно его делать честным. Если он не честный, то могут быть проблемы с сопряжение др. устройств. Если др. устройства разрабатывает сосед по офису, то он может "вам пойти на встречу". А если это какая нить санкционочка - то .....

И надо помнить, что даже если сегодня "сосед пошёл вам навстречу", то завтра может прилететь совсем с неожиданного направления. Скажем: разработали вы сложный аппаратно-программный супер-мега-комплекс, потратили на него кучу времени и денег. Но протокол он реализует не совсем честно. Так как "соседи" (разработчики его компонентов) работают в одной конторе, на один результат и "пошли навстречу" другу другу.

Но вот вы выходите на рынок с сим девайсом. А рынок - это не ваша контора, где все друг с другом - вась-вась, это - страшный лес с волками злой внешний мир с конкурентами. Ваш девайс - это кость в горле конкурентам. В мануале девайса прописано, что он работает в протоколе таком-то. И даже сертификатик соответствия протоколу вы заблаговременно прикупили. Естественно - что делают волки чтобы вас съесть конкуренты чтобы вас вытеснить с рынка? Они втихаря покупают ваш супер-мега-комплекс и самостоятельно тестируют его на соответствие вашим заявленным сертификатам соответствия протоколу. Находят несоответствие протоколу и выкладывают результаты тестирования на общее обозрение. И в результате - вы проигрываете крупный тендер, в условиях которого заявлено требование обязательного соответствия данному протоколу.  

Дружелюбные соседи, "пошедшие друг другу навстречу", оказываются без зарплаты.  Занавес...

 

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

[razrab83 21]

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

Никогда не понимал, зачем повторять то, что уже сделано? Тратить на это время? Мне своей жизни на такую фигню жалко.

ни когда не понимал, зачем писать MS Word, когда есть OpenOffice? Зачем писать дельта-дизайн, когда есть альтиум и eagle? Зачем писать ВК, когда есть фэйсбук? Зачем писать воцап, когда есть вайбер? На такую фигню жизни жалко. ))

Делали своё железо, по него делали свою скаду, со своим блекджетом и девушками. Продовалось и железо и скада. Что в этом плохово?

[jcxz 242]

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

Так всё-таки есть? Пусть и не во всех фреймах?

Вы путаете канальный уровень Modbus-RTU с более высокими уровнями. На канальном уровне (уровне выделения кадров Modbus-RTU из происходящего на линии) длины кадра нет. Да она там и не нужна. Так как выделение кадров базируется на межбайтовых дырках.

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

И насколько лучше будет получившийся протокол в сравнении с Модбас? Смысл городить свой протокол ради экономии пары-тройки байт на фоне 256?

Модбас- это стандарт, хорошо документированный и поддержанный

...который вы похоже не читали.  Раз рассуждаете о некоей "длине кадра". Или предлагаете что-то там докостылить в него.

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

В MODBUS полная длина пакета (запроса или ответа) - известна заранее.

Известна заранее приёмнику???  Это откуда это? И зачем тогда вообще этот пакет передавать, если он уже "известен заранее"?

2 часа назад, mantech сказал:

А ничего, что заявленный битрейт почти в 10 раз больше, чем макс по стандарту модбаса?

В урну тогда его!   Нормальные SLIP/COBS не накладывают никаких ограничений на скорость. Как и вообще а времянки.

[razrab83 21]

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

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

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

[quark 48]

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

Известна заранее приёмнику???  Это откуда это? И зачем тогда вообще этот пакет передавать, если он уже "известен заранее"?

Не пакет известен заранее, а его длина. Не передергивайте!
Хорошо, уточню. Длина становится известна после приема первых байт пакета.
Этого достаточно.

[ericN 3]

уважаемые пассажиры этой темы, что там с пруфами на 19200? Просто не охото при разработке очередного честного модбас устройства попасть в просак и проигнорировать требование в битрейт 19200. 

Если пруфов нет, то приходим к общему мнению, что на сегодняшний день такого ограничения нет?

[jcxz 242]

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

Допустим имеем FT232 мост, который имеет 256 байт буфер ФИФО на передачу, а нам нужна именно передача, мы формируем пакет модбаса на передачу, не более размера буфера, т.е. до 256 байт длиной. Какой смысл драйверу разрывать этот пакет? Ну если не принципиально там сделан корявый драйвер и он вместо того, чтобы выдать одной булкой эти 256 байт, будет их делить на 8 например и толкать в течении секунды??

да уж... "Разработчик собственных USB-стеков"....  

Откройте уже наконец-то дескриптор этого самого FT232, посмотрите на размер его энд-поинтов. А размер их == 64 байт. Я уже писал об этом, но что-то всё без толку....    А значит - заполнить всё TX-FIFO одним чохом - никак не получится.

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

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

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

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

Не пакет известен заранее, а его длина. Не передергивайте!
Хорошо, уточню. Длина становится известна после приема первых байт пакета.
Этого достаточно.

И как определить где у пакета "первые байты", а где - последние? Не зная его границ.

[razrab83 21]

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

Хорошо, уточню. Длина становится известна после приема первых байт пакета.

ну анализировать первый попавшийся байт - это тоже не торт. приняли вы первый байт - тут должен быть адрес. Если пакет без ошибки - то это адрес. Приняли второй. Если пакет без ошибки - то это функция... но вот только есть там ошибка или нет, вы поймете только после расчета CRC (не берём во внимание паузы в 1.5). Как так? вы уже анализируете пакет не проверив его целостность. Вам отправили 200 байт одним пакетом. вы приняли второй байт с ошибкой и ошибочно определили длину пакета допустим в 7 байт. у вас crc не совпало. игнорим. приняли 8-ой и 9-ый байт - для вас это новый адрес и функция. Но это ещё первый пакет. вы запускате новый вычисление нового пакета - упс, там тоже crc не совпал. В счетчике пакетов девайс отметит "Получил 10 пакетов, из них 10 с ошибкой". А на самом деле был один пакет и он с ошибкой. как можно анализировать пакет, если ты не знаешь про его целостность?

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

Ошибаетесь.

нет, не ошибаюсь. в даyном случае в тендере на оборудование не было ни каких требований к стандарту протокола. Да и этого протокола как такого не было... он родился спонтанно... просто решили сделать межплатный обмен на Modbus. Было требование, допустим, измерять влажность и включать насос. Было бы это один МК или Два... шкаф или ящик... внутри CAN или RS485. сколько плат и как они сопрягаются - вообще таких требований не стояло. Делай хоть на ПЛИС, хоть на МК, хоть на MOXA, хоть на паровом двигателе... Главное чтобы обеспечить внешние измерения, внешние воздействие и индикацию. А как ты там обеспечил межплатный обмен - это ни кого не интересует. 

[tonyk_av 45]

42 minutes ago, ericN said:

Префразирую: Кто может поделиться трушной рабочей ссылкой на текущиый действующий стандарт протокола Modbus

Внизу на картинке указан адрес сайта.

45 minutes ago, ericN said:

на текущиый действующий стандарт протокола Modbus, в котором есть ограничение на битрейт?

Меня явно с кем-то путают. Такого я не утверждал, да и не мог, потому что в стандарте нет ограничений на скорость. Есть рекомендации использовать скорости из стандартного ряда, но запретов нет.

33 minutes ago, jcxz said:

...который вы похоже не читали.  Раз рассуждаете о некоей "длине кадра".

Вообще-то, максимальная длина фрейма явно прописана.

17 minutes ago, jcxz said:

И как определить где у пакета "первые байты", а где - последние? Не зная его границ.

Типично, когда слэйв начинает приём какого-то кадра в его середине. И что страшного? Ошибочность частично принятого фрейма определяется очень просто, зато точно становится известно начало следующего.

[quark 48]

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

Как так? вы уже анализируете пакет не проверив его целостность.

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