Просмотр полной версии : OwenLogic 1.15
Андрей Посохов
19.08.2019, 15:33
Всем привет!
Мы выпустили бета-версию OwenLogic 1.15.
Будем рады вашим отзывам и пожеланиям.
Скачать OwenLogic 1.15.201 (https://owen.ru/uploads/168/setup_owenlogic_1.15.201.zip)
Что добавили и улучшили:
1.Изменение значений в онлайн отладке
Теперь Овен Лоджик умеет изменять значения входов функциональных блоков в онлайн отладке. Доступно два режима: однократная запись и фиксация значения.
Однократная запись приводит к изменению значения на входе функционального блока в течение одного цикла, в последующих циклах прибор использует значения с выхода подключенного функционального блока или входа прибора. Подходит для имитации одиночных импульсов.
44166
При фиксации значений прибор будет использовать введенное значение до тех пор пока фиксация не будет снята или не прекращена онлайн отладка. Подходит для имитации постоянных во времени сигналов.
44167
2.Меньше времени на создание переменных
Улучшили создание переменных в Таблице переменных.
Теперь переменные создаются при помощи кнопки или комбинации клавиш Ctrl+N.
44168
Если создать переменную во время поиска, то будет создана переменная с именем веденным в поле Поиск.
44169
Так же переменные можно создавать дублированием из другой переменной. Операция доступна по кнопке или комбинации клавиш Ctr+D.
44170
3.Сортировка переменных по энергонезависимости и типу.
В Таблице переменных появилась сортировка по энергонезависимости и типу.
44171
Заранее всем спасибо за обратную связь и помощь сделать Owen Logic еще лучше :)
Скачать OwenLogic 1.15.201 (https://owen.ru/uploads/168/setup_owenlogic_1.15.201.zip)
Все конечно классно, но нельзя ли сделать нумерацию вновь вставленных переменных не такой безумной. Можно же просто присваивать номер по очереди, ну или хотя бы без дефиса. Ведь вы почти сделали идеальное средство создания большого объема новых пронумерованных переменных... Но нет...
Андрей Посохов
20.08.2019, 14:33
Добрый день.
Спасибо за обратную связь.
Подумаем, как сделать лучше.
v.borovikov
20.08.2019, 14:41
Все конечно классно, но нельзя ли сделать нумерацию вновь вставленных переменных не такой безумной. Можно же просто присваивать номер по очереди, ну или хотя бы без дефиса. Ведь вы почти сделали идеальное средство создания большого объема новых пронумерованных переменных... Но нет...
Добрый день.
Что не так с нумерацией созданных переменных?
Ну вот смотрите было бы идеально, если есть переменная xxx
Мы ее дублируем сочетанием клавиш. Было бы хорошо , чтобы создалась переменная xxx1, если ещё раз нажать дублирование, то проверить, если переменная xxx1 существует, то присвоить ей имя xxx2 и так далее.
Очень часто при обработке большого количества однотипных данных (обратотка аварий или распаковка/запаковка битовых переменных ) нужно создавать массив переменных с прирастающим номером. Тут как раз бы очень выручил функционал дублирования. Дефис я считаю лишним элементом, который перегружает имя переменной.
Идея с номером переменной при дублировании хорошея.
Сергей0308
21.08.2019, 06:36
Ну, а если не надо переименовывать, например с другого проекта копируешь? По вашему, в идеале наверно так: одеваешь на голову считыватель мысли, уже есть такие устройства, выглядят в виде короны с проводами. Мысли считываются, переменная переименовывается, переназначается привязка к другой переменной, короче одни плюсы со всех сторон, главное самому ничего не делать, а то можно такого наворотить! Я Вас правильно понимаю?
Алексей Геннадьевич
21.08.2019, 09:37
bayk игорь68
Автонумерация это хорошо ? :confused:
Реализация этой функции довольно проста.
Есть ли она в языках МЭК 6-1131/3 ? А если её нет, (а её там нет) то почему? (Безопасность превыше всего).
Сергей0308 Присоединюсь к вам: а если в момент работы со "считывающей короной" мимо пройдёт сочная блондинка? Что будет записано редактором программ управления? :rolleyes::D
Алексей Геннадьевич убедили. Безопасность она дороже пары кликов мышкой. PS Ещё не разу не видел сочную блондинку рядом со шкафами автоматики )))
Сергей0308 и Алексей Геннадьевич
Я не понимаю, почему к моему здравому предложению к уже реализованной функции такая неприязнь? И при чем тут копирование из другого проекта? Я не предлагаю делать перенумеровку автоматом всегда, а только при вызове функции дублирования переменной, которое заявлено в релизе. Функция то уже реализована.ну если так принципиально, то пусть дефис останется, но нумерация после него будет приростать.
Если эта функция опасна, то наверное надо вообще ее убрать из ОЛ.
Сергей0308 и Алексей Геннадьевич
Я не понимаю, почему к моему здравому предложению к уже реализованной функции такая неприязнь? И при чем тут копирование из другого проекта? Я не предлагаю делать перенумеровку автоматом всегда, а только при вызове функции дублирования переменной, которое заявлено в релизе. Функция то уже реализована.ну если так принципиально, то пусть дефис останется, но нумерация после него будет приростать.
Если эта функция опасна, то наверное надо вообще ее убрать из ОЛ.
Вы наверно сами и не пробовали как работает эта функция потому, что
пусть дефис останется, но нумерация после него будет приростать
именно так она и работает
https://owen.ru/forum/attachment.php?attachmentid=44218&d=1566379754
Да, действительно не пробовал, поскольку никак не выберусь из "полей". Успеваю только вечером форум с мобилы подистать.
Тогда ещё один вопрос, а почему нумерация с 2 начинается?
Доброе утро. Я начал потихоньку работать в этой версии. Наткнулся на проблему. Если из другого проекта скопировать большой элемент, а приставке его в новый ширина холста меньше, чем вставленный объект, то передвинуть вставленный объект целиком невозможно. Скорее всего и по отдельности элементы за пределами полотна не достать. У меня не влез маленький хвостик от переменной м уже все - приплыли.
Еще, давно забывал написать, но просто вымораживает, что если использовать границу комментария для выделения какой-то зоны, то невозможно работать с элементами, которые попали под нее. одинарным кликом элемент выделяется, а вот двойным кликом открывается редактирование комментария. я очень прошу, сделайте ему по умолчанию положение "позади всех" чтобы комментарий без дела не выбирался.
Нашел очередной косяк в 1.15.215.19479. я импортировал большой макрос с макросами в проект. потом решил, что он мне не нужен. и удалил его (на поле даже не заносил). теперь не могу удалить макросы, которые входили в его сосвав - ОЛ пишет, что они используются в том самом удаленном макросе. если нажать в информационном окне на отсутствующий макрос - выдает сообщение без смысла.
хоть как-то помогает перезапуск лоджика. но надо обязательно перед перезапуском подвигать что-то на экране, иначе сохранение не приводит к запоминанию удаленного макроса. тогда можно удалить... но если вложения в макросы глубже, то надо много раз все это перезапускать.
ДА ЧТО ЗА ЧЕРТ!!! почему удаляется пункт "три точки" в макросах??? хорошо не сохранился, а то я не смог даже подняться из раздела "другие макросы" в общий список!!!
Мне жутко не нравится работа с экранами - эмуляции нет, передвигать экраны невозможно, при переименовании экрана - в группе его название не меняется, отображается старое.
передвигать экраны возможно! вот пост (https://owen.ru/forum/showthread.php?t=31245&p=310682&viewfull=1#post310682), в котором все идеально показано!
Спасибо! Я уже закончил проект в котором каша из экранов и их переходов :) Кто бы мог знать
Снизу имеется разделение рабочего поля. Предлагаю сделать разбиение, при котором на другом экране не будет тех элементов, которые на первом. И портов, уже занятых на первом. Удобно будет раскидывать.
Экраны можно перемещать, связи при этом не теряются.
Экраны можно перемещать, связи при этом не теряются.
Да, я это уже понял. Выше говорил про само рабочее поле, где функциональные блоки расставляются.
Я понял, но это маловероятно, я тут попробовал поработать в аналогичной среде другого российского перспективного программируемого реле, так там среда сделана вообще негуманоидной рассой исключительно под собственные тентакли и специфику зрения. Теперь, сравнив эти две среды хочу поставить коньяк в отдел разработок овена, хотя косяков и не мало. Очень надеюсь, что они доведут экраны на своих реле хотя бы до уровня 2511 (я думаю все догадались, о чем речь) и сделают штатно возможность логирования на внешний носитель.
Я конечно понимаю, что есть уже разработка вместо модуля рс485, но к сожалению это стороннее решение от энтузиастов, и я никак не могу внести его в спецификацию к проекту.
Ревака Юрий
07.11.2019, 10:53
Я понял, но это маловероятно, я тут попробовал поработать в аналогичной среде другого российского перспективного программируемого реле, так там среда сделана вообще негуманоидной рассой исключительно под собственные тентакли и специфику зрения. Теперь, сравнив эти две среды хочу поставить коньяк в отдел разработок овена, хотя косяков и не мало. Очень надеюсь, что они доведут экраны на своих реле хотя бы до уровня 2511 (я думаю все догадались, о чем речь) и сделают штатно возможность логирования на внешний носитель.
Я конечно понимаю, что есть уже разработка вместо модуля рс485, но к сожалению это стороннее решение от энтузиастов, и я никак не могу внести его в спецификацию к проекту.
Для логирования можно использовать owencloud, что касается 2511, сейчас в разработке модель с цветным экраном 2.4" функционал должен быть даже шире.
Сделайте возможность работы с переменными по аналогии с электронными таблицами excel в части выделения, клонирования, копирования (причем не только внутри программы) Также нужна функция массового переименования по шаблону. Ну и для работы с переменными было бы удобно иметь один общий интерфейс во всех местах программы.
Логирования в овен-клауд не удобна, поскольку требует дополнительного оборудования, но кроме этого ещё и доступа в интернет, что ведёт за собой кроме стартовых, но ещё и постоянных в виде абонентской платы за связь . Ещё возникает проблема с отсутствием связи внутри цехов или районов с плохим покрытием. По поводу цветного экрана на прке, плохо, что этот функционал не вынесли на всеобщее обсуждение. Очень надеюсь, что этот экран будет по функционалу, как простенькая ХМИ - кчтобы кнопки можно было по желанию или как навигацию использовать или как дискретные входы в программу. Равно то-же и переходов по экранам должно касаться. Зошь управляй с кнопок , хошь с помощью пере енной. Кстати использование номера экрана как идентификатора перехода значительно удобнее чем привязка событий для каждого перехода каждого экрана
Дмитрий_Е
19.11.2019, 13:29
Здравствуйте. При попытке редактирования групп в Менеджере экранов, окно программы изменяет размер. Если после этого развернут окно программы на весь экран шрифты и изображение схем сбивается, работать крайне неудобно, помогает только перезапуск программы. Windows 10 x64
4570445705
Ну с экраном работы видут давно. Это все обсуждается в закрытой группе в VK. Одна из "плюшек" доступ к цвету экрана через переменную. Будут кнопки и .....
В Owen Logic 1.15.215.19479 экраны можно переименовать, в менеджере экранов имена отображаются корректно, но в редакторе группы они остаются старыми.
Это сильно усложняет понимание связей между экранами при просмотре проекта на следующий день.
Два одинаковых макроса округления (округление до целых), на вход одного подается константа 12.5, на вход второго - выходное число с макроса Pt100 (сопротивление 104,86 --> 1.25Е+01).
Одинаковые числа на входе, одинаковые макросы, а на выходе первого как и должно быть 13, а на выходе второго 12. Почему?
Сергей0308
30.11.2019, 19:52
Два одинаковых макроса округления (округление до целых), на вход одного подается константа 12.5, на вход второго - выходное число с макроса Pt100 (сопротивление 104,86 --> 1.25Е+01).
Одинаковые числа на входе, одинаковые макросы, а на выходе первого как и должно быть 13, а на выходе второго 12. Почему?
Почему, почему, по тому, что повезло Вам! У меня вот погрешность отображения составляет более пяти миллионов единиц, это Вам ни какие ни будь там сотые или десятые доли:
45885
Допёр - потому как отображается округленное число флоат, не все разряды видим.
roman_1986
02.12.2019, 09:06
Добрый день уважаемые разработчики... В двух словах: У нас имеется ПР200, СП307Б, МВ110-32 и МУ110-32. Связь по RS485 следующим образом (скоростя пробовали разные и 9600 и 115200): СП307 (мастер)->ПР200 (RS485-1), затем с ПР200 (RS485-2) на модуля МВ110 и МУ110... Программа состоит из одного большого макроса + много небольших макросов... Проблема в следующем: при срабатывание датчика происходит включение реле (по программе),так вот датчик сработал, а реле может сработать сразу, а может и через секунду... что для нас очень нежелательно. По мере удаления макросов из программы, начинает работать стабильнее... ПО информации в программе - среднее время выполнения программы - 9мс... А в действительности как будто 1 секунда...
Собственно вопрос: как в OwenLigoc обрабатываются макросы? Пока макрос не отработает, программа ждет?
Надеюсь смог объяснить проблему... Заранее спасибо.
45898
Неплохо было бы посмотреть саму программу, чтобы видеть, как она обрабатывает сигнал с датчика. Датчик аналоговый или датчик-реле? И при чём тут сетевые настройки? Датчик привязан к одному устройству, а реле -- к другому? Тогда нужно не столько скоростями играть, столько периодом опроса.
Ревака Юрий
02.12.2019, 11:03
Добрый день уважаемые разработчики... В двух словах: У нас имеется ПР200, СП307Б, МВ110-32 и МУ110-32. Связь по RS485 следующим образом (скоростя пробовали разные и 9600 и 115200): СП307 (мастер)->ПР200 (RS485-1), затем с ПР200 (RS485-2) на модуля МВ110 и МУ110... Программа состоит из одного большого макроса + много небольших макросов... Проблема в следующем: при срабатывание датчика происходит включение реле (по программе),так вот датчик сработал, а реле может сработать сразу, а может и через секунду... что для нас очень нежелательно. По мере удаления макросов из программы, начинает работать стабильнее... ПО информации в программе - среднее время выполнения программы - 9мс... А в действительности как будто 1 секунда...
Собственно вопрос: как в OwenLigoc обрабатываются макросы? Пока макрос не отработает, программа ждет?
Надеюсь смог объяснить проблему... Заранее спасибо.
45898
Я думаю проблема в стабильности связи по RS, точнее настройках задержек и таймаутов, если оборудование по связи находится рядом, лучше работать на максимальной скорости. так же играет роль количество сетевых переменных которыми обмениваются приборы. Так посмотрите время ответа на модулях, его можно так же уменьшить, по умолчанию там вроде 20 мс.
roman_1986
02.12.2019, 12:03
Мы тоже грешили на связь... поставили отдельный блок питания на управление (ПР200, МУ110 и МВ110), независимо от скорости связи, происходит тоже самое... переменных сетевых мизер... для панели штук 20, на модулях по 2 переменных... Время опроса уменьшено, время и таймаут ответа по 20 установлено.... Причем интересный момент получился, на ПР200 используются выхода... так вот они работают четко! Соответственно проблема в связи модуле либо ВВОДа, либо ВЫВОДА... Панель (СП307) сидит на первом RS485, с ней проблем нет. Причем на панели индикация переменной, которая ушла на модуль, отображается без задержек и "тормозов", т.е. нажали на кнопке включить выход №1 на модуле ВЫВОДА, бит от панели пошел на ПР200, обработался, отправился на панель и на модуль ВЫВОДА, на панели изменилось состояние бита (а значит и на модуль ВЫВОДА отправили уже бит), а в реале может сразу сработать выход, а может и спустя секунду... и что самое интересное, что задержка варьируется от примерно 0 мс до 1.5 секунд... У меня один макрос содержит очень много элементов... к слову, макрос "весит" почти 3 мегабайта.... при удалении этого макроса работает более шустрее... (предвижу возможные высказывания в адрес данного макросу скажу сразу, данный макрос обрабатывает ту часть программы, с которой вообще нет проблем...) Приближаемся к вопросу, который я задал в самом начале )))
Собственно вопрос: как в OwenLigoc обрабатываются макросы? Пока макрос не отработает, программа ждет?
Возможно ли такое, что пока внутренняя программа (ЯДРО так сказать) не обработает данный макрос, программа не "решает" другие вопросы? У ПР200 внутри стоит STM32 контроллер, и скорее всего реализовано RTOS, ну и соответственно многозадачность... и возможно ли такое, что макрос обрабатывается как то иначе?
До этого решали похожие задачи на ПР200 и с такими же модулями... но макросы были очень мелкими 5-20 элементов... и никаких проблем нет даже на низких скоростях...
По поводу максимальной скорости RS485 - спешу не согласиться что это решение лучше... модуль МУ110 или МВ110 использует всего по 2 регистра... а это 32 бита, ну еще + стоповые и стартовые биты... при скорости 115200 наш модуль может опрашиваться более 2.000 раз (!!!). при том, что программа имеет цикл около 10 мс... т.е. сама программа сможет опрашивать модель не более 100 раз за 1 секунду... даже этого более чем достаточно... НО(!!!) какая будет помехоустойчивость при такой скорости??? При скорости 9600 за 1 секунду мы можем получать данные около 200 раз в секунду.... но помехоустойчивость будет лучше... Я даже согласен что используя STM32, скорее всего используется аппаратный RS232+преобразователь RS485, с аппаратным RS намного проще... отправили регистры в буфер и все, делаем свои дела и ждем когда нам придет ответ в виде прерывания о законченной отправке/приеме данных... т.е. цикл программы нас почти не лимитирует по скорости обмена... Заканчивая свои размышления, хочется скачать что при более высокой скорости и при низкой скорости происходит тоже самое... ну может быть при высокой скорости на чуть чуть быстрее отрабатывают датчики и выхода...
Программу к сожалению не имею право выкладывать в открытый доступ...
roman_1986
02.12.2019, 12:16
Мы даже начали грешили на помехи от клапанов, которые подключены на модуль вывода... и поставили промежуточные реле, чтобы развязать вообще все...
Сергей0308
02.12.2019, 12:47
Мы даже начали грешили на помехи от клапанов, которые подключены на модуль вывода... и поставили промежуточные реле, чтобы развязать вообще все...
Очень интересно, как Вы с помощью дополнительных реле снизили уровень помех?
Ревака Юрий
02.12.2019, 12:57
Мы тоже грешили на связь... поставили отдельный блок питания на управление (ПР200, МУ110 и МВ110), независимо от скорости связи, происходит тоже самое... переменных сетевых мизер... для панели штук 20, на модулях по 2 переменных... Время опроса уменьшено, время и таймаут ответа по 20 установлено.... Причем интересный момент получился, на ПР200 используются выхода... так вот они работают четко! Соответственно проблема в связи модуле либо ВВОДа, либо ВЫВОДА... Панель (СП307) сидит на первом RS485, с ней проблем нет. Причем на панели индикация переменной, которая ушла на модуль, отображается без задержек и "тормозов", т.е. нажали на кнопке включить выход №1 на модуле ВЫВОДА, бит от панели пошел на ПР200, обработался, отправился на панель и на модуль ВЫВОДА, на панели изменилось состояние бита (а значит и на модуль ВЫВОДА отправили уже бит), а в реале может сразу сработать выход, а может и спустя секунду... и что самое интересное, что задержка варьируется от примерно 0 мс до 1.5 секунд... У меня один макрос содержит очень много элементов... к слову, макрос "весит" почти 3 мегабайта.... при удалении этого макроса работает более шустрее... (предвижу возможные высказывания в адрес данного макросу скажу сразу, данный макрос обрабатывает ту часть программы, с которой вообще нет проблем...) Приближаемся к вопросу, который я задал в самом начале )))
Собственно вопрос: как в OwenLigoc обрабатываются макросы? Пока макрос не отработает, программа ждет?
Возможно ли такое, что пока внутренняя программа (ЯДРО так сказать) не обработает данный макрос, программа не "решает" другие вопросы? У ПР200 внутри стоит STM32 контроллер, и скорее всего реализовано RTOS, ну и соответственно многозадачность... и возможно ли такое, что макрос обрабатывается как то иначе?
До этого решали похожие задачи на ПР200 и с такими же модулями... но макросы были очень мелкими 5-20 элементов... и никаких проблем нет даже на низких скоростях...
По поводу максимальной скорости RS485 - спешу не согласиться что это решение лучше... модуль МУ110 или МВ110 использует всего по 2 регистра... а это 32 бита, ну еще + стоповые и стартовые биты... при скорости 115200 наш модуль может опрашиваться более 2.000 раз (!!!). при том, что программа имеет цикл около 10 мс... т.е. сама программа сможет опрашивать модель не более 100 раз за 1 секунду... даже этого более чем достаточно... НО(!!!) какая будет помехоустойчивость при такой скорости??? При скорости 9600 за 1 секунду мы можем получать данные около 200 раз в секунду.... но помехоустойчивость будет лучше... Я даже согласен что используя STM32, скорее всего используется аппаратный RS232+преобразователь RS485, с аппаратным RS намного проще... отправили регистры в буфер и все, делаем свои дела и ждем когда нам придет ответ в виде прерывания о законченной отправке/приеме данных... т.е. цикл программы нас почти не лимитирует по скорости обмена... Заканчивая свои размышления, хочется скачать что при более высокой скорости и при низкой скорости происходит тоже самое... ну может быть при высокой скорости на чуть чуть быстрее отрабатывают датчики и выхода...
Программу к сожалению не имею право выкладывать в открытый доступ...
Сделайте скрины сетевых настроек в Owenlogic. Прочитав вторую часть про скорость, сразу скажу Вы ошибаетесь в быстродействии, не получится опрашивать на скорости 115200 2000 раз в секунду, максимум около 90 и то на не "нагруженной" программе, 10 мс это уже вполне себе нагруженная.
roman_1986
02.12.2019, 13:08
Спасибо за ответ... по поводу 2000 раз в секунду, это я имел ввиду, что по протоколу и данной скорости мы может столько обращаться))) А так, да... максимум 90раз в секунду...и это более чем достаточно....
Функция чтения 0х03 для модуля ввода.
Функция записи 0х10 для модуля вывода.
И там и там стоит галочка - ЗАПИСЬ ПО ИЗМЕНЕНИЮ...
А вот период опроса 25 мс, это я так понимаю именно через сколько будет происходить следующий опрос? Т.е. за 1 секунду опрос - 40 раз? (даже если так, и этого должно быть достаточно..... а у нас как будто 1 раз в 1 секунду....)
45907
45908
45909
Ревака Юрий
02.12.2019, 13:31
Спасибо за ответ... по поводу 2000 раз в секунду, это я имел ввиду, что по протоколу и данной скорости мы может столько обращаться))) А так, да... максимум 90раз в секунду...и это более чем достаточно....
Функция чтения 0х03 для модуля ввода.
Функция записи 0х10 для модуля вывода.
И там и там стоит галочка - ЗАПИСЬ ПО ИЗМЕНЕНИЮ...
А вот период опроса 25 мс, это я так понимаю именно через сколько будет происходить следующий опрос? Т.е. за 1 секунду опрос - 40 раз? (даже если так, и этого должно быть достаточно..... а у нас как будто 1 раз в 1 секунду....)
45907
45908
45909
По первой картинке, интервал между запросами можно уменьшить до 2 мс.
По второй и третей, таймаут ответа можно 200-300мс поставить.
Сами переменные не вижу как выбраны команды, но надеюсь что в модуль вывода только пишем, а из модуля ввода только читаем. По поводу чекбоксов изменения, то это опция для выходного модуля, если у вас данные не меняются часто, лучше оставить по изменению, тогда команда будет уходить на модуль только по факту изменения выходного состояния из ПР, это даст больше времени на другие команды.
roman_1986
02.12.2019, 14:44
В общем сейчас пошел проверять еще раз... Программа со всеми макросами дает задержку в промежутках от 0 до 1.5 секунд.... убираю все макросы - и задержек нет!!! Грешу на большие макросы..... Так же проверил макросы по одному, т.е. оставлял только один макрос и запускал.... нет задержек... при добавлении под одному макросу - начинают появляться задержки....
roman_1986
02.12.2019, 14:57
Хотя память и ресурсы ПР200 заняты на 20%....
45912
Ревака Юрий
02.12.2019, 15:12
В общем сейчас пошел проверять еще раз... Программа со всеми макросами дает задержку в промежутках от 0 до 1.5 секунд.... убираю все макросы - и задержек нет!!! Грешу на большие макросы..... Так же проверил макросы по одному, т.е. оставлял только один макрос и запускал.... нет задержек... при добавлении под одному макросу - начинают появляться задержки....
С Вашими настройками это неизбежно, увеличивается время цикла, и соответственно идут не ответы от модуля, начинаются повторные запросы что затягивает обмен.
roman_1986
02.12.2019, 15:13
Т.е. получается пока макрос не завершит свой цикл, программа ждет?
roman_1986
02.12.2019, 15:24
А какие именно настройки?
Т.е. получается пока макрос не завершит свой цикл, программа ждет?
в контроллерах и ПР нет многозадачности. В данном случае нет разделения макрос и программа, макрос это часть программы, в качестве примера это как обед, пищу принимают по порядку первое, второе и компот, так вот макрос это тарелка второго, а обед это программа, после того как программа выполнилась, записываются выхода, затем считываются входа и опять выполняется программа со всеми своими макросами
Ревака Юрий
02.12.2019, 15:45
А какие именно настройки?
В сетевых настройках, на прошлой странице я написал.
roman_1986
02.12.2019, 15:56
в контроллерах и ПР нет многозадачности. В данном случае нет разделения макрос и программа, макрос это часть программы, в качестве примера это как обед, пищу принимают по порядку первое, второе и компот, так вот макрос это тарелка второго, а обед это программа, после того как программа выполнилась, записываются выхода, затем считываются входа и опять выполняется программа со всеми своими макросами
Т.е. согласно Вашим же словам и получается, что пока я "обед" не съем - "компота" на видать? Если в макросе есть циклические связи (а они наверняка есть), то вполне может получится, что "обед" затянется..... А на счет много задачности - возможно Вы и правы, в ПР точно не должно быть многозадачности...
roman_1986
02.12.2019, 15:59
В сетевых настройках, на прошлой странице я написал.
Изменил все временные интервалы, менял по разному - эффекта нет... Сейчас переписываю программу без макросов... Циклические связи как то могут вносить корректировку по временным интервалам? И все равно не очень понятно... если в среднем один цикл = 10мс... то в секунду наша программа повторится 100 раз... даже если будет 50 раз повторяться программа - не должно быть задержек таких больших....
циклы типа FOR | WHILE в ПР не реализованы, все выполняется один раз. Влияние циклической связи проявиться уже в следующем цикле контроллера
roman_1986
02.12.2019, 16:04
циклы типа FOR | WHILE в ПР не реализованы, все выполняется один раз. Влияние циклической связи проявиться уже в следующем цикле контроллера
Оооо... не знал.... теперь буду знать... спасибо.... Правда теперь еще больше непонятностей в моей ситауции))) Я то грешил на макросы......
Ревака Юрий
02.12.2019, 16:19
Изменил все временные интервалы, менял по разному - эффекта нет....
Не нужно менять по разному, нужно вдумчиво понимать как происходит обмен. В модулях МВ/МУ проверить и уменьшить до минимума время ответа, проверить только на модуле вывода, какая длина линии связи, модули подключены последовательно?
Судя по симптомам, что без макросов связь норма, значит при увеличении цикла или идут перезапросы к модулям что соответственно увеличивает время реакции, или действительно так долго происходит запись всех регистров, но на 10 мс цикла что-то не верится.
roman_1986
02.12.2019, 16:25
Не нужно менять по разному, нужно вдумчиво понимать как происходит обмен. В модулях МВ/МУ проверить и уменьшить до минимума время ответа, проверить только на модуле вывода, какая длина линии связи, модули подключены последовательно?
Судя по симптомам, что без макросов связь норма, значит при увеличении цикла или идут перезапросы к модулям что соответственно увеличивает время реакции, или действительно так долго происходит запись всех регистров, но на 10 мс цикла что-то не верится.
Время меняли не бездумчиво... ставились и большие временные интервалы и маленькие - не было разницы... Вот по поводу перезапросов я тоже думал... что каждый макрос вызывает процедуру опроса датчиков и выходов... и тога вполне понятно почему происходят такие задержки... Как перепишу все без макросов - отпишусь....
Как перепишу все без макросов - отпишусь....
зачем эта бесполезная работа, лучше установите снифер и прослушайте линию, кто испрвно шлет пакеты, а кто тормозит, с тем и нужно будет "бороться"
Если с ПР ушел бит включения по 485 и панель его быстро увидела, а модуль сработал не сразу, то причем тут ПР с программой? Явно модули тормозят.
А, сейчас вспомнил, что они на разных портах. Задержка между портами? Неужели так может быть? Я бы осциллографом полез проверять.
roman_1986
03.12.2019, 07:43
Если с ПР ушел бит включения по 485 и панель его быстро увидела, а модуль сработал не сразу, то причем тут ПР с программой? Явно модули тормозят.
А, сейчас вспомнил, что они на разных портах. Задержка между портами? Неужели так может быть? Я бы осциллографом полез проверять.
Отвечаю на вопрос - ПРИЧЕМ ТУТ ПР С ПРОГРАММОЙ? Чуть выше я писал, что удаляю макросы и начинает работать отлично... добавляю по одному макросу и начинают происходить ненужные огромные задержки.... значит с модулями все в порядке?
roman_1986
03.12.2019, 07:44
зачем эта бесполезная работа, лучше установите снифер и прослушайте линию, кто испрвно шлет пакеты, а кто тормозит, с тем и нужно будет "бороться"
Сегодня оберу такую же сборку на столе... и буду выяснять в чем именно беда....
без проекта бессмысленно вообще разговаривать, просить помощи в решении проблемы
Я так понимаю, что датчик привинчен к МВ, а реле -- к МУ? Но тогда между срабатыванием датчика и срабатыванием реле как минимум 1 цикл, насколь я понимаю. Вообще, кмк, неплохо было бы для начала определить точное время цикла, раз уж программа такая тяжёлая. Был где-то макрос, позволяющий это сделать. Или действительно сниффером послушать. А определив время цикла, от этого уже плясать и устанавливать периоды опроса. А тайм-аут ответа -- побольше.
каждый макрос вызывает процедуру опроса датчиков и выходов
А он вызывает? В сетевых переменных использованы поля "запуск чтения" и "запуск записи"?
roman_1986
03.12.2019, 08:09
Я так понимаю, что датчик привинчен к МВ, а реле -- к МУ? Но тогда между срабатыванием датчика и срабатыванием реле как минимум 1 цикл, насколь я понимаю. Вообще, кмк, неплохо было бы для начала определить точное время цикла, раз уж программа такая тяжёлая. Был где-то макрос, позволяющий это сделать. Или действительно сниффером послушать. А определив время цикла, от этого уже плясать и устанавливать периоды опроса. А тайм-аут ответа -- побольше.
Подключено именно так: Датчики к МВ, реле к МУ. Вот и я понимаю что один цикл между изменениями... даже если 2-5 цикла... это где-то 50 раз в секунду... Но.... жизненные реалии совсем другие.... сегодня займусь анализом цикла... макрос уже нашел для подсчета времени цикла... буду смотреть какие именно временные интервалы и что происходит...
А он вызывает? В сетевых переменных использованы поля "запуск чтения" и "запуск записи"?
Установлена галка "Запись по изменению"...
Ревака Юрий
03.12.2019, 10:44
А, сейчас вспомнил, что они на разных портах. Задержка между портами? Неужели так может быть? Я бы осциллографом полез проверять.
Тут как раз все логично, если панель мастер, то она за раз может вычитать все регистры групповым запросом, с мастером так не получится.
Почитал последние посты - какие-то дебри!
roman_1986,
Вот по поводу перезапросов я тоже думал... что каждый макрос вызывает процедуру опроса датчиков и выходов... и тога вполне понятно почему происходят такие задержки... Как перепишу все без макросов - отпишусь....
Никаких опросов/ записей сетевых переменных в середине цикла выполнения программы, а тем более в макросах НЕ ПРОИСХОДИТ!
ПР работает строго циклически
1. читаются физические входы и входные сетевые переменные
2. значения полученные в п.1 запоминаются в буфере и до конца цикла используются в программе в не измененном виде Даже если состояние входа изменилось, то ПР узнает об этом только в следующем цикле
3. Выполняется ВСЯ программа на холсте, включая ВСЕ макросы.
4. Новые значения ВСЕХ внутренних и сетевых переменных запоминаются в буфере.
5. Происходит запись значений полученных в п.4 в физические выходы
6. Выполняется внутренние процедуры сетевого обмена(запросы чтения или записи)
далее все повторяется с п.1
Перестаньте извращаться над ПР, не нужно делать период опроса 20мс! Вы не даете ПР "вздохнуть" ПР не успевает обрабатывать ответы на запросы! Оставьте значение "по умолчанию" - 100мс, время реакции системы возрастет - не будет 1,5 секунды, а будет 0,1 сек.
И самое главное - зачем Вы читаете из МВ110 по два регистра и соответственно пишете по два регистра в МУ110?
Мастер в ПР не умеет делать групповые запросы и будет делать четыре отдельных запроса - два на чтение из МВ110 и два на запись в МУ110. И то, если в настройках сетевых переменных Вы отключили чтение для МУ110 иначе ПР еще будет делать два запроса на чтение из МУ100, а зачем это?
Я рекомендую читать и писать для модулей сразу по два регистра (DWORD), для них будет выполнятся по одному запросу!
ВВОД_32
45929
1. Период опроса - 100мс
2. читаем сразу два регистра с адреса 99
3. функции записи - НЕТ.
ВЫВОД_32
45930
1. Включаем галку "Запись по изменению"
2. Период опроса в этом случае - не имеет значения, т.к. запись будет однократная - только по факту изменения значения.
3. Пишем сразу два регистра с адреса 97
4. функция записи -0х10,
5. функции чтения - НЕТ
Обнаружил еще одну ошибку в последнем ОЛ, ну и раньше я думаю она была. если установить сетевую переменную на рабочее поле, а потом изменить ее название не в перечне переменных, а через "настройку прибора" то в списке переменных она название поменяет, а на рабочем поле останется со старым именем, при этом будет совершенно работоспособна. чтобы поменять отображаемое имя эту переменную над заменить на любую другую, а потом снова на нужную но обязательно с применением изменений каждый раз.
Сегодня на другом компьютере открыл большой проект. Гляжу, а у логического И один вход никуда не подключен... Точно знаю, что проект рабочий и я в нем ничего не менял. Запустил эмуляцию и, о чудо! На обоих входах лог.1. Значит связь есть, но она просто не отображается. Подвигал элемент, масштаб несколько раз менял - без толку, связь не видна, как будто вход никуда не подключен...
Сергей0308
04.12.2019, 22:34
Сегодня на другом компьютере открыл большой проект. Гляжу, а у логического И один вход никуда не подключен... Точно знаю, что проект рабочий и я в нем ничего не менял. Запустил эмуляцию и, о чудо! На обоих входах лог.1. Значит связь есть, но она просто не отображается. Подвигал элемент, масштаб несколько раз менял - без толку, связь не видна, как будто вход никуда не подключен...
Чтобы восстановить видимость связи я удаляю старую невидимую и вновь протягиваю связь! Если удалить(выделить) старую невидимую не получается можно удалить вместе с элементом!
Такое(невидимость связи) получается при перемещении элемента с протянутой к нему связью, короче, чтобы такого не возникало, сначала перемещайте элемент, а затем протягивайте связь и горя знать не будете!
з.ы. добавьте возможность в макросах использования системных переменных.
А то для Года, Месяца и т.д. надо создавать входа. Ну ведь просится же ?
Кстати я бы добавил и возможность как-то использовать и сетевые переменные, ну это ладно....
RockTeal
05.12.2019, 15:04
Нет всё таки глюк, по крайней мере, с AND. Заметил ещё на пред. сборке45999
RockTeal, Логическая единица на неподключенных входах AND -- это абсолютно нормальная ситуация, и это есть у других производителей программируемых реле. Иначе любой неподключенный вход попросту заблокировал бы этот AND. Кста, а зачем оставлять неподключенными входы AND, когда их всего 2 штуки?
Чтобы восстановить видимость связи я удаляю старую невидимую и вновь протягиваю связь! Если удалить(выделить) старую невидимую не получается можно удалить вместе с элементом!
Такое(невидимость связи) получается при перемещении элемента с протянутой к нему связью, короче, чтобы такого не возникало, сначала перемещайте элемент, а затем протягивайте связь и горя знать не будете!
Я ничего не перемещал! Открыл проект и обомлел - связь кто то стырил! Я что, в большом проекте помню куда шла эта связь?! Удалю элемент и гуд бай логике :confused:
RockTeal, Логическая единица на неподключенных входах AND -- это абсолютно нормальная ситуация, и это есть у других производителей программируемых реле. Иначе любой неподключенный вход попросту заблокировал бы этот AND. Кста, а зачем оставлять неподключенными входы AND, когда их всего 2 штуки?
Вообще то эмулятор должен имитировать реальный мир :) В реальности неподключенные выводы КМОП логики могут запросто ловить лог.1 с эфира :) Периодически и псевдослучайно.
Ollema это нормально. Например у некоторых производителей нет И на 2 входа, сразу на 4. А вам нужно 2, чтобы не лепить к каждому свободному лог 1, так специально запрограммировано.
для ИЛИ свободные входы будут всегда лог 0 например.
з.ы. это программа а не КМОП, здесь предусматриваются такие ситуации.
Вообще то эмулятор должен имитировать реальный мир :) В реальности неподключенные выводы КМОП логики могут запросто ловить лог.1 с эфира :) Периодически и псевдослучайно.
Щас прям ностальгическую слезу смахнул, вспомнив времена, когда не было этих ваших ПРок, а были сплошь 176 и 155 серии. Понятно, что у логики в "железном" исполнении неиспользуемые выводы сажаются либо на общий, либо на питание. В программной модели это необязательно, ибо с эфира там ничего не прилетит.
Я по первости сажал на ноль и в OL ;)
Сергей0308
06.12.2019, 01:03
Некоторые для формирования "1" ставят в программе элемент "не" с "оторванным" входом, что мне кажется просто какой-то дикостью! Я предпочитаю константу для таких случаев!
Угу, видывал и такое буквально сегодня, хыхыхы! Оборванный инвертор с TON использовался как детектор включения питания ПР. И да, сам в таких случая предпочитаю константы.
И да, сам в таких случая предпочитаю константы.
код в студию, как Вы с помощью констант определяете первый скан контроллера в ПР
Сергей0308
06.12.2019, 08:48
код в студию, как Вы с помощью констант определяете первый скан контроллера в ПР
Если после включения при первом цикле ПР на выходе элемента "не" с "оторванным" входом логическое "0", то это неправильно и лишний раз доказывает, что так не нужно делать(оставлять элементы с неподключенными входами! И это легко сделать с помощью константы логической "1" и линии задержки на цикл!
Если после включения ...то это неправильно
значит на первом цикле константа вместо единицы дает ноль это правильно? Иначе, как Вы можете предлагать такой же вариант как на элементе NOT, если код выглядит как то иначе, покажите
На первом цикле константа даёт 1. А вот, так сказать, в "нулевом" цикле, до включения питания -- не даёт. Поэтому линия задержки на цикл в первом цикле выдаёт 0. Ежели задержки на цикл недостаточно, используем TON, который будет =0 на протяжении времени своей выдержки.
Сергей0308
06.12.2019, 09:19
значит на первом цикле константа вместо единицы дает ноль это правильно? Иначе, как Вы можете предлагать такой же вариант как на элементе NOT, если код выглядит как то иначе, покажите
Вообще то если константа "1", то единица должна быть при первом(любом) и последнем цикле, откуда Вы взяли, что при первом цикле там "0" будет? Протяните с константы линию задержки на цикл, уже второй раз приходится для Вас повторить, и будет, я так понимаю, Вам счастье!
в электронных элементах неопределенное состояние на выходе это нормально, но здесь программирование, если переменная/элемент не инициализированы то его начальное состояние ноль/фальш, но константа должна инициализироваться перед запуском программы тем значением которое установлено в проекте. По факту, вы оба рекомендуете действительно ошибочный вариант, а если его исправят?
эээ, да чего вы спорите, оба варианта в студию и в пошаговом исполнении плиз. Мне кажется это еще сила привычки. главное, чтобы работало как задумано.
А задержка на цикл вообще из другой оперы, баго-фича так сказать. В других ПР это и проверяется и настраивается через флаги.
Сегодня на другом компьютере открыл большой проект. Гляжу, а у логического И один вход никуда не подключен... Точно знаю, что проект рабочий и я в нем ничего не менял. Запустил эмуляцию и, о чудо! На обоих входах лог.1. Значит связь есть, но она просто не отображается. Подвигал элемент, масштаб несколько раз менял - без толку, связь не видна, как будто вход никуда не подключен...
Был неправ, каюсь. В рабочем проекте оставил висячий вход элемента И. По выше перечисленным причинам все нормально работало, а меня ввело в заблуждение. Ампутировал этот И, логика не нарушилась, но на душе стало легче :)
Сергей0308
06.12.2019, 09:37
в электронных элементах неопределенное состояние на выходе это нормально, но здесь программирование, если переменная/элемент не инициализированы то его начальное состояние ноль/фальш, но константа должна инициализироваться перед запуском программы тем значением которое установлено в проекте. По факту, вы оба рекомендуете действительно ошибочный вариант, а если его исправят?
Так по-вашему элемент "не" с неподключенным входом что должен на выходе давать при первом цикле? Наверно "1"?
И зачем Вы его рекомендуете?
эээ, да чего вы спорите, оба варианта в студию и в пошаговом исполнении плиз. Мне кажется это еще сила привычки. главное, чтобы работало как задумано.
А задержка на цикл вообще из другой оперы, баго-фича так сказать. В других ПР это и проверяется и настраивается через флаги.
М8, ага.
В данный момент оба варика работают. Чёта даже не думал, что что-то тут могут пофиксить.
Так по-вашему элемент "не" с неподключенным входом что должен на выходе давать при первом цикле? Наверно "1"?
Он и даёт. Но линия задержки на цикл выдаёт 0.
Сергей0308 пустой НЕ будет давать на выход 1 в любых циклах... ему как-то на все остальное пофигу.
Ну, что константа, что НЕ в шаговом варианте одинаковы без всяких линий задержек.
Сергей0308
06.12.2019, 09:51
Ну тогда может энергонезависимая переменная подойдёт?
Оторванные входа это неприемлемо!
Или две линии задержки через промежуточную переменную.
оторванные входа ага, мозолят глаза, но когда понимаешь. что программа это не живая логика становится пофигу :) я тоже по началу возмущался, потом перестал...
Ну тогда может энергонезависимая переменная подойдёт?
Оторванные входа это неприемлимо!
Энергонезависимой вообще пофиг включения/отключения. Как на ней реализовать флаг запуска?
Сергей0308
06.12.2019, 10:06
Энергонезависимой вообще пофиг включения/отключения. Как на ней реализовать флаг запуска?
Вместо константы логической "1" - энергонезависимая булева переменная в состоянии логической "1". Далее - линия задержки на цикл.
Так, надеюсь, правильно со всех сторон?
Вместо константы логической "1" - энергонезависимая булева переменная в состоянии логической "1".
Так, надеюсь, правильно со всех сторон?
А, ну да. Собсно, никто не мешает занулить вход оборванного NOT, результат будет тот же. По факту, это просто наведение красоты. И оборванный и занулённый NOT -- это не что иное, как замена константы 1 на константу NOT 0.
з.ы. красоту надо наводить в других местах, хватает где... это про ОЛ...
меня вот удивило, что сервисные переменные часов нельзя использовать просто в макросе. Нет, надо кучу входов налепить, и кучу переменных на экране... ну почему нельзя ?
По прежнему самая последняя версия ОЛ 15 обнаружил, что невозможно скопировать экранные элементы с одного экрана на другой, уже не говоря об копировании между проектами, если к экранному элементу привязана сетевая переменная. если локальная - то все ок!
кстати, дапвно хотел спросить, а баги, что я тут пишу они к сведенью принимаются, или нужна отдельная тема?
roman_1986
10.12.2019, 07:55
Почитал последние посты - какие-то дебри!
roman_1986,
Никаких опросов/ записей сетевых переменных в середине цикла выполнения программы, а тем более в макросах НЕ ПРОИСХОДИТ!
ПР работает строго циклически
1. читаются физические входы и входные сетевые переменные
2. значения полученные в п.1 запоминаются в буфере и до конца цикла используются в программе в не измененном виде Даже если состояние входа изменилось, то ПР узнает об этом только в следующем цикле
3. Выполняется ВСЯ программа на холсте, включая ВСЕ макросы.
4. Новые значения ВСЕХ внутренних и сетевых переменных запоминаются в буфере.
5. Происходит запись значений полученных в п.4 в физические выходы
6. Выполняется внутренние процедуры сетевого обмена(запросы чтения или записи)
далее все повторяется с п.1
Перестаньте извращаться над ПР, не нужно делать период опроса 20мс! Вы не даете ПР "вздохнуть" ПР не успевает обрабатывать ответы на запросы! Оставьте значение "по умолчанию" - 100мс, время реакции системы возрастет - не будет 1,5 секунды, а будет 0,1 сек.
И самое главное - зачем Вы читаете из МВ110 по два регистра и соответственно пишете по два регистра в МУ110?
Мастер в ПР не умеет делать групповые запросы и будет делать четыре отдельных запроса - два на чтение из МВ110 и два на запись в МУ110. И то, если в настройках сетевых переменных Вы отключили чтение для МУ110 иначе ПР еще будет делать два запроса на чтение из МУ100, а зачем это?
Я рекомендую читать и писать для модулей сразу по два регистра (DWORD), для них будет выполнятся по одному запросу!
ВВОД_32
45929
1. Период опроса - 100мс
2. читаем сразу два регистра с адреса 99
3. функции записи - НЕТ.
ВЫВОД_32
45930
1. Включаем галку "Запись по изменению"
2. Период опроса в этом случае - не имеет значения, т.к. запись будет однократная - только по факту изменения значения.
3. Пишем сразу два регистра с адреса 97
4. функция записи -0х10,
5. функции чтения - НЕТ
И снова здравствуйте )))
По поводу модулей - опрос сделал как Вы показали (спасибо за подсказку)... Но к сожалению, это никак не решило мою проблему, зависание именно связи между ПР200 и модулями... ПР200 работает и обрабатывает все четко!
Собственно что было сделано - из всех макросов все было вынесено в основное окно программы, и самый большой макрос содержал в себе элементов 10... ни алгоритм, ни чего не менял вообще!!! И все заработало отлично!!! Причем независимо от того, какие временные интервалы для периода опроса делать, что 20мс что 100 мс... Понятно, что для 20мс нагрузка на сам процессор может и быть и возрастет, но если вы сталкивались с программированием именно самих микроконтроллеров (точнее с STM23, который стоит в ПР200), то вы должны знать как работает связь по RS485, а точнее по RS232(!!!), и что программный RS232 и аппаратный RS232 работают совершенно по разному! В аппаратной части - мы только передали наши регистры для отправки, а вот как и что оно будет передавать - это уже проблемы аппаратной части микроконтроллера, которая ни как не сказывается на работу основной программы, по окончанию передачи или приема данных - у нас появляется прерывание, либо некий БИТ, говорящий о том, что процесс связи окончен... Еще до работы с ПР200, я программировал на ATMEGA8, которая в разы слабее ПР200, и нагружал намного больше чем на ПР200, так же была связь по RS485 и никаких провалов по связи не было....
В связи с этим снова вопрос)))): Как обрабатываются все-таки макросы, и есть ли ограничение на количества элементов в макросе?
stanislau
18.12.2019, 11:37
Заметил одну странность при режиме работы с экранами. Переходы - вверх/вниз.Если сделать два экрана по три строчки, то третья строчка в первом экране не отображается - на третье нажатие вниз срабатывает переход на второй экран. На втором экране дощелкать до третьей строчки можно.
Сергей0308
18.12.2019, 11:52
Заметил одну странность при режиме работы с экранами. Переходы - вверх/вниз.Если сделать два экрана по три строчки, то третья строчка в первом экране не отображается - на третье нажатие вниз срабатывает переход на второй экран. На втором экране дощелкать до третьей строчки можно.
Мягко выражаясь странные у Вас претензии, если всё работает именно так, как Вы сделали, короче, вот поправил:
46243
stanislau
18.12.2019, 21:46
Ну я думал, что последовательным нажатием вниз прощелкиваются все строки экрана, а при нажатии вниз на последней строке происходит переход на следующий экран. Мне это странным не кажется. А получается, чтобы так сделать надо делать переход не нажатием вниз, а удержанием. Тогда бы настройку времени удержания сделать.
Сергей0308
18.12.2019, 22:27
Ну я думал, что последовательным нажатием вниз прощелкиваются все строки экрана, а при нажатии вниз на последней строке происходит переход на следующий экран. Мне это странным не кажется. А получается, чтобы так сделать надо делать переход не нажатием вниз, а удержанием. Тогда бы настройку времени удержания сделать.
У Вас по нажатию - переход на другой экран, реле и переходит на другой экран, чего здесь странного?
stanislau
19.12.2019, 00:13
Как чего? А третью строку кто отображать будет? То есть переход по нажатию вниз на следующий экран происходит не с последней строки предыдущего. Вот это мне не понятно. Почему так сделано? Доходишь до последней строки, жмешь вниз- в верхней строке дисплея пр200 появляется первая строка следующего экрана. Что тут не логичного? Тогда ни какое "по удержанию вниз" не надо вообще.
Сергей0308
19.12.2019, 00:40
Например Вы хотите сделать(пытаетесь делать) переход на следующий экран кнопкой "вниз"(меньше) у Вас сначала экран должен прокрутится до нижней строки текущего экрана, потом совершится переход к следующему экрану, а я хочу сделать переход в следующему экрану кнопкой "вверх"(больше), это же логично к следующему экрану переходить по кнопке больше, кстати и номер экрана увеличивается, а к преведущему кнопкой меньше(номер экрана уменьшается), короче, ПР не знает, кто там чего хочет, оно выполняет поданные команды!
Совсем забыл спросить, в моём случае, надо полагать, он ещё более логичный чем ваш, экран тоже должен до конца вниз промотаться перед переходом или вверх?
Если переход на следующий экран стрелкой вверх, то ничего не меняется в плане невозможности "листать" строки текущего экрана, только теперь будет невозможно перемещаться по строкам вверх.
Короче,
Если уж так хочется задействовать стрелки вверх и вниз для перехода между много строчными экранами - используйте комбинацию "ALT+ Стрелка вверх" и "ALT+ Стрелка вниз"
stanislau
19.12.2019, 12:39
Так вверх все аналогично. Если есть строки выше-листаем их, если нет или долистали до крайней, то переходим на следующий экран вверх (при этом "курсор" оказывается на первой/верхней строке дисплея). Как сейчас помню:) на приставке "денди" типовой картридж на 999 игр в одном:D Первый экран 1-100, второй 101-200 и т.д. Листаешь себе до 100й игры - это один экран, нажал еще раз - появился второй экран со списком игр 101-200. И ни каких удержаний не надо. Начинаешь листать с первой строчки экрана. Если так сделать невозможно в OL, то в описании стоит указать, что переход к следующему экрану нажатием вверх/вниз стоит использовать только если экран содержит не более двух строк. Я сразу не обратил внимания, а потом смотрю - не хватает одного параметра, в OL он есть. Переделал чтобы этот параметр был в отдельном экране. Думал, что это глюк какой-то, а оказывается, что нет:confused:
stanislau
19.12.2019, 12:46
И да. В ПЧ, устройствах защиты двигателей, различных контроллерах и даже телефонах с которыми мне приходилось сталкиваться меню листалось вниз, а не вверх. Вот и в пр200 системное меню (то, которое вкл через alt) пролистывается нажатием вниз.
Massmeter
28.12.2019, 21:06
Уважаемые господа. Еще недавно предельные значения настроечных коэффициентов ФБ PID выглядели по-человечески. Сейчас они выглядят как на картинке. Нельзя ли все вернуть обратно?
Серёга Букашкин
22.01.2020, 15:48
Почему-то в ОЛ15.222 когда стал смотреть время цикла на системном индикаторе ПР200, то оно плавает, и сильно. В моем случае 10,03...11,07 мс. В более ранних версиях не было такого, было стабильным. какие процессы его меняют если всегда все связи выполняются в каждом цикле?
nickbeljaev
23.01.2020, 20:37
Почему-то в ОЛ15.222 когда стал смотреть время цикла на системном индикаторе ПР200, то оно плавает, и сильно. В моем случае 10,03...11,07 мс. В более ранних версиях не было такого, было стабильным. какие процессы его меняют если всегда все связи выполняются в каждом цикле?
У всех ПЛК время цикла плавает, те которые для управления движением просто запускают короткий цикл по таймеру, основная масса просто плавает, а ветвления в МК общего назначения неизбывны, я уже 8 раз упоминаю причину - деление целых, деление флоата тем более содержит в себе ветвления, от них можно избавится только вместе с компилятором. Поэтому, нам всем (ну или многим) нужен системный таймер, учитывая типовое время цикла 5..15 мс, таймер должен быть в мкс, так у мс разрешения не хватит. Я упорный - я это буду здесь писать пока таймер не появится или меня от овена не отвлечет что то более интересное. :)
упоминаю причину - деление целых, деление флоата тем более содержит в себе ветвления, от них можно избавится только вместе с компилятором.по ощущениям, Вы полагаете что об этом знаете только Вы, и даже нет желания подумать что другие при расчете могут все учесть, сколько каждый элемент схемы занимает времени в тактах в любых ситуациях. В ПР время будет плавать, так зачем Вы его использовать хотите, возьмите овеновский плк с PRU не так там уж и велика цена по сравнению с немцем, зато удовлетовит все Ваши потребности в микросекундах
Сергей0308
24.01.2020, 12:55
Было бы удобнее если бы показывало максимальное время цикла. А то при запросах из ОЛ всегда разная величина показывается.
Вы наверно имели ввиду в системном меню?
В ОЛ Вы вольны сделать как Вам удобно!
nickbeljaev
24.01.2020, 16:22
по ощущениям, Вы полагаете что об этом знаете только Вы, и даже нет желания подумать что другие при расчете могут все учесть, сколько каждый элемент схемы занимает времени в тактах в любых ситуациях. В ПР время будет плавать, так зачем Вы его использовать хотите, возьмите овеновский плк с PRU не так там уж и велика цена по сравнению с немцем, зато удовлетовит все Ваши потребности в микросекундах
Ощущения Вас обманывают, но да, меня удивляют заявления о том что в OL нет ветвлений. Я не знаю что такое PRU но Овеневские ПЛК пока брать не хочу. Возможно в следующем поколении они меня заинтересуют.
nickbeljaev
24.01.2020, 16:24
Было бы удобнее если бы показывало максимальное время цикла. А то при запросах из ОЛ всегда разная величина показывается.
Было бы реально удобно если бы могли в любой момент времени измерить отрезок до некоторого предыдущего фиксированного события. Был бы таймер, я бы не участвовал бы в обсуждении времени цикла, а советовал бы всем включать фактически прошедшее время в свои расчеты, и не обращать внимания на колебания циклов.
nickbeljaev
24.01.2020, 16:28
Вы наверно имели ввиду в системном меню?
В ОЛ Вы вольны сделать как Вам удобно!
Был бы таймер, при желании можно было бы вывести минимальное, максимальное, среднее время цикла и не дергать разработчиков своими противоречивыми хотелками по поводу системного показометра.
Ощущения Вас обманывают, но да, меня удивляют заявления о том что в OL нет ветвлений. Я не знаю что такое PRU но Овеневские ПЛК пока брать не хочу. Возможно в следующем поколении они меня заинтересуют.
Странно как то это, то что действительно работает на уровне тактов процессора, для скорости только целочисленная арифметика, восторженные отзывы форумчан по работе с шаговыми двигателями Вас не интересует, а реле на котором даже не всякий энкодер заработает покоя не даёт. За те деньги которые он стоит, ПР свою работу делает
На OL_1.15.231 указана не верная ссылка
46962
Чуть чуть инсайда. У новой ПР будет 2 высоко скоростных входа. . Сроки появлени не подскажу. PS. На этом реле и цветной графический дисплей будет.
stanislau
02.02.2020, 15:51
Наверно с таким дисплеем цена будет не гуманна:)
Подсел на пр200 с плк, честно жуть ФБД, времени на проект уходит в три четыре раза больше.:mad:
:
А если подсесть с ПР на ПЛК то время нужно будет в раз 10 больше ...по началу .Я уж не говорю про уровень вхождения .
Андрей СТ есть в планах. Но нет ресурсов. И не очень скаро. И на первых порах будет не очень много инструментов. Основа ПР это ФБ. Это по причине того что ФБ впервую очередь для электронщиков. А уже потом для программистов . Лично для меня проще понять как работает ЛА3 чем тот-же код на СТ которых описывает этот элемент.
Вы не правы. Все программируемые реле всегда (последние лет 15 точно) выполнялись именно на fbd, я так понимаю, как самом простом для интерпретации в машинный код языке.
Только в лого 8 Сименс наконец добавил подобие LD , да и то это у него толком не вышло.
Кроме этого фбд всегда служил этаким водоразделом между программируемыми реле и полноценными ПЛК. Но мы не забываем, что тот же ПЛК Сименс изначально програмировался на cfc, а лд уже был разработан для снижения планки вхождения в программирование для простых релейщиков. С другой стороны сейчас настолько компьютеризация пробралась в общество, что прыщавые студенты ничего не понимающие в релейных схемах, зато научившиеся мало-мальски кодить на Си начинают путь в ПЛК с , если так можно выразиться, с хвоста паровоза. Но профессионалы используют ST только по делу, где нужна математика или работа с массивами.
nickbeljaev
04.02.2020, 05:30
Вы не правы. Все программируемые реле всегда (последние лет 15 точно) выполнялись именно на fbd, я так понимаю, как самом простом для интерпретации в машинный код языке.
Только в лого 8 Сименс наконец добавил подобие LD , да и то это у него толком не вышло.
Кроме этого фбд всегда служил этаким водоразделом между программируемыми реле и полноценными ПЛК. Но мы не забываем, что тот же ПЛК Сименс изначально програмировался на cfc, а лд уже был разработан для снижения планки вхождения в программирование для простых релейщиков. С другой стороны сейчас настолько компьютеризация пробралась в общество, что прыщавые студенты ничего не понимающие в релейных схемах, зато научившиеся мало-мальски кодить на Си начинают путь в ПЛК с , если так можно выразиться, с хвоста паровоза. Но профессионалы используют ST только по делу, где нужна математика или работа с массивами.
Это ФБД простой в компиляции, как бы не так, я тут заглянул "в прошлое" на этом форуме - мне очень интересно как такая "простая мамочка" как Овен родил такое "симпатичное дитя" как ОЛ, так вот у меня просто волосы дыбом вставали когда я вчитывался в холивары по поводу циклических связей и процесс рождения задержек какие они есть в 15-ом, по этим форумам отлично видно как не просто пришлось "мамочке", а вы говорите простой. ФБД относится к языкам сверхвысокого ур-ня, думаю компилятор с Си сильно попроще (если не считать современного ур-ня оптимизации) будет. И на счет электронщиков это не верно я много лет пишу на Си, но если нужно по быстрому навесить огромную "люстру" из Булевой логики (а это основное развлечение всех АСУшников) ФБД очень спасает, на Си тот же код выглядит довольно адцки из за огромных верениц скобок при вложении функций или промежуточных переменных. Так что тут главное ничего не испортить, пока ОЛ воспринимается весьма юзабельным.
Коллеги вы просто возьмите каталог овен за 2010 и посмотрите на каталог 2019. Очень много приборов сняты с производства и эти же приборы выходят как модификация ПР200. И это будет только развиваться. Про LD и ST. Я первое реле держал в руках в 2000 году. Француз. Так там был выбор LD или FBD. ST рядом не было. Но были пара макросов для некоторых математических операций. Все. Самое интересно что если смотреть на макросы 2000 у француза и на макросы ПР200 всё почти один в один. Стой лишь разницей что некоторые макросы у француза уже тогда позволяли например работать с давление в резервуаре для контроля уровня. А у овен это появилось только сейчас. Но конструктора макросов который изначально был у овен у немца появился только в 7 версии лого.
Это ФБД простой в компиляции, как бы не так, я тут заглянул "в прошлое" на этом форуме - мне очень интересно как такая "простая мамочка" как Овен родил такое "симпатичное дитя" как ОЛ, так вот у меня просто волосы дыбом вставали когда я вчитывался в холивары по поводу циклических связей и процесс рождения задержек какие они есть в 15-ом, по этим форумам отлично видно как не просто пришлось "мамочке", а вы говорите простой. ФБД относится к языкам сверхвысокого ур-ня, думаю компилятор с Си сильно попроще (если не считать современного ур-ня оптимизации) будет. ...
Если по Вашему целой команде программистов адски сложно сделать компилятор с ФБД, то что Вы скажете про FLProg - ФДБ программирование для Ардуино? https://flprog.ru/
Разработал его ВСЕГО ОДИН ЧЕЛОВЕК - Сергей Глушенко https://www.youtube.com/channel/UCI0qdIuuNMOdIoAA-5623rQ/videos?disable_polymer=1
Француз. Так там был выбор LD или FBD
а вы пробовали на ЛД там писать? это и ЛД то не назвать - так прилепух. основа всегда ФБД.
Самое интересно что если смотреть на макросы 2000 у француза и на макросы ПР200 всё почти один в один.
а что там нового может быть? ведь задачи для программируемых реле с годами не меняются, просто в россии все с большой задержкой реализуется.
с другой стороны такой развитой математики нет у забугорных аналогов ни у кого до сих пор, я уже не говорю о выводе на экран.
вы в лого 8 пробовали хоть что-то на экран вывести.... да это же ад и бред.
тем более, если очень хочется СТ, то тогда нужны подпрограммы, поскольку на нем, действительно булевые операции очень многоэтажные, особенно импульсные, в итоге, чтобы это было юзабельно, уже получается полноценная среда для ПЛК.
Как я и говорил ранее - ФБД это тот язык, который отделяет дешевые ПР от полноценных ПЛК вот уже десятки лет. и никто от этого уходить не будет.
самое идеальное, что могли бы сделать овеновцев, это отдельный блок, внутри которого можно писать математику не с помощью блоков, а в виде любого из вариантов текстовых языков.
но не надо их об этом просить, пусть лучше сделают управлением экранами и сигналы от кнопок в программу, да сделают нормальные макро-экраны для вывода аварий, журнала событий, чтобы не городить все это в поле ФБД каждый раз (у меня обработка вывода и фиксации аварий занимает от 2/3 до 3/4 всех программ)
nickbeljaev
04.02.2020, 20:16
Коллеги вы просто возьмите каталог овен за 2010 и посмотрите на каталог 2019. Очень много приборов сняты с производства и эти же приборы выходят как модификация ПР200. И это будет только развиваться. Про LD и ST. Я первое реле держал в руках в 2000 году. Француз. Так там был выбор LD или FBD. ST рядом не было. Но были пара макросов для некоторых математических операций. Все. Самое интересно что если смотреть на макросы 2000 у француза и на макросы ПР200 всё почти один в один. Стой лишь разницей что некоторые макросы у француза уже тогда позволяли например работать с давление в резервуаре для контроля уровня. А у овен это появилось только сейчас. Но конструктора макросов который изначально был у овен у немца появился только в 7 версии лого.
И это правильно, чем меньше сортамент железа тем приятнее наша жизнь :)
nickbeljaev
04.02.2020, 20:21
В си есть свои плюсы и минусы, но как основа он неплох я не стараюсь ставить много скобок и в этом его прелесть. В нем нужно все разбивать на не большие блоки, от как раз и заточен под библиотечный тип. Есть у него и еще одна сторона он любит последовательность с сопровождением идеи самого программиста, другим уже будет трудно разобраться в чужих идеях и подходах, это многих и пугает и отпугивает, некий иммунитет защищает от легкого плагиата кода:).
"Плагиата кода" ? А вы сами то как программировать научились? Часом не посредством этого самого "плагиата"? :) На разборе кода "старших товарищей" держится процесс обучения программированию на любом языке, и наша с вами обязанность пред теми кто был до нас и будет после сделать его максимально читаемым, а не плодить "код с иммунитетом" который называется немного иначе (на букву г если чего).
nickbeljaev
04.02.2020, 20:31
а вы пробовали на ЛД там писать? это и ЛД то не назвать - так прилепух. основа всегда ФБД.
а что там нового может быть? ведь задачи для программируемых реле с годами не меняются, просто в россии все с большой задержкой реализуется.
с другой стороны такой развитой математики нет у забугорных аналогов ни у кого до сих пор, я уже не говорю о выводе на экран.
вы в лого 8 пробовали хоть что-то на экран вывести.... да это же ад и бред.
тем более, если очень хочется СТ, то тогда нужны подпрограммы, поскольку на нем, действительно булевые операции очень многоэтажные, особенно импульсные, в итоге, чтобы это было юзабельно, уже получается полноценная среда для ПЛК.
Как я и говорил ранее - ФБД это тот язык, который отделяет дешевые ПР от полноценных ПЛК вот уже десятки лет. и никто от этого уходить не будет.
самое идеальное, что могли бы сделать овеновцев, это отдельный блок, внутри которого можно писать математику не с помощью блоков, а в виде любого из вариантов текстовых языков.
но не надо их об этом просить, пусть лучше сделают управлением экранами и сигналы от кнопок в программу, да сделают нормальные макро-экраны для вывода аварий, журнала событий, чтобы не городить все это в поле ФБД каждый раз (у меня обработка вывода и фиксации аварий занимает от 2/3 до 3/4 всех программ)
Я начинал с реле у которых был только ЛД - считаю что это рудиментарный язык полностью заменяемый ФБД. Одно из его достоинств, то что он очень легко перекладывался в асм, то есть вот у него компилятор был действительно простой, но это точно вчерашний день - переписать любую лестницу в ФБД дело одного вечера, я бы не посоветовал тратить на него ресурсы, лучше микросекундный таймер дайте, сами же отрезаете себе кучу применений.
На счет математики, тут поле очень скользкое - стандартный путь бортовой автоматики упрощать все до полиномиальных функций на инструментальных системах (типа той же Octave), а в целевые вычислители помещать только полиномы с лимитами, в противном случае код очень сложно верифицировать на безопасность, а для многих применений это нужно. Для полиномов ФБД хватает вполне.
stanislau
04.02.2020, 21:58
Не надо ни какого LD. На нем азиаты специлизируются:). Пусть концентрируются на чем-то одном. Продукт получился у ОВЕНа на самом деле очень достойный. Но вот есть мелкие "подглючивания" в OL. Тут на форуме на них часто указывают. Лучше удовлетворить пожелания пользователей, чем гнаться за двумя зайцами:D.
PS Или лучше энергонезависимой памяти добавить, чтоб пользователь меньше старался экономить:).
nickbeljaev вы один из не многих в ветке про ПР, кто вообще знает что такое верификация и сталкивались с этим процессом.
Основным преимуществом лд для себя я считаю возможность удобной работы с импульсными командами(например по импульсу записать в переменную нужную константу и не думать как потом ее сохранить. Никаких мультиплексоров не нужно и обратных связей.), а так же возможность записывать данные в один и тот же регистр из разных мест в удобном виде
nickbeljaev
06.02.2020, 04:18
Если по Вашему целой команде программистов адски сложно сделать компилятор с ФБД, то что Вы скажете про FLProg - ФДБ программирование для Ардуино? https://flprog.ru/
Разработал его ВСЕГО ОДИН ЧЕЛОВЕК - Сергей Глушенко https://www.youtube.com/channel/UCI0qdIuuNMOdIoAA-5623rQ/videos?disable_polymer=1
А первый на планете компилятор Си разработали 2 человека, а первое ядро Линукса один человек - количество авторов ничего не говорит о сложности задачи. Есть языки близкие к машинному коду, в которых операции и порядок их выполнения подобны порядку выполнения машинных команд, например асм такой, ЛД такой, Си практически такой кроме вызова функций, а ФБД совсем не такой, у него вообще порядок выполнения задом наперед - редукция выражений должна происходить от выхода ко входу (не буду утверждать что все реализации именно такие, но теория говорит именно так), ну и пресловутые циклические связи - требуют плясок с бубном и всяких неочевидных реализаций, поэтому я считаю компилятор с ФБД весьма сложным.
в которых операции и порядок их выполнения подобны порядку выполнения машинных команд, например асм такой, ЛД такой, Си практически такой кроме вызова функций, а ФБД совсем не такой
Выс подводит терминологическая показуха того что Вы в теме, второй пост подряд путаете язык похожий на асм. Перечитайте здесь (https://ru.wikipedia.org/wiki/Ladder_Diagram) и здесь (https://ru.wikipedia.org/wiki/Instruction_List)
Powered by vBulletin® Version 4.2.3 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot