Код на SCL - есть ли преимущество?

[Franc]

Доброе время суток всем!
Инструмент: ТИА 16.
Обычно программирую на языке LAD, однако, жизнь заставила использовать SCL.
Вопрос вот в чём. Вот фрагмент кода на SCL из функционального блока. После компиляции
размер блока в work memory равен 6300 байт. Если же удалить эти два нетворка, то после компиляции размер блока в work memory равен 710 байт.
Вопрос - почему код на SCL занимает такой большой объём?
Грубо, разница почти в 6 КБ. Я весьма удивлен таким расходом памяти, учитывая что у S7-1200 её и так немного. У меня напрашивается вывод, что SCL не лучший вариант для программирования.

[AlexandrGr]

А еще для SCL требуется STEP 7 Professional, если я не ошибаюсь. А это другие деньги.

[Franc]

Больше интересует техническая сторона вопроса (насчёт такого неумеренного потребления памяти). Или, SCL не очень для S7-1200, а лучше для продвинутого S7-1500?

[AlexandrGr]

У меня не было проблем с SCL и S7-1200. Совсем не было.
P.S. Кроме требования заказчика писать в LAD.

[keysansa]

Вопрос - почему код на SCL занимает такой большой объём?

Потому, что кроме кода - есть много вызовов FB, которые тоже место в памяти забирают на внутренние статические переменные.

[Franc]

В общем, всё-таки нужно немного предыстории. Сама ФБ, из которой фрагменты SCL, является альтернативным вариантом того же алгоритма, только на языке LAD. Конечно же, на LAD используются его инструкции - MOVE_BLK и FILL_BLK. Ну и пересылка тех же данных, только хранящихся в виде массивов в одном DB (а во втором варианте, что с вставками SCL данные в виде отдельных DB). Так вот, вариант на языке LAD занимает что-то около 660 байт! То есть, требует памяти в 10 раз меньше! Вот это-то и смущает.
Ясно, что мы имеем дело с реальностью как она есть, но всё-таки!

[VADR]

Сама ФБ, из которой фрагменты SCL, является альтернативным вариантом того же алгоритма, только на языке LAD.

Можно посмотреть, как на LAD реализованы первые три строки с первого скрина? В частности - функция DB_ANY_TO_VARIANT. И вообще интересна работа с типом VARIANT на LAD. Сдаётся мне, что там всё не так уж и одинаково.

[petr2off]

А если на IL писать наверно еще чутка ужатся нужно. Мне кажется сама постановка вопроса не корректна.
Я когда кодирую ПЛК всегда стараюсь писать на LAD или FDB, просто потому, что отладка становится проще и наглядней, да и сами инструменты заставляют думать в рамках релейно - дискретной логике.
Но иногда прихожится реализовывать какой то логически ориентированный алгоритм, связанный например с обработкой массива (делал как то медианный фильтр, попробуйте тренировки ради его на LAD реализовать) или сильно ветвистой логики, когда в зависимости от сочетания параметров должны выполнятся разные куски кода. Здесь SCL смотрится очень естественно и логично.
Основным фактором, определяющим выбор инструмента является задача, а не размер памяти.
На мой взгляд конечно.

[Franc]

Простого вопроса и простого ответа не получилось.

В общем, всё началось с задачи обмена по MODBUS RTU с некоторым
множеством слэйвов, весьма разнообразных по составу карт памяти.
С одними блоками нужен был обмен чтение-запись, с другими только чтение,
с третими чтение, а запись по требованию (записать уставки).

Размер карт памяти тоже разный, от 1 слова до 120 (операторская панель).
Схема данных была выбрана следующая. Буфер мастера представляет собой массив
с наибольшей длиной карты слэйва (пусть 120 слов).

Буферы слэйвов для чтения и для записи хранились в отдельных блоках
тоже в виде массивов (двухмерных). Соответственно, у всех буферов для чтения размер был одинаков
(по наибольшему, например, 15 слов), и у буферов записи размер массивов устанавливался по
наибольшему (пусть 120 слов).

Итак, если в системе есть 15 слэйвов и 14 из них имеют карту +/- сопоставимых размеров,
а 15-й слэйв операторская панель с картой 120 слов, то видно, что у остальных 14
слэйвов размер буферов записи сильно избыточен. Кому-то нужно, например, 6 слов, а
приходится пользоваться массивом из 120 слов.

Приходилось мириться с таким расточительством из-за весьма удобной обработки данных
в виде массивов - перебирай себе слэйвы и буферы по индексам, нет проблем.
Однако, проект подрастал не только в части обработки MODBUS, и остаток памяти начал
подходить к концу... Да, такое бывает. Возник вопрос оптимизации программы, в том числе
и алгоритма обемена по MODBUS.

Мысль о том, что каждому слэйву можно дать индивидуальные буферы и для чтения и для записи
точно под его карту, заставила провести эксперимент. Буферы были сделаны в виде массивов, но каждый
в отдельном DB. Как перебирать DB? Это ведь не строки в массиве, доступные по индексу.
Вот и пришлось применить DB_ANY_TO_VARIANT, VariantPut, POKE_BLK.

Оба алгоритма работают, но второй - меня сильно удивил потреблением памяти.
Придется вернуться к двухмерным массивам, только вот сделать так, что бы был массив
одного размера, подходящий большинству слэйвов, а для операторской панели сделать буфер
из кратного числа таких массивов. Как это будет и получится ли, пока не знаю, это набросок.

А на LAD выглядит все просто, это фрагменты участков аналогов SCL. Как я и писал выше, используются только MOVE_BLK и FILL_BLK.
И никаких VARIANT. На первом вложении получилось что первым идёт фрагмент для чтения, хотя в программе он второй. Сейчас привожу так как в программе, только нетворков чуть больше.

[keysansa]

Возможно, SCL размещает еще отладочную (соответствие адресов именам переменных) информацию в памяти (так практически все компиляторы с Runtime Debigging действуют). Посмотрите опции компиляции SCL, возможно в "релизе" потребление будет меньше.

[POV]

Там, кроме отладки, может быть какой-нибудь контроль границ массивов включен в опциях SCL. Он тогда столько кода на таком исходнике сгенерит ...
В классическом Step7 можно было глянуть результат работы компилятора - очень помогает в понимании его работы. Я думаю и в портальной версии можно как то исхитриться. Ну и оптимизировать потом.

[keysansa]

может быть какой-нибудь контроль границ массивов включен в опциях SCL

В B&R добавление кода контроля границ массива и прочих исключений добавляет около 30кб.
Но этот код позволяет обрабатывать эти исключения.
Сам контроль всего этого уже включен на уровне библиотек ОС.

[Franc]

Посмотрел настройки для SCL. Да, есть там опции "Create extended status information", "Check ARRAY limits". Но они сброшены.
В общем, всем спасибо за обсуждение. Хотя вопрос был, скорее риторическим.
Для себя делаю вывод, что использовать SCL можно, но только тогда, когда нет ограничения по ресурсу памяти.
Всем хорошего настроения!

[Nicolayy]

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

[Михайло]

Я сейчас не помню, но какой-то из блоков типа MOVE_BLK я написал самодельный на SCL, чтобы тот не отъедал столько памяти.