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

Извиняюсь если вопрос некорректный.
Мне пришлось взять и вести не свой софт (исходники VC++ есть) для работы с LTR11,  LTR114 и LTR212. Всё выполнено в виде OPC сервера (OPC серверы мне знакомы). Работа каждого из модулей выполнена в виде отдельного С++/*.h файла. В программе есть casы типа
            case 0x1b1b: //27
            case 0x7272: //114
            case 0xd4d4: //212

Теперь стоит задача малой кровью добавить в крейт LTR11. Какой из трех модулей наиболее близок по программированию к LTR11 (вопрос - на основе какого модуля мне будет легче сделать добавку LTR11?) Также по аналогии я добавлю
            case 0x0b0b: //11

Думаю должно получиться. Раньше с LTR дело не имел, возможно я сам разберусь после прочтения мануалов, но хотелось бы услышать совет.

Ну с точки зрения программирования LTR11 скорее похож на несколько упрощенный LTR114. Если там используются стандартные библиотеки ltrapi, то в принципе работа с модулями достаточна похожа.

А что на выходе выдает OPC-сервер? Используете для встраивания в какую-то SCADA-систему?

На всякий случай скажу, что Л Кард в качестве заказной работы может адаптировать под задачи клиентов свой OPC-сервер.

Спасибо, начну с него.

Да для работы с LTR используется стандартные ltrapi библиотеки.

OPC сервер выдает тэги типа u1_m1_c1. Также имеется встроенная запсиь данных в файл (для скоростного опроса).

Решается ли как-то в этом случае проблема скоростной записи? Я так понимаю, что сам OPC сервер работающий с крейтами должен это поддерживать, так как две разные программы не могут работать с крейтом одновременно?

А что в этих тегах возвращается?

А можно подробнее, что именно Вы имеете ввиду под скоростной записью? Какую именно задачу решаете?

Точнее две разные программы не могут напрямую работать с одним и тем же модулем.

Возвращается значение с плавающей точкой (один параметр - одно значение). Т.е. к каждому параметру привязан OPC тег, и  значение с него считывается программой клентом.

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

Про тэги это понятно, я хотел как раз узнать, что за рассчитанные пораметры он возвращет.

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

Это потребует серьезной переделки как серверной так и клиентской части, а достижение многокилогерцовых записей не факт, что будет - OPC медленный механизм.

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