ПР225 пользовательское ПЗУ визуализации 104%

Приветствую.
Сейчас делаю проект на ПР225.
8 экранов, в каждом по картинке 35-50кб, всего 349кб
Индикатор пишет 100% использовано памяти ПЗУ визуализации. 1572811 байт занято из 1572864. Но в принципе всё работает и даже при 104%.
Проект грузится в панель минуты три аж и даже при 94%
Это баг какой-то?
Ещё момент, если грузить картинку размером больше чем выбрал шаблон, то owen logic уход в глухой завис.
По началу писал что максимальный размер картинки не должен превышать 430пикселей, но потом каким-то образом стал принимать 480, т.е. в полную ширину экрана.
Вот думаю так оставлять, ничего не выйдет из строя с временем???
Ещё не понял как поменять цвет экрана с белого на иной. Или много хочу от ПР))
В общем, пока как-то всё сыроватое ещё. Версия последняя.

ПР225 считает 104% по самому загруженному экрану (а не все экраны сразу). Меньше 80% не показывает вообще.
Разгрузите самый загруженный, а лучше убрать картинки и подложить прямоугольник нужного цвета под кнопки.
Так вы закрасите экран нужным цветом.

Лоджик не очень корректно считает видеопамять. Где-то здесь представитель Овена рекомендовал дальше 80% не заходить (от греха)
По поводу цвета экрана - прямоугольник нужного цвета в виде фона

ПР205 понимает картинки svg? или только jpg, png и т.д? даже если второе, их можно уменьшить в объеме если обработать граф редактором простеньким.

Цитата:

---

Сообщение от melky

ПР205 понимает картинки svg? или только jpg, png и т.д? даже если второе, их можно уменьшить в объеме если обработать граф редактором простеньким.

---

Только jpg и bmp

тогда используйте jpg, некоторыми манипуляциями их можно уменьшать. Например использую для просмотра i-view и он умеет менять размеры в том числе. В общем поиграйтесь с jpg в редакторах и посравнивайте после этого размеры. с bmp не работаю обычно, может и их можно сделать меньше, но вроде вряд ли, сейчас не помню уже.

Небольшой эксперимент: круг 100*100 зеленого цвета. Картинкой в формате jpg и bmp удалось поместить 77 шт до 100% заполнения памяти. А, вот, базовый элемент "круг" удалось разместить только 17 шт

Цитата:

---

Сообщение от kondor3000

ПР225 считает 104% по самому загруженному экрану (а не все экраны сразу). Меньше 80% не показывает вообще.
Разгрузите самый загруженный, а лучше убрать картинки и подложить прямоугольник нужного цвета под кнопки.

---

Поэкспериментировал и не нашёл этому подтверждение. Счётчик памяти всё же общий и да, появляется после 80%.
Причём, все мои рисунки 390 кб по итогу - утяжеляют проект аж на мегабайт с лишним, из-за чего он и грузится долго...
В принципе, проект получился очень красивым и реалистичным к объекту и всё работает ок. Но как бы потом не окирпичиться из-за сдохшей памяти)))

Цитата:

---

Сообщение от melky

тогда используйте jpg, некоторыми манипуляциями их можно уменьшать. Например использую для просмотра i-view и он умеет менять размеры в том числе. В общем поиграйтесь с jpg в редакторах и посравнивайте после этого размеры. с bmp не работаю обычно, может и их можно сделать меньше, но вроде вряд ли, сейчас не помню уже.

---

Перебрал все форматы и градации, и бестолку, jpeg самый оптимальный минимум.

Цитата:

---

Сообщение от Vadik2881

Поэкспериментировал и не нашёл этому подтверждение. Счётчик памяти всё же общий и да, появляется после 80%.
Причём, все мои рисунки 390 кб по итогу - утяжеляют проект аж на мегабайт с лишним, из-за чего он и грузится долго...
В принципе, проект получился очень красивым и реалистичным к объекту и всё работает ок. Но как бы потом не окирпичиться из-за сдохшей памяти)))

---

Это писал инженер Овен, проверить просто, на копии программы удалите самый загруженный экран,
после сохранения появится (например 90%) это 2 по загруженности экран. Можете последовательно удалить все экраны и посмотреть.
А так же заменить (на время) свои рисунки на подложенный закрашенный прямоугольник и посмотреть разницу.

Выложите на обменник самый большой свой jpg

Цитата:

---

Сообщение от kondor3000

Это писал инженер Овен, проверить просто, на копии программы удалите самый загруженный экран,
после сохранения появится (например 90%) это 2 по загруженности экран. Можете последовательно удалить все экраны и посмотреть.
А так же заменить (на время) свои рисунки на подложенный закрашенный прямоугольник и посмотреть разницу.

---

Так и делал). У меня экраны и рисунки практически идентичные. Нет как такого загруженного экрана. Переполнение памяти происходит на всех без исключения. Хотя один из экранов, потом в работе видно, что прогружается с некоторым запаздыванием. Но тоже пробовал менять рисунок и без результатно.
В общем, графика на ПР будем считать работает, но с некоторыми нюансами...

Цитата:

---

Сообщение от melky

Выложите на обменник самый большой свой jpg

---

Вот пример. 50кб

Для ПР205 поступал так:
- в самой ПР рисовал экран линиями, кружочками и текстами (единицы измерения, названия) - статические элементы
- запускал эмуляцию и делал скрин в масштабе, близком к разрешению экрана панели
- в графическом редакторе (или пакетном ImageMagick) обрезал и уменьшал скрин до разрешения экрана ПР
Ещё в графическом редакторе можно добавлять статические тексты меньшим шрифтом, чем в OL.
Так получал подложку.

А уже на подложку накладывал динамические объекты. Экономия памяти - бешенная.

Зачем рисовал сначала в Owen Logic - чтобы размеры фигур точно совпали - у меня были кружочки насосов.

У насоса три состояния - включён, отключён, неисправен. Вот отключён и показан на подложке.
Примерно, так же у задвижки.

На текстах экономия совсем грандиозная.

На картинке - именно подложка без динамических элементов.

Один из вариантов уменьшение размера, если на экране есть возможность масштабирования, второй вариант просто уменьшен за счет удаления служебной инфы без изменения размеров. Ну вроде DPI еще уменьшал.

собственно за счет уменьшения качества картинки, но достаточном для отображения на экране в приемлемом качестве можно сократить размер занимаемой памяти.

У меня было ощущение, что в проект загружалась картинка в одном из форматов, а после компиляции в ПР она отправлялась в каком-то самодельном внутреннем формате и уже подогнанном к размеру элемента.
В переводе на нормальный язык, мне казалось, что исходный размер картинки в проекте никак не влияет на размер картинки, которая попадает в конечном итоге в ПР. И смысла в оптимизации - нет.

Проверял загрузкой bmp на мегабайты и jpg на килобайты.

Ой, тогда как печальненько, если ОЛ выполняет обработку картинки. И превращает ее в монстра :)
а вообще, экран маленький, нужно использовать картинки на 256 цветов, думаю вполне достаточно, а не лепить туда с 16-ти млн цветов серые картинки.

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

Цитата:

---

Сообщение от Vadik2881

Приветствую.
Сейчас делаю проект на ПР225.
8 экранов, в каждом по картинке 35-50кб, всего 349кб
Индикатор пишет 100% использовано памяти ПЗУ визуализации. 1572811 байт занято из 1572864. Но в принципе всё работает и даже при 104%.
Проект грузится в панель минуты три аж и даже при 94%
Это баг какой-то?
Ещё момент, если грузить картинку размером больше чем выбрал шаблон, то owen logic уход в глухой завис.
По началу писал что максимальный размер картинки не должен превышать 430пикселей, но потом каким-то образом стал принимать 480, т.е. в полную ширину экрана.
Вот думаю так оставлять, ничего не выйдет из строя с временем???
Ещё не понял как поменять цвет экрана с белого на иной. Или много хочу от ПР))
В общем, пока как-то всё сыроватое ещё. Версия последняя.

---

Добрый день. Заполнился индикатор именно пользовательской ПЗУ визуализации, не ОЗУ? А можете прислать проект на почту посмотреть? Подобных обращений еще не встречал. Просто, чтобы забить ПЗУ визу картинками (а этот индикатор заполняется исключительно от картинок) нужно прямо сильно постараться :)

Цитата:

---

Сообщение от melky

Ой, тогда как печальненько, если ОЛ выполняет обработку картинки. И превращает ее в монстра :)
а вообще, экран маленький, нужно использовать картинки на 256 цветов, думаю вполне достаточно, а не лепить туда с 16-ти млн цветов серые картинки.

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

---

Да, тоже создалось такое ощущение. Потому что картинки 390кб утяжеляют проект н а мегабайт с лишним.

Цитата:

---

Сообщение от Королев Кирилл

Добрый день. Заполнился индикатор именно пользовательской ПЗУ визуализации, не ОЗУ? А можете прислать проект на почту посмотреть? Подобных обращений еще не встречал. Просто, чтобы забить ПЗУ визу картинками (а этот индикатор заполняется исключительно от картинок) нужно прямо сильно постараться :)

---

отправил вам на email

Цитата:

---

Сообщение от melky

Один из вариантов уменьшение размера, если на экране есть возможность масштабирования, второй вариант просто уменьшен за счет удаления служебной инфы без изменения размеров. Ну вроде DPI еще уменьшал.

собственно за счет уменьшения качества картинки, но достаточном для отображения на экране в приемлемом качестве можно сократить размер занимаемой памяти.

---

Вариант, который 6кб уменьшил потребление памяти с 100 до 92, но и картинка совсем мелкая. Второй вариант, хоть и весит в два раза меньше исходника, но как было 100 так и осталось. В общем, очень сильно размер влияет ресурсы памяти.

Цитата:

---

Сообщение от Vadik2881

Вариант, который 6кб уменьшил потребление памяти с 100 до 92, но и картинка совсем мелкая. Второй вариант, хоть и весит в два раза меньше исходника, но как было 100 так и осталось. В общем, очень сильно размер влияет ресурсы памяти.

---

Прошло несколько дней, Вы что-то делали...
Хоть покажите скрин самого загруженного экрана.

Ограничились только заменой той одной картинки?
А заменить все СТАТИЧЕСКИЕ тексты, линии, фигуры на одну картинку пробовали?

Для приведённой мной картинки с тремя насосами экономия составила 20% при замене всех показанных элементов на одну картинку. Проверял на 370 версии OL в тот же самый день.

Цитата:

---

Сообщение от FPavel

Прошло несколько дней, Вы что-то делали...
Хоть покажите скрин самого загруженного экрана.

Ограничились только заменой той одной картинки?
А заменить все СТАТИЧЕСКИЕ тексты, линии, фигуры на одну картинку пробовали?

Для приведённой мной картинки с тремя насосами экономия составила 20% при замене всех показанных элементов на одну картинку. Проверял на 370 версии OL в тот же самый день.

---

Да я уже весь тут изтестировался и не особо пойму ситуацию). Есть 9 картинок похожих по содержанию и объёму. Закидываешь их в проект - памяти не хватает. Берёшь любую картинку одну и переименовываешь многократно, и можно добавлять сколько угодно без ограничения памяти. Это какой-то софтовый баг у OL. Попробуйте сами.
Прикол. Когда память уже красная за 100% и просто добавляешь ПУСТОЙ рисунок - счётчик повышается до 120 аж%. В общем тут недоделанное ПО...

Сама картинка занимает мало места на экране.

А как выглядит сам экран? Скрин можете показать?

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

И что сказали в техподдержке, представитель которой просил им прислать проект?


Вот мой пример экрана:
- Irrigation_104 всё сделано линиями и текстом и занимает 104% памяти ОЗУ визуализации
- Irrigation_85 линии и текст заменены одной картинкой и занимает 85% памяти ОЗУ визуализации

Цитата:

---

Сообщение от FPavel

Сама картинка занимает мало места на экране.

---

Кроме ОЗУ есть еще и ПЗУ, где эти картинки хранятся. Так вот, там каждая картинка примерно 11% места занимает.

Цитата:

---

Сообщение от Dimensy

Кроме ОЗУ есть еще и ПЗУ, где эти картинки хранятся. Так вот, там каждая картинка примерно 11% места занимает.

---

Не спорю.

Цитата:

---

Сообщение от Vadik2881

Да я уже весь тут изтестировался и не особо пойму ситуацию). Есть 9 картинок похожих по содержанию и объёму. Закидываешь их в проект - памяти не хватает. Берёшь любую картинку одну и переименовываешь многократно, и можно добавлять сколько угодно без ограничения памяти.

---

Мне непонятно, что проверил автор темы, в чём у него проблема и что бы ему посоветовать.
Автор опубликовал какие-то картинки с фоновым изображением. И что? Как он их применял? На одном экране или на разных? Объединял ли все статические объекты в одной картинке для сокращения использованной памяти?

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

Ну да, тоже интересно что автор с этими картинками делал. Как фон они не подходят, как образец - то же так себе

Суть проекта следующая. 9 экранов, на каждом по своей картинке. Картинки размером ровно в пол экрана. К ПР подключаются датчики расстояния и на картинке в определённых местах выводятся показания. Всё. Никак экраны между собой не связаны. Т.е. да, картинка по сути фон. Почему она не может подходить в виде фона?!

Да тупо создал новый пустой проект с одним экраном и все 9 рисунков на него закинул уменьшая масштаб, чтоб уместить, и всё так же - памяти не хватает. Помогает только если уменьшить реальное разрешение картинки, предварительно в графическом редакторе. Но только картинка потом в ПР мелкая и не хорошо получается...

Но самый прикол в том, что если тупо берём любую одну картинку и делаем ей 9 разных имён, то все они прекрасно помещаются в памяти, это как?)) Получается, алгоритм обработки изображения в OL не совершенен и одно изображение переваривает, а несколько уже не может. Так же доказывается тем, что объём проекта очень сильно увеличивается. Значит или дорабатывать или вводить ограничения.
Предположу, что выявлен серьёзный баг и странно, что только сейчас...

Ну, тогда, делайте фон не целой картинкой, а из отдельных кирпичей Вложение 87774
или, из отдельных рядов Вложение 87775

В общем, вот занимаемая память для целой картинки
Вложение 87776

а это, когда картинка из отдельных рядов построена
Вложение 87777

Не, так не прокатило, то на то и вышло, увы. Ждём ответа от разработчика.

Я еще заметил, если писать текст в разных элементах вывода статического текста, то при большом количестве таких элементов ОЗУ визуализации быстро выходит за 100%. Объединив текст в один элемент на весь экран получаем заметное снижение ОЗУ.
На картинке если весь текст писать отдельно - было 117%. При частичном объединении стало 83%.
Вложение 87804