This is topic Мнемосхема с графическими объектами слишком тяжёлая in forum Редактор проекта TRACE MODE 6 / at Форум TRACE MODE: техническая поддержка.


To visit this topic, use this URL:
http://forum.adastra.ru/ultimatebb.php/ubb/get_topic/f/32/t/000234.html

Posted by Kramarenko Stanislav (Участник № / Member № 119) on :
 
Послал свой проект на hotline3@adastra.ru для разбора следующей ситуации.

Имеется у меня в проекте вот такая мнемосхема:
Нажми сюда, чтобы посмотреть.

На ней располагается 212 графических объектов различных типов: задвижки разных видов, регуляторы, насосы, цифровые индикаторы.

Во-первых, мнемосхема очень долго грузится в редакторе (сегодня специально замерял - 10 минут 50 секунд на CeleronD 3.06 GHz).
Во-вторых, столько же она грузится и в МРВ, а при работе постоянно хавает 60-80% процессороного времени (ничего особо не делая).

Опыты выявили прямую зависимость между количеством графических объектов на мнемосхеме и скоростью загрузки/нагрузкой на процессор(при удалении объектов вообще падает до 0-6%).

Кроме того, замечено, что если последней редактировалась не данная мнемосхема, а какая-либо другая - с малым количеством элементов, - то процесс загрузки проекта в МРВ проходит быстро (исчисляется секундами), но на загрузку процессора не влияет.

Хотелось бы разобраться в данной проблеме, поскольку эксплуатировать в таком виде не представляется возможным (загрузка процессора слишком велика и не оправдана).

И еще, если проблема будет локализована, стоит ли мне продолжать в том же духе с надеждой на скорое исправление, или разгруппировывать объекты, что практически смерти подобно (за то малое время, что у меня есть)?
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Использование большого числа графических объектов, конечно, не самый лучший способ. Где можно лучше заменить его на стандартные элементы.

В релизе 6.06 значительно улучшится работа с графическими объектами в реальном времени. При работе в инструментальной среде улучшений скорее всего не будет.
 
Posted by Kramarenko Stanislav (Участник № / Member № 119) on :
 
Использование большого числа графических элементов обусловлено в том числе и тем, что отсутствует механизм группировки графических элементов в редакторе, ведь даже простая статическая задвижка состоит из 2 элементов, а есть объекты, состоящие и из 3-5 элементов. И неудобно для размножения выделять их все, гораздо удобнее, чтоб это был один сгруппированый объект.

P.S. ...не совсем понятно, чем может заниматься достаточно мощный процессор на протяжении 10 минут со 100% загрузкой при открытии мнемосхемы...
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Занимается проверкой всевозможных связей. На это уходит значительное количество времени
 
Posted by ShuraX (TM_Prof) (Участник № / Member № 3130) on :
 
На счет объектов и динамизации графики могу добавить, что заметил следующее:
я так же использую на экранах одни объекты (с практической т.з. и ООП предпочтительный вариант [правда в ТМ со своими особенностями [Улыбка / Smile] ] ) Так вот: если одновременно использовать статическую динамизацию и видеоклипы, то тормоза на порядок увеличиваются нежели без видеоклипов (даже если используется один видеоклип). Так что пришлось полностью отказаться от использования видеоклипов.
Значительно снизить тормоза удается если полностью перейти на 2D объекты и не использовать 3D объекты (упаси боже еще со всякими текстурами, материалами, прозрачностью, одно под другое подкладывать и т.п.), что планирую и сделать (пока все в 3D сделал по отсутствию опыта работы с ТМ6). И поему субъективному мнению (после прокрутке на МРВ) визуально "плоская" мнемосхема воспринимается лучше, чем "объемная" (это подтвержают и операторы).
Для снижения тормозов можно еще всю статику в файлик запихнуть и использовать его как подложку экрана мнемосхемы.

quote:
Отправитель / Originally posted by AdAstra Technical Support:
Использование большого числа графических объектов, конечно, не самый лучший способ. Где можно лучше заменить его на стандартные элементы.

Зачем они тогда нужны если их использовать в полной мере не удается?!
И, действительно, отсутствие группировки ГЭ на мнемосхеме (как это было в ТМ5) делает неудобной процедуру "лучше заменить его на стандартные элементы". Я так думаю, отсутствие данной возможности как раз и предполагало восполнить использованием объектов, что в принципе правильно с т.з. ООП, а главное ОЧЕНЬ удобно(!), вот только упирается в выше приведенную цитату.

А почему не самый лучший способ?
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Основное значение надо придать словосочитанию "Использование большого числа", в данном конкретном примере их было на одном экране около 200. При этом при тестировании на выходящем в скором времени релизе работа с этим экраном никаких проблем не создавала. Загрузка процессора была в районе 10-15%.

Трудности возникали при загрузке (10-15 мин) данного экрана в ИС, что в принципе не критично.
 
Posted by ShuraX (TM_Prof) (Участник № / Member № 3130) on :
 
Именно про "Использование большого числа" и думал [Улыбка / Smile] .
У меня на одном экране сейчас также порядка 200 объектов, в каждом от 4 до 7-8 аргументов. В ИС загружается за 1-1,5 минуты. Правда пока аргументы экрана не привязаны к каналам.
На аналогичном проекте у коллеги (часть экранов у него привязаны уже) на МРВ загрузка процессора в среднем 70-75%.

Будем ждать релиз 6.06.
 
Posted by SerchenyaN (Участник № / Member № 2877) on :
 
Новый релиз - это всё конечно здорово, но что нам делать с уже купленным 6.05.1? в утиль? деньги-то уплачены... Или есть возможность бесплатно обновить профессиональную версию?
quote:
AdAstra Technical Support
Трудности возникали при загрузке (10-15 мин) данного экрана в ИС, что в принципе не критично.

Удовольствия мало доставляет ждать открытия экрана 15 минут, а потом после кое-какого редактирования ждать ещё +15 минут, чтобы проверить работу в профайлере. И чем дальше, тем хуже.

Теперь о МРВ и NLL (которые тоже приобретены). При запуске МРВ или NLL загрузка в нашем случае 2-х ядерного процессора не выходит за пределы 50% (т.е. одно ядро на 100%), что в принципе допустимо, но 15 минут ожиданий запуска в процессе пусконаладочных работ - это чрезвычайно раздрожающий и отнимающий много времени фактор.
quote:
AdAstra Technical Support
Занимается проверкой всевозможных связей. На это уходит значительное количество времени

Этим же он занимаеться и при запуске МРВ? Тогда может подскажете возможность хоть каким-то образом сократить время запуска. У нас один из NLL вообще планировался как вспомогательный, который будет запускаться лишь по мере необходимости. И компьютер будет работать не круглосуточно. А теперь выходит, что пользователь должен будет каждый раз по 15 минут ждать загрузки, а потом и ещё минут 5 старта? В таком виде система будет приносить больше неудобства и негативных эмоций при эксплуатации, нежели пользы. Подскажите, пожалуйста, может можно как-то обойти проблему?
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Давайте дождемся нового релиза. Он будет работать примерно в 3-4 раза быстрее. Обновить Вы его сможете бесплатно на нашем сайте.
 
Posted by SerchenyaN (Участник № / Member № 2877) on :
 
Спасибо за скорый ответ. Будем ждать.
 
Posted by Kramarenko Stanislav (Участник № / Member № 119) on :
 
А может есть бета-версия? Хотя бы МРВ?
А то 15 августа на объект ехать и мне кажется, нас там не похвалят за такое быстродействие.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Возможность участия в бета-тестировании обсуждается индивидуально. Заявки можно отсылать на адрес hotline@adastra.ru
 


Новости АСУ ТП / News | SCADA / HMI | Обучение / Trainings | Свяжитесь с нами / Contact Us



Powered by Infopop Corporation
UBB.classic™ 6.7.2