Просмотр полной версии : Запись переменной с двух мест по сети и с экрана
Здравствуйте !
Вопрос уже задавал в разделе " программируемые реле', теме "ПР225.Первое щитовое программируемре реле Овен".
Вопрос о макросах изменения переменной типa Bool двумя переменными (SelChgB), числа типa Float двумя переменными (SelChgF) и числа типa lNT двумя переменными (SelChgI).
Через эти макросы пытаюсь записывать параметры с двух мест с экрана ПР205 и с Owen Cloud.
Введенный с экрана прибора параметр при вводе с
Owen Cloud не изменяет значения, на экране сохраняется предыдущее, причем в симуляции изменяет, записывается последнее изменение.
Что нужно сделать для того, чтобы при вводе по сети через макросы SelChgB,F,I параметр записывался, как и при вводе с экрана ?
Посмотри тут может подойдет
https://owen.ru/forum/showthread.php?t=9398&page=613&p=367694&highlight=%C7%E0%EF%E8%F1%FC%20%EF%E5%F0%E5%EC%E5% ED%ED%EE%E9%20%E4%E2%F3%F5%20%EC%E5%F1%F2#post3676 94
У меня без макросов работает.
Благодарен за ссылку. Просмотрю когда будет
возможность.
ЕFrol без макросов можете в одну выходную
переменную сделать запись одной из двух
входных поданных с экрана и с Оwen Cloud и
та которая была последней и запишется ?
А попробуйте сетевую переменную прямо к экрану привязать (сейчас так, вроде, можно)
Для работы с сетевыми битами я использую макрос Exchange:
89640
function_block Exchange
var_input
inNet : udint;
bi0, bi1, bi2, bi3, bi4: bool;
end_var
var_output
outNet : udint;
bo0, bo1, bo2, bo3, bo4: bool;
end_var
var
ex : bool;
end_var
ex := false;
ex := ex or (bi0 <> bo0);
ex := ex or (bi1 <> bo1);
ex := ex or (bi2 <> bo2);
ex := ex or (bi3 <> bo3);
ex := ex or (bi4 <> bo4);
if ex then
outNet.0 := bi0;
outNet.1 := bi1;
outNet.2 := bi2;
outNet.3 := bi3;
outNet.4 := bi4;
else
outNet := inNet;
end_if
bo0 := outNet.0;
bo1 := outNet.1;
bo2 := outNet.2;
bo3 := outNet.3;
bo4 := outNet.4;
end_function_block
Не забывайте выставить галочку запись в конце цикла.
Не удается открыть вложение:
Направить еще раз можете ?
Сергей0308
24.06.2026, 23:11
Не удается открыть вложение:
Направить еще раз можете ?
Давайте я Вас направлю, чтобы открыть, надо обновить ОЛ!
Здравствуйте !
EFrol правильно понимаю, что фукциональный блок Exchange написан на
на ST.
Hо как реализовать запись с двух мест значения в одну выходную переменную с экрана ПР205 и по сети значения по примеру из вложения ? Может быть команды поданные с экрана прибора в приоритете и поэтому команды поданные по сети будут игнорироваться всегда ?
А если не делать 2 переменные, а оставить одну общую для всех?
Здравствуйте !
EFrol правильно понимаю, что фукциональный блок Exchange написан на
на ST.
Hо как реализовать запись с двух мест значения в одну выходную переменную с экрана ПР205 и по сети значения по примеру из вложения ? Может быть команды поданные с экрана прибора в приоритете и поэтому команды поданные по сети будут игнорироваться всегда ?
Зачем Вам отдельная переменная "уст.Т приток зимой" ?
Оставьте в проекте только сетевую переменную "уст.Т приток зимой". Её используйте в программе, в нее пишите сразу с экрана или по сети. Никаких макросов в принципе здесь не надо
Hо как реализовать запись с двух мест значения в одну выходную переменную с экрана ПР205 и по сети значения по примеру из вложения ? Может быть команды поданные с экрана прибора в приоритете и поэтому команды поданные по сети будут игнорироваться всегда ?
Вы неправильно макросом пользуетесь
89656
Одна общая, тогда или локальная или сетевая,
или с экрана задавать, или с Owen Cloud, что-то одно.
Но ведь пробую задавать с двух мест.
Одна общая сетевая. Тогда можно считать/записать из сети (OwenCloud) и с экрана.
Да, действительно, к экрану ПР205
можно привязать и сетевые переменные.
Не знал об этом.
Так будет работать: " уст.Т приток зимой"-сетевая
переменная, она используется в программе, привязана
к экрану, задается с экрана и по сети ?
Да, действительно, к экрану ПР205
можно привязать и сетевые переменные.
Не знал об этом.
Так будет работать: " уст.Т приток зимой"-сетевая
переменная, она используется в программе, привязана
к экрану, задается с экрана и по сети ?
Без сомнений, иначе зачем они (сетевые переменные) вообще нужны? Неужели только для того, чтобы их значения запихивать в какие-то промежуточные переменные.
ЗЫ.
Учтите, что сетевые в слейве - энергонезависимые по умолчанию
Как правило это благо (уставки какие-либо хранить), но иногда, например, команды не всегда нужно сохранять при выключении питания, тогда в первом цикле программы нужно такие сетевые переменные принудительно обнулять
Если Вы смогли открыть owen.owle, то там сетевая netVar выведена на экран.
Её можно задавать как с экрана так и по сети.
ЗЫ.
Учтите, что сетевые в слейве - энергонезависимые по умолчанию
Как правило это благо (уставки какие-либо хранить), но иногда, например, команды не всегда нужно сохранять при выключении питания, тогда в первом цикле программы нужно такие сетевые переменные принудительно обнулять
В новой линейке ПРрок сейчас у сетевых в слейве по умолчанию галка с энергонезависимости снята
EFrol cмог открыть направленный owen.owle.
Petera поясните- "тогда в первом цикле программы нужно такие сетевые переменные принудительно обнулять".
Как это сделать ?
Вот такая схема сбросит netVar в 0 только в 1-ом цикле.
89663
Ведь можно галочку "энергонезависимость"
у выбранных сетевых переменных в cлейве снять, тогда при выключении
питания переменная обнулится ?
Вы не стой стороны подходите к решению.
Если этот бит - команда - например, "ПУСК", то нужно применить импульсное управление включением. Т.е. при получении
- командного слова из Modbus/OwenCloud выделить бит команды, а всё слово обнулить
- бит от локальной панели ПР - обнулить его через таймер TP
- бит из алгоритма - подать через RTRIG
Все три импульса объединить через OR и подать на RS-trig (с приоритетом сброса).
Сброс - аналогично, но только останов от защитной блокировки должен действовать на сброс триггера непрерывно, а команды - импульсами.
Здравствуйте!
Как все-таки при выключении питания ПР205 обнулить целочисленную сетевую переменную, которая преобразованная в булевское значение поступает на вход макроса Damper_1 ?
Схема, которую предложил EFrol подойдет для этого ?
Здравствуйте!
Как все-таки при выключении питания ПР205 обнулить целочисленную сетевую переменную, которая преобразованная в булевское значение поступает на вход макроса Damper_1 ?
Схема, которую предложил EFrol подойдет для этого ?
Отследить момент отключения питания скорее всего не получится, но можно обнулить её сразу:
89674
Пишу как думаю. Из Owen Cloud в том числе посылаются команды по сети в ПР на запись. Команда записалась. Теперь питание ПР выключилось, например на доли секунд и снова включилось.
При этом записанная команда не изменила своего прежнего значения, 1-а по прежнему висит. Как Owen Cloud "узнает", что питание прибора было выключено на доли секунд ?
Была предложена схема, которая обнулить netVar только в первом цикле программы.
Но у меня вопросы.
Почему netVar будет 0 ? На выходе таймера RTRIG будет 1 на один цикл программы сразу при включении питания, при этом на на выходе SEL значение с 3-его входа, т.е. нет значения.
После этого на выходе SEL значение со 2-его входа, т.е. netVar-это то значение, которое как раз и
задано с Owen Cloud ?
Здравствуйте!
Как все-таки при выключении питания ПР205 обнулить целочисленную сетевую переменную, которая преобразованная в булевское значение поступает на вход макроса Damper_1 ?
Схема, которую предложил EFrol подойдет для этого ?
На ПР205 снять галку с энергонезависимости
Пишу как думаю. Из Owen Cloud в том числе посылаются команды по сети в ПР на запись. Команда записалась. Теперь питание ПР выключилось, например на доли секунд и снова включилось.
При этом записанная команда не изменила своего прежнего значения, 1-а по прежнему висит. Как Owen Cloud "узнает", что питание прибора было выключено на доли секунд ?
Была предложена схема, которая обнулить netVar только в первом цикле программы.
Но у меня вопросы.
Почему netVar будет 0 ? На выходе таймера RTRIG будет 1 на один цикл программы сразу при включении питания, при этом на на выходе SEL значение с 3-его входа, т.е. нет значения.
После этого на выходе SEL значение со 2-его входа, т.е. netVar-это то значение, которое как раз и
задано с Owen Cloud ?
А тут зависит от того как облако пишет в ПРку. Можно, ведь, записать и забыть, а можно без перерыва циклически писать. В первом случае обнуление сработает, во втором нет
Я бы сделал так - с импульсным управлением от облака (Modbus) и из алгоритма программы, и с потенциальным от локальной панели ПР
FUNCTION_BLOCK MTR_Control
VAR_INPUT
bPgmStart : BOOL; // Импульсная команда ПУСК из программы
bPgmStop : BOOL; // Импульсная команда СТОП из программы
bHmiStart : BOOL; // Импульсная команда ПУСК из вышестоящей системы
bHmiStop : BOOL; // Импульсная команда СТОП из вышестоящей системы
bLocalCtrl_In : BOOL; // Потенциальная команда ПУСК (и состояние) от локальной панели
bEmergencyStop : BOOL; // Состояние кнопки АВАРИЙНЫЙ ОСТАНОВ
Enable : BOOL; // Разрешение работы из программы
END_VAR
VAR_OUTPUT
bStart : BOOL; // Потенциальная команда ВКЛЮЧИТЬ
bLocalCtrl_Out : BOOL; // Обновление входной переменной команды и состояния от локальной панели
END_VAR
VAR
rtrigPgmStart : BOOL; // для выделения фронта импульсной команды
rtrigPgmStop : BOOL; // для выделения фронта импульсной команды
rtrigLocalCtrl : BOOL; // для выделения фронта импульсной команды
END_VAR
IF Enable AND NOT bEmergencyStop THEN
// если работа разрешена и кнопка АВАРИЙНЫЙ ОСТАНОВ не нажата
// если пришёл фронт команды ПУСК от любого из источников - включить
IF (bPgmStart AND NOT rtrigPgmStart)
OR bHmiStart
OR (bLocalCtrl_In AND NOT rtrigLocalCtrl)
THEN
bStart := TRUE;
END_IF
// если пришёл фронт команды СТОП от любого из источников - выключить
IF (bPgmStop AND NOT rtrigPgmStop)
OR bHmiStop
OR (NOT bLocalCtrl_In AND rtrigLocalCtrl)
THEN
bStart := FALSE;
END_IF
ELSE
// если работа не разрешена или нажата кнопка АВАРИЙНЫЙ ОСТАНОВ - выключить
bStart := FALSE;
END_IF
// для выделения фронта команд
rtrigPgmStart := bPgmStart;
rtrigPgmStop := bPgmStop;
// команда от локальной панели - потенциальная, поэтому для исключения формирования импульса
// от неё на следующем машинном цикле при изменении состояния от другого источника
// предыдущее состояние устанавливается текущему только если управление выполнилось от локальной панели
IF bLocalCtrl_In XOR bStart THEN
rtrigLocalCtrl := bStart;
ELSE
rtrigLocalCtrl := bLocalCtrl_In;
END_IF
// Owen Logic не позволяет работать с переменными InOut, поэтому переменная команды-состояния
// локальной панели обновляется за пределами ФБ
bLocalCtrl_Out := bStart;
END_FUNCTION_BLOCK
Команда из облака - бит в принятом слове. Слово сразу после приёма и декодирования обнуляется, команда однократно исполняется.
В облаке настроить на передачу команды в течение нескольких секунд.
Сразу же обрабатывается сигнал аварии (кнопки СТОП) и инициализации при включении питания.
Мне кажется - так будет работать.
Единственно, тут слабое место - непредсказуемость команд из облака.
Если записать и забыть, то ведь такая схема обнуления сетевой переменной в первом цикле при включении питания ПР должна работать ( в схему предложенную EFrol
на 3-ий вход добавил константу со значением 0 ) ?
Dimensy можете привести пример, когда в ПР из Owen Cloud без перерыва циклически что-то пишется, когда обнуление не сработает ?
Сергей0308
28.06.2026, 08:40
Вроде подобное делали много лет тому назад: https://owen.ru/forum/showthread.php?t=26216&page=222&p=376273&viewfull=1#post376273
AHom, определитесь, что в конечном счёте требуется без манипуляций с кодом, без грязных хаков с принудительными обнулениями при включении или отключении электропитания.
Из облака (или от панели оператора) и от местной панели ПР могут формироваться следующие переключения:
- команды управления (ВКЛ/ОТКЛ), которые при выключении электропитания гарантированно обнуляются, выключая агрегат (переводя его в безопасное состояние)
- режимы работы (РУЧ/АВТ, ЗИМА/ЛЕТО), которые сохраняют значение при выключении электропитания
Для работы из нескольких источников (локальная панель, облако, программа, аварийный останов) удобнее всего сигналы управления от этих источников сделать импульсными и изменения состояния агрегата выполнять по фронту команды.
Для этого на панели оператора (в облаке) делают 2 кнопки - ВКЛ и ОТКЛ, которые устанавливают в true определённые биты (разные) в слове управления. Программа после выделения бит команд обнуляет принятое слово, тем самым формируя импульс команды. Этот импульс можно сделать и свойствами панели - некоторые позволяют формировать импульс на несколько секунд - но связь по Modbus, а тем более с облаком может прерваться в неподходящий момент, поэтому по цифровому интерфейсу принимается команда и командное слово приводится в исходное состояние.
Таким образом устраняется противоречие между состоянием агрегата и состоянием команды в каждом из источников команд.
Для локальной панели ПР тоже было бы идеально сделать 2 кнопки, но интерфейс будет неудобным и загромождённым. Поэтому придётся пойти на компромисс и отступить от предложенной схемы и делать совмещённый бит - и команда и состояние. И значит сложнее его обрабатывать.
Выше я привёл пример обработки команды. В своих программах делаю сложнее - разделяю управление на автоматическое (из программы) и на ручное дистанционное (от локальной панели или из облака) - при помощи обычного bSEL. Но Вы по образцу сможете самостоятельно подогнать под собственные нужды.
Для переключения режима нужно будет немного изменить программу ФБ - вынести переключаемый бит из локальных в глобальные энергонезависимые переменные.
Ещё раз повторю вопрос - требуется переключить команду или режим?
Для работы из нескольких источников ... удобнее всего сигналы управления от этих источников сделать импульсными и изменения состояния агрегата выполнять по фронту команды.
Для этого на панели оператора (в облаке) делают 2 кнопки - ВКЛ и ОТКЛ, которые устанавливают в true определённые биты...
А нафига какие-то биты когда само число представляет 65тыс команд
...
Для этого на панели оператора (в облаке) делают 2 кнопки - ВКЛ и ОТКЛ, которые устанавливают в true определённые биты .
Даже в ИП320 по кнопе можно записать XXXX в нужный регистр. Которого одного хватит чуть меньше чем для всего.
... В своих программах делаю сложнее - разделяю управление на автоматическое (из программы) и на ручное дистанционное (от локальной панели или из облака) - при помощи обычного bSEL?
Вообще не разделяю.
Исполнительные части работают только по получаемым в свой ящик командам-сообщениям.
Команды принимаются в одно центральное место, а в нужные места-приемники раскладывает почтальон - диспетчер команд. CASE рулит.
Команды могут прилетететь и сверху и с местной панели управления и с автоматической части логики.
Если нужно строго от автоматической логики, почтальон сообщения от запрещёных источников кладет в топку.
Команды можно занести в журнал. Для отладки удобно.
Если припрет, несложно сделать очередь команд.
Здравствуйте !
FPavel команду нужно переключить (обнулить) посланную из Owen Cloud при выключении и последующем включении ПР.
Сергей0308
28.06.2026, 15:59
Здравствуйте !
FPavel команду нужно переключить (обнулить) посланную из Owen Cloud при выключении и последующем включении ПР.
Если Вы хотите чтобы команда, при её наличии не исполнялась при перезагрузке ПР делайте формирование команд по фронту сигнала, тогда проблем не должно возникнуть, если не будете принудительно обнулять(снимать) команду при перезагрузке ПР, мне так кажется!
Здравствуйте !
FPavel команду нужно переключить (обнулить) посланную из Owen Cloud при выключении и последующем включении ПР.
ПР никак не определяет для программы пользователя состояние отключения электропитания, а включение - возможно определить.
В такой постановке задача не решаема средствами ПР и Owen Logic.
При замене ПР на ПЛК - Овен ПЛК2хх - в задачах можно настроить обработку по разным событиям - и включение питание и отключение питания.
Заменяйте на ПЛК и сможете решить именно эту задачу именно в такой постановке.
Если же требуется подать команду включения от нескольких источников и состояние агрегата после включения электропитания окажется в безопасном (отключённом) состоянии, то посмотрите мой пример.
Мой пример - это и есть такая команда и такое состояние.
Этот эффект получается за счёт того, что RS-триггер после включения питания находится в выключенном состоянии и до прихода команд включиться - в этом состоянии и будет пребывать.
Чтобы была возможность применять команды от нескольких источников - время их действия ограничивается одним машинным циклом - когда оговаривается, что переключение будет выполняться только по фронту команды - от импульса.
Команда из облака поступает в сетевой переменной, после выделения команды - сетевая переменная обнуляется, чем и создаётся импульс.
От других источников (программа и локальная панель ПР) выделение фронта производится в коде - можно явно через RTRIG, а можно через дополнительную переменную предыдущего состояния входа - у меня вторым способом.
Пример работает - проверил в отладчике. В "живой" ПР, думаю тоже будет работать.
Берите пример и разбирайтесь, подгоняйте под свои нужды.
А нафига какие-то биты когда само число представляет 65тыс команд
...
Спасибо, хорошая идея. Воспользуюсь в следующем проекте.
Именно в Owen Logic будет несколько неудобно из-за отсутствия именованных констант.
Как понимаю, в моём примере отличие только в количестве команд на одну переменную (но это скрыто в макросе UnpackBits, который можно заменить на сетку сравнений с константами - CASE), и месте обработки, а последующая часть будет сходной, за исключением, что игнорирование команды у меня выполняется не на этапе распределения команд в CASE, а в коде управления каждого из агрегатов.
Как понимаю, потребуется очередь (или разные переменные по числу источников) - команды из Modbus и из локальной панели могут прийти одновременно и один из источников будет пропущен при записи в одну и ту же переменную. И цикл обработки очереди команд (вернее, переменных хранения для каждого из источников команд).
...потребуется очередь (или разные переменные по числу источников) - команды из Modbus и из локальной панели могут прийти одновременно и один из источников будет пропущен при записи в одну и ту же переменную. ...
Не потребуется. Во всех вариантах придется выбирать кто главней в таких чуть чаще чем никогда случаях.
Как понимаю, в моём примере отличие только ...
.... а в коде управления каждого из агрегатов.
В общем да. Но в моем варианте при других конфигурациях/задачах лазить только почтальона (если не меняется база).
А отсутствие констант это всего лишь открыть и сравнить 2 линейных списка: [где-то] констант со значениями и [здесь] определителей CASE.
Это же не хитросплетения кода. Особенно если это квадратики в виде атласа жд РФ.
--
Но еще раз - это лично мое. Я не собираюсь говорить что "нада именно так" в отличие от некоторых бывающих тут. Решений всегда тьма.
Главное - внутреннее удовлетворение результатом для того кто делает. А как - вообще пофиг.
Спасибо.
Идею уловил, попробую. Если не справлюсь - никогда не поздно вернуться к прежнему решению.
Здравствуйте !
Может быть задам дилетантский вопрос, но все же.
В чем принципиальное отличие локальной энергонезависимой
переменной от сетевой энергонезависимой переменной, только в том
что первая задается из программы, а вторая по сети ?
Например локальная энергонезависимая переменная это команда
она будет сохранять свое значение при перезарузке ПР, т.е. если эта
команда Пуск вентсистемы, при перезагрузке прибора
система сначала отстановится, а затем перезапустится.
Также и с сетевой энергонезависимой переменной если
эта переменная команда, тогда энергонезависимость какой из
переменных устойчивей и отчего это зааисит ?
Локальная имеет свойство значения по умолчанию.
Сетевая нет, лишилась когда-то этого свойства.
Других отличий вроде нет.
Отсюда и костыли с записью из двух мест.
kondor3000
05.07.2026, 19:42
Локальная имеет свойство значения по умолчанию.
Сетевая нет, лишилась когда-то этого свойства.
Других отличий вроде нет.
Отсюда и костыли с записью из двух мест.
Уже нет, сетевым в слейве можно задать начальное значение и энергонезависимость.
Главное отличие, что сетевая по умолчанию это 1 регистр, а локальная 2 регистра.
Например локальная энергонезависимая переменная это команда
она будет сохранять свое значение при перезарузке ПР, т.е. если эта
команда Пуск вентсистемы, при перезагрузке прибора
система сначала отстановится, а затем перезапустится.
Также и с сетевой энергонезависимой переменной если
эта переменная команда, тогда энергонезависимость какой из
переменных устойчивей и отчего это зааисит ?
Главное отличие, что сетевая по умолчанию это 1 регистр, а локальная 2 регистра.
Сохранение переменной зависит от написанной программы. Если вы при включении перезапишите её в 0, то энергонезависимость не поможет и неважно сетевая или локальная.
Поэтому в ОЛ все переменные для сохранения делаются со входом и выходом. (с SEL или без).
В мастере сетевую надо инициализировать из обычной или читать из слейва.
Уже нет, сетевым в слейве можно задать начальное значение и энергонезависимость.
Главное отличие, что сетевая по умолчанию это 1 регистр, а локальная 2 регистра.
Для ПР200 это возвращено? в какой версии? или эта возможность (задание значения по умолчанию) есть только для новых ПР типа 103, 205 и т.д. ?
Сергей0308
05.07.2026, 20:19
Уже нет, сетевым в слейве можно задать начальное значение и энергонезависимость.
Главное отличие, что сетевая по умолчанию это 1 регистр, а локальная 2 регистра.
Главное отличие, что сетевая по умолчанию это 1 регистр, а локальная 2 регистра.
Сохранение переменной зависит от написанной программы. Если вы при включении перезапишите её в 0, то энергонезависимость не поможет и неважно сетевая или локальная.
Поэтому в ОЛ все переменные для сохранения делаются со входом и выходом. (с SEL или без).
В мастере сетевую надо инициализировать из обычной или читать из слейва.
По меньшей мере(но этого достаточно) это не так, в смысле, сетевая переменная с плавающей запятой всегда занимает 2 регистра(32-х битная).
kondor3000
05.07.2026, 20:49
По меньшей мере(но этого достаточно) это не так, в смысле, сетевая переменная с плавающей запятой всегда занимает 2 регистра(32-х битная).
Это частный случай, указывая Float, вы указываете уже 2 регистра сами, для битовой маски (или для бит) и для целых это 1 регистр по умолчанию и это главная ошибка новичков.
Сергей0308
06.07.2026, 00:12
Это частный случай, указывая Float, вы указываете уже 2 регистра сами, для битовой маски (или для бит) и для целых это 1 регистр по умолчанию и это главная ошибка новичков.
Вот видите, Вы даже сами себе противоречите, в смысле, в преведущем посте Вы написали безусловное положение, что сетевая переменная по умолчанию занимает один регистр!
Сергей0308 можете пояснить, в чем с Вашей точки зрения главные
отличия локальной и сетевой энергонезависимых переменных, учитывая
сказанное в предыдущих постах ?
Сергей0308
07.07.2026, 13:13
Сергей0308 можете пояснить, в чем с Вашей точки зрения главные
отличия локальной и сетевой энергонезависимых переменных, учитывая
сказанное в предыдущих постах ?
Помнится на форуме даже вопрос всплывал, кому-то не хватало энергонезависимой памяти и он использовал сетевые переменные(в режиме слейв) как обычные локальные энергонезависимые переменные, для них, как я понимаю память резервируется независимо от того используются они или нет, короче, для ПР200 особой разницы нет, за исключением, что сетевые можно читать(писать) по интерфейсу RS485, но от ПР к ПР их свойства постоянно меняются, не знаю зачем, например в ПР200 их можно было вывести на экран для редактирования, а в ПР225, на форуме вроде писали, что теперь нельзя сетевые переменные непосредственно на экран вывести, чуть ли не каждый день нововведения, короче, лучше спросите у "творцов" что они там натворили, я как бы специально не слежу за их нововведениями, мне это не интересно, а ПР225 у меня нет!
На форуме были сообщения, что если сетевая Slave переменная не используется в программе, то обращение к ней от Master вызовет ошибку. Это приводило к невозможности считывать все Slave переменные одним запросом.
Свойства сетевых переменных различаются от модели к модели ПР.
В ПР205/225 их можно редактировать с экрана.
Но нужно помнить, что целочисленные сетевые переменные имеют размер 2 байта (16 бит), а в программе используются целочисленные переменные 4 байта (32 бита). Т.е. при присвоении возможна потеря разрядности, искажение значения.
Также, время цикла ПР зависит от количества сетевых переменных независимо от существования опрашивающего Master-устройства. Причём, весьма существенно.
В программе управления двумя насосными группами (5+2), одна из которых заполняла резервуар (АВР, каскад, ПИД), а другая его опустошала (АВР, каскад, ПИД, сон), автоматическое и ручное управление, по десятку блокировок и защит на насос в зависимости от группы, все настройки, режимы и состояния доступны с панели оператора. Всего 160 переменных на 200 регистров.
Цикл выполнения стал 34 мс.
Возвращаясь к исходной теме - управление из нескольких источников...
Сейчас искал у себя кое-какую документацию и наткнулся на собственные тесты разных задач. Нашёл среди них выдержки из ГОСТ Р МЭК 61511-2-2018. В приложении к этому ГОСТ в редакции 2018 года рассматривалось управление соленоидным клапаном (SOV), приводились схемы автоматизации, схемы подключений и структурная схема управления (похожая на FBD программу) и даже FBD программа.
Как раз рассматривалось поступление команд из нескольких источников. И видно, что эти команды подаются в виде импульсов, чтобы могла выполниться и другая команда.
Т.е. решение задачи - в принятии и принудительной организации всех команд исключительно в виде импульсов. А импульсы уже проще обрабатывать и переключать триггеры (как явные, так и неявные на if).
Этот ГОСТ интересен тем, что в каждой редакции меняется раздел приложений и рассматриваются разные примеры. Вот только найти действующую редакцию затруднительно. А за 2018 - можно.
Здравствуйте !
Вот сейчас в ПР205 для управления приточно-вытяжной установкой используются в большей части сетевые переменные, которые привязаны также и к экрану прибора, а значит их можно
задавать как с экрана ,так и по сети. И поэтому вопрос следующий: если таким переменным задано определенное значение с экрана, после этого сделать в Owen Cloud импорт файла
Json со всеми сетевыми переменными прибора, то ведь в этом случае значение настраиваемых управляемых переменных в облаке будет 0, такого же значения они станут и в приборе в
не зависимости от первоначального значения заданного с экрана или нет, сохранят значения ?
сделать в Owen Cloud импорт файла
Json со всеми сетевыми переменными прибора, то ведь в этом случае значение настраиваемых управляемых переменных в облаке будет 0, такого же значения они станут и в приборе в
не зависимости от первоначального значения заданного с экрана или нет, сохранят значения ?
Облако сначала прочитает значения из прибора, потом будет возможность их изменить и только по подтверждению пользователя. Никакой самостоятельной записи не будет и соответственно никаких внезапных изменений.
Облако можно представить в виде обычной панели оператора, просто очень удалённой.
Powered by vBulletin® Version 4.2.3 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot