Добрый день. Используем крейт LTR-EU-16 с набором различных модулей, пока наиболее тесно работаем с LTR114. Крейт работает в условиях больших наводок (рядом с импульсным генератором). Практика показала, что LTR114 чувствителен именно к электромагнитной наводке (собираемся делать навесной экран на весь модуль). В процессе работы следим за типами ошибок, наиболее распространенные -10010, -10016 и -10017. Без экрана почти каждое вычитывание и обработка данных заканчивается ошибкой. Чаще всего появляеется ошибка -10017, даже когда импульсный генератор не работает. Насколько понятно из описания -10017 некритичная ошибка, которая даже не приводит к отбраковке принятых данных. Тем не менее, хотелось бы услышать комментарии по поводу появления этой ошибке "в спокойной обстановке" и наиболее адекватные способы восстановления после появления остальных типов ошибки (особенно -10010) (закрыть и снова открыть соединении с модулем, например).

Алексей, давайте всё-таки сначала электрический аспект проблемы посмотрим:
1. Винты на панелях LTR114 завинчены? Проверьте тестером на Ом-ах, есть ли электрическая связь  металлической части разъёма DRB-37 каждого модуля с клеммой заземления (корпусом) крейта.
2. "Крейт работает в условиях больших наводок (рядом с импульсным генератором). Практика показала, что LTR114 чувствителен именно к электромагнитной наводке..." - чувствителен  даже тогда, когда разъём к LTR114 не подсоединён?
3. В неиспользуемые посадочные места крейта, если таковые имеются, панели-заглушки установлены?
4. Что за импульсный генератор? Какой его тип, мощность, характеристики импульсов?
5. Перечислите всю аппаратуру в Вашей системе, и опишите по какой схеме они заземлены.
6. Используете Ethernet или USB?
7. Какую конфигурацию модулей LTR применяете? Ошибка происходит в одном модуле или сразу в нескольких?

А что за ПО используете? Если свое, то при использовании, например, LGraph2 эти ошибки проявляются? Не до конца понял, есть ли условия, при которых этих ошибок не возникает и все работает нормально?

1. Винты завинчены.
2. Чувствиелен даже тогда, когда ничего не подсоединено.
3. Заглушки установлены почти все, не хватает пары в самой дальней части от LTR114.
4. Пара слов в следующем абзаце.
5. Зарядное устройство на 5 кВ, модулятор с тиратроном для формирования импульса тока длиной порядка 300 мкс для питания магнита, кабельная трасса несколько десятков метров и набор резисторов в качестве нагрузки, блок запуска тиратрона, осциллограф, генератор импульсов и собственно LTR крейт с модулем LTR114. Крейт, ЗУ, модулятор и блок запуска тиратрона находиться в одном 19" шкафу. Крейт как можно дальше от модулятора.
6. Ethernet
7. Пока используем только LTR114.

Постепенно исключая возможные пути помехи по проводам, пришли к выводу, что основной вклад дает электро-магнитная наводка. Помог экран из медных пластинок расположенных непосредственно рядом с LTR114.
Да, еще один момент. Используем внешнее тактирование LTR114, с внутренним количество ошибок уменьшается, но не становится нулевым.

ПО свое. В более ранних вопросах  (конец мая) я сообщал, что LGraph2 отказывается нормально запускаться, поэтому им совершенно не пользуемся. Иногда пользуемся LComp и PowerGraph.
Условия при которых наблюдалась бы долговременная стабильность работы (несколько часов) не были достигнуты. Самая частая ошибка -10017. Хотелось бы услышать комментарии именно по адекватному реагированию на ошибки. Можно ли именно эту, например, просто игнорировать?

Немного слукавил. Сегодня проверяю на столе, за пару часов ни одной ошибки. Использую только внутреннее тактирование, без каких-либо внешних подключений.

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

Про сбои и общую идеологию восстановления после сбоев написано в руководстве 
http://www.lcard.ru/download/ltr.pdf , п.3.9.2.
В Вашем случае, на сколько я понял, сбои носят не фатальный характер, т.е. дальнейший сбор данных от модулей продолжается, но поток данных от модуля был либо разорван (непрерывность точечно нарушена), либо валидность данных точечно не была обеспечена. В этой ситуации есть два варианта реакции: перезапуск данного модуля (через RESET), либо игнорирование ошибки. В последнем случае, нужно понимать, что если потоки данных от разных модулей Вы обрабатывали совместно, с учётом взаимных задержек данных, то после сбоя потоки нужно снова засинхронизировать (по тем признакам синхронизации, которые использовались). Замечу также, что используемый механизм обнаружения сбоев в LTR не гарантирует обнаружение всех сбоев. Этот механизм только в статистическом смысле отвечает на вопрос: были обнаружены сбои или нет. И если были, то это сигнал о том, что  присутствуют проблемы электромагнитной совместимости в данной обстановке и при данном подключении.

Возьмите программу отсюда.
ftp://ftp.lcard.ru/pub/ltr/ltrtest2.zip
При запущенном LTR-сервере нужно сначала нажать "Найти крейты", а потом запустить тест. Поставьте на длительный прогон в нормальных условиях. О результатах сообщите, пожалуйста.

Имеют смысл два эксперимента c LTRTEST2:
1. Когда разъёмы LTR-модулей не подключены.
2. Когда разъёмы LTR-модулей подключены и все сигнальные цепи и цепи заземления Вашей установки подсоединены, но генератор электромагнитных  полей выключен.

Обязательно проверим, но сейчас немного занялись другим. А именно метками старт. Добавил LTR41 и обнаружил, что счетчик меток не сбрасывается как это описано в даташите. Начало смущать то, что на различные програмные манипуляции с параметрами функции LTR114 приводят к ошибке -10010 или -10017 (изменение частоты вызова функции чтения, таймаута, количества ожидаемых данных).

А при приеме Вы корректно проверяете размер принятых данных, который вернул LTR114_Recv(), что он соответствует тому, что запрашивали?

Вообще не проверяю. Я заведомо большее количество точек запрашиваю, чтобы не отставать от заполнения буфера. Зачем нужно проверять, если я и так знаю, что вернул меньше?

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

Честно говоря, не делал, просто задавал целое число.  Какой смысл в таком случае функцию приема было реализовывать в таком виде? Если запрос на нецелое количество кадров приведет в дальнейшем к ошибке? Почему просто не передавать количество кадров?

Ну теоретически никто не мешает принимать и не целыми кадрами, но потом их собирать и уже передавать кратным количеством в ProcessData….

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

Может, но это не влияет на прием. Метки обрабатываются специальным образом и возвращаются из Recv отдельным массивом tmrak. Так что в массиве данных, которые вернула Recv только данные от самого LTR114

Это понятно. что метки в массиве tmark. Мой вопрос был в сторону соответствия индексов массивов. То есть, индекс элемента tmark, в котором зафиксировано изменение значения счетчика меток может соответствовать как первой части кадра данных АЦП, так и второй. Такое положение вещей требует дополнительной проверки количества данных до метки в "сыром" массиве данных на кратность размеру кадра до передачи функции обработки. Я правильно все понимаю?

Метка может прийти в любой момент, они привязаны только к "сырым" словам и изменение индекса в tmark может быть и в середине кадра. Что с ними делать дальше уже зависит от Вашей задачи.

В таком случае как различать части кадра АЦП в сыром виде? По значению 22 бита? Я вывожу его значение у четырех последовательно расположенных элементов сырого массива и не вижу чередование 1 и 0.

Я имею ввиду различать части кадра в массиве, заполение которого происходить во время работы функции LTR114_Recv()

Так как данные идут непрерывно, то самый простой способ – это по кол-ву слов принятых от начала сбора (каждое слово с номером, кратным FrameSize – начало кадра). Если нужно по формату слов различать первое слово отсчета или второе – то это 4-ый бит (маска 0x08)

Алексей, я хочу напомнить Вам, что вопрос о стабильности работы ПО Вы уже ставили в марте 2013 г. http://www.lcard.ru/forumthreads/13905  Я тогда ещё просил Вас протестировать LTR с помощью LTRTEST2, и ответа Вас не получил, что крайне осложняет техническую поддержку...

И в прошлый раз и сейчас при прогоне LTRTEST2 ошибок не возникало. Я уже понял, что ошибки -10010 и -10017 могут появляться при некорректном использовании функции обработки, когда в исходном массиве присутствуют обрывки кадров (это может быть либо в начале массива, либо в конце, насколько я понимаю). Внешние наводки лишь усугубляют ситуацию.

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

Действительно, в руководстве этого нет. По-видимому, пользователи эту информацию и не используют, т.к. вопросов не было. Выслал Вам формат по почте.