-
Управление из 2-х мест
Здравствуйте, господа!
Кто нибудь реализовывал управление с 2-х устройств на CDS3 одними и теми же переменными?
Возможно ли создание листа сетевых переменных с возможностью чтения/записи?
Или нужно создавать по паре специальных листов сетевых переменных (один на чтение, другой на запись) в каждом устройстве, с передачей по изменению. Но тогда придется искусственно копировать состояние из одного листа в другой в программе, что довольно ненадежно.
Может быть есть более очевидный и элегантный способ решения этой задачи?
-
это же работа без установления соединения, не важно кто прислал данные в определенный порт. Вообщем что во второй что в третьей версии UDP везде одинаков
-
Как и написал Capzap - сетевые переменные по UDP - Ваш выбор.
Пример для второго CoDeSys есть. В третьем по аналогии.
-
Похоже что произошло недопонимание. Нужно ведь не только писать, но и читать. Т.е. при изменении с одного "пульта управления" меняется состояние и второго "пульта управления".
При этом хотелось бы выполнять циклическую передачу, что бы при перебоях связи система оставалась согласованной.
-
Приветствую всех! Хотелось бы узнать чем все закончилось? Элегантный способ решения нашли?
-
А чего тут нового ? Простая задача.
Кол-во точек управления не имеет значения. Если инициировать запрос чтения/записи может любой из (условно) кучи "панелей" и "объекта", то в общем виде алгоритм такой:
1.Объект.
Cохраняет где-то в своем "ретайне" текущие настройки.
Как очнулся - выложил их в область обмена.
Как увидел изменения в области обмена - сохранил в "ретайн" [* и разослал всем Панелям]
2.Панели.
Ничего не хранят, но имеют область куда прилетают настройки.
Как очнулась - сначала читает в эту область настройки с Объекта и обеспечивает оператору возможность изменения в этой области, отображая текущие значения.
Если изменились по месту - шлет Объекту [* и всем Панелям] новые.
Так как Панели чем-то контролируют связь с Объектом, при отсутствии ее - сообщают об этом и, например, делают невозможным редактирование настроек, но при вновь обнаружении Объекта считывают с него текущие данные.
*Тут нужно решить - рассылка Панель-Панель делать напрямую или через Объект.
-
Вложений: 1
Тут бы разобраться с сетевыми переменными. там ведь для обмена данными между контроллерами надо две папки с переменными. одна для отправки, другая для приема.
В документации читаем:
!Важно: Рекомендуется не ставить галочки чтение и запись для одной и той же группы «PRIMER» в одном контроллере. То есть только в одном контроллере переменные одной папки должны быть Write, в остальных контроллерах типа Read.
Если необходимо, чтобы у каждого контроллера были переменные, которые и опрашиваются, и задаются – необходимо сделать несколько таких папок.
То есть для обмена с панелью, которая находится на другом ПЛК надо иметь две разные переменные (одну для чтения другую для записи)
У меня панель подключена к ПЛК1, а скада будет подключена к ПЛК2. Панель и скада должны читать текущее значение параметра из ПЛК2 (сетевая переменная a). А также могут изменить его. В дальнейшем в эту же сеть будут включены еще и другие контроллеры, которые тоже будут обмениваться с панелью и скадой.
Пока нарисовал вот такую схему.
Вложение 14462
Стрелочками указано направление пересылки значения сетевой переменной. В ПЛК1 в каждом цикле b:=a. При изменении значения сетевой переменной она пересылается в другой ПЛК. Похоже надо будет еще промежуточные переменные делать. Как-то совсем не элегантно получается.
-
Чем пугают копии ? Просто работу с копиями лучше вынести куда-нить в отдельный технический уровень чтоб в основном алгоритме не раздваиватся шизофренически, а работать с одной переменной. Типа как в слейве из конфигурации кдс2
Если что-то "рекомендуется" значит до сих пор не реализовали такую ерунду как IN_OUT по сети ? Тогда это сделайте это поверх того что есть. Есть запись и чтение, пусть и в разных папках - это достаточно чтоб сделать работу с одной переменной как с IN_OUT по сети
По картинке.
Кто кому кем является и у кого на борту ? Конфигураций - море
А и B сидели на трубе можно синхронно изменять на всех 4х объектах
-
Вложений: 1
Не понял про аналогию со слэйвом из конфигурации. И про IN_OUT тоже. Разъясните, пожалуйста. А то у меня мысли неправильные пошли сделать ФБ с одной входной переменной (с которой предполагается работать в основном алгоритме), в котором имеются еще две сетевые переменные для обмена. Причем получается для каждой переменной нужно по две сетевые. Может так и надо?
Подправленный вариант схемы. Тут вроде бы не надо создавать дополнительных переменных. В ПЛК1 в каждом цикле b:=a, а в ПЛК2 в каждом цикле a:=b. ИП320 читает и пишет в сетевую переменную a, Скада читает и пишет в сетевую переменную b.
Вложение 14463
По картинке подробнее:
ИП320 (мастер) подключен к ПЛК1 по RS232.
ПЛК1 и ПЛК2 между собой подключены по Ethernet (пока напрямую, но на объекте будут через свитч, так как там планируется несколько контроллеров подключить между собой)
Скада (мастер) будет подключена к ПЛК2 если получится, то тоже через свитч.
-
Про слейв в конфигурации - его можно читать, писать не заморачиваясь. Стандартный мастер - разделяет сознание. Но через библиотеки нетрудно сделать работу с 1й переменной. Поменяли тут - поменялось и там. Поменялось там - поменялось и тут. Это и есть IN_OUT. Странно что не сделано на уровне системы.
А цепаните ип мастером на 485 для обоих ПЛК. Скада опять же - мастер для каждого ПЛК. А области слейвов в плк для 485 и tcp - совместите.
Правдоть это для кдс2. Есть похожее в кдс3 ?