ПР200

[Владимир Ситников]

И насчёт массивов, я наверно ещё не осознал их полезность, чем критиковать лучше конкретный пример привели бы, не очень заумный, чтобы понятно всем стало, это Ситникову!

Конкретный пример: очередь. Т.е. с одной стороны записываем (например, номера опустевших баков), из другой читаем (первый опустел -- его перого и будем заполнять).

В варианте олимпиады под эгидой "нет массивам" это делается как кучка SEL'ов. Начинаются игры "как поддержать очередь на 33 бака и не сломать мозг об SEL".
Да, в качестве игры это, конечно, норм.

Но вот для надёжного решения (а в пром автоматике же нужны именно надёжные решения?) должно быть ясно и прозрачно что это не 100500 SEL'ов, а очередь.
Чтобы не требовалось день изучать схему для осознания того, что хотел сказать автор.

С массивом это было бы так:
1) Объявляем массив для хранения очереди. При объявлении указываем его размер. Нужна очередь на 8? Указываем 8 в объявлении. Нужна на 48? Указываем 48. При этом не приходится добавлять и проводить связи между этими 48 SEL'ами, а просто объявили, что нам нужен массив из этих самых 48 ячеек.

2) Для записи/чтения используем две переменные. Одна указывает на порядковый номер ячейки для записи, вторая -- порядковый номер ячейки тения.

3) Запись это просто взять номер ячейки для записи, записать туда значение, увеличить переменную-индекс записи (ну и обработать случаи очередь переполнена/индекс вышел за границы). Можно себе представлять это как блок-"запись в ФБ" с параметрами "имя массива", "порядковый номер ячейки" и "записываемое значение".

4) Чтения -- берём значение из массива по порядковому номеру. Можно себе представлять это как "read from FB" с параметрами "имя массива" и "порядковый номер ячейки", а на выходе -- "результат чтения".


Очередь, стек, линия задержки, всё это гораздо проще программировать и понимать именно с массивом, а не с месивом SEL/GT блоков.

В общем, сила массива в том, что "количество ячеек" можно указать одним числом, и это исключает ошибки copy&paste, которые могут возникнуть при ручном размножении SEL'ов.
Да и потребление ресурсов у массива должно быть меньше, чем у кучки SEL'ов.


Тут кто-нибудь может сказать: "но макрос STEK это же и есть простое и понятное решение с N входами и N выходами. По названию понятно, что стек. Зачем массивы-то нужны?"
Если возникла такая мысль, то человек ничего не понял.
Вдруг в этом самом макросе STEK какая-нибудь связь неправильно проложена? Как это проверить? Как вариант упражнения: давайте я удалю какую-нибудь связь (нарисую лишнюю) и посмотрим сколько времени уйдёт у "эксперта-электронщика" на поиск ошибки, когда он будет заранее знать, что ошибка есть?

А, если нужен стек не на 8 входов, а на 33? Придётся, ведь, макрос перекраивать. Это как раз прямая возможность накосячить. Как тестировать новосозданный макрос на 33 элемента?
Даже, если имеющийся "стек на 8 элементов" был полностью протестирован (как, кстати? ведь в ОЛ нет автотестов), то новый блок придётся тестировать заново.
Запустить в эксплуатацию и ждать когда взорвётся бак?

В случае массивов же, шансов на ошибку гораздо меньше, ведь для увеличения/уменьшения длины очереди достаточно будет лишь изменить размер массива.

[Сергей0308]

Конкретный пример: очередь. Т.е. с одной стороны записываем (например, номера опустевших баков), из другой читаем (первый опустел -- его перого и будем заполнять).

В варианте олимпиады под эгидой "нет массивам" это делается как кучка SEL'ов. Начинаются игры "как поддержать очередь на 33 бака и не сломать мозг об SEL".
Да, в качестве игры это, конечно, норм.

Но вот для надёжного решения (а в пром автоматике же нужны именно надёжные решения?) должно быть ясно и прозрачно что это не 100500 SEL'ов, а очередь.
Чтобы не требовалось день изучать схему для осознания того, что хотел сказать автор.

С массивом это было бы так:
1) Объявляем массив для хранения очереди. При объявлении указываем его размер. Нужна очередь на 8? Указываем 8 в объявлении. Нужна на 48? Указываем 48. При этом не приходится добавлять и проводить связи между этими 48 SEL'ами, а просто объявили, что нам нужен массив из этих самых 48 ячеек.

2) Для записи/чтения используем две переменные. Одна указывает на порядковый номер ячейки для записи, вторая -- порядковый номер ячейки тения.

3) Запись это просто взять номер ячейки для записи, записать туда значение, увеличить переменную-индекс записи (ну и обработать случаи очередь переполнена/индекс вышел за границы). Можно себе представлять это как блок-"запись в ФБ" с параметрами "имя массива", "порядковый номер ячейки" и "записываемое значение".

4) Чтения -- берём значение из массива по порядковому номеру. Можно себе представлять это как "read from FB" с параметрами "имя массива" и "порядковый номер ячейки", а на выходе -- "результат чтения".


Очередь, стек, линия задержки, всё это гораздо проще программировать и понимать именно с массивом, а не с месивом SEL/GT блоков.

В общем, сила массива в том, что "количество ячеек" можно указать одним числом, и это исключает ошибки copy&paste, которые могут возникнуть при ручном размножении SEL'ов.
Да и потребление ресурсов у массива должно быть меньше, чем у кучки SEL'ов.


Тут кто-нибудь может сказать: "но макрос STEK это же и есть простое и понятное решение с N входами и N выходами. По названию понятно, что стек. Зачем массивы-то нужны?"
Если возникла такая мысль, то человек ничего не понял.
Вдруг в этом самом макросе STEK какая-нибудь связь неправильно проложена? Как это проверить? Как вариант упражнения: давайте я удалю какую-нибудь связь (нарисую лишнюю) и посмотрим сколько времени уйдёт у "эксперта-электронщика" на поиск ошибки, когда он будет заранее знать, что ошибка есть?

А, если нужен стек не на 8 входов, а на 33? Придётся, ведь, макрос перекраивать. Это как раз прямая возможность накосячить. Как тестировать новосозданный макрос на 33 элемента?
Даже, если имеющийся "стек на 8 элементов" был полностью протестирован (как, кстати? ведь в ОЛ нет автотестов), то новый блок придётся тестировать заново.
Запустить в эксплуатацию и ждать когда взорвётся бак?

В случае массивов же, шансов на ошибку гораздо меньше, ведь для увеличения/уменьшения длины очереди достаточно будет лишь изменить размер массива.

Вот у меня есть такой макрос:

EEPROM.PNG

Чем он не дотягивает до массива(способ создания опустим)? На сколько понял на запись счётчик поставить, чтобы каждый раз увеличивал на единицу адрес ячейки записи, на чтение не очень понятно и надо ли там какие связи "налаживать", а то у меня все ячейки независимые, никак между собой не связаны?
Вот, на всякий случай проект с макросом:

[Владимир Ситников]

Чем он не дотягивает до массива(способ создания опустим)?

Вот тут я отвечал на этот же вопрос:

Повторяю по буквам:
1) Запросто может оказаться, что какая-нибудь связь пошла не туда, не подключилась, или лишняя связь.
2) В ОЛ отсутствует понятие автоматических тестов. Т.е. пощёлкать на 2-3-4 элемента ещё можно, а вот найти ошибку, что "30 и 31ый элементы перепутаны" крайне затруднительно.
3) Потребление ресурсов ПР будет чрезмерным. Например, линия задержки из 400 SEL'ов будет выполнять как минимум 400 операций в каждом цикле ПР. Каждая SEL ячейка будет "пересохранять значение". В случае же массива, добавление/чтение записи это лишь пара целочисленных операций с индексами. Т.е. не 400 операций, а 3-4.

И чуть позже дополнял: http://www.owen.ru/forum/showthread....l=1#post237637

Да, в вашем проекте вместо линий задержки используются переменные, но это всё равно не исключает шанса на ошибку (выбор не той переменной). И всё равно ПР проводит все-все-все вычисления на каждом цикле.

С массивом не пришлось бы переливать из пустого в порожнее весь набор данных на каждом цикле ПР.