Этот вопрос не ко мне. Надеюсь знающие люди ответят Вам.Цитата:
Сообщение от pop70
Этот вопрос не ко мне. Надеюсь знающие люди ответят Вам.Цитата:
Сообщение от pop70
Можно же объединить 2 счётчика, как-то так:
Вложение 32520
Не всегда требуется 32 бита, если Вам требуется элемент 8И, зачем тогда нужен 2И?!
Не. Не понимаю!Цитата:
Сообщение от Сергей0308
Проще заново нарисовать, чем объединять. Если не нужны 32 бита - можно вообще ничего не делать. Переменную один фиг 32 бита хранить. Экономии никакой. Просто, странное решение для среды, не имеющей 16 битных переменных.
По элементам, как раз, всё понятно - базовый элемент на 2 входа. По счётчикам - базовый JK на один бит для булевых, и 32 бита для интов.
Фича бессмысленная. Значит, баг.
В сетевых целочисленных переменных 16 бит, старшие 16 бит срезаются! Допустим Вам надо по сети передать целочисленное значение 32 битного счётчика, надо разбивать на два регистра по 16 бит, а здесь уже всё разбито! Останется получить и собрать!Цитата:
Сообщение от pop70
Цитата:
Сообщение от Владимир Ситников
Я бы не назвал это багом. Но как уже сказал замечание принято. Насчет оптимизации анализа ЛЗ и не только. Естественно расматривались в свое время такие задачи и делались некие прототипы. Но игра не стоила свеч. Затраты не окупались полученным выигрышем в производительности. В 1.10 ставки сделаны на другое - асинхронность операций, что в разы увеличило отзывчивость пользовательского интерфейса. Что на мой взгляд более востребовано в ОЛ.Цитата:
Сообщение от Владимир Ситников
ИМХО, тут дело не в быстродействии, а в минимальном нарушении заданной схемой логики. Это, опять же ИМХО, приоритетнее любых остальных задач. Чтобы работало "как нариовано", а не "быстро, но как Бог на душу положит".Цитата:
Сообщение от wal79
А кроме счётчика по сети ничего передавать не надо?Цитата:
Сообщение от Сергей0308
Так, может быть, вообще инты 16 битами ограничить? А где надо больше - собирать?
Или просто с "сетевыми переменными" поработать на тему одно/двух-регистровые? Тем более, что модбас вполне себе это позволяет.
Вообще, сетевые операции в ОЛ на слишком низком, по сравнению с остальным, уровне программируются. Это повод поработать над концепцией сетевого обмена уровнем выше, а не придумывать высосанных из пальца ограничений для отдельных ФБ.
Вообще говоря, ОЛ - весьма удачный продукт. Жаль сыроват.
Чего реально не хватает в интерфейсе - это "горячих клавиш". Особенно в симуляции. (Режим симуляции, пуск, стоп, пауза, шаг).
"Точек останова" "по условию".
Примитивная ctrl+A в редакторе :) - тоже не хватает.
Вобщем, управления для "клавишников".
При установке обратной связи, "петли дурацкие" вылазят, невозможность прокрутки схемы при постановке связи (на больших "холстах" доставляет) - решилось бы прокруткой в режиме "+ctrl"(масштаб), " +shift"(прокрутка влево/вправо), "+alt"(прокрутка вверх/вниз).
Стандартные для графических редакторов вещи...
Вид поля элементов не сохраняется, по умолчанию стоит огромная "плитка", на маленьких экранах, в результате имеем одну папку или один элемент в поле, при прокрутке - прыжки "через один". В "списке" удобнее гораздо....
Таких мелочей набирается воз и маленькая тележка.
Я не придираюсь - просто очевидные вещи, важные для удобства.
Это надо всё регламентировать(стандартизировать), чтобы у всех производителей одинаково было, а то с реалами(флоатами) воз и ныне там, до сих пор байты тасуют всяк по своему!Цитата:
Сообщение от pop70
Естественное, нарушений в логике работы последовательной программы быть не должно. К этому и стремимся. Этот ответ больше предназначался Владимиру о вопросах оптимизации. Я согласен что, принуждение лоджиком вставлять у макроса дополнительную ЛЗ - это не совсем верно. Но считаю это не багом, а избыточностью. И согласился что следует это замечание учесть и скорректировать анализ обратных связей. Насчет CTMAX пока ничего не могу сказать ,баг это или фича. Но в любом случае замечание будет проанализировано и приняты необходимые меры. Или есть еще какие-то баги?Цитата:
Сообщение от pop70