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

разбираюсь в тонкостях написания плагина, появились вопросы:
Возможна ли работа плагина, который сам бы выдавал данные, не получая входных данных?
например, виртуальный прибор выдающий синус?
я так понимаю, если в настройках плагина стоит ноль входных переменных, то он с lgraph-ом должен работать самостоятельно, не завися от других приборов.

вопрос второй:
в описание указано, что в плагин передаются все кадры независимо от кол-ва входных переменных. например, у меня есть прибор Е20-10, подключено 4 входа, а в плагине использую 2 и 3й, то формат кадра для плагина будет таким:
1 вход, 2 вход, 3 вход, 4 вход ?
соответственно я должен из них выбрать 2 и 3.

Нет, плагину надо в любом случае получать какие-либо данные.

Имеется в виду, что передаются кадры с включенными в настройках каналами АЦП. Если Вы в настройках ЛГраф2 включите только 3 и 4 входы, то и  в плагин будут поступать кадры, состоящие только из двух каналов.

подскажите пожалуйста как оптимальнее сделать:
один плагин, в котором будут 2 входных канала с Е20-10 и 4-5 расчетных каналов на выходе.
или три-четыре плагина один вход и один выход?

есть ли рекомендации по значениям параметров:
input_kadrs_min, input_kadrs_max, max_points_from_plugin ?

Оптимальнее сделать один плагин с 4-5 каналами.

Конкретных рекомендаций нет.

• input_kadrs_min определяет, сколько кадров должно придти от АЦП, прежде чем будет вызван плагин

• input_kadrs_max определяет, какое максимальное число кадров может обработать плагин за один вызов

• max_points_from_plugin можно вообще не задавать, при явном указании помогает ЛГрафу более оптимально выделять память.

Добрый день, если нет плагина "виртуальное устройство" для генерации данных, посоветуйте куда копать...

Ситуация в следующем: имеется E20-10, но удаленный и предполагается с ним работать по локальной сети. Как лучше его подключить к Lgraph? Как расчетный плагин? или можно ли как-то зарегестрировать свой тип оборудования, прокси над  E20-10.
Буду благодарен любым идеям 

Все равно же придется писать две программы (клиент и сервер) для удаленного сбора данных. Может быть, тогда уж проще сделать и визуализацию/регистрацию свою.
Хотя теоретически можно взять ltrd или ltrserver и приделать к нему виртуальный однослотовый крейт с каким-то модулем АЦП, максимально похожим по функциональности на E20-10.

А еще есть вроде бы всякий софт (виртуальные USB хабы) для проброса USB через TCP/IP - что-то коммерческое, что-то свободное. Попробуйте поискать в сети "usb device over tcp/ip".
Правда, мы с нашими приборами такого не тестировали - но идея, кстати, интересная.

Наконец, можно просто сделать удаленную консоль (RDP, VNC) на компьютер, к которому подключен прибор Динамическая отрисовка осциллограммы, правда, вряд ли будет красиво выглядеть при этом.

RDP, VNC - это не совсем то, а вот USB через TCP/IP мысль интересная... можно попробовать поискать, спасибо 

USB через TCP/IP - халява не прокатила, устройство не распозналось должным образом  .

Начал разбираться в исходниках ltr_cross_sdk на предмет подключения E20-10 к ltrd.
Куда лучше встроиться, от куда начать? В файле ltrsrv_usb_libusb.c нашел список подключаемых устройств:

f_crates_id_list[] =
{
    { 0x0471, 0x3131},
    { 0x0471, 0x3030},
    { 0x0471, 0x2121},
    { 0x0471, 0x1010}
};

сюда прописал E20-10

...
{ 0x0471, 0x2010}
...

и дальше хожу отладчиком...  устройство открывается, получается его имя, но дальше пока ошибка LTRSRV_ERR_USB_TRANSF_TOUT (-607)...
Я в верном направлении пошел или есть более адекватное решение?

Хм... добавления модуля к ltrd задача интересная, хотя и не очень простая. Что проще - добавить в ltrd или написать свой сервер так и не скажешь. С одной стороны в ltrd уже есть некий интерфейс для работы как с устройством, так и с клиентами, с другой стороны есть привязка к протоколу крейтов.

А под какой ОС Вы это делаете? Просто по-умолчанию вообще ltrd работает с USB устройствами под Windows через lcomp, а под linux - через libusb (хотя при желании можно собрать, чтобы работать и под Windows через libusb, если  поставить соответствующий драйвер). Соответственно в файлах ltrsrv_usb.c идет общая логика, а в ltrsrv_usb_libusb.c и ltrsrv_usb_lcomp.c - зависящая от того, что используется. В последних файлах Вам скорее всего не придется что-либо менять (таблицу id модулей я кстати в последней версии тоже перенес в ltrsrv_usb.c, архив с исходниками обновил), а вот в  ltrsrv_usb.c изменять придется, так как E20-10 имеет совсем другой набор управляющих запросов.

В общем по логике устройства проверяются по таблице id в ltrsrv_usb_libusb.c/ltrsrv_usb_lcomp.c в f_check_devlist (которая и не должна меняться), а затем уже при обнаружении нового устройства вызывается p_usb_add_new_dev(), а вот в ней уже начинается последовательность управляющих запросов для инициализации крейтов. Начинается с получения имени через start_ioctl, а обрабатывается завершение запросов в p_usb_process_ioctl. По завершению инициализации вызывается ltrsrv_crate_register() для регистрации в системе. GET_MODULE_NAME у вас пройдет и для E20-10, а остальные запросы уже специфичные для крейта, но в вашем случае инициализация может быть совсем минимальной - можно даже сразу после получения имени завершать.

Кроме того изменится несколько логика обработки данных, так как в крейтах в каждом слове есть номер слота и в ltrsrv_crates.c это обрабатывается, как и обработка некоторых специфичных слов для крейтов. Вам же данные надо будет передавать без изменений между устройством и клиентом.

Кроме того, Вам конечно понадобится по сути переписать API работы с E20-10, чтобы оно работало через ltrd, а не напрямую через USB (можно с использованием ltrapi).

В общем и целом конечно задача выглядит достаточно объемной. А почему Вы остановились на использовании E20-10 по локальной сети, а не рассматриваете использование каких-либо модулей LTR для этого?

Сложный вопрос
Протоколы обмена по USB у LTR и у E20-10 не имеют практически ничего общего.
На самом деле я думаю, что задача сделать эмуляцию LTR-xx (чтобы штатный LGraph работал с E20-10, думая, что это LTR-xx) будет посложнее, чем написать клиент-сервер для проброски данных и собственную визуализацию. Объем кода, может, в последнем случае и больше, а вот его придумывание...
(Это надо сначала выбрать по описанию такой модуль LTR, режимы которого покрывают нужные режимы E20-10 хотя бы "с точностью до константы". Потом разобраться в протоколе обмена ltrd с крейтами и сделать, например, виртуальный одноместный крейт - программную модель - то есть что-то типа плагина, вызовы которого вставить вместо чтения/записи в usb, чтобы он в свою очередь работал с E20-10 и прикидывался LTR-xx...)
Честно говоря, я бы рекомендовал этот вариант в последнюю очередь. Уж очень он вычурный.

Для собственной визуализации, кстати, могут подойти и какие-то готовые библиотечные решения. Тем более что не нужна универсальность LGraph, можно писать прямо под свою задачу только то, что потребуется.

Кстати, тут еще надо отслеживать экономику задачи - если затраты на разработку собственного решения превысят стоимость LTR-EU-2 с каким-то подходящим измерительным модулем, получится обидно.

Е20-10, по-своему, уникален, и аналогов из LTR, у него, увы, нет (210-й может только в буфер пару-тройку секунд и всё ). Отсюда и задача: удалённый одноплатный комп с гигабитом с подключёнными Е20-10 (2 шт). От него сетевое соединение с основным компьютером для сбора данных, А ориентация на LGraph2 (его функционал очень удачен по опыту использования) связана с тем, что помимо "удалённых" данных нужно одновременно (с синхронным стартом) собирать данные от локальных (подключённых к USB основного компьютера модулей Е20-10).

Хм.... ну если к LGraph2 цеплять, то придумывается разве что переписать логику работы с E-20-10 в lcomp (правда тогда нельзя будет работать локально с E-20-10), правда адрес удаленной машины тоже не понятно как задавать... В таком случае наверное проще свой простой сервер написать на удаленном компе. В любом случае это конечно очень объемная работа...

А Вам нужно именно 10 МГц или Вы на меньшей частоте работаете?

И нужно собирать одновременно (а анализируются уже потом) или их отображать во время сбора вместе (и возможно анализировать). И какой именно функционал LGraph2 Вы используете?

Да, используется 10 МГц.

Предполагается в LGraph2 получить данные от Е20-10 (как локальных по USB, так и удаленных) и отобразить их на графиках, во время сбора. Интересующие фрагменты записываются в файл для пост-обработки.

Где-то нужно свести устройства (локальные и удаленные) к общему знаменателю... либо на уровне сбора данных и воспользоваться готовой визуализацией LGraph2... либо на уровне визуализации, на уровне плагина который будет собирать данные и отображать с разных источников... либо еще где 

  Кстати, а что есть к локальным Е20-10 в LGraph2  написать "расчетный плагин" который и будет "виртуальным устройством". Таким образом 4 канала Е20-10 расшираются до 8 (еще 4 от удаленного)... процесс отрисовки/записи данных остается неизменным... останется только прокинуть команды по сети...
Я так понимаю что это укладывается в текущую структуру LGraph2.

А как будете локальный и удалённый E20-10 синхронизировать? Допустим, "старт" от ведущего к ведомому можно передать по какому-то отдельному гальванически изолированному каналу. Но для синхронизации  частот преобразования E20-10 понадобится синхронизированные друг от друга источники опорной частоты 10 МГц для каждого E20-10.

Синхронизируем только старт именно так, как Вы описали. Синхронизировать опорную частоту не представляется возможным, а с учётом 50 ppm, планируемым временем записи и допустимым "уходом", в принципе, не обязательно.

Работаем 4 х 2,5 МГц (можем 3 х 2,5 или даже 2 Х 2,5, если это что-то меняет в плане более простого решения). Вы имели в виду в пределах ли возможностей крейта LTR или имелось в виду что-то другое?

Юрий, например аналог L-502, но виде коробочки с Ethernet Вас устроил бы? - В этом случае потребовался бы только гигабитный коммутатор Ethernet...

Александр, теоретически (с точки зрения тех.характеристик) устроил бы в виде 4х таких коробочек (4 канала) и гигабитный свитч. Что Вы имели в виду?

Юрий, на днях будет анонс на эту тему. Следите за нашими новостями.

Александр, анонс - это хорошо, а когда планируется производство (когда можно будет купить)?

Юрий, подробности спросите в нашем отделе продаж.