Страница 8 из 13 ПерваяПервая ... 678910 ... ПоследняяПоследняя
Показано с 71 по 80 из 122

Тема: Архив аварий на ПР200

  1. #71

    По умолчанию

    нафига ему три разных макроса ext, когда сам макрос позволяет менять константы?
    Вот это не понял. Три сетевые переменные, три разных МВ, три макроса. Как одним макросом опрашивать три МВ?
    одновременные срабатывания входов, что наверно Вам не нужно
    Я такой возможности не исключаю, поэтому-нужно.
    а если их тысяча была
    Ну над этим я думал. Но тут их 24, а не 100. Чтобы сделать один дисплей мне надо 4 демультиплексора. Что более затратно: 4 демультиплексора на 24 канала каждый или 24 дисплея?
    заменил ваш макрос SR24 на два своих
    Вот сравнил расход ресурсов. Мне кажется нет тут экономии. Плюс надо добавить фиксацию при одновременном срабатывании в Вашем варианте.
    С хранением архива я затупил. В макросе энергонезависимые переменные и в самой проге еще раз создал энергонезависимые переменные. Надо лишние удалить.
    Изображения Изображения
    Последний раз редактировалось stanislau; 13.02.2020 в 15:56.

  2. #72
    Пользователь Аватар для Сергей0308
    Регистрация
    25.06.2011
    Адрес
    Галактика Андромеды (M31)
    Сообщений
    8,167

    По умолчанию

    Цитата Сообщение от stanislau Посмотреть сообщение
    Вот это не понял. Три сетевые переменные, три разных МВ, три макроса. Как одним макросом опрашивать три МВ?

    Я такой возможности не исключаю, поэтому-нужно.

    Ну над этим я думал. Но тут их 24, а не 100. Чтобы сделать один дисплей мне надо 4 демультиплексора. Что более затратно: 4 демультиплексора на 24 канала каждый или 24 дисплея?

    Вот сравнил расход ресурсов. Мне кажется нет тут экономии. Плюс надо добавить фиксацию при одновременном срабатывании в Вашем варианте.
    С хранением архива я затупил. В макросе энергонезависимые переменные и в самой проге еще раз создал энергонезависимые переменные. Надо лишние удалить.
    Не надо там никакой фиксации, всё и так замечательно фиксируется, но если сработает одновременно более одной аварии, например все 24, то каждый цикл программы будет возникать по одной аварии, начиная с самой старшей по номеру входа(номеру, весовому коэффициенту соответствующего ему бита) и далее по мере уменьшения старшинства, это позволяет не иметь отдельного бита для записи каждой аварии, а писать номер бита соответствующий аварии на входе, т. е. достаточно 5 бит(диапазон 0-31) для всех аварий, вместо 24, только недавно писал об этом, видимо никто не читает?!
    И эти макросы я создавал для своих целей, своего проекта, не факт, что здесь абсолютно одинаковая задача!
    Насколько я понял, у Вас не стоит задача экономии памяти, значит можно если более одной аварии одновременно сработали записать их битовой маской аварий(а не триггерами) + время аварий(одно на все) и всё это сделать за один цикл, надеюсь понятно написал?!

    Вот создал аналог вашего макроса, смотрите что получается:

    Запоминание аварии.PNG

    Вы помните, что Вы утверждали? Посмотрите на конструкцию в овале, что я выделил, по сути Вы утверждали что это(много дней Вам говорил об этом) сложней вашей конструкции из 24 RS-триггеров(может быть до 32), что противоречит здравому смыслу. К тому же здесь функционал выше, например можно сделать энергонезависимость, сброс аварий гибче настраивается!

    Запоминание аварии.owl

    Даже так:

    Запоминание аварии_3.PNG

    Вот, даже макрос состряпал на всякий случай:

    Запоминание аварии_2.PNG

    Запоминание аварии_2.owl

    И ещё хотел уточнить, Вам какой функционал нужен? А то в проекте, что я переделал из другой темы там ваш макрос SR24 без детекторов переднего фронта на входе взведения триггеров, а в текущей теме в последнем вашем проекте тот же макрос с детекторами переднего фронта, как бы логика работы будет отличатся ну и лучше наверно их следует как-то по разному подписать, хотя бы для того, что бы не путать, ну я так думаю, и если Вам потребуется второй вариант(с детекторами переднего фронта), надеюсь, сумеете пальцем шевельнуть, что бы сделать как Вы хотите, я понимаю когда что-то сложное, но здесь же самое элементарное, проще не куда(мне даже стыдно такое подсказывать), как мне кажется!

    Для упрощения макроса SR24 с детекторами переднего фронта на входах взвода триггеров ничего и придумывать не надо, подойдёт самый первый вариант, что я предложил:

    Запоминание аварии_4.PNG

    Запоминание аварии_4.owl

    Ну если придумаете проще моего, не буду напоминать, что я его делал для других задач, то не таите в себе, похвалитесь!

    Вот и в вашем проекте из текущей темы:

    Архив аварий_8_2.owl
    Последний раз редактировалось Сергей0308; 14.02.2020 в 20:19.
    Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
    справиться с проблемами, либо это не твои проблемы.

  3. #73

    По умолчанию

    Цитата Сообщение от bayk Посмотреть сообщение
    Сетевую переменную нельзя сделать 32 битной, зато две сетевых переменных прекрасно собираются в 32 битную локальную через сдвиг и сложение. Посмотрите тему/опрос которую я создавал. Там как раз в одном из вариантов так сделано
    Ежели это был мне ответ, то "насколько мне известно" -- это просто фигура речи. На самом деле у меня двухрегистровыми INT-переменными давно опрашиваются ТРМы202. Нужды сокращать количество запросов по modbus на том объекте нет (слейвов немного), просто пробовал. А вот через сдвиг и деление с остатком сетевые переменные там как раз разбираются, а не собираются.

  4. #74

    По умолчанию

    Цитата Сообщение от stanislau Посмотреть сообщение
    Вот это не понял. Три сетевые переменные, три разных МВ, три макроса. Как одним макросом опрашивать три МВ?
    Не о том речь. Для чего было создавать 3 макроса: ext1-8, ext9-16 и ext17-24? Можно было обойтись одним, меняя значения констант.
    ext 0.png

  5. #75

    По умолчанию

    Да хоспаде, 24 триггера были прилеплены по-быстрому чтобы проверить работу ExtC. Это просто костыль. Я еще тогда не решил кто будет давать импульс аварийного сигнала. Какой-нибудь "сумматор" кода после pack24 я еще не делал. Что Вы так разволновались? Я добился нормального разложения кодов аварий и бросил пока это. Сейчас переделал макрос РКС, займусь авариями.
    Вы, RAMPами сэкономили 18 ФБ по сравнению с моим архивом с ненавистными 24 триггерами. Зато переменных, ЭСППЗУ, ПЗУ, ОЗУ потратили больше. Посмотрите сами. Теперь вопрос в студию - что лучше? Экономить ФБ или переменные, ЭСППЗУ, ПЗУ, ОЗУ?
    Остальное завтра посмотрю.
    Вложения Вложения

  6. #76

    По умолчанию

    В принципе вот с сумматором. Только надо побитово складывать, а не через ADD.
    Вложения Вложения

  7. #77
    Пользователь Аватар для Сергей0308
    Регистрация
    25.06.2011
    Адрес
    Галактика Андромеды (M31)
    Сообщений
    8,167

    По умолчанию

    Цитата Сообщение от stanislau Посмотреть сообщение
    Да хоспаде, 24 триггера были прилеплены по-быстрому чтобы проверить работу ExtC. Это просто костыль. Я еще тогда не решил кто будет давать импульс аварийного сигнала. Какой-нибудь "сумматор" кода после pack24 я еще не делал. Что Вы так разволновались? Я добился нормального разложения кодов аварий и бросил пока это. Сейчас переделал макрос РКС, займусь авариями.
    Вы, RAMPами сэкономили 18 ФБ по сравнению с моим архивом с ненавистными 24 триггерами. Зато переменных, ЭСППЗУ, ПЗУ, ОЗУ потратили больше. Посмотрите сами. Теперь вопрос в студию - что лучше? Экономить ФБ или переменные, ЭСППЗУ, ПЗУ, ОЗУ?
    Остальное завтра посмотрю.
    Цитата Сообщение от stanislau Посмотреть сообщение
    В принципе вот с сумматором. Только надо побитово складывать, а не через ADD.
    Вы бы, для начала, определились с необходимой логикой работы(ТЗ), пока не определитесь, считаю дальнейшие действия бессмысленными, так вот, если вдруг, Вам не нужны детекторы переднего фронта на входах взвода SR-триггеров, то всю вашу конструкцию можно заменить на два элемента, даже не ФБ как у вас, а две функции, я же чуть выше не только картинку выложил:

    Запоминание аварии_3_2.png

    но и проект, так вот при таком раскладе количество элементов уменьшится в 12 раз, количество ФБ я бы на вашем месте вообще не сравнивал, их количество разнится в гугол раз(самое большое значение раз), насчёт энергонезависимой памяти тоже следует помолчать, я могу сделать переменную энергонезависимой, могу и не делать, в зависимость от требуемой логики работы, а Вы не можете SR-триггеры сделать энергонезависимыми, надеюсь, понятно объяснил и если с математикой у Вас проблем нет, можете сами пересчитать, короче, хотел сказать, что бы Вы поскорей определились с необходимой логикой работы!
    Последний раз редактировалось Сергей0308; 15.02.2020 в 16:55.
    Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
    справиться с проблемами, либо это не твои проблемы.

  8. #78

    По умолчанию

    Я же писал, что триггеры - временно. RTRIG уже не нужны поскольку макрос РКС будет выдавать импульс аварийного сигнала. Сегодня посмотрел на работу сумматора на ADD из #76. Он не годится - суммирует одинаковые импульсы до окончания проверки сработавших бит ExtC. Заменил на OR. Все заработало как надо. Посмотрел Ваши остальные файлы. Так у Вас тоже через OR сделано. Вот переделанный файл. Кстати, так и не услышал ответа на вопрос, что все-таки лучше: меньшее количество ФБ и большее потребление ОЗУ, ПЗУ или большее количество ФБ и меньшее потребление ОЗУ, ПЗУ. В посте #75 два файла я специально выложил. Посмотрите в них потребление ресурсов. Получается 24 триггера жрут меньше чем 2 RAMPа.
    Вложения Вложения
    Последний раз редактировалось stanislau; 15.02.2020 в 20:06.

  9. #79
    Пользователь Аватар для Сергей0308
    Регистрация
    25.06.2011
    Адрес
    Галактика Андромеды (M31)
    Сообщений
    8,167

    По умолчанию

    Цитата Сообщение от stanislau Посмотреть сообщение
    Я же писал, что триггеры - временно. RTRIG уже не нужны поскольку макрос РКС будет выдавать импульс аварийного сигнала. Сегодня посмотрел на работу сумматора на ADD из #76. Он не годится - суммирует одинаковые импульсы до окончания проверки сработавших бит ExtC. Заменил на OR. Все заработало как надо. Посмотрел Ваши остальные файлы. Так у Вас тоже через OR сделано. Вот переделанный файл. Кстати, так и не услышал ответа на вопрос, что все-таки лучше: меньшее количество ФБ и большее потребление ОЗУ, ПЗУ или большее количество ФБ и меньшее потребление ОЗУ, ПЗУ. В посте #75 два файла я специально выложил. Посмотрите в них потребление ресурсов. Получается 24 триггера жрут меньше чем 2 RAMPа.
    Замечательно, хоть что-то начинает проясняться! Тогда запишем золотыми буквами, что детекторы переднего фронта Вам не нужны, если использовать макрос SR24 в данный момент! Тогда ваши 24 триггера с лихвой заменят два элемента, целочисленный SEL и OR, вот и сравнивайте их с 24 триггерами, что Вы всё пытаетесь мне какую-то лабуду преподнести, давайте лучше по делу, в конце концов, это же Вам, а не мне нужно! Ну и странно что Вы только что посмотрели, как же Вы пишите ответы не смотря, что Вам прислали?! Как говорится, лучше поздно, чем никогда!
    По вопросу что лучше: https://www.youtube.com/watch?v=glQ32H-4gdw
    Последний раз редактировалось Сергей0308; 15.02.2020 в 21:01.
    Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
    справиться с проблемами, либо это не твои проблемы.

  10. #80

    По умолчанию

    Вы, что между строк читаете? Я вообще не понимаю. Все началось с темы "ПР200". Вы там посмотрели первый файл ркс_дискр_24_1 и сказали, что все можно упростить. Причем в том файле уже был макрос только на ср-триггерах без ртриг. Я перешел по ссылке которую Вы указали. Далее обсуждали здесь. Я открыл последний файл из #72 этой темы. Вы пишете, что я нерационально что-то там использую, лишние 24 элемента и т.д. Смотрю, что после "оптимизации" на рампах потребление переменных, ЭСППЗУ, ПЗУ, ОЗУ увеличилось. Не так что ли?
    В #78 уже последний вариант без триггеров, рампов и прочего.
    Все Ваши файлы сразу не посмотрел, было уже очень поздно. А сегодня и сам с сел и ор сделал.

    И, да, очень смешное видео. Очень помогло.
    Последний раз редактировалось stanislau; 15.02.2020 в 22:38.

Страница 8 из 13 ПерваяПервая ... 678910 ... ПоследняяПоследняя

Похожие темы

  1. Диспетчеризация аварий по GSM
    от Ololo в разделе Подбор Оборудования
    Ответов: 2
    Последнее сообщение: 27.06.2018, 09:47
  2. Список аварий с квитированием на дисплее ПР200
    от djon1 в разделе Среда программирования OWEN Logic
    Ответов: 8
    Последнее сообщение: 02.01.2018, 16:43
  3. Архив аварий
    от Vasyandra в разделе СПК1хх
    Ответов: 9
    Последнее сообщение: 04.11.2016, 11:15
  4. Конфигуратор аварий
    от hells1ng в разделе ПЛК3хх
    Ответов: 5
    Последнее сообщение: 30.10.2015, 10:47
  5. Журнал аварий-пчв
    от taruska в разделе Эксплуатация
    Ответов: 2
    Последнее сообщение: 08.09.2011, 15:16

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •