Реализация обмена набора уставок с ПР200

Здравствуйте, уважаемые участники форума!

Прошу вашей помощи в следующем вопросе, связанном с использованием ПР200 в статусе slave и OwenCloud.

Известно, что ПР200 в режиме slave имеет ограничение на использование сетевых переменных в количестве 64 регистров. Это ограничение затрудняет передачу полного набора данных для управления сложными процессами с множеством шагов и уставок.

Хотелось бы узнать, существует ли возможность в рамках OwenCloud решить эту задачу путем написания программы, которая использовала бы шаблоны с набором уставок для каждого шага программы, разработанной в OwenLogic? Идея заключается в том, чтобы в OwenCloud динамически подгружать соответствующий шаблон уставок, получая номер текущего шага от ПР200.

Конкретно интересует:

Поддерживает ли OwenCloud такой функционал — хранение шаблонов уставок и их динамическую подгрузку в зависимости от данных от ПР200?

Если да, то есть ли документация или примеры реализации подобного?

Если нет, то планируется ли подобная функционал в будущем и есть ли возможные обходные пути?

Заранее благодарен за ваш ответ и помощь.

Не проще взять ПР205?

Что понимается под динамической загрузкой?
Использование 64-х регистров как 128? (Образно)

В рамках цикла, нескольких циклов программы ?

Или ПР сделала шаг, ей дали порцию, сделала второй, порцию поменяли?

Собственно, как вы это представляете в самой ПР ? оставим пока верхний уровень.

Есть платный функционал OwenCloud - программа (на языке Pascal).
Можете сделать какую-нибудь переменную в ПР200 - номер выбранного рецепта, и по её значению изменять набор переменных.
Но, думаю, требуется какое-то подтверждение из облака, что все уставки изменены и соответствуют выбранному рецепту, например, ещё одна переменная - номер загруженного рецепта. Особенно с учётом периода обмена и возможного обрыва соединения.
В таком варианте - все значения будут намертво прописаны в программе. И до подтверждения готовности со стороны облака - я бы блокировал работу программы в ПР (вдруг половину рецепта загрузил, а потом связь оборвалась).

Выбирать номер рецепта можно на мнемосхеме.

Но самым удобным вариантом был бы - замена на ПР205 - поддерживающее около 1000 сетевых переменных, что позволяет хранить все рецепты в разных переменных, т.е. достаточно изменить только одно число - номер рецепта. Один недостаток по мнению ряда пользователей - отсутствует встроенный ПИД регулятор с автонастройкой (вроде бы исправили вчера в версии 2.11) и стоимость на 50% (10 т.р.) выше.

Цитата:

---

Сообщение от Пашечкин

шаблоны с набором уставок для каждого шага программы

---

все переменные в облаке привязаны к переменным в устройствах, Вам не преодолеть ограничение таким образом. Если же это какой то фиксированный набор, то его не затруднить хранить и в самой ПР

Физически через 3 регистра можно передать хоть 300 регистров, но это займет где то 10- 30 секунд.
Делал проект, ради эксперимента, на панели СП310 и ПЛК.

В одной из тем я предлагал с помощью одного регистра передавать до 128 переменных, в смысле регистр разбивается на два байта, в одном данные, в другом служебная информация(число от 0 до 255) для "склеивания" байтов в приёмном устройстве, между двумя ПР такая передача возможна, если не нужно максимального быстродействия, но с облаком такое провернуть проблематично, мне так кажется!
Ещё можно в одну переменную упаковать несколько значений уставок, если они не космических масштабов!

все эти передачи через один, несколько регистров требуют одной простой вещи. ПР выполнила часть программы (шаг), отчиталась, дождалась новых переменных, продолжила выполнение.

на FBD в ПР проще будет застрелиться :)

Цитата:

---

Сообщение от melky

все эти передачи через один, несколько регистров требуют одной простой вещи. ПР выполнила часть программы (шаг), отчиталась, дождалась новых переменных, продолжила выполнение.

на FBD в ПР проще будет застрелиться :)

---

Так наоборот это поможет, в смысле, мозги не закиснут!

на FBD нельзя делать обходы, ну можно, закольцовывая переменные через SEL, но сама программа будет ужасть... если такое делать, то на ST

Цитата:

---

Сообщение от melky

на FBD нельзя делать обходы, ну можно, закольцовывая переменные через SEL, но сама программа будет ужасть... если такое делать, то на ST

---

Макрос в макросе - способ облегчения решения.

В принципе, делал запись наработки (три параметра - часы, минуты, количество пусков) из одной группы переменных в три (по числу насосов) - при помощи дополнительной переменной "номер насоса для записи".
Здесь задача похожа.

Т.е. заполнение конкретного рецепта - не очень сложная задача.

Единственное ограничение - ПР200 имеет энергонезависимых переменных 1016 байт = 254 переменных udint или real, т.е. количество рецептов конечно и не очень значительно.
Видимо, поэтому выбор автора темы - внешнее хранение рецептов - в облаке. Хотя и предложенный вариант хранения в виде констант - тоже вариант для рассмотрения.

Цитата:

---

Сообщение от FPavel

Есть платный функционал OwenCloud - программа (на языке Pascal).
Можете сделать какую-нибудь переменную в ПР200 - номер выбранного рецепта, и по её значению изменять набор переменных.
Но, думаю, требуется какое-то подтверждение из облака, что все уставки изменены и соответствуют выбранному рецепту, например, ещё одна переменная - номер загруженного рецепта. Особенно с учётом периода обмена и возможного обрыва соединения.
В таком варианте - все значения будут намертво прописаны в программе. И до подтверждения готовности со стороны облака - я бы блокировал работу программы в ПР (вдруг половину рецепта загрузил, а потом связь оборвалась).

Выбирать номер рецепта можно на мнемосхеме.

Но самым удобным вариантом был бы - замена на ПР205 - поддерживающее около 1000 сетевых переменных, что позволяет хранить все рецепты в разных переменных, т.е. достаточно изменить только одно число - номер рецепта. Один недостаток по мнению ряда пользователей - отсутствует встроенный ПИД регулятор с автонастройкой (вроде бы исправили вчера в версии 2.11) и стоимость на 50% (10 т.р.) выше.

---

Желательно иметь возможность удаленно менять значения уставок для каждого шага, поэтому и думал каким-то образом использовать для этого редактируемые шаблоны.

Цитата:

---

Сообщение от Пашечкин

Желательно иметь возможность удаленно менять значения уставок для каждого шага, поэтому и думал каким-то образом использовать для этого редактируемые шаблоны.

---

Тогда:
1. объявить набор переменных - уставок и заданий для рецептов
2. объявить переменную - номер записываемого рецепта
3. в целочисленной переменной для команд из вышестоящей системы выделить бит - строб записи рецепта

И соответствующим образом записывать рецепты в саму ПР, а потом из облака только менять номер применяемого рецепта.

У меня под рукой сейчас нет готового примера для записи времени наработки для трёх насосов - но идея записи будет именно подобной.
Могу сделать за 30-40 минут, но работоспособность в ПР200 нужно проверять - больше работаю с ПР205, а они проще работают с энергонезависимыми переменными, т.е. навыки с ПР200 у меня слабее.

через RapidScada можно такое организовать наверное. Или другую Scada. собственно смысл. Останавливаем ПР (программу), делаем несколько одинаковых команд, которые запишут всю пачку регистров, запускаем программу (ПР) с новыми данными. Тут важно, чтобы можно было в одну и ту же область записать разный набор данных. в Rapid это легко реализовать непосредственно при обмене с прибором. Насчет через облако, имея на хвосте ПМ210 или другой шлюз не пробовал.

Я сохраняю рецепты в энергонезависимой самой ПР и другой командой извлекаю в сетевые.
Вложение 85601

EFrol ну у вас же переменных не так много. да и рецептов тоже. А если их будет 10-ок (рецептов) и каждый по 20-30 переменных ? Внутри ПР на FBD ?

С рецептами никогда работать не доводилось, но из общих соображений сделал бы, как описал выше

1. объявить набор переменных - уставок и заданий для рецептов
2. объявить переменную - номер записываемого рецепта
3. в целочисленной переменной для команд из вышестоящей системы выделить бит - строб записи рецепта

И соответствующим образом записывать рецепты в саму ПР, а потом из облака только менять номер применяемого рецепта.

Вот, как в примере - его ещё нужно дополнить проверкой номеров рецептов, т.к. из сети могут поступить недостоверные.
Вложение 85602

По большому счёту, отличие от примера EFrol только в принудительном обнулении регистра команд и выбором номеров рецептов для использования и для записи при помощи отдельных переменных.

И ещё - весть повторяющийся код ОБЯЗАТЕЛЬНО оформлять макросами - поможет сократить число опечаток.

Цитата:

---

Сообщение от melky

EFrol ну у вас же переменных не так много. да и рецептов тоже. А если их будет 10-ок (рецептов) и каждый по 20-30 переменных ? Внутри ПР на FBD ?

---

Такая задача попадалась. Но там можно было вместо энергонезависимых регистров использовать просто константы.
Портянка на FBD получилась масштабная.:rolleyes:

Я подобное делал и выкладывал на форуме! Там всё очень просто, в смысле, например для 16 рецептов: ставится мультиплексор на 16 входов и так на каждую переменную(уставку). Уставки(рецепты) хранятся в ПЗУ(константы). Чтобы можно было оперативно менять(редактировать) пару рецептом можно сохранить в энергонезависимой памяти ПР, у ПР 200 её не так много, всё!
Короче, мне кажется, здесь минимум сложностей и ничего думать(придумывать) не надо, мультиплексоры должны быть в менеджере компонентов и я тысячу раз выкладывал на форуме, чуть ли не в каждом моём проекте встречаются.

Спасибо всем, кто откликнулся. Склоняюсь к варианту с мультиплексорами. Только уставки не константы, а локальные переменные, их будут заносить уже на объекте.