Вы просто подумайте:
22к памяти программ и около 500 программных блоков!

Дилемма следующая:
Можно было бы поставить пожирнее процессор, да и не 8 бит, а целых 32.
Но тогда вырастет цена контроллера. Да, сейчас 32 бита машины дешевле 8 битных.
Но помехоустойчивость у них хуже на порядок.
Следовательно, нужно принять меры по помехоподавлению. Вот отсюда и поползет цена.

Производительность 8 битной машины невысока. Но вполне достаточная для выполнения весьма серьезных задач.
Зачем платить больше за тот же результат?

Привыкнуть к выбору типа данных совсем несложно, хотя конечно же это требует некоторого внимания.
Но с другой стороны вы самообучитесь писать оптимально для любого проекта.

Причин не сборки проекта несколько, вот самые распространенные:

1. Неправильно указан тип данных.
Как можно было бы поступить:
Сделать так же, как в смлоджике: 4 типа данных и нет возможности коннекта к разным типам.
Давайте посмотрим на эту "простоту" пристальнее.
типы Bool / Sint / Long / Real

Нет возможности прямого соединения типов данных по восходящей, следовательно, появляются лишние блоки.
Станет бессмысленна функция "обратного" соединения двух блоков (от выхода к входу)

Оптимизация трафика по сети.
Пример, надо в сеть послать число 65000
2хбайтовым целым - да пожалуйста, а вот знаковым двухбайтовым - фиг. Используйте 4х байтовое.
А если переменных 100? Правильно! мы отправим в два раза больше данных, причем половина - бесполезных. А теперь умножим на 30 контроллеров в сети. Получается, что упрощая работу с ФБД редактором, вы автоматически генерируете избыточный трафик по низкоскоростному каналу.

Мне задали вопрос недавно. Модбас - говенный протокол. Очень медленный.
Я ответил, что многое зависит от оптимизации данных и мне на скорости 19к очень комфортно общаться с 30ю подчиненными.

2. Рекурсивные связи.
В нашей реализации ФБД рекурсия осуществляется переменными.
Казалось бы - что стоит сделать визуальное представление переменной, как линии связи?

Почему оставили именно вид переменных? Этот подход открывает огромное количество возможностей для творчества.

Простой пример, но прежде чем вы его посмотрите в картинке, пришлите, кому не лень, свою реализацию в других ФБД редакторах.

Задача: вывести в сеть состояние D-триггера с возможностью локальной и сетевой установки триггера (то есть все по-взрослому: Сет/Ресет/Переключение).
Кстати, задача абсолютно не абстрактная - это локальная/удаленная кнопка Пуск/Стоп.
______________
Подсказка: я это сделаю в ZWB на одной рекурсивной переменной.


3. Конфликт множественной записи в переменные.
Это сумасшедшая возможность ЗВБ!!!
Ее просто надо понять. Эта штука позволяет синхронизировать по приоритетам данные из разных портов, мест программы. Короче всего со всем.
И требует это минимального усилия программиста.

Решите в стороннем ФБД редакторе задачу:
Есть абстрактный контроллер с двумя портами (протокол неважен).
Контроллер по двум портам - подчиненный, или другими словами, ему нет надобности инициировать запросы.
В программе есть переменная УСТАВКА ТЕМПЕРАТУРЫ. Уставка сохраняется в ПЗУ (ну и естественно, читается по запросу мастера)
Цель: отдать на оба порта уставку из переменной и изменить ее по запросу любого из мастеров.

Ах, да! Усложним. Контроллер имеет индикатор и клавиатуру. И с клавиатуры тоже можно задать уставку в эту же переменную.
Примем, что переменная получает уставку от устройства ввода-вывода каким-то образом, например значение и строб на запись.
______________
Подсказка: я это сделаю в ZWB на одной переменной.


Очень жду вашего резюме.

[quote author=mike link=topic=70.msg1208#msg1208 date=1459268005]
Задача: вывести в сеть состояние D-триггера с возможностью локальной и сетевой установки триггера (то есть все по-взрослому: Сет/Ресет/Переключение).
Кстати, задача абсолютно не абстрактная - это локальная/удаленная кнопка Пуск/Стоп.
[/quote]

Мой вариант решения задачи в лоджике.

Попутно небольшой косячок нашёл, как мне кажется. НА Z400 на экране отладки, созданном по умолчанию, выходы дискретные не отрабатывают.

Ещё небольшой глюк: окно "отладка - переферия" при входе в симуляцию и выходе самопроизвольно закрывается.

Вот мой вариант решения на ZWB.
Да, в ZWB поудобнее.

Вот ещё один вариант решения задачи на лоджике, здесь приоритет записи в переменную организован посредством макроса.

Немного поправлю.

Приоритет 0 - это когда нет других мест записи.
Так что при записи в переменную из разных мест приоритет надо указывать отличным от нуля.

Что касается предложенной схемы - у тебя не корректная запись по сети. Сет/Ресет работать будут, а вот переключение нет.

На входах Сет и Ресет не нужны передние фронты.
Инверсия в части Ресет излишняя - можно решить константами.

К чему это я всё.
Мы тщательно продумываем поведение пользователя в ЗВБ.
Итог - программа для контроллера получается нагляднее и компактнее.
Мне кажется не такая уж и большая нагрузка на инженера - выбрать тип данных переменной или входа.

Посмотрим, как справятся наши конкурсанты со второй задачей. Она значительно сложнее.

Про приоритет понял.
Про фронты понял.
Про инверсию понял.

В твоей схеме переключение происходит независимо от того что передал мастер, 0 или 1. Я могу добавить отдельную сетевую переменную, которая и будет переключать триггер. Ну а так предполагается что мастер если ему надо сделать переключение отправит на запись противоположное значение.

В целом идею с приоритетом записи я понял.

[quote author=VoronovMaksim88 link=topic=111.msg1225#msg1225 date=1459311441]

В твоей схеме переключение происходит независимо от того что передал мастер, 0 или 1. Я могу добавить отдельную сетевую переменную, которая и будет переключать триггер. Ну а так предполагается что мастер если ему надо сделать переключение отправит на запись противоположное значение.
[/quote]

Таки мы D-trigger делаем или шо? Я же с удаленной системы должен записать единицу в переменную.
Я чуть упростил и вытаскиваю сам факт записи, а чего пишут меня не волнует.

Можно и добавить переменную.
Основная идея задания - показать насколько изящно получается решить сложную задачу. Причем всего парой блоков.