| Автор |
Сообщение |
|
Сообщение создано: 31. 03. 2015 [17:21]
|
|
dekoder
Павел Дегода
Создатель темы
Зарегистрирован(а) с: 31.03.2015
Сообщения: 7
|
Пытаюсь реализовать следующую конфигурацию: есть контроллер, который работает по своему протоколу. Он должен сам по TCP к Openscada, а инициатором обмена уже является она. Насколько я понял, нужно использовать "Режим ассоциированных исходящих транспортов для входящего".
Создаю входящий транспорт в сокетах. Оставляю транспортный протокол у него пустым. Адрес пишу так: TCP::5555:1. Теоретически, насколько я понимаю, теперь при подключении на этот сокет должны создаваться ассоциированные исходящие транспорты. Но этого при подключении не происходит. То есть соединение с сокетом устанавливается, а никаких транспортов не появляется. Видимо, я чего-то недопонял. Что нужно сделать, чтобы эти транспорты создавались?
Openscada версии 0.8.12 на Ubuntu 14.04.
|
|
Сообщение создано: 01. 04. 2015 [08:38]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
"dekoder" wrote:
... теперь при подключении на этот сокет должны создаваться ассоциированные исходящие транспорты. Но этого при подключении не происходит. То есть соединение с сокетом устанавливается, а никаких транспортов не появляется. Видимо, я чего-то недопонял. Что нужно сделать, чтобы эти транспорты создавались?
Openscada версии 0.8.12 на Ubuntu 14.04.
Нет такой функции в LTS (0.8).
Используйте Work (0.9) версию для этого!
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 01. 04. 2015 [10:38]
|
|
dekoder
Павел Дегода
Создатель темы
Зарегистрирован(а) с: 31.03.2015
Сообщения: 7
|
Действительно, в версии 0.9 работает. Я увидел что ассоциированные выходные транспорты получают ID типа inAss<ID входного>_<номер>. Теперь можно с ними работать. Только не понятно как узнать общее количество созданных выходных транспортов или получить их список. Может быть есть пример такой команды?
[Сообщение редактировалось 2 раз(а), в последний раз 01.04.2015 в 17:02.]
|
|
Сообщение создано: 01. 04. 2015 [22:23]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
"dekoder" wrote:
Действительно, в версии 0.9 работает. Я увидел что ассоциированные выходные транспорты получают ID типа inAss<ID входного>_<номер>. Теперь можно с ними работать. Только не понятно как узнать общее количество созданных выходных транспортов или получить их список. Может быть есть пример такой команды?
Можно было запросить и отобрать из общего списка выходных транспортов, с помощью nodeList().
Сейчас добавил специальную функцию assTrsList(), выгружу позже.
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 04. 04. 2015 [12:03]
|
|
dekoder
Павел Дегода
Создатель темы
Зарегистрирован(а) с: 31.03.2015
Сообщения: 7
|
Спасибо! С этим разобрался.
Есть ещё один момент, который хотелось бы понять. Если использовать ассоциированный транспорт с протоколом Modbus, например так:
req = SYS.XMLNode("RTU");
req.setAttr("id","test").setAttr("reqTm",1000).setAttr("node",1).setAttr("reqTry",0);
req.setText(Special.FLibSYS.strEnc2Bin("03 00 00 00 05"));
SYS.Transport.Sockets.out_inAsstest_0.messIO(req,"ModBus");
...
всё работает, но! Ассоциированный транспорт при создании у меня получает временные интервалы 5:1, то есть время ожидания ответа 5 сек и время ожидания продолжения ответа 1 сек. При обращении на этот транспорт можно выставить в атрибуте reqTm необходимое время ожидания, а вот время ожидания продолжения не понятно как. Из-за этого происходит ожидание 1 секунду, даже если уже всё быстренько пришло. Пробовал менять с помощью функции cfgSet("TMS","2:0.1"), видимо не верно, хотя, например, поле NAME так менять получается.
Собственно, вопрос: есть возможность задать нужные тайминги при создании ассоциированного транспорта или как-то установить после?
|
|
Сообщение создано: 04. 04. 2015 [14:34]
|
|
dekoder
Павел Дегода
Создатель темы
Зарегистрирован(а) с: 31.03.2015
Сообщения: 7
|
Сам спросил - сам отвечаю:
req = SYS.XMLNode("set").setAttr("path","/sub_Transport/mod_Sockets/out_inAsstest_0/%2fprm%2fcfg%2fTMS").setText("2:0.1");
SYS.cntrReq(req);
хотя вариант с
SYS.Transport.Sockets.out_inAssus_0.cfgSet("TMS","2:0.1");
у меня не заработал.
Интересно, есть ещё варианты решения этой задачи?
|
|
Сообщение создано: 04. 04. 2015 [17:38]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
"dekoder" wrote:
req = SYS.XMLNode("set").setAttr("path","/sub_Transport/mod_Sockets/out_inAsstest_0/%2fprm%2fcfg%2fTMS").setText("2:0.1");
SYS.cntrReq(req);
Правильно.
"dekoder" wrote:
хотя вариант с
SYS.Transport.Sockets.out_inAssus_0.cfgSet("TMS","2:0.1");
у меня не заработал.
Потому-что "TMS" (тайминги) считались неосновным параметром и такого поля отдельно в БД нет, а есть группа "A_PRMS" (доп. параметры).
Хотя сейчас уже считаются и внутри так как нужно здесь вызываются, но для совместимости всё ещё хранятся в "A_PRMS".
Позже добавлю спец-обработку для cfgGet() и cfgSet() или таки выделю им отдельное поле БД.
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 06. 04. 2015 [10:54]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
"roman" wrote:
Позже добавлю спец-обработку для cfgGet() и cfgSet() или таки выделю им отдельное поле БД.
Добавил специальные функции, что более правильно: http://wiki.oscada.org/Doc/OpisanieProgrammy#h920-14
Learn, learn and learn better than work, work and work.
|
