Переполнена EEPROM в SMArt

[Shurion]

Создал проект, успешно загрузил его в контроллер.
Выскочила ошибка "переполнение EEPROM".

1) Чем чревато для проекта и работы плк переполнение EEPROM?
2) Не должен ли Logix указывать на превышение EEPROM до загрузки в плк?

[Ilya J.]

Приложите проект.

[Arsie]

Сообщение от Shurion

1) Чем чревато для проекта и работы плк переполнение EEPROM?

Для работы ПЛК ничем. Для проекта - неработоспособностью части блоков памяти. Тех, что за границу выходят. Подробнее в справке про блоки памяти. С картинками.

Сообщение от Shurion

2) Не должен ли Logix указывать на превышение EEPROM до загрузки в плк?

До загрузки в ПЛК лоджик не знает, вставили вы модуль памяти в этот ПЛК или не вставили.

[Shurion]

Сообщение от Arsie

Для работы ПЛК ничем. Для проекта - неработоспособностью части блоков памяти. Тех, что за границу выходят. Подробнее в справке про блоки памяти.

Посмотрел, у меня таких блоков нет. Методом тыка определил что EEPROM сжирает элемент-экран " меню настроек".

Вот только мне не совсем понятно, почему? Ведь я ничего не сохраняю, а только вывожу на экран

[Arsie]

Сообщение от Shurion

Вот только мне не совсем понятно, почему? Ведь я ничего не сохраняю, а только вывожу на экран

Такова селяви. Для меню в SMArt всегда выделяется память.

[Shurion]

Сообщение от Arsie

Такова селяви. Для меню в SMArt всегда выделяется память.

С блоками "Вывод числа" такая же ситуация. Зачем смарт резервирует EEPROM если его (по идеи) не использует?

UPDATE: не, это не так, блок "Вывод числа" не затрагивает EEPROM.

[Arsie]

Сообщение от Shurion

С блоками "Вывод числа" такая же ситуация. Зачем смарт резервирует EEPROM если его (по идеи) не использует?

Память выделяется единым куском от начала до конца всех параметров, а какие из них вы пишете, а какие нет - это всё существует внутри этого единого куска.

[Shurion]

Сообщение от Arsie

Память выделяется единым куском от начала до конца всех параметров, а какие из них вы пишете, а какие нет - это всё существует внутри этого единого куска.

Понял, спасибо.
Буду думать как сократить.

Правда это максимально глупо, получается куча памяти не задействована и заблокирована.
P.s. По шапке надо дать разработчику))Моё ИМХО

[Arsie]

Сообщение от Shurion

Понял, спасибо.
Буду думать как сократить.

Правда это максимально глупо, получается куча памяти не задействована и заблокирована.
P.s. По шапке надо дать разработчику))Моё ИМХО

Любой фреймворк в любом языке программирования требует накладных расходов, давая взамен упрощение программирования. Чем универсальнее фреймворк, тем больше он отжирает из-за накладных расходов своей универсальности.

Даже простейший пример на винде: Win11 даёт вам интерфейс плюс-минус такой же, как и Win95. Т.е. нет ничего такого в Win11, чего нельзя сделать с окошками в Win95. Но Win11 жрёт даже не в разы, а на порядки больше, чем Win95, давая взамен много бОльшую стабильность работы ПО на компьютере.

[Shurion]

Сообщение от Arsie

Любой фреймворк в любом языке программирования требует накладных расходов, давая взамен упрощение программирования. Чем универсальнее фреймворк, тем больше он отжирает из-за накладных расходов своей универсальности.

Здесь наверняка сработала скорее лень разработчика, чем ограничение вызванное мощностными затратами.
как минимум добавить точно такой же элемент экран, но который не взаимодействует с EEPROM не составило бы труда.

А так получается "покупайте доп. модуль EEPROM" пока мы ради универсальности заблокировали всю память контроллера просто так.

[Arsie]

Сообщение от Shurion

Здесь наверняка

Вы всегда можете отказаться от SMArt и использовать FBD. Это сэкономит и память и само количество FBD-блоков.