Просмотр полной версии : ПР225 пользовательское ПЗУ визуализации 104%
Vadik2881
26.01.2026, 13:44
Приветствую.
Сейчас делаю проект на ПР225.
8 экранов, в каждом по картинке 35-50кб, всего 349кб
Индикатор пишет 100% использовано памяти ПЗУ визуализации. 1572811 байт занято из 1572864. Но в принципе всё работает и даже при 104%.
Проект грузится в панель минуты три аж и даже при 94%
Это баг какой-то?
Ещё момент, если грузить картинку размером больше чем выбрал шаблон, то owen logic уход в глухой завис.
По началу писал что максимальный размер картинки не должен превышать 430пикселей, но потом каким-то образом стал принимать 480, т.е. в полную ширину экрана.
Вот думаю так оставлять, ничего не выйдет из строя с временем???
Ещё не понял как поменять цвет экрана с белого на иной. Или много хочу от ПР))
В общем, пока как-то всё сыроватое ещё. Версия последняя.
kondor3000
26.01.2026, 13:54
ПР225 считает 104% по самому загруженному экрану (а не все экраны сразу). Меньше 80% не показывает вообще.
Разгрузите самый загруженный, а лучше убрать картинки и подложить прямоугольник нужного цвета под кнопки.
Так вы закрасите экран нужным цветом.
Лоджик не очень корректно считает видеопамять. Где-то здесь представитель Овена рекомендовал дальше 80% не заходить (от греха)
По поводу цвета экрана - прямоугольник нужного цвета в виде фона
ПР205 понимает картинки svg? или только jpg, png и т.д? даже если второе, их можно уменьшить в объеме если обработать граф редактором простеньким.
ПР205 понимает картинки svg? или только jpg, png и т.д? даже если второе, их можно уменьшить в объеме если обработать граф редактором простеньким.
Только jpg и bmp
тогда используйте jpg, некоторыми манипуляциями их можно уменьшать. Например использую для просмотра i-view и он умеет менять размеры в том числе. В общем поиграйтесь с jpg в редакторах и посравнивайте после этого размеры. с bmp не работаю обычно, может и их можно сделать меньше, но вроде вряд ли, сейчас не помню уже.
Небольшой эксперимент: круг 100*100 зеленого цвета. Картинкой в формате jpg и bmp удалось поместить 77 шт до 100% заполнения памяти. А, вот, базовый элемент "круг" удалось разместить только 17 шт
Vadik2881
26.01.2026, 18:19
ПР225 считает 104% по самому загруженному экрану (а не все экраны сразу). Меньше 80% не показывает вообще.
Разгрузите самый загруженный, а лучше убрать картинки и подложить прямоугольник нужного цвета под кнопки.
Поэкспериментировал и не нашёл этому подтверждение. Счётчик памяти всё же общий и да, появляется после 80%.
Причём, все мои рисунки 390 кб по итогу - утяжеляют проект аж на мегабайт с лишним, из-за чего он и грузится долго...
В принципе, проект получился очень красивым и реалистичным к объекту и всё работает ок. Но как бы потом не окирпичиться из-за сдохшей памяти)))
Vadik2881
26.01.2026, 18:21
тогда используйте jpg, некоторыми манипуляциями их можно уменьшать. Например использую для просмотра i-view и он умеет менять размеры в том числе. В общем поиграйтесь с jpg в редакторах и посравнивайте после этого размеры. с bmp не работаю обычно, может и их можно сделать меньше, но вроде вряд ли, сейчас не помню уже.
Перебрал все форматы и градации, и бестолку, jpeg самый оптимальный минимум.
kondor3000
26.01.2026, 18:25
Поэкспериментировал и не нашёл этому подтверждение. Счётчик памяти всё же общий и да, появляется после 80%.
Причём, все мои рисунки 390 кб по итогу - утяжеляют проект аж на мегабайт с лишним, из-за чего он и грузится долго...
В принципе, проект получился очень красивым и реалистичным к объекту и всё работает ок. Но как бы потом не окирпичиться из-за сдохшей памяти)))
Это писал инженер Овен, проверить просто, на копии программы удалите самый загруженный экран,
после сохранения появится (например 90%) это 2 по загруженности экран. Можете последовательно удалить все экраны и посмотреть.
А так же заменить (на время) свои рисунки на подложенный закрашенный прямоугольник и посмотреть разницу.
Выложите на обменник самый большой свой jpg
Vadik2881
26.01.2026, 19:05
Это писал инженер Овен, проверить просто, на копии программы удалите самый загруженный экран,
после сохранения появится (например 90%) это 2 по загруженности экран. Можете последовательно удалить все экраны и посмотреть.
А так же заменить (на время) свои рисунки на подложенный закрашенный прямоугольник и посмотреть разницу.
Так и делал). У меня экраны и рисунки практически идентичные. Нет как такого загруженного экрана. Переполнение памяти происходит на всех без исключения. Хотя один из экранов, потом в работе видно, что прогружается с некоторым запаздыванием. Но тоже пробовал менять рисунок и без результатно.
В общем, графика на ПР будем считать работает, но с некоторыми нюансами...
Vadik2881
26.01.2026, 19:08
Выложите на обменник самый большой свой jpg
Вот пример. 50кб
Для ПР205 поступал так:
- в самой ПР рисовал экран линиями, кружочками и текстами (единицы измерения, названия) - статические элементы
- запускал эмуляцию и делал скрин в масштабе, близком к разрешению экрана панели
- в графическом редакторе (или пакетном ImageMagick) обрезал и уменьшал скрин до разрешения экрана ПР
Ещё в графическом редакторе можно добавлять статические тексты меньшим шрифтом, чем в OL.
Так получал подложку.
А уже на подложку накладывал динамические объекты. Экономия памяти - бешенная.
Зачем рисовал сначала в Owen Logic - чтобы размеры фигур точно совпали - у меня были кружочки насосов.
У насоса три состояния - включён, отключён, неисправен. Вот отключён и показан на подложке.
Примерно, так же у задвижки.
На текстах экономия совсем грандиозная.
На картинке - именно подложка без динамических элементов.
Один из вариантов уменьшение размера, если на экране есть возможность масштабирования, второй вариант просто уменьшен за счет удаления служебной инфы без изменения размеров. Ну вроде DPI еще уменьшал.
собственно за счет уменьшения качества картинки, но достаточном для отображения на экране в приемлемом качестве можно сократить размер занимаемой памяти.
У меня было ощущение, что в проект загружалась картинка в одном из форматов, а после компиляции в ПР она отправлялась в каком-то самодельном внутреннем формате и уже подогнанном к размеру элемента.
В переводе на нормальный язык, мне казалось, что исходный размер картинки в проекте никак не влияет на размер картинки, которая попадает в конечном итоге в ПР. И смысла в оптимизации - нет.
Проверял загрузкой bmp на мегабайты и jpg на килобайты.
Ой, тогда как печальненько, если ОЛ выполняет обработку картинки. И превращает ее в монстра :)
а вообще, экран маленький, нужно использовать картинки на 256 цветов, думаю вполне достаточно, а не лепить туда с 16-ти млн цветов серые картинки.
В общем разработчик в лице Овен должен где-то описать рекомендации для снижения размеров и как лучше для этого создавать картинки.
Королев Кирилл
27.01.2026, 11:09
Приветствую.
Сейчас делаю проект на ПР225.
8 экранов, в каждом по картинке 35-50кб, всего 349кб
Индикатор пишет 100% использовано памяти ПЗУ визуализации. 1572811 байт занято из 1572864. Но в принципе всё работает и даже при 104%.
Проект грузится в панель минуты три аж и даже при 94%
Это баг какой-то?
Ещё момент, если грузить картинку размером больше чем выбрал шаблон, то owen logic уход в глухой завис.
По началу писал что максимальный размер картинки не должен превышать 430пикселей, но потом каким-то образом стал принимать 480, т.е. в полную ширину экрана.
Вот думаю так оставлять, ничего не выйдет из строя с временем???
Ещё не понял как поменять цвет экрана с белого на иной. Или много хочу от ПР))
В общем, пока как-то всё сыроватое ещё. Версия последняя.
Добрый день. Заполнился индикатор именно пользовательской ПЗУ визуализации, не ОЗУ? А можете прислать проект на почту посмотреть? Подобных обращений еще не встречал. Просто, чтобы забить ПЗУ визу картинками (а этот индикатор заполняется исключительно от картинок) нужно прямо сильно постараться :)
Vadik2881
29.01.2026, 16:55
Ой, тогда как печальненько, если ОЛ выполняет обработку картинки. И превращает ее в монстра :)
а вообще, экран маленький, нужно использовать картинки на 256 цветов, думаю вполне достаточно, а не лепить туда с 16-ти млн цветов серые картинки.
В общем разработчик в лице Овен должен где-то описать рекомендации для снижения размеров и как лучше для этого создавать картинки.
Да, тоже создалось такое ощущение. Потому что картинки 390кб утяжеляют проект н а мегабайт с лишним.
Vadik2881
29.01.2026, 16:56
Добрый день. Заполнился индикатор именно пользовательской ПЗУ визуализации, не ОЗУ? А можете прислать проект на почту посмотреть? Подобных обращений еще не встречал. Просто, чтобы забить ПЗУ визу картинками (а этот индикатор заполняется исключительно от картинок) нужно прямо сильно постараться :)
отправил вам на email
Vadik2881
29.01.2026, 17:09
Один из вариантов уменьшение размера, если на экране есть возможность масштабирования, второй вариант просто уменьшен за счет удаления служебной инфы без изменения размеров. Ну вроде DPI еще уменьшал.
собственно за счет уменьшения качества картинки, но достаточном для отображения на экране в приемлемом качестве можно сократить размер занимаемой памяти.
Вариант, который 6кб уменьшил потребление памяти с 100 до 92, но и картинка совсем мелкая. Второй вариант, хоть и весит в два раза меньше исходника, но как было 100 так и осталось. В общем, очень сильно размер влияет ресурсы памяти.
Вариант, который 6кб уменьшил потребление памяти с 100 до 92, но и картинка совсем мелкая. Второй вариант, хоть и весит в два раза меньше исходника, но как было 100 так и осталось. В общем, очень сильно размер влияет ресурсы памяти.
Прошло несколько дней, Вы что-то делали...
Хоть покажите скрин самого загруженного экрана.
Ограничились только заменой той одной картинки?
А заменить все СТАТИЧЕСКИЕ тексты, линии, фигуры на одну картинку пробовали?
Для приведённой мной картинки с тремя насосами экономия составила 20% при замене всех показанных элементов на одну картинку. Проверял на 370 версии OL в тот же самый день.
Vadik2881
29.01.2026, 19:47
Прошло несколько дней, Вы что-то делали...
Хоть покажите скрин самого загруженного экрана.
Ограничились только заменой той одной картинки?
А заменить все СТАТИЧЕСКИЕ тексты, линии, фигуры на одну картинку пробовали?
Для приведённой мной картинки с тремя насосами экономия составила 20% при замене всех показанных элементов на одну картинку. Проверял на 370 версии OL в тот же самый день.
Да я уже весь тут изтестировался и не особо пойму ситуацию). Есть 9 картинок похожих по содержанию и объёму. Закидываешь их в проект - памяти не хватает. Берёшь любую картинку одну и переименовываешь многократно, и можно добавлять сколько угодно без ограничения памяти. Это какой-то софтовый баг у OL. Попробуйте сами.
Прикол. Когда память уже красная за 100% и просто добавляешь ПУСТОЙ рисунок - счётчик повышается до 120 аж%. В общем тут недоделанное ПО...
Сама картинка занимает мало места на экране.
А как выглядит сам экран? Скрин можете показать?
Или удалите программу из проекта, оставьте только экраны и переменные и опубликуйте здесь.
И что сказали в техподдержке, представитель которой просил им прислать проект?
Вот мой пример экрана:
- Irrigation_104 всё сделано линиями и текстом и занимает 104% памяти ОЗУ визуализации
- Irrigation_85 линии и текст заменены одной картинкой и занимает 85% памяти ОЗУ визуализации
Сама картинка занимает мало места на экране.
Кроме ОЗУ есть еще и ПЗУ, где эти картинки хранятся. Так вот, там каждая картинка примерно 11% места занимает.
Кроме ОЗУ есть еще и ПЗУ, где эти картинки хранятся. Так вот, там каждая картинка примерно 11% места занимает.
Не спорю.
Да я уже весь тут изтестировался и не особо пойму ситуацию). Есть 9 картинок похожих по содержанию и объёму. Закидываешь их в проект - памяти не хватает. Берёшь любую картинку одну и переименовываешь многократно, и можно добавлять сколько угодно без ограничения памяти.
Мне непонятно, что проверил автор темы, в чём у него проблема и что бы ему посоветовать.
Автор опубликовал какие-то картинки с фоновым изображением. И что? Как он их применял? На одном экране или на разных? Объединял ли все статические объекты в одной картинке для сокращения использованной памяти?
Мне кажется, что автору бы неплохо удалить все макросы из программы и опубликовать проект - чтобы можно было увидеть и попытаться что-то посоветовать.
Ну да, тоже интересно что автор с этими картинками делал. Как фон они не подходят, как образец - то же так себе
Vadik2881
30.01.2026, 08:33
Суть проекта следующая. 9 экранов, на каждом по своей картинке. Картинки размером ровно в пол экрана. К ПР подключаются датчики расстояния и на картинке в определённых местах выводятся показания. Всё. Никак экраны между собой не связаны. Т.е. да, картинка по сути фон. Почему она не может подходить в виде фона?!
Да тупо создал новый пустой проект с одним экраном и все 9 рисунков на него закинул уменьшая масштаб, чтоб уместить, и всё так же - памяти не хватает. Помогает только если уменьшить реальное разрешение картинки, предварительно в графическом редакторе. Но только картинка потом в ПР мелкая и не хорошо получается...
Но самый прикол в том, что если тупо берём любую одну картинку и делаем ей 9 разных имён, то все они прекрасно помещаются в памяти, это как?)) Получается, алгоритм обработки изображения в OL не совершенен и одно изображение переваривает, а несколько уже не может. Так же доказывается тем, что объём проекта очень сильно увеличивается. Значит или дорабатывать или вводить ограничения.
Предположу, что выявлен серьёзный баг и странно, что только сейчас...
Ну, тогда, делайте фон не целой картинкой, а из отдельных кирпичей 87774
или, из отдельных рядов 87775
В общем, вот занимаемая память для целой картинки
87776
а это, когда картинка из отдельных рядов построена
87777
Vadik2881
30.01.2026, 19:40
Не, так не прокатило, то на то и вышло, увы. Ждём ответа от разработчика.
Я еще заметил, если писать текст в разных элементах вывода статического текста, то при большом количестве таких элементов ОЗУ визуализации быстро выходит за 100%. Объединив текст в один элемент на весь экран получаем заметное снижение ОЗУ.
На картинке если весь текст писать отдельно - было 117%. При частичном объединении стало 83%.
87804
Vadik2881
02.02.2026, 10:49
Провёл эксперимент. Все мои рисунки прекрасно уместились в ПР205, память заполнена на 46%. Картинки уменьшены под экран ПР205.
Так что ПР225 ещё пока недоведена до ума... Имеет достаточно мощный функционал по периферии и управлению, но ограничена в визуализации. Солидный проект на ней будет сложнова-то сделать.
Провёл эксперимент. Все мои рисунки прекрасно уместились в ПР205, память заполнена на 46%. Картинки уменьшены под более меньший экран ПР205
Так что ПР225 ещё пока недоведена до ума... Имеет достаточно мощный функционал по периферии и управлению, но ограничена в визуализации. Солидный проект на ней будет сложнова-то сделать.
Здесь разработчики немного промахнулись - экранчик увеличился, а память под картинки осталась прежняя
Сергей0308
02.02.2026, 12:50
Здесь разработчики немного промахнулись - экранчик увеличился, а память под картинки осталась прежняя
Так ещё не вечер, может флешку припаяют или ОЗУ, в смысле, чего не будет хватать!
Сергей0308
03.02.2026, 14:42
тогда используйте jpg, некоторыми манипуляциями их можно уменьшать. Например использую для просмотра i-view и он умеет менять размеры в том числе. В общем поиграйтесь с jpg в редакторах и посравнивайте после этого размеры. с bmp не работаю обычно, может и их можно сделать меньше, но вроде вряд ли, сейчас не помню уже.
Так "bmp" это не сжатый формат, конечно можно уменьшить размер файла в несколько десятков раз с потерей качества изображения, сжав его в формате "ipg", и для наших целей это больше подходит, для экрана ПР не нужна картинка высокого разрешения и студийного качества!
Сергей0308 вы знаете что делает ОЛ при "копировании" рисунка в ПР? вполне вероятно, приводит все к bmp, чтобы ПР потом не перетруждался. То есть все приводится к пикселям, тем самым, увеличивая файл проекта.
От Овен так никто и не "выступил" с объяснениями
Сергей0308
03.02.2026, 14:53
Сергей0308 вы знаете что делает ОЛ при "копировании" рисунка в ПР? вполне вероятно, приводит все к bmp, чтобы ПР потом не перетруждался. То есть все приводится к пикселям, тем самым, увеличивая файл проекта.
От Овен так никто и не "выступил" с объяснениями
Ну а зачем им что-то объяснять, в смысле, дело уже сделано!
Несжатый формат требует минимум ресурсов ПР, это похоже на правду!
поэтому png был бы предпочтительным вариантом, есть компрессия и прозрачность.
поэтому png был бы предпочтительным вариантом, есть компрессия и прозрачность.
Мне кажется, обработка изображений - отнюдь не самое однозначное дело.
Пример.
Сделайте скрин png какой-нибудь программы в OwenLogic.
Обработайте его пакетом сжатия без потерь FileOptimizer
Уменьшите размер изображения в 2 раза
Снова сожмите.
И вот в этом месте будет удивление - уменьшенный в размерах файл будет по размерам больше исходного на 50%.
Произойдёт это из-за размытия цветов пикселей при кубической интерполяции при уменьшении размера. Т.е. сжать будет уже невозможно - в исходном были одинаковые соседние пиксели, а в уменьшенном - сильно разные, плохо поддающиеся сжатию.
А т.к. счастья нет, то для изображений 240х320 можно выбрать и несжатый формат.
Или обязать полуграмотного пользователя самостоятельно готовить изображения под сильное сжатие и только заданного размера и глубины цвета, что вызовет недовольство - мол у конкурентов всеядные компоненты берут всё, что дают.
Поэтому лично я просто принял такую ситуацию с изображениями, как данность.
Прикреплю пример png до и после уменьшения размера 100% и 70% от исходного и обработкой по оптимизации
Результаты:
исходный файл 100% размер - 16809 байт
уменьшенный файл 70% размер - 58593 байт
Королев Кирилл
04.02.2026, 12:30
Прибору, действительно, не важно в каком формате будет загружено изображение в редактор визуализации. Расчет Пользовательского ПЗУ визуализации для изображений - Ширина х Высота х 2. Важно заметить, что в расчет берется исходное изображение, которое загружается в редактор визуализации, а не скорректированные размеры уже в редакторе. Это позволяет использовать копипасту одних и тех же изображений без увеличения занимаемого Пользовательского ПЗУ визуализации.
Прибору, действительно, не важно в каком формате будет загружено изображение в редактор визуализации. Расчет Пользовательского ПЗУ визуализации для изображений - Ширина х Высота х 2. Важно заметить, что в расчет берется исходное изображение, которое загружается в редактор визуализации, а не скорректированные размеры уже в редакторе. Это позволяет использовать копипасту одних и тех же изображений без увеличения занимаемого Пользовательского ПЗУ визуализации.
Можно это пояснение поместить в справку и РЭ на Owen Logic?
А то гадания на форуме - не самое лучшее занятие.
Теперь понятно, что есть смысл уменьшения размера исходного файла перед загрузкой в проект.
И с повторным использованием - тоже.
Т.е. автору вопроса действительно нужно взять одну маленькую плиточку и ею сделать большой фон - как ему и предлагали.
Королев Кирилл
04.02.2026, 12:41
Можно это пояснение поместить в справку и РЭ на Owen Logic?
А то гадания на форуме - не самое лучшее занятие.
Теперь понятно, что есть смысл уменьшения размера исходного файла перед загрузкой в проект.
Да, конечно. В ближайшем релизе подтянем справку. Будет табличка занимаемого ОЗУ визу элементами визуализации, а также информация про расчет занимаемого Пользовательского ПЗУ визу для изображений.
Vadik2881
06.02.2026, 16:25
Теперь понятно, что есть смысл уменьшения размера исходного файла перед загрузкой в проект.
И с повторным использованием - тоже.
Т.е. автору вопроса действительно нужно взять одну маленькую плиточку и ею сделать большой фон - как ему и предлагали.
Это не сработало, я же писал! Точнее имелось ввиду нарезать большое фото на много мелких. А вариант из плиточки собрать деталь, как вы это себе представляете))
Ну может редких случаях и можно...
Vadik2881
06.02.2026, 16:30
Прибору, действительно, не важно в каком формате будет загружено изображение в редактор визуализации. Расчет Пользовательского ПЗУ визуализации для изображений - Ширина х Высота х 2. Важно заметить, что в расчет берется исходное изображение, которое загружается в редактор визуализации, а не скорректированные размеры уже в редакторе. Это позволяет использовать копипасту одних и тех же изображений без увеличения занимаемого Пользовательского ПЗУ визуализации.
Да это в принципе и так было ясно...
Так что с моими проектом, а то тишина от Вас... Хотя в принципе, у меня всё работе уже, с такой переполненной памятью.
Это не сработало, я же писал! Точнее имелось ввиду нарезать большое фото на много мелких. А вариант из плиточки собрать деталь, как вы это себе представляете))
Ну может редких случаях и можно...
Вот так, как в тестовом проекте - на одном экране из отдельных плиточек, а на другом целый рисунок.
Не идеально, но отдалённое сходство между ними присутствует.
Если на выбор - ничего или с небольшими визуальными допущениями - я бы предпочёл второе.
Вот так, как в тестовом проекте - на одном экране из отдельных плиточек, а на другом целый рисунок.
Не идеально, но отдалённое сходство между ними присутствует.
Если на выбор - ничего или с небольшими визуальными допущениями - я бы предпочёл второе.
Я уже предлагал подобное https://owen.ru/forum/showthread.php?t=42422&p=479058&viewfull=1#post479058
Да, именно об этом и говорил.
Но на тот момент это была интуитивная догадка, работающая, возможно, только для конкретной версии OwenLogic, а после уточнения представителя Овен - это уверенное хорошее решение.
Powered by vBulletin® Version 4.2.3 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot