PDA

Просмотр полной версии : Тормоза Owen Logic



Irgy
24.04.2017, 20:55
Всем привет!

Такая проблема: при относительно большом проекте Owen Logic начинает подтупливать от каждого действия: соеденить 2 элемента - ждем секунды 2-3, выделить расколько объектов - ждем секунд 10, передвинуть 5-6 объектов в другое место - ждем секунд 10, и т.д., думаю идея понятна. А если уж действие посерьезнее нужно, например, треть схемы выделить и подвинуть, то это ваще полминуты только выделяться будет, а потом еще полминуты перетаскиваться. Пугает перспектива увеличивать дальше программу, т.к. требуемый функционал еще не достигнут и надо еще немного покодить, а времени это начинает занимать гораздо больше, чем хотелось бы.

Версия среды 1.8.107.9617, проект для ПР200, размер поля 400х2400, объем программы ФБ 0%, перем. 2%, ЭСППЗУ 45%, ПЗУ 28%, ОЗУ 37%.

Собственно вопрос к разработчикам: есть ли какие-либо способы ускорить работу Owen Logic, планируется ли оптимизация? Пробовал в диспетчере задач давать процессу высокий приоритет - не помогло. Комп далеко не дряблый, Corei7 8Гб ОЗУ Win8.1. Как вариант может поможет, к примеру, внедрение возможности разбиения всей программы на программные блоки (не макросы)? Или внедрение возможности написания части кода на C?

rovki
24.04.2017, 21:02
Как пить дать , не видя проекта ,предположу что вы используете в качестве связей внутренние переменные .

Irgy
24.04.2017, 21:16
Как пить дать , не видя проекта ,предположу что вы используете в качестве связей внутренние переменные .

В таком большом проекте естественно не все связи идут напрямую, но нет ни одной переменной, которая была бы создана только ради связи между дальними частями схемы - все переменные так или иначе важны для алгоритмов работы и используются еще и для вывода по modbus. И да, сетевых переменных тоже много, почти по максимуму, и тоже все используются по делу.

Василий Кашуба
24.04.2017, 21:34
Всем привет! ... Версия среды 1.8.107.9617, проект для ПР200, размер поля 400х2400, объем программы ФБ 0%, перем. 2%, ЭСППЗУ 45%, ПЗУ 28%, ОЗУ 37%...
Интересно, что у вас за задача такая, что для её описания нужно такое поле и как вы говорите, что нужно ещё дополнить.

Сергей0308
24.04.2017, 21:41
Делал макрос, даже открывается несколько минут, ни одной внутренней переменной нет, вообще никаких переменных не создавал, кроме тех, что имеются по умолчанию, капзап успел пообедать и матом обложить, пока макрос открывался, так что переменные здесь(в моём случае) не при чём, там много экземпляров одного макроса, в свойствах задаются константы для каждого, много времени ждёшь при их вводе(изменении), одну ввёл, пока станет доступно изменение другой покурить можно!
Так что грешу на международную напряжённость или погода была неблагоприятная(нелётная)!

Irgy
24.04.2017, 21:43
Интересно, что у вас за задача такая, что для её описания нужно такое поле и как вы говорите, что нужно ещё дополнить.

особого космоса там нет, просто много всего разного :)

Василий Кашуба
24.04.2017, 21:58
особого космоса там нет, просто много всего разного :)
А всё таки. У меня самый большой холст 300*400, и то я считаю, что это большой холст. Может вашу задачу можно как то проще решить? Вы напишите подробное ТЗ (программу не прошу, так как в чужом разбираться, больше времени потеряешь), а мы вам может чем то сможем помочь.

Irgy
24.04.2017, 22:17
А всё таки. У меня самый большой холст 300*400, и то я считаю, что это большой холст. Может вашу задачу можно как то проще решить? Вы напишите подробное ТЗ (программу не прошу, так как в чужом разбираться, больше времени потеряешь), а мы вам может чем то сможем помочь.

Благодарю за отзывчивость и предложение помощи, но я воздержусь :) Задача сильно разноплановая, долго описывать, да и какая-бы она ни была, тема не об этом. У меня вопрос только к разработчикам - стоит ли ждать в обозримом будущем оптимизации работы среды или ускоряющих разработку нововведений.

rovki
24.04.2017, 22:24
Без схемы (для разработчиков) ждать не стоит .

Василий Кашуба
24.04.2017, 22:30
Благодарю за отзывчивость и предложение помощи, но я воздержусь :) Задача сильно разноплановая, долго описывать, да и какая-бы она ни была, тема не об этом. У меня вопрос только к разработчикам - стоит ли ждать в обозримом будущем оптимизации работы среды или ускоряющих разработку нововведений.
Я же намекнул вам, что нужно оптимизировать схему, и мы вам в этом поможем.

melky
24.04.2017, 22:33
Не привязывайтесь к схеме, ОЛ тормозная программа это неоспоримый факт. Как его не оптимизировали, а толком ума дать не могут.

Irgy
24.04.2017, 22:38
Я же намекнул вам, что нужно оптимизировать схему, и мы вам в этом поможем.

Схема очень большая, и правда долго будете разбираться, но опять же - спасибо за отзывчивость :) Код уже оптимизировал где можно, толку от этого особого нет.

Василий Кашуба
24.04.2017, 22:45
Не привязывайтесь к схеме, ОЛ тормозная программа это неоспоримый факт. Как его не оптимизировали, а толком ума дать не могут.
"Это вы просто готовить не умеете". :)

rovki
24.04.2017, 22:46
Схема очень большая, и правда долго будете разбираться, но опять же - спасибо за отзывчивость :) Код уже оптимизировал где можно, толку от этого особого нет.
Ну так дайте схему ,без описания ,что бы оценить уровень сложности

Irgy
24.04.2017, 23:11
Ну так дайте схему ,без описания ,что бы оценить уровень сложности

тема была создана не для оценки уровня сложности моей схемы, я просто хотел донести до разработчиков информацию о проблеме

Василий Кашуба
24.04.2017, 23:23
тема была создана не для оценки уровня сложности моей схемы, я просто хотел донести до разработчиков информацию о проблеме
Значит проблема в вас.

Irgy
24.04.2017, 23:28
Значит проблема в вас.

Да, точно, теперь всё встало на свои места. Тему можно закрывать, всем спасибо!

rovki
24.04.2017, 23:30
Если просто проинформировать разработчика ,то он знает что такое бывает ,а если хотите что бы разработчик нашел решение ,то без проекта не реально.Потому что могут быть много причин приводящих к такому эффекту .
А то ни схем ,ни да же скринов и хотите что бы разработчики медитировали . Если уж на форум ,а не в тех.поддержку значит и на пользователей рассчитывали ...

Алексей Геннадьевич
25.04.2017, 07:53
Всем привет!

Версия среды 1.8.107.9617, проект для ПР200, размер поля 400х2400, объем программы ФБ 0%, перем. 2%, ЭСППЗУ 45%, ПЗУ 28%, ОЗУ 37%.
Выкладывайте программу, без неё-пустой разговор...


Собственно вопрос к разработчикам: есть ли какие-либо способы ускорить работу Owen Logic, планируется ли оптимизация? Пробовал в диспетчере задач давать процессу высокий приоритет - не помогло. Комп далеко не дряблый, Corei7 8Гб ОЗУ Win8.1. Как вариант может поможет, к примеру, внедрение возможности разбиения всей программы на программные блоки (не макросы)? Или внедрение возможности написания части кода на C?
Вам сюда.
http://www.owen.ru/forum/showthread.php?t=23754

тема была создана не для оценки уровня сложности моей схемы, я просто хотел донести до разработчиков информацию о проблеме
Проблема известная.
Частично решается макросами.
P.S.
Если единичная разработка, то проще ПЛК взять, меньше времени на "медитацию" угробите.
А если серийное изделие, то имеет смысл.

rovki
25.04.2017, 10:21
Irgy, скорее всего ПР200 не тянет вашу задачу.
С чего такие выводы? ПР тянет ,не тянет ОЛ в его руках (программиста).;)

Вольд
25.04.2017, 10:29
У автора ПК с Corei7 и такие жуткие тормоза при написании проекта. Может ОЛ криво встал при установке. Надо автору попробовать запустить проект на другом ПК.

rovki
25.04.2017, 10:35
Что бы не гадать нужен проект ,об этом и было сказано .

melky
25.04.2017, 10:36
У меня программа в ПР выполняется 5 мс, не знаю, насколько это большой проект, но редактировать его можно и достаточно без тормозов на i5, но реально должно работать быстрее.
У ОЛ явное недоразумение с компиляцией. Скорее всего потому, что оно происходит на лету даже при простом перемещении линии (выравнивании ее например) на поле, а не при переносе на другой вход другого блока...

Irgy
25.04.2017, 10:43
Что бы не гадать нужен проект ,об этом и было сказано .

Да не дам я в своем проекте ковыряться, вот заладили... Типа сядете, изучите по-быстрому мою схему, найдете 2-3-5 мест неоптимальных , ткнете носом, я допустим послушаю и исправлю - и что, ОЛ резко начнет бодрее работать с оставшимися 90-95% объектов на рабочей области 400*2400? Да не смешите! И ОЛ не тянет не только в моих руках. Или вы хотите сказать что Ваш аналогичный по величине рабочей области и занимаемым ресурсам супер оптимизированный проект не заставляет тормозить ОЛ?

Irgy
25.04.2017, 10:46
У ОЛ явное недоразумение с компиляцией. Скорее всего потому, что оно происходит на лету даже при простом перемещении линии (выравнивании ее например) на поле, а не при переносе на другой вход другого блока...

Полностью согласен, по ощущениям и правда происходит полная перекомпиляция после каждого действия

rovki
25.04.2017, 11:15
Да не дам я в своем проекте ковыряться, вот заладили... Типа сядете, изучите по-быстрому мою схему, найдете 2-3-5 мест неоптимальных , ткнете носом, я допустим послушаю и исправлю - и что, ОЛ резко начнет бодрее работать с оставшимися 90-95% объектов на рабочей области 400*2400? Да не смешите! И ОЛ не тянет не только в моих руках. Или вы хотите сказать что Ваш аналогичный по величине рабочей области и занимаемым ресурсам супер оптимизированный проект не заставляет тормозить ОЛ?
Спрошу по другому -сколько у вас элементов и ФБ?

Irgy
25.04.2017, 11:26
Спрошу по другому -сколько у вас элементов и ФБ?

из ФБ примерно 10 триггеров, 25 таймеров, макросы разные из репозитория и свои - штук 50 (примерно, не считал), в макросах ФБ преимущественно нет, остальное - логические элементы (И, ИЛИ, функции, процентов 20% с плавающей точкой) - много. А что Вам дает эта информация?

Вольд
25.04.2017, 11:29
из ФБ примерно 10 триггеров, 25 таймеров, макросы разные из репозитория и свои - штук 50 (примерно, не считал), в макросах ФБ преимущественно нет, остальное - логические элементы (И, ИЛИ, функции, процентов 20% с плавающей точкой) - много. А что Вам дает эта информация?

Программа получилась не хилых размеров. Интересно какое будет время цикла у ПР200.

rovki
25.04.2017, 11:40
из ФБ примерно 10 триггеров, 25 таймеров, макросы разные из репозитория и свои - штук 50 (примерно, не считал), в макросах ФБ преимущественно нет, остальное - логические элементы (И, ИЛИ, функции, процентов 20% с плавающей точкой) - много. А что Вам дает эта информация?Про элементы не понял .Около 200?А из какой области задача ,что делает в двух словах, чем управляет ?

Irgy
25.04.2017, 11:44
Про элементы не понял .Около 200?А из какой области задача ,что делает в двух словах, чем управляет ?

Элементов не считал сколько, с логическими функциями может и 200, может побольше. В общих чертах - небольшое очистное сооружение, просто с функционалом посложнее чем просто вкл/выкл насос по уставке. Да, опять же, не столь это важно

Irgy
25.04.2017, 11:49
Программа получилась не хилых размеров. Интересно какое будет время цикла у ПР200.

Посмотрел, 15мс показывает

Вольд
25.04.2017, 11:58
Посмотрел, 15мс показывает

Редактор ОЛ скорее всего дубово сделан. А на другом ПК пробовали проект редактировать ? Может у вас кроме ОЛ куча других приложений на ПК запущено и не хватает ресурсов. Надо отключиться от интернета, закрыть все приложения кроме ОЛ.

Irgy
25.04.2017, 12:02
Редактор ОЛ скорее всего дубовый получился. А на другом ПК пробовали проект редактировать ? Может у вас кроме ОЛ куча других приложений на ПК запущено.

пробовал, без разницы

Серёга Букашкин
25.04.2017, 12:05
может и 200, может побольше.
Крепитесь, ничего не улучшат. Я уже на эту тему шумел, толку нет. Оптимизировать своими силами нельзя, даже не пытайтесь. Мне кажется что ОЛ был задуман в принципе на задачи попроще, а в ПР200 приходит аппетит, но ОЛ придуман раньше и на это не заточен. Смиритесь. Немного поможет если побольше блоков задвигать в макросы, но не в разы конечно.

Irgy
25.04.2017, 12:11
Крепитесь, ничего не улучшат. Я уже на эту тему шумел, толку нет. Оптимизировать своими силами нельзя, даже не пытайтесь. Мне кажется что ОЛ был задуман в принципе на задачи попроще, а в ПР200 приходит аппетит, но ОЛ придуман раньше и на это не заточен. Смиритесь.

да, я уже понял

Владимир Ситников
25.04.2017, 12:12
Редактор ОЛ скорее всего дубовый получился. А на другом ПК пробовали проект редактировать ? Может у вас кроме ОЛ куча других приложений на ПК запущено и не хватает ресурсов. Надо отключиться от интернета, закрыть все приложения кроме ОЛ.

Скорее всего, беда в том, что на каждый чих происходит перекомпиляция проекта и при этом ОЛ не продолжает работать пока компиляция не завершится.

По-хорошему, компиляцию нужно выполнять в фоне и не затормаживать основную работу.

rovki
25.04.2017, 12:13
Скорее соглашусь .Выход - разбить задачу на 2 ПР (2 проекта) или использовать ПЛК. Ведать не свойственные для ПР задачи ,коль так сложно получается .

Серёга Букашкин
25.04.2017, 12:17
не свойственные для ПР задачи ,коль так сложно получается .
Задача станет несвойственной если загрузка ресурсов ПР200 достигает 100%. А у нас уже с 30% тормозит сильно.

rovki
25.04.2017, 12:18
Рассматривать ПР отдельно от ОЛ нет смысла .Превращать реле в ЭВМ не самая лучшая задача.

Irgy
25.04.2017, 12:21
Задача станет несвойственной если загрузка ресурсов ПР200 достигает 100%. А у нас уже с 30% тормозит сильно.

Полностью согласен

Irgy
25.04.2017, 12:23
Скорее всего, беда в том, что на каждый чих происходит перекомпиляция проекта и при этом ОЛ не продолжает работать пока компиляция не завершится.

По-хорошему, компиляцию нужно выполнять в фоне и не затормаживать основную работу.

Тут тоже - полность согласен. Может проблема "вызреет" и ОЛ все же оптимизируют со временем

Вольд
25.04.2017, 12:25
Рассматривать ПР отдельно от ОЛ нет смысла .Превращать реле в ЭВМ не самая лучшая задача.

Значит ОЛ - это анахронизм. ;)

Вольд
25.04.2017, 12:26
Тут тоже - полность согласен. Может проблема "вызреет" и ОЛ все же оптимизируют со временем

ОЛ уже много лет оптимизируют, но толку мало. Нужна новая концепция, нужны новые не зашоренные разработчики.

Перемен, мы ждем перемен. ;)

Серёга Букашкин
25.04.2017, 12:29
Посмотрел, 15мс показывает
Время цикла тут вообще ни при чем, оно здорово растет от плавающей точки. При работе только с битами и целочисленными даже на крутой сложности выходит не больше 10мс. Но ОЛ тормозит безбожно. Я просил чтобы в ОЛ был не один холст, а больше, типа добавления большого макроса с связями через переменные. Ведь при рисовании макроса не тормозит и при малых количествах внешних связей это хороший способ и сейчас.

rovki
25.04.2017, 12:31
Я всегда ПР рассматривал в совокупности с ОЛ ,со всеми его ограничениями .Раньше была актуальна пословица -из пушки по воробьям ,когда приходилось уговаривать решать простые задачи на ПР ,теперь нужна другая пословица -по Сеньке шапка. Надеяться можно и нужно на лучшее ,но работать нужно сейчас с учетом реалий.Это то же одно из обязанностей разработчика - правильно выбрать средства по конкретную задачу.

Вольд
25.04.2017, 12:35
ПР200 - замечательный прибор, ОЛ - посредственная вещь. Но в одну телегу впрячь не можно коня и трепетную лань. ;)

Для ПР110 и ПР114 ОЛ пойдет, но для ПР200 нужна новая среда. Чем раньше поймут это в фирме ОВЕН тем лучше будет для всех.

rovki
25.04.2017, 12:40
ПР200 - замечательный прибор, ОЛ - посредственная вещь. Но в одну телегу впрячь не можно коня и трепетную лань. ;)
Другими словами- общая скорость движения будет меньше наименьшей ,вот ее и надо брать в расчет ..
Мне процесс работы на ОЛ нравиться ,но я не буду требовать что бы он обеспечивал работу с ШД и энкодерами.Сам МК контроллер может и позволил бы ,но ОЛ заточена под другой круг задач.

Серёга Букашкин
25.04.2017, 12:44
ПР200 - замечательный прибор, ОЛ - посредственная вещь. ;)
Теперь уж получив ПР200 всё равно будем как ёжики, которые едят кактус.

rovki
25.04.2017, 12:52
Для ПР110 и ПР114 ОЛ пойдет, но для ПР200 нужна новая среда. Чем раньше поймут это в фирме ОВЕН тем лучше будет для всех..
Даже если поймут ,то времени и средств не хватает на более мелкие задачи (нужные) .Я в начале был то же сторонник разных ОЛ .Много сил ушло на поддержание всех ПР и проектов в одном ОЛ ,сковали себя по рукам и ногам .Универсальность вещь хорошая ,но все имеет цену....Завтра появиться ПР300 ,например и опять несколько лет на отладку...

melky
25.04.2017, 13:39
rovki так речь не о том, какие задачи можно решать а какие нет на ОЛ, а о том, чтобы по своим задачам сам ОЛ не тормозил....

rovki
25.04.2017, 14:01
Вы сами то поняли что сказали- со своими задачами сам ОЛ не тормозил .??? А задачи он в магазине покупает ?

Вольд
25.04.2017, 16:09
.
Даже если поймут ,то времени и средств не хватает на более мелкие задачи (нужные) .Я в начале был то же сторонник разных ОЛ .Много сил ушло на поддержание всех ПР и проектов в одном ОЛ ,сковали себя по рукам и ногам .Универсальность вещь хорошая ,но все имеет цену....Завтра появиться ПР300 ,например и опять несколько лет на отладку...

А почему CoDeSys одна, а ПЛК, которые из под нее работают великое множество ? А потому, что чем прежде большое дело начинать надо мозгами хорошо пошевелить. Вот разработчики CoDeSys мозгами хорошо шевелят.

melky
25.04.2017, 16:42
rovki прекрасно понял о чем сказал. Если есть ПР200, ПР114 и т.д., которые поддерживает ОЛ, то забив все поле макросами и FBD, которые в состоянии вместить память этих приборов, то тормозов быть не должно, от слова СОВСЕМ... и плювать, сколько в итоге мс будет выполняться программа в ПР, процессор выполняет действия по шагам и его мощность Х, если он будет выполнять эту программу 50 мс, значит 50. Но это не значит, что ОЛ должен выполнять действия по 10 минут.

На лицо недоработка программистов продукта.

Кстати для разработчиков ОЛ, вроде когда-то они говорили, что ОЛ на С# написан, так вот (Int32)double оказывается не одно и то же, что Convert.ToInt32(double) по выходному значению от входного.
Куда писать, в Microsoft ?:)

Так что код в зубы и оптимизировать.

rovki
25.04.2017, 17:31
Фантастика .Значит время цикла ПР зависит от количества компонентов ,а время компилятора не должно зависеть от количества .Если меня не устраивает время цикла ПР (15мс ,а надо 1мс) ,я беру другой инструмент .А если транслятор тормозит 5сек для задач что требует футбольного поля даже при наличии макросов , то он не работает или плохой .А я думаю это родимое пятно ....от которого просто не избавится (чревато раком).

ASo
25.04.2017, 17:35
А не проще компилировать перед загрузкой или по кнопке? Как это сделано в КДС и всех других нормальных системах.
Или сила есть - ума не надо?

rovki
25.04.2017, 17:37
А почему CoDeSys одна, а ПЛК, которые из под нее работают великое множество ? А потому, что чем прежде большое дело начинать надо мозгами хорошо пошевелить. Вот разработчики CoDeSys мозгами хорошо шевелят.

Вы еще скажите что ОЛ должна поддерживать все виды ПР всех производителей (как кодесис) .На сколько я видел ,с ОЛ работает плотно 1 человек .

melky
25.04.2017, 17:40
Да уж, нам ваших не понять :).....

При редактировании линий на поле, не надо заниматься перекомпилированием на лету, если я не оторвал линию от входа или выхода, кстати насколько помню в ОЛ этого сделать нельзя.
А так поддерживаю, лучше компилирование сделать по кнопке, раз уж ума нет сделать иначе.

я не говорил что 5 мс это много или мало для ПР, я говорил о том, что при разницах в процессорах ПК и ПР эти 5 мс в ПР почему то превращаются в минуты на ПК а это уже явно странность.

rovki
25.04.2017, 17:41
А не проще компилировать перед загрузкой или по кнопке? Как это сделано в КДС и всех других нормальных системах.
Или сила есть - ума не надо?
Тут сказать не могу ,не специалист.НО чувствую что если можно было ,то сделали бы.В ОЛ как бы идет проверка каждого шага пользователя ,что бы потом не разгребать ситуацию с ошибками.А то на соединяют целочисленные выходы с дробными входами или еще чего.ОЛ гарантирует и исключает ошибки синтаксические .

melky
25.04.2017, 17:51
Так проверкой "синтаксических" ошибок только и должен заниматься ОЛ когда "рисуешь", потом компиляция - проверка алгоритмических ошибок с указанием где и как. и только потом запуск.
Сразу то нафига ?

Вот по поводу тормозов - простое выделение макроса с его переменными (сетевые и внутренние) - 2,22 сек с момента отпускания кнопки мыши после обводки до выделения макроса и захваченных элементов . Я еще не решил что с выделенным делать, перемещать или удалять, только выделил.

И чем больше выделяешь элементов, тем больше уходит времени.

Василий Кашуба
25.04.2017, 20:54
А я на 100% уверен, что программа составлена не оптимально и вся проблема в этом.

anthrwpos
25.04.2017, 20:57
У меня на работе на ноутбуке даже простые проекты лагают. Разрабатывать на нем что бы то ни было практически невозможно. Использую рабочий ноут только чтобы проекты заливать в контроллер на месте его установки. По 5 минут жду, пока проект откроется.
На стационарном компе 10-летней давности чуть лучше. Можно разрабатывать, но сделать связь например требует 3-5 секунд, причем торопиться нельзя, иначе связь "залипает" и приходится начинать всё заново - удалять компонент и добавлять его снова, соединяя всеми связями. По первому времени по 5 раз переустанавливал компоненты на поле.

Дома на ноуте Lenovo G770 летает всё что я когда либо делал.
Типичный мой проект выглядит примерно так:30793
Макросы внутри тоже совсем не простенькие.
Думается, на нормальном современном компутере можно будет работать на забитом поле 1000х1000 без особых проблем.

rovki
25.04.2017, 20:57
А я на 100% уверен, что программа составлена не оптимально и вся проблема в этом.
Мне то же так кажется ,что там воплощен программистский подход ,а лоджик этого не любит ;).

melky
25.04.2017, 21:14
афигеть, лоджик написан не программистами выходит ? :)

rovki
25.04.2017, 21:30
Я говорю о пользователях ,а не разработчиках инструмента .

starmos
26.04.2017, 07:10
Смешно. В соседней теме столько было разговоров про "ОЛ наше все" и "нам квадратиками удобнее", а тут выясняется что ОЛ = торможеное г... Повторюсь - в связке ПР200-ОЛ = проблема в ОЛ, он сильно ущемляет возможности ПР200, а теперь еще и возможности разработки оказывается. Вангую, что все разговоры об "оптимизации ОЛ" разговорами же и останутся, т.к. скорее всего в него изначально был заложен неверный подход к разработке пользовательских программ, который оправдывал себя на малых сложностях и сам проще реализовывался, а сейчас вылезли проблемы и они принципиально не решаемы. Тут точно тоже что и для С на ПР200 - сделать нельзя из-за самого подхода к построению ПО, как на ПР200 - подхода удобного и правильного, для своего времени, но морально устаревшего. Однако сделать уже ничего нельзя. И в том, и в другом случае, помог бы выпуск вариантов ПР200, без привязки к ОЛ - это дало бы свободу тем пользователям, кто в ней нуждается. А остальные привычно "ели бы кактус". В своем теперешнем состоянии, связка ПР200-ОЛ = данность, которая не может быть улучшена, без кардинальной переработки. Но это явно будет нескоро, т.к. у ОВЕН свой большой запас "кактусов". Поэтому, если ОЛ тормозит, значит вам нужен другой контроллер.

Алексей Геннадьевич
26.04.2017, 08:23
А почему CoDeSys одна, а ПЛК, которые из под нее работают великое множество ? А потому, что чем прежде большое дело начинать надо мозгами хорошо пошевелить. Вот разработчики CoDeSys мозгами хорошо шевелят.
Есть масштабируемые решения (Codesys) в которых введение нового компонента не требует титанических усилий.

А есть решения изначально задуманные как немасштабируемые, и прекрасно работающие на маленькой платформе. Но стоит попробовать на них сделать что-то более обьёмное, как начинаются проблемы.
Как-то уже предлагал переделать весь ОЛ с 0, а все старые программы - через компилятор прогонять.
Сейчас стараюсь не писать под ОЛ больших проектов - из-за тормозов нервы страдают.

SA104
26.04.2017, 08:24
Чисто из любопытства, можно ссылку на проект (часть проекта, если секретная разработка), который тормозит.
Просто у меня нет вышеописанного торможения, может я что-то не так делаю ?
А вообще правильнее проверять на железе , а не в эмуляторе - и результат достоверный и тормозить не будет.

melky
26.04.2017, 08:49
Так в том и фокус, что на железе с гораздо меньшей производительностью чем ПК программа не страдает тормозами и адекватна по быстродействию :)

SA104
26.04.2017, 09:27
Так в том и фокус, что на железе с гораздо меньшей производительностью чем ПК программа не страдает тормозами и адекватна по быстродействию :)
Так у меня и на ПК Лоджик не страдает тормозами. Хотя ноут десятилетней давности и винда XP.

Вольд
26.04.2017, 09:47
Так у меня и на ПК Лоджик не страдает тормозами. Хотя ноут десятилетней давности и винда XP.

У тебя проекты с гулькин нос, вот и не страдаешь. ;)

Вольд
26.04.2017, 09:49
Я думаю можно подвести черту и сделать такой вывод.

Для разработки больших проектов в ОЛ нужен суперкомпьютер. ;)

SA104
26.04.2017, 10:27
У тебя проекты с гулькин нос, вот и не страдаешь. ;)
А ты я вижу провидец. Портянки на экране, действительно не мой стиль.
А "большие" проекты не всегда сложные, а просто большие.

Владимир Ситников
26.04.2017, 10:49
А ты я вижу провидец. Портянки на экране, действительно не мой стиль.
А "большие" проекты не всегда сложные, а просто большие.

Да тут вообще провидцев набралось в теме. Реакции от ОВЕН не слышно.

Если проблема действительно в компиляции на каждый чих, то эта задержка будет зависеть только от общего количества элементов в схеме, а не от того, как они распределены (или не распределены) по макросам.
Советы в духе "надо макросы использовать и будет всё хорошо" это всё вилами по воде.

Нужно брать проблемный проект, открывать его в ОЛ, и профилировать это самое ОЛ.

Но, разумеется, ОЛ впереди планеты всей, ОЛ не тормозит, поэтому и нечего тратить время на анализ скорости работы ОЛ.

SA104
26.04.2017, 11:06
Я и просил скинуть "проблемный проект", дабы убедиться, что тормозит - ОЛ, проект или нечто третье.
Что касается ОЛ - для своих целей вполне рабочая лошадка, непритязательная и простая в обращении. )

Василий Кашуба
26.04.2017, 11:08
Где же его взять "проблемный" проект? У меня таких нет, все ведут себя адекватно.

Владимир Ситников
26.04.2017, 11:10
Я и просил скинуть "проблемный проект", дабы убедиться, что тормозит - ОЛ, проект или нечто третье.
Всё верно. Но есть разница, когда это просит ОВЕН и когда это делает неизвестнокто.



Что касается ОЛ - для своих целей вполне рабочая лошадка, непритязательная и простая в обращении. )
Тоже верно. Вас устраивает -- шикарно.

Но вот такими своими сообщениями вы не даёте раскачивать:

Так у меня и на ПК Лоджик не страдает тормозами. Хотя ноут десятилетней давности и винда XP.
Вас всё устраивает -- и ладно. Но говорить "ОЛ не страдает тормозами" без приписки "на моих микропроектах" нехорошо.
Чтобы сдвинуться с места нужно хорошенько раскачать.

Василий Кашуба
26.04.2017, 11:11
А на просьбу выложить проект на форум, владельцы "проблемных" проектов боятся, что их проблемную интеллектуальную собственность украдут.

anthrwpos
26.04.2017, 11:17
Вряд ли дело в интеллектуальной собственности. Скорее дело в высокомерии, ведь стоит только что нибудь выложить, как сразу посыпется критика что там не так и здесь не эдак) И критика эта будет не всегда по теме оптимизации ресурсов)
Многие воспринимают это крайне болезненно.

Вольд
26.04.2017, 11:23
Реакции от ОВЕН не слышно.

Не слышно, но зато видно. ;) Неугодные посты очень шустро удаляют.

SA104
26.04.2017, 11:24
Вас всё устраивает -- и ладно. Но говорить "ОЛ не страдает тормозами" без приписки "на моих микропроектах" нехорошо.
.
Я не писал, что у меня микропроекты, не надо за меня это делать.
Поставим вопрос по другому: при каком проценте задействованных ресурсов (внизу рабочего экрана) ОЛ начинает "тормозить"

Василий Кашуба
26.04.2017, 11:26
Критиков нужно пропускать мимо ушей, а полезные советы наматывать на ус. :) Поэтому благодаря Анатолию(rovki) и AI!, я теперь и сам неплохо разбираюсь в ОЛ.

Василий Кашуба
26.04.2017, 11:28
Я не писал, что у меня микропроекты, не надо за меня это делать.
Поставим вопрос по другому: при каком проценте задействованных ресурсов (внизу рабочего экрана) ОЛ начинает "тормозить"
Да ресурсы как раз загружаются плохим составлением кода.

SA104
26.04.2017, 11:32
Да ресурсы как раз загружаются плохим составлением кода.

+ !

melky
26.04.2017, 11:38
Не бог весть, есть ошибки в логике, наращивание было постепенным, поэтому нет оптимизации, которая бы радовала глаз многих.
Так вот при выделении элемента, с которым я еще не решил что делать по левой кнопки мыши, проходит 2-3 секунды на ПК с i5

Ресурсы в ПР еще пихать и пихать... 5 мс выполнение программы на ПР, 2-3 секунды выделение одного элемента на ПК... это ли не тормоза ?

Да, и спасибо Овену за применение макросов iChange, fChange, они в проекте только благодаря разработчикам, которые накосячили незнамо когда, на версии 51 все работало и без этого.

Вольд
26.04.2017, 11:39
Я не писал, что у меня микропроекты, не надо за меня это делать.
Поставим вопрос по другому: при каком проценте задействованных ресурсов (внизу рабочего экрана) ОЛ начинает "тормозить"

Читай пост #38, там ответ на твой вопрос.

capzap
26.04.2017, 11:43
всё не то, просто кто то перешл с плк на ПР из-за дешевизны и пытается впихнуть невпихуемое. Поэтому разговоры о ресурсах и т.п. тут ни к чему не приведут

Василий Кашуба
26.04.2017, 11:51
При первом же беглом взгляде (не критика, вопрос), для чего нужен выделенный элемент? Задержка на цикл, или для чего?
30800

melky
26.04.2017, 11:59
Не, стояло два датчика напряжения до автомата и после если выбьет по нагрузке (контроль автомата без допконтакта состояния) и генератор не пытался заводиться, если все равно нагрузку подключить не может. Сейчас была смена генератора и пока один датчик отключен, поэтому в схеме добавлен ИЛИ, чтобы пока на одном датчике работало.

Вольд
26.04.2017, 12:08
всё не то, просто кто то перешл с плк на ПР из-за дешевизны и пытается впихнуть невпихуемое. Поэтому разговоры о ресурсах и т.п. тут ни к чему не приведут

Не надо наводить тень на ясный день. Лучше прочтите пост #38.

SA104
26.04.2017, 12:10
melky, ваш пример действительно тормозит, примерно 1-1,5 сек на перетаскивании ФБ мышкой.
Почему то кажется, что из-за обилия внутренних переменных, которые можно заменить обычными связями (неэстэтично будет, согласен)
Проверю, напишу.

capzap
26.04.2017, 12:16
Не надо наводить тень на ясный день. Лучше прочтите пост #38.

Вы видимо большой специалист в этом вопросе, в чем заключаются смысл этих процентов можете растолковать?
И какое отношение это всё имеет к среде разработки

melky
26.04.2017, 12:17
Я уже написал, что благодаря разработчикам там даже лишние FB есть, которых в принципе там быть не должно. Все для того, чтобы были энергонезависимые переменные, управляемые через сетевые.

rovki
26.04.2017, 12:20
всё не то, просто кто то перешл с плк на ПР из-за дешевизны и пытается впихнуть невпихуемое. Поэтому разговоры о ресурсах и т.п. тут ни к чему не приведут
О чем и речь .!

Вольд
26.04.2017, 12:21
Вы видимо большой специалист в этом вопросе, в чем заключаются смысл этих процентов можете растолковать?
И какое отношение это всё имеет к среде разработки

capzap, зачем задавать детские вопросы ? Из того что написано в посте #38 явствует, что из-за жутких тормозов в ОЛ задействовать больше 30% ресурсов ПР200 не возможно. Чем больше схема, тем сильнее тормоза вплоть до того, что полдня придется ждать реакции ОЛ на движение мышки. Вы согласны ждать полдня ? ;)

Еще раз повторю, что писал раньше: ПР200 - отличный прибор, ОЛ - посредственный продукт.

SA104
26.04.2017, 16:13
Для информации, кому интересно.
Провел лабораторную работу с целью исследования "тормозов" Owen Logic

1. Разместил на рабочем поле 800 ФБ (элементы ИЛИ), никуда не подключенных. Время реакции( на моем ПК) при наведении мышкой 6 сек.
2. Сделал макрос для 21 элемента. Разместил 50 макросов - больше тысячи элементов. Время реакции минимально, как при наведении на макрос, так и при редактировании внутри макроса.

Вывод: Больше макросов хороших и разных.

rovki
26.04.2017, 16:19
Макросы- Наше ВСЕ! 1000 раз об этом говорилось .Только толку от макросов в котором 2,3,4,5 элементов мало .В Макросы надо запихивать функционално законченные блоки схем большего размера с минимальным количеством входов\выходов .
SA104 ,спасибо за примеры ,не поленились.
Что ище интересно - ввиду того что элементы не соеденены ,в двух вариантах вычисляеется время выполнения проекта в ПР 1мс .А зависания наблюдаем только в первом вариане .Значит зависания не определяются временем выполнения и не определяются % памяти - в двух вариантах % минимальны (ввиду того что элементы не соединены),а количеством отображаемых самих элементов на одном поле

rovki
26.04.2017, 16:59
А вот ваш пример но только 4000элементов на 4 макросах и зависаний нет в схеме ,а внутри маросов есть .
Вывод -в очень сложных проектов стремитесь к количеству макросов равному корень из 2 от общего количества элементов ,с количеством элементов внутри каждого макроса также корень из 2 .Например 1000элементов - 33 макроса по 33 элемента ,теоритически для получения минимального времени реакции в ОЛ .Для ПР думаю это не имеет значения .
К стати обьем проекта то же вырос в почти 4 раза.
Если же вам нужны мелкие ,повторяющиеся макросы ,то делайте вложения -Макрос в макросе .И не нужно будет футбольное поле , достатчно будет 10 шахматных досок ;) для схемы.

SA104
26.04.2017, 17:17
Проверил ваш пример, результат аналогичный.

rovki
26.04.2017, 17:21
Проверил ваш пример, результат аналогичный.
Тоесть читайте пост#96,97,для писсиммиссттов .Спасибо, коллега .

melky
26.04.2017, 17:27
Что делать, если код получается разветвленным и макросами сложно обойтись ?

Макрос - это повторяющийся код в схеме, а ни как не требование запихивать куски схемы просто для того, чтобы получился один блок вместо 10.

rovki
26.04.2017, 17:31
Что делать, если код получается разветвленным и макросами сложно обойтись ?

Макрос - это повторяющийся код в схеме, а ни как не требование запихивать куски схемы просто для того, чтобы получился один блок вместо 10.
Я же как раз и говорю о функционально законченных блоках,которые не обязательно должны повторятся,значит еще укрупните макрос,сделайте макрос в макросе) ,которые нужно запихнуть в макрос .Да ,не люблю и коробит употребление слова КОД применимо к ПР ,ОЛ.
Если нет такой возможности (законченная функция) ,то разбейте исходя из минимума входов\выходов .
Таким образом зависания связаны с графикой (элементы,связи),библиотеками ,а не компиляцией ...
Диагнос поставлен ,лечитесь и будьте здоровы ;)

Вольд
26.04.2017, 19:01
Для информации, кому интересно.
Провел лабораторную работу с целью исследования "тормозов" Owen Logic

1. Разместил на рабочем поле 800 ФБ (элементы ИЛИ), никуда не подключенных. Время реакции( на моем ПК) при наведении мышкой 6 сек.
2. Сделал макрос для 21 элемента. Разместил 50 макросов - больше тысячи элементов. Время реакции минимально, как при наведении на макрос, так и при редактировании внутри макроса.

Вывод: Больше макросов хороших и разных.


Эксперимент поставлен плохо. Вот когда все связи подключишь тормоза и начнутся.

rovki
26.04.2017, 19:29
Эксперимент поставлен плохо. Вот когда все связи подключишь тормоза и начнутся.
Вы через строчку читаете? Связи есть между элементами ,но не подключены в выходам.входам ,но это не влияет на тормоза .В одном примере тормоза 5-6 сек ,а в другом точно та же схема ,но в макрасах тормозов не имеет .
Не делайте скорополительных ,не проверенных выводов ,подключение выходов не влияеет на тормоза ,проверено ,в отличие от вас . Подключенные выводы увеличат размер памяти в ПР и время цикла ,а на ОЛ это не влияет .
Естественно чем сложнее схема тем больше время цикла и больше требуется ресурсов от ПР ,но Тормоза ОЛ связаны только с количеством элементов и связей (переменных) на поле СХЕМА (или поле Макроса) .Разбейте схему на макросы нормальные и можете ПР загрузить на 100%.
Но схему с 1000 фб трудно представить для ПР

Вольд
26.04.2017, 19:40
Даже в таком примитивном проекте тормоза ощущаются и при открытии проекта и при редактировании. Размер файла первого макроса гигантский - 13,7 Мб. В проекте с макросами вообще связей нет и говорить там не о чем.

rovki
26.04.2017, 19:49
Да что ж такое :mad: Я же говорю ,я подключал выходы ,разницы для тормозов нет .Тормозят бибилиотеки графические и разницы нет для них куда подключен или нет вывод. Уже пять раз сказал и проверил ,а вы все свое .Создайте свой пример и опровергайте ,а не бла-бла -бла .

Вольд
26.04.2017, 19:53
Создайте свой пример и опровергайте.

Делать мне больше нечего. Сообщений пользователей достаточно чтобы сделать правильный вывод. А вывод неутешительный.

rovki
26.04.2017, 19:59
Если еще так и не поняли как избежать тормозов ,то флаг вам в руки .Делать больше нечего ,как выводы делать ....и людей в заблуждение вводить .Тогда зачем писать ??? Здесь орденов не даеют за количество постов ...

melky
26.04.2017, 20:21
Оно тормозит в макросе безбожно даже с отключенными входами/выходами

rovki
26.04.2017, 20:30
Про то и речь и память ноль и время 1мс ;)
Хоть в схеме много элементов ,хоть в макросе .Поэтому и говорю большую схему чикать на куски большие .Графика в графическом языке много кушает времени ,это вам не текстовый язык ,когда на экран несколько десятков строк .Тут на поле сотни элементов впихивают ...

melky
26.04.2017, 21:21
Убедили, открыл для прикола Logo Soft, там конечно столько элементов не впихнешь, но поставил максимум, что программа сказала больше не могу.
Выделение, перетаскивание вместе с кусками программы (связями) в лет на i5

ОЛ - УДРУЧАЕТ в этом плане. А ведь в лого тоже графический язык. Так кто виноват ? графика или программисты ?

rovki
26.04.2017, 21:33
Так кто виноват ? графика или программисты ?
Программисты делавшие графику ;) Но их нужно понять и простить ;)
Для прикола сделали бы проект на 1000элементов в кодесис ,в том же языке и посмотрели бы .Думаю ситуация будет близкой ,но надо проверить

rovki
26.04.2017, 21:37
Убедили, открыл для прикола Logo Soft, там конечно столько элементов не впихнешь, но поставил максимум, что программа сказала больше не могу.

Вы предлагаете ,что бы ОЛ говорил -больше не могу ?Так сколько было элементов в лого ,когда он сказал ,что не могу ?

Василий Кашуба
26.04.2017, 21:58
Убедили, открыл для прикола Logo Soft, там конечно столько элементов не впихнешь, но поставил максимум, что программа сказала больше не могу.
Выделение, перетаскивание вместе с кусками программы (связями) в лет на i5

ОЛ - УДРУЧАЕТ в этом плане. А ведь в лого тоже графический язык. Так кто виноват ? графика или программисты ?
Вот посмотрите и сравните ваш макрос наработка и мой. У вас избыточный код.
30810 30811 и во многих макросах так.

rovki
26.04.2017, 22:13
И так почти у всех программистов ,потому как мыслят по другому ;)Вот если бы они сами покупали бы и паяли микросхемы ,то они быстро бы перестроились .А тут рисуй что хочет ,бумага (поле) стерпит , а главное если что- будут виноваты бумага и карандаш ;) (инструменты).
Так держать , Василий!!!

Scream
26.04.2017, 22:16
Программисты делавшие графику ;) Но их нужно понять и простить ;)
Для прикола сделали бы проект на 1000элементов в кодесис ,в том же языке и посмотрели бы .Думаю ситуация будет близкой ,но надо проверить

Сегодня делал расчет CRC, там надо 2 массива по 255 переменных как константы, итого ~500 констант, просто объявлены, тоесть 500 простых чисел загнаны в 2 массива, а codesys приуныл и тупил жестко при прокручивании этих переменных, чего там говорить о блоках, которых будет 1000.

rovki
26.04.2017, 22:19
Вот истина,проверенная опытом ...Поэтому если используешь графику ,то подчиняйся ее законам....если нет ,то в писатели (хорошие) ...

rovki
26.04.2017, 22:27
Думаю ,основательно проработали тему и нашли общие требования .Тема закроется ,но выводы из нее нужно выписать крупными буквами и повесить над столом тем кто хочет из-за дешевизны использовать ПР для реализации крупных проектов и помнить -по Сеньке шапка , и не винить шапку ,из-за того что у него голова большая .

melky
27.04.2017, 00:09
Василий Кашуба когда-то rovki заметил, что я неправильно обозвал этот макрос "макросом наработки", в данном примере он просто используется для этой функции.
Мой умеет считать бутылки в ящиках :) и умеет производить инициализацию заданными переменными при прошивке ПР (например обновлении программы с сохранением наработанного). И так же сбрасывать значения если это требуется логикой.

Ваш то же самое выполнит ? не проверял просто еще, рисовать сейчас лень..

И простите, что это внизу за сек на EQ на 4,3E+09 ? а если я последним значении установлю 100 ? открывать макрос и редактировать ? или выносить для редактирования переменную во вне ?
з.ы. не смотрите на название, смотрите на работу

melky
27.04.2017, 00:11
Scream у вас что-то с памятью, расчет CRC через таблицы выполняется быстрее, чем просто в коде. Что-то вы там намудрили скорее всего.

rovki
27.04.2017, 00:48
По теме сказать нечего ? И правильно ,но не надо переводить разговоры на другие темы и обьвинять Василия и Скрима в чем то бы то не было ибо примеры они приводиди для аргументации при обсуждении темы ,а вы ее пытаетесь увести в строну ,обвиняя их что первый что то не понял и второй что то напутал .Доказательства привел я ,меня и ругайте ,а они были свидетелями и предоставили факты .
А то вы сказали ,что вас убедили по теме ,но в отместку накидываетесь на тех кто свидетельствовал,что бы потом опровергнуть решение "суда" или внести смуту в в ряды "присяжных " (умы читающих тему).Тема закрыта (проблема решена),но не для разработчиков .

Василий Кашуба
27.04.2017, 07:51
Василий Кашуба когда-то rovki заметил, что я неправильно обозвал этот макрос "макросом наработки", в данном примере он просто используется для этой функции.
Мой умеет считать бутылки в ящиках :) и умеет производить инициализацию заданными переменными при прошивке ПР (например обновлении программы с сохранением наработанного). И так же сбрасывать значения если это требуется логикой....
Я же не сказал что ваш макрос плохой, я сказал что он избыточен для данной задачи, как говорится, из пушки по ...

melky
27.04.2017, 08:47
Василий, согласен, что несбрасываемый счетчик можно было бы и заменить, но как сказал выше, иногда (даже сейчас там есть ошибка, которую некогда исправить) нахожу ошибки и надо перешить ПР, сохранив время наработки. Ваш макрос на это не способен.
rovki вы о чем ? я просто говорю, что когда говорим об оптимизации, не стоит забывать о функционале, если я применил именно это, то вероятно была причина и не стоит урезать функционал не глядя. Попробуйте оптимизировать макрос при сохранении функционала, я вам памятник воздвигну :)

Я точно так же оптимизировал макрос AI - iChange так как его вариант был избыточен. А когда починят значение сетевых переменных по умолчанию, так вообще уберу, так как и сами макросы станут избыточны.

capzap
27.04.2017, 09:20
когда говорим об оптимизации, не стоит забывать о функционале, если я применил именно это, то вероятно была причина и не стоит урезать функционал не глядя
не один раз прогонял комбинации бит на входах, так и не понял в чем функциональный смысл второго OR

melky
27.04.2017, 09:28
capzap я ж выше писал Василию, геныч поменяли на скорую руку, второй датчик напряжения до автомата генератора еще не подключили, вот и вкорячил ИЛИ, чтобы схема сейчас работала.

Кстати Василию +, благодаря ему еще одну ошибку нашел :) надо будет поправить.

capzap
27.04.2017, 09:31
всёравно не пойму, входов же свободных нет, какой второй генератор?

melky
27.04.2017, 09:32
capzap сейчас посмотрел, не понял про какую часть схемы вы говорите ?

Если это про входа "Напряжение до QF" и "Напряжение после" то об этом и говорю, я ставлю два датчика наличия напряжения (паяю) так как на автоматах генераторов нет возможности установить допконтакт состояния. Да и в любом случае надо знать, что генератор именно запустился, так проще...
Одновременно видишь напругу и состояние автомата

capzap
27.04.2017, 09:43
про то место на которое акцентировал внимание Василий, про iChange кстати тоже, не возможно понять назначение, если смотреть внутренности макроса, может AI был прав со своей схемой, как вы там говорите:"вероятно была причина и не стоит урезать функционал не глядя"

rovki
27.04.2017, 09:54
Теперь будем обсуждать макросы от melky ???

capzap
27.04.2017, 10:04
Теперь будем обсуждать макросы от melky ???

Вы же вроде для себя закрыли тему.
А по поводу обсуждения, это как в рекламе на ТНТ, люди же старались, выкладывали, почему бы не по обсуждать. Тем более, все как Вы говорите, если всё стадо подобных макросов собрать в один макрос, чтоб получить резервацию однотипных юнитов, то главная схема сократится значительно

Владимир Ситников
27.04.2017, 10:13
Теперь будем обсуждать макросы от melky ???

Разумеется. Хоть кто-то выкладывает программы со словами "вот на этой программе ОЛ тормозит".

Да, предыдущие замеры показали, что при большом количестве элементов на экране ОЛ тормозит.
Но это не означает, что "большое количество элементов" это единственный случай, когда ОЛ тормозит.

Вполне возможно, есть другие причины по которым ОЛ тормозит, и в этом плане обсуждать разнообразные тормозящие проекты это правильно.

melky
27.04.2017, 10:16
capzap у AI макрос имеет приоритет по входу, а как писал выше, эти макросы временные до починки косяка разработчиков ОЛ. Назначение простое, активировать значение сетевой переменной по умолчанию при прошивке ПР (полгода уже чинят, если не больше, никак не дочинят)
на счет лишнего ИЛИ уже объяснил, временное решение, пока на место датчик напряжения не воткну и минимум изменений программы, просто обманка.

По крайней мере народ наблюдательный :)...

Пощупал макрос Василия, неплох, но чтобы обнулить одно значение в счетчике или записать определенное значение, например минуты, придется использовать макросы UnixTime и оперировать кучей переменных. Опять же, применительно ко времени, а если значения не временные ? выполнять еще кучку расчетов.

Сам макрос маленький, но обвязка будет ого-го, что еще добавит тормозов. При применении для чистого сброса вполне отличный. Кстати что произойдет если ему максимум времени задать и он перешагнет через него, обнулится ?

capzap
27.04.2017, 10:26
AI макрос имеет приоритет по входуне видел первоначальный макрос, но по моему это у Вас имеет значение приоритет, а не установить на выходе то значение которое изменилось на входах последним на текущий момент. Инициализацию от сетевой переменной, я бы делал по другому, еслиб стояла такая задача, без оглядки на какие то потенциальные косяки разработчиков


пока на место датчик напряжения не воткнуВы серьезно считаете, что внятно всё объяснили, здесь так же бы была уместна новость, что Вы без билета в автобусе проехали, содержательной информации ноль

melky
27.04.2017, 10:39
capzap еще раз - вход 2 и 3 получают дискретные сигналы от датчиков напряжения, установленные ДО и ПОСЛЕ автомата защиты генератора, отлавливают запуск генератора а так же что автомат не был отключен, или был отключен по перегрузке. На данный момент один датчик напряжения не установлен, сделана обманка при помощи ИЛИ. Что тут непонятного ?

если приоритет и есть, то только при прошивке ПР, не задавался этим вопросом, при изменении переменной с любой стороны, хоть с экрана, хоть по сети, переменная меняется везде.

Приходится оглядываться на косяки, так как на ПР114 и версии ОЛ .51 все работает без этого огорода. Потом что-то сломали либо в ОЛ либо в прошивке ПР и починить не могут уже более полугода.

capzap
27.04.2017, 10:57
вход 2 и 3 получают дискретные сигналы от датчиков напряжения, установленные ДО и ПОСЛЕ автомата защиты генератора, отлавливают запуск генератора а так же что автомат не был отключен, или был отключен по перегрузкеэто ясно из описания на схеме, можно было не повторять
На данный момент один датчик напряжения не установлен,какой датчик I2 или I3? Я выложил рисунок, где выходы обоих элементов сравниваются между собой и если будет разница, выход XOR включится, из двух физических входов может быть только четыре комбинации, если один датчик не используется то тогда вообще две, я их не однократно посылал на собранную схему и ни разу конечный выход не "загорелся", отсюда делаю вывод что второй OR лишний, даже если его назвать обманкой

melky
27.04.2017, 11:35
Блин, я сразу и сказал, что он лишний, так как на вход I2 сейчас тупо ничего не приходит, даже когда это необходимо, нет датчика, потом он доустановится и уберется один из программы

Одного не пойму, откуда вы выкопали XOR ?

capzap
27.04.2017, 11:52
так он лишний и с двумя датчиками и с одним датчиком. Повторяю, выход XOR показал бы(еслиб оно было) различие выходов первого и второго элемента OR, но их нет, потому что второй элемент повторяет работу первого, он лишний всегда

melky
27.04.2017, 11:59
Я понял о чем вы, на ТОН идет сигнал ИЛИ от двух входов, где достаточно было снять например только с I2. Но кучка сигналов с I2 идет совершенно на другие элементы, где I3 не нужен и может даже вреден.
з.ы. программу выкладывал показать тормоза больше, чем для разбора полетов. Все равно она будет перерабатываться, когда руки дойдут.
Ей лет 5 наверное, вернее она до этого состояния лет за 5 обросла, наверняка там есть не только это лишнее :)

Василий Кашуба
04.05.2017, 21:47
Элементов не считал сколько, с логическими функциями может и 200, может побольше. В общих чертах - небольшое очистное сооружение, просто с функционалом посложнее чем просто вкл/выкл насос по уставке. Да, опять же, не столь это важно
А какая же тогда у вас получится программа для вентиляции и кондиционирования кинотеатра с восемью кинозалами?

Irgy
04.05.2017, 22:34
А какая же тогда у вас получится программа для вентиляции и кондиционирования кинотеатра с восемью кинозалами?

Мы с Вами в процессе хитроумных рассуждений ранее уже решили, что проблема тормозов ОЛ кроется во мне лично, какая теперь разница какая у меня на что получится программа?! :) А если по делу, кода у меня написано ровно столько, сколько нужно на весь возложенный в моем проекте на ПР функционал, и, уж поверьте на слово, у меня хватает опыта самостоятельно оценить насколько оптимален мой код и можно ли сделать его короче или нет.

starmos
05.05.2017, 06:25
Мы с Вами в процессе хитроумных рассуждений ранее уже решили, что проблема тормозов ОЛ кроется во мне лично, какая теперь разница какая у меня на что получится программа?! :) А если по делу, кода у меня написано ровно столько, сколько нужно на весь возложенный в моем проекте на ПР функционал, и, уж поверьте на слово, у меня хватает опыта самостоятельно оценить насколько оптимален мой код и можно ли сделать его короче или нет.

Тут проблема в том, что и ПР200 и ОЛ = просто идеальны и любые изменения в них способны их только ухудшить. Это я кратко изложил аксиому, которой придерживается некоторые активные завсегдатаи данного форума. Поэтому если вы пишете программу на ОЛ, а ОЛ у вас тормозит, но при этом ОЛ идеален, то сами понимаете кто виноват? Осталось просто найти причину по которой вы виноваты и спокойствие восстановится.

Irgy
05.05.2017, 09:41
Тут проблема в том, что и ПР200 и ОЛ = просто идеальны и любые изменения в них способны их только ухудшить. Это я кратко изложил аксиому, которой придерживается некоторые активные завсегдатаи данного форума. Поэтому если вы пишете программу на ОЛ, а ОЛ у вас тормозит, но при этом ОЛ идеален, то сами понимаете кто виноват? Осталось просто найти причину по которой вы виноваты и спокойствие восстановится.

да, я уже все это понял, осознал и смиренно пошел дальше кодить :)

melky
05.05.2017, 09:48
Имхо, с чем бы ни были связаны тормоза, их быть не должно.... и не надо списывать на бесплатность продукта, ОЛ без ПР никому не нужен.

Irgy
05.05.2017, 09:58
Имхо, с чем бы ни были связаны тормоза, их быть не должно.... и не надо списывать на бесплатность продукта, ОЛ без ПР никому не нужен.

Полностью согласен. Если задуматься, на сайте заявлены характеристики прибора и цена, потребитель покупает и сталкивается с практической невозможностью использовать более 30-40% мощностей прибора из-за тормознутости программки для этого прибора, и при этом альтернативной программки нет.

Слышал, что в ОЛ1.9 постараются решить проблему, остается ждать и надеяться :)

Василий Кашуба
05.05.2017, 10:01
Тут проблема в том, что и ПР200 и ОЛ = просто идеальны и любые изменения в них способны их только ухудшить. Это я кратко изложил аксиому, которой придерживается некоторые активные завсегдатаи данного форума. Поэтому если вы пишете программу на ОЛ, а ОЛ у вас тормозит, но при этом ОЛ идеален, то сами понимаете кто виноват? Осталось просто найти причину по которой вы виноваты и спокойствие восстановится.
Ну конечно, вы самые крутые генераторы программных кодов и вам совершенно не нужны ни чьи советы. ВЫ сами с усами. :)

Вольд
05.05.2017, 14:54
да, я уже все это понял, осознал и смиренно пошел дальше кодить :)

Крепись, брателло. ;) А про сам ПР200 что можете сказать ? По моему хороший прибор получился.

melky
05.05.2017, 15:02
Вольд почти :) не хватает переменных для нумерации экранов и системных переменных для клавиш.
Системных переменных для корректировки времени.

Irgy
05.05.2017, 15:06
Крепись, брателло. ;) А про сам ПР200 что можете сказать ? По моему хороший прибор получился.

Сам ПР200 очень нравится, хороший набор входов/выходов, экран, 2 порта RS485, теперь еще модуль расширения - и все это по вполне приятной вменяемой цене. Да, чего-то по мелочи не хватает, но продукт и линейку развивают и наверняка будут развивать и дальше.

melky
05.05.2017, 15:40
главное чтобы с ним ничего не случилось как с Модусом.....

Вольд
05.05.2017, 15:50
Вольд почти :) не хватает переменных для нумерации экранов и системных переменных для клавиш.
Системных переменных для корректировки времени.

Это недостатки ОЛ, а не ПР200.

игорь68
05.05.2017, 19:33
Есть у меня в обслуживание одна КНС. 5 шкафов автоматики . 4 линии фильтрации и обработки. Насосы 2 . Там у меня и Ручной режим и Авто( кнопки лампочки), поплавки, реле протока 4, защита и пуск насосов, контроль работы бактерицидных ламп, ротация ламп и ротация насосов. Автор темы сравнима с вашим проектом? Как вы думаете кто всем этим управляет ? Уверен на 100000% не угадаете. Там стоит простое реле меллер И БЕЗ БЛОКОВ РАСШИРЕНИЯ. Кто не верит могу выложить фото всей системы и "внутрянки" шкафа. Реле рулит работой 4 контроллеров. Получает сигал работа/авария и простым выходом реле сообщает в СКАДУ что есть авария.
Грамотный анализ задачи и правильный подбор оборудования залог успешной работы проекта. Купив прибор за 6000 глупо ждать что сможет работать как прибор за 60000. Проще и быстрее разделить задачи и сделать 2-4 маленьких проекта 300*400 чем тратить время на полотно 400*2400.

Вольд
05.05.2017, 20:16
Может ты и проект этот сам сделал ?

Irgy
05.05.2017, 21:10
Есть у меня в обслуживание одна КНС. 5 шкафов автоматики . 4 линии фильтрации и обработки. Насосы 2 . Там у меня и Ручной режим и Авто( кнопки лампочки), поплавки, реле протока 4, защита и пуск насосов, контроль работы бактерицидных ламп, ротация ламп и ротация насосов. Автор темы сравнима с вашим проектом? Как вы думаете кто всем этим управляет ? Уверен на 100000% не угадаете. Там стоит простое реле меллер И БЕЗ БЛОКОВ РАСШИРЕНИЯ. Кто не верит могу выложить фото всей системы и "внутрянки" шкафа. Реле рулит работой 4 контроллеров. Получает сигал работа/авария и простым выходом реле сообщает в СКАДУ что есть авария.
Грамотный анализ задачи и правильный подбор оборудования залог успешной работы проекта. Купив прибор за 6000 глупо ждать что сможет работать как прибор за 60000. Проще и быстрее разделить задачи и сделать 2-4 маленьких проекта 300*400 чем тратить время на полотно 400*2400.

По объему сравнимо. Но мне принципиально нужно вложить мою логику в один бюджетный прибор, про то, как сделать проще и быстрее, мне известно, я не новичок в том, что делаю. Опять же, еще раз - к прибору претензий нет, прибор шикарен, претензии к среде разработки, которая не дает использовать прибор по максимуму. И, если честно, надоело уже на эту тему дискутировать

starmos
07.05.2017, 12:02
Есть у меня в обслуживание одна КНС. 5 шкафов автоматики . 4 линии фильтрации и обработки. Насосы 2 . Там у меня и Ручной режим и Авто( кнопки лампочки), поплавки, реле протока 4, защита и пуск насосов, контроль работы бактерицидных ламп, ротация ламп и ротация насосов. Автор темы сравнима с вашим проектом? Как вы думаете кто всем этим управляет ? Уверен на 100000% не угадаете. Там стоит простое реле меллер И БЕЗ БЛОКОВ РАСШИРЕНИЯ. Кто не верит могу выложить фото всей системы и "внутрянки" шкафа. Реле рулит работой 4 контроллеров. Получает сигал работа/авария и простым выходом реле сообщает в СКАДУ что есть авария.
Грамотный анализ задачи и правильный подбор оборудования залог успешной работы проекта. Купив прибор за 6000 глупо ждать что сможет работать как прибор за 60000. Проще и быстрее разделить задачи и сделать 2-4 маленьких проекта 300*400 чем тратить время на полотно 400*2400.

Ну тут-то конечно - я например все осознал и усовестился. "Одно реле управляет..." - капец, а я глупый конечно. Потому что не понимаю - зачем там это реле, да и еще и без блоков расширения (еще бы там были и блоки). Потому что мне кажется что УПРАВЛЯЮТ там контроллеры, а реле просто СИГНАЛИЗИРЕУТ в Скаду (по крайней мере так следует из описания). И это, по крайней мере по моему мнению, есть странно. Потому что сейчас даже дохлый контроллер, даже китайская дешевка, имеет на борту интерфейс 485, что позволяет подключить все эти 4 контроллера в Скаду и получать там состояние и значения необходимых переменных, а не только сигналы "работа/авария". Да еще и сэкономится вышеупомянутое реле.
Все вот эти песни - "вы хотите за 6000 получить то же что и за 60000" выглядят разумными только на первый взгляд, потому что это как минимум неоднозначно. Да конечно, за 60000 можно выпустить ОЧЕНЬ крутой контроллер. Но если в общем барахло или обычный по возможностям прибор стоит почему-то 60000, то прибивать возможности другого неплохого прибора, только потому что он стоит 6000 - это выглядит странным. Например контроллеры Данфосс ECL - неплохи вполне, но просят за них совершенно неадекватные деньги, такое впечатление что продавцы рехнулись. Однако на том же ПР200 вполне можно заменить некоторые из ECL200/300. Так не дадим же людям такой возможности, потому что ПР200 стоит 6000, а ECL - 60000?
Если быстродействия процессора хватает, объема памяти хватает и числа ввода-вывода хватает, то контроллер подходит для реализации задачи, сколько бы он ни стоил. И если где-то что-то тормозит при разработке, или нельзя использовать все ресурсы полностью, то это вина исключительно производителя контроллера.

rovki
07.05.2017, 13:30
Уже писали же -делайте хоть какие сложные (для вас) проекты ,но не забывайте про шапку Сенькину и маленьнькие хитрости при использовании ОЛ(родимые пятна) ,что бы не зависать на века ,учитывайте так сказать "характер"(особенности ОЛ), пусть даже внешне одинаковых субьектов(ПР-ПЛК).

anthrwpos
07.05.2017, 16:24
Тема закончилась тем, что чтобы не тормозило, достаточно разбивать проект на макросы, или я какой-то еще источник лагов пропустил?
Чета последние 4 страницы идет какое-то вялое ворчание без обсуждения конкретики)

rovki
07.05.2017, 16:39
Тема закончилась тем, что чтобы не тормозило, достаточно разбивать проект на макросы, или я какой-то еще источник лагов пропустил?
Чета последние 4 страницы идет какое-то вялое ворчание без обсуждения конкретики)
Да нужно разбивать на макросы ,в очень сложных проектах их число должно быть не менее чем корень из двух от общего числа ФБ ,что бы максимально загрузить ПР и ОЛ не тормозило .

Eugene.A
07.05.2017, 16:44
корень из двух от общего числа
Ни хрена не понял, от чего корень?

rovki
07.05.2017, 18:21
Ну это для оптимальности(теоретически) ,но не обязательно .Если у вас 1000 элеметов(фб) -это минимум 1500связей ,то делайте 30-33 макроса ....Для средней сложности проекта до 100 элементов можно делать любое удобное количество макросов или не делать их вовсе -тормозов не будет ,но читаемость ни какая .Иными словами ,если до ста не тормозит ,а у вас 500 элементов ,то делайте минимум 5 макросов ,а лучше 20 ,что бы читать можно было без напряга и обилия связей на одной станице (схемы или макроса).И думать об оптимальном разбиении схемы на макросы нужно в самом начале, если чувствуешь что потребуется несколько сотен элементов .

игорь68
08.05.2017, 14:55
Вы не много не правы. 4 Контроллера что там стоя это контроллеры что контролируют работу бактерицидных ламп. Каждый свою линию и свой лампы. Он же считает время наработки. Он же видит что есть проток и нужно лампы включить. В реле он передает что я РАБОТАЮ или У МЕНЯ АВАРИЯ. При этом РЕЛЕ решает кто работает а кто курит. А о том что есть скада контроллер ламп даже не знает. По поводу тормозов. AMDА4.quad-core/ win8.1 озу 16 гигов проблем нет.

anthrwpos
08.05.2017, 16:52
Лучше вместо корня делать логарифм)
Основной лист должен содержать до ~30 элементов. Если их становится сильно за 40, делить на макросы, каждый из которых в свою очередь должен содержать до ~30 элементов иначе делить на подмакросы.
Еще лучше, чтобы это деление совпадало с функциональным назначением данного участка программы, тогда программа становится не только красивой, но и легко обслуживаемой.