соглашусь. Очень не удобно ставить много "и или" или делать макрос. В кодесис это вот реализованно.Цитата:
Сообщение от gmz_001
Вид для печати
соглашусь. Очень не удобно ставить много "и или" или делать макрос. В кодесис это вот реализованно.Цитата:
Сообщение от gmz_001
Хотелось бы увидеть подпрограммы, которые можно будет запускать по событию, это должно ускорить работы контроллера.
А у вас реально проблемы со скоростью работы контроллера? Оно же летает.Цитата:
Сообщение от Goodwin2
При загрузке пр200 на 50% и выше, появляется заметная задержка при работе с RS-485, на работу не влияет, но почему бы не увеличить производительность контроллера с помощью подпрограмм? Из-за отсутствия оператора MOV приходится использовать оператор SEL, а он по моей логике перезаписывает переменную каждый цикл тем самым нагружая контроллер.
Если проблем нет, то нет смысла и менять. Доработки о которых говорите непонятно зачем нужны (сейчас у всех работает), а на их реализацию, тестирование и документирование потребуется время разработчиков ОЛ.Цитата:
Сообщение от Goodwin2
Касательно mov. Вот вы пишете, что сейчас sel выполняется на каждом цикле. Так и с mov будет та же история: сначала нужно проверить условие, а потом переместить данные. Проверку на каждом цикле всё равно никто не отменял.
Я предложил добавление подпрограмм для повышения производительность контроллера, а в качестве примера я привел оператор SEL который не совсем грамотно использует ресурсы контроллера. Это не проблема, это доработка/улучшение.
Оператор SEL каждый цикл записывает переменную, независимо от условия, а оператор MOV же должен записывать переменную только при наличие условия.
Вы меня не понимаете. Вот вы же сами пишете "только при наличие условия". Кто условие проверять будет? Пушкин? Это самое условие контроллеру всё равно придётся проверять.Цитата:
Сообщение от Goodwin2
Для обработки оператора SEL контроллеру нужно сделать следующие действия:
1) Перейти к шагу 4, если значение на 1-ом входе является TRUE
2) Записать значение 2-го входа в результат
3) Перейти к шагу 5
4) Записать значение 3-го входа в результат
5) ...очередное действие
Если на 1-ом входе блока SEL находится TRUE, то потребуется 2 действия: 1, 4
Если же там FALSE, то потребуется 3 действия: 1, 2, 3
Теперь в случае с MOV:
1) Перейти к шагу 3, если значение входа EN равно FALSE
2) Записать значение входа на выход
3) ...очередное действие
Если EN==FALSE, то требуется 1 действие: 1
Если же EN=TRUE, то 2 действия: 1, 2
В сухом остатке: да, оператор MOV может и быть чуть более эффективным, но никакого кардинального ускорения он не принесёт. Было 2-3 действия, стало 1-2.
А разрабатывать, отлаживать и документировать -- реальный расход времени и денег. Потом ещё и ошибки исправлять.
Ради чего вся оптимизация-то? Вы реально понимаете, что разница между SEL и MOV это пара инструкций контроллера и всё равно считаете, что ради этого имеет смысл затевать целый блок?
Ну вот, я имел ввиду, то что контроллеру необходимо выполнить больше инструкций при операторе SEL, чем при MOV.
У меня присутствует в программе около 150 вот таких вот блоков:
Вложение 37139
Блок используется для сброса переменной на заводское значение. Без этих блоков цикл выполняется, как пишет сама ПР200, за 10-14 мс,. С этими блоками цикл увеличивается до 22-26 мс. По моей логике контроллер работает в холостую из-за такого построения программы. Скорость цикла 26 мс тоже достаточно быстрая и удовлетворяет большинство потребностей, но появляются заметные задержки при работе с RS-485 в режиме SLAVE ПР200 при считывании переменных. В режиме мастер тоже должны быть задержки, но пока не довелось проверить.
Ввод подпрограммы или оператора MOV, увеличит скорость работы. Оптимизация радио увеличения скорости цикла, чем контроллер работает быстрее тем лучше.
Не путайте тёплое с мягким. Сначала говорили про SEL, а сейчас fSEL.Цитата:
Сообщение от Goodwin2
Это у вас встроенный блок fSEL? Или это макрос?
fSEL встроенный блок и их штук 10, не больше, скриншот я сделал в первом попавшемся месте.
Вложение 37141
Тогда, скорее, вопрос именно к производительности этого блока fSEL.Цитата:
Сообщение от Goodwin2
Судя по вашим данным, 150 блоков увеличивают цикл на 10мс, значит один блок вычисляется 10мс/150=66 микросекунд
Частота процессора ПР200 составляет 72МГц, и за 66 микросекунд процессор может выполнить 72*106 * 66*10-6 =~ 4700 операций.
Крайне и крайне много для такого блока. Если же сделать оператор fMOV, который будет занимать не 4700, а 4699 команд контроллера, то общее быстродействие вообще никак не изменится.
Поэтому тут 2 варианта:
1) Либо действительно 150 блоков fSEL занимают 10мс
2) Либо вы ошибаетесь (ну и там не только блоки fSEL, а ещё какие-то дополнительные операции или их не 150, а 15 тысяч)
Блоков SEL - 150, блоков fSEL - 10.
Я понимаю что блок SEL занимает примерно 3-5 тактов, пусть даже компилятор добавит ещё пару тактов. Время цикла я смотрю в сервисом меню ПР200, может ли быть там неверное число? Мне непонятна падение производительности. :\
Время цикла очень сильно зависит от правильности построения схемы.Цитата:
Сообщение от Goodwin2
А у вас кроме fSEL'ов в программе что-нибудь с этими переменными есть? Ну, какое-нибудь сложение, умножение?Цитата:
Сообщение от Goodwin2
1) Работа с плавающей точкой на ПР200 очень медленная (т.к. поддержки плавающей точки в железе нет, и работает за счёт эмуляции). Поэтому, если в программе используется fADD/fMUL и т.п. операции, то никакая оптимизация fSEL не спасёт.
2) Возможно, программисты ОЛ поленились добавлять fSEL в прошивку ПР, и реализовали fSEL(a,b,c) как a*c + (1-a)*b. Если действительно так, то это может объяснять почему fSEL тормозит. Но всё равно: у вас не только fSEL'ы же в программе?
Макросы для температурных датчиков есть, в них приличное количество арифметики для float. И разовые вычисления есть в самой программе, типа умножить float на 10 и перевести в int.
Не работает мастер тиражирования в Win10
Программа пишет, что обнаружено дополнение несовместимое с системой
После установки ни Win7 версии 1,10 таже ситуация
ДОПОЛНЕНИЕ НЕ СОВМЕСТИМО С СРЕДОЙ IDE
кАК ЭТО лечить
Вам требуется поставить в соответствие вашу версию OL с мастером тиражирования.
http://www.owen.ru/catalog/programmn...logic/72837766
Здравствуйте!
Предложение не глобально, но думаю всем понравится: хотя бы в таких блока как AND, ADD и еще в нескольких, добавьте пожалуйста возможность устанавливать дополнительные входа на эти блоки, в целях экономии места и удобства восприятия. А то когда боле 4 переменных собираешь (например в AND) получается арифметическая многоножка)).
Может где и было такое предложение, не увидел.
Ещё в 2012 году предлагал.Цитата:
Сообщение от Yaroslav_22
соглашусь с предыдущими комментаторами. Это было бы очень удобноЦитата:
Сообщение от Василий Кашуба
Добрый день.Цитата:
Сообщение от Yaroslav_22
В планах такое есть, спасибо :)
Но не в ближайших релизах пока что.
Пока же можно создавать макросы.
Понимаю, не так удобно, но как одно из решений.
мне кажется это нужно ставить как первоочередное изменение. Под каждое решение писать отдельный макрос не удобно... где-то мне нужно 4-и а где то 6-иЦитата:
Сообщение от Андрей Посохов
Добрый день. Как производитель оборудования столкнулся с необходимостью делать паспорт издели и инструкцию по эксплуатации. Если с паспортом все просто и понятно то по инструкции возникли большие затруднения. Рисовать дерево переходов и сами экраны это ещё то занятие. Может как то это упростим. Предлогаю "научить"ОЛ делать распечатку дерева переходов и отдельно экранов. Будет идеально если ОЛ сможет переводить это в PDF и сохронять ка отдельный документ. То же самое сделать и с листингом "схемы". Я закончил проект. У меня в папке проекта три документ. 1)прошивка. 2)схема прошивки. 3)экраны.
PS модератоы закрепите тему на первой странице а то заталкали уже на 5ю.
Я делал через PrintScreen, далее вставляем в Paint, обрезаем, сохраняем и вставляем в Word картинку.Цитата:
Сообщение от игорь68
Предлагаю следующие доработки:
1. Очень бы хотелось упростить работу с сетевыми переменными примерно как с энергонезависимыми - в таблице с переменными добавить колонку "сетевые" и расставлять галочки и указывать адрес.
2. Хотелось бы добавить экран аварий, всплывающий поверх всех экранов при изменении переменной (переменных), а не так что бы создавать экран и городить на него кучу переходов с каждого экрана.
3. Хотелось бы перемещать входы выходы на поляне не только вверх и вниз, не понимаю почему они должны быть привязаны к краю поляны.
4.Хотелось бы видеть названия входов/выходов макроса при его редактировании. Да и входы/выхода устройства тоже хотелось бы называть и видеть, пусть выводится второй строкой например (в первой всё так же I1 или Q1). Там конечно есть комментарий, но его видно только при наведении указателя мыши.
5. Почему не сделать работу с экранами как в ИП320? По моему было много лучше.
Ну и вопрос:
1. В последних версиях появились группы экранов, но добавить группу нельзя. Что это и для чего нужно?
Stesel вопрос по пункту 2. Как выпредставляете себе настройку ваших аварий. Что и где я должен настроить. Через что и как связывать с работой программы. Сейчас это изменение состояния входа. И те переменные которые привязанны к этим входам. Лично мне не понятно.
Так же, как во всех панелях оператора. Если в указанный для экрана аварий диапазон булевых переменных хотя бы одна активной становится, то переход к этому экрану. И отображение только активных аварий. Чтобы не городить кучу сортировок и копирования комбобоксов. В пределах самой пр. Аварийность булевых переменных можно через чекбокс устанавливать как и энергонезависимость
То есть нужно булевые переменные сначала собрать в маску а потом читать бит маски. И если бита нет(или есть) то авария. С выводом на экран. Но как быть с авариями те что с само сбросом. ?
Это уже вопрос как это организуют программисты. Я считаю, что архив аварий особо не нужен в сферах применения ПР. Достаточно просто при отсутствии аварий возвращаться на главный экран. А вот как реализовать сброс - это уже задача того, кто пишет ПО. Например я делаю (не только в ОЛ) отдельные аварийные переменные, которые импульсно возводятся аварийной ситуацией, а потом кнопкой сброса сначала снимается звук, а следующим нажатием сбрасываются отображенные аварии.
А если кому-то всё-таки нужен архив аварий, то здесь его уже реализовывали. Но это не основной функционал, который надо срочно штатно реализовывать в отличии от экрана аварий.
П.с. для упрощения этого экрана текст аварии можно брать из комментария к переменной. Тогда не надо придумывать, где писать текст подписи аварии и придумывать новые меню.
Дело в том что программируемые реле используются в более широком диапазоне .
И в большинстве там где не нужно контролировать нештатные ситуации (Аварии).
И вряд ли программисты прислушаются к таким узконаправленным пожеланиям .
Мне так кажется :)
тут как раз ситуация именно в широком распространении. поскольку в 90% решений, я так думаю, где необходимо программируемое реле, там необходимо так или иначе контролировать аварии. потому очень не хватает этого функционала. я вот например сейчас часто стал использовать ПР в малых проектах. так вот 6 реализаций, 6 раз пришлось делать отображение аварий. 6/6 это уже статистика. мне кажется, если все на форуме попросят, то может и сделают. тем более, как мне кажется это не сильно сложно. а если придумывать оправдание, то программисты и рады будут ничего не делать.
.
Скажу больше. Первопричина создания подобных реле это отказ от громоздких шкафов автоматики для тех целей где не нужен оператор. Насосные. Ворота. Рекламные банеры. И прочие. Пример: Реле от немцев стоит в ветрогенераторах этой же фирмы и контролирует работу шкафа АВР собственных нужд. Плюс передает в скаду кое какую телеметрию.
Вариант работы аварий от Вас тоже не самый простой. Овен сдела оптимальные инструменты для работы с экраном. Ps серия ПР200 это не только для индикации аварий но в основном для возможнлсти поменять какие то уставки. И эти инструменты ОЛ справляются с этим на 100%. А авария это как приятный бонус.
Вот Вы пишите о ПР200, но это же противоречит здравому смыслу, пока нет ПР200 щитового исполнения, ПР200 не может быть предметом обсуждения! Согласитесь не логично звучит: есть обсуждение, предмета обсуждения нет! Вот если бы написали ИПП120, я бы мог понять! А пока, как телега впереди лошади, применительно к ПР200, ну это я так думаю!
А разницы то между пр200 и ипп никакой. Я подразумеваю, что этот функционал сделают и там и там, если сделают. Кстати для Сименс лого в продаже есть специальные адаптеры для монтажа на переднюю панель.
Если пользовали ИП320, то там как раз именно так. Ну а если словами, то экран аварий всплывает поверх всех экранов по изменению одной из переменных.Цитата:
Сообщение от игорь68
По этому вопросу, уже предложено несколько разных вариантов, проверяйте, пользуйтесь.https://www.owen.ru/forum/showthread.php?t=31113&page=2Цитата:
Сообщение от stesel
Работа с экраном в ОЛ полный швах...
1. нет опроса кнопок и возможности их использовать
2. даже тот функционал переходов хромает - короткое нажатие и удержание. Короткое ДОЛЖНО работать по заднему фронту, удержание по ПЕРЕДНЕМУ ессно с паузой и блокировкой короткого нажатия. Попробуйте с одного экрана сделать переход и по короткому и по удержанию и поймете
3. Нужны подменю в организации экранов. Не могу красиво объяснить, но это несколько отличается от простых переходов с экрана на экран... То есть возможность подменю должно быть по умолчанию в самом ОЛ, без лишних наворотов с переходами и привязыванием переменных и так далее. То есть просто указываем на строку текста и ставим галочку (подменю), автоматом создается экран, выход всегда на пункт вызова а не куда-то там в никуда...
з.ы. из-за отсутствия опроса клавиш и корректной работы коротких и длинных нажатий я свой журнал аварий доделать не могу :) вечно упираюсь в отсутствующие возможности и необходимость лепить грабли...
Цитата Сообщение от Ревака Юрий Посмотреть сообщение
Разница в том, что если переменная в логике никуда не "привязана", вся эта часть логики в расчетах не участвует, и соответственно не моделируется, установка энерго-сти "фича" которая позволяет это обойти.
Программисты ОЛ стремятся довести OWEN Logic до совершенства ( чтобы можно было создавать
легко большие проекты). Разве сложно им распространить ФИЧУ и на энерго зависимые переменные .
Допустим всегда ОЛ запускается с установленной галочкой на проверку всех переменных энерго зависимых
и энерго независимых на обязательную запись в них и "на не привязку". А пользователь Сам если нужно снимает её
если ему это необходимо.
Это пожелание . Работать (симулировать ) с переменными как с входами- выходами . Симулировать макрос который размещен на двух (трех страницах экрана ) проблематично .
Приходится ставить галочки энергонезависимости ,потом помнить , затем снимать .
Я Вас услышал, просто хочу еще раз уточнить, если проблема в законченном макросе, которые необходимо проверить, то проще открыть его на редактирование и отработать внутри, не делая привязки к физическим входам выходам, а после уже можно в общей схеме проверить, когда вх/вых и все другие каналы будут назначены, а не висеть в воздухе.Цитата:
Сообщение от Алексеев
Пример во вложении, что бы проверить макрос, я не буду ничего устанавливать и соединять или выводить на вх/вых, просто открою макрос на редактирование и запущу симуляцию.
Я так и делаю с макросами (с каждым).Цитата:
Сообщение от Ревака Юрий
Но требуется в конце проверить всю схему то есть проверить макрос в схеме . И перенести его с переменными в существующий рабочий проект со структурой экранов .
Тем более хочу структуру экранов и руководство пользователя с корректировкой ( с их дизайном ,паролями ) сохранить .
Проект будет примерно таким .
Самое главное программисты оставили ФИЧУ не спроста . Это удобная фича . А если распространить её ????????
Я натолкнулся на неё случайно . Программистам это не составит труда .
А проверка должна быть на всех переменных и всегда и по умолчанию . А пользователь может её убирать на каждый сеанс работы в OWEN Logic .