Добрый день! В начале сентября планируем выпустить обновление, где появится ПИД-регулятор с автонастройкой для приборов второго поколения, в том числе и ПР205.Цитата:
Сообщение от majevgenij
Вид для печати
Добрый день! В начале сентября планируем выпустить обновление, где появится ПИД-регулятор с автонастройкой для приборов второго поколения, в том числе и ПР205.Цитата:
Сообщение от majevgenij
1. Вместо роста знаний и навыков Вы предлагаете деградацию. В соседней теме человек разоряется, что вместо рецепта "на два клика мышью" его отправили читать. Потребность опции автонастройки только у начинающих или совершенно случайных людей.Цитата:
Сообщение от Traveller
Также, как и ИИ, автонастройка (АН) - всего лишь инструмент в руках наладчика, а не обывателя - после нескольких экспериментов с АН наладчик выбирает наиболее оптимальный вариант. Тем более, что существуют несколько критериев оптимальности настройки, а Вам предложат какой-то один.
Ещё - макрос ПИД с АН это часть прошивки и этот макрос нельзя вложить в другой - т.е. вместо сохранения полезного регулятора с дополнительными свойствами (например, плавное изменение уставки, настроенных переключений между РУЧ-АВТО) получаете мерзкую рассыпуху, теряя время при программировании.
Т.е. минусов много. А плюс всего один - подобие настройки может получить посторонний человек, но следующий шаг - посторонний полезет и в другие настройки, отключит защиты.
Уже неоднократно повторял - оценочно все коэффициенты ПИД регулятора можно получить без включения электричества проведя вычисления в уме. А дальше уточнить их экспериментом.
2. После знакомства с ПР205/225 добровольно не вернусь к ПР200.
Просто ощутите:
- почти 10 сокращение времени цикла,
- несколько сот Modbus регистров против 64 целых или 32 real у ПР200 (а только ПИД регулятор требует 5-6),
- инициализация начальным значением Modbus-регистров при помощи флажка ("птички") против громоздких макросов на холсте,
- наличие Ethernet,
- более информативный экран,
- подключение к облаку через любой роутер.
Сделав всего одну программу на ПР205 я нашёл доводы к переходу на 205 - даже в скорости программирования.
Поясню по поводу Modbus регистров.
Сетевые Slave переменные у всех ПР очень удобны для хранения настроек. И используя их сразу и для настроек и для переменных состояния процесса - никогда не столкнётесь с необходимостью грандиозной переделки проекта для работы с панелью или облаком.
В свежих проектах используется сетевых переменных:
- для насоса вакуум установки - 68
- насосной станции из 2 насосов - 116
- насосной станции из 3 насосов - 110
Везде ПР200 не подходит.
Я неоднократно работал и с ПР200 и с ПР205 - сравнивая, делаю предпочтение ПР205.
Попробуйте применить ПР205 и тоже останетесь. Цена прибора не так важна, как удобство и скорость работы.
Ой как многа текста :)Цитата:
Сообщение от FPavel
Не, я понимаю что вы профи и для вас не проблема потратить часов 5 настраивая ловя максимумы и минимумы + засекать пока остынет или нагреется, типа вычисляя инерцию, но не все же такие умные, я же уже написал:
Вот как с этим быть?Цитата:
Сообщение от Traveller
А так да, каждый сам себе злобный буратина, в.т.ч. и те кому не хватает АНР... :)
Из собственного опыта могу утверждать - ПР205 многократно превосходит по возможностям ПР200.
Не по дисплею, а по возможностям, удобству при программировании.
Я недавно публиковал pdf с программой для упомянутой вакуум-установки. https://owen.ru/forum/showthread.php...058#post470058
Если сочтёте возможным - опубликуйте собственную. Подозреваю, что мнение о толковости ПР идут из стиля и архитектуры программы.
pdf получается печатью на один лист формата А3 средствами Windows - там есть какой-то pdf-принтер по умолчанию.
Яж разве спорю, но есть одно маленькое но, пока не будет возможности его запрограммировать так, что бы этим мог пользоваться дежурный дядя Вася электрик, не вызывая из отпуска на Бали, специалиста который умеет, то оно и даром как гриться не нать, не, ну даром можно конечно побаловаться, но для работы, которая приносит прибыль, я поставлю уже то, что будет отвечать моим требованиям на 100%, нам же нужно ехать, а не шашечки, я в том плане, что нужно работу делать, а не то что бы дисплей был красивый... :)Цитата:
Сообщение от FPavel
А у какого объекта управления стремительно и внезапно изменяются характеристики?
По каким причинам?
У меня в практике был случай, когда отопление торгового центра было паровым из старой паровой котельной. Соответственно, от погоды расход питательной воды через деаэратор менялся. Поддержание уровня воды в деаэраторе было на ТРМ12. При этом получалось, что больших морозах в середине зимы нужны были одни настройки ПИД, а в начале и конце зимы - другие настройки.
Записал их на бумаге и вложил в шкаф. Два раза за сезон местный киповец менял настройки.
За 15 лет, которые обслуживал эту котельную - настройки так ни разу и не потребовалось уточнять - ни на котлах, ни на деаэраторе, ни на ПЧВ насосов подпитки. При должном уходе за оборудованием, деградация объекта происходит медленно.
Характеристики не меняются, но если вдруг, ПР-ка прикажет долго жить, ну бывает и у меня было пару раз причем, практически сразу одна за другой, ну да я их поменял сам, но вдруг окажется что, на смене дядя Вася, а я на даче, ну дык, как закатать программу в ПР-ку я подробную инструкцию написал, там ничего сложного, а вот с этими коэффициентами можно перепутать (такое кстати тоже было, не в данном случае, а вообще, в моей практике) и тонны продукции потом придется утилизировать, что кстати тоже не дешево, человеческий фактор ни кто не отменял, я же уже приводил куда печальнее примеры когда, неточности и невнимательности, причем сертифицированного и обученного персонала приводили к человеческим жертвам, а так в инструкции будет прописан простой алгоритм, нажмите одновременно две кнопки и удерживайте их пару секунд, все остальное, сделает автоматика, ну знаете ли защита от дурака, хотя конечно, я признаю, что от всех дураков нет защиты, но стремиться к этому нужно... :)Цитата:
Сообщение от FPavel
Если я сейчас начну приводить примеры из своей практики, то я могу на эти темы книгу написать... :DЦитата:
У меня в практике был случай, когда отопление торгового центра было паровым из старой паровой котельной. Соответственно, от погоды расход питательной воды через деаэратор менялся. Поддержание уровня воды в деаэраторе было на ТРМ12. При этом получалось, что больших морозах в середине зимы нужны были одни настройки ПИД, а в начале и конце зимы - другие настройки.
Записал их на бумаге и вложил в шкаф. Два раза за сезон местный киповец менял настройки.
За 15 лет, которые обслуживал эту котельную - настройки так ни разу и не потребовалось уточнять - ни на котлах, ни на деаэраторе, ни на ПЧВ насосов подпитки. При должном уходе за оборудованием, деградация объекта происходит медленно.
Для ПР205 есть возможность восстановить параметры при помощи OwenConfigurator - сначала считать, сохранить в файл, восстановить из файла.
Для ПР200 - не уверен, нужно смотреть.
За Деаэратор Вы правы. Тож сделал на ПР205. Делал на 200 и 205 на 205 получилось лучше. По отзывам эксплуатантов (Таких как дядя Вася) все ОК. Работает 2 года. ПР получена с Бета теста.
Формирование наличия Modbus соединения по аппаратной переменной, возможно, не корректно работает.
Проект содержит два ПР205 в двух шкафах на расстоянии до 10 м. Связь между ними по Modbus RTU RS-485.
Для Master обрыв соединения определяется с фиксацией по инверсии аппаратной переменной наличия соединения с задержкой 15 секунд.
Для Slave обрыв соединения определяется по прекращению изменения принимаемой целочисленной переменной с задержкой в 4 секунды.
И тем не менее, ошибка зафиксировалась в Master, а в Slave ошибки не случилось. Непонятно, ведь у Master задержка 15 секунд против 4 секунд у Slave.
Также, Slave управляет собственным ПЧВ, который почти всё время стоит в ожидании.
Вывел на дисплей ПР205 состояние обрыва связи с ПЧВ - получил на экране непрерывно мигающий индикатор.
Мне кажется, что или я не понимаю назначение привязанной переменной или её алгоритм некорректен.
Прикладываю скрины:
- Master - привязка переменной к аппаратной части
- Master - формирование сигнала текущего отсутствия связи со Slave
- Master - формирование изменяющегося числа для Slave, чтобы Slave мог следить за состоянием связи
- Slave - формирование сигнала текущего отсутствия соединения с Master
Не стал показывать фиксацию с задержкой, но поверьте, это один и тот же проверенный макрос.
Это же неправильно, что один прибор фиксирует обрыв соединения, а другой даже не замечает этого.
Очень странно, в смысле, Вы сами придумали неправильную логигу и другим жалуетесь на это?Цитата:
Сообщение от FPavel
Впрочем не надо расстраиваться, этот вопрос много раз обсуждался, в смысле, надо было просто взять готовое типа такого:
Вложение 85414
Если всё же прочитать мой вопрос - предложенное решение там уже реализовано в Slave.Цитата:
Сообщение от Сергей0308
А вот в Master контроль выполняется по переменной, привязанной к аппаратному контролю. И это единственный способ определить отсутствие связи с готовыми устройствами типа ПЧВ, ТРМ. Поэтому применить для контроля связи с другим ПР тоже считаю корректным.
Проблема состоит в том, что в Master с контролем по аппаратной привязке сработала ошибка при 15 секундах задержки, а при контроле через heartbeat в Slave - не сработала даже с 4 секундами.
Оба ПР205 куплены одновременно, аппаратно идентичны.
Хорошо, верим Вам, в смысле, в мастере работает, а в слейве нет, так Овен здесь причём, в смысле, в слейве Вы сами формируете логику работы при потере связи?Цитата:
Сообщение от FPavel
Или объясните понятно, ясно и конкретно, что не так по-вашему, намёки здесь неуместны, мне так кажется!
А почему вы думаете, что конструкция в виде целочисленного XOR должна выдать требуемый результат?Цитата:
Сообщение от FPavel
В ПР производителем реализован аппаратный контроль соединения по Modbus только со стороны Master, со стороны Slave нужно реализовывать программно.
У меня система из двух ПР205, соединённых по Modbus RTU RS-485. Одно из ПР является Master, другое - Slave.
Контроль связи организован в них по разному: в Master - аппаратно, в Slave - программно (именно так - из Master приходят секунды и длительное отсутствие изменения является признаком ошибки).
При помощи TON и SR-триггера эти обрывы связи фиксируются после небольшой выдержки.
Для Master выдержка составляет 15 секунд, для Slave - 4 секунды.
Скрины привязки к аппаратной части Master и фрагменты получения признака отсутствия соединения привёл выше. Не показал только фиксацию ошибки на TON и триггере.
Вчера сработала защита по отсутствию связи. Оператор сбросил сигнализацию только на Master, а на Slave ошибки зафиксировано не было.
Это меня беспокоит.
Также, использую аппаратную переменную для определения обрыва связи с ПЧВ. Привязал индикатор на экране ПР205 к аппаратному сигналу - наблюдаю постоянное мигание индикатора, т.е. аппаратура постоянно диагностирует обрыв и восстановление соединения.
Возможности получить от ПЧВ переменную с секундами для программной диагностики связи - не имею технической возможности. И, получается, могу использовать только аппаратную переменную.
Меня интересует, как правильно интерпретировать аппаратную переменную, почему диагностирован обрыв соединения при задержке 15 секунд (а программная диагностика и при 4 секундах не заметила).
При отсутствии изменений переменной Heartbeat на выходе XOR будет целочисленный 0, а при изменении - на один такт будет что-то отличное от 0, после преобразования результата в BOOL соответственно получу 0 и 1, а дальше - небольшая фильтрация результата на TON с задержкой в 1-2 секунды.Цитата:
А почему вы думаете, что конструкция в виде целочисленного XOR должна выдать требуемый результат?
Может у вас сильные помехи, например от ПЧ, на одно из ПР они действуют сильнее, может оно ближе к источнику помех или сетевой фильтр хуже работает, мне так кажется!Цитата:
Сообщение от FPavel
И зачем так усложнять очень простую функцию, она становится неочевидной(трудно разобраться как она работает), Валенок как-то называл подобный код, типа индусский код, точно уже не припомню, зачем что-то выдумывать(время тратить не жалко) когда есть простое и очевидное решение, это мне непонятно!
Хорошо. Если есть другое решение - применю его.Цитата:
Сообщение от Сергей0308
ПР205 и ПЧВ связаны по Modbus. Определить в ПР205 обрыв связи, чтобы остановить неуправляемую работу.
Как определить?
"Слова ничего не стоят - код на бочку!" (c) Л. Торвальд
Чем же Вас не устаивает мой вариант для слейва? В мастере уже всё есть!Цитата:
Сообщение от FPavel
Как с помехами бороться было 100 тем, в смысле, можно поставить сетевой фильтр(я всегда ставлю иначе при работе с ПЧ - беда), применить специальный экранированный кабель, терминаторы и т. д.
Тем, что вы не вникаете в то, что я пишу.Цитата:
Сообщение от Сергей0308
Именно то решение, что Вы предлагаете - уже применено! Именно с его помощью в Slave и диагностируется обрыв.
А в Master я диагностирую по переменной с привязкой к аппаратной части - в окне настройки Master. И вот эта переменная ведёт себя не так, как я представляю.
Да, я могу и из Slave (ПР205) отправлять в Master секунды (heartbeat) и там диагностировать так же, как и в Slave, но другие slave-устройства (ПЧВ, ТРМ) останутся без диагностики.
Я не против бороться с помехами, но для начала хочу понять, что исправить в моём "индусском" коде.
Помехами будут заниматься другие люди и их работа - их личная боль.
Всё что вам надо, любая переменная из слейва, которая меняется постоянно типа Float, и используете её вместо секунд в том же виде с таймером. Вложение 85418
Как только изменение остановится (оборвётся связь), не будет сигнала сравнения.
На скрине, умножение на 1000, чтобы реагировало даже на изменение тысячных
А как пользоваться с переменной "наличие связи по Modbus" к которой привязываются в окне настройки Master?Цитата:
Сообщение от kondor3000
Это не праздное любопытство, т.к. при связи с ПЧВ (или ТРМ или другим slave-устройством) опять вернусь к диагностике от аппаратной переменной.
А напомню - вчера вечером оператор сбрасывал ошибку связи только на Master ПР205 с аппаратной диагностикой, но не сбрасывал на Slave ПР205 с диагностикой по изменению входящего числа.
Поэтому я и усомнился в корректности этой аппаратной переменной или в неправильном её использовании.
Если Вы сомневаетесь в работоспособности переменной потери связи в мастере, сделайте как в слейве, в смысле, читайте секунды часов из слейва. Во многих приборах предусмотрено действие при потере связи, ошибке, типа безопасного состояния, в ПЧВ точно такое есть, здесь и придумывать ничего не надо!Цитата:
Сообщение от FPavel
Вложение 85417
Да, так и сделал. И в ПЧВ настроил останов и в обе стороны ПР205 передаю heartbeat (изменяющееся целое число).Цитата:
Сообщение от Сергей0308
Отправляю исходники, завтра их загрузят.
Думаю, а не виновата ли неправильная настройка таймаута - 100 мс при 9600@8n1. На один байт отправляется 10 бит, на один ответ от Slave отправляется чуть меньше 10 байт, т.е. 100 бит, а значит ответ занимает по времени около тех самых 100 мс. Исправлю таймаут на 300 мс и буду ждать счастья.
--------------------
Сообразил, о чём речь в критике кода - вместо сравнения двух чисел EQ у меня XOR+ToBool+NOT.
Видимо, решал подобную задачу для BOOL и механически перенёс на целые числа. Результат выполнения эквивалентен (проверяется эмуляцией), только формула излишне усложнена.
Улучшу на эту короткую и более адекватную версию с EQ.
Просто от вида формулы, суть моего вопроса не зависела, поэтому не придавал и не придаю этому уточнению весомого значения.
Не знаю сюда ли я пишу, но раз это фичи и баги, значит сюда :)
Сейчас допиливаю один небольшой проектик, и в общем когда то давно использовал макрос fSave из базы данных OwenLogic, в принципе в старом проекте он работал нормально, ну я делаю копипаст из одного проекта в другой новый и вроде бы он тоже как бы работает в программе и как бы все делает правильно, но порой примерно 4 из 10ти раз, при включении выдает значение "Не число", которое так и висит пока не перезагрузишь контроллер, вернее может и не он выдает, а то что после него, но тем не менее... и как бы мне такая стабильность ни к чему, мне нужно что бы он всегда работал как в предыдущих проектах в 100% случаев! В общем пришлось этот макрос переделать, т.е. сделать такой же по функционалу, но предельно упрощенный и как бы все заработало, теперь работает всегда штатно! :)
Вот этот макрос из базы данных:
Вложение 85451
Вот этим пришлось его заменить:
Вложение 85452
Может я что то не догоняю, но тем не менее интересно, а зачем так усложнять, если можно сделать проще и это будет делать тоже самое 1 в 1?
В ранних версиях ОЛ в инструментах не было элемента fSEL По этому проще сделать было нельзяЦитата:
Сообщение от Traveller
Ну я так в принципе тоже подумал :), но с другой стороны, а что за этой базой ни кто не следит, т.е. ничего там не обновляется, как вложили туда, так и лежат там реликтовые макросы, ладно я, мне они нужны что бы принцип понять, я не гордый могу и на современный лад для себя сам переделать :), но не все же такие, сделают, а потом репу чешут, а что там не так, темы здесь развивают... :)Цитата:
Сообщение от petera
Подскажите, а на каком приборе ошибка воспроизводилась? Проверим у себя, в случае чего починим/обновим макрос.Цитата:
Сообщение от Traveller
Вот такое в обоих случаях: ПР200-24.8.2.0
Вложение 85571Вложение 85572
Ну, куда ж без этого :-)
Действительно, опечатка... Спасибо за бдительность!Цитата:
Сообщение от KotoVasya
Проверил Радиокнопку и Чекбокс на ПР205, даже повторить ваш пример не удалось. Вложение 85592
Слова больше 6 букв на влезают. Шрифт меньше сделать тоже нельзя.
Перенёс проект на ПР225, тоже всего 6 букв влезает.
В настройках контрола есть высота и ширина ячейки. В этих параметрах задается габариты окон, отведенных под текстовое наполнение. Можно увеличить ширину ячейки и все поместится :)Цитата:
Сообщение от kondor3000
Действительно, расширил ячейку и всё влезло Вложение 85600Цитата:
Сообщение от Королев Кирилл
Версия 2.11.368.
Что-то, вообще, непонятное происходит
тут работает
Вложение 85603
тут не работает
Вложение 85604
З.Ы. В железе работает
Вложение 85606
В общем, одно лечим, другое калечим
В новой версии стало невозможным использовать квадратные скобки в именах переменных, например, rPressure_[bar], rPressure_[mA].
Квадратные скобки из ранних проектов автоматически заменяются на фигурные например, rPressure_{bar}, rPressure_{mA}.
А при попытке добавить квадратные скобки к новым переменным, после нажатия ENTER - скобки просто исчезают.
Поведение действительно только для стандартных переменных, у сетевых - изменений нет.
Этого нет в списке изменений.
Имена по стандарту, конечно, не должны содержать скобок, но раз для фигурных уже есть исключение - чем квадратные не угодили?
Тем более, что 10+ лет это позволялось.
FPavel 10 лет... Ха! Я тольк щас узнал о такой дичи =)
Ха, в версии 2.11.368 добавили ПИД регулятор для новой линейки. И что прикольно, регулятор отличается от того что у старой линейки, а именно, он умеет с КЗР работать.
В менеджере компонентов в разделе Регуляторы добавили четыре макроса ПИД. По сути, это штатный ПИД завернутый в макрос. И второе "Ха", эти новые макросы предназначены только для новой линейки. На старой не работают (о чем есть сообщение в описании макроса)
Наверно Вы имеете ввиду с дискретными выходами больше-меньше?Цитата:
Сообщение от Dimensy
Интересно, как реализован ПИД с КЗР - как аналоговый ПИД + макрос RegKZR (т.е. при аналоговом выходе ПИД в крайних точках КЗР перестаёт регулировать, т.к. непрерывно открывается или закрывается)?Цитата:
Сообщение от Dimensy
Или там алгоритм не учитывает расчётное значение выхода, а продолжает регулировать импульсами, которые соответствуют ситуации?
У кого есть железная ПР205 - можете проверить на эмуляторе объекта?
Понятно, что скобки в имени - отступление от стандарта, но я его удобно пристроил:Цитата:
Сообщение от Cs-Cs
- для аналоговых датчиков даю почти одинаковые имена - различия в единицах измерения в этих скобках [mA] или [bar] - для "сырого" и масштабированного значений
- для переменных времени указываю единицы измерения [m], [s], [h] - очень удобно и при "стыковке" с макросом, вход которого оформлен аналогично - не требуется читать описание или искать внутри кода
Переменными с квадратными скобками в имени они окончательно болт на массивы положили. Так что ничего хорошего в этом нет.