Можно ли в Codesys сэмулировать работу датчика

[antoshkin3267g]

Здравствуйте,знаю что в Codesys можно сэмулировать работу контроллера,а можно ли сэмулировать работу датчика?возможно в других подобных программах есть такая функция,буду рад,если кто-нибудь подскажет

[petr2off]

Если общение с датчиком идет по Modbus, то я применял такой прием. Есть такая софтина - бесплатная между прочим - Эмулятор Modbus TCP сервера. Где то на форуме есть на нее ссылка. Ее вполне можно использовать для таких целей.
Создаешь набор регистров датчика, пишешь скрипт - который моделирует изменение значений регистров согласно логике тестирования, ну а софт контроллера работает с этими регистрам и обрабатывает входящие значения м выдает выходящие.
Правда я чаще скадовские программы таким образом отлаживал.

[Jackson]

Здравствуйте,знаю что в Codesys можно сэмулировать работу контроллера,а можно ли сэмулировать работу датчика?возможно в других подобных программах есть такая функция,буду рад,если кто-нибудь подскажет

Можно. Но готовых функций нет. Мат.модель надо тоже писать самому, что вообще бессмысленно. Проще взять калибратор для аналоговых входов, тумблер для дискретных и имитаторы интерфейсов на других компах (ModSlave, ModSim и т.п. например для ModBUS). Если нет готового калибратора, то он мастрячится из блока питания и потенциометра за 15 минут.

[Velt]

а можно ли сэмулировать работу датчика?

Если достаточно грубой эмуляции, то, как вариант, можно форсить значение соответствующей переменной в онлайне

[petr2off]

Эмуляция процесс не всегда простой, понятное дело - если это какой нибуть датчик давления или темературы - то да загнал нужное значение и в общем то все.
Причем, я разделяю эмуляцию от проверки работоспособности каналов. Тут только калибратор, перемычки, тумблер. Потому как нужно убедится, что пришедший сигнал будет обрабатыватся.
А вот скажем возмем задвижку простую и попробуем проэмулировать ее работу.
1 Выставили команду открыть.
2 через какое то достаточно короткое время должен снятся сигнал с концевика закрыто
3 Через какое то более продолжительное врнмя должен появится сигнал с другого концевка - открыто.
А еще после этапа 2 какое нибуть давление должно возрасти или упасть.
Т.е. по определенной временной диаграмме должны измениться 3 сигнала.
Это я еще не беру вовнимания всякие сервисные сигналы - типа отсутствия питания на приводе, или скажем блокировка какая нибуть по уровню.

Т.е. взаимосвязь сигналов это отнють не редкое явление. И как правило логика работы построена на анализе совокупности нескольких параметров.

[Jackson]

А вот скажем возмем задвижку простую и попробуем проэмулировать ее работу.

И задаём краеугольный вопрос: зачем?

Либо садимся и создаём мат.модель объекта - это отдельная серьезная работа за отдельные серьезные деньги и в отдельные сроки. Либо берём в руки калибраторы, тумблеры и лампочки и довольствуемся этим. А тайминги вот этим всем и эмулируем: щёлкаем тумблерами, крутим ручку калибратора.

Я знаю контроллеры со встроенной мат.моделью объекта. Они хороших денег стОят. И они для объектов которые не хухры-мухры, а надо быть уверенным во всём. Поэтому и стОят. Но эти деньги того стОят, потому что затраченное на это всё время и ресурсы стОили бы значительно дороже. Для некоторых объектов нормами предусмотрено и создание натурного макета с точной мат.моделью, но это те объекты где ошибка будет стОить очень дорого и выражаться эта стоимость будет отнють не в деньгах. Отдельно взятая задвижка - явно не тот объект.

Отправлено спустя 32 минуты 15 секунд:
Сделать можно абсолютно всё. Нет ничего невозможного. Вопрос цены и ресурсов.

[muZZy]

можно ли сэмулировать работу датчика?

Интересно узнать, что вкладывает ТС в понятие "сэмулировать"?

[petr2off]

И задаём краеугольный вопрос: зачем?

Например для отладки софта контроллера.
Из практики - есть штука такая - Агрегет фильтрации топлива. У него штук 40 регистров модбас, но ко мне в офис эту хрень никто не притащит, а торчать в поле, где и интернета то нет для отладки вариант так себе. И интерфейс у него модбус, не привинтишь тумблеры и калибраторы. А так собрал простенький эмулятор, и отлаживаешь работу контроллера в весьма высоком приближении к объекту.

[Jackson]

Из практики - есть штука такая - Агрегет фильтрации топлива. У него штук 40 регистров модбас, но ко мне в офис эту хрень никто не притащит, а торчать в поле, где и интернета то нет для отладки вариант так себе. И интерфейс у него модбус

И какие проблемы? Из практики: эмулятором ModBUS Slave эмулируете всё-таки Модбас и в контроллере пишете Модбас. Когда всё отлажено - меняете протокол. Данные после опроса должны попадать в нужные регистры независимо от протокола, тогда весь алгоритм от протокола вообще не зависит. Да, лишняя операция перезаписи, но зато отладка возможна. Только с обменом данных придется посидеть на объекте, если что-то пойдёт не так. А алгоритм уже готов и отлажен.

Не, я-то чего. Если время есть лишнее навалом и задаром - можно написать эмулятор контроллера с мат.моделью. Никто ж не запрещает. На свете вообще мало невозможного.

Отправлено спустя 11 минут 54 секунды:

простенький эмулятор

в весьма высоком приближении к объекту

Что такое "Оксюморон" - знаете? Второе значение - "парадокс". Вы только что привели наглядный пример.
Как в детской загадке про холодильник, бегемота и слона.

Отправлено спустя 8 минут 34 секунды:
Кстати, где-то это уже обсуждалось, в МатЛабе человек делал модель объекта, а потом выдавал результаты моделирования по интерфейсу - как раз для эмуляции работы. Да мы и сами с коллегами эмулировали двигатель внутреннего сгорания, выдавая параметры по CAN J1939. Прекрасно работало, контроллер был уверен что он ДЭСкой управляет.

[petr2off]

Эмулятор контроллера писать я не призывал. В контроллере пишется программаи управления объектьом. А сам объект эмулируется Modbus сервером. И даже протоколы в поле переписывать не надо. Обмен идет с теми же регистрами Модбас. И да, я не говорил, что это проблема - я говорил что это один из возможных инструментов, полезных весьма.

[keysansa]

Для себя всегда использую такой метод (удаленный/локальный ввод/вывод - не важно), который является модернизированным для PLC методом тестирования DUnit:
Переменная, обрабатывающая вход получает значение от функции, которая получает минимум 3 аргумента - реальное значение, признак симуляции, признак имитировать ли выходы за границы/ошибки в работе.
1. При отсутствии признака симуляции - на выход передается реальное значение.
2. При наличии признака симуляции, функция возвращает значение, сформированное из других аргументов (для клапана, например, это сигнал выхода активирования).
2а. При наличии признака имитации аварии, при каждой активации выходного воздействия, генерируется следующее аварийное состояние, для исполнительного устройства.

Отправлено спустя 10 минут 4 секунды:

И задаём краеугольный вопрос: зачем?

По мне - это не краеугольный вопрос, а основной. Написание логики программы занимает около 10-20% времени. Остальное - это обработка исключительных ситуаций и самодиагностика. Когда устройство замирает и не выдает никаких диагностических сообщений - плохо. Когда устройство не выполняет безопасных блокировок - так же плохо.

Отправлено спустя 8 минут 47 секунд:

Что такое "Оксюморон" - знаете? Второе значение - "парадокс". Вы только что привели наглядный пример.

Это не оксюморон - нам не надо имитировать действие устройства, нам надо имитировать лишь его нормальную работу и все предполагаемые отказы. При наследовании устройств - все это гораздо меньше времени занимает.
Например. Еще в 2000 году, на моей первой работе, мы сформировали требования к "двухпозиционному устройству". Это клапан, пускатель и прочее, имеющее 2 состояния, например "Вкл" и "Выкл", с одним сигналом контроля состояния.
Далее, добавили второй сигнал контроля состояния (обычно это заслонка, открыта/закрыта). Прописали все возможные рабочие состояния и отказы уже этого устройства.
Уже из этих двух устройств вполне можно собрать достаточно сложные конвейерные или пересыпные устройства, у которых КАЖДЫЙ отказ КАЖДОГО устройства учтен и проверена реакция системы на эти отказы.

Далее, уже на другой работе, сделал функции для теста аналоговых входов (нагревателей, тензодатчиков).

ЗЫ. Дополнительный бонус - всегда готова программа для обучения персонала, отвязанная от установки. Устанавливаем среду на ПК и запускаем симуляцию без формирования аварий и обучаем операторов.

[Jackson]

Это не оксюморон - нам не надо имитировать действие устройства, нам надо имитировать лишь его нормальную работу и все

А кто такие "мы"? И почему это всё "нам" не надо?
Это к автору уже.

В имитации нормальных режимов мало смысла - и так понятно как оно будет работать когда всё нормально. Сами же пишете, что львиная доля времени - обработка исключений и отклонений от нормы, вот с целью как раз их обработки люди и создают модели, имитаторы и даже натурные физические модели (я лично делал, а видел и ещё более масштабные, с целые здания). Потому что нормальное состояние всего одно, а ненормальных - сотни, где-то тысячи, и в каждом из них алгоритм должен отработать. И по-нормальному проверяется каждое из этих сотен и тысяч, шаг за шагом.
Так проходят нормальные испытания, медленно и муторно, но зато потом контроллер или система уезжает на объект и там уже об этом голова точно не болит.

А иначе это всё не имеет никакого смысла. Иначе на объекте по закону Мерфи возникнет именно та нештатная ситуация, которая не была проверена, и значит вся работа по проверке была впустую (а деньги и ресурсы на неё сожраны).

[+]

И получается что работник, который выполнял эту работу, нанёс фирме материальный ущерб в чистом виде, а при этом думал что приносит пользу.

Поэтому вопрос "зачем" как раз и является важнейшим. Если только проверить нормальный режим - незачем даже думать об этом. Думы тоже занимают время, а рабочее время это деньги.

[keysansa]

Потому что нормальное состояние всего одно, а ненормальных - сотни, где-то тысячи, и в каждом из них алгоритм должен отработать. И по-нормальному проверяется каждое из этих сотен и тысяч, шаг за шагом.

Есть методы упрощения. Много разных. Математически доказанных. Для дискретных устройств, например - карты Карно. И не надо все тысячи-тысяч состояний рассматривать. Опять, же, Codesys поддерживает наследование (а так же интерфейсы, сам правда стал использовать интерфейсы только недавно в Codesys), которые позволяют с помощью (грубо) декомпозиции, сократить число испытаний.
Но в целом с этим:

Так проходят нормальные испытания, медленно и муторно, но зато потом контроллер или система уезжает на объект и там уже об этом голова точно не болит.

полностью согласен.

ЗЫ. Система DUnit - была написана как раз с целью быстрого тестирования программы, особенно важна она при внесении изменений в код (проверка на то, что новый код не изменил работу системы диагностики).

[Jackson]

Есть методы упрощения. Много разных.

Но не везде допустимо их применение.