Это где то документировано чтоб на разработчиков гнать?
Я обычно Кр меняю на отрицательный знак, этого достаточно
Вид для печати
Это где то документировано чтоб на разработчиков гнать?
Я обычно Кр меняю на отрицательный знак, этого достаточно
А вы проверяли, прежде чем писать?Цитата:
Сообщение от capzap
Хрен он работает даже с отрицательным Xp пока не поменяешь Мах и Минимум.
А у PID_REG отрицательную вообще нельзя применить.
"Очень умное решение" - это вообще гон ? По моему кто-то уже реально гонит.
Отрицательный Кп(Хр) уже где-то встречал для смены режима - или в PID (Utils Codesys) или КОНГРАФ (МЗТА). Если производитель заложил такую возможность, то она работает.
Как понимаю, смысл применения встроенного ПИД регулятора имеет один очевидный и превалирующий плюс - автонастройка.
Будет ли работать автонастройка для "холодильника", добытого таким образом?
это не из-за реализации частного ПИД-а, это в формуле видно https://docs.owen.ru/book_img/2154/20633.svg, что смена местами SP и PV даст отрицательный знак при положительном коэффициенте, что коэффициенту поменять знак, оставив уставку и текущее значние без измененийЦитата:
Сообщение от FPavel
Блок ругается, если в его настройках поставить отрицательный коэффициентЦитата:
Сообщение от capzap
я видел картинку с PID AT_ вот видео, мне кажется работает в режиме холодильник без руганиЦитата:
Сообщение от Dimensy
ЗЫ настройки ни какие не менял, внутрь макроса не лез Вложение 87372
Добрый день. Есть ошибки при работе блока в режиме симуляции. На приборе (и в онлайн отладке, соответственно) поведение будет корректным.Цитата:
Сообщение от tandrew
Вы можете конкретно написать, что надо сделать в настройках, чтобы блок работал в режиме холодильник?Цитата:
Сообщение от Королев Кирилл
Макс и минимум надо менять местами или нет?
В симуляции, к сожалению, не получится в данный момент корректно отладить блок. Из самых явных ошибок: перепутана пропорциональная составляющая (в симуляции - числитель, в приборе - знаменатель) и, в целом, некорректная работа в режиме холодильник.Цитата:
Сообщение от kondor3000
Могу написать, что нужно делать, чтобы корректно работал на приборе :)
- Просто выставить режим работы холодильник.
- Мощности менять местами не нужно.
- Коэффициенты корректировать каким-то специальным образом тоже не требуется (например, делать отрицательной пропорциональную составляющую).
Минимум, указанный в настройках, будет соответствовать минимальному воздействию на объект, максимум, соответственно, максимальному.
Тоже такая проблема, в какой конкретно момент появляется трудно отловить, открыто несоклько макросов, между ними переключаюсь, перетаскиваю переменные на рабочую область, потом просто сообщение посреди экрана с ошибкой, сохраняю проект сочетанием клавиш иначе никак, закрыл, открыл, дальше можно работать какое-то время.Цитата:
Сообщение от mitqa
Хотел бы добавить. Да, попользовался фильтром в панели переменных и поработал с макросом. Ошибка появляется когда курсор мышки навожу на область панели переменных. Я со страницы Лоджика все обязательные и рекомендуемые библиотеки скачал и установил - бесполезно. По времени возникновения у меня по разному, специально пробовал воспроизвести - не получилось.Цитата:
Сообщение от 66666666
Смогли наконец-то воспроизвести данный баг. Ошибка происходит если вбить что-то в поиск в панели переменных, после чего переместить одну из найденных переменных на холст, затем переключиться на макрос и навести курсор на панель переменных. Будем этот баг править.
Коллеги, привет!
Всех с наступающим!
Под НГ возникла засада. Был проект для ПР103 в ОЛ2.7.359.0. Этот проект открыл в ОЛ2.11.370.0, сменил целевую платформу на ПР205, сохранил. При попытке открыть получаю вот такое сообщение.
Вложение 87464
По совету старших товарищей удалили всю логику - ошибка осталась.
Прикладываю пустые проекты.
Если секцию AI_N_DAT в сломанном проекте заменить на аналогичную из целого - то вроде открывается (без гарантий отсутствия побочных эффектов конечно)Цитата:
Сообщение от Aviator_VZh
У меня вот так получилосьЦитата:
Сообщение от Aviator_VZh
https://disk.yandex.ru/i/6BMdEn_ljaWI-Q
Проект Evo_1.15_2.7_0 открывается и в 9 и в 11 версиях без проблем, переносится и сохраняется.Цитата:
Сообщение от 1exan
Да, 7 версия открывается, и платформа меняется - поэтому я лично не уловил в чём именно засада.Цитата:
Сообщение от kondor3000
Возможно в исходном проекте надо перед сменой платформы аналоговые входа отцепить и для верности токовый сигнал на всех поставить.
А попытка открытия 11 версии файла была просто из интереса
11 с ошибками, выше выложили видео,Цитата:
Сообщение от 1exan
7 окрывается, разница в кол-ве аналоговых входов ПР103 и ПР 205 их надо проверить.
После переноса платформы и проверки входов и сохранения, всё открывается в 11 версии.
Так фишка в том, что платформу надо сменить с ПР103 на ПР205. А у них количество входов-выходов разноеЦитата:
Сообщение от 1exan
Друзья, СПАСИБО!!!
Всё дело оказалось в том, что перед сохранением проекта в 2.11 с измененной на ПР205 платформой необходимо было в настройках прибора проверить настройку аналоговых входов. Ничего не изменять, просто проверить.
И ошибка ушла.
Всех с наступающим!
Здоровья и удачи Вам и близким!
Понятно, подобное называется эффект наблюдателя, грубо говоря, если мы начинаем подсматривать за фотонами(частицами) у них пропадает волновая функция, в смысле, они начинают вести себя как частицы, ещё в школе изучали!Цитата:
Сообщение от Aviator_VZh
У меня наоборот. Когда я начинаю подсматривать за фотонами, то они начинают вести себя волна. Ну, типа, освещают все вокруг.Цитата:
Сообщение от Сергей0308
У Вас наверно какие-то особенные фотоны, может даже запутанные!Цитата:
Сообщение от Aviator_VZh
Перед Новым годом (с неделю назад) столкнулся с багом Owen Logic.
Весь проект, к сожалению, на форуме выложить не могу, но при дублировании претензии в техподдержку обязательно прикреплю.
Проект автоматизации содержит несколько насосов, нагревателей, задвижек. Управление всем оборудованием возможно как в автоматическом режиме, так и в ручном режиме с панели оператора Weintek.
Задвижки не имеют концевиков, поэтому управляются "на доверии" - т.е. в программе используется модель задвижки, которая по длительности сигналов "открыть" и "закрыть" вычисляет позицию и срабатывание концевиков (вопросы по решениям и подбору оборудования - к проектировщику, я лишь получаю ТЗ и реализую его).
Эти задвижки открываются только перед пуском насосов для заполнения их водой. Поэтому повторяющийся код с моделью и условиями открытия-закрытия одной задвижки оформлен в макрос. По количеству задвижек программа содержит два макроса.
Каюсь - до этой поры игнорировал предупреждения о циклических связях, поэтому программа содержала 11 таких сообщений. Но при этом, внутри использованных макросов циклических связей не было.
Ошибка проявлялась следующим образом:
Поведение наблюдал как по состояниям на панели, так и на ПР по значениям переменных в режиме онлайн-отладки.
Во время ПНР и проверки исполнительных механизмов с панели оператора перевожу в ручной режим обе задвижки.
Подаю сигнал открыть или закрыть на первую задвижку - через время полного хода (45 секунд) срабатывает "концевик" модели и соответствующее реле выключается и управляющее напряжение с привода снимается.
А вот для второй задвижки срабатывание "концевика" выполняется почти сразу без выдержки времени полного хода в обоих направлениях (и открыть и закрыть).
Ситуация странная, т.к. для каждой задвижки использовал экземпляры одного и того же макроса.
Проблему решил устранением циклических связей - заменой соединительных линий на линии обратной связи.
Ошибка воспроизводилась на ПР205-230.1211.22 и двух разных OwenLogic 2.10.367 и 2.11.370 (с заменой прошивки в ПР).
Думаю, что это всё же ошибка OwenLogic, т.к. несмотря на мою небрежность к циклическим связям, макросы для двух задвижек должны были отрабатывать одинаково - т.е. при формировании состояний "задвижка открыта" или "задвижка закрыта" должно было выдерживаться время полного хода. Тем более, что для одной задвижки это работало, а для другой - нет.
После устранения всех циклических связей - ошибка ушла, т.е. макрос корректный.
Приведу внешний вид макросов в программе, чтобы показать, что все переменные подключены, не перепутаны. Назначение макросов - при поступлении запроса включения насоса перекачки воды - проверить его заполненность водой и при необходимости выполнить заполнение (открыть задвижку и включить погружной насос заполнения). Задвижки индивидуальные, а насос заполнения общий, поэтому сигнал его включения объединяется по OR.
Повторюсь, проекты для ПР и Weintek отправлю в техподдержку, т.к. не могу их опубликовать.
Но для себя сделал вывод, что предупреждения о циклических связях не столь безобидны.
На языке ST это примерно если бы вы поменяли местами 2 строки, на LD это поменять местами 2 ветви. Это очень критично. Код совершенно по разному будет работать. Но иногда, если в программе нет замороченных связей, это случайным образом проканывает. Тут у вас не прошёл этот финт, где то эта последовательность выполнения и присвоения переменной портит вам всю логику, но это не баг OL, это реальность...
Писанины много, а толку как обычно 0.
Если это макрос на FBD, то при копировании, связи в макросе могут просто разорваться. Надо проверять.
А по выходным линиям задержки видно, что выхода присваиваются в разной последовательности.
Возможно дело не только в линиях задержки, но и в присвоении выходов (например по разному присваиваются энергонезависимые и нет
или с настройкой присвоение в конце цикла -Да или Нет)
А я всегда согласно логики линию задержки ставлю. А если что-то не уследил и Лоджик подсветил желтым, то разбираюсь что на что влияет и ставлю линию задержки (и не всегда там где ее Лоджик подсветил).
Не могу публиковать весь проект.
Повторю - есть макрос на FBD - Prepare_Pump_ - он содержит БЕЗ циклических связей формирование условий открытия и закрытия задвижки, включение насоса заполнения водой через эту задвижку, контроль заполнения трубопровода через дискретный датчик, формирование сигнала разрешения включения основного насоса.
В системе два рабочих насоса, поэтому через две задвижки они заполняются единственным насосом заполнения. Поэтому есть смысл повторяющийся код оформить макросом.
Этот макрос не секретный и приведу его здесь в тестовой программе - он НЕ содержит внутри себя циклических связей.
Ошибка работы ППО на OL состоит в том, что когда поступает сигнал открыть задвижку №1, то после этого сигнала через 45 секунд (время полного хода) сигнал выключается. А вот для задвижки №2 время не выдерживается и выключение происходит почти сразу.
А макросы - одинаковые, и по скрину видно, что снаружи они подключены без обрывов связей.
Т.е. пауза на TON внутри макроса должна отрабатывать и для задвижки №1 и для задвижки №2.
А должна, потому, что подаю с панели команду открыть-закрыть - и вижу эту команду на входе в макрос.
К сожалению, не записал видео, как одна задвижка открывается 45 секунд, а другая - почти мгновенно.
При ПНР первым делом проверил подключение переменной времени полного хода к макросу. Проверил прохождение команд РУЧН-АВТО и ОТКР-ЗАКР от панели - проходят. Значит таймер внутри макроса должен выдержать 45 секунд. НО, не выдерживал для задвижки №2, а выдерживал для №1.
Прикладываю скрины макросов и тестовую программу с ними - это не та, с которой ошибка.
Ещё раз выделю ошибку:
- в ручном режиме все циклические связи уже недействительны - они не проходят через маски из элементов AND
- в ручном режиме остаются только сигналы переключения РУЧН-АВТО и ОТКР-ЗАКР, приходящие от панели оператора
- макрос и вложенный в него - НЕ содержит циклических связей
- при подаче в РУЧН команды ОТКР (или ЗАКР) внутренний таймер TON не выдерживает 45 секунд, а сразу формирует сигнал окончания отсчёта
А таймер в макросе неожиданно стал одним и тем же, и вышло у него время...
Хотя вроде таймеры тут все программные и не должно быть такого, но вдруг как-то с этим связано?
Эта ошибку я устранял методом последовательного удаления соединений ко входам макроса, загрузкой и проверкой управления задвижкой в РУЧН режиме.
После какого-то очередного удаления связи работоспособность задвижки (таймера TON) в РУЧН режиме восстановилась. Тогда я восстановил связи, но устранил все циклические связи - после этого задвижка работала нормально.
Т.е. я устранил ошибку и сдал работу.
Но считаю, что ошибка в OL существует, т.к. таймер TON должен был отсчитать 45 секунд, а не один или несколько машинных циклов.
Возможно при какой то комбинации у вас срабатывал таймер, но не выходы макроса. Не полностью протестировали работу макроса или ещё что.
з.ы. вот банального EN не хватает в Лождике., типа ЕN в нуле и код даже не исполняй.
Вообще печалька, что программисты ОЛ непробиваемые буратины...
А куда, от кактуса деться? Сигнетикс - там свои буратины. Есть еще Зентек - косят под Карел и многие производители на него переходят - Нед, Веза, РовенЦитата:
Сообщение от melky
Dimensy да туда, в Пиксель да в Зентек, собственно Овен выигрывает только в математике, Зентек не пробовал, не скажу, а по остальным точно в плане математики Овен лучший.
НО, есть еще типы и количество входов/выходов и другие параметры, включая цену, а главное еще качество, и если именно математика не нужна такого плана, то Овен проигрывает.
а они этого не понимают, и боюсь с менеджерами от ЕГЭ не поймут никогда. А уж в вентиляции математика особо и не нужна.
Всё в Овен понимают - на смену Owen Logic уже пришла ALTA с 5+1 языками, развитыми средствами управления задачами.
Лично я жду.
Я тоже жду, но ценник там будет не ПР-ный. Так что не путайте мягкое с теплым. Альта это больше замена CodeSys 2.3 и возможно выше.
А вот сам ОЛ через попу писанный китайцами, и адаптированный русскими ни в какие ворота.
Насколько я понял, там целая экосистема планируется, где и ПЛК и ПРки и панели будутЦитата:
Сообщение от melky
Как раз ОВЕН всё понимает. И ведет весьма правильную политику. В которой качество и цена - да, важны, но не на первом месте :(Цитата:
Сообщение от melky
Подскажите, можно ли в ПР205 при переходе к экрану, содержащему компонент Меню, этот компонент был сразу активен без нажатия на SEL и первая строчка подсвечивалась? По аналогии с системным меню прибора.
Нельзя. Хотите сразу, рисуйте свое менюЦитата:
Сообщение от Aviator_VZh