Форум

Здравствуйте.

Я посмотрел тот пример, что Вы присылали.
Тут нужно учитывать, что хотя сам модуль позволяет вводить и выводить сигнал синхронно с заданной частотой и диаграммы синхронного ввода и вывода привязаны к одной точке старта, но сами данные между модулем и программой на ПК передаются с задержками. Более того, под ОС общего назначения эти задержки строго не определены и могут варьироваться от запуска к запуску.

В связи с этим синхронный вывод с точной привязкой по времени возможен только при условии, что на момент вывода данные уже загружены в сам модуль, т.е. всегда нужно иметь загруженную часть сигнала в памяти самого модуля (время предзагруженного сигнала в общем и определяет макс. суммарную задержку, которая не приведет к разрыву данных).

У Вас в программе выполняется предзагрузка, но всего на две точки для каждого канала (что для частоты 2.5 КГц меньше мс).
В результате, когда Вы запускаете синхронный ввод-вывод через StreamsStart, пока модуль пошлет ответ (функция завершается по успешному ответу от модуля)  и этот ответ будет обработан программой ПК, у Вас эти точки уже давно будут выведены и из-за отсутствия новых данных последняя точка будет повторяться до тех пор, пока не придут новые данные, которые уже начнут выводиться синхронно с момента прихода, но длительность паузы пока данных не было будет зависеть от задержек передачи ответа, его обработки, посылки новых данных, которые каждый раз разные. При этом с АЦП данные собираются с момента старта всегда синхронно и хоть и получаются в ПК с задержкой, но соответствуют синхронным моментам времени с заданной частотой от начала сбора.

Таким образом Вам нужно изначально предзагрузить достаточно данных - хотя бы 7-10 Ваших циклов по 8 мкс, чтобы к моменту посылки новых данных буфер на вывод не опустошился и вывод был бы строго синхронным. Я для проверки у себя завел DOUT1 и DOUT2 на первый и второй канал АЦП  и проверил Ваш пример с достаточной предзагрузкой, в результате получился синхронный сигнал с той же задержкой от начала, что и выводилось, без сдвигов от запуска к запуску:

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

Также у Вас несколько странно был сделан сам вывод. В Prepeare передается размер каждого сигнала (на цикл у Вас 20 точек) и каждый массив на входе должен быть этого размера, а в Send передается уже размер слов общего результирующего массива. Т.к. Вы используете все 3 потока вывода, то он должен быть в 3 раза больше. У Вас же получалось, что Вы подавали размер 4, при этом массив цифровых линий был из одного элемента (3 других по сути использовались как мусор из памяти за массивом), далее получался массив на 12 элементов из которых Вы передавали только 4 первых (ЦАП1, ЦАП2, DOUT, ЦАП1), что соответствовало двум циклам вывода, где во втором значения ЦАП2 и DOUT повторялись, т.к. они не пришли в кадре (т.е. так как Вы из выходного потока передавали все равно только один DOUT, то лишний мусор на выходе из PrepareData не видели). Да и разбивать цикл на 10 частей и выводить по два отсчета особого смысла не имеет, логичнее формировать и посылать сразу блок на цикл в 8 мс (времена реакции в 1мс все равно сильно меньше мин. возможных задержек в windows).

Подправленный пример я выслал Вам на почту.

P.S,: если цикл всегда одинаковый, а вывод уровней на ЦАП явно к фазе цикла не привязан, то проще использовать циклический вывод для DOUT и асинхронный для ЦАП.