Вы правильно поняли мой вопрос. Читаю функцией 01
Вы правильно поняли мой вопрос. Читаю функцией 01
Добрый день!
Столкнулся со следующей проблемой на ПР205. Имеется достаточно объемный проект, который переезжает с ПР200. При попытке отрисовать все нужные экраны катастрофически не хватает ОЗУ визуализации. Имеется около 80 уставок для редактирования, доступно 28672 байта ОЗУ, при этом 1 поле ввода-вывода переменной занимает 820 байт. Простой расчет показывает что всего объема ОЗУ не хватит даже на 35 переменных, не считая всего остального оформления. Вот пример простого экрана, который в одиночку выжирает 38% ОЗУ.
capture_20260614134903487.bmp
Есть какие-то варианты работы с экраном ПР205 чтобы хоть как-то это уместить?
Вообще кажется странным, что ОЗУ визуализации задействуется даже на неактивных экранах, обычно они подгружаются в момент перехода на них.
По ПЗУ визуализации нареканий нет, влезает аж 10 монохромных бмп 320х240 что для ПР достаточно много.
Мне кажется, что 38% ОЗУ - это для максимально нагруженного экрана из множества всех экранов.Сообщение от GeLeX
Для уменьшения объёма памяти можно статические элементы (текст, линии) сделать в виде картинки.
В декабре делал проект на ПР205 с ОЗУ визуализации 99% - в основном за счёт главного экрана (57 анимированных элемента). Остальные экраны вводили 60 параметров, хотя суммарно вместе с отображением состояний - около 130 параметров показывалось или вводилось.
Так что должно хватить памяти на все 80 параметров.
И ещё, представитель Овен утверждал, что рисунки в памяти ПР хранятся в исходном виде, т.е. я бы хранил не bmp, а в сжатом формате jpg - это тоже уменьшит потребление памяти.
Последний раз редактировалось FPavel; 14.06.2026 в 19:39.
Да, такой вариант рассматривался, что можно хранить всю статику в виде картинок (и в случае экранов с текстом как раз монохромный бмп занимает меньше объема чем жпег), но я проверил экспериментально, что пустой проект с 35 полями ввода/вывода занимают 99% ОЗУ.
P.S. это верно для ПР 1211, сейчас увидел что в модификации 1816 памяти более чем в 2 раза больше. Что конечно лучше, но всё равно не влезет. Так же обнаружил, что не важно какого размера картинка, на неё по умолчанию выделяется 150КБ ПЗУ зачем-то, хоть сама картинка 9 КБ занимает места. Очень много вопросов к выделению памяти
Последний раз редактировалось GeLeX; 14.06.2026 в 22:23.
Проверил - одна и та же картинка в формате bmp и jpg занимает в ПЗУ один и тот же размер
Лоджик показывает заполненность ОЗУ по самому большому экрану. Попробуйте свой экран, который 38% ОЗУ сжирает просто продублировать несколько раз. Объем занимаемой ОЗУ не поменяется
Проверял по другому. Когда мне Лоджик выдал ошибку, что памяти не хватает, я просто удалил для теста этот экран и ОЗУ уменьшилось с 110% до 72% сразу.
Сейчас проверил и действительно, получается размер самого большого экрана отображает, и это просто экран на 110% ОЗУ съел. Моя невнимательность получается, тогда всё реально. Спасибо.
И с ПЗУ вроде разобрался. Действительно пересохраняет в свой формат, зависит только от разрешения картинки память
Последний раз редактировалось GeLeX; 15.06.2026 в 00:10.
Так вроде не так давно представитель Овена объяснял, что создаётся своя картинка и в своём формате, в смысле, не важен формат и размер исходной картинки!
В той теме(если кто найти хочет), ТС хотел сделать фон с минимальными затратами ресурсов.
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
Возможно вы кидаете картинку с 16 млн цветов и он ее преобразует в bmp так же с 16 млн цветов, отсюда она и становится огромной. (предположительно)
Не, в этом плане Лоджик умный - он преобразует картинку в 16 бит
Ваши права
Ответить с цитированием