Разработчикам: многовходовые И, ИЛИ через меню по кнопке мыши, а также И-НЕ, ИЛИ-НЕ

[Kliper]

Очередное, и наверное опять безответное обращение к разработчикам.
Каскады из этих элементов занимают место и некрасивы.
Просьба сделать элементы И, ИЛИ многовходовыми. Добавление/убавление входов или их числа можно реализовать по правой/левой кнопке мыши.
Также было бы неплохо увидеть базовые компоненты И-НЕ, ИЛИ-НЕ (с кружочком на "хвостике").

[kondor3000]

Очередное, и наверное опять безответное обращение к разработчикам.
Каскады из этих элементов занимают место и некрасивы.
Просьба сделать элементы И, ИЛИ многовходовыми. Добавление/убавление входов или их числа можно реализовать по правой/левой кнопке мыши.
Также было бы неплохо увидеть базовые компоненты И-НЕ, ИЛИ-НЕ (с кружочком на "хвостике").

Используйте функции и ФБ на ST. Пишите уже работающий алгоритм, вместо десятков и сотен квадратов.
Кроме того есть блоки на 3-4 входа в менеджере и свои макросы никто не отменял.

[melky]

kondor3000, кружочков это не добавит :)

[kondor3000]

kondor3000, кружочков это не добавит :)

Писать про кружочки, когда полно другого не доделанного, глупо. 85348 макрос нарисовать 2 сек надо.
Типы данных целых со знаком, побитовые операции в ST, глобальные переменные, выбор в слейве 2 регистров в целочисленной, вставка ФБ в макросы и наоборот
уже 3 года просим, не считая постоянных багов.

[Kliper]

Не надо петь дифирамбы макросам! Не в этом случае.
1. Макросы на холсте занимают больше места чем базовые компоненты.
2. Плодить кучу макросов под элементарные задачи и искать их в библиотеках не есть гуд.
3. Макрос может быть изменен, и гадай где оно выстрелит в другом месте.
4. Макрос будет дольше исполняться.
5. Набор этих элементарных макросов занимает место в проекте.
И т.д.

В среде просто не хватает базовой логики, и это вызывает неудобство.

[melky]

Вроде макросы прозрачны для выполнения, так как состоят из базовых компонентов.
Если у вас растет файл проекта, то там совершенно другие причины. Хоть вы 1 макрос поставите, хоть 4 базовых компонента.

[kondor3000]

По времени исполнения не дольше будет.
По поводу большего размера, вообще лажа, скрин выше, при добавлении входов размер и у базового тоже увеличится, едва ли не больше чем макрос нарисованный.
а про кружочки, уже выше написал, ещё 5 лет ждать будем.
Про ST конечно, вообще никто не читал.

[FPavel]

По организации программы - согласен с kondor3000 - с четверга по субботу собирал две программы для ПР205. Так вот "рассыпухи" на холсте очень мало, а вот макросы занимают почти всё место.
Уже давно для себя решил - если код в программе повторяется (например, поиск минимального тока мотора только для включённых насосов - т.е. поиск среди "значения с качеством") - оформлять в макрос.
Макросы - благо.

Хотя, если разработчики добавят возможность изменения количества входов и инверсию входов и выходов - как у Codesys - хуже бы не стало. Но, для меня лично - пройдёт почти незаметно.

Чтобы не быть голословным - покажу главный экран свежей программы в виде pdf.
Организация программы:
- здесь вся система состоит из двух частей (насос и общие для всего комплекса), соответственно для каждой части поддерживаются наборы (состояние, технологическая сигнализация, отказы, команды из вышестоящей системы - HMI - панель, облако). Было бы два насоса - частей было бы три. Это разбиение для выделения отказов, которые блокируют работу одного или всех насосов
- состояние отдельной части - это уникальное для данной части состояние (для насоса - запрос включения, состояние готовности к работе, инициализация и т.д.) Эти состояния и так всегда имеются, я их просто на этапе описания переменных группирую
- команды от вышестоящей системы делаю импульсными, т.е. сразу после восприятия команды обнуляю командное слово
- часть команд задаются с местной панели - поэтому команды от источников обрабатываются в макросах
- чтобы не переделывать программу - сразу текущие измерения, состояния, параметры настройки - держу в сетевых Slave переменных - при поступлении распоряжения организовать обмен с облаком всё уже готово
- структура программы - инициализация, обмен с вышестоящей, формирование технологической сигнализации (Warning), формирование отказов и блокировок, формирование сетевого обмена с контроллером основной технологии (насосов перекачки), рабочий алгоритм. При общем отказе рабочий алгоритм блокируется, при отказе какой-то части - блокируется только эта часть. Здесь этого не видно, т.к. есть единственный насос.
Видно, что "рассыпухи" почти нет - ценные для других проектов или повторяющиеся фрагменты кода оформлены в макросы.