[Arlleex 131]

Modbus-RTU - это (как и много чего еще подобного на свете) перл из 80-х, а не протокол. Уж не стоит оправдывать откровенную какаху, господа, а тем более выдавать ее за фичу

[mantech 34]

В 08.06.2022 в 17:23, Arlleex сказал:

Modbus-RTU - это из 80-х, а не протокол. Уж не стоит оправдывать откровенную какаху, господа,

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

[Eddy_Em 1]

On 6/8/2022 at 8:46 PM, mantech said:

Modbus-ASCII - вот зачем это было изобретать

Между прочим, в отличие от гнилого rtu, модбас ascii значительно более логичен и удобен: есть пометки начала/конца сообщения, нет задержек. Т.е. я могу просто открыть терминал и писать/читать. А для работы с rtu придется минимум 2-3 страницы сишного кода накатать!

P.S. Абсолютно во всех моих современных железяках используется текстовый протокол (если, конечно, это не CAN). Запустил терминал, жамкнул ? или help — получил полную справку по командам, версию и дату прошивки. И работай себе. Да и парсеры несложно сделать, которые с этими данными будут работать. Понятно, что для парсера бинарный протокол был бы проще, но в таком случае не получилось бы работать человеку в терминале. Я когда-то давно еще заморачивался с бинарным протоколом, пришлось параллельно 2 протокола использовать: бинарный для парсера и символьный для человека с переключением по специальным командам. Но потом таки плюнул и стал исключительно символьный использовать. Сериализация помогает еще и с endiannes не заморачиваться.

Изменено 9 июня, 2022 пользователем Eddy_Em

[tonyk_av 31]

On 6/8/2022 at 10:46 PM, mantech said:

 И уж если на счет каках - так это Modbus-ASCII - вот зачем это было изобретать - непонятно...

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

Изменено 9 июня, 2022 пользователем tonyk_av

[Arlleex 131]

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

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

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

[Eddy_Em 1]

On 6/9/2022 at 4:39 PM, Arlleex said:

В настоящий RTU еще и без аппаратных переходников-нахлобучек не подлезть с персоналки.

Ну что за чушь? И как же у меня в этом случае сейчас метео  работает? Просто выставляешь таймаут select'а или poll'а в 3.5 кадра, да читаешь, пока не выйдет таймаут. Вышел — ОК, конец пакета. Если для чтения/записи выделить отдельный поток, то и проблем не будет даже с очень активным потоком данных.

[mantech 34]

В 09.06.2022 в 16:39, Arlleex сказал:

В настоящий RTU еще и без аппаратных переходников-нахлобучек не подлезть с персоналки.

Обычный переходник на ft232 и драйвер adm3485 - если это слишком сложные "нахлобучки" - то тут уж...

В 09.06.2022 в 15:53, tonyk_av сказал:

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

Ну так-то это М2М интерфейс, чтоб  не парсить всю эту текстовую мешанину...

[Arlleex 131]

14 часов назад, Eddy_Em сказал:

Ну что за чушь? И как же у меня в этом случае сейчас метео  работает?

Чушь - это ваша надежда на то, что я в курсе о каком-то там "метео".
 

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

Обычный переходник на ft232 и драйвер adm3485 - если это слишком сложные "нахлобучки" - то тут уж...

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

[mantech 34]

В 09.06.2022 в 21:10, Arlleex сказал:

Но лезть в промышленное оборудование с нашлепкой в виде FT232 с ее USB-шными приколами в виде недетерминированных межсимвольных интервалах - плавали, больше плавать не хотим, спасибо.

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

[Arlleex 131]

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

...но что касалось собственно протокола и таймингов - все прекрасно работало.

Везение с оборудованием и малые скорости обмена (и интервалы между запросами/ответами)

[mantech 34]

В 09.06.2022 в 21:22, Arlleex сказал:

Везение с оборудованием и малые скорости обмена

Ну везением отваливание усб особо не назовешь, но скорости были от 9600 до 115200, как по стандарту.

[Eddy_Em 1]

On 6/9/2022 at 9:10 PM, Arlleex said:

в виде недетерминированных межсимвольных интервалах

Кстати, да: сегодня наткнулся на то, что по непонятной причине иногда, как запустишь приложение, приходят битые пакеты. Видимо, если включение попадает на середину пакета, то почему-то после него select не отваливается!  Но у меня на ch341 преобразователь — ХЗ, может быть он там у себя кэширует, поэтому такая дрянь и вылезает. Но если взять честный некэширующий преобразователь, а еще лучше - подключить модбас  к RS-485 компа, то будет ОК. Просто не у всех компов есть 485: 232 есть абсолютно всегда, а вот на 485 иной раз не напрягаются. Но можно и простой преобразователь воткнуть, который к кэшированию, как микроконтроллер, не приведет.

[Arlleex 131]

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

Ну везением отваливание усб особо не назовешь, но скорости были от 9600 до 115200, как по стандарту.

Нет. Я про "везение" в реализации таймаутов и логики кадрирования в оборудовании. Если речь, разумеется, идет о подключении к оборудованию стороннего производителя, в котором реализован Modbus-RTU. В стандарте на протокол много неточностей, которые предоставляют разработчику пищу и поле для размышлений, коих даже на этом форуме набралось достаточно много, это мягко говоря...

[mantech 34]

В 09.06.2022 в 21:45, Arlleex сказал:

Если речь, разумеется, идет о подключении к оборудованию стороннего производителя, в котором реализован Modbus-RTU.

Да, такое и есть, в сети была смесь устройств собственного и китайского изготовления.

[Arlleex 131]

11 часов назад, Eddy_Em сказал:

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

Чтобы понять эти "непонятные причины", достаточно лишь вспомнить, что USB сам по себе - это интерфейс с кадр-ориентированным протоколом (по проводам бегают пакеты данных), а UART (и все что прямо на нем ездит в виде RS-485/232 и т.д.) - это байт-ориентированный интерфейс. И прямое преобразование одного в другое без допущений и компромиссов невозможно в принципе, т.к. затрагивает идеологические основы работы первого и второго. Все эти FT-шки всего лишь преобразуют байтовый поток, упакованный в кадры USB-протокола, в байтовый поток UART, и гарантировать какие-то межсимвольные gap-ы здесь невозможно в принципе (хотя бы потому, что не во всех FT-шках глубина FIFO достаточная + USB-эндпоинты - булки, хотя и другие вряд ли спасли бы ситуацию). Именно поэтому к фирмовому оборудованию FT-нашлепками не подлезть, разве что там действительно щадящая реализация RTU и она многое прощает.

Цитата

Но если взять честный некэширующий преобразователь, а еще лучше - подключить модбас  к RS-485 компа, то будет ОК.

Забудьте о "честных" таймаутах на контроллерах UART-порта на ПК. Если он на современных ПК еще и торчит там где-то сзади. Даже на драйверном уровне запрограммировать на персоналке честный RTU, который будет работать всегда, со всем оборудованием, на высоких темпах обмена и, разумеется, если комп не занят только тем что обслуживает порт и больше ничего не умеет - НЕ ПОЛУЧИТСЯ. Но можете попробовать, я не возражаю