Да, всю программу целиком — было бы очень интересно. Даже если бы просто прогонять сценарии управляя входами и временем, и сопоставлять что на выходах — я бы с написания тестов кодить начинал. Основная сложность поддержки таких тестов в IDE это, по-моему, модули ввода-вывода, механизм обмена с которыми не формализован.
можно и чтение входов на этапе тестирования переопределить. но в итоге получится этакий тестирующий рантайм, который потребует ресурсов ПЛК. Писать "в обрез" не получится.
Юнит-тесты больше полезны самому программисту при написании кода. Чисто проверить, что при работе над модулем ничего не развалилось. Ну а наличие такой возможности может побудить к работе в другом стиле, с более независимыми ФБ.
Функциональные тесты - сценарии, похожие на жизнь - полезная конечно штука, но по-хорошему отдельный человек должен этим заниматься. И дело не только в лени программиста, просто знание потрохов при функц. подходе мешает. Тонкие места интуитивно обходятся стороной.
Последний раз редактировалось rapucha; 11.01.2016 в 13:19.
Можно вообще хоть что сделать спасибо, Тьюринг-полнота. Я даже таймеры с глобальной перемоткой делал как-то раз для демонстрации и тестирования многочасовых процессов. Но гораздо веселее было бы в полном автомате прогонять ряд тестов программно.
Либо значения через force write подкладывать. Или force write не работает с реальными ПЛК?Сообщение от rapucha
Это же тоже через force write можно эмулировать?
Или там какие-то особенности?
Кстати, чтобы "залить программу в модуль ввода-вывода и в ПЛК" нужно 2 разных CS проекта?
Или достаточно одного и там plc conf?
Конкретно в кодесисе работает это не очень стабильно и вызвать можно только вручную.Это же тоже через force write можно эмулировать?
Или там какие-то особенности?Программируется только ПЛК. Обмен с модулями — по поддерживаемым модулями протоколам. Делается либо через PLC Configuration, либо с портом напрямую через функции в SysLibCom — 50 / 50 в зависимости от разных тонкостей. Протокол у Овна чаще всего модбас, который поддерживается и в конфигураторе, и через распространённую modbus.lib (которая поверх SysLibCom). Модбас примитивен — практически набор функций чтения и записи адресного пространства подчинённых устройств.Кстати, чтобы "залить программу в модуль ввода-вывода и в ПЛК" нужно 2 разных CS проекта?
Или достаточно одного и там plc conf?
Заковырка — адреса входов/выходов модулей пишутся в руководствах, то есть из абстрактного проекта полный расклад модуля получить нельзя. Из PLC Configuration, впрочем, можно вытащить уже заданные программистом для конкретного проекта узлы. Так как использование существующих программ всё равно под вопросом из-за проекционного редактора, наверное, стоило бы рассмотреть аннотирование входных/выходных переменных на случай, когда обмен реализуется в обход конфигуратора (modbus.lib или вообще что-нибудь своё).
Хоть что-то там работает?
Я, если честно, думал о том, чтобы "force write" делать через программную интеграцию.
https://en.wikipedia.org/wiki/Data_s...creen_scraping
Т.е. подкидываем в CS "нажатия клавиш", чтобы оно думало, что мы "вручную" вызвали force write.
Я так понимаю, полный расклад не очень-то и нужен. Ведь, тестируем то, что используется. А если какие-то выходы не используются, то чего их тестировать?
Да, посмотрю что такое modbus.lib
Пункты меню можно попытаться без клавиатуры и мыши вызывать через WinAPI. Идентификаторы команд можно редактором ресурсов подсмотреть:Т.е. подкидываем в CS "нажатия клавиш", чтобы оно думало, что мы "вручную" вызвали force write.
res_ed.png
Но я не совсем понимаю, как вы собираетесь предварительно эти переменные на экране находить, чтобы их «щёлкнуть» и подготовить к force write. Судя по википедии, искать распознаванием на экране? Чёт я очкую, Славик.
Эх, где, она, молодость? HWND и SendMessage...
Да, разумеется SendMessage лучше чем эмуляция клавиатуры.
Товарищи из CoDeSys заботливо сделали окно Online -> Write/Force dialog.
Там "машиночитаемый" список всех переменных в виде таблицы переменная-значение.
Правда, как добавить туда новую запись, конечно, вопрос.
Возможно, через команду "watchlist load <file>" и там просто перечислить все возможные переменные.
Либо ещё можно сделать специальную программу, которая нужна только для того, чтобы интеграция открыла её в нужный момент, и воспользовалась открытом окном для редактирования переменных (там раскладка известна заранее, т.к. спец-программу генерируем мы сами)
К распознаванию на экране, конечно, не хотелось бы прибегать.
Хотелось бы, конечно, остаться в рамках вызова каких-то API. Т.е. gettext, вызов команд по ID и т.п.
Вот, кстати, пример: http://www.owen.ru/forum/showthread....l=1#post192422
Кода всего две строки, но там были бы полезны тесты типа "при таком-то напряжении на входе должна быть такая-то диаграмма на выходе".
Так сказать, сразу было бы понятно "что будет в таком-то случае", и можно спокойно добавлять гистерезисы
Тот код с большой вероятностью окажется в теле программы, а не функционального блока. И тестировать его придётся вместе с остальной программой. Об этом я и говорил в #87 и #95. Другое дело, если бы эти две строки были сначала обобщены в функциональный блок, а уже потом встроены в программу — тогда можно было бы говорить о тестировании функционального блока. Но в ПЛК ради одного вызова не обобщают обычно.
Ваши права
Ответить с цитированием