Вид для печати
Толи лыжи не едут...
Внутри макроса стоят счетчики CTN, на выходе счетчика сравнение на число и по обратной связи на сброс счетчика.
Открываем макрос, запускаем эмуляцию - счетчик работает. В проекте счетчик НЕ РАБОТАЕТ.
Как связать внешние переменные проекта с внутренними макроса, чтобы все заработало ?
Макрос в студию!
ща... надо его как-то собрать... :)
Я щас просто слепил на скоряк макрос с счётчиком внутри и попробовал эмулировать. Всё пашет.
У меня там обратные связи и плюс работа на экран, есть некоторое количество линий задержки, может из-за них часть криво пашет. Сейчас вроде запустился, немного чуть подшаманю и сделаю проектом...
Не всегда зажигается окно аварий....
Если нигде не ошибся, то как-то так.
Проблемы.
При сработке аварии вывести на экран именно ее, при снятии аварии так же отображает ее. То есть если светится журнал то что-то либо есть либо было.
И вот тут то и косяк, не могу заставить отображать действующую аварию, чтобы потом сохранить возможность между ними переключаться.
Переменная next на экране, жмем SEL, вверх, ОК. двигаемся по кругу.
Игры с WriteToFB для счетчика CTN2 приводят либо к поломкам либо к неправильному действию...
Вот как вылечить ?
Не хватает работы с кнопками, чтобы двигаться по журналу по кругу вверх или вниз, не занимаясь тыканьем по булевым переменным.....
з.ы. ну и потом хочется прикрутить макрос Сергей308 на 32 записи.
А, еще не хватает, чтобы ПР200 умел работать с UTC временем САМ для экрана. То есть подаем на экран переменную DateTime а ПР сама отображает дату и время на экране... Приходится кучу переменных использовать.
Пока что я вижу, что надпись NEXT не связана ни с одной переменной. Соответственно, танцы с SEL-OK ни к чему не приведут.
А, тогда извиняюсь... где-то накосячил. Должна быть связана с переменной R - вместо I6 должна быть переменная R
Еще, R - запись в конце цикла
Сохр. Write и Read - Да
Дело в другом, как заставить отображать последнюю аварию из ROM для чтения и одновременно с этим зайдя в журнал была возможность его пролистывания ? Вот тут у меня косяк.
CTN1 удерживает значение ячейки, в которую будет запись следующей ошибки. Не должно скакать, работает строго по кругу.
Т.е. при переходе на экран аварий всегда должна отображаться последняя авария, а потом можно пролистать список переменной NEXT. А в какой момент должна переключаться индикация пролистанных аварий на индикацию последней аварии?
В таком случае, для индикации последней аварии нам понадобится подавать на вход SELR значение (СTN1-1) с помощью какой-нибудь такой конструкции:Цитата:
Сообщение от melky
Вложение 46003
И, кста, переходы между экранами лучше не по кнопкам сделать, а по переменным, тогда сможем делать сброс на последнюю аварию после листания списка. Мы же не можем в ПР200 привязать событие к нажатию кнопки.
Такая конструкция работать не будет. SEL будет всегда будет показывать выход CTN1 если тот не 0.
пробовал с такой конструкцией, только управление SEL было иное, ничего путнего не получается.
Пришел к выводу, что надо убрать СTN2 и делать на SEL без 2-ого счетчика вообще
В идеале надо стековый вариант прикручивать а не циклический, но это уже потом, сейчас хотя бы это победить...
Естественно. Он будет показывать номер ячейки, в которую была записана последняя авария. Этот номер будет подаваться на EPROM. Или я что-то не понимаю в работе этих макросов?Цитата:
Сообщение от melky
При аварии да, должна высветиться ячейка, в которую записали, но далее я хочу пройтись по журналу. Или просто решил открыть журнал и посмотреть время сработки других аварий... По этому такой вариант и не подходит. Иначе я вообще бы обошелся одним счетчиком.
все равно это зачаточный вариант из-за отсутствия возможности управлять кнопками...
Привязывать события к кнопкам всё равно в обозримом будущем не предвидится, насколько я понял. Хошь-не хошь, придётся извращаться. Я потому и советую листать экраны не кнопками, а переменными, что тогда мы к переходу на экран аварий можем привязать, например, сброс счётчиков. В схеме с SEL я имел в виду, что такое значение будет иметь переменная Read в момент перехода на экран аварий. А потом мы сможем её менять счётчиком CTN2, как и было в схеме изначально.
не получится менять ее счетчиком, тоже пробовал. Делал WriteToFB номера ячейки в счетчик.
Еще хуже получается.
Короче, получилась такая кракозябра, и вроде даже работает. В ПР не зашивал, смотрел в эмуляторе. Когда код аварии =0, считаю, что аварии нет. Когда код меняется, происходит запись в ячейку памяти. Счётчик CTN1 показывает следующую ячейку, а в переменную Read пишется номер текущей ячейки. Происходит переход на экран аварий. ПР отображает последнюю аварию. По переменной R (она же NEXT) листаем список аварий вниз и по кругу. Ежели в это время придёт новая авария, переменная Read поменяется в макросе, и новая авария отобразится на экране. Всего лог содержит 9 аварий, по числу ячеек макроса EEPROM.
Кста, RTRIG2 в макросе можно смело убрать, он нужен только для испытаний в редакторе макроса, а так у нас R всегда импульс длиной в цикл, и в детекторе переднего фронта нужды нет.
Но, повторюсь, испытывать прогу на реальном ПР нет времени, а Лоджик -- это, увы не та программа, где все элементы И на 4 входа (хе-хе), и эмуляции экранов тут нет. Как точно ведут себя экраны, сказать не могу.
Подправил переход на экран. Так должно работать.
PPS: Чтобы всё было "по-взрослому", надобно ещё предусмотреть очистку памяти аварий и организовать подсчёт заполненности памяти, дабы не выводить на экран нули из пустых ячеек.
Доберусь до работы, гляну. Все равно спасибо.
А макрос был заброшен когда-то как раз из за отсутствия человеческого управления.
Да вот понадобился. Основная цель, передать время в UTC (надо ещё переменную разделить на два регистра) и код аварии по сети в Scada. А отображение на экране просто для местного просмотра.
Аварий 0 это тоже надо, так как время фиксируется. Ну и потом на стек перейти.
Да,, вести количество тоже надо, чтобы пустоту не показывать.
з.ы. спасибо, работает. смотрю 0 заблокировали (в принципе подумаю, а нужен ли мне он? хотя есть код ошибки, где хотелось бы видеть его отсутствие).
Вообще надо время передавать не в UTC в идеале, а в DateTime, который понимается C#. чтобы сразу без всяких скриптов показывать... Но это наверное будет сильно жестко для ПР. Потому что с этим временем надо будет работать и внутри программы тогда.
dan75 спасибо за помощь. Окультурил, протестил на ПР. Моя вполне удовлетворен :)
Главное что по сети я увижу и битовую маску ошибок и время ее возникновения.
з.ы. можно убрать проверку на ноль внутри макроса, тогда можно видеть и время снятия ошибки соответственно.
Время бы только победить, и фиг бы с ними, с 4-мя регистрами...
В проекте полноценный макрос (з.ы. макросы, не относящиеся к макросу Alarm_log не удалял из проекта, так что экспорт, импорт в новый проект перенесут только нужное). Ну и пример настроенного экрана аварий. Все остальное почистил.
Я бы не стал тратить на записи о времени квитирования наши виртуальные ячейки памяти. У нас их и так кот наплакал. Поэтому 0 на входе не приводит к перезаписи.
Стекообразный лог аварий -- это даже в чём-то проще. Лично я вижу это так: Когда при присутствии разрешающего сигнала En меняется значение входа I, оно записывается в первую ячейку и в следующем цикле буферизируется. Ежели значение на входе I поменялось (но не на 0), оно так же пишется в первую ячейку, а в остальные ячейки прописывается содержимое буферов предыдущих ячеек.
Счётчик CTN1 считает количество аварий.Кста, флаг запуска на входе En как раз и нужен для правильной работы этого счётчика. Плохо только, что не записывается авария, ежели она присутствовала на входе при включении ПР. Но это решаемо.
Счётчик CTN2 нужен для листания аварий по импульсам на входе L. Т.к. у нас стек, последняя авария всегда находится в ячейке f0.Поэтому сброс этого счётчика всегда выводит последнюю аварию. Сброс происходит при поступлении на вход новой аварии, очистке памяти или принудительно по входу R (например, по переменной перхода на экран).
Вход Clr по идее должен был полностью очищать память, потом я посчитал, что достаточно очистить первую ячейку и сбросить счётчики. Скажем так, память этот вход стирает, но не форматирует, хе.
Мой макрос RCTU -- это реверсивный инкрементный счётчик с возможностью автосброса и изменения уставки. Вот тут, правда, сказали, что не работает, хе. Один глюк нашёл, но в нашем случае он, как говорится, на скорость не влияет. Он нужен для того, чтобы при листании списка не отображать пустые ячейки.
Вывод на экран осуществляется с помощью выходов Q и n. Q -- код аварии, n -- порядковый номер. При этом листание осуществляется от записи с максимальным номером до 1.
Как-то так.
PS: Вашу финальную версию посмотрел, но на ПР не тестил.
гляну как объект доделаем, сейчас уже времени нет. стек я делал на 8 ячеек кажется, не помню. Ну либо как вариант, что писал выше, использовать стек от Сергей308 на 32 ячейки.
для существующего варианта можно добавить второй экран и раскидывать побитно все аварии. Но основная его цель, это компактность и передача по сети, а так как в Scada можно любые биты вытащить, абсолютно все равно что CD32 показывает на экране только старшую ошибку. ну и в Scada легко можно проверять 1970 год и ничего не делать, ну либо код 0 - нет ошибки, тоже ничего не делать.
очищать вообще нет смысла, иначе это не журнал аварий...он как раз и должен сохраняться всегда.
Ежели так рассуждать, какой смысл при наличии скады вообще вести лог в ПР? В скаде и памяти хоть попой кушай, и возможности несравнимы с ПРовскми. Читай ошибки с ПР и формируй журнал как нравится. Другое дело -- автономный режим. По описанному мной алгоритму работают многие автономные устройства. И, кста, на автономных контроллерах возможность очистки журнала как раз-таки есть.
Делать полноценный журнал ошибок на ПР это издевательство над его памятью. По этому и искал компактное решение. Ну и чтобы решение не зависело от периода опроса. Оно иногда специально может быть с большим периодом. Например опрос каждые 15 минут на удаленном объекте. А там, мы знаем точное время возникновения ошибки.. В общем как раз из всех этих соображений и делалось.
Другой момент, Scada читает постоянно, но в базу пишется раз в минуту. а событие в ПР моет появиться между записью в БД...
в общем попытка найти не сильно затратное по ресурсам решение, но которое можно применять в различных ситуациях.
Ну а почему тогда очистка не нужна? Прочитали скадой, какие ошибки накопились с момента предыдущего опроса, да и обнулили список в ПР. Тоже ведь вариант.
А смысл? Ячейки памяти от этого не освободятся, только станут нулями. Да и полезно для обслуживающего персонала по месту, без всяких Scada. Или или так сказать. Если грамотно все организовать при работе с экраном.
А пожалуй, что и так. При условии, что у нас запоминается время аварии. Есть ведь устройства, которые записывают просто сам факт аварии. Тогда, понятное дело, обнуляю список сразу после того, как прочитал, чтобы потом не путаться.
Ну и, кста, есть у меня пара дешёвых-сердитых схем диспетчеризации, где ПР выступает в роли удалённого прибора, читая МВ110 на 16 входов и пару ТРМов. И никаких скад и даже панелей. Вот туда-то я при случае лог, наверно, и запихну.
Кстати чуть допилить макрос, чтобы при изменении переменной с экрана (переключение между ошибками), сетевые переменные времени и кода ошибки были заблокированы. Тогда я чуть допилю еще и сделаю второй экран.
Добавлен второй экран. Переходы с Главного экрана ОК - в Журнал Аварий, ESC - возврат к главному экрану
В Журнале Аварий ОК - переход на Экран расшифровки, ESC - Возврат к Журналу Аварий, SEL и далее Стрелка Вверх - смена номера списка Журнала по кругу в сторону уменьшения то есть у нас 4, круг 4, 3, 2, 1, 0, 8, 7 и так далее (не хватает управления кнопками чтобы и туда и сюда можно было крутить)
На стек бы переделать и с большим количеством записей, но чтобы память не увеличилась от того что есть... Некогда пока ковырять...
По идее при отсутствии новой Аварии и листании на экране ПР в сеть передается последняя Дата + Код аварии. Дата в формате UTC
Добавил версию 6, использовал макрос EEPROM32 от Сергей0308 правда покрошил его до 16 бит. Так как количество аварий ограничено 16-тью. Для сохранения времени просто используется два макроса и один для ошибок. Пробовал так же использовать макрос стека, но при его использовании мигает экран и еще какой-то был косяк.
На простом EEPROM поведение лучше. За счет этих урезаний снизил потребляемые ресурсы. Да. В версии 5, забыл в параметрах макроса Лога включить параметр Сохр.Write = Да. Чтобы ПР мог сохранять ошибки после выключения, не стирая уже созданные.
Здравствуйте,как з.ы. можно убрать проверку на ноль внутри макроса, тогда можно видеть и время снятия ошибки соответственно.Цитата:
Сообщение от melky
Виталик ВВ по идее просто убирается в макросе 2 элемента и проверки на 0 не будет. Проверить пока не на чем.
файл с x0 в имени не должен проверять на 0 и снятие аварии должно так же записываться в журнал.
Цитата:
Сообщение от melky
какаие 2 элемента убрать вы имеете ввиду?Вложение 50639
Виталик ВВ я их убрал внутри макроса AlarmLog. Файл, где есть x0 - убраны, в первоначальном как есть.