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

Есть два E20-10, каждый собирает данные с одного катала на частоте 10 МГц. Ведущий стартует с трансляцией сигнала старт, и трансляцией тактовых импульсов. Ведомый стартует от внешнего импульса старт по переднему фронту, внешний источник тактовых импульсов по переднему фронту.

Для проверки подаю один импульс через делитель на два АЦП одновременно.

В результате получается задержка ведомого АЦП в ~70000 отсчётов относительно ведущего, при этом количество отсчётов задержки непостоянно.

При этом на записи с ведомого АЦП ~70000 отсчётов занимает подобный сигнал:

ПО на С++, ОС Linux.

Это признак того, что ведомый физически стартует программно, а не от ведущего. Вообще, ведомый нужно стартовать раньше, чтобы ожидал старта от ведущего.
А линии синхронизации ведущего и ведомого соединены, как указано в руководстве?

Линии соединены по руководству, ведомые естественно стартует раньше ведущего и ждёт. Я не задержка всегда одинаковая не смотря на то, сколько прождал ведомый.

Ваше последнее предложение непонятно. Поясните.

Всё сделал по руководству.

Запускаю ведомый АЦП первым, после запускаю ведущий АЦП. Время запуска ведущего относительно ведомого разное. Но всегда ведомый запускается первым и ждёт ведущего. В результате получаю задержку ведомого ацп от ведущего в ~70000 отсчётов.

Ссылки в первом сообщении не работают
Василий, программист по E20-10 выйдет из отпуска на следующей неделе, будем разбираться почему возникает задержка.
Сообщите серийный номер E20-10, версии прошивок AVR и FPGA.

Серийные номера:

SerNum       5D775023
Current Firmware Version 0x0

SerNum       5D358243
Current Firmware Version 0x0

В loadBios загружаю файл e2010m размером 40481 байт. (вроде взят с диска от который был в коробке с АЦП)

Какие-то странные у Вас версии прошивок...
Для получения серийного номера и версий прошивок можно воспользоваться штатной утилитой ModulesViewer:
www.lcard.ru/download/modulesviewer13.exe

Вчера результаты я переписал из приложения test которое входит в архив с модулями ядра и библиотеками для Linux.

modulesviewer13.exe
выдаёт следующее:

5D775023
Микроконтроллер:
версия 2.1 от Apr 18 2008
Загрузчик:
версия 2.0 от Mar 18 2008
ПЛИС
версия 2.00.06 от 01.09.08

5D358243
Версии аналогичны предыдущему модулю.

Под windows7 в LGraph2 всё синхронно.

Попробуйте задействовать обновлённую прошивку ПЛИС:
ftp.lcard.ru/pub/users/e2010/e2010m10.zip

Ситуация не изменилась.

Может я не правильно конфигурирую АЦП

Ведомый АЦП конфигурирую след. образом:
            pI->LoadBios("e2010m");
        pI->PlataTest();
        adcPar.t2.s_Type = L_ADC_PARAM;
        adcPar.t2.AutoInit = 1;
        adcPar.t2.dRate = 10000.0; // частота опроса каналов АЦП
        adcPar.t2.dKadr = 0.;
        adcPar.t2.SynchroType = EXT_START_DOWN_REVB;
        adcPar.t2.SynchroSrc = EXT_CLK_UP;
        adcPar.t2.AdcIMask = SIG_0 + V30_0;
        adcPar.t2.NCh = 1;
        adcPar.t2.Chn[0] = 0x0;

        adcPar.t2.FIFO = 32768;
        adcPar.t2.IrqStep = 32768;
        adcPar.t2.Pages = 8;
        adcPar.t2.IrqEna = 1;
        adcPar.t2.AdcEna = 1;

        adcPar.t2.StartCnt = 0;
        adcPar.t2.StopCnt = 0;
        adcPar.t2.DM_Ena = 0;
        adcPar.t2.SynchroMode = 0;
        adcPar.t2.AdPorog = 0;

Ведущий АЦП конфигурирую след. образом:
        pI->LoadBios("e2010m");
        pI->PlataTest();
        adcPar.t2.s_Type = L_ADC_PARAM;
        adcPar.t2.AutoInit = 1;
        adcPar.t2.dRate = 10000.0;
        adcPar.t2.dKadr = 0.;
        adcPar.t2.SynchroType = INT_START_TRANS;
        adcPar.t2.SynchroSrc = INT_CLK_TRANS;
        adcPar.t2.AdcIMask = SIG_0 + V30_0;
        adcPar.t2.NCh = 1;
        adcPar.t2.Chn[0] = 0x0;

        adcPar.t2.FIFO = 32768;
        adcPar.t2.IrqStep = 32768;
        adcPar.t2.Pages = 8;
        adcPar.t2.IrqEna = 1;
        adcPar.t2.AdcEna = 1;

        adcPar.t2.StartCnt = 0;
        adcPar.t2.StopCnt = 0;
        adcPar.t2.DM_Ena = 0;
        adcPar.t2.SynchroMode = 0;
        adcPar.t2.AdPorog = 0;

Те сма режим ведущий ведомый визически работает? если разорвать связь то один модуль будет собирать, а второй стоять?

Чтобы корректно проверить, что оторванный ведомый стоит в ожидании, нужно его вход START подключить к GND на разъёме DIGITAL.
Следует учитывать, что сигнал START от ведущего идёт активным  высоким логическим уровнем.  Если вход START ведомого оторван, то этот вход будет подтянут к высокому уровню внутренней резисторной подтяжкой.

Если разорвать связь, то ведомый стоит, ведущий собирает.

Я имел ввиду, что если разорвать связь до запуска приложений.

Изменил у ведомого в инициализации
adcPar.t2.SynchroType = EXT_START_DOWN_REVB;

на
adcPar.t2.SynchroType = EXT_START_UP;

И задержка стала всего 100 отсчётов АЦП.
Всё-таки новая прошивка плис помогает. Со старой задержка 70000 отсчётов.

Хотя нет, это была просто случайность похоже... Несколько экспериментов показали, что задержка осталась...

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

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

До старта минимально физически с модулем  общаются только LoadBios, ReadPlataDescr и если вызывается, то EnableCorrection. Параметры сбора и синхронизации осмысленно пишутся именно  в StartLDevice. Что  в программе зациклено при рестарте сбора?

После сбора данных программа заканчивает свою работу. Потом её перезапускаю уже руками из консоли.

Похоже я нашёл свою ошибку.... 

pI->FillDAQparameters(&adcPar.t2);
pI->SetParametersStream(&adcPar.t2,.....

вместо t2 я сначала писал t1.... ух блин.
После этого вроде всё заработало как надо!

Хотя нет, задержка присутствует.