Вот фирменное описание, если что))):Сообщение от melky
Запуск чтения — назначается переменная булевского типа (командная переменная) для принудительного чтения настраиваемой переменной: если значение командной переменной меняется с 0 на 1, мастер инициирует запрос на чтение, после успешного выполнения запроса значение командной переменной автоматически меняется с 1 на 0;
msl272 ну на ПР200 это не прокатывало. Было даже видео от Юрия Ревака с диаграммами. Если добавили то хорошо, вопрос а добавили ли? и в каких моделях ПР?
добавлю. В любом случае при нулевой "командной переменной" чтения происходить не должно.
В ПР, действительно, команда Запуск чтения не блокирует циклический опрос (который работает на уровне добавляемого slave-устройства), указываемый в параметре Период опроса.
Фактически, Запуск чтения - это не разрешение на отправку запросов с функцией чтения, а команда однократного принудительного чтения.
Скорее, соглашусь, что ожидаемое поведение - это именно запрет/разрешение. Однако, такое поведение было всегда. И если его изменить, то может нарушиться работа уже существующих пользовательских проектов при обновлении до актуальных версий ПО.
P.S. во втором поколении (ПР103, 205, 225) есть возможность настраивать период опроса индивидуально для каждой переменной, что позволяет задать его равным 0 и оставить чтение исключительно по команде.
Инженер по продукту | ПР и Owen Logic
email: k.korolev@owen.ru
Замечание/предложение по экранам второго поколения:
При переносе экранов или отдельных графических элементов с ПР225 на ПР205 - не переносятся элементы, которые "не помещаются" в меньшее разрешение.
Было бы удобнее предлагать варианты:
- не переносить
- сдвинуть в "рамку экрана" с сокращением длины/ширины, если необходимо
- перенести не вместившиеся в верхний левый угол для самостоятельного "размещения"
И, конечно, тут прям просится возможность "размещения элементов "в воздухе", чтобы было удобнее компоновать элементы экрана. А что делать с элементами вне окна видимости: не компилировать в программу (пропускать) или ругаться на ошибку визуализации... лучше первое. В таком случае можно было бы иметь "универсальные переносимые экраны между проектами", итоговый вид которых бы определялся теми элементами, которые попали в компилируемое разрешение экрана.
И когда добавите ещё размеры шрифтов??
(16 -> 32 слишком большой шаг)
Последний раз редактировалось kaftanati; 12.10.2026 в 12:03.
Дважды плюсую
Только это не поможет. На шрифты слишком много памяти надо, которой и так там не хватает.
Тоже по шрифтам в чек боксах!!!
Я не понимаю, а что жалко добавить шрифты поменьше не 16-32-48, а еще хотя бы 10-12 добавить, а то надписи не помещаются:
2026-10-14_105828.png
Могу посоветовать костыль - оставить чекбоксы без текста, а сам текст (все тексты этого экрана) реализовать на картинке-подложке - при этом можно подбирать любые размеры щрифтов. После сохранения картинки буквы потеряют резкие очертания, пиксели будут разной градации серого, что при просмотре на настоящем экране очень хорошо скажется.
Так делал тексты Arial, 8 на ПР205 - хорошо получилось, хотя у меня были сомнения.
Пользуюсь графическим редактором Gimp для текстов, линий, возни с отдельными пикселями, и редактором Paint для фигур (эллипсы-окружности, прямоугольники).
Gimp позволяет работать со слоями и перемещать тексты, менять гарнитуру. Поэтому именно для работы с текстом - рекомендую Gimp.
Есть ещё векторный онлайн-редактор на сайте draw.io - тоже работа со слоями, много готовых фигур. В нём делал картинки подложки для сенсорных панелей, сохранял в png.
Ну можно и так, только я все же за то что бы сама OwenLogic, была способна выдавать более широкий диапазон шрифтов...
Хотя да, вы мне подсказали хорошую идею, но это уже будет реализовываться в других проектах, этот я уже не хочу переделывать!
Ваши права
Ответить с цитированием