[Plain 212]

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

Разумеется)))

Т.е. нет? Три рта — сарказм?

[jcxz 236]

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

Сссылку на модбас?)))  И при чем тут интерфейс и протокол?

При том, что не всякий модбас через произвольный последовательный канал гарантированно работать станет.

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

 "USB <-> usb/uart <-> uart/485" - это просто переходник с одного интерфейса на другой, протокол там может быть и модбас и просто набор символов...

А ничего, что такой переходник не гарантирует повторяемость границ пакетов с двух своих концов?

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

Преобразователи, во всяком случае PL-2303, имеют пренебрежимо малую задержку при преобразовании, поэтому Модбас работает стабильно.

Речь не о задержке, причём тут она? Где в описании таких преобразователей гарантируется, что интервалы между символами с одной стороны будут повторены на другой стороне? Да и как это в принципе возможно, если с одной стороны (USB) - пакетный обмен, с другой - поток байт?

Что будет если со стороны UART послать скажем 70 байт сплошным пакетом (по UART-у пришёл пакет Modbus RTU)? При условии, что USB - это USB FS? В каком виде оно придёт драйверу USB CDC?

Или в обратную сторону: как USB-CDC host-у послать кадр размером 70 байт в протоколе "Modbus RTU"?

 

PS: Через такой преобразователь гарантированно будет работать только "Modbus ASCII". Который собственно и есть "что-то текстовое" (c) mantech. Вот отсюда и "при том тут интерфейс и протокол".

Но "Modbus ASCII" безнадёжно проигрывает по эффективности тому же COBS.  

[mantech 49]

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

А ничего, что такой переходник не гарантирует повторяемость границ пакетов с двух своих концов?

Совсем ничего, т.к. именно такой переходник и работает у меня на модбасе уже не один год, между ПК и контроллером.

ЗЫ. Пролификом и подобным уг никогда не пользовался и никому не советую, только FT232.

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

PS: Через такой преобразователь гарантированно будет работать только "Modbus ASCII".

Никогда не пользовался этим извратом, только RTU!

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

Т.е. нет? Три рта — сарказм?

Просто никогда б не подумал, что есть какие-то совместимые и несовместимые уарты для модбаса)))  Вот для 9и битных посылок да, есть такие...

Изменено 21 мая, 2023 пользователем mantech

[jcxz 236]

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

Никогда не пользовался этим извратом, только RTU!

Почему тогда не ответили на вопросы?:

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

Что будет если со стороны UART послать скажем 70 байт сплошным пакетом (по UART-у пришёл пакет Modbus RTU)? При условии, что USB - это USB FS? В каком виде оно придёт драйверу USB CDC?

Или в обратную сторону: как USB-CDC host-у послать кадр размером 70 байт в протоколе "Modbus RTU"?

и так...?

[dimka76 62]

On 5/21/2023 at 8:30 PM, jcxz said:

и так...?

А в чем проблема ?

[jcxz 236]

57 минут назад, dimka76 сказал:

А в чем проблема ?

Втыкаю USB-свисток на FT232. Наблюдаю в его дескрипторе 2 ep (IN и OUT): по 64 байта каждая. Соответственно - макс.размер кадра в котором передаются данные USB-CDC = 64 байта. Если по UART пришёл непрерывный кадр размером 70 байт, то очевидно USB-хосту он будет отправлен как минимум в двух USB-bulk-кадрах (а может и больше никто ведь не запрещает FT232 нарезать его ещё мельче?).

И тогда как обработчику USB-CDC узнать:

по UART поступил один кадр Modbus RTU, который был порезан на 2 или более USB-кадра?

или по UART поступило 2 кадра Modbus RTU, с небольшой паузой между ними?

 

Другой случай: если по UART поступило 10 байт, пауза 2 байта, затем ещё 10 байт. В каком виде эти 20 байт будут переданы USB-хосту? Как 2 USB-кадра или как один? И как это обрабатывать драйверу Modbus RTU, функционирующему поверх USB CDC?

[dimka76 62]

On 5/21/2023 at 9:47 PM, jcxz said:

Втыкаю USB-свисток на FT232.

Modbus диалоговый протокол, соответственно два разных кадра Modbus RTU  не могут прийти друг за другом.

Придет только один, пусть и порезанный на булки.

[mantech 49]

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

А в чем проблема ?

Чет тоже не догоняю, ну передавай его 2мя, да хоть 3мя пакетами, какая разница-то, там таймауты не маленькие, прекрасно все принимается и передается. Специально таких исследований не проводил, ибо предпочитаю решать проблемы по мере их появления, а тут даже не задумывался))) Мастер-слейв протоколам вообще пофиг на это дело, там ответ идет либо по набору нужного кол-ва байт, либо по таймауту, который либо 1 байт либо заметно более. 

Если усб такой тормозной, что даже не может загрузить постоянный поток данных в уарте, то я даже не знаю, и для этого в чипах-мостах есть фифо буфера... Да и порядок скоростей, для модбаса по стандарту 9600-115200, для усб даже фулл - 10-12мегабит, разница более чем в порядок...

ЗЫ. По моему - эт задача из разряда на ровном месте поискать проблему)))

Изменено 21 мая, 2023 пользователем mantech

[dimka76 62]

On 5/21/2023 at 10:19 PM, mantech said:

Чет тоже не догоняю

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

Но не думаю, что USB будет вставлять существенные задержки между булками.

[mantech 49]

29 минут назад, dimka76 сказал:

Но не думаю, что USB будет вставлять существенные задержки между булками.

Вот и я об этом. Даже представить не могу, что может так затормозить 12мегабит FS усб, чтобы он не смог передать 115200 бит\сек нужное кол-во байт с задержкой более, чем в байт... Ну разве, что полное зависание компа, причем на уровне драйвера, т.е. ядра системы)))))))

Изменено 21 мая, 2023 пользователем mantech

[firstvald 23]

смотрите. ситуация с пересылом модбас пакетов такая : из за использования виртуальных портов временной целостности при передаче не будет. на практике посылка может разрываться на фрагменты с временным зазором порядка 52 мс. посему, работоспособность по использующее виртуальные порты можно сохранить ,  но используя тайм ауты более 52 мс .  

5 hours ago, tonyk_av said:

Модбас, как обычно, оплевали, а альтернатив не предложили.

 

постоянно с этим сталкиваюсь. пишут как правило не проектирующие пром автоматику

[dimka76 62]

On 5/21/2023 at 11:12 PM, firstvald said:

смотрите. ситуация с пересылом модбас пакетов такая : из за использования виртуальных портов временной целостности при передаче не будет. на практике посылка может разрываться на фрагменты с временным зазором порядка 52 мс. посему, работоспособность по использующее виртуальные порты можно сохранить ,  но используя тайм ауты более 52 мс .  

постоянно с этим сталкиваюсь. пишут как правило не проектирующие пром автоматику

А может просто ПО кривое ?

Никогда при использовании USB-CDC с такими задержками не сталкивался.

[jcxz 236]

5 часов назад, dimka76 сказал:

Modbus диалоговый протокол, соответственно два разных кадра Modbus RTU  не могут прийти друг за другом.

Да ладно? Правда что-ли?  А если немного подумать?

Даже если диалоговый: Имеется один мастер и 2 ведомых (RS-485 например). Один ведомый подключен напрямую через свой UART к шине, второй - посредством моста USB-UART. Мастер запрашивает 1-го ведомого, он отвечает. Отвечает быстро, выполняя условие "кадры должны разделяться интервалом не менее 3.5 символов", вот 1-й и ответил через 3.5 после стоп-бита запроса от мастера.

Вопрос: Как эти два кадра будут выглядеть для 2-го ведомого?

А если вообще: мастер долго-долго общается с 1-м ведомым; оба быстро переключаются приём-передача (через 3.5 символа - ведь могут?). Скажем - 100 кадров подряд. А 101-й кадр - мастер шлёт второму ведомому. Как это будет видеть 2-й ведомый? Сможет он выделить этот 101-й кадр из предыдущего потока?

5 часов назад, dimka76 сказал:

Придет только один, пусть и порезанный на булки.

Кроме того - вы уже ограничили области применения "диалоговостью".  А если не "диалоговый"? Если скажем нужно широковещательно отправить большой объём данных (много-много кадров)?

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

Чет тоже не догоняю, ну передавай его 2мя, да хоть 3мя пакетами, какая разница-то, там таймауты не маленькие,

Вы вообще поняли о чём я писал? Судя по всему - нет. Перечитайте ещё раз если не поняли.

Разница в том, что принимающий не может гарантированно определить границы кадра. Если только не делать огромные дырки между кадрами.

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

Специально таких исследований не проводил, ибо предпочитаю решать проблемы по мере их появления, а тут даже не задумывался)))

Вот и большинство, лепящее modbus на USB-UART, также не включают голову. Ведь вроде как работает, но иногда почему-то глючит.  

[razrab83 21]

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

Вот и большинство, лепящее modbus на USB-UART, также не включают голову. Ведь вроде как работает, но иногда почему-то глючит.

более того.... большинство, лепящие modbus в ПК на COM (без усб) или /dev/tty - так же не включают голову. 1,5 и 3,5 символа между байтами не анализируют.

 

вопрос филоссофический..... допустим cpu шлет в пк через усб свисток USB FS. скорость в modbus 9600. всего 5 байт. 

байт-пауза в 0,5 байт - байт - пауза в 0,5 байт - байт - пауза в 0,5 байт - байт - пауза в 0,5 байт - байт - пауза в 3,5

как UART/USB выдаст в ПК эти байты? Будет пять булков отправлено в ПК и приложение получит через VCP пять байт с паузой между ними 0,5±t? Или преобразователь эти байты оформит в один булк? 

А если в modbus будет два пакета по 5 байт с паузой между ними в 4 символа. То в пк отправятся 10 булков по 1 байту? или UART/USB соберёт эти два пакета отправит один булк в 10 байт? Как ваше приложение на ПК в одном булке разделит на пакеты эти 10 байт? 

В 20.05.2023 в 09:26, Cirnas сказал:

Изначально я закладывал другой конфиг:

ПК <-> USB/UART <-> CPU + CPU <-> UART/422 <-> 422/UART <-> CPU

Таким образом один модуль должен был получать команды от ПК по USB и пересылать их по витой паре с 422 другому модулю.

Меня стали убеждать что этот вариант плохой

Это хороший вариант, лучше чем у вас на первой картинке. Если не 422, то тогда так 

ПК <-> USB/UART <-> CPU1 + CPU1 <-> UART/485 <-> 485/UART <-> CPU2

А вообще... вы пишете, что вам нужно ТРИ устройство посадить на шину? Зачем? Соедините два устройства любой самой дешевой/доступной шиной: CAN/UART/485/422/1-Wire/I2C/Ethernet.... и сделайте порт USB для подключения к ПК. Зачем ПК лезьть в шину между CPU? CPU может ретранслировать команды от пк другому CPU. 

 

Ну хорошо.... ну всё таки вам нужен modbus (т.к. это стандарт, сторонние устройства, сторонние программы, бла бла бла.... ) выкиньте с платы всю ветку usb-uart-485, оставьте на плате только 485 и втыкайтесь в эту шину компьютером напрямую через всё тот же злощасный usb/uart, ой, т.е. через usb/rs485. Например через такой. Возможно они дороговаты... но алиэкспресс ещё не забанили. Там эти переходники 72р (по мойму на сегодня  меньше $1). 

 

 

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

[Plain 212]

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

никогда б не подумал, что есть какие-то совместимые и несовместимые уарты для модбаса)))

Снова три рта — тоже сарказм? Потому что стандартные с ним все несовместимы, Modbus не асинхронный протокол.