Зачем нужны отдельные fGT/fADD, когда есть GT и ADD?
Точно так же и остальные.
Можно сделать, чтобы был просто блок ADD, а фактическая реализация выбиралась исходя из типов данных, поступающих на вход?
Зачем нужны отдельные блоки fGT, fADD?
Зачем нужны отдельные fGT/fADD, когда есть GT и ADD?
Точно так же и остальные.
Можно сделать, чтобы был просто блок ADD, а фактическая реализация выбиралась исходя из типов данных, поступающих на вход?
Да особенно когда на один вход прицепил буля и на другой флат ,случайно ..Не там автоматизируете ....однако .С имеющими возможностями написание средней сложности проекта(несколько десятков элементов и фб) на ПР занимает несколько часов ,а вы думаете что с автоматизацией нарисования разработка сократится до минут ,но при этом потратите дни при отладки на обьекте ,вылавливая баги не от алгоритмических ошибок ,а от описок ....
Я уже не говорю о международных стандартах (МЭК) ,которые все это регламинтируют ,и которые все одинаково понимают глядя на те или иные элементы ,как они работают ...
Последний раз редактировалось rovki; 01.02.2016 в 15:09.
электронщик до мозга костей и не только
Возможности отладки/тестирования в OL действительно хромают. Но это совсем другой вопрос. А в остальном, среда не должна мешать создавать программу.Сообщение от rovki
Алгоритмические же ошибки на раз появляются, когда слишком много держишь в голове. Именно по-этому я и хочу упразнить блоки fGT, fADD, научить SEL работать с BOOL/FLOAT, и тем самым получить более-менее удобный конструктор, когда не нужно задумываться "а какой у нас там тип входа/выхода/результата". Надо GT -- поставили.
А вот вы скажите что-нибудь о МЭК. Там-то как раз и пропагандируется подход: "блок ADD работает с числовыми типами данных". Да, в стандарте есть "ADD_INT" и "ADD_FLOAT", но никто же их не использует. Все ставят ADD и всего делов.
Я к чему: бросаться словами "МЭК" все горазды.
А текущие "возможности OL по добавлению GT -> TO_FLOAT -> MUL(0, ...)" это просто прорыв. И это в 2016 году.
Честное слово, не вижу сложностей с реализацией, а вот пользу для пользователей -- вижу.
Использовать POW(-1, N) для того, чтобы генерировать -1 или 1? Это явно нецелевое использование ресурсов. SEL намного понятнее, и без всяких ошибок округления.
Неужели на уровне железа там вообще нет возможности сделать fSEL?
пожалуй поддержу Анатолия. всем удобно, Вам не удобно... вторая тема от Вас с нано-новшествами...
так упраздните. напишите свой овенлоджик, делов-то, с таким энтузиазмом.
Уважаемые друзья!
Призываю вас к терпимости.
У каждого из нас есть своё мнение о данном продукте, и мы, компания ОВЕН, хотели бы слышать все ваши идеи, какими бы фантастическими они не являлись.
Поддержу vladimirisitnikov. Зачем изобретать велосипед.
ВЫ О каком велосипеде ?С ПР и ОЛ работаем 6 лет...Схема(элементы и связи составляющие ее) должна быть читабельна даже с листа ,а не когда нажимаешь кнопочки ,комментарии,свойства ...Сразу видно ,что ТС не был никогда электронщиком ,сразу в программисты и привык писать схемы (проекты) ,а не рисовать , ну тогда лучще начать с модернизации кодесис и ПЛК....
не надо этого. Ни в коем случае не надо. FLOAT должен быть FLOATом, INT должен быть INTом. И их надо четко разделять.
А то что FSEL нужен как ФБ согласен.
Ну в голове надо держать всю программу. Такова увы, нелегкая программерская доля. А ошибок в случае универсальных блоков будет на порядок больше.Алгоритмические же ошибки на раз появляются, когда слишком много держишь в голове. Именно по-этому я и хочу упразнить блоки fGT, fADD, научить SEL работать с BOOL/FLOAT, и тем самым получить более-менее удобный конструктор, когда не нужно задумываться "а какой у нас там тип входа/выхода/результата". Надо GT -- поставили.
Последний раз редактировалось Мордорец; 05.02.2016 в 22:32.
Вот вы сейчас говорите про "надпись на квадратике" или про его сущность?
Приведу пример: в выражении 2+2*2 знаки + и * не содержат явных упоминаний что они умножают и складывают.
Нет специальных знаков для "сложения целых" и "сложения дробных".
И ничего, математики живут как-то, не путаются.
А по-вашему, почему-то нужно разделять float_add и int_add. Зачем?
С чего бы это?
Можете привести пример ошибки, которая будет возникать при универсальном add/sel, и не будет возникать (или реже) на типизированных add/fadd?
именно про сущность. Потому как 2(FLOAT) и 2 (INT) это совершенно разные числа, которые не в коем случае нельзя между собой смешивать. Это сродни тому что выполнить 10(HEX) + 10 (DEC) =???. Математики не путаются, а вот для программиста (особенно ассемблер) это стандартная ошибка, которая кстати порой довольно сложно отлавливается. Сейчас OL надежно защищен от данных ошибок.
Ваши права
