вот ,изменил .
Вид для печати
вот ,изменил .
завтра добавим \АВАРИИ\ и усе ,почти ,потом оформим ввиде 2-3 макросов
ОК, я сегодня тоже не могу долго сидеть.
Спасибо!
Пробую разобраться с полученным подарком.
Вот практичкеский пример: а как уважаемый коллега rovki собирается добавить выход АВАРИЯ?
Втыкаю в схему. В голову приходит выражение примерно такого плана:
АВАРИЯ = Выход TON (5сек), на вход которого приходит: (~Q1) & (~Q2) & (была начата подача, но еще не было дозы)
(знак ~ использую для инверсии)
Ищу это выражение "была начата подача, но еще не было дозы". В схеме всего 3 триггера, которые хранят то, что можно назвать остатками моих фаз: RS1, RS2, RS3. На искомую роль легко идет именно RS1 - он взводится в начале подачи и падает при получении Уставки2.
Значит ли это, что вот берем схему И на 3 входа:
~Q1
~Q1
RS1.Q
подаем с нее на вход 5-секундного TON - а его выход на АВАРИЮ - и всьо?
Попробую проверить, если меня редактор не выведет из себя :)
ДОБАВЛЕНО: Я в шоке... Работает! Удивительно. Самое смешное, что с редактором не проблема, я просто таскал связи, которые мне были нужны, не обращая внимания на красоту полученного рисунка. То есть, добавление всего, что я описал, заняло... ну, две минуты, если не меньше (сначала забыл об инверсиях). То есть - удобство на высоте.
Но. Но как же в этой каше разбираться потом?
Вспоминаю, что коллега rovki говорил о переработке схемы, разбиении на макросы или что там еще... Только это может спасти кашу. Иначе это шаманство.
держите на макросах .Разбираться нужно по функционально законченным блокам (макросам) .Да и что потом разбираться то ,если меняется логика ,то вносим изменения в макрос или делаем новый .Тоны и Тофы специально вынес за макросы ,но можно и внутрь засунуть.
В ОЛ совсем другой подход к программированию ,чем на ST .Запоминаем события на триггерах(если события могут быть кратковременные) ,используем логику ,таймеры ,,,ну и все для данного ,простейшего проекта.
Ну а дальше сами... будут вопросы ,обращайтесь ....
Шикарно!
Спасибо огромное!
Я понимаю, что нужно много научиться, чтобы самому синтезировать такие схемы. Ибо вот этот магический момент, от обсуждения ТЗ до появления первого варианта, остался для меня загадкой. Ну, ничьо, разберемси.
В ходе игр с последним вариантом увидел, что снятие сигнала РАЗРЕШЕНИЕ РАЗГРУЗКИ во время самой разгрузки приводит к закрытию днища. Так не должно быть. Если уж в момент анализа этого разрешения мы получили "добро", то дальше нам по барабасику, ибо разгрузку не остановишь.
Будем считать, что это мое домашнее задание :)
Хорошего выходного!
P.S. Другие варианты реализации мне тоже интересны, есличьо...
ставим триггерочик ,который взводится по фронту разрешения ,а сбрасываем в конце цикла .....Можно засунуть внутрь макроса ,а можно поставить снаружи .
Да уж пообсуждали на 9 листах ,,,на схему саму затратил около часа (с переделками)
Уважаемые коллеги,
Я действительно глубоко благодарен Вам, ососбенно коллеге rovki, за введение в мир программирования ПР. Во-первых, я понял (кажется), как принято составлять ТЗ для любителей классического FBD. Действительно, все не так, как я привык.
Во-вторых, взяв щедрый дар от нашего уважаемого пропагандиста ПР, я изучил проект, понял, как это выглядит и как работают макросы. Я даже начал править проект, вполне успешно.
Но остались 2 "но".
1) Асболютно непонятно, как это создать. Да, с шаблона коллеги rovki можно и слепить что-то. Но КАК он это получил... У меня нет столько мозгов.
2) Отладка такого проекта для меня очень сложна. И дело не только в малом опыте, он у меня все же не нулевой. Принципиально дело в том, что вы строите все на логических выражениях, если нужно, поддержаных элементами памяти (триггеры) и задержек. Угадать, в какой точке нашего процесса (циклического) внезапно (или "запно") сработает то или иное условие - сложно. Ососбенно, когда что-то изменил, а оно вдруг выскочит совершенно неожиданно в другом месте...
Вот поэтому, имея уже неплохо работающий проект имени rovki, я сегодня с утреца все сделал так, как и собирался. Слава Богу, вы меня уже немного научили, за что еще раз спасибо.
Проект прилагаю. Конечно, в ходе разработки и отладки (завтра покупаю железо, будем отлаживать нипадецки) я кое-что изменил и в ТЗ. Но не существенное.
where the project is :cool:
Требуется не много мозгов ,а по другому устроенные .Есть искусство программирования и есть искусство схемотехники .
Что бы повернуть мозги нужно решить десяток простеньких задач (проектов) .После того как повернете начнется процесс самосовершенства ;) бесконечный
Если вы поняли как составлять (подробное) ТЗ для ПРки(ОЛ) ,то это уже пол дела .Как слышим (читаем ТЗ) ,так и пишем (рисуем) проект .Естественно используем нужные ФБ и макросы .Например бегущая единица -используем нужные ФБ или макросы (соответствующие) .....
Если необходимо выявить(зафиксировать) во времени какое то состояние(событие) ,то используем триггер (флаг) ,которые не забываем сбрасывать в нужное время ....
Завтра?с1234
Конструкция понятна ,но не оптимальная .Для вашего простейшего случая она избыточна ,но полезна для изучения ОЛ .Заметил что либо логика изменена либо ошибки .
Добрейшего всем утречка!
Уффф. Не стал править свой вчерашний пьяненький бред. Смешно получилось, не мог приаттачить проект, хоть убейся. А похвастаться же хотелось, аж руки чесались!
Этот совершенно сознательно. Я же не скрывал, что учусь и мне было важно понять, что можно получить в йентом самом ОВ. Кроме того, сам подход с привычными мне фазами - получится или нет.
Боюсь дискутировать с вами, ибо я в данной области "от горшка два вершка", но с этой высоты все же мне видится очень перспективным использование вот такого "степпера", как я придумал. Скажем так: мне лично удобно. На каждом шаге (фазе) я анализирую те и только те переменные, которые имеют значение с учетом текущего шага. Скажем, когда идет насыпка продукта, я "ловлю" сигнал Уставка1, не забывая следить за сигналом ДНИЩЕ ЗАКРЫТО. И пофик в это время погода в Гонолулу! Она не влияет, как не влияет и Уставка0, как не влияет РАЗРЕШЕНИЕ РАЗГРУЗКИ и даже Уставка2. Ибо мы в этой фазе не случайно: мы в нее попали в результате предыдущих анализирований и действий.
У меня "на ходу" упрощалось ТЗ. Поэтому и поведение программы отличается от того, которое я расписывал раньше. Более того. Отладка в железе обещает дальнейшие коррективы. Ну, я же сам себе пишу ТЗ, сам и отступаю. Мелитопольцы уже заплатили аванс по работе, в которой я рискну все же поставить ПР вместо ПЛК. "Аннушка уже разлила масло". Вот там и посмотрим, что это за фрукт, ваше ПР110. Мне очень интересно.
(Хотя редактор схем все же вызывает большое раздражение. Вы-то уже притерпелись, ясен пень, а я все еще хотел бы подержать за кадык того пацана, что это писал!)
День добрый. А вот пацанов наших лучше не трогайте. Они стараются как могут, и поправляют огрехи.
За выходные смотрю дело сдвинулось. Если хотите попробовать пошаговый алгоритм, то попробуйте разобраться в "лесорубе". Там на самом деле достаточно просто, и именно так как вы и хотите, всё по шагам. Стоит счётчик, который перещёлкивается в зависимости от входных условий и на выходе Дешифратор в двоичный код, что соответствует включаемым входам. А между ними ППЗУ, в который Вы закладываете код для каждого шага.
Просто там конечно много блокировок нацеплено, может это помешало Вам разобраться. Но там всё таки опасный станок. Представьте что две больших фрезы могут столкнуться, ужас, поэтому и налепил. А так в основе то как раз и лежит три элемента (счётчик, ППЗУ, дешифратор).
"Хорошо, я посмотрю внимательнее" написал я и полез смотреть. Еще и удивился, мол, как же я не обратил внимание на то, что меня больше всего интересовало...
Хэх, так там же только описание, проекта нет. Потому и не связал ту реализацию со "своим" подходом :) Я тогда упирался в то, чтобы сделать ТЗ, приемлимое для знатоков ОЛ.
Мне интересно, как реализуется ПЗУ.
И еще у меня возникла трудность с временнЫми параметрами при перещелкивании CTN. Наступление следующего состояния у него как-то странно: есть такт, в котором у меня срабатывают 2 соседних компаратора, как будто на выходе счетчика присутствует и код 5, к примеру, и 6. В общем, не разобрался, а наставил задержек по 0,2 с в макросах. Коряво, надо будет понять, что за фигня.
И еще один стремный момент. Я был вынужден выбросить из цепей сброса счетчика входной сигнал от тумблера СТОП-РАБОТА. Иначе счетчик не уходил из состояния "0". Короче говоря, я полагаюсь на то, что при включении питания этот счетчик обнулен. Не слишком приятно, хотелось бы явно сбрасывать, но в симуляторе работает.
Так что идею я проверил, но к программе есть еще претензии. Именно на концептуальном уровне. Не чувствую, чтобы сама система перебора фаз (состояний счетчика) была стройной и логичной.
Я же тогда сказал, что уже выкладывал на форуме, надо было пошарится в архиве. Выкладываю ещё раз. Основное я пометил на схеме.
Что не понятно, переспросите. В ППЗУ (блок 16мем) в свойствах макроса справа внизу задаётся число десятичное, которое появляется на выходе при соответствующем шаге. Шаги идут снизу вверх от 0 до 15. Задаваемое число для соответствующего шага соответствует двоичному коду выходов в данный момент.
Можно и по другому чуть-чуть реализовать управление по событиям (фазам) .Для начала сделаем макрос ,который запоминает событие(переход из "0" в "1) и формирует короткий импульс ,причем последовательно во времени .То есть ,например событие по входу № 3,сформирует импульс при условии ,что были последовательно события по входу 1 ,потом входу2, это позволит упростить логику по входам .В макросе есть вход R-сброс всех событий ,для организации нового цикла.:rolleyes:
Затем добавляем счетчик ,пзу , экстрактор и получаем "синхрофазатрон";):rolleyes::o потом все засовываем в один макрос
я пока не понял, как это использовать. Но подумаю.
Во всяком случае, я хотел бы решить все вопросы организации "степпера" неким единым и стройным образом. Чтобы получился шаблон, в который начиняешь всего 2 множества: условия переходов по фазам и (полезные) действия в самих фазах. Последнее вполне можно закатать в ПЗУ, хотя меня смущает такой момент: как быть с выходами, которые не изменяются в данной фазе?
В общем, еще много нужно допилить.
О, еще есть инфо! Бум смотреть, спасибо!
на входа макроса заводится как информация со входов ,так из любой точки схемы ,в том числе с выхода макроса-(условия переходов) .Главное -нужно заводить события ,так как они располагаются во времени .С выходами будет ,то что вы запишите в ПЗу(макрос)
Исправьте в макросе свойство в макросе ПЗУ ,на использование в макросе -ДА ..
Ну вот например ваш дозатор ,цикл начинается с закрытия крышки ,потом пуск ,потом уровень1,потом уровень2 ,потом уровень ноль ,потом еще уровень0
в предышущем посте макрос SF был с ошибкой ,исправил (старая версия) и тут исправил старую версию
Вот пример как на базе этого макроса сделать бегущую единицу .в пзу пишем значения "картинки" 1,2,4,8,16,32,64,128 ...Входа все в кучу и все .:rolleyes:Ясно что можно проще ,но это пример как пользоваться макросом .
В данном макросе(способе) есть 7 шагов (интервалов) во времени(произвольной длины) .Шаг -любое последовательное во времени событие (переход из "0 в "1") ,в соответствии которого ставится любая комбинация на выходе макроса ,путем записи констант во внутреннее ПЗУ макроса .Он рассчитан для работы в циклических алгоритмах .
Следующим будет макрос ,позволяющий увеличивать количество событий (шагов) .
Я как раз проснулся с тоскливым обдумыванием ограниченности количества входов-выходов в макросах этой вашей хваленой ОВ :)
И решил, что есть такие пути:
1) максимально прятать внутрь те части схемы, в которых "позиционный код". Возможно, проводить границу разделения макросов по целочисленным аргументам. Ну, например, текущую фазу из макроса, где она создается и модифицируется, выносить для других макросов в виде числа. А в тех макросах, где она юзается, разворачивать число в позиционный код. Например, ставить блоки EQ и получать все интересующие нас значения в виде булевых переменных (равно или не равно, скажем, 5)
2) наращивать макросы в макросах (это то, что Вы собираетесь делать?)
Мне еще надо время понять полеты Вашей мысли, я так быстро не умею. Но наперед закину вот что: наш сиквенсер (степпер, фазовый управитель, как его назвать?) должен иметь такие параметры:
1) Реагирование не только на события, но и на постоянно существующие условия. Это значит, вот что. Допустим, в фазе 5 анализируется некое "событие". Так вот, нужно реагировать на это "событие" не только в случае, когда оно происходит (условие начинает выполняться) непосредственно в фазе 5. Нужно также реагировать на это событие, если оно произошло еще до наступления фазы 5.
Пример: вместо сигнала "Разрешение разгрузки" я ставлю перемычку. И хочу, чтобы в нужной фазе ПР увидел эту перемычку и пошел дальше "мгновенно", пусть там и прощелкает несколько циклов работы контроллера. Если же перемычки не будет, то ПР постоит в фазе ожидания разрешения разгрузки и по получению "события" пойдет дальше.
Я для реализации такого поведения наставил кучу таймеров по 0,2 с - это ужасное решение
2) "Произвольный условный переход"
В любой фазе мы можем принять решение о переходе не к следующей фазе, а к какой-то иной. Теоретически, можно требовать, чтобы из любой фазы при некоторых условиях можно было улетать на любую другую. Но практически это громоздко и трудно. Поэтому я бы рассмотрел чуть менее универсальное умение: в каждой фазе есть одно условие "нормального" выхода (к следующей фазе) и одно условие выхода к произвольной фазе. Скажем, у нас есть сигнал "Днище закрыто". Его исчезновение в некоторых фазах должно вызывать отработку аварийной ситуации. Сейчас я тупо сбрасываю счетчик фаз. И в состоянии INIT должен побеспокоиться о сбросе всего что нужно и переходе или не переходе в фазу BottomWait. А можно было бы зарезервировать некую фазу 8, предназначенную для отработки аварии "Днище упало во время подачи или ожидания фиксации результата дозирования". И именно туда направлять степпер (теперь уже джампер?) в случае такой аварии. Тогда в системе есть место и для других аварий - заведу фазу 9 для аварии "Слишком долго идет насыпка", фазу 10 для аварии "Не могу дождаться разргрузки" и т.д....
Одним словом, добавить условный переход, как в обычных программах, есличьо...
3) Конечно же, хотелось бы иметь масштабируемый степпер, чтобы фаз могло быть больше, чем 8. Мне просто повезло с моим первым проектом, но расширяться уже некуда. А может понадобиться.
Я не слишком размечтался?
хотел узнать, дошло ли до сознания, что в отличии от плк в ПРке выполняется весь код, который разместили в проектеЦитата:
Я не слишком размечтался?
Да, я понимаю, что в каждом цикле работы ПР (равно как и в случае ПЛК) производится отработка всех возможных блоков. Но степпер для того и создан, чтобы "разнести" по разным фазам анализ и отработку определенных комбинаций входов и внутренних переменных. Поэтому меня, как разработчика, не волнует "выполнение" тех частей, тех блоков, которые в данной фазе не важны. Я их все равно блокирую, на работу схемы (программы) в данной фазе они не влияют.
Вот это разделение схемы на несколько частей, важдая из которых "играет" в положенной фазе - главное отличие предлагаемого (здесь мною, но вообще это совсем не мое изобретение) подхода.
Я не про то, что Вы грамотно или нет производите селекцию, а про то что от "раздувания" кода, время исполнения, трата ресурсов и т.п. будет увеличиваться
Если мне не хватит производительности ПР, я буду работать с другой моделью. Но код должен быть понятным, отлаживаемым, пригодным для модифицирования в дальнейшем. Иначе лично я (за других не могу расписываться) работать с программой (схемой) не могу.
Предлагаю свой вариант. Правда у меня 5-й вход оказался лишним :). Руководствовался заданием в посте 55. Сделал частично с макросами. Если нужно, то можно и остальное убрать в макросы. Там кое-где есть комментарии (для этого надо навести курсор на блок или переменную).
Как обещал новые макросы фазатрона .Первый макрос (2шт) фиксатор событий ,второй- счетчик событий с преобразованием в код целочисленный ,третий экстрактор .Если в счетчик поставить 2ППзу ,то можно отрабатывать 32 события ,но тогда нужно ставить 5фиксаторов .Данный способ(абстракционизм;)) имеет право на существование ,но я предпочитаю классику ,когда смотришь на картину(проект) и понимаешь ,что хотел сказать автор....
Ребята, я сегодня запустил на своем первом ПР110 первый проект в железе. Уф. Работает! Ваши варианты не рассматривал. Не потому, что не интересно, просто пекло другое :)
Завтра...
Лиха беда начало .Удачи в освоении .
Спасибо! Но фраза звучит так, что мне уж и спрашивать вродь не полагается... А вопросы еще есть и будут. Просто я стараюсь пощупать-поиграться для получения своих шишек - без этого какое же обучение. Потому лишь постепенно осваиваю то, что предлагают уважаемые коллеги.
Очень понравилась реализация от amn. Да, она выполнена в том подходе, который я бы назвал "нерегулярный фазовый автомат". Или, иначе говоря, более традиционный для схем на ПР. Но все же фазы выделены (даже визуально) и при моей реально простой задаче это решение, которое можно было бы считать более удачным, чем мои навороты. Но, сами понимаете, охота пуще неволи. Я хочу работать с регулярной структурой.
А советы коллеги rovki как раз звучат в унисон с моими хотелками. Я наконец-то понял, как "программировать" ПЗУ :) То есть, по сути, было ясно, что при наличии счетчика фаз установка ПЗУ на выходы (это раз!) и на отработку событий для следующего шага (это два!) придает системе фантастическую регулярность и стройность. Но я сразу тупо не въехал, "куда ж коней впрягают". Поэтому проигнорил ПЗУ как класс. Теперь буду думать. Правда, у меня вся схема такая простая, что кодировать состояние 4-х выходов (АВАРИЯ рождается из фазы 0 и таймера 5 сек) вроде уж совсем помпезно... Но. Но ради будущих проектов могу попробовать и здесь ПЗУ заюзать.
А вот сам синхрофазотрон как-то меня "не вставил". Мож тут как с ПЗУ, я просто не понял. Но "отработчик событий для перехода на следующую фазу" (так я понимаю официальную функцию СФТ) должен работать как с событиями, возникающими в текущей фазе, так и с событиями, фронт от которых уже не получишь (например, перемычка, которая "произошла" еще на этапе монтажа шкафа). Поэтому подавать "события" на входы С триггера... Не то. При этом хочу прдчеркнуть: именно реализация СФТ у меня представляет ИМХО самое слабое место. То есть, я буду копать именно в данном направлении, поизучаю проект коллеги rovki.
А чтобі вам было удобнее следить за полетом моей фантазии, ща причешу чуток проект (который работает на железке, йо-майо!) и приаттачу.
Ну, слегка причесал, добавил макрос RANGE и парочку переменных (разгружают рисунок). Ввел все же возможность перезапуска с произвольной фазы по перепаду на тумблере СТОП-РАБОТА. Ибо иногда на железе сам заводил систему в раскаряку (нереальными, в принципе, действиями, но все же может быть) - и выводить приходится передергом питания. Оно-то и не страшно, но как-то тумблером хотелось с самого начала...
Конечно, главный фокус по сравнению со старой версией - использование целочисленной переменной для передачи номера фазы из счетчика в схему (2 макроса, UPPER и UpLo) генерации импульсов перехода ("СФТ" по терминологии от rovki). Это позволило ввести 9-ю фазу и сделать красивые UPPER и UpLo.
Добрый день.
Если развернуть все макросы больно уж громоздко для такой задачи. Ощущение, что к звёздам через большие тернии. Или по принципу "Мы не ищем лёгких путей". Покажем программу заказчику, он напугается и заплатит побольше. При таком раскладе ваша попытка отдать исходники заказчику заранее обречена на то, что никто не разберётся и всегда будут звать Вас. А через несколько лет возможно они захотят перейти на другое аппаратное решение. Вот у меня полетел контроллер, где программа на зелио ложике была представленна просто напечатанной на бумажке и всё понятно, переделать можно и на ПР. А у Вас такой фокус не пройдёт. Больно уж вы замудрёвываете. Универсальные есть макросы, но создать универсальную программу нельзя. Возьмётесь решать посерьёзнее задачу и с Вашим подходом у Вас просто банально не хватит памяти. Обратите внимание на показания внизу окошка ОЛ с используемыми ресурсами. Коллеги не дадут соврать, что особенно помню при создании первых универсальных макросов вылазили такие трудности.
С уважением.
Не-не, тут Вы не правы. Я исходники не передаю, да и некому, как правило. Сопровождаю свои изделия еще 99-го года выпуска. Ну, мы уже говорили об особенностях моих клиентов.
Так что нагромождать ради объема - смысла нет никакого. Исключительно для того, чтобы я сам лучше видел логику работы и потом легче сопровождал.
Наверное, так и есть. Как мне судить с опытом одной программы за плечами? Но... Будем считать, что я ищу не наилучшее решение с точки зрения грамотного специалиста, а решение, понятное мне. Как единственному потребителю "внутренностей" программы. Все остальные потребляют только ее работу - и пока ПР справляется, им по-барабасику.
Значит не возьмусь. У меня же джокер в рукаве: я сюда пришел с ПЛК. Чуть запахнет жареным - я не принципы написания программ буду ломать, а сменю контроллер :)
Хотя... Вредность не позволяет мне не упомянуть такие цифры (раз уж речь пошла об используемых ресурсах): беру ту строчку снизу для трех вариантов:
27 19 33 08 15 мой (полностью работающая программа)
27 24 40 06 10 rovki (его программа, допиленная мною)
19 22 27 05 07 amn (программу нужно чуток подпилить)
Я бы не сказал, что мое решение очень "жрущее".