jcxz 231 24 мая, 2023 Опубликовано 24 мая, 2023 · Жалоба 1 минуту назад, quark сказал: У вас при приеме в ПК все паузы потеряются. Хуже того - могут появиться лишние. Там не годится этот метод. Значит: Modbus-RTU в урну. И применяем что-то иное. Вот и вывод! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
quark 48 24 мая, 2023 Опубликовано 24 мая, 2023 · Жалоба 6 минут назад, Arlleex сказал: А для гарантированного отделения начала RTU-кадра передатчик должен активировать выход на определенный интервал (точных цифр не помню, но я всегда выдерживаю DE трансивера активным 2 UART-фрейма). При вашем методе "мусорной линии", к ПК, скорее всего, вообще не удастся подключиться. Постоянные сигналы "Break", которыми будет изобиловать ваш поток, могут просто "подвесить" порт. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 231 24 мая, 2023 Опубликовано 24 мая, 2023 · Жалоба 2 минуты назад, quark сказал: Постоянные сигналы "Break", которыми будет изобиловать ваш поток, могут просто "подвесить" порт. С чего бы это? BREAK нормально обрабатывается Serial WinAPI. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 173 24 мая, 2023 Опубликовано 24 мая, 2023 · Жалоба 14 минут назад, quark сказал: У вас при приеме в ПК все паузы потеряются. Хуже того - могут появиться лишние. Там не годится этот метод. Так ведь и речь о том, что на ПК сделать честный RTU нельзя. Ну, на каких-то (мб под линуксой, да на открытом железе) можно, наверное, если прям заморочиться (и то я очень сомневаюсь, т.к. на Application CPU UART-периферию вешают крайне убогую древнюю). А нам тут некоторые утверждают, что у них честный RTU принимается/отправляется через USB-RS-свистки. Ага, "честный" он до первого устройства в модбас-сети, где разработчик прям упоролся в стандарт и выполнил все обработки таймаутов четко-четко. Цитата При вашем методе "мусорной линии", к ПК, скорее всего, вообще не удастся подключиться. Постоянные сигналы "Break", которыми будет изобиловать ваш поток, могут просто "подвесить" порт. Нет. Активировать выход != установить Break. Активировать выход с установленным Idle, разумеется. Да можно и Break, не важно это, если приемник умеет находить Break. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
razrab83 21 24 мая, 2023 Опубликовано 24 мая, 2023 · Жалоба 2 минуты назад, Arlleex сказал: 14 минут назад, quark сказал: У вас при приеме в ПК все паузы потеряются. Хуже того - могут появиться лишние. Там не годится этот метод. Так ведь и речь о том, что на ПК сделать честный RTU нельзя. ну наконец то... всё! Расходимся ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 173 24 мая, 2023 Опубликовано 24 мая, 2023 · Жалоба 2 минуты назад, razrab83 сказал: ну наконец то... всё! Расходимся 😉 Про ПК я еще на 5 странице написал)) А про USB - еще раньше)) Но этот холивар поднимается не впервые и даже действующие лица - те же Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
quark 48 24 мая, 2023 Опубликовано 24 мая, 2023 · Жалоба 21 минуту назад, jcxz сказал: Значит: Modbus-RTU в урну. И применяем что-то иное. Вот и вывод! Лучше нерабочие методы - в урну! Да здравствует MODBUS! 11 минут назад, Arlleex сказал: на ПК сделать честный RTU нельзя Для "честного" MODBUS, нужен "честный" реал-тайм. Говорили уже об этом. Если "честного" реал-тайма нет, то и MODBUS будет такой же. Только "нечестным" он будет только внутри ПК. А снаружи - все будет честно. И строго по стандарту. 11 минут назад, Arlleex сказал: Ага, он "честный" он до первого устройства в модбас-сети, где разработчик прям упоролся в стандарт и выполнил все обработки таймаутов четко-четко. И с такими устройствами все будет работать Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Plain 197 24 мая, 2023 Опубликовано 24 мая, 2023 · Жалоба Цитата recommended to use a value of 750µs В переводе означает, что "стандарт" лишь до 19200. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
tonyk_av 41 24 мая, 2023 Опубликовано 24 мая, 2023 · Жалоба 22 minutes ago, razrab83 said: ну вы и описываете что-то доморощенное. Это из последнего. Бывало всякое. Попадался какой-то контроллер, у которого Ethernet был выполнен на отдельно сетевом контроллере, и чтение данных по флагу поступления новых данных по сети не означало, что прочитаешь весь пакет. Тоже приходилось собирать фрейм. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ericN 3 24 мая, 2023 Опубликовано 24 мая, 2023 · Жалоба В 24.05.2023 в 16:32, quark сказал: Для "честного" MODBUS, нужен "честный" реал-тайм. Говорили уже об этом. Если "честного" реал-тайма нет, то и MODBUS будет такой же. Только "нечестным" он будет только внутри ПК. А снаружи - все будет честно. И строго по стандарту. в одном посте противоречия. вам ПК компортом не обеспечит честного реалтайма ни на встроенных RS232, ни на встроенных RS-485, ни тем более на усб свистках. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
tonyk_av 41 24 мая, 2023 Опубликовано 24 мая, 2023 · Жалоба 2 minutes ago, ericN said: вам ПК компортом не обеспечит честного реалтайма Для этого в ПК ставят платы последовательных портов. Ни разу от таких плат не получал рваных фреймов. Есть данные- прочитал целый фрейм. Поэтому не нужно путать китайские свистки и промышленные девайсы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
quark 48 24 мая, 2023 Опубликовано 24 мая, 2023 · Жалоба 2 минуты назад, ericN сказал: в одном посте противоречия. вам ПК компортом не обеспечит честного реалтайма ни на встроенных RS232, ни на встроенных RS-485, ни тем более на усб свистках. Вы тоже тему не читаете? Отлистайте пару страниц назад, и почитайте как, в случае ПК, обеспечивается неразрывность фреймов и необходимые по стандарту межфреймовые паузы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 173 24 мая, 2023 Опубликовано 24 мая, 2023 · Жалоба Только что, quark сказал: Для "честного" MODBUS, нужен "честный" реал-тайм. Говорили уже об этом. Реалтайм для модбас? Для меня что-то новое, т.к. мне совершенно не понятно, каким боком системная архитектура связана с протоколом обмена. Я что, не могу подключиться самодельным даже USB-ModbusRTU-адаптером к нереалтаймовой винде? Могу. А необходимость якобы "реалтайма" для RTU вытекает из реализации драйверов между ОС и приложением во всех Unix-ах - там в принципе не закладывалось возможности передавать информацию о дырках между байтами на уровне, достаточном для реализации RTU. Цитата Только "нечестным" он будет только внутри ПК. А снаружи - все будет честно. И строго по стандарту. Если аппаратный UART ПК + обслуживающий его драйвер способен покрывать требования канального уровня RTU, на уровне драйвера корректно обрабатываются все таймауты модбаса, а не только один, то да, будет по стандарту. А теперь смотрим, что там за UART-ы в даже современных Application CPU, на которых строят пром. компы - ах, старый добрый дохлый 16550-совместимый, без продвинутых фич и упаси господи возможности контролить хоть какие-то таймауты. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
razrab83 21 24 мая, 2023 Опубликовано 24 мая, 2023 · Жалоба 5 минут назад, tonyk_av сказал: Для этого в ПК ставят платы последовательных портов. Ни разу от таких плат не получал рваных фреймов. я получал на передаче. пк, т.е. микроэвм была по мойму MOXA UC8410. а на приеме, вы не разделите фреймы по паузам, если только не напишете свой драйвер /dev/modbus, который задействует аппартаный UART и таймер. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 173 24 мая, 2023 Опубликовано 24 мая, 2023 · Жалоба 13 минут назад, razrab83 сказал: а на приеме, вы не разделите фреймы по паузам, если только не напишете свой драйвер /dev/modbus, который задействует аппартаный UART и таймер. После чего проблема тупо перетекает на как раз обеспечение реалтаймовости процессов обслуживания драйвера, а с учетом того, что крупные ОС таким похвастаться не могут, все таймауты будут сыпаться, как и надежды на честный RTU. Мы в своей аппаратуре всегда при наличии каких-то нестандартных, трудно интегрируемых и т.д. интерфейсов заводим их на МК/ПЛИС, который сделает все как надо. А уже от этого МК/ПЛИС кидается любой удобный интерфейс (для UART-ов это вообще сквозная линия получается) - по которому ходит протокол, удобный для любых операционок с любыми своими ограничениями, возможностями и т.д. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться