Форум

Вопрос вариантах о перезапуска процесса сбора данных при сбое:
Собираем данные в нескольких потоках с модулей LTR114, LTR212-M3.
Допустимо ли в потоках сбора (см.далее) данных для модулей LTR114 и LTR212-M3 после выхода из циклов сбора данных в потоках сбора данных выполнять только LTR114_Stop или LTR212_Stop и после этого не закрывая поток возвращаться на подготовку цикла и далее повторный запуск цикла сбора
данных; а LTR114_Close и LTR212_Close выполнять только в основном потоке при закрытии программы после остановки всех потоков сбора данных?

В настоящее время алгоритм выглядит так:
1) Сначала загружаем настройки для модулей LTR114 и LTR212 в главном потоке.
Функции настройки LTR114:
LTR114_Init,LTR114_Open,LTR114_GetConfig, LTR114_CreateLChannel,LTR114_SetADC
Функции настройки LTR212:
LTR212_Init,LTR212_Open,LTR212_CreateLChannel,LTR212_SetADC

2) Далее создаем потоки для сбора данных отдельно для каждого модуля.

2-LTR114) Поток для LTR114
Подготовка цикла:
    LTR114_Calibrate,LTR114_Start
Цикл:
    LTR114_Recv,LTR114_ProcessData
После цикла (при сбое):
    LTR114_Stop,LTR114_Close

2-LTR212) Поток для LTR212
Подготовка цикла:
    LTR212_Start,LTR212_CalcTimeOut
Цикл:
    LTR212_Recv,LTR212_ProcessData
После цикла (при сбое):
    LTR212_Stop,LTR212_Close
Потоки завершаем.
Перезапускаем при сбое программу целиком.

В новом проекте добавится модуль LTR12.

Вопросы по LTR114.

Запустили систему из 4 8-слотовых крейтов с модулями LTR114 и LTR212M-3. Иногда происходит аварийное завершение в потоке сбора данных одного из модулей LTR114 с кодом -10010 "Неверный номер канала в массиве данных от модуля":
04.01.2024 в модуле sn:4T777790, Firmware version AVR: 1.3, Firmware version PLD: 1.
22.02.2024 в модуле sn:4T777799, Firmware version AVR: 1.3, Firmware version PLD: 1.

Вопрос 1) Аварийная ситуация возникает внутри крейта на уровне взаимодействия крейта и модуля? Снаружи сеть не виновата? (Вроде бы вполне надежная оптика).
Вопрос 2) Какие меры можем предпринять, чтобы в дальнейшем устранить эти проблемы? Или только рестарт нашей программы?

Часто при попытке подключения по сети к крейтам LTR получаем отказ. По диагностике так понимаем, что кто-то захватил уже доступ (только непонятно кто). Приходится передергивать питание крейта, чтобы подключиться. Другие варианты восстановления доступа существуют?
Какие посторонние приложения могут захватить доступ к крейтам? Какие варианты запрета захвата крейтов сторонними программными средствами можете предложить? Или только отключение и включение?

Программой LGraph2 в свободных каналах LTR114 наблюдается импульсная помеха напряжением до 10 В.
В каналах измерения напряжения также присутствует импульсная помеха. В чем причина?

Крейт пингуется, но в LTRManager не подключается. Ошибка -507. Иногда подключается, иногда не подключается. День на день не приходится.
Есть ли возможность без передергивания питания перезапустить крейт. Если есть такая функция в ltrapi, пожалуйста, укажите.
Если такой возможности нет, можно ли как-либо "реанимировать" крейт через TCP?
Кстати, и под winows7 перед этим вел себя так же.

Система AltLinux.
В предыдущие дни обычно крейт был виден. Запускали ранее пример для сбора данных с LTR114, переделанный из примера LCard, в котором сбор данных идет через отдельный поток, как в примере LCard для LTR212.
Прекрасно работал. Крейт был виден.

В ответе на запрос про дистрибутивы под Linux от 28.07.2023 (https://www.lcard.ru/forums/viewtopic.php?id=10590) сообщалось, что для AltLinux отсутствуют пакеты от LCard и что их надо собирать из исходников.
Приведите, пожалуйста, подробную инструкцию по сборке под AltLinux этих пакетов из исходников (и доступны ли эти исходники).
Использование этого варианта Linux является требованием отраслевого руководства заказчика.

В потоках сбора данных LTR114 иногда возникает ошибка -10017, а в потоках сбора данных LTR212 - ошибка -2026.
Судя по именам констант в заголовочных файлах модулей, это ошибки, связанные с каким-то сбоем счетчика пакетов.
Как можно купировать эти ошибки?
Можно ли продолжать процесс получения данных при этих ошибках, ограниченно обработав результат или просто проигнорировав эту порцию данных?

Рассмотрим варианты:

1) Игнорируем данные и продолжаем сбор данных, если LTR не выбросит нас из процесса сбора данных.
2) Делаем в потоке _Stop() и сразу _Start(). (Или потребуется перезапускать процесс сбора данных?)
3) Какой есть в этом плане опыт у LCard?

Поясните, пожалуйста, какие необходимо задать значения размеров массивов recv_data и proc_data в функциях

LTR114_Recv(&hltr114, recv_data, NULL, size, STREAM_RECV_TOUT);
LTR114_ProcessData(&hltr114, recv_data, proc_data, &size,LTR114_CORRECTION_MODE_INIT, LTR114_PROCF_VALUE);

для приведенного далее примера:

hltr114.FreqDivider = 2;
hltr114.LChQnt = 8;
hltr114.Interval = 152;
Длина буфера соответствует 1сек.
(Хотим получить каждую секунду по 25 значений с каждого из 8 каналов)