[?]: Обращение к переменным контроллера Quantum из OFS

[witgr]

Добрый день.
Помогите, пожалуйста, разобраться в подключении OPC сервера OFS v. 3.34 к котроллеру Quantum 140 CPU 651 60 02.80.
Подключение производится по протоколу Ethernet – контроллер имеет в своем распоряжении Ehetnet модуль – IP адрес 192.168.1.102.
С помощью утилиты экспорта в Unity Pro XL V5.0 были получены файлы с переменными контроллера в форматах *. XVM, *.XSY, *.SCY, *.TXT.
В дальнейшем эти файлы были использованы при конфигурировании OPC сервера.



При подключении OPC Client’а OPC видит перечень тегов в файле



Однако данные не идут – качество связи Bad (20).



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




Вопрос: как достучаться до значений внутренних переменных контроллера (символов) из OPC. Какие для этого настройки необходимы?
Справочно: в *.TXT файле, полученном при экспорте, информация о символах храниться следующим образом



Заранее благодарен,
Виталий

[pupena_san]

Подозреваю что проект в ПЛК отличен от того, с которого был сделан XVM. Если есть исходник проекта, или если его можно выгрузить с ПЛК, попробуйте прицепиться в OFS к проекту UNITY (файл STU).
Дело в том, что при каждой компиляции проекта, нелокализированные (unlocated) переменные находятся по новому адресу, по этой причине лучше чтоб исходный проект был всегда доступен для OFS. Если в ранних версиях OFS все это работало немного коряво, то сейчас OFS подхватывает новые переменные с проекта даже без перезагрузки самого OFS.
А вобще для оптимизации трафика, я все равно использовал бы только локализированные переменные типа %MW, как-то спокойнее и за версии не переживаешь, ИМХО.

[witgr]

Большое спасибо, pupena_san!
Ваше предположение подтвердилось.
При использовании файла проекта UNITY (*.STU) в OFS связь с нелокализованными переменными (unlocated) появилась.
В нашей организации контроллерами и SCADA занимаются разные отделы.
Теперь будем думать как и где лучше хранить файл проекта UNITY (*.STU) для совместного использования.
Наверное, заведем сетевую папку и будем обращаться к ней при необходимости.
Причем нелокализованные переменные на самом деле после каждой новой компиляции требуют именно последнюю версию файла *.STU.
Я думаю, что тема закрыта.

[witgr]

Вот что ответили по моему запросу в Службе поддержки Schneider Electric.
Думаю информация будет полезна.

Это хорошо, что Вы обнаружили причину проблемы, но Вам следует учитывать следующее:
если Вы применяете в своем проекте нелокализованные переменные и файл *.STU, то Ваш Unity должен быть не менее чем версии XL и он должен быть установлен на том же ПК, что и OFS в связи с тем, что в этом случае при запуске OFS, автоматически в теневом режиме на ПК запускается сервер переменных Unity для предоставления в OFS корректных ссылок на переменные.

Если Вы используете файл XVM, то необходимо использовать последнюю версию этого файла, сформированную Unity при компиляции и загрузке проекта в ПЛК (нужно включить соответствующие настройки в Unity, чтоб эти файлы формировались автоматически и можно разместить этот файл на общедоступных сетевых ресурсах );
Если в настройках Вашего OFS выбран режим Stric то переменные не будут подключаться при малейшем рассогласовании версий приложения в ПЛК и файле XVM, если же в конфигурации OFS выбран режим Debug, то при незначительном отличии проекта от файла XVM, подключение должно осуществляться корректно;
Если используются локализованные переменные %M, %MW, то их местоположение в памяти ПЛК не зависит от компиляции и по этому файл списка переменных для доступа к ним не требуется.

[pupena_san]

Вот-вот.
По этому к черту все эти приблуды с нелокализированными переменными.
Located Variables - forewer!
И трафик оптимизируешь как хочешь и за несоответствие проектов не переживаешь. Файл с символами вообще можно не подключать к девайсу в OFS, а можно и старым добрым способом - загнать в Excel нужные переменные вместе с комментариями и адресами, и подключить CSV файл.
Вот где без этого нельзя обойтись - когда пускать в свой ПЛК нужно только к нужным переменным.
Тогда без наличия файла экспорта к другим переменным не доберешься.
Как то слушатели такую задачку подкинули, а так бы я даже не догадывался о такой необходимости.
Предложил им для обмена с чужой системой использовать локализированные переменные, а со своей - нелокализированные.