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

[Пашечкин]

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

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

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

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

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

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

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

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

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

[1exan]

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

[melky]

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

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

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

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

[FPavel]

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

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

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

[capzap]

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

[kondor3000]

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

[Сергей0308]

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

[melky]

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

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

[Сергей0308]

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

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

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

[melky]

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

[FPavel]

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

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

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

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

[Пашечкин]

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

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

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

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

[FPavel]

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

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

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

[melky]

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

[EFrol]

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

[melky]

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

[FPavel]

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

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

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

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

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

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

[EFrol]

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

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

[Сергей0308]

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

[Пашечкин]

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