Разделение цикла опроса модулей и UI

[Sergey Puzanov]

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

[Borjomy_1]

Зачем надо натягивать сову на глобус? Задачи жёсткой синхронизации и тактирования решаются аппаратно. Для этого есть cRIO, FPGA.

[Sergey Puzanov]

Зачем надо натягивать сову на глобус? Задачи жёсткой синхронизации и тактирования решаются аппаратно. Для этого есть cRIO, FPGA.

cRIO рассматривали, но там большие два НО:
1) Число каналов в совокупности = 256, это минимум 2 cRIO, которые как-то нужно настроить.
2) Такое число оборудования просто не закупят, поэтому и приходится с этой старой и полудохлой совой работать.

[Artem.spb]

В общем имеется возможность переделать опрос модулей с CVT на принцип FIFO, но и соответственно отказаться от некоторых пост-обработок,

Вам нужно прям по одному элементу?
Не на аппаратных уровнях вопрос решается выборкой массива и его обработкой, что позволяет "плавать" по частоте цикла-обработчика, главное чтобы он успевал вытащить всё.

[Artem.spb]

Зачем надо натягивать сову на глобус? Задачи жёсткой синхронизации и тактирования решаются аппаратно. Для этого есть cRIO, FPGA.

На надо мучить птичку..
Мне лично любопытно, реально ли разделяет потоки, и почему на слабых машинах не-UI поток всё равно страдает из-за UI-активности.
Ладно бы загрузка была 100%, но судя по "отчёту" ujin1 там ещё есть запас.

[Borjomy_1]

Если выдавать ничего не надо с такими-же таймингами, то никакого смысла искать задержки нет в принципе. Необходимо только обеспечить аппаратную буферизацию, которую обеспечивает практически любая плата сбора. Потребность выцарапывать миллисекунды стабильности нужна только когда обеспечивается обратная связь (и она обладает такими требованиями, в том числе по инерционности системы). А вот попытки сделать систему истинно реального времени на Windows - это, извините, принципиально ошибочная стратегия.

[Borjomy_1]

Зачем надо натягивать сову на глобус? Задачи жёсткой синхронизации и тактирования решаются аппаратно. Для этого есть cRIO, FPGA.

На надо мучить птичку..
Мне лично любопытно, реально ли разделяет потоки, и почему на слабых машинах не-UI поток всё равно страдает из-за UI-активности.
Ладно бы загрузка была 100%, но судя по "отчёту" ujin1 там ещё есть запас.

Скорее всего задействовано одно ядро для всего процесса (так построена программа) и его не хватает для работы в условиях перегрузки.

[dadreamer]

А вот попытки сделать систему истинно реального времени на Windows - это, извините, принципиально ошибочная стратегия.

Вообще можно, если туда вкорячить IntervalZero RTX/RTX64, INtime и т.п. или перескочить на RT-Linux (можно и самому ядро пересобрать на основе rt-kernel). Однако в первых двух случаях Windows как основная система всё равно будет необходима по ряду причин: API ядра, HAL, функции лицензирования, да хотя бы GUI хоть какой-то для оператора. Ну, и придётся разделить программу на два модуля: для обычной системы и для RT-прослойки. RT-часть, естественно, придётся писать на C/C++ и потом сопрягать по IPC с .