LabVIEW Portal

Вот не пойму зачем читать по одной точке и издеваться над железом?

Во внутреннем цикле автор 1000 раз в секунду куда-то через global variable передает данные о направлении вращения.
Плюс он упоминал, что по окончании цикла опроса должен знать угол поворота и точное время за которое этот угол достигнут. Но при неизменном времени цикла заранее известно (так как задано) за какое время будет достигнут угол поворота.
Плюс ему необходимо прервать цикл опроса в произвольный момент времени с точностью внутреннего цикла.
Если всего этого не нужно, тогда действительно. Т.е. если нет задачи максимально точного позиционирования и достаточно реакции 100 мс или 1 с.

Рабочий режим: время интегрирования ~100 мс, контроль направления вращения ~1 мс. Да, это миллисекунды.
На таких периодах невозможно визуально отслеживать изменения значений, поэтому для отладки я использовал значения, более подходящие для визуального наблюдения (1 c и 5 c). Они и попали на скриншоты.

По поводу возможности оборудования.
Каждый прибор по-отдельности укладывается в требуемые параметры. А вообще уверенности в том, что всё это вместе удовлетворит требованиям нет ни у меня, ни у конструктора. У нас это первый проект на labVIEW, первый проект с использованием Real-Time и он оказался очень сильно экспериментальным. Сейчас главное сделать чтобы можно было в целом управлять оборудованием и снимать показания. По ходу реализации требования к быстродействию могут измениться как в большую, так и в меньшую сторону.

Направление нужно контролировать непрерывно. В том числе и для того, чтобы вовремя остановить движение при смене направления (подать сигнал на ПЧ).

Мое мнение - один while loop внутри другого это неизбежное зло! Исключения составляют FGV. Мне видятся минимум три параллельных цикла. Один собирает данные, второй рассчитывает управляющее воздействие, третий отвечает за коммуникацию с внешним миром (PC)

[quote=="rsv"]Каждый прибор по-отдельности укладывается в требуемые параметры. А вообще уверенности в том, что всё это вместе удовлетворит требованиям нет ни у меня, ни у конструктора.[/quote]

То, что на АЦП написано "1МГц" вовсе не означает, что у вас получится гонять цикл с такой частотой и брать по одной точке, т.к. накладные расходы всё сожрут.
А вот взять пачку точек за 100-1000 мс вполне реально

Features
Deterministic, software-based control—The real-time controller executes the control algorithm at rates exceeding 1 kHz.
User interface—The user interface VI interacts with the real-time controller and displays data from the control loop. This VI can disconnect from the device and reconnect at any time without affecting the control loop.
Error handling—The application reports and logs all errors from the real-time controller, shutting down on any critical error.
System Requirements

>>Мне видятся минимум три параллельных цикла. Один собирает данные, второй рассчитывает управляющее воздействие, третий отвечает за коммуникацию с внешним миром (PC)

Да, пожалуй в идеале так и надо сделать.

Blackman, спасибо за пример. Он для PXI, а у меня CompactRIO, но думаю что пригодится.

Здесь главная фраза Real-Time, а на каком железе (Target) это вторично.