[khach 38]

Для протоколов типа модбаса делали преобразователь протоколов типа UART-UART( USB). Т.е винда видит на USB ком порт, но получает уже чистые пакеты данных. А все тайминги протокола, контрольные суммы, ASK-NAK, 9 бит итд  обрабатываются на стороне контроллера.

[ДЕЙЛ 30]

По поводу таймингов. При использовании эмулятора  usb-com без пауз можно передать до 64 байт, затем будет обязательно пауза примерно 1мс, что обусловлено самой природой USB, как понимаю. 

Со стороны ПК максимально жёсткий тайминг возможен при работе с портом в отдельном потоке с максимальным приоритетом и без всяких пауз вроде vTaskDelay,  Task.Delay или Sleep, если в процессоре больше одного ядра, иначе можно повесить операционку. 

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

[tonyk_av 39]

15 hours ago, ДЕЙЛ said:

затем будет обязательно пауза примерно 1м

С чего бы это?

Хост начинает раз в 1мс опрашивает узел после последнего ответа, что нет данных. Пока узел отвечает данными, пауз на опросе не будет. Никакого жёсткого тайминга не требуется, пакеты принимаются целиком задачей с обычным приоритетом.

[ДЕЙЛ 30]

On 5/8/2024 at 10:14 AM, tonyk_av said:

С чего бы это?

Хост начинает раз в 1мс опрашивает узел после последнего ответа, что нет данных. Пока узел отвечает данными, пауз на опросе не будет. Никакого жёсткого тайминга не требуется, пакеты принимаются целиком задачей с обычным приоритетом.

Предлагаю попробовать отправить файл через мой терминал  и переходник USB-COM  на максимальной скорости с помощью команды [sendfile:] (пример: [sendfile:]E:\TerminalTMB_Logs\LOG TEST_2024 4 26 18 10 32 TX RX.txt) и посмотреть осциллографом паузы. Самому любопытно стало, но руки не доходят.

 

[tonyk_av 39]

1 minute ago, ДЕЙЛ said:

переходник USB-COM  на максимальной скорости с помощью команды

Пробовал до 461К через МОХА. Проблем не было.

Драйверы для преобразователей пишут ведь не идиоты. Если узел не сказал, что данных в нём нет, то и драйвер не будет говорить ОС, что у него есть данные. Даже получив такой ответ, драйвером может ведь быть сделана небольшая задержка для того, чтобы удостовериться в отсутствии ещё данных. Конечно, это моё предположение, но я ни разу не встречался с ситуацией прихода разорванных Модбас/RTU-пакетов.

[ДЕЙЛ 30]

4 minutes ago, tonyk_av said:

Пробовал до 461К через МОХА. Проблем не было.

Драйверы для преобразователей пишут ведь не идиоты. Если узел не сказал, что данных в нём нет, то и драйвер не будет говорить ОС, что у него есть данные. Даже получив такой ответ, драйвером может ведь быть сделана небольшая задержка для того, чтобы удостовериться в отсутствии ещё данных. Конечно, это моё предположение, но я ни разу не встречался с ситуацией прихода разорванных Модбас/RTU-пакетов.

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

[jcxz 215]

12 минут назад, ДЕЙЛ сказал:

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

ACK в USB не может быть причиной задержки. Так как даже в FS-USB отправляется внутри того же 1мсек фрейма, что и сам кадр данных. Т.е. - в следующем USB-фрейме уже может идти следующий кадр данных. Что уж говорить о HS-USB с его 125мксек фреймами....

Имхо - задержки скорее всего из-за некорректной работы прикладной программы с Serial WinAPI. Или же в драйверах.

[Палыч 9]

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

Пробовал до 461К через МОХА. Проблем не было.

Преобразователь интерфейсов USB-RS485 от MOXA наверное единственный, который нормально поддерживает MODBUS-RTU. Весь остальной зоопарк преобразователей рвали прием/передачу на 32-ом байте.

[tonyk_av 39]

3 hours ago, Палыч said:

Весь остальной зоопарк преобразователей рвали прием/передачу на 32-ом байте.

Не знаю, с какими преобразователями вы работаете, но сейчас у меня два ПЛК работают с четырьмя разными китайскими преобразователями, и ни на одном я не вижу ошибок, что означает правильный приём-передачу фреймов. И да, фреймы больше 70 байт.

[Палыч 9]

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

Не знаю, с какими преобразователями вы работаете

Например, преобразователи, построенные на CH340, однозначно рвут передачу.

[tonyk_av 39]

51 minutes ago, Палыч said:

Например, преобразователи, построенные на CH340, однозначно рвут передачу.

При случае попробую, проверю.

[firstvald 22]

практически все. первое, на ком увидел это ftdi. ну и конечно же все остальные. CH  PL  CP. ну и механизм явления я выше расписал.

[jcxz 215]

1 час назад, Палыч сказал:

Например, преобразователи, построенные на CH340, однозначно рвут передачу.

Категорически не использую ни PL2303 ни CH340. Исключительно только CP21xx и FTDI. Может поэтому и не сталкиваюсь с проблемами с USB-UART?