Проблема решилась. Отключили ltr-сервер, выключили удаленный крейт, FpgaVersion обновился до 1.0.7.0, метки СТАРТ генерируются нормально. Спасибо!

Еще один вопросик. Сразу после включения компьютера и USB и ETHERNET крейтов, первая генерация одиночной внутренней метки СТАРТ на USB крейте вызывает несколько внешних меток на удаленном крейте. Повторные генерации одиночных внутренних меток вызывают как и предполагается одинарные внешние метки на удаленном крейте. После выключения и включения оборудования ситуация повторилась. Лишние метки работе пока не мешают, однако беспокойство вызывают. В чем может быть дело?

Александр. Я так понял, что крейты LTR-EU Вы соединили по схеме "ведущий-ведомый", соединив выход DIGOUTx ведущего со входом DIGINx ведомого.

Во-первых: В такой связке важен порядок действий по инициализации системы. Например, можно ошибочно настроить сначала ведомого на приём меток, а ведущего начать конфигурировать вторым шагом. Как следствие, переход линии  DIGOUTx ведущего на активный выход после вызова LTR_Config() может спровоцировать ложный импульс, поскольку предыдущее состояние линии может быть не определено, или потому, что сам переход в активное состояние  может паразитное вызвать отражение на линии. Поэтому, рекомендуемый  порядок действий при включении следующий:
1. Исходные состояния ведущего и ведомого (при включении) - внутренняя синхронизация.
2. Выполнить для ведущего LTR_Config(), устанавливающий его линии DIGOUTx на выход.
3. Выполнить для ведомого LTR_Config(), устанавливающий его линии DIGin на вход внешней синхронизации. (На всякий случай, после этого проконтролировать: меток ещё не должно быть)
4. Включить генерацию меток ведущего (в том или ином режиме) функцией LTR_MakeStartMark().
Соответственно выключать систему целесообразно в обратной последовательности:
1. Выключить генерацию меток ведущего функцией LTR_MakeStartMark().
2. Выполнить для ведомого LTR_Config() для установки на внутреннюю синхронизацию.
3. Выполнить для ведущего LTR_Config() для установки на внутреннюю синхронизацию.

Во-вторых: рекомендуется в линию синхронизации ввести резистор подтяжки к нулю, и расположить его на стороне ведомого, параллельно его входу. Сопротивление подтяжки рекомендуется 120-200 Ом, 0,125 Вт. Синхронизируемые крейты объединить кратчайшим путём по клеммам заземления. Саму линию синхронизации вести витой парой, желательно, экранированной.

Обязательно ведомый в такой системе нужно настраивать на внешнюю синхронизацию "по фронту", тогда активные перепады (фронты) ведущего и ведомого будут совпадать по времени.

Завтра попробуем выполнить Ваши рекомендации. Вроде бы порядок инициализации близок к описанному Вами, кроме фазы выключения, уточню на месте завтра. Может поэтому и нет "лишних" меток при повторной программной инициализации (перезапуск ltr-сервера и прикладной программы)? Синхронизируемые крейты объединить коротким путём не удастся - между ними порядка 50 м.

1.Программная инициализация крейтов под синхронизацию соответствует рекомендуем, за исключением шага перевода их на внутреннюю синхронизацию
2. Попытка проверить на каком шаге генерируются лишние метки СТАРТ не к чему не привела, сегодня почему то прежние действия вообще не вызвали лишних меток.
3.Пока будем наблюдать за этим эффектом, и обсудим варианты помехозащиты, предложенные Вами
4.Еще еще одно наблюдение, и ранее и сегодня секундные метки генерировались синхронно на обоих крейтах.
Спасибо за помощь!

Александр. Два удалённых на 50 м крейтов имеют разные потенциалы точек заземления. Соединяя  линии синхронизации крейтов без гальваноразвязки, Вы по общему проводу пропускаете уравновешивающие земельные токи. Достаточно хорошего броска по сети (например, в момент включения сторонней аппаратуры) и ложный импульс синхронизации будет пойман. Между тем, соединение с применением оптрона и нескольких резисторов эту ситуацию бы исключила. Как говорится, моё дело предупредить...

1. Период секундных меток 1000 мс, длительность импульса около 470 мс (могу посмотреть точно, если это принципиально). Пассивное состояние - логический ноль. Стабильность частоты реально не хуже +-25 *10^-6

2. В текущей версии прошивок и ПО задать 990 миллисекунд нельзя. Как Вы уже поняли, генератор секундных меток крейт-контроллера - в ПЛИСе, прошивка которого дистанционно обновляема. Таким образом, мы можем дополнить её необходимым сервисом, а потом выслать новую прошивку. Теперь по сути. Идея пошагового подбора периода мне кажется слишком сложна. Гораздо проще будут следующие варианты:

Вариант 1. Размечать 100- или 10- или 1-миллисекундные  интервалы второй синхрометкой (поскольку сейчас в архитектуре LTR - две различимые синхрометки), фазу которой привязывать: -  к моменту генерации секундной метки (для ведущего крейта), или к моменту приёма  секундной метки (для ведомого крейта).   
Вариант 2. Использовать вторую линию синхронизации, на которую подать от ведущего крейта синхрометки с 100- или 10- или 1-миллисекундными  интервалами, привязанными по фазе к секундным меткам.

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

Лишняя работа, понятно, никому не нужна, мы не и не думали Вас напрягать, может такая синхронизация больше никому не интересна.

Я наверное не очень понятно сформулировал, идея не в том, чтобы подобрать период, а задать период опроса заранее, скажем, 110 мс, тогда за 10 секунд можно определить смещения потоков медленных LTR27 (10Гц) относительно синхрометок. Для каждого такого модуля 9 из 10 последовательных секундных меток будут связаны с 9 отсчетами а одна метка с 10 отсчетами, тогда первый  и последний отсчеты (соответствующие 10-ти отсчетной метке) будут сфазированы точнее других относительно секундных меток и не хуже 10 мс (первый в плюс, последний в минус). Программная реализация поиска этой секунды не слишком сложна.
Все отсчеты следующей секундной метки будут иметь дополнительное смещение +10 мс и т.д. Т.е для каждого десятигерцового модуля будет своя 10-отсчетная метка и можно выровнять потоки данных с точностью до 10 мс а не периода опроса.
К сожалению, начальству не нравятся такие периоды дискретизации, поэтому я и спрашивал про генерацию секундных меток. Кстати, ситуация с LTR41,42,43 наверное еще тяжелее, в смысле перепрошивки AVR?

Александр. Я не уверен, что я Вас понял окончательно, но если Вам нужна прошивка LTR-EU крейта, где вместо секундных меток должны быть метки с каким-либо другим неизменным интервалом времени, допустим, 110 мс, то это проще простого. Такую прошивку я Вам сделаю, она  не потребует изменения какого-либо ПО. Это будет не официальная прошивка "как есть", от Вас потребуется её тестирование.
В LTR41,42,43 вводить какие-либо изменения возможно, хотя там значительно меньше ресурсов для этого. Но, в принципе, на другой период там метки тоже можно переделать...

Да, Александр, Вы правильно поняли, нас вполне устроила бы генерация "секундных" меток на ведущем крейте с постоянным интервалом 990 мс, чтобы не менять длину импульса в 470 мс, если это не очень сложно. Она позволит реализовать описанный мною алгоритм для "красивых" периодов дискретизации в 100 мс. Мы конечно же готовы протестировать такую прошивку, ведь в случае проблем мы всегда можем вернуться к официальной, не так ли?

Безусловно, сможете вернуться.
Хорошо. Сделаю с периодом 990 мс и длиной импульса 470 мс. Вышлю Вам на e-mail предположительно завтра.

Выслал.

Огромное Вам спасибо! Завтра доработаем свою программу, обновим прошивку и начнем тестирование. О результатах сообщу в этой же теме. Еще раз спасибо!

Добрый день!Получили первые результаты работы с экспериментальной прошивкой. Пока каких либо отличий от работы стандартной не заметили. А вот попытка определить временные смещения кадров данных от разных LTR27(в одном крейте и при одном периоде дискретизации 10 Гц) выявила не очень понятные моменты. Оказалось, что LTR27 выдают кадры практически синхронно относительно секундных меток (иногда отмечалась разница порядка 10 мс). Величина смещения меняется для повторных экспериментов от 10 до 80 мс. Если я правильно понимаю, запуск и работа LTR27 не является синхронными, именно поэтому и была предпринята попытка найти смещения. Конечно же мы еще проверим код своей программы, но может что-то сразу посоветуете?

1.Александр, после обновления параметр FpgaVersion обновился?
2.LTR27 вполне может выдавать кадры практически синхронно относительно секундных меток, если метки и сбор данных со всех LTR27 будут запущены одновременно. Но если при передаче команды запуска, например, тормознёт Windows, то произойдёт запаздывание запуска одного LTR27 относительно другого. Это происходит из-за того, что команды запуска до LTR27 доходят асинхронно.
3. Если есть частотомер, то период следования  меток можно проконтролировать с хорошей точностью.
4. То, что сейчас синхронный запуск LTR27 не сделан, это не означает, что его в принципе нельзя сделать. Можно, например, процессор в крейте заставить выслать все команды запуска всем LTR27 без пауз, и на интерфейсе между процессором и модулями не набежит задержек больше, чем несколько микросекунд, если правильно это организовать. Но для этого нужно модифицировать ПО процессора под Вашу задачу...   
5. Определить смещение 10 мс между асинхронно запущенными модулями с частотой 10 Гц можно и другим путём. Например, если в этом крейте у Вас запущен ЛЮБОЙ синхронный LTR-модуль с частотой сбора данных 100 Гц, то выходной групповой  RAW-поток от сервера (который ещё не рассортирован по разным модулям) будет устроен так, что положение отсчётов данных 100 Гц фактически и будут для Вас дополнительными метками синхронизации, поскольку они разобьют Ваш поток на 10 мс интервалы. Фактически, анализируя RAW-поток, Вы будете работать с последовательностью данных, соответствующей последовательности их зарождения.
6. Напомню на всякий случай, что в разных LTR-крейтах генераторы опорной частоты друг с другом не синхронизируются.

1.FpgaVersion обновился до 1.0.10.0
2.Не очень понял как можно выполнить одновременный запуск всех 16 LTR27 установленных в крейт. Удивила именно синхронность (почти) разных LTR27 между собой.
3.Возможность определить временные смещения LTR27-х с помощью синхронного LTR действительно интересна, но к сожалению, все 16 мест крейта забиты LTR27-ми.
4.Я понимаю что генераторы опорной частоты разных крейтов не синхронны, все задержки измерялись относительно внешних секундных меток крейта с модулями LTR27

2. В штатном ПО гарантировать нельзя. Но если модифицировать ПО Blackfin, чтобы 16 команд запуска всех  LTR27 он смог выслать буквально друг за другом, тогда команды запуска дойдут до LTR-модулей практически одновременно.
 
"Удивила именно синхронность (почти) разных LTR27 между собой." -Что тут удивительного? Команды запуска от компьютера в большинстве случаев приходят почти друг за другом, но иногда встревают асинхронные задержки Windows и USB...

Александр, прошу извинения, я не указал, что команда запуска каждого LTR27 посылается из отдельного потока (для каждого модуля свой поток), до посылки команды запуска потоки ждут общего флага запуска, в каждом потоке имеется Sleep(15). При таких условиях синхронность меня удивила.

В конце концов, можно было бы и аппаратно сгенерировать всем LTR27-модулям команды старт, адаптировать под это специальную прошивку ПЛИС, но я не считаю это идеологически правильным решением, поскольку в LTR-EU для выполнения специфических Real Time задач специально был применён сигнальный процессор с JTAG-интерфейсом, предоставляются исходники ПО. Жалко, что этим мало кто пользуется...

Александр, а почему Вы не хотите один или все LTR27 запустить с частотой 100 Гц? Из-за случайной погрешности измерений, которая больше на 100 Гц по сравнению с 10 Гц? Если по этой причине, то Вы можете усреднить каждые 10-точек,получив из них одну (децимация) на верхнем программном уровне, получив в итоге ТУ ЖЕ САМУЮ случайную составляющую погрешности, сделав из 100 герцового потока 10-герцовый, но, при этом, более точно привязавшись к секундным меткам...

Александр_Р, насчет почти_одновременности вполне допускаю, что эти старты сложились в какой-то буфер где-то в дебрях USB и ушли оттуда подряд, т.е. <<сели в один автобус>>.
Вообще случайная разница во времени порядка 10 мс (при нормальных условиях) характерна для команд, подаваемых <<подряд>> с точки зрения прикладной программы - что-то вроде
LTRx_Start(&ltr1); LTRx_Start(&ltr2); LTRx_Start(&ltr3); LTRx_Start(&ltr4);
Но вообще лучше не связывать время по часам ПК и время физического процесса. Я помню яркий пример, как один человек отлаживал программу на Delphi, и при вызове помощи по F1 измерения разваливались напрочь, т.к. система начинала не спеша запускать winhelp

А скорее даже не в дебрях USB, а в TCP/IP между приложением ltrserver или в самом ltrserver. Все эти обмены данными на самом деле буферизуются по десять раз на разных уровнях.

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

1.Александр Гарманов, Вы по большому счету правы, под нашу задачу (не только измерение но и управление) нужно по идее создавать real time систему и переносить часть обработки в DSP. Но, обработка весьма мудреная, связана с газодинамическими расчетами, к тому же может сильно изменяться от испытания к испытанию,и еще много чего против этого пути. Возможно? когда нибудь мы попробуем реализовать синхронный запуск LTR27. Сейчас на это нет времени да и программистов нужного уровня.
Насчет того, чтобы все LTR27 запустить на 100Гц, надо попробовать. Эта идея возникала, но сразу отметалась по причине того, что порядка 80% измерений обеспечивается 10 Гц опросом. Только по двум последним контрактам пришлось делать 100Гц измерения (еще на старой системе на LM-модулях и LTC-модулях), тогда то и вылезла проблема синхронности разночастотных измерений. На самом деле, по-моему проблемы нет, это вопрос трактовки результатов, однако зарубежным заказчикам не понравились несовпадающие по фазе изменения параметров. Если компьютер не захлебнется потоком данных с одновременной обработкой, может перейдем на 100 Гц опрос.

Попробуем 100 Гц на всех LTR27. Спасибо!