Ответы в темах
-
Сообщения
-
Итоги.
Коммуникатор подключить в нормальном режиме к локальной машине-серверу удалось только при соблюдении следующих условий, помимо согласования профилей Instance (имя станции и профиля, ключ, пароль и имя доступа к службе):
1. Номера каналов на разных удаленных станциях обязательно должны различаться, иначе на локальной машине из данных от коммуникаторов получится каша как в статусах, так и при дальнейшей реализации управления. При создании таких проектов лучше выбирать и резервировать диапазоны каналов для каждой удаленной станции заранее.
2. Коммуникатор, данные которого вы собираетесь получить с удаленной машины, должен их сам отправить на службу-сервер экземпляра системы целевой машины (!), т.о. в настройках Communicator-CommonParameters-Server нужно указать адрес целевой машины вместо Localhost.
И это крайне неудобно, т.к. чтобы не потерять полный функционал работы на удаленной машине, то придется создать там еще один дубляж того же коммуникатора уже для локальной службы сервера. А так как дополнительный коммуникатор не создается в текущей станции (Instance), то получим и двойную станцию в проекте, со своим профилем, нагрузка на линию связи с объектом получится двойная, если не поправить получение данных от одного коммуникатора в другой, но вкупе с этим и количество каналов текущей базы вырастет.
Аналогично база данных каналов, интерфейсы и проч.: при подключении нескольких удаленных станций она является общей в проекте, и тут главное не выгрузить лишнюю конфигурацию случайно, смотреть с чем вы работаете на данный момент.
Что удобно, так это то, что можно полностью работать с проектом удаленной машины на локальной, от загрузки конфигурации до просмотра статуса работы.Построение системы с настройками режима в коммуникаторах в TCP Server/Client/UDP для устройств для согласования не удалось, по крайней мере для КП типа OPC. Наверное, работает только для MODBUS и подобного.
Для всей такой архитектуры будет работать только один секретный ключ Instance на всех экземплярах Scada, т.к. для конфигурации агента невозможно создать отдельный секретный ключ для отдельной станции в проекте, а если все станции находятся в соединении в одном проекте на серверной машине, то на то и получается. Опция Ignore: Registration Keys не могу сказать для чего служит точно в полной мере.
После переименования Instance или ключа в проекте,- в базе агента их приходится править вручную, иначе далее проект будет невозможно и не выгрузить, и не загрузить. Часто при изменении данных в конфигурации базы проекта необходимо обновлять вручную представление отдельных элементов проекта, чтобы изменения имели силу и отобразились в представлении приложения Администратор.
В текущей версии разработки из-за невозможности работы службы-коммуникатора как сервера данных не могу порекомендовать создавать системы децентрализованного контроля/управления с локальными полными станциями только на чистой основе RapidSCADA. С применением UA-OPC, или с шлюзом RapidGate ситуация выглядит гораздо интереснее, система получится более легкая и гибкая при разработке и обслуживании.
Может быть это как-то правильнее и удобнее по-другому сделать? Как подключить каналы удаленного коммуникатора в текуший проект на локальной машине.
Задача, в общем, была следующая:
Есть несколько удаленных машин, со своими проектами-экземплярами системы, они работают на месте. Есть еще одна машина, т.н. локальная, которая должна подключаться к вышеуказанным экземплярам систем и получать отдельные данные от каждой, т.е. быть сервером. Сервер не обязательно должен быть сопряжен с проектами удаленных машин, редактировать и работать с ними удаленно не требуется, хотя и приветствуется. Такое можно сделать, прибегнув в технологиям OPC (особенно UA) серверов, это получилось, и успешно было протестировано. Но задача состоит в том, чтобы OPC не использовать, также как и тунеллирование. Все машины находятся в одной локальной сети. Локальный сервер будет использоваться для сбора и отображения статистики работы по системам от удаленных машин.После редактирования вручную ScadaAgentConfig.xml и перезапуска службы агента удалось подключиться к удаленной станции и работать с ее проктом на локальной машине.
Что неудобно, так это то, что на локальной и удаленной машине станции, и, соответственно, проекты, должны иметь одинаковые ключи SecretKey, помимо самих имен станций. При переименовании станции, равно как и изменении ее ключа, придется править конфиг агента на месте, вручную. Т.е. такое (поэтому был вопрос про синтаксис, как его воспримет агент), не покатит:<?xml version=»1.0″ encoding=»utf-8″?>
<ScadaAgentConfig>
<SecretKey>5ABF5A7FD01752A2F1DFD21370B96EA462B0AE5C66A64F8901C9E1E2A06E40F1</SecretKey>
<Instances>
<Instance name=»LocalInstance» directory=»C:\SCADA\» />
</Instances>
<SecretKey>6BCD7FCDB479ACC123DEE859AEC365F329ABE778FA5B9FF616FAAB8290DEF1A5</SecretKey>
<Instances>
<Instance name=»RemoteInstance» directory=»C:\SCADA\» />
</Instances>
</ScadaAgentConfig>Коммуникатор удаленной станции подключить к локальной машине так и не получилось, при внесении в базу кп сервер локальной станции пишет норма, веб-интерфейс — сервер недоступен.
т.о., все кроется именно в агенте. догадывался, что править базу agent вручную надо, даже при изменении deployment profile на локальной машине. интересно, что даже администратор на месте не может внести изменения в станцию в плане профиля.
если это на месте заработает, то и удаленно тоже. профиль администраторов везде по умолчанию стоит, к самому агенту он подключается, но ничего не может сделать, прав нет на изменение профиля станции.
как правильно не изменить, а добавить регистрационные данные (в плане синтаксиса xml), т.е. создать несколько станций на у одного проекта с разными рег. данными?
агент как службу нет необходимости перезапускать?
(сейчас временно нет доступа к проектам, чуть позже отпишусь)
К вопросу о коммуникаторе, его настройках связи. Т.о. к одному серверу можно подсоединить несколько коммуникаторов. А что будет, если к одному серверу будут подключены несколько коммуникаторов, а у них же могут быть и одинаковые каналы, не возникнет конфликт конфигураций?
На удаленных станциях в полном составе развернуты системы. Любой коммуникатор, веб-станция, сервер являются под-объектами станции (instance), их невозможно создать без создания станции.
Допустим, необходимо создать еще один коммуникатор в проекте. Создав его, создаем новую станцию. К этой станции необходимо указать deployment profile. Создав новый профиль, сталкиваемся с тем, что выгрузить конфигурацию не получается, т.к. ее нет в базе агента. С одной стороны, агент на месте должен принять обновленные данные, новую станцию, передать их конфигурацию другим сервисам, с другой он же их и проверяет, а их нет в его базе. Тупик.
Аналогично получается, если переименовать саму станцию, изменить ее секретный ключ. Поэтому невозможно что-то добавить в проект, ни дополнительный коммуникатор, ни удаленную станцию.Получается подсоединить к локальной машине только одну станцию из-за указанной ситуации. Они полностью и правильно синхронизируются, как по данным, так и по конфигурации. Создавая же другую точку instance, не получается ее прописать в проекте, ее конфигурацию невозможно выгрузить, агент не дает. И имя, и пароль, и ключ безопасности станции default тоже нельзя изменить, администратор отклонит upload с сообщением, что «Экземпляр не найден в системе», что логично, их нет в старой базе агента, а новая не загружается даже администрптором на месте.
На нескольких удаленных машинах установлены экземпляры Rapid SCADA, коммуникаторы которых требуется подключить к одному общему серверу Rapid SCADA. В документации к версии 5.6 также указано, что можно подключить удаленную станцию и напрямую работать с ней. В новой версии это не получается по нескольким причинам:
1) необходимо переименовать Instance из имени по-умолчанию «Default», настроить для нее заново Deployment Profile, но такую конфигурацию уже невозможно выгрузить, т.к. все идет через сервис Agent-а, а в нем другая конфигурация, и он не принимает созданное подключение. Т.о. переименовать, создать новую станцию, кроме default, на одной машине не получается.
2) при изменении локального ключа безопасности профиля соединения Deployment Profile также уже невозможно передать конфигурацию, т.к. Agent отклоняет запрос по вышеописанной причине, т.о. и для даже одной станции Default невозможно изменить ключ, все получаются с одинаковыми ключами.К удаленной станции подключение работает, все опции наблюдения, редактирования и управления работой функционируют, но только для одной станции Default, как на удаленной, так и на локальной машине.
Как подключить несколько удаленых станций (либо коммуникаторов этих станций) к одной общей локальной?
Как изменить ключ безопасности, если с одной стороны агент отклоняет конфигурацию, с другой проверяет ее же?
У коммуникатора также есть настройка CommonParameters=>ServerConnection=>Server. Она указывает к какому серверу будут переданы данные?
При отправке команды, только для компонента Тумблер учитывается его положение
Правильно. Тумблер и создается, только из динамической надписи, или из динамического изображения, если стандартный не подходит. Кнопка, с фиксацией, без, двух или многопозиционный переключатель и т.д., — все действия этих созданных объектов проходят через выполнение команд привязанного выходного канала, но чтобы учесть состояние переменной до подачи команды, и приходится обращаться к входному каналу напрямую. В тумблере готовом обращение идет к его собственным параметрам, как компонента. Обратиться к таким данным, не углубляясь в создание библиотеки компонентов, наверное, и не возможно.
Если не хотите менять язык в Администраторе, установите культуру…
Вообщем, если в администраторе задан язык русский, то коммуникатор отображает данные линии правильно (по-нашему) без запятых.
Web-интерфейс отображает правильно также только если этот параметр culture выставлен на ru-RU, но при этом и его язык интерфейса меняется на русский. Вот бы отвязать бы эти путы, чтобы было отображение данных нормальное, но без изменения языка.Язык тут не причем. https://it.wikireading.ru/17860
Настройте отображение как Вам необходимо.Там все указано правильно, пробовали менять. Отображение зависит от настроек языка интерфейса и администратора, который и влияет на коммуникатор.
Попутный вопрос. Есть какие-либо команды, чтобы окно текущего представления (не самого браузера) разворачивалось при открытии в полноэкранном режиме сразу?
Если перевести на русский язык интерфейс администратора, то данные отображаются в коммуникаторе как 1 234,000. Но не в веб. В итоге получается, и на русском шаблоне ru-RU в веб интерфейсе тоже надо работать, только тогда отображается правильно. Это можно подправить в будущих версиях, или сделать опции в веб-интерфейсе по отображению числовых данных? На русском работать и отображать — не всем надо.
Администратор и web-интерфейс на английском оба. Работает в связке с KEPServerEx, там заданы данные типа Short, и отображаются правильно. В администраторе канал указан как CalculatedReal, без формулы, формат «D».
В языке и региональных стандартах системы все указано правильно, разделитель разрядов — пробел, дробной части — запятая. Так понимаю, это не отсюда ноги, т.к. в статистике от самого коммуникатора отображаются данные по каналу уже в виде 1,234.000У компонента Dynamic text есть свойства Input channel, Output channel. Для того, чтобы изменить значение данных, привязанных к входному каналу компонента в пар. Input channel, необходимо выполнить команду по команде в пар. Output channel. И чтобы работать с данными самой переменной канала Input channel, мне необходимо выполнить функцию Val(101)==1 && Stat(101)!=0 ? 0 : 1. 101 — это и есть канал, указанный в пар. Input channel, но только мне его приходится записывать прямой адресацией. Если я поменяю в самом компоненте значение пар. Input channel, то это не приведет к изменению выполнения формулы команды, что неудобно. Есть ли какой-то доступ к значению параметров самого компонента, чтобы значение пар. Input channel подставить в формулу? Жаль что не доступны скрипты на компоненте по определенному типу действий, так можно было бы что угодно выполнять с данными привязанных каналов.
