Затем добавляем счетчик ,пзу , экстрактор и получаем "синхрофазатрон"потом все засовываем в один макрос
Затем добавляем счетчик ,пзу , экстрактор и получаем "синхрофазатрон"
Последний раз редактировалось rovki; 04.08.2014 в 21:37.
электронщик до мозга костей и не только
я пока не понял, как это использовать. Но подумаю.
Во всяком случае, я хотел бы решить все вопросы организации "степпера" неким единым и стройным образом. Чтобы получился шаблон, в который начиняешь всего 2 множества: условия переходов по фазам и (полезные) действия в самих фазах. Последнее вполне можно закатать в ПЗУ, хотя меня смущает такой момент: как быть с выходами, которые не изменяются в данной фазе?
В общем, еще много нужно допилить.
О, еще есть инфо! Бум смотреть, спасибо!
на входа макроса заводится как информация со входов ,так из любой точки схемы ,в том числе с выхода макроса-(условия переходов) .Главное -нужно заводить события ,так как они располагаются во времени .С выходами будет ,то что вы запишите в ПЗу(макрос)
Исправьте в макросе свойство в макросе ПЗУ ,на использование в макросе -ДА ..
Ну вот например ваш дозатор ,цикл начинается с закрытия крышки ,потом пуск ,потом уровень1,потом уровень2 ,потом уровень ноль ,потом еще уровень0
в предышущем посте макрос SF был с ошибкой ,исправил (старая версия) и тут исправил старую версию
Последний раз редактировалось rovki; 04.08.2014 в 22:40.
Вот пример как на базе этого макроса сделать бегущую единицу .в пзу пишем значения "картинки" 1,2,4,8,16,32,64,128 ...Входа все в кучу и все .Ясно что можно проще ,но это пример как пользоваться макросом .
В данном макросе(способе) есть 7 шагов (интервалов) во времени(произвольной длины) .Шаг -любое последовательное во времени событие (переход из "0 в "1") ,в соответствии которого ставится любая комбинация на выходе макроса ,путем записи констант во внутреннее ПЗУ макроса .Он рассчитан для работы в циклических алгоритмах .
Следующим будет макрос ,позволяющий увеличивать количество событий (шагов) .
Последний раз редактировалось rovki; 05.08.2014 в 06:59.
Я как раз проснулся с тоскливым обдумыванием ограниченности количества входов-выходов в макросах этой вашей хваленой ОВСообщение от rovki
И решил, что есть такие пути:
1) максимально прятать внутрь те части схемы, в которых "позиционный код". Возможно, проводить границу разделения макросов по целочисленным аргументам. Ну, например, текущую фазу из макроса, где она создается и модифицируется, выносить для других макросов в виде числа. А в тех макросах, где она юзается, разворачивать число в позиционный код. Например, ставить блоки EQ и получать все интересующие нас значения в виде булевых переменных (равно или не равно, скажем, 5)
2) наращивать макросы в макросах (это то, что Вы собираетесь делать?)
Мне еще надо время понять полеты Вашей мысли, я так быстро не умею. Но наперед закину вот что: наш сиквенсер (степпер, фазовый управитель, как его назвать?) должен иметь такие параметры:
1) Реагирование не только на события, но и на постоянно существующие условия. Это значит, вот что. Допустим, в фазе 5 анализируется некое "событие". Так вот, нужно реагировать на это "событие" не только в случае, когда оно происходит (условие начинает выполняться) непосредственно в фазе 5. Нужно также реагировать на это событие, если оно произошло еще до наступления фазы 5.
Пример: вместо сигнала "Разрешение разгрузки" я ставлю перемычку. И хочу, чтобы в нужной фазе ПР увидел эту перемычку и пошел дальше "мгновенно", пусть там и прощелкает несколько циклов работы контроллера. Если же перемычки не будет, то ПР постоит в фазе ожидания разрешения разгрузки и по получению "события" пойдет дальше.
Я для реализации такого поведения наставил кучу таймеров по 0,2 с - это ужасное решение
2) "Произвольный условный переход"
В любой фазе мы можем принять решение о переходе не к следующей фазе, а к какой-то иной. Теоретически, можно требовать, чтобы из любой фазы при некоторых условиях можно было улетать на любую другую. Но практически это громоздко и трудно. Поэтому я бы рассмотрел чуть менее универсальное умение: в каждой фазе есть одно условие "нормального" выхода (к следующей фазе) и одно условие выхода к произвольной фазе. Скажем, у нас есть сигнал "Днище закрыто". Его исчезновение в некоторых фазах должно вызывать отработку аварийной ситуации. Сейчас я тупо сбрасываю счетчик фаз. И в состоянии INIT должен побеспокоиться о сбросе всего что нужно и переходе или не переходе в фазу BottomWait. А можно было бы зарезервировать некую фазу 8, предназначенную для отработки аварии "Днище упало во время подачи или ожидания фиксации результата дозирования". И именно туда направлять степпер (теперь уже джампер?) в случае такой аварии. Тогда в системе есть место и для других аварий - заведу фазу 9 для аварии "Слишком долго идет насыпка", фазу 10 для аварии "Не могу дождаться разргрузки" и т.д....
Одним словом, добавить условный переход, как в обычных программах, есличьо...
3) Конечно же, хотелось бы иметь масштабируемый степпер, чтобы фаз могло быть больше, чем 8. Мне просто повезло с моим первым проектом, но расширяться уже некуда. А может понадобиться.
Я не слишком размечтался?
хотел узнать, дошло ли до сознания, что в отличии от плк в ПРке выполняется весь код, который разместили в проектеЯ не слишком размечтался?
Да, я понимаю, что в каждом цикле работы ПР (равно как и в случае ПЛК) производится отработка всех возможных блоков. Но степпер для того и создан, чтобы "разнести" по разным фазам анализ и отработку определенных комбинаций входов и внутренних переменных. Поэтому меня, как разработчика, не волнует "выполнение" тех частей, тех блоков, которые в данной фазе не важны. Я их все равно блокирую, на работу схемы (программы) в данной фазе они не влияют.
Вот это разделение схемы на несколько частей, важдая из которых "играет" в положенной фазе - главное отличие предлагаемого (здесь мною, но вообще это совсем не мое изобретение) подхода.
Я не про то, что Вы грамотно или нет производите селекцию, а про то что от "раздувания" кода, время исполнения, трата ресурсов и т.п. будет увеличиваться
Если мне не хватит производительности ПР, я буду работать с другой моделью. Но код должен быть понятным, отлаживаемым, пригодным для модифицирования в дальнейшем. Иначе лично я (за других не могу расписываться) работать с программой (схемой) не могу.
Ваши права
Ответить с цитированием