Форум: Техническая поддержка

Большая просьба дать рекомендации по выбору архитектуры системы непрерывного мониторинга на базе LTR на основе опыта LCard.
Не хотелось бы тратить время, которого всегда мало, на дополнительное тестирование вариантов.

Рассматриваем такие варианты:

1) Один главный поток и по одному потоку для каждого крейта.
Главный поток настраивает аппаратную синхронизацию крейтов, задает параметры каждого модуля для сбора данных, запускат сбор данных  системы, получает очередные порции данных от каждого потока крейта для отправки их в хранилище.
Поток для крейта последовательно собирает очередную порцию данных  с каждого из модулей крейта и подготавливает эти данные для передачи  в главный поток.
Итого 5 потоков.

2) Один главный поток и потоки для каждого модуля с аналогичными функциями.
Итого 17 потоков (=1+8(для LTR114)+8(для LTR212).

ПОДРОБНОСТИ О СИСТЕМЕ:

1. Для нашей системы закупили 4 крейта LTR-EU-8-1 и по 8 модулей LTR114 и LTR212M-3.
Каждый крейт содержит LTR114 и LTR212M-3.
2. Система должна непрерывно получать и сохранять данные с этих модулей в единое хранилище фрагментами по 5 сек.
3. Для модулей LTR114 предполагаем частоту оцифровки 25Гц (или 50Гц).
Модули LTR212M-3 используются в 4-канальном режиме высокой точности с запитывающим мост напряжением 2.5В.
Протестировал один модуль LTR212M-3, в котором используются все 4 канала, с помощью примера LCard для LTR212 (ltr212api_bcb6.zip - адаптировал для Qt и mingw32 под Win7 Pro 64бит), а также ltreu_marks_delphi (ltreu_marks.zip)для старта временных меток.
Между 2 событиями "СЕКУНДА" удается собрать в среднем по 35.75 значений по каждому каналу LTR212M-3.
Видимо на эту частоту оцифровки и следует нам опираться.
4. Макет (консольное приложение) собирается под Windows.
Затем будет перенесен под Linux (тестируем сначала на Ubuntu 20.04, потом переносим на AltLinux 10).

1) Ну с подходом, тут однозначно правильного и неправильного нет, можно получить рабочий результат разными способами.

Я использую вариант, в котором сбор данных с каждого модуля выполняется в своем индивидуальном потоке, т.е. сюда входит по крайней мере цикл Recv/ProcessData/обработка tmark, плюс возможна какая-то минимальная обработка (например если требуется перевод в физические величины). В нем отпадает куча моментов, связанных с приемом данных от разных модулей в одном потоке, особенно когда не у всех одна частота. А дальше уже результаты сбора каждым потоком отправляются в отдельный поток для сохранения результатов. Главное только обеспечить, что генерация метки, по которой будет привязка к началу, была выполнена после старта сбора всех модулей, чтобы найти ее в данных, т.е. либо все начальные операции из общего потока, либо открытие/настройка/запуск может быть из индивидуального потока модуля, но он тогда должен оповестить об этом главный, а главный по приходу оповещений от всех запущенных потоков на модуль уже запустит метку для синхронизации начала данных.  17 потоков в общем это не много.

2) С частотой LTR212 у Вас что-то странное. Должно быть около 150,15, можете выложить минимальный проект примера, с помощью которого Вы получаете значение 35.75 ?

=====
С частотой оцифровки разобрался. DWORD временной метки относится к всему кадру из 4 каналов, поэтому между событиями СЕКУНДА все время около 151 кадра данных. Минимальный проект адаптированного примера: ссылка LTR212 в записи http://krym52.ru/k-forumu-lcard/
Только обнаружил, что между событиями СЕКУНДА, кроме 151 кадра, встечается и другое количество (144 или 143).
Это проявление непостоянства частоты оцифровки или признак битых кадров данных по 4 каналам?