Форум

Выяснилось что переключение невозможно пока не подключен USB кабель (текущий режим был IP). После подключения и перезапуска крейта появляется двойник крейта со значком USB. Так что сорри наверно за тревогу.

В общем и с USB интерфейсом работает - после того как модуль обнаружился в ltrmanager через IP я указал USB интерфейс и все заработало. Ваш пример https://gitlab.com/l-card/acq/devices/l … ecv/main.c
все откомпилировалось  и работает.

Да, lcard на виртуальной астре работает и отключения драйверов в windows не требуется. По крайне мере у меня сейчас отлично работает ltrmanager и он показывает и крейт и все его модули.
Вторая OC (перегружаемые поочередно) неудобно - я собираюсь взять значительную часть софта своего OPC сервера и сделать MQTT сервер. Быстрый доступ к windows (прямо из астры) ускоряет процесс.

Попробовал установить LCARD софт вручную без Synaptic - вроде все прошло без ругани. Главное что /etc/apt/sources.list
заполнил правильно.

sudo apt-get update
sudo apt-get install ltrd ltrmanager libltrapi1-dev

Буду пробовать что-то написать и скомпилировать.

Крейт LTR-EU-16-1 переход из Windows в Linux Astra.

Нельзя ли попросить уважаемый LCard выложить С++ исходник простого консольного приложения на C++, демонстрирующий работу с крейтами. Главное Хотелось бы сначала понять, что нужно чтобы заставить пример компилироваться, линковаться и работать. L-Card модуль для демо может быть любой, например LTR27.

PS:
Предполагается что программирование будет на Qtcreator.
Репозитарий http://download.opensuse.org/repositori … Debian_10/ установлен.

Продолжение о совместной записи модулей LTR114 и LTR27 (проблема рассинхронизации и как её убрать)

Кратко напомню о чем речь:
В одном крейте стоят LTR27 и LTR114. Задача вроде тривиальная - сделать так, чтобы мой OPC сервер записывал бы полученные данные (частота 10 Гц) в файл. Оцифровывалась синусоида с частотой 1 Гц - сигнал подавался на все модули.

Как я выяснил главная проблема - в получении одинаковой временной маркировки получаемых данных как на LTR27, так и на LTR114. Мы допустим сделали нитки разных модулей и вызываем функцию LTRxx_Recv. Но эти функции работают по разному у разных модулей.

LTR27:
Что происходит во время LTR27_Recv при кадре в 100 миллисекунд? Я могу считать время только после вызова LTR27_Recv. Но внутри этой функции сначала идет оцифровка, потом пауза и только после я могу считать системное время для маркировки полученных данных. Но у LTR27 после паузы время отличается от времени оцифровки на порядка 45 миллисекунд (плюс минус - зависит от состояния windows).

LTR114:
У модуля LTR114 (с последовательной оцифровкой каналов) похожее происходит когда у него 1 логический канал, но если их много, то пауза между реальным событием и измерением времени будет много меньше чем на LTR27. Время измеренное после LTR114_Recv будет гораздо ближе к времени оцифровки последнего канала. Значит, мы можем получить времена остальных параметров в буфере вычитая из в времени последнего параметра длительность оцифровки одного канала умноженное на индекс канала относительно последнего канала.

При записие двух модулей результат - синусоиды одного сигнала записанные разными модулями (LTR114/LTR27) не совпадают на графике, LTR27 отстает в среднем на 45 миллисекунд, но временами и больше.

https://i.ibb.co/C1SpDN6/image.jpg

Нужно заметить, что если работают все одинаковые модули LTR27, то проблема много меньше. Просто ошибка одинакова для всех каналов.

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

Второй вариант реальный - у LTR27 нужно сократить паузы после оцифровки. Т.е. максимально приблизить замер времени после LTRxx_Recv к моменту оцифровки. Этого можно достигнуть увеличив частоту дискретизации минимум на порядок.

Иначе говоря, для записи с LTR27 с частотой 10 Гц я задаю опрос модулей LTR27 в 200 Герц. В настойках моего OPC сервера я указываю, что во время записи записывать только каждое 20-е измерение.

Если так же записывать и LTR114, то результат будут еще идеальнее. Испробовано для длинных сериях.

Результат - отсутствие расхождения кривых разных модулей - идеальная запись!

https://i.ibb.co/hH2mLKm/image.jpg

Проблема временной маркировки на большой частоте опроса хорошо решается путем увеличения интервала считывая времени из системы.

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

Как возможное объяснение я могу предложить это

Конструкция замера времени после считывания

   CoFileTimeNow( (FILETIME*)&timestamp_recbuf ); 
   FileTimeToLocalFileTime((FILETIME*)&timestamp_recbuf, (FILETIME*)&timestamp_recbuf);

Не может дать точное время на таких частотах (мы говорим про 250Гц опрос). Как я выяснил эта конструкция не выдает микросекунд при замере (только миллисекунды), хотя и оперирует с 64битным числом. А это значит, что по крайней мере в windows XP расхождение времени двух параметров из разных потоков при замере времени таким способом может достать максимум двух миллисекунд, а в благоприятном случае время может совпадать.

Нашел в чем было дело. Я для теста сделал замер времени для LTR27 не после LTR27_Recv(), а до вызова (и забыл вернуть назад). Время работы функции LTR27_Recv и было неточностью. Упс.

Всё, разложил и разобрался, сделал правильное формирование времени блока тега (после LTR114_Recv()) Мне также помог случай, когда падение у меандра совпало с моментом измерения первого канала на LTR114 1Гц. Стало особенно ясно как последовательно измеряются каналы на LTR114 при низкой частоте опроса. Максимальное расхождение с опросом LTR27 10Гц не может превышать 1 секунду, что и было достигнуто.
https://wmpics.pics/di-6HCU.jpg

А как же тогда заполняются метки времени (массив tmark) при вызове LTR27_Recv()? Ведь каждая метка соответстует элементу принятого массива?