Просмотр полной версии : Архив аварий на ПР200
stanislau
25.11.2018, 14:40
Интересует кто как реализовывал архив аварий и его отображение на экране ПР200. Стандартный макрос EventLog из менеджера компонентов не удобен тем, что для просмотра сохраненной аварии необходимо вводить номер записи для ее просмотра.Да и на используемые в этом макросе Im_Log_Mem и Im_Log_Man я описания на форуме не нашел. Хотелось бы чтобы сигналы аварий отображались в виде списка: на один экран одна авария. Для этого лучше чтобы аварии выводились из макроса переменными (пускай их будет много),а не выдавались только по запросу на отображение. Я тут из стандартного EventLog сделал то, что хотелось, но объем используемой энергонезависимой памяти удручает.
Сергей0308
25.11.2018, 18:13
Интересует кто как реализовывал архив аварий и его отображение на экране ПР200. Стандартный макрос EventLog из менеджера компонентов не удобен тем, что для просмотра сохраненной аварии необходимо вводить номер записи для ее просмотра.Да и на используемые в этом макросе Im_Log_Mem и Im_Log_Man я описания на форуме не нашел. Хотелось бы чтобы сигналы аварий отображались в виде списка: на один экран одна авария. Для этого лучше чтобы аварии выводились из макроса переменными (пускай их будет много),а не выдавались только по запросу на отображение. Я тут из стандартного EventLog сделал то, что хотелось, но объем используемой энергонезависимой памяти удручает.
На мой взгляд, Вы сами забиваете память абсолютно ненужной(бесполезной) информацией, например 2000 годами, я бы вообще года убрал, ну если Вы не каждый год аварии смотрите, хотя бы "лишними" 2000 не забивал память, ну а если забили по незнанию или глупости, кто же Вам виноват, вот посмотрите, когда-то делал контроль состояния входа, не помню в какой теме подробно описывал, если заинтересует, сами найдёте:
stanislau
25.11.2018, 21:15
Года память не забивают. Память жрут макросы EventLog. Проект в первом посте - это то как хотелось бы чтобы работал журнал аварий. Без лишних нажатий и лазаний по меню. Аварии переменными выводятся на экран. Если бы можно было считывать нажатие кнопок ПР200 - поставил бы счетчик импульсов на нажатие вверх/вниз и показания этого счетчика завел на vi_Display и не мучал себе голову. Весь вопрос в том можно ли переделать EventLog чтобы он выводил сохраненные события не по запросу, а постоянно в виде переменных? Если нет - то искать другие способы.
Сергей0308
26.11.2018, 01:37
Года память не забивают. Память жрут макросы EventLog. Проект в первом посте - это то как хотелось бы чтобы работал журнал аварий. Без лишних нажатий и лазаний по меню. Аварии переменными выводятся на экран. Если бы можно было считывать нажатие кнопок ПР200 - поставил бы счетчик импульсов на нажатие вверх/вниз и показания этого счетчика завел на vi_Display и не мучал себе голову. Весь вопрос в том можно ли переделать EventLog чтобы он выводил сохраненные события не по запросу, а постоянно в виде переменных? Если нет - то искать другие способы.
У Вас время и дата аварии запоминается? Если, да, то смотрите мой преведущий пост!
Начинал делать список аварий с фиксацией даты, но потом забил. Было не до этого и сейчас пока тоже.
Были применены макросы от petera с работой времени по UTC и макросы ПЗУ от rovki если не ошибаюсь. Могу поискать заготовки, но там еще допиливать и допиливать...
На счет памяти не помню сколько сожрется. По факту мне нужно время сохранять в формате double - DateTime.ToAODate() из C# так как Scada прекрасно понимает этот формат времени.
Не, ну можно и с UTC но меня напрягает этот формат времени, так как он умрет в 2038 году навечно, ну либо они сменят начальную дату и будут дальше считать, но все старое точно умрет...
Я думаю, что такой функционал надо заказать Овеновцам, но сколько это будет делаться (если будет вообще).
Ревака Юрий
27.11.2018, 10:32
Года память не забивают. Память жрут макросы EventLog. Проект в первом посте - это то как хотелось бы чтобы работал журнал аварий. Без лишних нажатий и лазаний по меню. Аварии переменными выводятся на экран. Если бы можно было считывать нажатие кнопок ПР200 - поставил бы счетчик импульсов на нажатие вверх/вниз и показания этого счетчика завел на vi_Display и не мучал себе голову. Весь вопрос в том можно ли переделать EventLog чтобы он выводил сохраненные события не по запросу, а постоянно в виде переменных? Если нет - то искать другие способы.
Может Вам проще поставить рядом МСД-200? И что значит выводил сохраненные события постоянно в виде переменных? Сам макрос открыт, можно переделать под свои задачи.
stanislau
27.11.2018, 20:33
Я имел ввиду вывод записи не по запросу на vi_Display, а сделать например 10 выходов alarm1 - alarm10. На эти выходы постоянно выводить сохраненные записи. Макрос открытый, но назначение не всех выводов Im_Log_Mem и Im_Log_Man нонятно.
Ревака Юрий
28.11.2018, 10:51
Я имел ввиду вывод записи не по запросу на vi_Display, а сделать например 10 выходов alarm1 - alarm10. На эти выходы постоянно выводить сохраненные записи. Макрос открытый, но назначение не всех выводов Im_Log_Mem и Im_Log_Man нонятно.
Понятно, думаю это можно реализовать. Но если задача писать в 10 ячеек на экране, так пишите в них по счетчику, тут и макрос не нужен.
stanislau
28.11.2018, 21:40
так пишите в них по счетчику
Юрий, не понял как это?
Ревака Юрий
29.11.2018, 10:41
Юрий, не понял как это?
Я пока тоже всю задачу не понимаю, но из того что написано, получается что сам лог и не нужен. Макрос который вы хотите адаптировать дает возможность посмотреть определенное событие выбрав его, вы хотите все события видеть на экране сразу. Тогда делайте необходимые переменные построчно на экран и записывайте туда числа, биты и т.д. Каждая строка соответствует определенному событию, я это вижу так, простые аварийные меню так и делал всегда, но я никогда не пытался втиснуть туда все в одну строку, имею ввиду и дату до секунд и название аварии, так как на 16 знаках это не читаемо. Но насколько я помню выкладывали и такие решения.
stanislau
29.11.2018, 12:06
Тогда делайте необходимые переменные построчно на экран и записывайте туда числа, биты и т.д. Каждая строка соответствует определенному событию
Так я же и хочу так сделать. Только событию выделить весь дисплей, сделать их штук 10, задать между ними переходы и помощью кнопок вверх/вниз перемещаться между ними.
Вроде появилась одна идея. Вечером попробую.
Ревака Юрий
29.11.2018, 12:18
Так я же и хочу так сделать. Только событию выделить весь дисплей, сделать их штук 10, задать между ними переходы и помощью кнопок вверх/вниз перемещаться между ними.
Вроде появилась одна идея. Вечером попробую.
Весь дисплей не очень понятно, можно упростить, одно событие-1 строка, листаем вверх/вниз по строкам, даже переходы не нужно настраивать. А уже в строке любые типы переменных и кол-во.
Так я же и хочу так сделать. Только событию выделить весь дисплей, сделать их штук 10, задать между ними переходы и помощью кнопок вверх/вниз перемещаться между ними.
Вроде появилась одна идея. Вечером попробую.
http://www.owen.ru/forum/attachment.php?attachmentid=40113&d=1543514669
Тут журнал на три события - как пример, расширяйте вниз на сколько влезет в память.
Доделать:
- формирование тактового сигнала
- формирование кода события
По фронту CLK происходит запись кода события, даты и времени в первую строку журнала, предыдущие строки журнала сдвигаются вниз, самая старая строка пропадает.
На каждую запись(событие) отводится один экран
40103
между экранами ходим стрелками
40104
Дата события упакована в одну переменную таким образом, чтобы было просто выводить на экран - с доп. нулями между разрядами
Т.е. 29011018 - означает 29-11-18.
На экранах символы "-" наложены поверх переменной дата в позициях этих доп. нулей
Аналогично упаковано и время.
Макрос
40105
События хранит этот макрос
40106
Дата, время и Event - энергонезависимые
40169
ЗЫ.
Готовый журнал через два поста ниже http://www.owen.ru/forum/showthread.php?t=29865&p=294061&viewfull=1#post294061
Василий Кашуба
29.11.2018, 18:33
Заготовка такого журнала
40102
для просмотра гифки нажми на картинку
Тут журнал на три события - как пример, расширяйте вниз на сколько влезет в память.
Доделать формирование тактового сигнала и формирование кода события
По фронту CLK происходит запись кода события, даты и времени в первую строку журнала, предыдущие строки журнала сдвигаются вниз, самая старая строка пропадает.
На каждую запись(событие) отводится один экран
40103
между экранами ходим стрелками
40104
Дата и время события упакованы таким в одну переменную образом, чтобы было просто выводить на экран - с доп. нулем между разрядами
Т.е. 29011018 - означает 29-11-18.
На экранах символы "-" наложены поверх переменной дата в позициях этих доп. нулей
Аналогично упаковано и время.
Макрос
40105
События хранит этот макрос
40106
Дата, время и Event - энергонезависимые
Спасибо, отличное решение задачи.
stanislau
29.11.2018, 22:56
Petera, Вялiкi дзякуй! Вот то, что у меня получилось со стандартным журналом.
Petera, Вялiкi дзякуй! Вот то, что у меня получилось со стандартным журналом.Вот то, что у меня получилось. Это полностью оформленный вариант.http://www.owen.ru/forum/attachment.php?attachmentid=40119&d=154354969740124
использовать "стандартный" журнал для Ваших хотелок слишком расточительно. Кроме журнала ведь еще что-то будет в программе.Сравните хотя бы сколько ресурсов использовано в проектах
Ваш вариант
40120
Мой вариант
40121
Размер проектов
40122
Пока в Вашем журнале есть только коды событий, временных отметок событий не наблюдаю. Придется добавлять еще для каждой строки SEL для временной отметки и макросы UNIX_to_DT и получите еще шесть переменных для каждой строки журнала.
Я сразу отказался от использования макросов UNIX-time, т.к. временные отметки нужны только для вывода на экран, меня не интересует точное количество секунд от 1 января 1970г.
В моем журнале временные отметки события сразу пригодны для вывода на экран и для одного события нужно только две переменные, а не шесть.
Всю цепочку макросов Event и макрос ДатаВремя можно оформить одним макросом.
ЗЫ.Обращаю вниманиепеременные внутри макроса Event должны быть энергонезависимыми!
40170
Aviator_VZh
30.11.2018, 09:12
petera, отличное решение, спасибо, забираю.
И пользуясь случаем напомню о своей просьбе сделать возможность перемещения по экрану не по одной строчке, а по две. В данном случае можно было обойтись одним экраном.
Newcomer
30.11.2018, 09:18
petera, в какой версии OL сделан ваш проект ?
petera, в какой версии OL сделан ваш проект ?
===== 1.12.173 ====
stanislau
30.11.2018, 12:28
Да это черновик только. По ресурсам - в стандартном журнале 24 события, оставлю 6, посмотрю на потребление ресурсов. Мне просто надо было понять как в OL реализовать "динамическую индикацию". С временем теперь поразбираюсь. С юникс тайм неудобно. Ваше решение лаконично - не надо преобразовывать несколько раз. И вообще: "Я ведь ещё только учусь!"© :)
stanislau
01.12.2018, 21:37
Что будет, если в макросе petera одновременно сработает больше двух аварийных сигналов одновременно? Как расшифровать полученный код? Или надо делать задержки чтобы данной ситуации не возникало?
Что будет, если в макросе petera одновременно сработает больше двух аварийных сигналов одновременно? Как расшифровать полученный код? Или надо делать задержки чтобы данной ситуации не возникало?
код будет 17(10001), 33(100001) или 25(11001)
Могу предложить макрос который "разбирает" такой код на части
ЗЫ
40145
Вот этот макрос
40144
Макрос просматривает все биты кода по очереди
- если бит лог.0, то на выходе число 0
- если бит лог.1, то на выходе число соответствующее номеру бита
- задержка на 2с
- опрос следующего бита.
Выход макроса подключить к динамическому тексту
В дин.тексте список
0 - пусто
1 - Сработал вход 1
2 - Сработал вход 2
3 - Сработал вход 3
4 - Сработал вход 4
5 - Сработал вход 5
6 - Сработал вход 6
40146
Таким образом на экране в дин.тексте будут отображаться по очереди ВСЕ сработавшие биты кода или пустая строка если ни один бит не сработал
ЗЫ.
Переменные в макросе Event должны быть энергонезависимыми.
40171
stanislau вообще аварии пакуют в одну переменную, а распаковать и русскими буквами написать уже дело Scada системы
ИМХО, не вижу смысла на экране ПР расшифровывать несколько одновременных аварий, там достаточно кода и времени.
Не насилуйте ПР лишним кодом :) достаточно ошибки раскидать на биты. Например для одних ошибок дать 0,1,2 биты, для других ошибок 4,5,6 и так далее. 3 бита дают 7 ошибок любого типа. и вот на экран выводить несколько цифер от 1 до 7 + банальная табличка на дверце щита легко позволит идентифицировать ошибку персоналу с экрана.
Aviator_VZh
01.12.2018, 23:52
А еще можно в верхней строчке дать номера аварий 0 - F, а в нижней индикацию наличия.
Что будет, если в макросе petera одновременно сработает больше двух аварийных сигналов одновременно? Как расшифровать полученный код? Или надо делать задержки чтобы данной ситуации не возникало?
Как вариант-
Если вместо макроса PACK8
40151
Применить, такой макрос, где используются не двоичные разряды числа, а десятичные
40152
то событие в журнале и на экране будет представлять комбинацию 0 и 1,
где 1 будут в позициях включенного входа
40153
40154
В этом случае табличка на двери будет содержать всего 6 строк(или числу входных сигналов)
1 - Сработал вход 1
10 - Сработал вход 2
100 - Сработал вход 3
1000 - Сработал вход 4
10000 - Сработал вход 5
100000 - Сработал вход 6
если на экране будет 101001, то без математических вычислений сразу видно - сработали входы 6, 4 и 1.
Вот, это более конструктивная упаковка, так как в ПР не надо распаковывать биты, для отображения на экране. В общем меньше ненужного программного кода.
Сергей0308
02.12.2018, 13:01
Вот, это более конструктивная упаковка, так как в ПР не надо распаковывать биты, для отображения на экране. В общем меньше ненужного программного кода.
Ресурсы ПР ограничены, я например время и дату могу упаковать в одну переменную(если Вам так захочется спросите - отвечу как) и это сократит количество занимаемой ими памяти в 2 раза, что немало, а когда её не хватает и другого выхода не существует! Конечно это усложнит программу, но станет возможным сделать задуманное или существенно расширить!
stanislau
02.12.2018, 14:52
Вот, что пока у меня получилось. Архив на 15 аварий. Выводить на дисплей, как я понимаю, можно через combobox. Тогда в одном combobox можно создать 6 строк, что равно 6 авариям. Значит, в зависимости от поступившего значения в переменную, будет отображаться необходимое сообщение.
Посмотрел предложения выше. Надо завтра все на ПР проверить, если время будет.
stanislau
30.01.2020, 15:10
Подскажите, есть ли у кого-нибудь пароль от внутренних макросов журнала на 24 события Event_Log. Сейчас понадобился небольшой архив на аварий 8-10. Как в посте выше. Этот вариант устраивает всем, кроме своей громоздкости. Посмотреть бы, что у него внутри. Мне, например, время сброса аварии не надо, время в формате Unix тоже. Соответствующие блоки удалил бы. Может макрос более "легкий" стал. Сейчас он урезанный до 10 аварий увеличивает время цикла до 5мс (если смотреть в меню ПР). Вариант который предложил Petera мне в данном случае не подходит потому, что входных сигналов будет 24. Не удобно в динамическом тексте высматривать какое оборудование в аварии. Если только не придумать как отображать аварии не в динамическом тексте, а каждую аварию на отдельном экране. Я не могу сообразить как это сделать. Поэтому нужен пароль от Event_Log. Может кто лучше что-нибудь предложит.
Сергей0308
30.01.2020, 18:35
Подскажите, есть ли у кого-нибудь пароль от внутренних макросов журнала на 24 события Event_Log. Сейчас понадобился небольшой архив на аварий 8-10. Как в посте выше. Этот вариант устраивает всем, кроме своей громоздкости. Посмотреть бы, что у него внутри. Мне, например, время сброса аварии не надо, время в формате Unix тоже. Соответствующие блоки удалил бы. Может макрос более "легкий" стал. Сейчас он урезанный до 10 аварий увеличивает время цикла до 5мс (если смотреть в меню ПР). Вариант который предложил Petera мне в данном случае не подходит потому, что входных сигналов будет 24. Не удобно в динамическом тексте высматривать какое оборудование в аварии. Если только не придумать как отображать аварии не в динамическом тексте, а каждую аварию на отдельном экране. Я не могу сообразить как это сделать. Поэтому нужен пароль от Event_Log. Может кто лучше что-нибудь предложит.
Вот здесь посмотрите, мне кажется "костюмчик" как по вам шитый:
46960
https://owen.ru/forum/showthread.php?t=31113&page=7
stanislau
31.01.2020, 00:12
Спасибо. Посмотрю завтра. Но все таки, как в Event_Log они решили проблему одновременного срабатывания входов?
Stanislau тут Сергей 0308 делал макрос кто первый встал того и тапки. В макросе 8входов и выходов. При появлении 1 на входе на этом же выходе весит 1. Если появится 1еще на каком то входе то на Выходе будет 0 пока не пропадет самая первая еденичка. Макрос есть на компе. Могу скинуть сюда вечером. Или спроси у Сергея.
stanislau
31.01.2020, 11:22
Поищу тут на форуме, где-то в какой-то теме было.
Сергей0308
31.01.2020, 11:47
Спасибо. Посмотрю завтра. Но все таки, как в Event_Log они решили проблему одновременного срабатывания входов?
А чем Вас не устраивает вариант, что я чуть выше выложил: там для этого случая(если одновременно сработало 2 и более аварии) предусмотрен макрос RAMP_BIT, если на его входе одновременно изменятся сразу даже все 32 бита(каждый бит соответствует определённой аварии), то на его выходе будет менятся по одному биту каждый цикл, начиная с самого старшего и далее по мере уменьшения старшинства(весового коэффициента), процесс изменения займёт количество циклов соответствующее количеству изменённых бит, короче, этим разруливается построчное построение аварий в порядке поступления, надеюсь, понятно объяснил?!
stanislau
31.01.2020, 12:56
Сегодня посмотрю. Но вроде получилось самому придумать. Вечером выложу, что получилось.
https://owen.ru/forum/showthread.php?t=32279&p=320436&viewfull=1#post320436
Вот общими усилиями был сделан архив аварий с меткой времени. Время можно убить... макрос ПЗУ можно взять на большее количество ячеек.
Правда аварии пишутся в биты все, но если происходит изменение числа (например сперва бит 3 - произойдет фиксация, потом бит 5, так же произойдет фиксация 3 и 5 битов, так как 3 уже срабатывал)
stanislau
02.02.2020, 00:44
Вот, что у меня получилось.
Сергей0308
02.02.2020, 01:22
Вот, что у меня получилось.
У Вас очень неэффективно используется энергонезависимая память, например код аварии, до 32 аварий достаточно 5 бит из 32 у вас, то есть используется около 15% памяти, остальные около 85% присутствуют, но стоят мёртвым грузом!
Я ранее в какой то из тем, даже не одной, подробно расписывал что можно поместить в 32 битах переменной, короче использовать во много раз эффективней, так как энергонезависимой памяти у ПР не так и много, но если Вам хватает, то нет и проблем, когда не хватит, тогда есть смысл над этим задуматься, например по моим прикидкам, я бы смог сделать архив на 160 аварий(код аварии и дата время в одной переменной), у Вас пока 8, для начала тоже не плохо, я так думаю!
Мне вот интересно, вы когда пишите макросы, вам самим нравится, что вы забабахали макрос на 32 бита, а используете всего 8-12 из них ?
Почему не сделать тот же макрос всего на 8 бит с возможности изменения положения бит и не стыковать их вместе при необходимости ?
Есть один прикол, который разработчики объяснить не могут. По какой-то причине прикопировании и переименовании макроса, даже с изменением его имени и состава при его вставке в проект кричит что такой макрос уже есть. В итоге проще сделать 32 битный вариант и всюду его вставлять
bayk потому что макросы определяются по их ID а не ИМЕНИ. Создайте Новый макрос, сменится ID, скопируйте туда нужное, задав новое имя и так далее.
Вроде этот момент давно разработчики объяснили...
Я вообще к чему. Когда мы лепим 32-х битные макросы, но используем от них только половину или меньше, и когда в проекте таких вариантов много, мы просто засираем память ПР холостыми операциями и количеством FBD... просто не оптимальное решение...
stanislau
02.02.2020, 15:30
Ну, Сергей в чем-то прав. Дату и время можно склеить в одну энергонезависимую переменную. Так памяти меньше израсходуется, наверно. Надо проверить. А как в скаду лучше передавать: одной большой переменной ( в скаде ее расшифровывать) или каждой параметр своей переменной?
Сергей0308
02.02.2020, 15:48
Ну, Сергей в чем-то прав. Дату и время можно склеить в одну энергонезависимую переменную. Так памяти меньше израсходуется, наверно. Надо проверить. А как в скаду лучше передавать: одной большой переменной ( в скаде ее расшифровывать) или каждой параметр своей переменной?
Так, если Вы в скаду передаёте, тогда архив в ПР и не нужен, максимум буфер из не энергонезависимой памяти, мне так кажется!
stanislau
02.02.2020, 15:49
Не, я сейчас не планирую передавать. Это вообще, чтобы знать как лучше и правильней.
stanislau
02.02.2020, 21:54
В общем, если склеивать дату и время в одну переменную, то без компромиссов не обойтись. Для нормальной читаемости на экране ПР все таки между гг мм дд чч мм сс должны быть пробелы, хоть между чем-нибудь. С пробелами в инт все не влазит. Придется урезать дату/время до дд мм чч сс. А так, да, меньше байт расходуется. Если все-таки будет скада только для чтения архива из ПР, то,все-таки, как лучше паковать данные? Хотелось бы и на ПР сохранить информативность, и со скадой уменьшить сетевой обмен (наверно чем меньше ПР будет по сети "нагружена", тем лучше?).
Сергей0308
02.02.2020, 22:48
В общем, если склеивать дату и время в одну переменную, то без компромиссов не обойтись. Для нормальной читаемости на экране ПР все таки между гг мм дд чч мм сс должны быть пробелы, хоть между чем-нибудь. С пробелами в инт все не влазит. Придется урезать дату/время до дд мм чч сс. А так, да, меньше байт расходуется. Если все-таки будет скада только для чтения архива из ПР, то,все-таки, как лучше паковать данные? Хотелось бы и на ПР сохранить информативность, и со скадой уменьшить сетевой обмен (наверно чем меньше ПР будет по сети "нагружена", тем лучше?).
Вот прикинем: код аварии(до 64 аварий) - 6 бит, секунды(0-59) - 6 бит, минуты(0-59) - 6 бит, часы(0-23) - 5 бит, число(1-31) - 5 бит, месяц(1-12) - 4 бит, итого 32 бита, если хотя бы раз в год просматривать, то год и не потребуется писать. Если не каждый год просматривать, то можно вместо секунд - год писать, хватит на 64 года, короче, как-то примерно так я это вижу и хотел повторить, что у меня(ранее делал подобные проекты с использованием энергонезависимой памяти) энергонезависимой памяти хватало более чем на 160 аварий(переменных), надеюсь, понятно написал!
вам так жалко 3-х регистров на дату и Аварии ? ну вы бдин даете.... а ничего, что вам потом придется выделываться и со стороны Scada системы, преобразуя все обратно ?????? это и есть мне кажется извращение, создать себе дополнительных трудностей, чтобы потом их преодолевать....
и простите, как вы в 6 бит запихнете 16 аварий одновременно? ну если правильнее сказать несколько из 16 аварий в любой из комбинаций ?
Сергей0308
02.02.2020, 23:35
вам так жалко 3-х регистров на дату и Аварии ? ну вы бдин даете.... а ничего, что вам потом придется выделываться и со стороны Scada системы, преобразуя все обратно ?????? это и есть мне кажется извращение, создать себе дополнительных трудностей, чтобы потом их преодолевать....
и простите, как вы в 6 бит запихнете 16 аварий одновременно? ну если правильнее сказать несколько из 16 аварий в любой из комбинаций ?
Я же только пару часов назад написал, что считаю если в скаду передаётся, то в ПР архив и не нужен от слова совсем максимум буфер из не энергонезависимой памяти!
И если бы Вы удосужились посмотреть мой проект аварий хоть одним глазком, я кстати и писал об этом, там это всё разруливается макросом RAMP_BIT, короче, при возникновении на входе одновременно даже всех 32 аварий, на выходе будет менятся по одной каждый цикл программы, начиная со самого старшего бита и далее по мере уменьшения старшинства(весового коэффициента), процесс изменения займет столько циклов программы сколько бит изменилось, лучше посмотрите для наглядности, можно в симуляторе спокойно посмотреть, проект там присутствует, по ссылке: https://owen.ru/forum/showthread.php?t=31113&page=7
47020
Сергей0308 RAMP_BIT некрасивое решение, если есть передача в Scada. Цикл ПР куда быстрее, чем опрос и тем более запись в БД Scada системы.
Он больше подходит для работы на экране без всяких Scada. Я же делал универсальное решение, ни вашим ни нашим... Хочешь используй Scada, хочешь не используй. Даже если опрос настроить раз в несколько минут, в регистрах будет зафиксирован последний код Аварии и ее время.
Разложить на биты в Scada не составляет труда, а вот все засунуть в один или два регистра и потом вытаскивать в Scada еще и время это лишний мартышкин труд.
Проще передать двумя регистрами время UTC и третьим регистром код Аварии. А вот для экрана надо будет добавить разложение по битам в самом ПР, если прямо нужна будет такая необходимость. При чем во время работы экрана в сеть так же передается только последняя Авария, чтобы в Scada не попадали данные предыдущих, если оператор смотрит ошибки непосредственно на экране.
Я исходил из того, что вероятность возникновения ДВУХ аварий в ОДНОМ цикле ПР крайне мала, и даже если она есть, Scada это увидит на следующем опросе. Ну а на экране будет код числа из двух битов, что не так уж и страшно....
Сергей0308
03.02.2020, 19:03
Сергей0308 RAMP_BIT некрасивое решение, если есть передача в Scada. Цикл ПР куда быстрее, чем опрос и тем более запись в БД Scada системы.
Он больше подходит для работы на экране без всяких Scada. Я же делал универсальное решение, ни вашим ни нашим... Хочешь используй Scada, хочешь не используй. Даже если опрос настроить раз в несколько минут, в регистрах будет зафиксирован последний код Аварии и ее время.
Разложить на биты в Scada не составляет труда, а вот все засунуть в один или два регистра и потом вытаскивать в Scada еще и время это лишний мартышкин труд.
Проще передать двумя регистрами время UTC и третьим регистром код Аварии. А вот для экрана надо будет добавить разложение по битам в самом ПР, если прямо нужна будет такая необходимость. При чем во время работы экрана в сеть так же передается только последняя Авария, чтобы в Scada не попадали данные предыдущих, если оператор смотрит ошибки непосредственно на экране.
Я исходил из того, что вероятность возникновения ДВУХ аварий в ОДНОМ цикле ПР крайне мала, и даже если она есть, Scada это увидит на следующем опросе. Ну а на экране будет код числа из двух битов, что не так уж и страшно....
Макрос RAMP_BIT позволяет для 32 аварий иметь код аварии занимающий 5 бит в энергонезависимой памяти(уже писал об этом), у Вас, как Вы сами написали каждой аварии соответствует свой определённый бит, то есть занимает памяти в 6,4 раза больше! В любой момент времени срабатывает одновременно не более одной аварии и это всё для отображения аварии на экране ПР построчно, в порядке их поступления(можно и с датой-временем, если это нужно) и сохранением в памяти, это позволит на ПР сохранить не менее 160 аварий при моём подходе, ну если это нужно! Если это не нужно и достаточно 25 аварий сохранить, то и заморачиваться не стоит, я так думаю!
А зачем Вы в скаду время передаёте, возьмите нормальную скаду с часами и проблема отпадёт сама собой! И в скаду, мне так кажется, лучше передавать значение контролируемого параметра(например: давление, ток двигателя и т. д.), тогда и проще будет разобраться случись какая авария, надеюсь, понятно объяснил?! Ну и по тренду и так будет видно когда там чего выключилось, то есть, что Вы делаете, будет и не нужно!
Примерно как-то так:
47046
Разные Scada пишут архивы по разному. Например запись раз в минуту, а текущие значения по мере скорости опроса. Например на текущие значения можно натравить "События" и мы узнаем даже пиковый всплеск, НО, а если пиковый всплеск произошел МЕЖДУ периодами опроса ?
Время сохраняется для того, чтобы отобразить его на экране ПР и для того, чтобы Scada прочитав код Аварии увидела, когда она произошла.
з.ы. Понятие Спорадическая связь надеюсь вам о чем-то говорит ? Вот именно для таких случаев это все делается.
Каждый раз делать своеобразные макросы под те или иные задачи банально трата времени. Нужно сделать ОДИН и пользоваться его возможностями в различных ситуациях.
По этому я и не приемлю запихивание в один регистр сразу и времени и кодов ошибок.
А так, есть два фактора
1. Время - Многие Scada спокойно работают с форматом UTC (а часики в железках часто оставляют желать лучшего)
2. ну собственно код Аварии - любая Scada раскладывает биты без проблем
Ну вот из 2 вытекает еще разложение по битам в самом ПР на экране, но это не прямо таки жесткая необходимость. Тут может и таблички на двери щитка хватить... Просто отобразить на экране битовую маску кода например... Это чисто для оперативного персонала.
Сергей0308
05.02.2020, 01:42
Разные Scada пишут архивы по разному. Например запись раз в минуту, а текущие значения по мере скорости опроса. Например на текущие значения можно натравить "События" и мы узнаем даже пиковый всплеск, НО, а если пиковый всплеск произошел МЕЖДУ периодами опроса ?
Время сохраняется для того, чтобы отобразить его на экране ПР и для того, чтобы Scada прочитав код Аварии увидела, когда она произошла.
з.ы. Понятие Спорадическая связь надеюсь вам о чем-то говорит ? Вот именно для таких случаев это все делается.
Каждый раз делать своеобразные макросы под те или иные задачи банально трата времени. Нужно сделать ОДИН и пользоваться его возможностями в различных ситуациях.
По этому я и не приемлю запихивание в один регистр сразу и времени и кодов ошибок.
А так, есть два фактора
1. Время - Многие Scada спокойно работают с форматом UTC (а часики в железках часто оставляют желать лучшего)
2. ну собственно код Аварии - любая Scada раскладывает биты без проблем
Ну вот из 2 вытекает еще разложение по битам в самом ПР на экране, но это не прямо таки жесткая необходимость. Тут может и таблички на двери щитка хватить... Просто отобразить на экране битовую маску кода например... Это чисто для оперативного персонала.
И Вы не правы насчёт макроса RAMP_BIT, его прототип у меня получился ещё при создании макроса "очередь", самого сложного моего макроса, потом несколько раз совершенствовался(стал быстрее в 32 раза), в результате получилось то, что имеем и он достаточно универсален, хотя изначально такое не планировалось, например, как Вы хотели изменение переменной на выходе макроса можно привязать в событию(внешнему сигналу), для этого существуют входы разрешения работы "En", просто Вы этого не знаете, а пытаетесь о нем что-то сказать, спросили бы, если Вам такое нужно сделать, то можете как Архимед кричать эврика!
Да про события речь не о ПР, а о Scada. Не путайте немного. Все упирается в время опроса Scada системы ПР и других устройств на линии, ведь ПР может быть не единственным устройством и опрос может быть например раз в 5 минут или вообще раз в 30 минут.
Вот исходя из этого и скажите, как настроить RAMP_BIT, чтобы Scada не пропустила ошибку ?
Еще момент, даже если Scada будет читать в цикле по кругу, а RAMP_BIT в цикле ПР будет менять биты ошибок - я себе такой мусор в БД Scada просто не представляю...
Есть моменты где хороши одни решения, но не подходят для других ситуаций.
Сергей0308
05.02.2020, 11:13
Да про события речь не о ПР, а о Scada. Не путайте немного. Все упирается в время опроса Scada системы ПР и других устройств на линии, ведь ПР может быть не единственным устройством и опрос может быть например раз в 5 минут или вообще раз в 30 минут.
Вот исходя из этого и скажите, как настроить RAMP_BIT, чтобы Scada не пропустила ошибку ?
Еще момент, даже если Scada будет читать в цикле по кругу, а RAMP_BIT в цикле ПР будет менять биты ошибок - я себе такой мусор в БД Scada просто не представляю...
Есть моменты где хороши одни решения, но не подходят для других ситуаций.
Я не вижу никаних проблем, можно как угодно сделать, даже как Вы хотите(насколько могу это понять), в предложенном мной варианте аварии запоминаются в памяти реле с меткой времени и если метка времени с секундами, то на года не остаётся памяти в одной переменной и в скаду надо передать в течении года, короче, надеюсь за год Вы успеете в скаду передать?
Сергей0308 я же писал выше, в Scada уходит время в формате UTC, соответственно 2 регистра. Обработка в Scada минимальна, так как все умеют работать с UTC, ну по крайней мере многие.
з.ы. что-то не пойму, то вы пишите, что RAMP_BIT постоянно перебирает биты аварий на выход для отображения на экране и тут вы говорите, что этого можно не далать, так как он тогда работает ?
Поймите, в Scada (сетевая переменная в ПР) не должна скакать как ей вздумается, она должна быть всегда ПОСЛЕДНЕЙ.
А вот на экране ПР, в любой момент можно посмотреть все...
В общем кучка факторов чтобы работало красиво и на ПР и в то же время в Scada
stanislau
09.02.2020, 20:30
В общем, если понадобится в скаду передавать аварии, то я думаю можно передавать из ПР только последнюю запись архива. В скаде же можно свой журнал сделать. Пускай она аналогично ПР смещает первую запись по мере поступления следующих аварий в конец архива. Так можно будет сделать? Еще прикрутил к архиву сброс.
stanislau к экранам пробовали прикручивать ? что вышло ?
stanislau
09.02.2020, 22:36
На экран ПР? Если на ПР, то да, все нормально отображается и регистрируется, завтра фото сделаю. Вместо нолей используемых в качестве пробелов поставил /.
stanislau
10.02.2020, 14:14
Вот, что получилось.
stanislau
12.02.2020, 21:29
Сергей0308! Если можно, то по архиву аварий давайте тут. Мне нужен следующий архив: дата/время обязательно, в читаемом для обычного человека виде; номер сработавшего канала-ни каких бегущих строк, расшифровок приклеенных на дверь щита и т.д. В вашем проекте я не увидел даты/времени. Если можете, переделайте Ваш проект на 24 аварийных сигнала, отображение сработавшего канала, отображение даты и времени. Храниться должно восемь записей. Выглядеть это должно как на фото из #60. Что в таком случае можно упростить в 24 раза?
я свой Архиватор еще не доделал, в планах второй экран с расшифровкой как раз.
На основном экране у меня дата и код аварии, на втором экране будет расшифровка, но пока нету, и в планах увеличить количество ячеек до 32-х
stanislau
12.02.2020, 22:26
Я не понимаю чем мой так плох? Тем, что одно значение-одна энергонезависимая переменная? Зато ОЗУ и ПЗУ в разы меньше расходуется. Сэкономим на энергонезависимых переменных, но на эту экономию потратим 50% ОЗУ и 25% ПЗУ. Что там на проект остается? Перекладывание из одного кармана в другой.
На экране главное все понятно для обычного рабочего без красного диплома по автоматизации. Подошел на одну кнопку нажал - все перед глазами.
Выкладывайте свои варианты, интересно сравнить по возможностям и ресурсам.
ссылка в 37 посту темы.
Кажется писал уже. зачем использовать макросы на кучу входов, если используется меньше ?
Макрос только с 8-мью выходными авариями. Ну и там стек на задержках. Иногда он полезен, иногда нет...
Сергей0308
12.02.2020, 23:36
Сергей0308! Если можно, то по архиву аварий давайте тут. Мне нужен следующий архив: дата/время обязательно, в читаемом для обычного человека виде; номер сработавшего канала-ни каких бегущих строк, расшифровок приклеенных на дверь щита и т.д. В вашем проекте я не увидел даты/времени. Если можете, переделайте Ваш проект на 24 аварийных сигнала, отображение сработавшего канала, отображение даты и времени. Храниться должно восемь записей. Выглядеть это должно как на фото из #60. Что в таком случае можно упростить в 24 раза?
Вот в Вашем проекте из другой темы заменил ваш макрос SR24 на два своих! Они не только запоминают аварии, но и разруливают одновременные срабатывания входов, что наверно Вам не нужно, но это всё равно проще вашей конструкции и в них не используются функциональные блоки по которым существует ограничение в ОЛ, это первый пункт, что я одним глазком взглянул, наверно по остальным подобная ситуация, ну я так думаю!
47270
И наверно можно из 24 экранов настройки канала оставить один, и менять на нём номер настраемого канала, у Вас же они абсолютно одинаковые, зачем так "мудрить", а если их тысяча была, Вы бы тысячу экранов прилепили?!
Я вот только совсем недавно приводил пример, как я делал:
47272
Надеюсь смысл понятен?!
И, насколько мне известно, сетевая переменная 16 битная(обрезается до 16 бит, диапазон 0-15):
47277
stanislau
13.02.2020, 09:12
У меня OL 1,16 не обновляется, открыть файл не могу.
И, насколько мне известно, сетевая переменная 16 битная(обрезается до 16 бит, диапазон 0-15):
47277
Насколько мне известно, целочисленную сетевую переменную можно сделать двухрегистровой и читать, например, из МВ110-32 битовую маску входов одной переменной. Но это неважно, т.к. автор планировал читать данные из трёх МВ110. Вопрос в другом: нафига ему три разных макроса ext, когда сам макрос позволяет менять константы?
Сетевую переменную нельзя сделать 32 битной, зато две сетевых переменных прекрасно собираются в 32 битную локальную через сдвиг и сложение. Посмотрите тему/опрос которую я создавал. Там как раз в одном из вариантов так сделано
Сетевую переменную нельзя сделать 32 битной, зато две сетевых переменных прекрасно собираются в 32 битную локальную через сдвиг и сложение. Посмотрите тему/опрос которую я создавал. Там как раз в одном из вариантов так сделано
Нельзя только если ПР - слейв
Если ПР мастер, то можно читать и писать 32 битные переменные
47279
Сергей0308
13.02.2020, 12:50
Нельзя только если ПР - слейв
Если ПР мастер, то можно читать и писать 32 битные переменные
47279
Если это так, это просто замечательно, тогда непонятно почему аналогично нельзя сделать для режима ведомого устройства, ну что бы вручную не слепливать?
stanislau
13.02.2020, 13:33
нафига ему три разных макроса ext, когда сам макрос позволяет менять константы?
Вот это не понял. Три сетевые переменные, три разных МВ, три макроса. Как одним макросом опрашивать три МВ?
одновременные срабатывания входов, что наверно Вам не нужно
Я такой возможности не исключаю, поэтому-нужно.
а если их тысяча была
Ну над этим я думал. Но тут их 24, а не 100. Чтобы сделать один дисплей мне надо 4 демультиплексора. Что более затратно: 4 демультиплексора на 24 канала каждый или 24 дисплея?
заменил ваш макрос SR24 на два своих
Вот сравнил расход ресурсов. Мне кажется нет тут экономии. Плюс надо добавить фиксацию при одновременном срабатывании в Вашем варианте.
С хранением архива я затупил. В макросе энергонезависимые переменные и в самой проге еще раз создал энергонезависимые переменные. Надо лишние удалить.
Сергей0308
13.02.2020, 18:18
Вот это не понял. Три сетевые переменные, три разных МВ, три макроса. Как одним макросом опрашивать три МВ?
Я такой возможности не исключаю, поэтому-нужно.
Ну над этим я думал. Но тут их 24, а не 100. Чтобы сделать один дисплей мне надо 4 демультиплексора. Что более затратно: 4 демультиплексора на 24 канала каждый или 24 дисплея?
Вот сравнил расход ресурсов. Мне кажется нет тут экономии. Плюс надо добавить фиксацию при одновременном срабатывании в Вашем варианте.
С хранением архива я затупил. В макросе энергонезависимые переменные и в самой проге еще раз создал энергонезависимые переменные. Надо лишние удалить.
Не надо там никакой фиксации, всё и так замечательно фиксируется, но если сработает одновременно более одной аварии, например все 24, то каждый цикл программы будет возникать по одной аварии, начиная с самой старшей по номеру входа(номеру, весовому коэффициенту соответствующего ему бита) и далее по мере уменьшения старшинства, это позволяет не иметь отдельного бита для записи каждой аварии, а писать номер бита соответствующий аварии на входе, т. е. достаточно 5 бит(диапазон 0-31) для всех аварий, вместо 24, только недавно писал об этом, видимо никто не читает?!
И эти макросы я создавал для своих целей, своего проекта, не факт, что здесь абсолютно одинаковая задача!
Насколько я понял, у Вас не стоит задача экономии памяти, значит можно если более одной аварии одновременно сработали записать их битовой маской аварий(а не триггерами) + время аварий(одно на все) и всё это сделать за один цикл, надеюсь понятно написал?!
Вот создал аналог вашего макроса, смотрите что получается:
47286
Вы помните, что Вы утверждали? Посмотрите на конструкцию в овале, что я выделил, по сути Вы утверждали что это(много дней Вам говорил об этом) сложней вашей конструкции из 24 RS-триггеров(может быть до 32), что противоречит здравому смыслу. К тому же здесь функционал выше, например можно сделать энергонезависимость, сброс аварий гибче настраивается!
47287
Даже так:
47290
Вот, даже макрос состряпал на всякий случай:
47291
47292
И ещё хотел уточнить, Вам какой функционал нужен? А то в проекте, что я переделал из другой темы там ваш макрос SR24 без детекторов переднего фронта на входе взведения триггеров, а в текущей теме в последнем вашем проекте тот же макрос с детекторами переднего фронта, как бы логика работы будет отличатся ну и лучше наверно их следует как-то по разному подписать, хотя бы для того, что бы не путать, ну я так думаю, и если Вам потребуется второй вариант(с детекторами переднего фронта), надеюсь, сумеете пальцем шевельнуть, что бы сделать как Вы хотите, я понимаю когда что-то сложное, но здесь же самое элементарное, проще не куда(мне даже стыдно такое подсказывать), как мне кажется!
Для упрощения макроса SR24 с детекторами переднего фронта на входах взвода триггеров ничего и придумывать не надо, подойдёт самый первый вариант, что я предложил:
47306
47307
Ну если придумаете проще моего, не буду напоминать, что я его делал для других задач, то не таите в себе, похвалитесь!
Вот и в вашем проекте из текущей темы:
47308
Сетевую переменную нельзя сделать 32 битной, зато две сетевых переменных прекрасно собираются в 32 битную локальную через сдвиг и сложение. Посмотрите тему/опрос которую я создавал. Там как раз в одном из вариантов так сделано
Ежели это был мне ответ, то "насколько мне известно" -- это просто фигура речи. На самом деле у меня двухрегистровыми INT-переменными давно опрашиваются ТРМы202. Нужды сокращать количество запросов по modbus на том объекте нет (слейвов немного), просто пробовал. А вот через сдвиг и деление с остатком сетевые переменные там как раз разбираются, а не собираются.
Вот это не понял. Три сетевые переменные, три разных МВ, три макроса. Как одним макросом опрашивать три МВ?
Не о том речь. Для чего было создавать 3 макроса: ext1-8, ext9-16 и ext17-24? Можно было обойтись одним, меняя значения констант.
47293
stanislau
15.02.2020, 01:59
Да хоспаде, 24 триггера были прилеплены по-быстрому чтобы проверить работу ExtC. Это просто костыль. Я еще тогда не решил кто будет давать импульс аварийного сигнала. Какой-нибудь "сумматор" кода после pack24 я еще не делал. Что Вы так разволновались? Я добился нормального разложения кодов аварий и бросил пока это. Сейчас переделал макрос РКС, займусь авариями.
Вы, RAMPами сэкономили 18 ФБ по сравнению с моим архивом с ненавистными 24 триггерами. Зато переменных, ЭСППЗУ, ПЗУ, ОЗУ потратили больше. Посмотрите сами. Теперь вопрос в студию - что лучше? Экономить ФБ или переменные, ЭСППЗУ, ПЗУ, ОЗУ?
Остальное завтра посмотрю.
stanislau
15.02.2020, 02:01
В принципе вот с сумматором. Только надо побитово складывать, а не через ADD.
Сергей0308
15.02.2020, 16:17
Да хоспаде, 24 триггера были прилеплены по-быстрому чтобы проверить работу ExtC. Это просто костыль. Я еще тогда не решил кто будет давать импульс аварийного сигнала. Какой-нибудь "сумматор" кода после pack24 я еще не делал. Что Вы так разволновались? Я добился нормального разложения кодов аварий и бросил пока это. Сейчас переделал макрос РКС, займусь авариями.
Вы, RAMPами сэкономили 18 ФБ по сравнению с моим архивом с ненавистными 24 триггерами. Зато переменных, ЭСППЗУ, ПЗУ, ОЗУ потратили больше. Посмотрите сами. Теперь вопрос в студию - что лучше? Экономить ФБ или переменные, ЭСППЗУ, ПЗУ, ОЗУ?
Остальное завтра посмотрю.
В принципе вот с сумматором. Только надо побитово складывать, а не через ADD.
Вы бы, для начала, определились с необходимой логикой работы(ТЗ), пока не определитесь, считаю дальнейшие действия бессмысленными, так вот, если вдруг, Вам не нужны детекторы переднего фронта на входах взвода SR-триггеров, то всю вашу конструкцию можно заменить на два элемента, даже не ФБ как у вас, а две функции, я же чуть выше не только картинку выложил:
47319
но и проект, так вот при таком раскладе количество элементов уменьшится в 12 раз, количество ФБ я бы на вашем месте вообще не сравнивал, их количество разнится в гугол раз(самое большое значение раз), насчёт энергонезависимой памяти тоже следует помолчать, я могу сделать переменную энергонезависимой, могу и не делать, в зависимость от требуемой логики работы, а Вы не можете SR-триггеры сделать энергонезависимыми, надеюсь, понятно объяснил и если с математикой у Вас проблем нет, можете сами пересчитать, короче, хотел сказать, что бы Вы поскорей определились с необходимой логикой работы!
stanislau
15.02.2020, 20:02
Я же писал, что триггеры - временно. RTRIG уже не нужны поскольку макрос РКС будет выдавать импульс аварийного сигнала. Сегодня посмотрел на работу сумматора на ADD из #76. Он не годится - суммирует одинаковые импульсы до окончания проверки сработавших бит ExtC. Заменил на OR. Все заработало как надо. Посмотрел Ваши остальные файлы. Так у Вас тоже через OR сделано. Вот переделанный файл. Кстати, так и не услышал ответа на вопрос, что все-таки лучше: меньшее количество ФБ и большее потребление ОЗУ, ПЗУ или большее количество ФБ и меньшее потребление ОЗУ, ПЗУ. В посте #75 два файла я специально выложил. Посмотрите в них потребление ресурсов. Получается 24 триггера жрут меньше чем 2 RAMPа.
Сергей0308
15.02.2020, 20:40
Я же писал, что триггеры - временно. RTRIG уже не нужны поскольку макрос РКС будет выдавать импульс аварийного сигнала. Сегодня посмотрел на работу сумматора на ADD из #76. Он не годится - суммирует одинаковые импульсы до окончания проверки сработавших бит ExtC. Заменил на OR. Все заработало как надо. Посмотрел Ваши остальные файлы. Так у Вас тоже через OR сделано. Вот переделанный файл. Кстати, так и не услышал ответа на вопрос, что все-таки лучше: меньшее количество ФБ и большее потребление ОЗУ, ПЗУ или большее количество ФБ и меньшее потребление ОЗУ, ПЗУ. В посте #75 два файла я специально выложил. Посмотрите в них потребление ресурсов. Получается 24 триггера жрут меньше чем 2 RAMPа.
Замечательно, хоть что-то начинает проясняться! Тогда запишем золотыми буквами, что детекторы переднего фронта Вам не нужны, если использовать макрос SR24 в данный момент! Тогда ваши 24 триггера с лихвой заменят два элемента, целочисленный SEL и OR, вот и сравнивайте их с 24 триггерами, что Вы всё пытаетесь мне какую-то лабуду преподнести, давайте лучше по делу, в конце концов, это же Вам, а не мне нужно! Ну и странно что Вы только что посмотрели, как же Вы пишите ответы не смотря, что Вам прислали?! Как говорится, лучше поздно, чем никогда!
По вопросу что лучше: https://www.youtube.com/watch?v=glQ32H-4gdw
stanislau
15.02.2020, 22:34
Вы, что между строк читаете? Я вообще не понимаю. Все началось с темы "ПР200". Вы там посмотрели первый файл ркс_дискр_24_1 и сказали, что все можно упростить. Причем в том файле уже был макрос только на ср-триггерах без ртриг. Я перешел по ссылке которую Вы указали. Далее обсуждали здесь. Я открыл последний файл из #72 этой темы. Вы пишете, что я нерационально что-то там использую, лишние 24 элемента и т.д. Смотрю, что после "оптимизации" на рампах потребление переменных, ЭСППЗУ, ПЗУ, ОЗУ увеличилось. Не так что ли?
В #78 уже последний вариант без триггеров, рампов и прочего.
Все Ваши файлы сразу не посмотрел, было уже очень поздно. А сегодня и сам с сел и ор сделал.
И, да, очень смешное видео. Очень помогло.
Сергей0308
15.02.2020, 22:59
Вы, что между строк читаете? Я вообще не понимаю. Все началось с темы "ПР200". Вы там посмотрели первый файл ркс_дискр_24_1 и сказали, что все можно упростить. Причем в том файле уже был макрос только на ср-триггерах без ртриг. Я перешел по ссылке которую Вы указали. Далее обсуждали здесь. Я открыл последний файл из #72 этой темы. Вы пишете, что я нерационально что-то там использую, лишние 24 элемента и т.д. Смотрю, что после "оптимизации" на рампах потребление переменных, ЭСППЗУ, ПЗУ, ОЗУ увеличилось. Не так что ли?
В #78 уже последний вариант без триггеров, рампов и прочего.
Все Ваши файлы сразу не посмотрел, было уже очень поздно. А сегодня и сам с сел и ор сделал.
И, да, очень смешное видео. Очень помогло.
Здесь важно понять смысл видео, чего не хватает, то и оптимизируете! Про очевидное я и говорить не хочу: две функции однозначно проще(и предпочтительней) 24 ФБ!
stanislau
15.02.2020, 23:10
Про функции я не спорю! Но вот с теми макросами мне не совсем очевидно, что такое решение лучше.
Сергей0308
15.02.2020, 23:37
Про функции я не спорю! Но вот с теми макросами мне не совсем очевидно, что такое решение лучше.
Во-первых я бы сравнивал макросы хотя бы выполняющие одну функцию, Вы постоянно лукавите предлагая сравнить два моих макроса с вашим макросом SR24 без детекторов переднего фронта, хотя я неоднократно заявил что для этого я специально придумал схему из двух функций, вот и сравните две функции с 24 ФБ! Теперь 2 вариант: сравниваем ваш макрос SR24 с детекторами переднего фронта, то есть в макросе 48 ФБ с двумя моими макросами, выполняющими туже функцию, короче в моих 2 макросах элементов раза в два меньше будет и функционал выше, про количество ФБ уже писал, что здесь непонятно?! И ещё раз приходится Вам напоминать, что эти макросы создавал для других задач и Вам не для сравнения показал, а для того что бы показать другие пути решения, Вы стали к ним придираться, а не делом заниматься, мне даже пришлось Вам аналог макроса SR24 без детекторов переднего фронта сделать, вот это и сравниваете, неужели это так тяжело?!
Лично для Вас(для любого человека) проще то, что Вы понимаете как это работает и можете поправить(усовершенствовать) под свои нужды! Самая короткая дорога та, которую знаешь!
stanislau
16.02.2020, 00:09
Вы постоянно лукавите
Ну, это не правда.
Вот тут в #4145. https://owen.ru/forum/showthread.php?t=17153&page=415 в макросе уже не было ртриггеров. Их до этого dan75 предложил выкинуть.
В #4147 той темы Вы предложили посмотреть Вашу программу с рампами. Я посмотрел, что потребляет ресурсов она больше чем то, что я выложил в #4145.
Здесь же Вы почему-то уже взяли более старую версию архива еще с ртриг.
Сергей0308
16.02.2020, 00:36
Ну, это не правда.
Вот тут в #4145. https://owen.ru/forum/showthread.php?t=17153&page=415 в макросе уже не было ртриггеров. Их до этого dan75 предложил выкинуть.
В #4147 той темы Вы предложили посмотреть Вашу программу с рампами. Я посмотрел, что потребляет ресурсов она больше чем то, что я выложил в #4145.
Здесь же Вы почему-то уже взяли более старую версию архива еще с ртриг.
Хорошо с этим макросом с 24 SR-триггерами разобрались, заменили их на две функции, во сколько раз упростили в 12 по количеству элементов в гугол раз по количеству ФБ, всё проехали это! Может что ещё можно упростить у Вас в проекте?
Я почему к этому макросу "доколупался", потому что он простой и легко понять его логику работы и то мы его смогли упростить в 12 раз, надо полагать другие, более сложные макросы должны упростится в большее количество раз, я логично рассуждаю?
Короче если напишите ТЗ, необходимую логику работы других макросов, можем попробовать и другие упростить, Вы, надеюсь, не против?
Я предлагаю начать с реле контроля скорости, сразу это коснется не одного, а 24 макросов!
stanislau
16.02.2020, 11:25
Да, Сергей, я только за. Реле контроля скорости по сравнению с первоначальным вариантом сильно упростил. Куда выкладывать? Тему отдельную создавать нет смысла. Тут где-то (или в разделе "Среда программирования OWEN Logic") была тема про тахометр, туда скину. А с архивом аварий вопрос только с возможной передачей в скаду. Вообще все это мне ни кто задания делать не давал. Да и в должностные обязанности слесаря кип и а разработка и программирование не входят. Так, пытаюсь облегчить себе и оперативному персоналу жизнь. Поэтому сейчас весь архив должен быть легко читаем с экрана ПР. Фото я выкладывал тут. Поэтому хранение даты/времени сейчас сделано именно так. Если при абсолютно такой же читаемости и понятности можно сделать проще, то говорите. В будущем хотелось бы на ПК архив вывести. Но со скадами не работал. Это надо сейчас поискать бесплатную версию какой-либо среды и посмотреть вообще что там и как. Покупать на предприятие программное обеспечение вряд ли кто-то будет.
Scada есть бесплатные, если что. Вариантов много в зависимости от количества необходимых тегов. С увеличением количества тегов варианты выбора уменьшаются :)
Сергей0308
16.02.2020, 20:59
Да, Сергей, я только за. Реле контроля скорости по сравнению с первоначальным вариантом сильно упростил. Куда выкладывать? Тему отдельную создавать нет смысла. Тут где-то (или в разделе "Среда программирования OWEN Logic") была тема про тахометр, туда скину. А с архивом аварий вопрос только с возможной передачей в скаду. Вообще все это мне ни кто задания делать не давал. Да и в должностные обязанности слесаря кип и а разработка и программирование не входят. Так, пытаюсь облегчить себе и оперативному персоналу жизнь. Поэтому сейчас весь архив должен быть легко читаем с экрана ПР. Фото я выкладывал тут. Поэтому хранение даты/времени сейчас сделано именно так. Если при абсолютно такой же читаемости и понятности можно сделать проще, то говорите. В будущем хотелось бы на ПК архив вывести. Но со скадами не работал. Это надо сейчас поискать бесплатную версию какой-либо среды и посмотреть вообще что там и как. Покупать на предприятие программное обеспечение вряд ли кто-то будет.
Мастерскада на 32 точки бесплатная + ОПС-сервер от инсата на 32 тега тоже бесплатный, короче, я их бы предпочёл:
https://insat.ru/products/section/?category=1535
ну да, 32 точки это супер много :)
stanislau
16.02.2020, 23:02
Завтра скачаю эту. Еще нашел SIMP Light . У них тоже 32 точки ввода/вывода. Вообще мне сейчас надо самую простую и распространенную потому, что я в этом разбираюсь как свинья в апельсинах:)
Я бы посоветовал не саму простую и распространенную, а исходя из вашей дальнейшей необходимости.
Просто вы сейчас поставите на 32 точки, а потом надумаете расширяться и удивитесь с цены.
Если речь идет только об опросе приборов, никаких плюшек за деньги, то RapidScada (всего то 65 тысяч тегов), плюшки за деньги. И таки можно сделать сервер на Linux
Если понравится Simp Ligth, то смотрите сколько стоит Enterprise версия, так как она позволяет работать с Modbus без OPC серверов
з.ы. на остальное наверное даже время бы не тратил.... Хотя вкусы у всех разные...
Сергей0308
17.02.2020, 10:48
Я бы посоветовал не саму простую и распространенную, а исходя из вашей дальнейшей необходимости.
Просто вы сейчас поставите на 32 точки, а потом надумаете расширяться и удивитесь с цены.
Если речь идет только об опросе приборов, никаких плюшек за деньги, то RapidScada (всего то 65 тысяч тегов), плюшки за деньги. И таки можно сделать сервер на Linux
Если понравится Simp Ligth, то смотрите сколько стоит Enterprise версия, так как она позволяет работать с Modbus без OPC серверов
з.ы. на остальное наверное даже время бы не тратил.... Хотя вкусы у всех разные...
Ну и что могут ваши скады? Надеюсь хотя бы могут раз в месяц отчёт составить и высчитать средную температуру по суточно, с опросом каждые 10 секунд, если нет и даром такие не нужны, если самого элементарного не могут, а Мастерскада такое может, короче, много чего может!
Сергей0308 часть из перечисленного относится к платным модулям, либо в зубы C# и делайте сами бесплатно либо формулами либо свои модули пишите. Ядро системы бесплатное и с открытым исходным кодом.
Опрос хоть в цикле, причем нативных драйверов в RapidScada несколько больше, чем в других, но и использовать OPC тоже можно.
Как минимум, чтобы раз в месяц что-то создавалось в автоматическом режиме без нажатий кнопок оператором нужен платный Модуль Автоматического управления.
у Simp Ligth можно взять так же Демо полноценную на час работы. По сути та же Enterprise
https://owen.ru/forum/showthread.php?t=32279&p=320574&viewfull=1#post320574
Обновил свой вариант, теперь с окном расшифровки
Решил пойти по пути petera в плане зачем хранить количество секунд от 1970 года, если можно просто упаковать дату и время в 2 регистра (не переменных а именно регистра по 16 бит) и уперся в сохранение времени. Если Дату можно впихнуть в регистр, использую года 0-99 без тысячелетий и столетий, то вот сохранить время в 24-х часовом формате с секундами не получается.... требуется 17 бит.
Как исхитриться чтобы впихнуть в один регистр время с секундами ? может быть с какими-то ограничениями. Есть у кого идеи ?
Легко! Эту классную идею подкинул сергей0308. Просто берите секунды, к ним плюсуйте минуты умноженные на 100, к этому добавляйте часы, умноженные на 10000
В итоге вы получите число формата ччммсс. Если в один регистр лезть ещё с месяцем и годом не хотите, то можно сделать разделитель в виде нуля, а на экране по прикрыть его знаком" :"
59 сек + 59 мин*100 + 23 часа*10000 = и где тут 16 бит ? - вообще 18 бит..... - сорри, действительно 0 упустил
Не, дата в отдельном регистре 16 бит, без столетий влазит. столетия и тысячелетия не проблема организовать в Scada из текущего времени
59 сек + 59 мин*100 + 23 часа*1000 = и где тут 16 бит ? - вообще 18 бит.....
аргументируйте что 18
capzap число получится 235959 а не то, что вам калькулятор показывает... часы умножаются на 10000 а не на 1000
Хорошо, вы умножите часы на 1000, а теперь в Scada обратно как ? что истина будет, чтобы гарантированно получить именно то время, которое зафиксировано единственное и в одном экземпляре ?
Пока придумал только как уместить в 16 бит с шагом секунд, равным 2... тогда влазит
Умножать часы на 1000 не вариант, вы не сможете определить точное время из двух и более совпадений и никакая математика не поможет...
capzap число получится 235959 а не то, что вам калькулятор показывает... часы умножаются на 10000 а не на 1000
Хорошо, вы умножите часы на 1000, а теперь в Scada обратно как ? что истина будет, чтобы гарантированно получить именно то время, которое зафиксировано единственное и в одном экземпляре ?
Пока придумал только как уместить в 16 бит с шагом секунд, равным 2... тогда влазит
ну не я же нолик пропустил в посте, я специально процитировал его
понятно что этот способ не подойдет, но есть же опыт других, сименс например складывает время в вещественное число, слева от запятой дата, справа время, в этом случае эта формула будет работать, естественно умножая часы на 10000.
ага, заметил. поправил пост... В принципе идея с шагом секунд 2 подойдет... уже лучше, чем ничего. зато ресурсы ПР освободятся от вычислений UTC времени. Конечно оно более универсально, так как любая Scada сможет прочесть....
Сименс не предлагать, он сильно захромает 19 января 2038 года с их то ошибкой....
Как вариант избавиться от года, если в Scada будет передаваться последняя ошибка, можно год воспринимать как текущий. Соответственно в архивах БД будут правильные года записаны. Тогда float нормально подойдет да и просто 32-х битная переменная.
А для отображения в ПР можно и с годом показывать, внутри переменные 32-х битные и влезет все.
Сделал макросы без года, но оказалось что выиграл только 1% ПЗУ, ни ЭСППЗУ ни ОЗУ не уменьшилось... тогда как бы и смысла нет получается.... Так как считать время UTC в Scada это всего две строчки кода, а из таких макросов придется чуть поболее написать...
https://owen.ru/forum/showthread.php?t=32279&p=320574&viewfull=1#post320574
Немного переделал, версия 6 на 32 записи. Огромнейшее спасибо Сергей0308 за его макросы EEPROM, правда я их покрошил в пользу использования ресурсов ПР.
Можно еще покрошить до 8 бит, но время с датой и секундами как ни крути останется 32 битным, по этому взял средний вариант.
Сергей0308
13.04.2020, 15:19
https://owen.ru/forum/showthread.php?t=32279&p=320574&viewfull=1#post320574
Немного переделал, версия 6 на 32 записи. Огромнейшее спасибо Сергей0308 за его макросы EEPROM, правда я их покрошил в пользу использования ресурсов ПР.
Можно еще покрошить до 8 бит, но время с датой и секундами как ни крути останется 32 битным, по этому взял средний вариант.
И какой смысл, чтобы разбить и вновь собрать?
48408
Смысл в ресурсах ПР, если у нас вариантов аварий всего 16, то не нужен 32-х битный макрос. Меньше макросов в самом проекте, хотя это конечно не критично.
Кстати когда-то нельзябыло использовать вложенные макросы, было плохо, сейчас все вложенные лезут в проект (что мне тоже не нравится). Было бы супер, если бы сделали возможность в самом макросе настраивать, показывать тот или иной вложенный макрос в общем списке макросов или нет.
Если для ошибок использовать 32-х битную версию, то сразу и ЭСППЗУ прыгает до 39% и ПЗУ тоже увеличивается до 15% (ну это у меняя с некоторыми элементами программы, в чистом виде не проверял).
з.ы. может кто-то будет использовать сокращенный вариант времени и обойдется 16-тью битами для этого. Так еще ресурсы сократит
Со стеком не получилось, скорее всего из-за макросов Fifo идет сильная нагрузка, не посмотрел только сколько мс программа при этом была. Экран при просмотре Аварий просто тух и потом опять показывал значения, и еще показывал на одну ошибку больше, точнее данные времени и ошибок сквозняком показывались, без записи в ячейку. Не стал использовать больше из-за мерцания экрана.
Сергей0308
13.04.2020, 15:41
Смысл в ресурсах ПР, если у нас вариантов аварий всего 16, то не нужен 32-х битный макрос. Меньше макросов в самом проекте, хотя это конечно не критично.
Кстати когда-то нельзябыло использовать вложенные макросы, было плохо, сейчас все вложенные лезут в проект (что мне тоже не нравится). Было бы супер, если бы сделали возможность в самом макросе настраивать, показывать тот или иной вложенный макрос в общем списке макросов или нет.
Если для ошибок использовать 32-х битную версию, то сразу и ЭСППЗУ прыгает до 39% и ПЗУ тоже увеличивается до 15% (ну это у меняя с некоторыми элементами программы, в чистом виде не проверял).
з.ы. может кто-то будет использовать сокращенный вариант времени и обойдется 16-тью битами для этого. Так еще ресурсы сократит
В данном случае переменные 32-х битные, надо было бы и использовать "полноценный" макрос, ну а если где переменная 16 битная, там и использовать "урезанный" вариант! В данном случае с полноценным вариантом макроса и проще вышло бы!
Да, я знаю. На время можно поставить и полноценный, по крайней мере для меня, так как использую макросы времени UTC. Хотя на самом деле надо исхитриться и в 16 бит время загнать. По крайней мере уж дату передавать не так обязательно в Scada. Будет зависеть от самой программы еще. Начнет тормозить или места не будет хватать, буду еще сокращать. Сейчас у меня читается 4 датчика через MB110-8AC плюс этот журнал. Время цикла 7 мс.
Евгений Леонтьев
20.06.2020, 17:18
Подскажите, где можно найти информацию по созданию меню аварий или как можно считать ошибку из журнала?
Сергей0308
20.06.2020, 18:30
Подскажите, где можно найти информацию по созданию меню аварий или как можно считать ошибку из журнала?
В этой теме про аварии писали: https://owen.ru/forum/showthread.php?t=31113&page=7
Непонятно, про какой журнал речь, надеюсь не про Мурзилку, а так никто не запрещает считывать регистры по сети, и всё что в них находится, даже и ошибки или аварии, если это будет соответствующий журнал!
Евгений Леонтьев
20.06.2020, 19:58
Сейчас изучу тему по вашей ссылке. Я имел ввиду журнал событий, например уходим в аварию и где можно посмотреть во сколько это было и как это сделать в лоджике.
Сергей0308
20.06.2020, 20:21
Сейчас изучу тему по вашей ссылке. Я имел ввиду журнал событий, например уходим в аварию и где можно посмотреть во сколько это было и как это сделать в лоджике.
Ещё такой проект у меня есть, с меткой даты-времени, если заинтересует можно найти в какой то теме его подробно обсуждали:
49737
Евгений Леонтьев
20.06.2020, 20:29
Спасибо, изучу.
Сергей0308
20.06.2020, 21:22
Спасибо, изучу.
Вот здесь проект обсуждали: https://owen.ru/forum/showthread.php?t=26216&page=24
Евгений Леонтьев до кучи в изучении https://owen.ru/forum/showthread.php?t=32279&p=320574&viewfull=1#post320574
Всем здравствуйте. Есть ПР200 и ИП120. На входа первого подключено 2 аналоговых датчика. Как можно организовать хранение информации о превышении уставки в формате "значение/время/дата" и вывод этого журнала на экран?
Сергей0308
24.07.2021, 09:48
Всем здравствуйте. Есть ПР200 и ИП120. На входа первого подключено 2 аналоговых датчика. Как можно организовать хранение информации о превышении уставки в формате "значение/время/дата" и вывод этого журнала на экран?
Если писать(в случае превышения уставки) с периодом 10 секунд, то памяти ПР200 хватит минут на 10, для одного параметра, Вас, надеюсь такое устраивает?
Если не устраивает - берите МСД-200: https://owen.ru/product/msd200
а лучше сразу ПК + Мастерскада!
Если писать(в случае превышения уставки) с периодом 10 секунд, то памяти ПР200 хватит минут на 10, для одного параметра, Вас, надеюсь такое устраивает?
Если не устраивает - берите МСД-200: https://owen.ru/product/msd200
а лучше сразу ПК + Мастерскада!
Превышения не так часто происходят, точно не каждые 10 секунд. И записи нужны на много лет вперед не надо - нужно просто зафиксировать событие, показать и сохранить пока не подойдет оператор. А он подойдет максимум через час-два. Потому да, надо такое.
Сергей0308
24.07.2021, 12:24
Превышения не так часто происходят, точно не каждые 10 секунд. И записи нужны на много лет вперед не надо - нужно просто зафиксировать событие, показать и сохранить пока не подойдет оператор. А он подойдет максимум через час-два. Потому да, надо такое.
Для фиксации события есть проект, чуть выше, можно расширить раз в 5-6, до 150-180 событий, тогда значение параметра не следует фиксировать, будет занимать лишнюю память и будет чуть выше уставки!
Короче, я так понимаю, Вы тему не смотрели(проекты из темы), просто решили написать?
Мой вариант аварий в теме Пр200 в теплице.Добавить время не проблема.Максимум 256.
Ruslanadm
13.06.2023, 11:31
День добрый.
Вот для своих целей пришлось сваять вывод и журнал аварий в одном флаконе.
Возможно, кому-то еще это сможет пригодиться.
Область применения - ПР200 и ИПП120.
1. Вывод 20 аварий, запись и хранение 10 последних аварий (цикличная перезапись). Вывод можно и уменьшить и увеличить хоть до 100 и более аварий путем убирания добавления блоков внутри макроса, если конечно в этом есть смысл :)
3. Если авария возникает, описание ее (задается динамическим текстом) выводится на экран 3 секунды и записывается в журнал. Если авария остается активной, она циклически отображается на экране, запись в журнал уже не производится. В случае возникновения одновременно нескольких аварий, они выводятся на экран и записываются в журнал по очереди.
3. Во время возникновения аварий программа переходит на отдельный экран, до снятия этих аварий.
4. Время дата (дд.мм.гг чч-мм, без секунд) и код аварии в журнале для сбережения ресурсов прибора упакованы в одну целочисленную переменную и могут в принципе быть переданы по сети.
5. На экран все выводится через динамический текст (хотя изначально были варианты как у тов. Petera - дата и время с доп. нулями и с наложением символами-разделителями поверх). Название любой аварии можно задать индивидуально. Есть очистка журнала (отдельный вход макроса).
Естественно, каждый пункт можно переделать под свои задачи и нужды.
68292
Немного видео, как это работает
https://youtu.be/sGMvgnRAicc
Ну и сам макрос в виде проекта
АлександрН
23.01.2024, 11:10
Понравилось решение, но чтобы работало
хранение 10 последних аварий (цикличная перезапись)
считаю необходимым поправить вот так:
73045
иначе при включении питания ПР в энергонезависимую переменную "ДатаXX" пишется "0".
Ruslanadm
24.01.2024, 22:38
Да, спасибо, когда я делал этот макрос, я совершенно забыл об сохранении и продолжении журнала при отключении питания, потому что у нас все эти вещи на бесперебойниках.
Планирую капитально доработать, надо чтобы это все-таки было.
Powered by vBulletin® Version 4.2.3 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot