Прошу прощения - именно загрузку из собственного сообщения не проверял.
Попробовал удалить и загрузить rar архив - не могу считать из сообщения.
Загрузил owl - и, о чудо, могу скачать из сообщения.
Обновил сообщение, теперь можно скачать
Видимо, это какая-то проблема форума.
Может, после исправления, и из исходного сообщения можно будет скачать этот и другие макросы...
Как-то не пришло в голову перепроверять прикреплённый файл на скачивание.
Спасибо.
Последний раз редактировалось FPavel; 27.01.2024 в 12:00.
смог) но было бы удобно. Еще то что оказывается есть старые и новые ПЧВ. В новых номера регистров иные и они ни в каких РЭ не прописаны. Благо что есть OPS сервер.
Вы не могли бы подсказать что означает - "статус не определен" в OPS когда пытаюсь считать регистры с ПР205. Хотя все выставлено верно. И пробовал разные варианты и настройки
Поделюсь макросом ПИ (урезанный ПИД) регулятора для привода с 3-позиционным управлением без обратной связи по положению.
Проверил его на одном объекте - регулировка температуры подачи теплосети при помощи смесительного клапана после гидравлического разделителя.
Т.е. процесс инерционный, время полного хода привода 60 с.
Понадобился такой, а на форуме предлагают или "аналоговый" ПИД с управлением по псевдо-обратной связи от математической модели привода или выход "аналогового" регулятора перерабатывают в ШИМ.
По формуле из РЭ ТРМ12 получил приращение выхода на каждом шаге пересчёта регулятора
dY.PNG
Физический смысл приращения - доля (-1,0...+1,0) от времени полного хода для перемещения привода с учётом направления.
Tm - время пересчёта регулятора
При каждом пересчёте обновляю также и расчётное положение привода, т.е. суммирую перемещения
SY.PNG
Сразу же ограничиваю "взвинчивание интегральной составляющей" значением в 20%, т.е. диапазоном (-1,2...+1,2). Этот параметр не выводил ко входам, а задал константой.
Для "отключения" интегральной, достаточно сделать время интегрирования менее 0,001, т.е. приравнять к 0.
алгоритм:
Также добавлено ограничение на паузу после реверса.
Кроме того, ввёл диагностику, останавливающую вычисления и выводящую сигнализацию на выход ФБ при некорректных входных параметрах.
Наверняка, можно расширить список проверок.
Входные параметры:
fPV — переменная процесса (process variable);
fSP — уставка (задание) процесса (setpoint);
fDeadBand — зона нечувствительности (dead band) - в каждую сторону, т.е. в итоге вся зона в два раза больше;
fKp — коэффициент пропорциональности, значение полосы пропорциональности Xp=1/Kp равно величине невязки (рассогласования) при котором регулятор сформирует импульс длительностью равный времени полного хода привода;
fTi — время интегрирования;
nTRecalc_[ms] — период пересчёта (квантования) значения выхода регулятора,
nTFullStroke_[ms] — время полного хода (full stroke);
nTPulseMin_[ms] — длительность минимального импульса;
nTPauseReverse_[ms] — минимальная длительность паузы между командами реверса;
bEnable - разрешение работы регулятора (при запрете не только останов, но и сброс накопленной интегральной составляющей)
bReset - задумывал, как установку "интегральной" в заданное со входа значение, но не реализовал, поэтому получил второй вход bEnablr, но инверсный
Выходные параметры:
bOpen - команда на привод "открыть" регулирующий орган;
bClose - команда на привод "закрыть" регулирующий орган;
bError - ошибка введённых параметров, вычисления остановлены.
Ошибка введённых параметров для случаев:
1. nTRecalc_[ms] < 1000 мс
2. nTPulseMin_[ms] < 200 мс
3. nTFullStroke_[ms] < 1000 мс
Для зоны нечувствительности покажу изображением
DB.PNG
test_PID_3pos.owle
[09/03/2025] Сделаю дополнение.
Добавлю тестовую программу с ПИ регулятором и эмулятором объекта - для наглядности работоспособности этого макроса.
В примере незначительные изменения макроса - взвинчивание интегральной ограничено 0%, убран бесполезный вход Reset.
Test_EMU_3pos.owle
Сделаю ремарку по поводу параметров настройки.
Kp - тут всё просто, примерно в 6 раз меньше требуемого отклонения при регулировании Kp=1/(6*отклонение), размерность 1/[EU]
Ti - при такой формуле регулятора с независимыми друг от друга коэффициентами Kp и Ti, сами они зависят от диапазона изменения (в физических единицах) регулируемой величины. Размерность Ti - [EU]/[s]. Поэтому значение параметра fTi для наладчика (и для настройки поля ввода в HMI) может оказаться неожиданно большим или наоборот маленьким. Например, в тестовом примере получены значения fKp=0.0012 и Ti=65000. Но если привести Ti к размерности только времени, умножив на Kp - , то получим значение ( fTi ⋅ fKp=65000 ⋅ 0,0012=78 с) сопоставимое с максимальным временем апериодического звена модели объекта (150000 мс = 150 с).
Последний раз редактировалось FPavel; 09.03.2025 в 08:53.
Спасибо, 1exan
Ваше исправление на обратные связи убрало все предупреждения
ST для OL в январе оставался сырым продуктом, не позволяющем использовать внутри себя таймеры (без ввода времени извне), а также не позволяющий помещать полученный ФБ внутрь другого законченного макроса.
Ведь ФБ ПИД не является самоцелью, он потом помещается внутрь большего ФБ, чтобы на итоговом холсте для однотипных процессов (несколько контуров регулирования) была не рассыпуха, а несколько ФБ - отладка и исправление недочётов резко упрощаются. Так у меня используется один большой ФБ аналоговый ПИД с переходом в сон, плавным изменением уставки и ещё какими-то функциями - очень удобно, при очередном проекте обхожусь импортом вместо рисования.
Поэтому FBD - осмысленное решение, несмотря на большую однозначность последовательности выполнения операций в ST.
Сейчас возможности ST доработаны, рукастый желающий может воспроизвести алгоритм.
После сдачи работы, пока нет возможности проверить переработку в ST на реальном объекте как проверил с FBD, поэтому реализацию на ST отложу до следующего раза.
Работа отнюдь не титаническая - видно, что там всего лишь вычисления по двум формулам и потом условие включения и отключения триггера (разрешить перемещение). И условий установки-сброса триггера - по два-три. Вместе с отладкой сделал за два подхода вместе с изучением опыта на форуме.
Поделюсь макросом, помогающим экспортировать сетевые переменные из ПР205 в пенель оператора Weintek.
Макрос не совсем закончен, не совсем идеален, но резко сокращает время создания проекта в EasyBuilder для Овен ПР205.
У меня пока нет времени на его доводку, приведу то, что готово - может быть идея вдохновит на более законченные решения. Мне советовали использовать другой скриптовый язык - PowerShell, но со свободным временем для изучения пока туго...
Итак, поехали!
OL для сетевых Slave переменных имеет возможность экспорта тегов в файл формата csv в кодировке UTF-8.
Easy Builder для тегов также имеет возможность импорта и экспорта тегов файлом csv в кодировке UTF-8.
Файл OL содержит почти все необходимые данные для импорта в Easy Builder, нужно только переставить поля, заменить названия типов данных, добавить название устройства, под именем которого данная ПР описана в проекте Easy Builder. Что без проблем выполняется в Exel (MS Office) или Calc (LibreOffice) - вручную, долго.
Скрипт (пакетный файл - bat или cmd) отлаживался для ПР205. Для других ПР не уточнял, если последовательность первых 5 полей совпадает, то и для них возможно применить.
OL_PR205_to_Weintek.bat:
Используются утилиты из UNIX: sed или ssed - обе работают одинаково в данном случае.
https://sourceforge.net/projects/gnuwin32/files/
https://sed.sourceforge.io
Их установка - просто распаковка в какой-нибудь каталог. В случае gnuwin32 скачать и распаковать sed-4.2.1-dep.zip и sed-4.2.1-bin.zip
Утилиты пакета binutils очень распространены и чаще всего уже установлены с каким-нибудь пакетом программирования: WinAVR, Visual Studio и другими. Но при их отсутствии - легко скачиваются и устанавливаются.
Для работы нужно в скрипте уточнить:
- полный путь к sed (или ssed)
- название файла экспорта переменных из OL
- название итогового файла для Easy Builder
- после завершения работы скрипта нужно в текстовом редакторе открыть итоговый файл и заменить дефолтное название устройства "Owen_PR205" на то, которое задано в проекте EasyBuilder, иначе импорт будет невозможен.
Отдельное действие с названием устройства получилось из-за того, что не разобрался с кодировками.
Но и так, хорошо получилось - много быстрее, чем перенос руками.
В результате работы:
из файла экспорта OL 'ТестовыйПроект_Сетевые, Slave.csv':
Получаю
result.csv:
После замены в Блокноте второго поля "Owen_PR205" на название устройства из "системных параметров" получаю готовый файл импорта.
Импорт в Easy Builder настраивается двумя опциями:
- удалить старые теги (нужно снять выбор, т.к. иначе удалятся и необходимые системные теги)
- заменить существующие теги на новые (установить выбор и заменять, обновлять теги).
возможно есть по проще вариант и кроссплатформенный, на питоне
Код:import pandas as pd import numpy as np fnamesrc = 'Slave.csv' fnamedst = 'result.csv' spisok = {'Целые':'16-bit Unsigned','Вещественные':'32-bit Float'} def load_ds(fnamesrc,fnamedst): df = pd.read_csv(fnamesrc, delimiter=';') stuff0 = df[['Имя переменной']].to_numpy() stuff3 = df[['Адрес регистра']].to_numpy() stuff4 = df[['Комментарий']].to_numpy() stuff5 = df[['Путь к параметру']].to_numpy() stuff1 = np.full(len(stuff0),'Owen_PR205') stuff2 = np.full(len(stuff0),'3x') frames = [pd.DataFrame(stuff0), pd.DataFrame(stuff1), pd.DataFrame(stuff2), pd.DataFrame(stuff3),pd.DataFrame(stuff4),pd.DataFrame(stuff5).rename(columns = {0:'type'})] adf = pd.concat(frames, join = 'inner', axis = 1) adf['type'] = adf['type'].map(spisok) adf.to_csv(fnamedst, header = False, index = False) load_ds(fnamesrc,fnamedst)
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран