Столкнулся с проблемой, с которой, думаю, сталкивался любой программист-асушник. Нехватка пользовательской памяти.
Имеется контроллер CompactLogix L31. 512Кбайт на борту. Как оказалось это очень немного (
Что сразу приходит на ум, так это компановка переменных. Битовые переменный хранить в массиве DINTa.
Ужимать DINTовские переменные в INTы смысла нету, т.к. весить они будут все равно 4байта.
Заметил, что комментарии тоже занимают место в памяти (для возможности полноценной выгрузки проекта).
Может кто поделится опытом, к каким приемам прибегаете вы в данных случаях (кроме как покупка более мощного контроллера))
Что это за такая программа у вас? Сколько ввода/вывода?
ferzio писал(а):
Добрый день!
Столкнулся с проблемой, с которой, думаю, сталкивался любой программист-асушник. Нехватка пользовательской памяти.
Имеется контроллер CompactLogix L31. 512Кбайт на борту. Как оказалось это очень немного (
Что сразу приходит на ум, так это компановка переменных. Битовые переменный хранить в массиве DINTa.
Ужимать DINTовские переменные в INTы смысла нету, т.к. весить они будут все равно 4байта.
Заметил, что комментарии тоже занимают место в памяти (для возможности полноценной выгрузки проекта).
Может кто поделится опытом, к каким приемам прибегаете вы в данных случаях (кроме как покупка более мощного контроллера))
Небольшой проект ~100Di ~50Do ~10Ai ~2Dc +Интерфейсные сигналы через MVI
Переменные и типы данных это пол беды .. на самом деле не так и много они занимают. Я так понял основное место занимает код (исходник). При добавлении ~30 строк кода (операции присваивания) размер проекта увеличился на 4Кбайта!
Можно как-нибудь сделать чтобы исходник не зашивался в память?
Что сразу приходит на ум, так это компановка переменных. Битовые переменный хранить в массиве DINTa.
Ужимать DINTовские переменные в INTы смысла нету, т.к. весить они будут все равно 4байта.
Ну это совершенно не так. Просто надо пользоваться предусмотренными для этих целей инструментами, а именно "User Defined Data Types".
Структуры выравниваются по четырем байтам, но внутри все упаковывается плотно (конечно, если не будете чередовать байты и реалы). Поэкспериментируйте с ними и всё станет понятно, при сохранении сразу размер расчитывается и показывается.
ferzio писал(а):
Заметил, что комментарии тоже занимают место в памяти (для возможности полноценной выгрузки проекта).
Настоящие программисты-асушники пишут на чём правильно, а не на чём легче
Пишите на Ladder, а не на ST - и комментарии и исходник будут исключительно в файле проекта на компе, а в контроллере только компактный программный код.
ЗЫ
и исполняться программа будет в разы быстрее
Спасибо! Фишку UDDT уже уловил и активно этим пользуюсь.
А вот про языки стало для меня открытием.
Слыхал мнения тру-асушников что не стоит программировать контроллер на ST и Cи, но не сталкивался с доказательствами. Вот пожалуй первая ласточка.
Тогда вопросы вдогонку по языкам на AB: IL - исходник копируется в контроллер?
Нет случайно возможности конвертации одного языка в другой?
И почему такая несправедливость к ST
оп .. что-то я тупанул, IL нету, LADы естественно есть.
На них я и собирался всю технологию писать. А вот типовые задачи (обработка Di, Do, Ai ...) хотелось написать на чем-то более человечном, типа ST
Ну если на человечном, то памяти никогда не будет хватать. 95% АСУТП-х задач пишутся на LD и FB.
А что имелось ввиду под типовыми задачами(обработка Di, Do, Ai ...)?
ferzio писал(а):
оп .. что-то я тупанул, IL нету, LADы естественно есть.
На них я и собирался всю технологию писать. А вот типовые задачи (обработка Di, Do, Ai ...) хотелось написать на чем-то более человечном, типа ST
Типовые задачи ( Di, Do, Ai ...) - задачи для гибкой настройки соответствующих сигналов Di, Do, Ai ... (инверсии, фильтрации, возможность маскирования, различные поправочные коэф. и еще миллиард настроек .. ), которые присутствуют во всех проектах, независимо от технологии
Все эти настройки как правило относятся к свойствам модулей. Поверьте их там много. И их можно менять на ходу.
Видел такой пример. Программа писалась для одного обьекта, т.е исходные условия были абсолюно одинаковыми. Первый писал на LD и FB. Второй писал на структурном тексте как вы. У 1-го обьем 50КВ, у 2-го 1МВ!!!!!!. Время выполнения соответственно различалось пропорционально, при том что это был критический параметр.
Вы пытаетесь подменить разработчикой системы.
Еше. Программа написанная простым способом, будет понятна всем. Программа написанная вашим способом, будет понятна только вам.
ferzio писал(а):
Типовые задачи ( Di, Do, Ai ...) - задачи для гибкой настройки соответствующих сигналов Di, Do, Ai ... (инверсии, фильтрации, возможность маскирования, различные поправочные коэф. и еще миллиард настроек .. ), которые присутствуют во всех проектах, независимо от технологии
В этом и загвоздка. На LADах проблем написать нету. Просто есть уже наработки на Си и перенести это на ST легче, чем на графические языки.
Посмотрел настройки модулей - нашел только на AIшки, возможно из-за того что всё железо довольно бюджетное. Плюс "пользовательских" настроек в том что их можно переносить с контроллера на контроллер (независимо от производителя и типа модулей).
По поводу размера программы - в 20 раз это существенно. Сам написал ~20 строк когда на ST и перевел этот код на LAD. Код ST оказался на 3 с лишним Кбайт тяжелее (
В этом и загвоздка. На LADах проблем написать нету. Просто есть уже наработки на Си и перенести это на ST легче, чем на графические языки.
Посмотрел настройки модулей - нашел только на AIшки, возможно из-за того что всё железо довольно бюджетное. Плюс "пользовательских" настроек в том что их можно переносить с контроллера на контроллер (независимо от производителя и типа модулей).
По поводу размера программы - в 20 раз это существенно. Сам написал ~20 строк когда на ST и перевел этот код на LAD. Код ST оказался на 3 с лишним Кбайт тяжелее (
Для Logix - LD самый быстрый и легкий (по отношению к памяти).
Использование FB и AOI минимизируй, т.к. для каждой команды создается своя структура (будет расход памяти).
Код:
BST XIC a OTE b NXB XIC c OTE d NXB XIC e OTE f BND
экономит память по сравнению с тремя отдельными строками.
Этот эффект был обнаружен для MicroLogix 1000 и было очень актуально.
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
Smart Solutions VDT GmbH | Friedrich-List-Allee 38, D-41844 Wegberg-Wildenrath, Germany Tel.: +49 2432 933 57 83 | e-Mail: office@vdt-solutions.de Все товарные знаки и торговые марки являются собственностью их владельцев.
При использовании материалов сайта ссылка на данный сайт обязательна. Открытие страницы: 0.132 секунды
FAQ
Поиск
Группы
Профиль
Войти и проверить личные сообщения
Вход
