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

Здравствуйте.
ОС АСТРА Linux
Имеется два LTR-EU-2-5
1. В первом  LTR-EU-2-5 установлен модуль LTR24-2v1 
2. Во втором LTR-EU-2-5 установлен модуль LTR24 -1v1.
Вопрос. Почему не работает обмен по ТСР/IP между клиентом и LTR-EU-2-5 укомплектованным модулем LTR24 -1v1, но с первым LTR-EU-2-5 и модулем LTR24-2v1 обмен с клиентом есть ?

Пояснения. В О.С.  оба устройства LTR-EU-2-5  и модули  инициализированы успешно.
прошивка одинаковая, 3.0.0.13
Устройства запускались в разных сетях  и разное время с перезагрузкой О.С.

Здравствуйте.
Честно говоря не до конца понял, что имеется ввиду под "не работает обмен по ТСР/IP между клиентом и LTR-EU-2-5" и "LTR-EU-2-5  и модули  инициализированы успешно".

В сами крейты какие настройки интерфейса записаны? Везде переключен интерфейс с USB на Ethernet? IP адрес одинаковый или разный?
В LTR Manager виден ли второй крейт, если нет, то какие сообщения выдаются в журнал при попытке подключиться по IP-адресу.
Если модули видны в LTR Manager, то что подразумевается под нерабочим обменом? Какая функция возвращает какую ошибку?

Модули LTR24-1 и LTR24-2 это две разные модификации модуля LTR24, выпускаемые одновременно (https://www.lcard.ru/products/ltr/ltr24 … =2#qt-ltab). LTR24-2 (в отличие от LTR24-1) имеет дополнительную возможность прямого подключения ICP-датчиков (возможность использования обычного диф. входа поддерживается обоими модификациями).

Клиентский крейт с модулями LTR24-1 (с которым некорректно работало клинское ПО) был проверен на штатном ПО Л Кард и каких-либо проблем с работой крейта и модулей выявлено не было.
При этом также были взяты  другой экземпляр крейта, модуля LTR24-1 и модуля LTR24-2 (имеющиеся в распоряжении Л Кард) и проверена работа с клентским ПО.
С модулем LTR24-2 клиентское ПО  сохраняло в журнал данные, в то время  как с модулем LTR24-1 клиентское ПО по журналу обнаруживает модуль и запускает сбор, но никаких данных в журнал не пишет. Каких-то явных признаков ошибок клиентское ПО не сообщает. При этом связь с крейтом и модулями службой ltrd устанавливается корректно и обмен данными происходит, явных признаков проблем с обменом данных с крейтом и модулем не обнаружено.
Таким образом работа клиентского зависит от модификации LTR24, но не зависит от экземпляра модуля, а также не зависит от типа и экземпляра крейта.

Из вышесказанного можно сделать вывод, что клиентское ПО написано таким образом, что корректно работает только с модификацией LTR24-2, но несовместимо с модификацией LTR24-1.

С точки зрения штатных библиотек работа с модулем LTR24-1 и LTR24-2 отличается следующим:
- библиотека предоставляет ПО явный логический признак, поддерживает ли модуль LTR24 прямое подключение ICP-датичков (истина для LTR24-2 и ложь для LTR24-1).
- если при конфигурации модуля для какого-то канала (в том числе не опрашиваемого) включен режим ICP, то для LTR24-1 библиотека вернет ошибку (т.к. этот режим не поддерживается), а для LTR24-2 примет эту конфигурации без ошибок.

Из чего можно предположить, что либо логика программы явно каким-либо образом использует признак поддержки подключения ICP датчиков, либо программа при конфигурации модуля устанавливает настройки, неподдерживаемые модификацией LTR24-1 (например, устанавливает не опрашиваемые каналы в ICP режим). Если клиентское ПО позволяет изменять количество опрашиваемых каналов, то можно попробовать настроить опрос всех 4 каналов, чтобы не осталось неиспользованных. Также если программа позволяет задавать настройки каналов, то проверить, нет ли настроек ICP режима, чтобы его можно было отключить.

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

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