Я же не сказал что ваш макрос плохой, я сказал что он избыточен для данной задачи, как говорится, из пушки по ...Цитата:
Сообщение от melky
Вид для печати
Я же не сказал что ваш макрос плохой, я сказал что он избыточен для данной задачи, как говорится, из пушки по ...Цитата:
Сообщение от melky
Василий, согласен, что несбрасываемый счетчик можно было бы и заменить, но как сказал выше, иногда (даже сейчас там есть ошибка, которую некогда исправить) нахожу ошибки и надо перешить ПР, сохранив время наработки. Ваш макрос на это не способен.
rovki вы о чем ? я просто говорю, что когда говорим об оптимизации, не стоит забывать о функционале, если я применил именно это, то вероятно была причина и не стоит урезать функционал не глядя. Попробуйте оптимизировать макрос при сохранении функционала, я вам памятник воздвигну :)
Я точно так же оптимизировал макрос AI - iChange так как его вариант был избыточен. А когда починят значение сетевых переменных по умолчанию, так вообще уберу, так как и сами макросы станут избыточны.
не один раз прогонял комбинации бит на входах, так и не понял в чем функциональный смысл второго ORЦитата:
Сообщение от melky
capzap я ж выше писал Василию, геныч поменяли на скорую руку, второй датчик напряжения до автомата генератора еще не подключили, вот и вкорячил ИЛИ, чтобы схема сейчас работала.
Кстати Василию +, благодаря ему еще одну ошибку нашел :) надо будет поправить.
всёравно не пойму, входов же свободных нет, какой второй генератор?
capzap сейчас посмотрел, не понял про какую часть схемы вы говорите ?
Если это про входа "Напряжение до QF" и "Напряжение после" то об этом и говорю, я ставлю два датчика наличия напряжения (паяю) так как на автоматах генераторов нет возможности установить допконтакт состояния. Да и в любом случае надо знать, что генератор именно запустился, так проще...
Одновременно видишь напругу и состояние автомата
про то место на которое акцентировал внимание Василий, про iChange кстати тоже, не возможно понять назначение, если смотреть внутренности макроса, может AI был прав со своей схемой, как вы там говорите:"вероятно была причина и не стоит урезать функционал не глядя"
Теперь будем обсуждать макросы от melky ???
Вы же вроде для себя закрыли тему.Цитата:
Сообщение от rovki
А по поводу обсуждения, это как в рекламе на ТНТ, люди же старались, выкладывали, почему бы не по обсуждать. Тем более, все как Вы говорите, если всё стадо подобных макросов собрать в один макрос, чтоб получить резервацию однотипных юнитов, то главная схема сократится значительно
Разумеется. Хоть кто-то выкладывает программы со словами "вот на этой программе ОЛ тормозит".Цитата:
Сообщение от rovki
Да, предыдущие замеры показали, что при большом количестве элементов на экране ОЛ тормозит.
Но это не означает, что "большое количество элементов" это единственный случай, когда ОЛ тормозит.
Вполне возможно, есть другие причины по которым ОЛ тормозит, и в этом плане обсуждать разнообразные тормозящие проекты это правильно.
capzap у AI макрос имеет приоритет по входу, а как писал выше, эти макросы временные до починки косяка разработчиков ОЛ. Назначение простое, активировать значение сетевой переменной по умолчанию при прошивке ПР (полгода уже чинят, если не больше, никак не дочинят)
на счет лишнего ИЛИ уже объяснил, временное решение, пока на место датчик напряжения не воткну и минимум изменений программы, просто обманка.
По крайней мере народ наблюдательный :)...
Пощупал макрос Василия, неплох, но чтобы обнулить одно значение в счетчике или записать определенное значение, например минуты, придется использовать макросы UnixTime и оперировать кучей переменных. Опять же, применительно ко времени, а если значения не временные ? выполнять еще кучку расчетов.
Сам макрос маленький, но обвязка будет ого-го, что еще добавит тормозов. При применении для чистого сброса вполне отличный. Кстати что произойдет если ему максимум времени задать и он перешагнет через него, обнулится ?
не видел первоначальный макрос, но по моему это у Вас имеет значение приоритет, а не установить на выходе то значение которое изменилось на входах последним на текущий момент. Инициализацию от сетевой переменной, я бы делал по другому, еслиб стояла такая задача, без оглядки на какие то потенциальные косяки разработчиковЦитата:
AI макрос имеет приоритет по входу
Вы серьезно считаете, что внятно всё объяснили, здесь так же бы была уместна новость, что Вы без билета в автобусе проехали, содержательной информации нольЦитата:
пока на место датчик напряжения не воткну
capzap еще раз - вход 2 и 3 получают дискретные сигналы от датчиков напряжения, установленные ДО и ПОСЛЕ автомата защиты генератора, отлавливают запуск генератора а так же что автомат не был отключен, или был отключен по перегрузке. На данный момент один датчик напряжения не установлен, сделана обманка при помощи ИЛИ. Что тут непонятного ?
если приоритет и есть, то только при прошивке ПР, не задавался этим вопросом, при изменении переменной с любой стороны, хоть с экрана, хоть по сети, переменная меняется везде.
Приходится оглядываться на косяки, так как на ПР114 и версии ОЛ .51 все работает без этого огорода. Потом что-то сломали либо в ОЛ либо в прошивке ПР и починить не могут уже более полугода.
это ясно из описания на схеме, можно было не повторятьЦитата:
вход 2 и 3 получают дискретные сигналы от датчиков напряжения, установленные ДО и ПОСЛЕ автомата защиты генератора, отлавливают запуск генератора а так же что автомат не был отключен, или был отключен по перегрузке
какой датчик I2 или I3? Я выложил рисунок, где выходы обоих элементов сравниваются между собой и если будет разница, выход XOR включится, из двух физических входов может быть только четыре комбинации, если один датчик не используется то тогда вообще две, я их не однократно посылал на собранную схему и ни разу конечный выход не "загорелся", отсюда делаю вывод что второй OR лишний, даже если его назвать обманкойЦитата:
На данный момент один датчик напряжения не установлен,
Блин, я сразу и сказал, что он лишний, так как на вход I2 сейчас тупо ничего не приходит, даже когда это необходимо, нет датчика, потом он доустановится и уберется один из программы
Одного не пойму, откуда вы выкопали XOR ?
так он лишний и с двумя датчиками и с одним датчиком. Повторяю, выход XOR показал бы(еслиб оно было) различие выходов первого и второго элемента OR, но их нет, потому что второй элемент повторяет работу первого, он лишний всегда
Я понял о чем вы, на ТОН идет сигнал ИЛИ от двух входов, где достаточно было снять например только с I2. Но кучка сигналов с I2 идет совершенно на другие элементы, где I3 не нужен и может даже вреден.
з.ы. программу выкладывал показать тормоза больше, чем для разбора полетов. Все равно она будет перерабатываться, когда руки дойдут.
Ей лет 5 наверное, вернее она до этого состояния лет за 5 обросла, наверняка там есть не только это лишнее :)
А какая же тогда у вас получится программа для вентиляции и кондиционирования кинотеатра с восемью кинозалами?Цитата:
Сообщение от Irgy
Мы с Вами в процессе хитроумных рассуждений ранее уже решили, что проблема тормозов ОЛ кроется во мне лично, какая теперь разница какая у меня на что получится программа?! :) А если по делу, кода у меня написано ровно столько, сколько нужно на весь возложенный в моем проекте на ПР функционал, и, уж поверьте на слово, у меня хватает опыта самостоятельно оценить насколько оптимален мой код и можно ли сделать его короче или нет.Цитата:
Сообщение от Василий Кашуба
Тут проблема в том, что и ПР200 и ОЛ = просто идеальны и любые изменения в них способны их только ухудшить. Это я кратко изложил аксиому, которой придерживается некоторые активные завсегдатаи данного форума. Поэтому если вы пишете программу на ОЛ, а ОЛ у вас тормозит, но при этом ОЛ идеален, то сами понимаете кто виноват? Осталось просто найти причину по которой вы виноваты и спокойствие восстановится.Цитата:
Сообщение от Irgy
да, я уже все это понял, осознал и смиренно пошел дальше кодить :)Цитата:
Сообщение от starmos
Имхо, с чем бы ни были связаны тормоза, их быть не должно.... и не надо списывать на бесплатность продукта, ОЛ без ПР никому не нужен.
Полностью согласен. Если задуматься, на сайте заявлены характеристики прибора и цена, потребитель покупает и сталкивается с практической невозможностью использовать более 30-40% мощностей прибора из-за тормознутости программки для этого прибора, и при этом альтернативной программки нет.Цитата:
Сообщение от melky
Слышал, что в ОЛ1.9 постараются решить проблему, остается ждать и надеяться :)
Ну конечно, вы самые крутые генераторы программных кодов и вам совершенно не нужны ни чьи советы. ВЫ сами с усами. :)Цитата:
Сообщение от starmos
Крепись, брателло. ;) А про сам ПР200 что можете сказать ? По моему хороший прибор получился.Цитата:
Сообщение от Irgy
Вольд почти :) не хватает переменных для нумерации экранов и системных переменных для клавиш.
Системных переменных для корректировки времени.
Сам ПР200 очень нравится, хороший набор входов/выходов, экран, 2 порта RS485, теперь еще модуль расширения - и все это по вполне приятной вменяемой цене. Да, чего-то по мелочи не хватает, но продукт и линейку развивают и наверняка будут развивать и дальше.Цитата:
Сообщение от Вольд
главное чтобы с ним ничего не случилось как с Модусом.....
Это недостатки ОЛ, а не ПР200.Цитата:
Сообщение от melky
Есть у меня в обслуживание одна КНС. 5 шкафов автоматики . 4 линии фильтрации и обработки. Насосы 2 . Там у меня и Ручной режим и Авто( кнопки лампочки), поплавки, реле протока 4, защита и пуск насосов, контроль работы бактерицидных ламп, ротация ламп и ротация насосов. Автор темы сравнима с вашим проектом? Как вы думаете кто всем этим управляет ? Уверен на 100000% не угадаете. Там стоит простое реле меллер И БЕЗ БЛОКОВ РАСШИРЕНИЯ. Кто не верит могу выложить фото всей системы и "внутрянки" шкафа. Реле рулит работой 4 контроллеров. Получает сигал работа/авария и простым выходом реле сообщает в СКАДУ что есть авария.
Грамотный анализ задачи и правильный подбор оборудования залог успешной работы проекта. Купив прибор за 6000 глупо ждать что сможет работать как прибор за 60000. Проще и быстрее разделить задачи и сделать 2-4 маленьких проекта 300*400 чем тратить время на полотно 400*2400.
Может ты и проект этот сам сделал ?
По объему сравнимо. Но мне принципиально нужно вложить мою логику в один бюджетный прибор, про то, как сделать проще и быстрее, мне известно, я не новичок в том, что делаю. Опять же, еще раз - к прибору претензий нет, прибор шикарен, претензии к среде разработки, которая не дает использовать прибор по максимуму. И, если честно, надоело уже на эту тему дискутироватьЦитата:
Сообщение от игорь68
Ну тут-то конечно - я например все осознал и усовестился. "Одно реле управляет..." - капец, а я глупый конечно. Потому что не понимаю - зачем там это реле, да и еще и без блоков расширения (еще бы там были и блоки). Потому что мне кажется что УПРАВЛЯЮТ там контроллеры, а реле просто СИГНАЛИЗИРЕУТ в Скаду (по крайней мере так следует из описания). И это, по крайней мере по моему мнению, есть странно. Потому что сейчас даже дохлый контроллер, даже китайская дешевка, имеет на борту интерфейс 485, что позволяет подключить все эти 4 контроллера в Скаду и получать там состояние и значения необходимых переменных, а не только сигналы "работа/авария". Да еще и сэкономится вышеупомянутое реле.Цитата:
Сообщение от игорь68
Все вот эти песни - "вы хотите за 6000 получить то же что и за 60000" выглядят разумными только на первый взгляд, потому что это как минимум неоднозначно. Да конечно, за 60000 можно выпустить ОЧЕНЬ крутой контроллер. Но если в общем барахло или обычный по возможностям прибор стоит почему-то 60000, то прибивать возможности другого неплохого прибора, только потому что он стоит 6000 - это выглядит странным. Например контроллеры Данфосс ECL - неплохи вполне, но просят за них совершенно неадекватные деньги, такое впечатление что продавцы рехнулись. Однако на том же ПР200 вполне можно заменить некоторые из ECL200/300. Так не дадим же людям такой возможности, потому что ПР200 стоит 6000, а ECL - 60000?
Если быстродействия процессора хватает, объема памяти хватает и числа ввода-вывода хватает, то контроллер подходит для реализации задачи, сколько бы он ни стоил. И если где-то что-то тормозит при разработке, или нельзя использовать все ресурсы полностью, то это вина исключительно производителя контроллера.
Уже писали же -делайте хоть какие сложные (для вас) проекты ,но не забывайте про шапку Сенькину и маленьнькие хитрости при использовании ОЛ(родимые пятна) ,что бы не зависать на века ,учитывайте так сказать "характер"(особенности ОЛ), пусть даже внешне одинаковых субьектов(ПР-ПЛК).
Тема закончилась тем, что чтобы не тормозило, достаточно разбивать проект на макросы, или я какой-то еще источник лагов пропустил?
Чета последние 4 страницы идет какое-то вялое ворчание без обсуждения конкретики)
Да нужно разбивать на макросы ,в очень сложных проектах их число должно быть не менее чем корень из двух от общего числа ФБ ,что бы максимально загрузить ПР и ОЛ не тормозило .Цитата:
Сообщение от anthrwpos
Ни хрена не понял, от чего корень?Цитата:
Сообщение от rovki
Ну это для оптимальности(теоретически) ,но не обязательно .Если у вас 1000 элеметов(фб) -это минимум 1500связей ,то делайте 30-33 макроса ....Для средней сложности проекта до 100 элементов можно делать любое удобное количество макросов или не делать их вовсе -тормозов не будет ,но читаемость ни какая .Иными словами ,если до ста не тормозит ,а у вас 500 элементов ,то делайте минимум 5 макросов ,а лучше 20 ,что бы читать можно было без напряга и обилия связей на одной станице (схемы или макроса).И думать об оптимальном разбиении схемы на макросы нужно в самом начале, если чувствуешь что потребуется несколько сотен элементов .
Вы не много не правы. 4 Контроллера что там стоя это контроллеры что контролируют работу бактерицидных ламп. Каждый свою линию и свой лампы. Он же считает время наработки. Он же видит что есть проток и нужно лампы включить. В реле он передает что я РАБОТАЮ или У МЕНЯ АВАРИЯ. При этом РЕЛЕ решает кто работает а кто курит. А о том что есть скада контроллер ламп даже не знает. По поводу тормозов. AMDА4.quad-core/ win8.1 озу 16 гигов проблем нет.
Лучше вместо корня делать логарифм)
Основной лист должен содержать до ~30 элементов. Если их становится сильно за 40, делить на макросы, каждый из которых в свою очередь должен содержать до ~30 элементов иначе делить на подмакросы.
Еще лучше, чтобы это деление совпадало с функциональным назначением данного участка программы, тогда программа становится не только красивой, но и легко обслуживаемой.