Просмотр полной версии : Подсветка переменных записываемых в конце цикла
Здравствуйте.
Пожелание разработчикам сделать подсветку переменных. Хотя бы тех, которые записываются в конце цикла.
Ну путь будут не в черной рамке, а например в зеленой. Или фон какого-нибудь другого цвета.
Что скажут участники?
МихаилГл
26.03.2024, 03:45
Это как? Непонятно. Они всё в конце цикла записываются. Вроде...
АРТ.Кар 64
26.03.2024, 07:14
Присоединяю своё непонимание к непониманию Михаила.
А именно...
Какой в этом смысл ? + Какой от этого "экономический эффект"?
То есть....Это что-то упростит ,или поможет выполнить работу в более "сжатые сроки"..
Sergey666
26.03.2024, 08:39
Что скажут участники?
Также, со страшной силой, присоединяю свое непонимание к непониманию товарищей.
74706
Если включить режим симулятора, то в свойствах схемы появится параметр "Фон входов/выходов".
Выбираете "Да" и каким цветом отображать. Тогда переменные, которые в цикле работы будут менять своё значение,
будут подсвечиваться выбранным цветом.
Но подсвечиваться будут все.
Выражаю непонимание про непонимающих: как это так вы про линии задержки не ругаетесь? Почему это они пунктиром сделаны, а не как обычные? Зачем это пользователю видеть на схеме то, простая ли это связь, или линия задержки? Пусть мучается.
Если бы я использовал бы запись в конце цикла и мне надо было бы кликать на все переменные на схеме, чтобы понять, какая из них записывается в конце цикла - я бы побежал бы лица бить разработчикам за такое.
Командую: СтарПёрство оставить и идти отдыхать! Идею пользователя Kliper принять к исполнению!
Дополнительный аргумент: когда вы на форуме схемы выкладываете, то по ним и будет видно, где линия задержки, а где запись в конце цикла.
Выражаю непонимание про непонимающих: как это так вы про линии задержки не ругаетесь? Почему это они пунктиром сделаны, а не как обычные? Зачем это пользователю видеть на схеме то, простая ли это связь, или линия задержки? Пусть мучается.
Если бы я использовал бы запись в конце цикла и мне надо было бы кликать на все переменные на схеме, чтобы понять, какая из них записывается в конце цикла - я бы побежал бы лица бить разработчикам за такое.
Командую: СтарПёрство оставить и идти отдыхать! Идею пользователя Kliper принять к исполнению!
Дополнительный аргумент: когда вы на форуме схемы выкладываете, то по ним и будет видно, где линия задержки, а где запись в конце цикла.
опять недопрограммист выскочил, че то ляпнул. Скажите как Вы увязали подсветку переменных и подсветку линий?
опять недопрограммист выскочил, че то ляпнул. Скажите как Вы увязали подсветку переменных и подсветку линий?
Чем докажешь, что я недопрограммист? Мой стаж - с 1996 года.
Вот здесь увязал. В соотвествии с ТЗ:
Пожелание разработчикам сделать подсветку переменных. Хотя бы тех, которые записываются в конце цикла.
Ну путь будут не в черной рамке, а например в зеленой. Или фон какого-нибудь другого цвета. Суть: Переменные, которые имеют запись в конце цикла, должны визуально отличаться от обычных.
Сергей0308
26.03.2024, 10:47
опять недопрограммист выскочил, че то ляпнул. Скажите как Вы увязали подсветку переменных и подсветку линий?
Так линию связи можно заменить переменной, связь прямая, по сути это может быть одно и тоже!
Короче, желания товарищей понятны в отличии от ваших, в смысле, зачем воду мутить?
Во первых автор темы так и не изложил подробно о своей задумке, что же он хотел.
Во вторых кто мешает оставить комментарий к переменной что она записывается в конце цикла или что то другое, что нужно ждать от этой переменной в отладке.
Ну и полагаться на цвет это не уровень программиста, править код пока переменная не загорится нужным цветом что ли, это метод тыка, а не глубокое понимание какую задачу должен решать программный код
Мда. Видимо, умение увидеть и реализовать грамотную идею в неявно оформленном потоке мыслей и отличает разработчика от кодера.
Вопросы:
1. Если мы говорим про графический язык, то способы показывать статус или отличие объектов друг от друга должны быть графическими.
Например, предлагаю представит графический язык без указаний входов и выходов блоков. Пусть вот все FB и функции были бы квадратиками, все выводы-сигналы которых подключались бы слева и без подписей. И надо было бы помнить, что у CTU первый сверху вход - это счёт, второй сверху - это Reset, а третий - счёт вниз. Без подписей.
Примерно на это ты и возмущаешься, предлагая оставить всё как есть: вслепую на графическом языке изучать переменные.
2. Сожалею, но на текущий момент в Owen Logic НЕТ явного способа увидеть все свойства переменных разом. В таблице окна переменных нет столбца "Запись в конце цикла", по которому можно понять, отличается ли одна переменная от другой по её свойствам.
Тип переменной отображается графически в виде её цвета. А вот это важное свойство - нет.
МихаилГл
26.03.2024, 15:33
Мне правда не понятно назначение всего этого. Ну, например, на моей предыдущей работе 4000 дискретных входов, 1000 дискретных выходов, по 100...200 аналоговых входов выходов. Для того, чтоб понимать как всё работает мне достаточно тру/фолс и реал. Никаких цветовых отображений и тем более что в какой последовательности куда положилось... Для этого надо только понимать код. Для новичка понятно трудно, но когда разберешься всё становится просто и понятно, без дополнительных наворотов в программе.
И что значит переменная записалась последней? Есть стандарт на языки. Переменная только тогда запишется на выход блока, когда она не будет нигде использоваться внутри блока. А если она несколько раз переписывается внутри блока, то последнее её присваивание будет истиной. Не говорим сейчас о линии задержки...
переменные на листе программы записываются сразу, если не указано иное.
Как вы себе представляете работу функции от которой зависит дальнейший ход программы? банальные 2+2= и типа она запишется в конце цикла?
з.ы. так понимаю человек хочет градацию по цвету штанов в режиме симуляции, видеть что и где у него пишется.
Мне правда не понятно назначение всего этого. Ну, например, на моей предыдущей работе 4000 дискретных входов, 1000 дискретных выходов, по 100...200 аналоговых входов выходов. Для того, чтоб понимать как всё работает мне достаточно тру/фолс и реал. Никаких цветовых отображений и тем более что в какой последовательности куда положилось... Для этого надо только понимать код. Для новичка понятно трудно, но когда разберешься всё становится просто и понятно, без дополнительных наворотов в программе.
И что значит переменная записалась последней? Есть стандарт на языки. Переменная только тогда запишется на выход блока, когда она не будет нигде использоваться внутри блока. А если она несколько раз переписывается внутри блока, то последнее её присваивание будет истиной. Не говорим сейчас о линии задержки...
Понятно, что все переменный получат своё значение в конце цикла (причём FBD не даст два раза присвоить значение одной переменной),
а тут похоже разговор о частном случае OwenLogic, точнее даже частном случае использования переменных программы во встроенном дисплее, когда появляются варианты очерёдности присваивания значений таким переменным (экран/программа)
Насколько я понял, автор хочет чтобы обычные переменные, энергонезависимые и экранные у которых стоит свойство "запись в конце цикла" визуально отличались друг от друга
Насколько я понял, автор хочет чтобы обычные переменные, энергонезависимые и экранные у которых стоит свойство "запись в конце цикла" визуально отличались друг от друга +1. Capzap нас тоже ща занесёт в "недопрограммисты" =/
МихаилГл
26.03.2024, 17:13
Ну я с релюхами мало работаю, чтоб такие тонкости знать. Всё на плк мысленно перевожу. Поэтому для меня "конец цикла" это конец подпрограммы с определённым временем. Простите люди добрые, мы не местные...
+1. Capzap нас тоже ща занесёт в "недопрограммисты" =/
У меня к Dimensy совершенно нет претензий. Он конкретно указал как он понял первый пост темы ни чего не от кого не требуя, в отличии от Вас
Сергей0308
26.03.2024, 18:19
Насколько я понял, автор хочет чтобы обычные переменные, энергонезависимые и экранные у которых стоит свойство "запись в конце цикла" визуально отличались друг от друга
Так эта функция "запись в конце цикла" ранее была только у неэнергонезависимых переменных, у энергонезависимых переменных это было уже по умолчанию, в смысле, если сейчас при выводе на экран переменная становится энергонезависимой, то и это свойство "запись в конце цикла" должно автоматически к ней "прилипать", короче, получается в новых ПР это свойство "запись в конце цикла" станет ненужным, я правильно понимаю?
Валенок, capzap, МихаилГл У вас весеннее обострение, что ли? Рано же ещё: заморозки не кончились... Обалдели вы так всё передёргивать. Я не представляю, как так можно. Особенно Валенок. Как был им, так и остался.
Валенок, Что за "все свойства всех"? Задачка про 365 итераций и Шампанское так и не решена ещё?
Напоминаю: 74738
Я говорил о том, что сейчас нет возможности штатным способом увидеть сводку "Запись в конце цикла" по всем переменным. Надо на каждую тыкать и в Свойствах смотреть.
capzap Да, я всё понял. Однако баг в библиотеке SmsOwenLib я поправил, и она успешно работает.
МихаилГл Ты нейросеть? Сообщения-то все невпопад. Если ты не в курсе ПРок - то и не надо лезть сюда.
Присоединяю своё непонимание к непониманию Михаила.
...
То есть....Это что-то упростит ,или поможет выполнить работу в более "сжатые сроки"..
Именно так. Достаточно одного взгляда на схему чтобы увидеть особенности. Особенно в чужой схеме.
И эта визуальная особенность (запись в конце цикла) не позволит забыть о ней.
АРТ.Кар 64
27.03.2024, 01:50
Тогда второй вопрос ....
Как Вы предлагаете реализовать Вашу идею ....Это должно быть "опциально"..То есть на выбор программиста.( принцип "хочу-не хочу)...Или "обязательно"...То есть переменные будут выделяться независимо от желания программиста и только таким образом (допустим цветом) какой выберет Производитель.....??
И убедительная просьба ко всем присутствующим в теме.
Не будем забывать о том,что "Хамство начинается тогда,когда заканчиваются аргументы"..
Ну если Вы уговорите разработчиков сделать это ещё и опционально, то почему бы и нет.
А так все просто. Линии же выделяются по типам данных. Красные, черные, фиолетовые. Так же и с переменными. Только рамки красить не получится, так как при расположении переменных вплотную, они перекроются. А вот с цветом фона или текста можно поиграться.
Какие именно цвета на усмотрение разработчиков или вашим пожеланиям, без разницы. По циклам записи я бы выбрал что-то броское но не кричащее. Бледно-розовый например.
МихаилГл
27.03.2024, 03:54
Эта "запись в конце цикла" видимо нужна только для того, чтобы экранные переменные не принимали промежуточных значений при работе программы. Что с одной стороны логично, но с другой, вывод этих переменных сам по себе должен обрабатываться после всего. А для остальных переменных зачем это свойство?
Убрать надо упоминание об этом вообще, так считает моя нейросеть.
Sergey666
27.03.2024, 08:19
Эта "запись в конце цикла" видимо нужна только для того, чтобы экранные переменные не принимали промежуточных значений при работе программы. Что с одной стороны логично, но с другой, вывод этих переменных сам по себе должен обрабатываться после всего. А для остальных переменных зачем это свойство?
Убрать надо упоминание об этом вообще, так считает моя нейросеть.
Присоединяю свою нейросеть.
У того кто придумал это свойство "запись в конце цикла", видимо для того "чтобы экранные переменные не принимали промежуточных значений при работе программы" в голове вместо мозга газировка со вкусом жевачки.
Возможно и ориентир был на таких же "разработчиков" с газировкой.
И..., CS-CS, хорош хамить и хвастать.
Присоединяю свою нейросеть.
У того кто придумал это свойство "запись в конце цикла", видимо для того "чтобы экранные переменные не принимали промежуточных значений при работе программы" в голове вместо мозга газировка со вкусом жевачки.
Возможно и ориентир был на таких же "разработчиков" с газировкой.
И..., CS-CS, хорош хамить и хвастать.
Переменные в пределах цикла не могут принимать промежуточных значений. Запись в конце цикла - это аналог линии задержки. И это очень удобно
Что касается пожеланий автора, то, по мне, такая картинка более удобна для восприятия
74753
МихаилГл
27.03.2024, 12:14
Переменные в пределах цикла не могут принимать промежуточных значений. Запись в конце цикла - это аналог линии задержки. И это очень удобно
Что касается пожеланий автора, то, по мне, такая картинка более удобна для восприятия
74753
То есть внутри программы в текущем цикле эту переменную уже не сможете использовать? Она станет актуальной при следующем заходе...
А как же язык ST, по идее это тот же язык, только по другому реализован, и уже вот такое вы не реализуете:
<Счетчик>:= 123;
код программы
<Счетчик>:= 234;
код программы
<Счетчик>:= 432;
Sergey666
27.03.2024, 12:24
Вот так созревает, рождается и эволюционирует параллельная фиолетовая вселенная пользователей Овен лоджика. Спросите почему параллельная- потому что нет нигде подобного функционала ни у одного из производителей, т.е опыт применения инкапсулирован в мирке Овен лоджика.
Переменные в пределах цикла не могут принимать промежуточных значений. Запись в конце цикла - это аналог линии задержки. И это очень удобно
Да вы что? А чем? В чем удобство состоит?
Я не особо часто работаю с ПР, но приходилось и не испытывал особых неудобств без сомнительных фишек разработчиков софта.
НО! Товарищи, я ж не против в принципе, только вот, пожелания свои надо уметь формулировать ясно и членораздельно, тогда может и сбудется.
Да вы что? А чем? В чем удобство состоит?
Хорошо, вот реализация r-trig на лоджике
74755
А вот, в кодесис
74756
И, косяк, в кодесис код не работает
Может я не очень удачный пример привел, но в классическом FBD и CFC неверное расположение блоков может привести совсем не к тому что вы задумывали. А лоджику плевать на расположение блоков, а если будет неопределенность, то лоджик любезно подсветит желтым проблемную связь.
Королев Кирилл
27.03.2024, 13:12
Коллеги, всем спасибо за обратную связь.
Что касается пожеланий автора, то, по мне, такая картинка более удобна для восприятия
74753
Добавили задачу себе в бэклог, подумаем над реализацией.
Sergey666
27.03.2024, 13:14
Хорошо, вот реализация r-trig на лоджике
74755
А вот, в кодесис
74756
И, косяк, в кодесис код не работает
Плохой индусский код (плохой, потому что не работает) не работает в нормальном IDE, что в этом плохого?
Может я не очень удачный пример привел, но в классическом FBD и CFC неверное расположение блоков может привести совсем не к тому что вы задумывали. А лоджику плевать на расположение блоков, а если будет неопределенность, то лоджик любезно подсветит желтым проблемную связь.
Т.е мое предположение о появлении секты свидетелей Овенлоджика верно?
А как же язык ST, по идее это тот же язык, только по другому реализован, и уже вот такое вы не реализуете:
<Счетчик>:= 123;
код программы
<Счетчик>:= 234;
код программы
<Счетчик>:= 432;
Один и тот же результат можно получить и на FBD и на ST. Просто некоторые вещи удобнее реализовывать на FBD, другие - на ST. Поэтому сравнивать в таком ключе языки не корректно. Вы же С++ с ассемблером не сравниваете?
МихаилГл
27.03.2024, 13:23
Т.е мое предположение о появлении секты свидетелей Овенлоджика верно?
Да, видимо, только потом при переходе даже на ПЛК2хх ломка начнется...
Как вы будете работать с проектом, в котором около 20 тысяч переменных, включая внутренние программные тэги?
Т.е мое предположение о появлении секты свидетелей Овенлоджика верно?
Пусть будет секта - лоджик мне нравиться, несмотря на кучу косяков, а, вот например, среда у Сегнетика мне не зашла, хотя там есть удобные фишки.
Да, видимо, только потом при переходе даже на ПЛК2хх ломка начнется...
Как вы будете работать с проектом, в котором около 20 тысяч переменных, включая внутренние программные тэги?
Если говорить честно, то даже переход с ПЛК1хх на ПЛК2хх вызовет некоторые сложности
МихаилГл
27.03.2024, 14:46
Если говорить честно, то даже переход с ПЛК1хх на ПЛК2хх вызовет некоторые сложности
Никаких не вызвало. Да и одновременная работа в 2.3 и 3.5 не вызывает трудностей.
АРТ.Кар 64
27.03.2024, 15:11
74759
В принципе ...(если это будет выглядеть так)-то почему бы и нет ?
Dimensy круто ! А главное то ,что никого не запутает.
Возможно,что у автора есть "своё видение",но что-то автор "слегка излишне скромен в обсуждении".
Автор только слегка решил намекнуть на то ,что бы в ОЛ внести дополнительный "момент наглядности"
И стоило ли из за этого ругаться и хамить ?Ну ,вы ,блин,.....даёте !
Что касается пожеланий автора, то, по мне, такая картинка более удобна для восприятия
74753
Нет, уже писал. Рамки так использовать неполучится, потому что при размещении переменных в притык они будут перекрываться соседними переменными. Надо работать цветом фона или текста.
Коллеги, всем спасибо за обратную связь.
Добавили задачу себе в бэклог, подумаем над реализацией.
Повторюсь.
Рамки так использовать неполучится, потому что при размещении переменных в притык они будут перекрываться соседними переменными. Надо работать цветом фона или текста.
Может фон в полосочку? )))
Нет, уже писал. Рамки так использовать неполучится, потому что при размещении переменных в притык они будут перекрываться соседними переменными. Надо работать цветом фона или текста.
сразу разъясните, этот поиск нужной переменной из-за того что всё впритык? Или по мимо этого схема на весь экран не влазит еще?
74776
Вот так например.
Ничего не упустил?
74776
Вот так например.
Ничего не упустил?
Вот, превращать холст в мозаику - это уже перебор. Просто не размещайте переменные в куче
Разумеется куч надо избегать, но не всегда так получается. Тем более что этот шаг соответствует стандартным расстояниям между линиями блоков.
Про цвета писал выше, они должны быть не броскими.
Опять же, я как инженер и архитектор систем, вижу здесь следующую задачу: сделать НАСТРАИВАЕМЫЕ представления объектов.
По аналогии с тем, как в текстовых редакторах исходного кода можноо настроить шрифт, цвет фона и текста для разных сущностей: ключевых слов, переменных, строк, комментариев.
Вот в Owen Logic давно просится система настроек (резервное копирование проекта при сохранении, расположение папки макросов), где пользователь мог бы настраивать внешний вид объектов под себя. Тогда не надо будет спорить: кто-то настроить вид в полосочку и с рамкой, кто-то в виде другого цвета фона и так далее.
...Вот в Owen Logic давно просится система настроек ... под себя. Тогда не надо будет спорить: кто-то настроить вид в полосочку и с рамкой, кто-то в виде другого цвета фона и так далее.
Вот тут не соглашусь. Должен быть единый стандартный вид, чтобы схема была понятна всем, а не только её хозяину. Про полосочки - идею развил Dimensy, в виде пунктирной рамки, по аналогии с линией задержки. Чтобы её сохранить я и предложил полосатый фон, что конечно сложней в реализации. Изначально я предполагал просто другой цвет фона.
Что касается организации макросов, тут согласен. Только знакомлюсь со средой, и мне сразу показалось очень неудобным и непонятным текущая организация. Фиг че найдешь.
Почему бы не сделать раздел библиотека пользователя, в которую он набивает СВОИ макросы? И она не должна быть привязана ник какому проекту. Потом нужные макросы просто выдергиваются в поле проекта, и работа идет с ними. А сейчас все валится в проект, захламляется, и потом надо выискивать и чистить то, что не нужно.
74782
Предлагаю итоговый вариант.
Закрашенный треугольник слева подразумевает запись переменной в конце цикла
Бледно-зеленые - экранные, бледно-розовые - энергонезависимые
Почему бы не сделать раздел библиотека пользователя, в которую он набивает СВОИ макросы? И она не должна быть привязана ник какому проекту. Потом нужные макросы просто выдергиваются в поле проекта, и работа идет с ними.
Библиотека имеется
74783
74784
Что касается организации макросов, тут согласен. Только знакомлюсь со средой, и мне сразу показалось очень неудобным и непонятным текущая организация. Фиг че найдешь.
Почему бы не сделать раздел библиотека пользователя, в которую он набивает СВОИ макросы? И она не должна быть привязана ник какому проекту. Потом нужные макросы просто выдергиваются в поле проекта, и работа идет с ними. А сейчас все валится в проект, захламляется, и потом надо выискивать и чистить то, что не нужно.
Ты не первый, кто начинает предлагать доработки Owen Logic. Я тоже много предлагал с матами. Часть из моих идей пойдёт в новое окно переменных Owen Logic.
Однако ОВЕН делает всё медленно и тяжко: до последних двух лет Owen Logic развивался несистематически, и ща там происходит много внутренних изменений и рефакторинга кода.
Я давно хочу, чтобы у Owen Logic были настройки, где можно указать папку для хранения макросов и ещё чего-нить под себя поднастроить.
А у меня вопрос, есть поиск переменных на поле?
Есть возможность из таблицы переменных перейти на поле с подсветкой этой переменной на поле программы ?
Или все только глазками?
melky Из той таблицы переменных, которая открывается в отдельном окне - нет.
А вот из списка переменных слева - да. Там под переменной есть список ссылок на неё, и если нажать на ссылку - то переменная на схеме подсвечивается, а схема прокручивается так, чтобы её было видно.
А у меня вопрос, есть поиск переменных на поле?
Есть возможность из таблицы переменных перейти на поле с подсветкой этой переменной на поле программы ?
Или все только глазками?
Есть вот такое
74786
Королев Кирилл
28.03.2024, 09:52
Может сначала про 31-бит и логические для целых в ST?
Запись в 31 бит исправили, фикс будет с новым релизом Owen Logic. Про "логические для целых" расскажите, пожалуйста, подробнее, что имеете в виду?
Dimensy, Cs-Cs спасибо, подойдет. А то глазами запарился искать где, что не так.
А ведь могли сделать простое по Ctrl+F и далее F3 как в большинстве программ штатно работает.
Запись в 31 бит исправили, фикс будет с новым релизом Owen Logic. Про "логические для целых" расскажите, пожалуйста, подробнее, что имеете в виду?
UDINT#FOO AND UDINT#BAR
Библиотека имеется
Ха. Так вот она где "локальная библиотека". А я все глаза сломал в её поисках, и непонятках куда пропадает загруженное. Может все-таки стоит придерживаться одинаковых названий?
И опять одни неудобства.
Почему нельзя работать в среде не закрыв менеджер компонентов? Это очень неудобно.
Где хранится эта библиотека? Я бы хотел таскать её на флешке, и работать с ней просто указав к ней путь в среде.
Нет простого перетаскивания компонентов мышью туда/обратно. Неудобно.
Так и не понял как их вытянуть оттуда в проект.
И раз пошла такая пьянка, очень удивляет отсутствие отрицательных целочисленных
kondor3000
28.03.2024, 19:03
И раз пошла такая пьянка, очень удивляет отсутствие отрицательных целочисленных
Для отрицательных целочисленных есть макросы пересчёта, возможно со временем они и появятся.
Функции FLOAT_TO_INT и INT_TO_FLOAT на ST и FBD https://owen.ru/forum/showthread.php?t=37203&page=9&p=429067#84
Сергей0308
29.03.2024, 19:15
Мой вариант чем не устроил, вроде и универсальный, в смысле диапазона INT/DINT, здесь последний раз выкладывал: https://owen.ru/forum/showthread.php?t=25067&page=77
74847
Сергей0308
29.03.2024, 20:04
Если на картинке, то нету там int32 на выходе
По умолчанию INT16, в смысле, он, мне кажется, чаще встречается, но там присутствуют настройки в свойствах макроса, можно и в INT32 преобразовать, об этом всё там написано(по ссылке), кстати, в проекте и обратная функция присутствует, тоже универсальная, в смысле, диапазона INT/DINT.
Сергей0308
29.03.2024, 20:36
Нет возможности посмотреть.
-100000?
74848
74849
Верхняя картинка преобразование в INT16, нижняя в INT32.
У меня диапазон ограничен, поэтому на верхней картинке максимальное значение в отрицательную сторону показывает!
Сергей0308
29.03.2024, 20:46
нет
...........
Что нет?
........
Сергей0308
29.03.2024, 20:59
Неправильно же
Ваши предложения, в смысле, какое должно быть значение, Вы наверно первую картинку посмотрели, на второй преобразование в INT32:
74850
Если нет, может Вы какой другой код имели ввиду, кроме дополнительного кода бывает ещё прямой и обратный код, в одной из тем я макрос выкладывал, где тип кода можно выбирать!
Естественно. Если учесть время моего ответа и вашего добавления
Позже еще посмотрю
kondor3000
29.03.2024, 22:35
Ваши предложения, в смысле, какое должно быть значение, Вы наверно первую картинку посмотрели, на второй преобразование в INT32:
74850
Если нет, может Вы какой другой код имели ввиду, кроме дополнительного кода бывает ещё прямой и обратный код, в одной из тем я макрос выкладывал, где тип кода можно выбирать!
Сергей верхний макрос INT-FLOAT считает не правильно, скрин 74852 вот его модернизировал 74851
Перевод во FLOAT надо делать после вычитания, иначе теряется часть последних цифр. При чём на пределах -1 000 000, -10 000, -1000 разные цифры в конце.
Число 4294867296 это -100 000
Сергей0308
29.03.2024, 23:03
Сергей верхний макрос INT-FLOAT считает не правильно, скрин 74852 вот его модернизировал 74851
Перевод во FLOAT надо делать после вычитания, иначе теряется часть последних цифр. При чём на пределах -1 000 000, -10 000, -1000 разные цифры в конце.
Число 4294867296 это -100 000
Тогда и у Вас неправильно, потому что цифры совпадают с моими!
И Вы не макрос модернизировали(что Вы нарисовали), а сделали другой макрос, в смысле обратную функцию, я писал, что в проекте есть и обратная функция, в смысле преобразование INT_TO_FLOAT:
74853
И, обратно значения совпадают с вашими, короче, Вы на этом основываете свои заключения, что неправильно считает?
И, почему то всем лень по ссылке перейти и посмотреть, короче, чтобы никого не утруждать кишки и этого макроса:
74854
Почти 2 года назад выложил!
kondor3000
29.03.2024, 23:12
Тогда и у Вас неправильно, потому что цифры совпадают с моими!
И Вы не макрос модернизировали(что Вы нарисовали), а сделали другой макрос, в смысле обратную функцию, я писал, что в проекте есть и обратная функция, в смысле преобразование INT_TO_FLOAT:
74853
И, обратно значения совпадают с вашими, короче, Вы на этом основываете свои заключения, что неправильно считает?
Вы плохо посмотрели, у вас -100096 а у меня -100 000. Разговор про INT-FLOAT
Про INT-DECOD вопросов нет.
Сергей0308
29.03.2024, 23:29
Вы плохо посмотрели, у вас -100096 а у меня -100 000. Разговор про INT-FLOAT
Про INT-DECOD вопросов нет.
Прочитали бы пару строчек по ссылке, что я давал, что там написано:
74855
kondor3000
30.03.2024, 17:14
все таки st это st
Переписал функции на ST, теперь они подходят для INT и для DINT 74859
Сергей0308
30.03.2024, 17:38
Сергей верхний макрос INT-FLOAT считает не правильно, скрин 74852 вот его модернизировал 74851
Перевод во FLOAT надо делать после вычитания, иначе теряется часть последних цифр. При чём на пределах -1 000 000, -10 000, -1000 разные цифры в конце.
Число 4294867296 это -100 000
Посмотрел этот макрос, вот преобразование самого большого по модулю отрицательного числа:
74863
Никакой погрешности там нет! Зачем было обманывать, мне не понятно в принципе!
Этот макрос для преобразования диапазона INT(INT16), для преобразования DINT(INT32) он не подходит!
Собственно для этого и усовершенствовал макрос, он чуть ниже, я его на скриншоте показывал(к которому у Вас претензий нет), он уже универсальный в смысле диапазона INT(INT16)/DINT(INT32), настройки в свойствах макроса!
Короче, не заметил настроек у вашего макроса, он универсальный или только диапазона DINT(INT32)?
Обычно используется диапазон INT(INT16), например во всех овенских ТРМ-ах!
kondor3000
30.03.2024, 18:16
Никакой погрешности там нет! Зачем было обманывать, мне не понятно в принципе!
Этот макрос для преобразования диапазона INT(INT16), для преобразования DINT(INT32) он не подходит!
Я пытался его использовать для DINT, даже скрин выложил с 31 битом. Вопрос снят.
Сергей0308
30.03.2024, 18:43
А зачем вообще нужно разделять 16/32?
Если откуда прилетело именно int16 - то сделать int16_to_32
Далее все операции абсолютно одинаковы.
А для отправки - так все равно улетает младшее слово.
А вопросы переполнения - так это не здесь, а "в консерватории нужно что-то поправить"
А как их можно не разделять?
Например, мы получили код числа "65535", в INT16 это будет число "-1", а в INT32 это будет число "65535".
В смысле, без знания диапазона, правильное преобразование не возможно!
Сергей0308
30.03.2024, 20:36
Легко.
(откудато - извне) Т.е. заполнить биты 16..31й 15тым. И всё.
Обратно - не требуется
Что-то я до конца не пойму, так получается всё-таки надо знать тип данных(INT/DINT)?
А, если мы знаем тип данных нет и проблем, не надо тогда изощряться изощрёнными способами!
Легко.
(откудато - извне) Т.е. заполнить биты 16..31й 15тым. И всё.
Обратно - не требуется
То же непонятно. В любом случае либо приемная часть должна знать разрядность передающей части, либо передающая часть знать разрядность приемной части и подстраиваться под нее. Так почему сразу не указать, что у нас 16 бит или 32.
Сергей0308
30.03.2024, 21:25
!?
Угу. Делать разные функции для 16 и 32, настраивать для 32 бит, для 16 бит - это же не извращение.
А через real делать базовые машиные операции - так это вообще нормуль нормулёв.
Ну, это "плата" за универсальность, в смысле никто не запрещает создать отдельные макросы для каждого диапазона!
В моём варианте это минимальная плата, всего один SEL:
74867
Что сводит к минимуму необходимость в отдельных макросах!
Мне кажется один из самых универсальных вариантов для расчёта отрицательной части диапазона Пётр из Минска предлагал, в смысле, инверсия(кода числа) + 1, получается значение отрицательного числа по модулю, я свой вариант предложил, мне он проще показался!
В моём варианте это минимальная плата, всего один SEL:
в моем варианте это приведение внешних i16 в i32.
в смысле никто не запрещает создать отдельные макросы для каждого диапазона!
и в моем варианте не нужно создавать отдельные макросы для каждого диапазона. Он 1.
инверсия(кода числа) + 1
0 - u
kondor3000
30.03.2024, 21:50
Ну, это "плата" за универсальность, в смысле никто не запрещает создать отдельные макросы для каждого диапазона!
Что сводит к минимуму необходимость в отдельных макросах!
Мне кажется один из самых универсальных варианта Пётр из Минска предлагал, в смысле, инверсия + 1, получается значение отрицательного числа по модулю, я свой вариант предложил, мне он проще показался!
Если есть функции для 32 битных, типа DINT, то как сказал Валенок, для 16 битных они не нужны. Скрин 74868
Вы передаёте 1 регистр если число меньше 65535 и через 2 регистра если больше и 32 битными функциями работаете с любыми переменными.
На скрине передан 1 регистр, а функции 32 битные. На ST функции универсальные, выложил выше. Переключатель делать не стал, хотя это возможно.
Сергей0308
30.03.2024, 22:09
Если есть функции для 32 битных, типа DINT, то как сказал Валенок, для 16 битных они не нужны. Скрин 74868
Вы передаёте 1 регистр если число меньше 65535 и через 2 регистра если больше и 32 битными функциями работаете с любыми переменными.
На скрине передан 1 регистр, а функции 32 битные. На ST функции универсальные, выложил выше. Переключатель делать не стал, хотя это возможно.
И Вы считаете что эти преобразования проще чем один SEL?
kondor3000
30.03.2024, 22:15
И Вы считаете что эти преобразования проще чем один SEL?
Сергей, вы меня удивляете, какие преобразования? Лоджик по умолчанию передаёт младший регистр (если не указать 2 регистра), хотя в программе UDINT. На скрине я просто показал происходящее.
Сергей0308
30.03.2024, 22:37
Сергей, вы меня удивляете, какие преобразования? Лоджик по умолчанию передаёт младший регистр (если не указать 2 регистра), хотя в программе UDINT. На скрине я просто показал происходящее.
Я то это в принципе рассматриваю, без привязки к конкретному случаю, в смысле, к сетевым переменным!
ОЛ в принципе не умеет работать с 32 -х битными целочисленными сетевыми переменными в режиме слейв(подчинённого устройства), в смысле, в любом случае, их придётся разделять на два соседних регистра. Может со временем это поправят, но это не точно!
Сергей0308
31.03.2024, 09:15
Если взять из слейва нужно int16, то int16_to_int32 и работаете c int32
Если отправлять в слейв нужно int16 - то работаете и кладете int32 и всё (уже сказали же)
Если взять из слейва нужно int32 - то склеиваете. Во всех вариантах. Включая Ваш. Но т.к там лежало int32 то и работаете c int32 как и выше.
Если отправлять в слейв нужно int32 - то кладете части. Во всех вариантах. Включая Ваш. Но т.к нужно отправлять int32, то и работаете c int32 как и выше.
Т.е. int32 подойдет во всех случаях, а int16 - в некоторых. (Дальше про стиральный порошок который лучше)
Вроде понял, что Вы хотите! В смысле всегда использовать один макрос DINT(INT32)_TO_FLOAT. Если надо преобразовать INT(INT16), то предварительно преобразовываете его в DINT(INT32).
Короче, мне кажется это не очень логичным, в смысле, чаще всё-таки INT(INT16) встречается, а DINT(INT32) намного реже. Вам надо всё равно знать, что это INT(INT16), иначе правильное преобразование невозможно, уже писал об этом, даже пример приводил! И, мне кажется в FBD проще значение INT(INT16) сразу преобразовать во FLOAT, чем ваше промежуточное преобразование в DINT(INT32). Если Вы говорите в ST это проще, поверю Вам на слово(я в ST не шарю), но это получается частный случай, не более!
Вроде понял, что Вы хотите
Не совсем
В смысле всегда использовать один макрос DINT(INT32)_TO_FLOAT.
Не только. Особенность целочисленных вычислений - абсолютная точность.
В целых никогда не будет x = (x + y) если y <> 0
Если надо преобразовать INT(INT16),
int16 может только извне прилететь. А внутренним вычислениям все равно.
чаще всё-таки INT(INT16) встречается, а DINT(INT32) намного реже.
Да? А что тогда здесь udint а не uint? Нету противоречий?
В 16-ти битах было тесно даже 50лет назад. А необходимость 64-х битов даже сейчас - экзотика.
чем ваше промежуточное преобразование в DINT(INT32).
Оно есть только в 1 случае - если извне пришло int16. И оно 1 раз. Далее нет никакой необходимости выбирать между 16 и 32 и думать - влезут ли промежуточные вычисления в 16 бит. А к моменту когда вычисления не влезают в 32 бита, float уже давно положил на точность.
Вам надо всё равно знать, что это INT(INT16),
И Вам все равно надо это знать. Давайте не будем общую (мою и Вашу) часть проблем называть моей проблемой?
И, мне кажется в FBD проще значение INT(INT16) сразу преобразовать во FLOAT,
Вам кажется. Любое целое во флоат везде одинаково просто. Касаемо ST - я приводил выше эти 5 строк.
Если Вы говорите в ST это проще, поверю Вам на слово(я в ST не шарю), но это получается частный случай, не более!
Я понимаю что ссылки по Вашим ссылкам доходят до "времен Очакова и покоренья Крыма" (практически буквально) - но ST какой никакой уже есть. Что касается частных случаев, то всё на ФБД и т.п графическом является частным случаем текстовых языков а не наоборот.
Сергей0308
31.03.2024, 18:16
Не совсем
Не только. Особенность целочисленных вычислений - абсолютная точность.
В целых никогда не будет x = (x + y) если y <> 0
int16 может только извне прилететь. А внутренним вычислениям все равно.
Да? А что тогда здесь udint а не uint? Нету противоречий?
В 16-ти битах было тесно даже 50лет назад. А необходимость 64-х битов даже сейчас - экзотика.
Оно есть только в 1 случае - если извне пришло int16. И оно 1 раз. Далее нет никакой необходимости выбирать между 16 и 32 и думать - влезут ли промежуточные вычисления в 16 бит. А к моменту когда вычисления не влезают в 32 бита, float уже давно положил на точность.
И Вам все равно надо это знать. Давайте не будем общую (мою и Вашу) часть проблем называть моей проблемой?
Вам кажется. Любое целое во флоат везде одинаково просто. Касаемо ST - я приводил выше эти 5 строк.
Я понимаю что ссылки по Вашим ссылкам доходят до "времен Очакова и покоренья Крыма" (практически буквально) - но ST какой никакой уже есть. Что касается частных случаев, то всё на ФБД и т.п графическом является частным случаем текстовых языков а не наоборот.
Так не надо так глубоко копать, так не мудрено дойти и до царя Гороха!
Короче, вот добавил в макрос преобразование INT в DINT и обратно и вход выбора типа данных, диапазона INT/DINT.
Если на входе выбрали INT, то на дополнительном выходе(что я добавил) преобразуется в DINT и обратно, если на входе выбрать DINT, то на выходе преобразуется в INT, если диапазон не превышать! Надеюсь, понятно объяснил?
74872
74873
Сергей0308
01.04.2024, 14:10
В обратно особой надобности нету.
.. то при любых* вычислениях с int32, младшее слово всегда содержит int16 (а биты 16..31 (int32-ого) всегда повторяют 15-й)
*Даже если какие-то промежуточные выходили за рамки int16 (но были в рамках int32)
a : int16 = 1000;
b : int16 = -1000
c : int16 = 10000
x := (a * b) / c
//(1000 * -1000) / 10000 = -100 (int16)
В рамках int16
1000 * -1000 => -16960
-16960 / 10000 => -1
В рамках int32
1000 * -1000 => -1000000
-1000000 / 10000 => -100 (FFFFFF9C) int32 => (FF9C) int16 => -100
На форуме много раз говорили, что математические действия с переполнением будут верными, рискнул так сделать, тогда функция упростится, станет одной для разных действий, короче, вроде правильно считает(сильно не проверял), заодно и "причесал":
74889
74890
74905
Powered by vBulletin® Version 4.2.3 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot