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

Здравствуйте!

Подскажите, пожалуйста, в чем может заключаться следующая проблема:
1. LTR Manager прекрасно видит как крейт, так и модуль в нем, когда в настройках крейта указан интерфейс крейта USB.
Но когда указывается TCP/IP(Ethernet) (с настроенным IP и маской подсети, шлюз, допустим, указан пустым), то виден только крейт,
но не видно модуля. ПК вместе с крейтом подключены к одной ЛС через обычный хаб.
2. При/после установки ПО последних версий (lcomp.exe, ltrd-setup.exe, ltrmanager_setup.exe, ltrdll.exe) утилита ltrctl не установлена.
(она желательна нам для общего единообразия в работе с другой ОС). Должна ли она устанавливаться в Windows. Об этом трудно судить из документации.

Спасибо.

Здравствуйте.
1. А подключенный крейт в LTR Manager при этом видится подключенным по какому интерфейсу (можно определить по значку крейта в дереве и интерфейс подключения в общих параметрах крейта на панеле статистики). Дело в том, что когда настраиваете крейт на Ethernet, то он все равно доступен по USB но только в режиме настройки (чтобы можно было сменить параметры) и в этом режиме настройки как раз не видно модулей, поэтому если сам USB не отключили, то это соединение в таком виде и останется.

Для подключения по Ethernet нужно добавить адрес крейта в LTR Manager в список IP-записей крейтов и нажать подключить по записи - эта операция проходит успешно?

2. Утилита ltrctl сейчас не устанавливается для Windows, т.к. не было запроса от пользователей - все же в Win не так часто пользуются командной строкой. Но если эта утилита нужна, то можно будет сделать для нее установщик под Windows.

По п.1 - разобрался. Да, так оно и есть.

2. Была произведена сборка ПО на одном из ноунейм ARM linux из исходников ltr_cross_reference. Если вас заинтересуют мелкие правки чтоб закомметить на bitbucket, могу на словах описать. (diff-файл не делал)
Под Windows ltrctl попробую собрать сам, если действительно будет актуально.

Да, если потребовались правки для сборки, то просьба их описать

Ничего существенного, но все же.
В исходнике ltrctl в  функцию f_crate_type_str() добавил поддержку крейта CEU-1-4
        case LTR_CRATE_TYPE_LTR_CEU_1:
            ret = "LTR-CEU1";
            mcnt = 1;
            break;
Иначе крейт - Unknown, а модуль не отображается (ltrctl clist)

При инсталляции (make install)
ltrd.service и ltr-crates.rules не устанавливаются вообще куда-либо, если не указать явные пути
set(SYSTEMD_SERVICE_INSTALL_DIR /lib/systemd/system)
set(LTRD_UDEV_RULES_DIR /lib/udev/rules.d)
(то есть добавить "/")

Поскольку делал сборку clang'ом (gcc слишком старый), то примеры некоторые не собирались из-за отсутствия линковки с математическими библиотеками (при этом библиотеки ltr собирались нормально)
Добавил в ltrmodule.cmake:

if(LTRAPI_MODULE_USE_MATH)
    ...
    if (CMAKE_C_COMPILER MATCHES "clang")
        set(LTRAPI_MODULE_LIBS ${LTRAPI_MODULE_LIBS} m)
    endif()
endif(LTRAPI_MODULE_USE_MATH)

Есть моменты, когда коды en_LTR_ERRORS присваиваются переменной другого типа t_flash_errs (возможно, это и важно)
(gcc это не обнаруживает)
ltr24api.c:688:33
flash_iface_ltr.c:222:12

Спасибо.
CEU добавил в ltrctl, хотя правильнее все же наверное название LTR-CEU-1 (с дефисом перед 1).

Несколько странно, вроде относительный путь должен устанавливать относительно префикса установки (CMAKE_INSTALL_PREFIX, который по умолчанию обычно /usr/local). Сходу не скажу, не нарушат ли абсолютные пути сборки каких-то пакетов, надо отдельно рассмотреть для решения какой вариант оставить. В принципе свои пути можно указать и явно один раз при вызове cmake через -DSYSTEMD_SERVICE_INSTALL_DIR=/lib/systemd/system -DLTRD_UDEV_RULES_DIR=/lib/udev/rules.d.

Clang явно не учитывал. clang как gcc позволяет собрать библиотеку без разрешения зависимости от внешних, но при исполняемом файле уже все зависимости должны быть разрешены. Добавил также как Вы в ltrmodule.cmake (только по общему условию с GCC).

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

Да, все правильно. Я ошибся.

Дело в том, что изначально делал сборку "как есть", то есть без игры с опциями (внутри ltrd настроек), - то есть чтобы собранная ltrd заработала хотя бы как обычное приложение. И только потом включил все остальное (LTRD_DAEMON_ENABLED - ON, LTRD_SYSTEMD_ENABLED - ON, LTRD_USB_ENABLED - ON).
Но cmake что-то кеширует со сборкой и не реагирует на такие изменения как option (или реагирует частично). В результате в тот момент, когда догадался удалить CMakeCache.txt, в CMakeLists уже стоял явный путь (после отчаяния увидеть ltrd.service где-либо на диске кроме исходников ;-))