Hardella IDE

[Валенок]

А где предложено что-то внутри анонимного блока ? Внутри блока - только его собственный код. А передаваемые параметры - все внешние. Даже если это собственные поля.

[rapucha]

в смысле, у вас два анонимных блока на каждый таймер? затупил. Я почему-то думал что там прямо и декларация блока, а наверное нет.

Вот это вот намекает, что можно:
tmpTON_0 : TON;

[rapucha]

а вот кстати, можно в вашей схеме работы к готовому CDS проекту уже из Идеи добавить новые блоки? если да, то весь тестовый фреймворк можно внутри Идеи сделать.

[lara197a]

vladimirisitnikov
прочел от бессонницы ваш пост.
Наверное правильнее было бы вам потратить время на чтение документации кдс,
а не изобретение велосипеда..
многое бы стало бы понятно, много нового открыто.
Вы просто не умеете пользоваться кдс.

[Yegor]

Собственно, вопрос: в какую сторону дальше двигаться?

В сторону отладки в реальном времени. Остальное — мелочи.

Т.е. конструкцию "NOT TON.Q" просто физически не получится ввести в том смысле, что TON это не переменная.

В третьем кодесисе есть THIS как в плюсах (во втором ADRINST). Его можно разрешить в контексте вызова блока и резолвить во временное имя. Я не просто так предложил именно TON#(...), а не TON(). Такой синтаксис аннотирования используется для литералов встроенных и перечисляемых типов (UDINT#42). Т.к. анонимность один хрен нарушает секцию объявлений, то её можно сделать опциональной и тупо вводить экземпляров: IF TON#(...) / IF TON#ton1(...). Только ни в коем случае не разрешать использование имени за пределами скобок — будет бардак. UPD: хотя не, с видимостью в скобках тоже бардак будет, т.к. другие переменные так себя не ведут.

С тестами всё сложно из-за практики программирования ПЛК. Программисту придётся выбирать между устоявшимися приёмами и возможностью тестировать отдельные POU. Под устоявшимися приёмами я понимаю подход, где входы оказываются связанными с выходами без дополнительных прослоек, а независимые ФБ содержат только обобщённый функционал. Модули с сильным зацеплением сопротивляются юнит-тестированию, как известно. Не TONы же тестировать, ей богу.

[Владимир Ситников]

Я не просто так предложил именно TON#(...), а не TON(). Такой синтаксис аннотирования используется для литералов встроенных и перечисляемых типов (UDINT#42). Т.к. анонимность один хрен нарушает секцию объявлений, то её можно сделать опциональной и тупо вводить экземпляров: IF TON#(...) / IF TON#ton1(...). Только ни в коем случае не разрешать использование имени за пределами скобок — будет бардак. UPD: хотя не, с видимостью в скобках тоже бардак будет, т.к. другие переменные так себя не ведут.

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

Под устоявшимися приёмами я понимаю подход, где входы оказываются связанными с выходами без дополнительных прослоек, а независимые ФБ содержат только обобщённый функционал

Можно с этого момента по-подробнее?

Я, вроде, на форуме как-то встречал, что народ вообще mock'и делает. Т.е. из отдельного ПЛК делает "эмулятор реальной системы", подключает его к "боевому ПЛК" и смотрит работает ли "как надо".

Модули с сильным зацеплением сопротивляются юнит-тестированию, как известно. Не TONы же тестировать, ей богу.

Ну, 10 TON'ов уже без поллитра на понять.
Поэтому, лучше лишний раз проверить.

Да и интеграционное тестирование никто не отменял.
Да и chaos monkey тестирование тоже (запускаем тест, и в произвольный момент жмём на перезагрузку ПЛК)

Вот, например, тема про измерение частоты: http://www.owen.ru/forum/showthread....l=1#post192280
Там могли бы помочь тесты вида: "подаём на вход меандр 1.0 Гц -- ожидаем, что через минуту на выходе переменная такая-то должна быть 1.0 +- 0.1 Гц".

С точки зрения тестов, самый сложный момент -- ПЛК завязано на "реальный мир" и на "реальные часы". Т.е. если сказано "среднее за час", то для обычного теста придётся ждать этот самый один час.

Я же могу при "компиляции в режиме теста" незаметно подменять вызовы TIME() на чтение специальнообученной переменной и таким образом "ускорять время". Да, будут некоторые проблемы с зашифрованными библиотеками, но в пользовательском коде вообще без проблем.

[rapucha]

можно и чтение входов на этапе тестирования переопределить. но в итоге получится этакий тестирующий рантайм, который потребует ресурсов ПЛК. Писать "в обрез" не получится.

Юнит-тесты больше полезны самому программисту при написании кода. Чисто проверить, что при работе над модулем ничего не развалилось. Ну а наличие такой возможности может побудить к работе в другом стиле, с более независимыми ФБ.

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

[Владимир Ситников]

можно и чтение входов на этапе тестирования переопределить

Либо значения через force write подкладывать. Или force write не работает с реальными ПЛК?

Основная сложность поддержки таких тестов в IDE это, по-моему, модули ввода-вывода, механизм обмена с которыми не формализован.

Это же тоже через force write можно эмулировать?
Или там какие-то особенности?

Кстати, чтобы "залить программу в модуль ввода-вывода и в ПЛК" нужно 2 разных CS проекта?
Или достаточно одного и там plc conf?

[Владимир Ситников]

Не TONы же тестировать, ей богу.

Вот, кстати, пример: http://www.owen.ru/forum/showthread....l=1#post192422

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

[capzap]

возможно надо было скачать пример, но по предоставленному коду в теме, меня вообще не впечатлил такой подход, собственно требуется изучать другой язык, что бы по факту прога заменила слово TON на объявление переменной в КДС