Hardella IDE

[Yegor]

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

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

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

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

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

[Валенок]

Переменная - это экземпляр ФБ.

А фб без экземпляра это вообще ничто. Просто NOP.
Какой смысл тогда от "просто" вызова кода ФБ ? Нужно просто занять чем-то проц ?
Для полноценной и независимой работы с 2-мя анонимными фб нужно создавать 2 набора переменных (in1,in2,pt1,pt2,et1,et2,q1,q2) ? (А есть фб у которых 100500 переменных в интерфейсе)
И зачем тогда нужен вообще фб с его инкапсуляцией, когда кучки из наборов однотипных переменных сгребли в просто структурые переменные - фб, а опосля сделали их анонимными и добавили еще такие же кучки..
"Море, на море суша, на суше поп сидит и видит - море, на море.."
Даже в авторском примере за ради экономии 1 (одной) переменной введено 2 (две) переменные.

[capzap]

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

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

собственно требуется изучать другой язык

А кто вам сказал про другой язык?
Язык тот же самый. Можно писать "в классическом стиле".

Вы же не ругаете CS 3 за поддержку ООП программирования? Хочешь -- используй ООП, не хочешь -- не используй.
Так и тут. Не нравятся анонимные блоки -- не используй и всего делов.

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

Вы видео смотрели?

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

Позволяет "искать использования конкретной переменной/функционального блока".
Вот пример по "поиск использований": http://recordit.co/rx38caMeIA

Вот пример на "переименование переменных": http://recordit.co/g1qQlwj1Co
Переименовываем переменную, автоматически меняются её использования.
При этом, другие переменные с совпадающим именем проблемы не делают.
Аналогично можно переименовывать типы, блоки и т.п.

Подкрашивание красным когда в IF условии оказалось INT выражение.
Автодополнение, в конце концов.

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

Я не просто так предложил именно 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() на чтение специальнообученной переменной и таким образом "ускорять время". Да, будут некоторые проблемы с зашифрованными библиотеками, но в пользовательском коде вообще без проблем.

[capzap]

конструкцию IF tik.Q THEN ... END_IF; tik(IN:=NOT tik.Q,PT:=T#5s); сможете через свою разработку создать? Работу с указателями сможете воссоздать?

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

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

конструкцию IF tik.Q THEN ... END_IF; tik(IN:=NOT tik.Q,PT:=T#5s); сможете через свою разработку создать?

Исходный код:

PROGRAM PLC_PRG 
  variables: 
    output v1 : BOOL; 
     tik : TON; 
   
  body: 
    IF tik.Q THEN 
      v1 := TRUE; 
    END_IF; 
    tik(IN := NOT(tik.Q), PT := T#5s); 
END_PROGRAM

Результирующий (наверное, после not стоит скобки генерировать):

PROGRAM PLC_PRG
VAR_OUTPUT
  v1 : BOOL;
END_VAR
VAR
  tik : TON;
END_VAR
  IF tik.Q THEN
    v1 := TRUE;
  END_IF;
  tik(IN := NOT tik.Q, PT := T#5s);
END_PROGRAM

Работу с указателями сможете воссоздать?

Да, проблем не вижу.

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

Ну, текущий CoDeSys код это "write-only" код (без разницы ST или CFC). Т.е. код, который 1 раз пишется, и через месяц уже невозможно понять зачем что нужно. Никакой навигации нет, хрен поймёшь где использовалась конкретная переменная, где в неё пишут, значения, а где из неё читают.

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

[capzap]

Ну, текущий CoDeSys код это "write-only" код (без разницы ST или CFC). Т.е. код, который 1 раз пишется, и через месяц уже невозможно понять зачем что нужно. Никакой навигации нет, хрен поймёшь где использовалась конкретная переменная, где в неё пишут, значения, а где из неё читают.

бибку от oscat видели, когда бы я к ней не обращался, мне понятен блок который я хочу из неё взять. Если же речь об использовании такой плюшки как найти случаи использования, в КДС их нет в степе есть, так один продукт бесплатный, другой платный. Сделать для КДС некоторое дополнение улучшений за бесплатно, конечно хорошее начинание, но как мне кажется Вы сейчас не загружены работой, поэтому есть время на развлечение

[Yegor]

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

Это всё к сильному зацеплению. Из тех чужих проектов, что я видел, большую часть POU было бы трудно выделить для юнит-тестов. Соответственно покрытие кода тестами будет никакое.

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

Если мы по-прежнему говорим о юнит-тестах, то TON тестируется один раз, будь в программе хоть сто экземпляров этого типа. Чтобы был смысл в поддержке юнит-тестов, должно быть много разнотипных ФБ, и они должны составлять основную часть логики проекта, и при этом быть изолированными. Я такого кода пока не встречал и сам так не писал. Самое важное мясо обычно в слипшихся пельменях типа 'программа'. Этому способствуют разные вещи: непортабельность логики управления (проекты пишутся под конкретный объект эксплуатации, зачастую в единственном экземпляре); «паблик морозов» в реализации стандарта кодесисом; да даже необходимость вводить переменные на каждый чих — почему я про анонимные блоки и написал. Но это по моему опыту, а большую часть проектов я смотрел в открытом доступе, куда обычно попадают работы новичков.

найти случаи использования, в КДС их нет в степе есть

По крайней мере переменные кодесис умеет искать:

crossref.png

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

Если мы по-прежнему говорим о юнит-тестах, то TON тестируется один раз, будь в программе хоть сто экземпляров этого типа. Чтобы был смысл в поддержке юнит-тестов, должно быть много разнотипных ФБ, и они должны составлять основную часть логики проекта, и при этом быть изолированными.

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