С целочисленными - с точностью до 1 МИЛЛИСЕКУНДЫ
Вид для печати
С целочисленными - с точностью до 1 МИЛЛИСЕКУНДЫ
Да, я про это написала, можно мс указывать как тысячные доли секунд, OL допускает, не ругается. Но я предполагаю, что при подстановке из WriteToFb целочисленного значения, оно будет интерпретировано так, как указано в свойствах ФБ, минимально как секунды. Проверить на ПР нет возможности, поэтому тут спрашиваю
Для этого ПР не нужен, запустите эмуляцию и всё видно будет. Вложение 80380
Спасибо всем за помощь. Для меня оказалось неочевидно, что параметр "Длительность импульса" задается по-разному в зависимости от способа ввода - через свойства или через блок записи в ФБ. В одном случае в комбинации с масштабом, в другом - в "исходных" единицах. Так себе инкапсуляция, после 25+ лет программирования на с++ такие вещи в принципе воспринимаются как "условно невозможные".
ПР102, проект в Owen Logic изменяю на экране, сохраняю проект. После этого загружаю в реле, а загружается старый вариант. Проект с изменениями загрузился только после перезапуска программы. Может я чего не так делаю?
Вчера на домашнем компьютере обновил OwenLogic до 2,8,361 причем спокойно с первого раза - как обычно. Сегодня на работе пытаюсь сделать тоже самое, но не могу. Пишет сообщение о загрузке файла с ошибкой.
Вложение 80520
Соответственно проект который правил дома на работе открыть не могу. Это только у меня данная проблема или общий баг?
Спасибо за отклик. Разобрался. Проблема во внутренней сетке оказалась. Раздал интернет с телефона, все с первого раза обновилось.
Верните функцию "Сохранить устройство ка шаблон" и "Тиражировать" в настройке прибора ПР103.
Вложение 80651
Вложение 80650
При открытии OL 2.8.362.0 без интернета возникает сообщение:
Вложение 80661
На более ранних версиях такого не было.
Добрый день,
Подскажите можно ли надеятся, что в новом обновлении добавят возможность работать с битами в целочисленных переменных на языке ST, так как это реализовано в Codesys.
Речь идёт о возможности как извлекать, так и записывать бит в целочисленную переменную указав имя переменной, после чего ставится точка и указывается бит с которым надо работать (a:= example.bit0)?
В каждом втором примере, на ST есть извлечение и упаковка бит через точку. https://owen.ru/forum/showthread.php?t=38920&page=2#13
Добрый день!
Подскажите, пожалуйста, не могу сохранить проект - скрины в приложении.
При всем при этом, день нормально отлаживалась программа, проблем не было, день закончился, нажал кнопку сохранить и вот:
Если нажать кнопку "Сохранить" - скрин №1
Если нажать кнопку "Сохранить проект как" - скрин №1
Так ST и для меня истинный кайф в ПР.
Недавно пришлось старый проект переделывать. Открыл функциональный блок и закрыл испугавшись. Удалил нафиг и все описал строчками кода. А входов там 450 штук, да и выходов не на много меньше. Excel здорово помогла автоматизировать набор переменных.
Excel вообще весьма универсальный инструмент. Я в последнее время почти любую программу начинаю с заполнения самодельного генератора регистров, который:
1. Позволяет собрать по шаблонам группы объектов управления (насосы, датчики, фильтры и т.д.)
2. Составить шаблонно связанные регистры - с автоматическим назначением адреса/номера бита/единиц измерений и т.п.
3. На выходе - готовые таблицы для импорта в панель Weintek (как регистров так и журналов событий/аварий)
4. На выходе - готовые таблица с json для импорта в OwenCloud (вот прям 300-800 регистров/тегов/битов с текстовым описанием/текстовым подстановкой/единицами/коэффициентами и т.п., разложенными по подпапкам)
5. На выходе - готовая таблица регистров управления/диспетчеризации в приложения к шкафу / заказчику/подрядчику.
6. Жду импорта переменных для ПР205/103 чтоб и туда сразу махом все подтягивать. Но пока разработчики OL завтраками кормят.
7. Разбираюсь (но это не точно) как в MasterScada подтянуть, но чую, что сходу не получится.
Есть замысел эту таблицу таки превратить в отдельную программу со встроенной БД и... но пока это только замысел
C экспортом в МастерСкаду (4D) тоже можно такое провернуть - не сложнее, чем в вайнтек.
С модбасом это так выглядит - в дерево скады добавляется протокол и устройство, потом двойным кликом на устройстве открывается окно импорта-экспорта. Формат файлов - Excel.
Вложение 80754
На других протоколах думаю аналогично должно быть
kaftanati Молодец! Отлично! Я ща такое решение встраиваю в свою базу 1Ски. Будет генерить:
* Расчёт мощностей блоков питания
* Список синалов IO и код для них по шаблонам
* Карты регистров и код для них по шаблонам
После обновления OWEN Logic при редактировании ST постоянно вываливается ошибка, даже когда просто правишь комментарии Вложение 81001 Не подскажете как исправить?
Только меня смущает качество отображения чисел с плавающей точкой в среде Owen Logic?
Если там используются стандартные float, то точность отображения должна быть порядка 6 знаков (пример: 123.456, 1.00000). Сейчас же если число не выводится в формате 1 или 1.0, то сразу начинает выводиться в научном формате: 8.33E+00. Вопрос, зачем?!? Вы так показываете округление? Предлагаю или сделать на галочке, или просто сразу отображать нормально: если число в обычном десятичном формате занимает не более 8 символов (с учетом десятичной точки/запятой), то в нем и выводить. При таком алгоритме возможны проблемы с числами по модулю меньше 1, но тут можно просто до E-03 выводить в обычной форме.
А то отлаживаешь, а у тебя все цифры скачут в разные стороны.
b-s-a Меня на смущает. Меня БЕСИТ просто, потому что мне непривычен формат с E+xx. Я его видел в начале 00ых годов в институте и сейчас в OwenLogic.
Ничего не имею против него. Это научный формат. Мы в институте, обычно, писали 0,1234*10^-6, но 0.1234e-6 несколько лаконичней. Этот формат очень удобен для сохранения необходимой точности вычислений: нельзя написать 10*9.8*3.1415926=307.8760748 - надо писать 0.31e+3, так как исходные данные имеют минимальную точность 2 знака. В науке это важно...
Но вся эта херня не имеет отношения к OwenLogic, так как здесь ограничения по точности накладывает только битовая разрядность переменных. Я посмотрел представление OL - в научном формате число занимает 8 символов: 3 значащих знака, десятичная запятая, буква E, знак степени и две цифры степени. Поэтому можно спокойно писать числа до миллиона в нормальном виде, более миллиона в научном, с шагом экспоненты 3: 1.23, 12.3, 123, 1230, 12300, 123000, 1.23е+06, 12.3е+06, 123е+06, 1.23е+09... Аналогично для чисел меньше 1: 0.123, 0.0123, 0.00123, 123е-06, 12.3е-06, 1.23е-06, 123е-09... Почему так? Во-первых, близкие числа не будут так часто скакать между экспонентами - а то смотришь, параметр должен расти, а он на первый взгляд в 10 раз уменьшается, это только потом, если успеваешь, можно разобрать изменение экспоненты. Во-вторых, наиболее популярные значения будут в интуитивно понятном виде. В-третьих, когда присутствует экспонента, она сразу совместима со стандартными размерностными приставками (микро, мега...).
Если так нельзя, то хотя бы всегда отображать float в научном формате с шагом экспоненты 3: 0.123e+03, 1.23e+03, 12.3e+03, 0.123e+06... и 12.3e+00, 1.23e+00, 0.123e+00, 12.3e-03, 1.23e-03...
В науке - пусть. Меня бесит, когда я пишу числовую константу типа 4294967295 (0xFFFFFFFF) и вижу там этот формат.
Если так нельзя, то хотя бы всегда отображать float в научном формате с шагом экспоненты 3: 0.123e+03, 1.23e+03, 12.3e+03, 0.123e+06... и 12.3e+00, 1.23e+00, 0.123e+00, 12.3e-03, 1.23e-03.
Не спорю. Но насколько помнится( могу и ошибаться),что мантисса всегда должна принимать значение от 1 до 10..
Но как написать мантиссу-тоже регламентируется.(стандартизуется).
1.23e+03,
Вот это правильно.
Мантисса должна быть от 1 до 10, называется стандартный вид числа, изучается в 8 классе школы:
https://math-prosto.ru/ru/pages/stan...d_form_number/
https://nsportal.ru/shkola/algebra/l...nyy-vid-chisla
https://ege-study.ru/ru/oge/material...tm_num_popup=3
Сергей.
Читать такую массу полезной информации 1-го числа Наступившего года как-то несвоевременно..Но хочется сказать ,что хорошо хоть то ,что числа отображаются в "десятичном формате",если бы в "двоичном"-то вообще бы "задолбались".
Но про то ,что нужно что-то в существующей "редакции менять" так и осталось для меня "тайной за 7-ю печатями".
всего-то достаточно сделать настройку как отображать числа float. и сколько знаков после запятой. При программировании той же вентиляции как-то глубоко пофигу на E+, достаточно и 2-х знаков.
всегда ставлю макросы округления и не парюсь. Но ведь можно было обойтись и без макросов.
Да. Я не хочу изучать математику и все эти мантиссы и какие-то ерунды. Мне это не нравилось и не нравится. И когда пишут что-то типа 2.08E-2 я буду дико тупить, потому что не знаю (и не хочу знать), как это ввести в калькулятор Windows чтобы получить понятное число.
Поэтому не надо тут всякой школы и высшей математики. Я наелся этим по горло. Я хочу программировать и видеть свои цифры, а не в ВУЗ играть. Фу.
Если это шутка-то это просто классная шутка!
Такое чувство,что число с "плавающей точкой" Вы стараетесь подменить на число с "фиксированной точкой"
Тогда числу "плыть" будет некуда и при "математических вычислениях" Вы очень проиграете в точности.
Либо придётся округлять.
всегда ставлю макросы округления и не парюсь.
Всё совершенно правильно.(Чуть не написал "С лёгким паром!")
А то ,что удобно-я не спорю. Но "машина" вычисляет именно так ,как и "затеяно" в ОЛ.
Вложение 81099
А когда вы что-то проверяете,то в любом случае получается "более понятливее". Впрочем убрать "целый пласт курса за 8 класс" и отпустить учеников на каникулы- это тоже не плохо.
Дело не в том, что кто-то курс пропустил. А в том, что это дико не удобно, когда у тебя при отладке значения прыгают 9,82 -> 1,01e+01 -> 9,93 -> 1,12e+01...
Если с шифтом перетащить переменную на вход блока - можно получить такую интересную конструкцию:
Вложение 81150
И наверное это всё же баг, а не фича
Попробовал, ругается
Вложение 81151