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