Windows 11 тормозит обмены через СОМ-порт

Добрый день, коллеги.

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

Есть приложение. написанное много лет назад на Delphi 7, и без вопросов работавшее на многих ПК с Windows XP и Windows 7. Приложение через СОМ порт (компонент BComPort) посылает запрос контроллеру, контроллер, приняв пакет, отвечает, приложение, приняв ответ, посылает новый запрос (или не приняв ответ, посылает запрос по таймеру). Все просто и отлажено в десятках приложений/устройств.

И вот эта отлаженная пара (приложение - контроллер) отказывается нормально работать по Windows 11 - существенно падает скорость обмена (со 120 до 40-50 обмен/с) и в обменах наблюдаются паузы до 0.5 с, что недопустимо. Причем сразу после запуска приложения показывает скорость 120 обмен/с, но через пару секунд скорость падает до 40, затем повышается до 60, снова падает и т.д.

Т.к. предположили, что проблема в новой (для нас) ОС, то отключили антивирусы, One Drive, пробовали режимы совместимости в разными ОС, устанавливали приоритет real_time, и пр. Существенного изменения скорости и непрерывности обмена получить не удалось.

Соответственно вопрос: как настроить Windows 11 под работу в режиме real_time?

Спасибо.

0

Вот на моей любимой Первой сборке так и было, один мастер-контроллер опрашивает полевую сеть, а комп берет с него. Зачем так сделали? Вот я спрашивал, когда переписывал, у человека который участвовал в изначальном проекте, по какой-то причине программист не смог в Visual Studio сделать эту самую адресацию со сменой четности. Ну мне так объяснили.

Избавился от этого, сразу так хорошо стало. Ладно у меня не управление, а только сбор. А как через эту прокладку управлять? Сначала с нее собрать данные, потом ей послать, потом она перешлет дальше. Не жирно задержка будет?

0

Сообщение от ay007 У меня складывается впечатление, что событие наступает раньше, чем изменение Port0.Parity оказывает влияние на паритет передаваемого байта.

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

Добавлено через 32 минуты

Сообщение от Beltar Вот на моей любимой Первой сборке так и было, один мастер-контроллер опрашивает полевую сеть, а комп берет с него. Зачем так сделали?

Затем что это один из самых оптимальных вариантов решения подобной задачи. Все контроллеры работают в однозадачном режиме и не отвлекаются ни на что лишнее. А получение с мастер-контроллера из ПО на ПК не обязательно в таком случае с чем-то синхронизировать.

Сообщение от Beltar по какой-то причине программист не смог в Visual Studio сделать эту самую адресацию со сменой четности.

Ну так я уже объяснил по какой причине. WINAPI не предоставляет такой возможности.

1

Может схему нарисовать, плату развести, спаять и программу написать???

у автора цЫклоавтомат. и работает по маске состояния датчиков. и проблему "холостого хода" решил по принцыпу будем х.... ить на высокой скорости и частыми опросами пока состояние не совпадет. прое.... опрос - а пох.. в следующий раз опросим.
А нужны ли в реальности такие скорости??? взять куркулятор и посчитать ????
115200 > 9600 байт в сек. посылка в 40 байт = 0,0042 с = 4.2 милисек. !!!! а тут тайаут в 20 миллисек.
теперь холостой ход в линии связи

1 3 пропуска 60 мс
2 1 ответ 2 пропуска
3 2 ответа 1 пропуск
4 3 ответа 0 пропусков

итого 60 + 4.2 + 40 + 4.2 + 4.2 + 20 + (3 * 4,2) = 145,2 мс 4,2 * 3 = 12 мс лишних телодвежений...
тут можно и полноценный ModBas реализовать. этоже не 100 байт в секунду.
да и вобще ситуация контроллер не ответил - а пох... потом опросим, в промаппаратуре както дико.

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

0

Сообщение от northener Ну так я уже объяснил по какой причине. WINAPI не предоставляет такой возможности.

У меня оно и так работает с USB<->RS-485. Железяка такая. Когда я проверял с нормальным COM-портом и внешним RS-485 преобразователем, то работать не стало, но я интуитивно всунул м\у адресом и посылкой Sleep(50) (может и меньше можно). Там размер ответа может до 246 байт доходить при 9600 скорости, и такие задержки в плане скорости ни о чем на фоне задержек работы через мастер-контроллер.

0

Сообщение от northener Правильно складывается. Это событие создано только для того, чтобы программа могла продолжать передачу. Но оно не означает, что все данные переданы в линию.

Недокументированная особенность компонента TBComPort? Ну и ладно.

Сообщение от northener Затем что это один из самых оптимальных вариантов решения подобной задачи.

С точки зрения скорости обмена - возможно, особенно, если добавить обмен с каждым контроллером по отдельному каналу.

Но вот с точки зрения прозрачности программы управления в целом - не уверен. В Установке семь независимых узлов, каждый из которых работает автономно и по своим циклограммам, с использованием флагов разрешения работы, связывающих узлы в единый комплекс. Циклограммы представлены в виде отдельных текстовых файлов, что упрощает их редактирование, а Установка может работать с различными наборами задействованных узлов (полный набор - 7 узлов, но можно работать только с одним (типа только сварка)). Это я к тому, что реализовать/отлаживать/модернизировать такие (сложные для меня алгоритмы) мне проще на языке высокого уровня типа Delphi, но не на ассемблере.

Добавлено через 1 час 12 минут

Сообщение от stalkernet Может схему нарисовать, плату развести, спаять и программу написать??? у автора цЫклоавтомат. и работает по маске состояния датчиков. и проблему "холостого хода" решил по принцыпу будем х.... ить на высокой скорости и частыми опросами пока состояние не совпадет. прое.... опрос - а пох.. в следующий раз опросим. А нужны ли в реальности такие скорости??? взять куркулятор и посчитать ???? 115200 > 9600 байт в сек. посылка в 40 байт = 0,0042 с = 4.2 милисек. !!!! а тут тайаут в 20 миллисек. теперь холостой ход в линии связи 1 3 пропуска 60 мс 2 1 ответ 2 пропуска 3 2 ответа 1 пропуск 4 3 ответа 0 пропусков итого 60 + 4.2 + 40 + 4.2 + 4.2 + 20 + (3 * 4,2) = 145,2 мс 4,2 * 3 = 12 мс лишних телодвежений... тут можно и полноценный ModBas реализовать. этоже не 100 байт в секунду. да и вобще ситуация контроллер не ответил - а пох... потом опросим, в промаппаратуре както дико. в третих контроллер для опроса - это RTS. таймауты у него стабильные и не зависят от чиха, пука и не дай бог резкого ослабления стула до цвета детской неожиданости системы под названием вЫнь.

Начнем с простого, при скорости 115200 бит/с и 11 бит на передачу байта (старт, стоп, паритет и 8 бит) можно передать 10472 байт/с. Сейчас реальная скорость обмена 5-7 кБайт/с, что вполне удовлетворительно с точки зрения производительности Установки.

Таймаут 20 мс - только при отсутствии приема ответа, что в нормальном режиме работы происходит нечасто.

Производительность Установки определяется временем выполнения самой длительной операции (в обсуждаемой Установке - это операция собственно сварки - время выполнения не зависит от скорости обмена) и суммарным временем перемещения деталей между позициями загрузки/выгрузки Узлов (это циклограммы и время выполнения напрямую связано скоростью обмена). И есть интегральный критерий достаточности скорости обмена - если в установившемся цикле Узел перемещения выполнил все операции перемещения и ожидает окончания операции сварки - скорость обмена достаточно высока, если же сварка закончилась и Узел сварки ожидает, когда Узел перемещения заберет сваренную деталь, - скорость низкая. Сейчас скорость обмена достаточно высока, ее увеличение не приведет к увеличению производительности Установки.

И да, время выполнения циклограммы - это время перемещения, например, пневмоцилиндров (не зависит от скорости обмена), и время реакции программы на изменения состояния датчиков (зависит от скорости обмена). Снижения скорости обмена в два раза приводит к снижению производительности Установки примерно на 10 %.

И к вопросу о дикости. С одной стороны, я действительно специалист малообразованный в области автоматического управления (радиоинженер эпохи развитого социализма). Когда чуть более 20 лет назад пришлось начать работать с конечными автоматами, то первое с чем столкнулся, разбирая сбоящую программу предшественников, это непонимание, как можно управлять Установкой с хотя бы десятком пневмоцилиндров и двумя десятками датчиков по системе, отдельная команда на опрос каждого датчика и отдельная команда на управление каждым пневмоцилиндром. Соответственно, постепенно была разработана система (уверен, что она широко известна и не менее широко используется, но пришел к ней сам и эволюционно), когда в каждом запросе (раз в 10 мс) в контроллер пересылается состояние всех пневмораспределителей (и пр. исполнительных устройств), а в каждом ответе в ПК пересылается состояние всех датчиков. При этом действительно неважно (для эксплуатируемых на нашем предприятии Установок), если какая-то посылка потеряется - через 20 мс придет следующая/дублирующая. При этом многолетний опыт эксплуатации показывает, что сбои, требующие вмешательства оператора крайне редки, а приводящие к самоповреждению Установки отсутствуют.

Поэтому не вижу оснований к любому усложнению системы управления.

0

Сообщение от ay007 Недокументированная особенность компонента TBComPort? Ну и ладно.

И не только этого компонента. Он всего лишь 333 и третья в периоде копия компонента, который написал некий четвёрошник надцать лет назад. Написал и забыл.

Сообщение от ay007 Но вот с точки зрения прозрачности программы управления в целом - не уверен. В Установке семь независимых узлов, каждый из которых работает автономно и по своим циклограммам, с использованием флагов разрешения работы, связывающих узлы в единый комплекс. Циклограммы представлены в виде отдельных текстовых файлов, что упрощает их редактирование, а Установка может работать с различными наборами задействованных узлов (полный набор - 7 узлов, но можно работать только с одним (типа только сварка)). Это я к тому, что реализовать/отлаживать/модернизировать такие (сложные для меня алгоритмы) мне проще на языке высокого уровня типа Delphi, но не на ассемблере.

Это для меня не понятно. Я писал только о механизме перехода от передачи адреса к передачи данных. Какие там к лешему циклограммы?

0