Если запоминать просто фронта, а потом формировать импульс произвольной длины, то конечно массив булей не нужен.
Вид для печати
Если запоминать просто фронта, а потом формировать импульс произвольной длины, то конечно массив булей не нужен.
Да и если надо прям повторить сигналы, то тоже самое - только время
А если 100-й спад затрётся 101-м фронтом? Что будет на выходе?
А если и он затрётся 102-м спадом?
Если время ещё не наступит для сдвига массива?
Так чел же написал, что задержка требуется 3 сек, а период импульсов 2 сек, так что здесь и массив как таковой не нужен. Можно и на квадратиках нарисовать
А вот, что он не написал, так требуется ли обрабатывать паузу, когда входящий импульс пришел и конвейер остановился до того как выход сработал
Чел написал что нужно повторить входное следование сигналов с задержкой а не создать независимую генерацию.
Предполагать что что-то механическое на входе имеет строгие 2 сек, насколько это принципиально, учесть банальное отсутствие одного (или.. ) изделий на ленте, колебания скорости конвейра прям в процессе - автор внятно не объяснил. Пока ясно только то, что нужны только передние фронты. Если это всё учесть, то на квадратиках и без массива-архива зае...тесь пыль глотать.
Допускаю что это всё вообще не нужно и есть какие-то принципиально другие решения, но это нужно знать полную технологию и итоговые задачи. Но "кушает" за это - автор.
Всех с Днем Великой Победы!
массив может быть и небольшим, если учесть, что на входе есть длительность сигнала, и следующий фронт сигнала всегда не меньше какого-то времени.
Но если смотреть на диаграмму, только первое включение имеет настройку задержки, далее должен быть повтор сигнала с нюансом настройки времени включения выхода.
Иначе на диаграмме везде было бы указано Т перед включением.
Спад не парит - автору не нужен. У вас массив на 101 значение)) т.к. 0..100.
Норм будет на выходе, как и хотели.
Так ранее вы сами же обозначали края.
Тот же вопрос: А если размер памяти для хранения необходимого окна архива будет больше наличной памяти?
Обычный ответ: Это проблема техники и/или того кто заявил свою хотелку.
Решение очевидное: Заменить технику и/или урезать осетра.
Здесь размер для массива ограничивает только память/синтаксис ОЛ. Ну и 2^32-1 мс таймера))
Тоже самое и если длина выходного импульса (по словам автора - какая-то константа) будет больше интервала между входными фронтами.
Обычное слипание.
Всё - выше. А сдвигать ничего не нужно. Индексы циклические и всего делов.
Если больше 101, то писать снова с 1го. Вчера только такой алгоритм для ИИ в кодесисе задал, но не стал тут выкладывать. Он почти аналогичен приведённому выше, только с данным условием.
PS
Код:
VAR
xInput : BOOL; // Входящий сигнал
tDelay : TIME := T#5S; // Желаемая задержка
xOutput : BOOL; // Выходной сигнал
// Структура для хранения события
fbGetTime : GET_TIME; // Псевдокод (зависит от целевого устройства, обычно TIME())
tCurrentTime : TIME;
// Очередь событий
arrValues : ARRAY[0..100] OF BOOL; // Состояния
arrTimestamps : ARRAY[0..100] OF TIME; // Когда выдать
iWriteIdx : INT := 0; // Индекс записи
iReadIdx : INT := 0; // Индекс чтения
xLastInput : BOOL; // Для отслеживания изменений
END_VAR
tCurrentTime := TIME(); // Получаем текущее время системы (мс)
// --- ЗАПИСЬ В FIFO ---
// Если сигнал изменился, записываем новое состояние и время его выхода
IF xInput <> xLastInput THEN
arrValues[iWriteIdx] := xInput;
arrTimestamps[iWriteIdx] := tCurrentTime + tDelay;
// Сдвигаем индекс записи по кольцу
iWriteIdx := (iWriteIdx + 1) MOD 101;
xLastInput := xInput;
END_IF
// --- ЧТЕНИЕ ИЗ FIFO ---
// Проверяем, не пора ли выдать сигнал, стоящий первым в очереди
IF iReadIdx <> iWriteIdx THEN
// Если текущее время больше или равно запланированному
IF tCurrentTime >= arrTimestamps[iReadIdx] THEN
xOutput := arrValues[iReadIdx];
// Сдвигаем индекс чтения по кольцу
iReadIdx := (iReadIdx + 1) MOD 101;
END_IF
END_IF
Да не нужен здесь массив булей. Время истекло - инверсия
С чего зациклится? Индексы сравняются и все
Не нужны никакие массивы булей
Возможно что есть смысл сделать еще и входной (+ синхронизирующий) Enable, но это хотелка-свистелка
Тема зажила своей жизнью))
Точно, там же индекс по отличию входа от предыдущего его значения меняется. ИИ всё же могет... Ну да, какой нибудь бит на старт. Ещё дня 2 поживёт и сойдёт на нет.
Предлагаю немного сменить тему. Например, попробовать решить давний спор между программистом и инженером АСУТП.
И: - Этот ST испоганил всю идею ПР. Я понимаю, что ST сильно расширяет возможности ПР, но требует обращаться к программистам за помощью.
Лучше бы расширяли библиотеки ФБ с подробным комментариями и примерами. Вот 1С пошла по пути замены программирования конфигурированием.
Пользователь расставляет нужные галочки и тем самым создает нужный алгоритм работы универсальной программы.
П: - Это сколько же надо времени пользователю, чтобы разобраться во всех галочках? Это сколько времени понадобиться Вам, чтобы нарыть в такой библиотеке нужный ФБ?
Если допустить, что в такой библиотеке будут ФБ на все случаи жизни.
И: - Так все производители стараются создавать универсальные приборы, впихивая по максимуму функциональность.
WEB-интерфейс с десятками страниц для настройки.
П: - А какой процент этих страниц Вы реально используете? Как часто, однажды настроив такой прибор в щиту управления, Вам приходится его перенастраивать?
Что лучше? Универсальный прибор с большим функционалом или ПР и знание ST?
На самом деле не правы оба.
Потому что есть простые алгоритмы, а есть составные.
Для 1-ого конфигурирование ("простые" имеется ввиду готовая программа, которую просто надо настроить)
Для 2-го нужно писать программу, пусть даже пользуясь более простыми.
Ну пример для 1. Готовые алгоритмы того же щита вентиляции. Выбрал через настройки датчики, схему вентмашины и т.д.
Пример для 2. Когда схема не является одной из стандартной.
Вообще не надо делать из асутп-шников программистов. У них немного другие задачи.
Грамотный асутпшник на производстве заменяет сисадмина, технолога, несколько киповцев и ещё кучу народа, а вот чтоб наоборот ещё ни разу не встречал...
так вот это и плохо, когда человеку надо знать больше, чем ему надо в рамках специализации :)
надо проще - дал команду админу, тот выполнил, может что-то подсказал. А не так, что асушник рассказывает админу как сделать.
Просто когда читаешь, например что на вакансию должен человек знать и уметь, удивляешься. Требуется и жнец и швец и на дуде игрец, но на зарплату только жнеца :)
У нас не запад, в России надо уметь всё и программировать и руками работать. Поэтому только программируемые устройства.
Все кто напишет наоборот, не хотят учиться или работать головой.
спасибо за проявленный интерес.
строгие 2 сек на входе - непринципиально.
про отсутствие изделия на конвейере я писал: нет изделия - нет сработки исполнительного механизма.
колебания скорости конвейера некритичны, т.к. на этот случай у исполнительного механизма есть механическое решение по точности позиционирования подъехавшего на конвейере изделия.
на квадратиках решение я выложил, но оно не изящное, конечно.
Здравствуйте. Подскажите пожалуйста, как при документировании функционального блока добавить описание побольше? Со временем забывается, а короткого названия не всегда хватает. Например как описание к блокам из онлайн библиотеки в ПДФ. Спасибо
Спасибо, это мне известно. Но не удобно, хотелось бы как Овена, в Библиотеке видеть и читать..
ilham345 Идеи и мысли:
1. PDF в билиотеке макросов сделаны ОТДЕЛЬНО.
То есть, взяли Word, в нём создали документ, вставили туда картинки, написали текст - и сделали из этого PDF.
2. Если блок рисуется в графическом виде, то я внутри него рисую большое поле комментария и там всё-всё себе (что могу забыть или непоянтно) расписываю.
Вложение 89421
Это тоже мне понятно и известно. Но хочу как у Овен. Чтобы листая в библиотеке можно было читать. вот как на скрине...Вложение 89422
Отдельно ПДФ сделать не проблема, а как и куда его "приклеить" не понимаю((
Спасибо всем! Буду работать)
Добрый день всем.
А PID регуляторы на ST не пробегали? мне все равно, для ПР или для CodeSys. все равно переделывать под C#. С поиском на форуме не очень дружу :(
да видел, что вроде пробегали, а поиск по PID или ПИД ничего не хочет выдавать :)
просто еще есть нюанс, выход ПИД должен управлять через больше/меньше (если потребуется)
ПИД обычный, ПИД для задвижек и эмулятор задвижек, выложил FPavel
https://owen.ru/forum/showthread.php...l=1#post447749
https://owen.ru/forum/showthread.php...l=1#post430251
IVM чтобы с нуля писать, надо понимать математику :), я пока не в зуб ногой про работу PID внутри :)
kondor3000 спасибо, пошел изучать... его то я и искал :)
Еще на oscat кто-то обзывался, тоже там поищу, вроде были доки и бибки. В общем есть с чего начать...
В библиотеке Utils (Codesys 2.3) есть аналоговый ПИД. Библиотеку можно открыть в редакторе - для этого в диалоговом окне открытия изменить тип файлов с prj на lib.
Там, правда, своеобразная реализация.
При вычислении I и D составляющей учитывайте период пересчёта, иначе это будут необъяснимые коэффициенты.
По поводу регулятора для задвижек больше/меньше - думаю, что в сообщении подробно объяснил алгоритм и привёл формулы. В самом ФБ тоже достаточно комментариев. Но, если возникнут вопросы - спрашивайте.
Если на лабораторках у Б.Н. Шелешпанского довелось разбирать работу регулятора Р25 - должны помнить, что после внесения рассогласования формируется первый большой импульс (П и И составляющие), а потом только короткие импульсы (И составляющей), длительность которых равна минимальной длительности (задаваемой с лицевой панели). Это должно помочь с пониманием алгоритма.
FPavel мне больше нужно это в код превратить :), тестировать и давать мне по ушам, что не так запрограммировал будут другие специально обученные люди.
Просто, чтобы программировать не абы что, немного изучить вопрос нужно. С PID раньше не сталкивался, хватало гистерезиса.
В ВУЗе нам головы иссверлили этим ПИД в разных ипостасях. Уже настолько пропитался им, что даже объяснить формулы не могу.
Как понимаю, все формулы сведутся к вычислению в конечных разностях и тогда придётся учитывать время между пересчётами, т.е. довольно точно отмерять время. В ПЛК это просто, а на C# - затрудняюсь сказать, т.к. Windows не является ОСРВ (операционной системой реального времени). Но, в принципе, должно получиться удовлетворительно.
Аналоговый ПИД - это обычное вычисление по формуле с ограничениями выхода диапазоном от 0 до 1 (или от 0% до 100%).
Особенностью только является использование D - нужно сильно сглаживать или весь входной сигнал переменной процесса (PV) или только ту его часть, что поступает на вычисление этой D составляющей.
Формулу предлагаю взять с зависимыми коэффициентами, т.е. с вынесенным за скобки Kp. Это приведёт к тому, что параметр Ti станет измеряться только в единицах времени и будет осознаваем.
Содержимое сообщения с алгоритмом ПИД для КЗР чуть более развёрнуто приводил в своём блоге - его движок позволяет записывать формулы в LaTeX и лучше показывать, чем скрины.
https://www.cyberforum.ru/blogs/534277/8438.html
Повторюсь, будут вопросы - задавайте. По вечерам я дома и могу ответить. Через неделю начнётся ПНР - тогда длительно буду доступен по субботам.