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