[jcxz 217]

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

У вас при приеме в ПК все паузы потеряются. Хуже того - могут появиться лишние. Там не годится этот метод.

Значит: Modbus-RTU в урну. И применяем что-то иное. Вот и вывод!  

[quark 48]

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

А для гарантированного отделения начала RTU-кадра передатчик должен активировать выход на определенный интервал (точных цифр не помню, но я всегда выдерживаю DE трансивера активным 2 UART-фрейма).

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

[jcxz 217]

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

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

С чего бы это? BREAK нормально обрабатывается Serial WinAPI.

[Arlleex 160]

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

У вас при приеме в ПК все паузы потеряются. Хуже того - могут появиться лишние. Там не годится этот метод.

Так ведь и речь о том, что на ПК сделать честный RTU нельзя. Ну, на каких-то (мб под линуксой, да на открытом железе) можно, наверное, если прям заморочиться (и то я очень сомневаюсь, т.к. на Application CPU UART-периферию вешают крайне убогую древнюю). А нам тут некоторые утверждают, что у них честный RTU принимается/отправляется через USB-RS-свистки. Ага, "честный" он до первого устройства в модбас-сети, где разработчик прям упоролся в стандарт и выполнил все обработки таймаутов четко-четко.

Цитата

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

Нет. Активировать выход != установить Break. Активировать выход с установленным Idle, разумеется. Да можно и Break, не важно это, если приемник умеет находить Break.

[razrab83 21]

 

2 минуты назад, Arlleex сказал:

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

У вас при приеме в ПК все паузы потеряются. Хуже того - могут появиться лишние. Там не годится этот метод.

Так ведь и речь о том, что на ПК сделать честный RTU нельзя.

ну наконец то... всё! Расходимся ;)

[Arlleex 160]

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

ну наконец то... всё! Расходимся 😉

Про ПК я еще на 5 странице написал)) А про USB - еще раньше)) Но этот холивар поднимается не впервые и даже действующие лица - те же

[quark 48]

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

Значит: Modbus-RTU в урну. И применяем что-то иное. Вот и вывод! 

Лучше нерабочие методы - в урну! Да здравствует MODBUS!

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

на ПК сделать честный RTU нельзя

Для "честного" MODBUS, нужен "честный" реал-тайм. Говорили уже об этом. Если "честного" реал-тайма нет, то и MODBUS будет такой же.
Только "нечестным" он будет только внутри ПК. А снаружи - все будет честно. И строго по стандарту.

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

Ага, он "честный" он до первого устройства в модбас-сети, где разработчик прям упоролся в стандарт и выполнил все обработки таймаутов четко-четко.

И с такими устройствами все будет работать

[Plain 188]

Цитата

recommended to use a value of 750µs

В переводе означает, что "стандарт" лишь до 19200.

[tonyk_av 39]

22 minutes ago, razrab83 said:

ну вы и описываете что-то доморощенное.

Это из последнего. Бывало всякое.

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

[ericN 3]

В 24.05.2023 в 16:32, quark сказал:

Для "честного" MODBUS, нужен "честный" реал-тайм. Говорили уже об этом. Если "честного" реал-тайма нет, то и MODBUS будет такой же.
Только "нечестным" он будет только внутри ПК. А снаружи - все будет честно. И строго по стандарту.

в одном посте противоречия. вам ПК компортом не обеспечит честного реалтайма ни на встроенных RS232, ни на встроенных RS-485, ни тем более на усб свистках. 

[tonyk_av 39]

2 minutes ago, ericN said:

вам ПК компортом не обеспечит честного реалтайма

Для этого в ПК ставят платы последовательных портов. Ни разу от таких плат не получал рваных фреймов. Есть данные- прочитал целый фрейм. Поэтому не нужно путать китайские свистки и промышленные девайсы.

[quark 48]

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

в одном посте противоречия. вам ПК компортом не обеспечит честного реалтайма ни на встроенных RS232, ни на встроенных RS-485, ни тем более на усб свистках. 

Вы тоже тему не читаете?
Отлистайте пару страниц назад, и почитайте как, в случае ПК, обеспечивается неразрывность фреймов и необходимые по стандарту межфреймовые паузы.

[Arlleex 160]

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

Для "честного" MODBUS, нужен "честный" реал-тайм. Говорили уже об этом.

Реалтайм для модбас? Для меня что-то новое, т.к. мне совершенно не понятно, каким боком системная архитектура связана с протоколом обмена.

Я что, не могу подключиться самодельным даже USB-ModbusRTU-адаптером к нереалтаймовой винде? Могу. А необходимость якобы "реалтайма" для RTU вытекает из реализации драйверов между ОС и приложением во всех Unix-ах - там в принципе не закладывалось возможности передавать информацию о дырках между байтами на уровне, достаточном для реализации RTU.

Цитата

Только "нечестным" он будет только внутри ПК. А снаружи - все будет честно. И строго по стандарту.

Если аппаратный UART ПК + обслуживающий его драйвер способен покрывать требования канального уровня RTU, на уровне драйвера корректно обрабатываются все таймауты модбаса, а не только один, то да, будет по стандарту.

А теперь смотрим, что там за UART-ы в даже современных Application CPU, на которых строят пром. компы - ах, старый добрый дохлый 16550-совместимый, без продвинутых фич и упаси господи возможности контролить хоть какие-то таймауты.

[razrab83 21]

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

Для этого в ПК ставят платы последовательных портов. Ни разу от таких плат не получал рваных фреймов.

я получал на передаче. пк, т.е. микроэвм была по мойму MOXA UC8410. а на приеме, вы не разделите фреймы по паузам, если только не напишете свой драйвер /dev/modbus, который задействует аппартаный UART и таймер. 

[Arlleex 160]

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

а на приеме, вы не разделите фреймы по паузам, если только не напишете свой драйвер /dev/modbus, который задействует аппартаный UART и таймер. 

После чего проблема тупо перетекает на как раз обеспечение реалтаймовости процессов обслуживания драйвера, а с учетом того, что крупные ОС таким похвастаться не могут, все таймауты будут сыпаться, как и надежды на честный RTU.

Мы в своей аппаратуре всегда при наличии каких-то нестандартных, трудно интегрируемых и т.д. интерфейсов заводим их на МК/ПЛИС, который сделает все как надо. А уже от этого МК/ПЛИС кидается любой удобный интерфейс (для UART-ов это вообще сквозная линия получается) - по которому ходит протокол, удобный для любых операционок с любыми своими ограничениями, возможностями и т.д.