Автор: Владимир Ситников
Дата: 06.11.16 19:49
>Кодесис, хоть архаичен с виду, но вполне достаточен чтоб заставить любой ПЛК выполнять любую задачу
Вы видели SMConstructor HVAC от Segnetics?
Как такое в КДС сделать?
По-нормальному -- никак.
SMConstructor прямо в нормальных вопросах спрашивает: "вентилятор у вас одноступенчатый или с частотным управлением?".
> Увеличивать состав инструментальных сред - может быть нужно только небольшому количеству людей
Вот тут не соглашусь.
Предметно-ориентированное программирование может быть крайне полезно.
1) Вот недавний доклад об опыте создания среды для embedded программирования: http://2016.splashcon.org/event/itsle2016-lessons-learned-about-language-engineering-from-the-development-of-mbeddr
Там на 71ой странице (Editor Usability) приведены результаты опроса, и результаты в целом положительные.
Ссылка на слайды: http://voelter.de/data/presentations/buildingMbeddr2016.pdf
2) Видели изыскания на тему "Switch-технологии"? Видели изыскания на тему "вот такой утилитой мы из Visio диаграммы сгенерируем код на ST, C и далее по списку"?
Даже если сама тула хорошая, то её отвязанность от процесса сразу ставит крест. Ну никто не будет запускать отдельные утилиты и "программировать в visio".
Совсем другое дело, если возможность "автоматного программирования" будет органично находиться в среде. Можно, конечно, обсуждать, что "SFC это и есть автомат", но предлагаю не углубляться в детали.
Моя мысль тут вот в чём: программировать в visio никто не будет, а, если среда обеспечит полный цикл, то уже может быть удобно. Грубо говоря, связь шагов/переменных не по именам должна быть, а прямо реальная связь. Чтобы можно было "найти все использования конкретной переменной" и т.п.
Опять же, на слайдах выше (66-ой слайд, "Different Notations for one Abstraction") пример, что один и тот же конечный автомат может отображаться по-разному (как диаграмма, как таблица, и в текстовом виде).
3) Пример SMConstructor выше. Не знаю насколько он интегрирован в основную среду программирования Segnetic, но возможность производителей ПЛК быстро выпускать адаптированные решения, по-моему, это очень полезно для конечных пользователей, ведь на порядок проще "подправить имеющийся/сгенерированный" проект, чем вкуривать "а как это делают"
4) Язык ДРАКОН. Даже если не пытаться использовать ДРАКОН взамен SFC (кстати, почему бы и нет?), то сам опыт языка говорит, что в смешанных нотациях сила (т.е. сам ДРАКОН для блок-схемы, а сами действия уже на произвольном другом языке). Вот у КДС крайне тяжело с "разными нотациями". Есть там стандартные "IL/LD/ST/CFC/SFC/PLC Configuration" и всё тут. Хоть таргетом об таргет тресни, но не сможешь в CDS добавить ещё один "язык", скажем для описания "проекта HVAC".
5) Всё вышеперечисленное смотрите не в применении к "программистам-профессионалам-на-закрытом-треке-не-пытайтесь-повторить-дома", к как раз к простым смертным. Именно для "простых смертных" адаптированные по месту (по задаче) поля ввода как раз и будут на высоте.
6) Импортозамещение в хорошем смысле этого слова. Считается, что "КДС уж точно никогда не запретят"?
7) Нормальная работа на linux/mac ОС, а не только на windows.
|
|
