Коллеги! Сделайте для начала хотя бы то, что уже реализовано в оффлайн симуляторе. Пусть все будет то же самое, но онлайн. Есть какие-то сроки по данному решению?
Вид для печати
Коллеги! Сделайте для начала хотя бы то, что уже реализовано в оффлайн симуляторе. Пусть все будет то же самое, но онлайн. Есть какие-то сроки по данному решению?
Мы работаем. Но не менее 6-9 месяцев.
Требования/пожелания ещё собираются?
Тогда предлагаю такое:
[*] Возможность работать с online режимом через API (т.е. запуск, останов, чтение/запись значений)
Тогда можно бы проще тестировать проекты. Как известно, народ и физические движки прикручивает для моделирования разнообразных проектов.
Не понятно....Цитата:
Сообщение от Владимир Ситников
А я думал ,что только мне не понятно :DЦитата:
Сообщение от Ельцов Андрей
Не понятно что именно?Цитата:
Сообщение от Ельцов Андрей
https://ru.wikipedia.org/wiki/API : API -- программный интерфейс приложения
В online режиме (как, впрочем, и в симуляции) нужна возможность программно управлять ходом online режима.
Иными словами, программно (из внешних программ) читать значения online переменных, программно выполнять force write, программно подавать команду на перезапуск программы, программно подавать команду на заливку owl файла в ПР, и так далее.
Вот, у OwenCloud есть API: https://api.owencloud.ru/
Подобное нужно и для ОЛ.
Это по-прежнему непонятно?
Тут дело не в том ,что не понятно было что вы хотели ,но и для чего это важно и нужно .Например,когда идет заливка программы ,то об онлайн отладки или симуляции говорить не приходится ...Поставьте тайм вьюжер и управляйте с удаленного рабочего стала ОЛ ,его режимами ,рисуйте схемы...запускайте отладчики...Или я опять не понял :confused:
В этом-то и проблема, что "запуск", "перезапуск" и т.п. приходится прощёлкивать ручками.Цитата:
Сообщение от rovki
Проверять и тестировать схемы гораздо удобнее, если можно автоматизировать управление ПР.
Не вручную щёлкать по менюшкам, а программно управлять.
Ну это пока фантастика ,что бы программа сама записывала (а может и составляла ;)) проект в ПР , управляла режимами ОЛ.
Для проверки схемы и оффлайн отладчика хватает ,а вот проверки системы в режиме онлайн ,то другое дело (реальное время).
Вы хотите:Цитата:
Сообщение от Владимир Ситников
1. залить программу в ПР
2. не отключая ПР от компа, запустить симулятор в ложике, выбрать в нем режим онлайн-отладка
3. тыкая на входы/переменные видеть как подключенный прибор с механизмми взаимодействует
??
Я бы брал большие деньги за такие функции)))
А можете привести пример аналогичного функционала для ПЛК с кодесис?
В CoDeSys 2 есть режим "batch mode": http://plc24.ru/komandnyj-fajl-cmdfile-codesys-chast-1/Цитата:
Сообщение от i.go
В CoDeSys 3.5 можно на Python скрипты писать: https://help.codesys.com/api-content...ython_scripts/
Для большинства задач, решаемых на ПР, достаточно иметь возможность просмотра необходимых переменных на ПК в виде таблицы, с возможностью пошагового выполнения программы в приборе, и возможность поставить точку останова. Для каких алгоритмов необходимо все остальное, даже не представляю.
Тут могут быть как минимум 2 варианта:Цитата:
Сообщение от Ревака Юрий
1) Фирма ОВЕН специально не хочет улучшать ПР. Например, чтобы не получилось, что "все клиенты пересели на ПР, и ПЛК покупать перестали".
2) Проблема "ПР и яйца". Иными словами, сейчас часть возможностей в ПР хромает, поэтому никто и не начинает использовать ПР в более интересных задачах. Возможность управлять работой системы ОЛ-ПР из внешних инструментов упростит ряд тестирований сделает возможным решение новых задач.
Смотря что тут понимается под "точками останова" и/или "пошагового выполнения".Цитата:
Сообщение от Ревака Юрий
Например, "выполнить 10 шагов, и потом остановиться" подразумевается? Или же нужно будет 10 раз мышкой щёлкать?
"Выполнять в течение 1секунды, а потом остановиться" тоже подразумевается?
"Точка останова с условием того, что такая-то переменная равна такому-то значению" подразумевается?
С момента появления ПР, их и так улучшили, если вспомнить какие задачи на них планировалось закрывать в 2009 и сейчас. Естественно, что все улучшения должны быть в ценовом коридоре ПР, в том числе и отладка, иначе это будет ПЛК.:)Цитата:
Сообщение от Владимир Ситников
Мне кажется если будет сам механизм, то сделать это по таймеру/счетчику или кол-ву кликов мыши не составит труда. Я не владею пока информацией, по функционалу который разрабатывается.Цитата:
Сообщение от Владимир Ситников
Вообще говоря, взаимодействие ОЛ и внешних программ едва ли кардинально изменит ценник.Цитата:
Сообщение от Ревака Юрий
Команд в ОЛ автоматизации не так много: "открыть owl файл", "загрузить проект в ПР", "запустить схему", "поставить ПР на паузу", "сделать 1 шаг схемы", "получить значение переменной", "изменить значение переменной".
Наверняка я что-то забыл, но всё равно весь этот функционал тем или иным образом уже реализован в связке ОЛ-ПР.
Совершенно непонятно почему возможность внешней автоматизации как-то существенно поднимает ценник. Более того, наверняка в ОВЕН автоматизация УЖЕ сделана. Компания же как-то тестирует изделия? Кстати, возможно ОВЕНу есть что рассказать (например, на конференции https://heisenbug-piter.ru/ , 17-18 мая )
Иными словами, если есть кнопка в интерфейсе (запуск симуляции), то добавить вызов этой функции из внешней программы не будет составлять труда.
Не составит труда это как? Из внешней программы, которая будет щёлкать в нужные координаты ОЛ 10 раз с интервалом в 10 секунд?Цитата:
Сообщение от Ревака Юрий
Разница между "щёлкать мышкой по координатам" и использовать команду "ol.next_step" колоссальная. Координаты могут измениться с выходом новой версии ОЛ, с обновлением Windows и так далее.
Какой то космос ...,половину даже не понял (наверное тупой) .Крайности они всегда чреваты ....Отладчик должен помочь не опытному пользователю отладить алгоритм на обьекте ,а не отправлять его еще изучать 500стр описания возможностей отладчика ...который будет позволять пользователю удаленно загружать ,записывать ,отлаживать ...и еще 100 опций , из другой программы .Программа на программе и программой погоняет :D - чур меня....Явный перебор!
По первой ссылке - Вложение 40200Цитата:
Сообщение от Владимир Ситников
По второй любопытно конечно. Но надо рядом иметь комп и круг сценариев не очень широк. Вот что комп заменит? Вачдог? Так ПР не настолько сложные приборы, чтоб зависать...
Так я и не предлагаю эту технологию использовать вместо основного мозга системы.Цитата:
Сообщение от i.go
Тут смысл в том, что подобная автоматизация может упростить тестирование.
Например, можно сделать тест, который выведет ПР "на режим":
1) Запускаем программу
2) Через 15 минут эмулируем воздействие (иными словами, через python или подобный скрипт заставляем ПР думать, что на входе появился сигнал)
3) Ещё через 5 минут скрипт проверяет какие выходы получились у ПР.
При этом получается, что:
А) Можно тестировать в более приближенных к реалиям условиях (часть датчиков и выходных сигналов можно не подключать, а часть можно и подключить)
Б) Можно тестировать на длительных интервалах времени. Зарядили -- и иногда присматриваем. Для ряда случаев шанс ошибки сильно сокращается.
В) Есть воспроизводимость результатов. Иными словами, если поправили схему, то "все прошлые" тесты можно просто запустить и убедиться, что ничего не сломалось.
И тому подобное.
Да, сайт plc24.ru, похоже, протух, но в CoDeSys 2.3 реально слабый функционал по скриптам: https://stackoverflow.com/questions/...-in-batch-mode Например, чтения-записи переменных нет.
Да этого ни чего не надо ,проще проверить алгорит в оффлайн ,а потом в онлайн .Тут дело не в том сколько работает ПР(5 минут или час) ,а в том что бы проверить поведение системы (алгоритма) при разных комбинациях дискретных входов и разных значениях аналоговых сигналов , а для ПИД регуляторов и аналоговых выходов проверить качество настройки (регулирования) ,для этого достаточно "самописца аналогового" (график) .А все остальное от Большого Ума.;) и тем у кого его меньше сильно усложнит жизнь.
Для любого электронщика для отладки достаточно осциллографа,потому и предлагал видео регистратор ,с возможностью видеть и записывать сигнал из любой точки схемы ,причем по 1,2,4 каналам через специальные переменные или сетевые .
такое ощущение, что люди никогда не работали с типовой отладкой по JTAG или тем же CoDeSys
Какие 10 шагов сделать и остановится?
Ещё онлайн-трассировку аппаратную попросите в устройстве за 3 копейки.
Ещё и скрипты.
Скрипты это вообще юнит-тестирование. Никакого отношения к отладке.
Мы тестируем ПР на внешнем, аппаратном стенде, не совсем дешёвом. Потому, что надо тестировать всё устройство, а не алгоритм. Алгоритм будет идеальным, но реальное быстродействие, задержки по i/O и т.п. сделают его нерабочим в принципе.
Тов. Ситников, не смущайте умы!
Ну прям Proteus :)Цитата:
Сообщение от rovki
Собственно этого и достаточно для отладки любой программы, "возможностью видеть и записывать сигнал из любой точки схемы ,причем по 1,2,4 каналам через специальные переменные или сетевые", сейчас это делается выводом ключевых точек на экран, если процесс длительный то график, логи.Цитата:
Сообщение от Aviator_VZh
Дело не в длительности процесса , а в том что смотреть на цифры и понять есть ли перегулирование и какой у него период не возможно ,даже для быстрых процессов. Для биотовых переменных важно не только знать ноль там или единица ,а то как они расположены во времени отнносительно друг друга итд.Цитата:
Сообщение от Ревака Юрий
Для отладки сложных цифровых систем мне хватало 2 канального осциллографа и ловушки импульсов (со счетчиком двоичным и 8 светодиодов) ...
Если ещё актуально, то неплохо было бы видеть обмен по портам RS-485. Я полагаю, что увидим много интересного ;) Особенно когда переменная постоянно отправляется по изменению значения. Значение не меняется, а отправка идёт(присвоение повторное старого значения считается изменением значения). И не все приборы выдерживают такой натиск.
Такая возможность сильно облегчит работу по RS-485.
Если установлен параметр запись по изменению, то постоянное отправление может быть из-за использования формата float, а вообще в настройках modbus есть много чего для управления обменом. Я подробно разобрал все в трех видео:Цитата:
Сообщение от Алексей_
Modbus и OwenLogic ч.1 https://www.youtube.com/watch?v=k9rUF5_kLqk
Modbus и OwenLogic ч.2 https://youtu.be/miTsntqGIQA
Modbus и OwenLogic ч.3 https://youtu.be/kOo4INKt8Nw
В описании есть таймкоды, можно сразу перейти к конкретному вопросу.
Спасибо, просмотрел видео. Нашёл даже кое-что мне неведомое :)
Ошибка 03 — значение в поле данных запроса, является недопустимой величиной, возникает(насколько я понимаю, но сам не сталкивался) если устройство проверяет значение на соответствие каким-либо условиям. Типа контроллер температуры, с допустимым диапазоном от 0 до 70 градусов, а приходит значение в 1000. Тогда в принципе и должна прийти ошибка 3. Интересно, ТРМы отвечают так на выход за пределы диапазона или нет?? При случае проверю :)
Мне известна только одна проблема c обменом по RS-485 на ПР-200, с которой я столкнулся:
Когда происходит повторное присвоение значения переменной, но значение переменной не меняется, почему-то исполнительная система ПР-200 считает, что переменная поменялась и отправляет ещё и ещё ... Причём приборы овеновские переносят это легко, а вот стороннее оборудование начинает глючить :(
Борюсь с этим, отключив вывод по изменению, только по стробированию переменной. :( А жаль, вещь очень уж удобная... В теории можно задержку увеличить... Но хочется иметь максимальную производительность канала :)
Возможно в текущей версии это и поправили . Но писать далее буду вывод по модбасу через стробирование, так как это точно работает и ничего лишнего в канале нет.
Теперь бы разобраться бы с вставкой функций ST :)
Такое может быть для переменных в формате float, для других форматов если значение по изменению такого быть не должно, а с float Вы на экране можете видеть 20, но на самом деле там серия чисел, например 20,0001 20,0005 и.т.д с точки зрения математики числа разные и они изменяются, я подозреваю что проблема в этом.Цитата:
Сообщение от Алексей_
Я сам так думал, что должно, но по факту :(
Долго въезжал и разбирался ...
Даже осциллограф использовал :)
Но потом оказалось, что с АС-4 подключенный к компьютеру с программой COMPump вполне все пересылки перехватывает и потом лог можно просмотреть и понять, что и когда творится.
Кстати, переменные с плавающей запятой при хранении не должны меняться. Это если значение переменной берётся из вне ...
А так в программе всё очень просто... Реверс шаговика...
Вложение 58193
Но когда без строба, по изменению - всё завалено повторяющимися одинаковыми посылками. Если бы переменная менялась, то посылки были бы разными. Со стробированием всё замечательно, ничего лишнего :)
Конечно это может быть особенность конкретной версии OWEN Logic, но ...
Я уже обновил версию.