Owen Logic 2.1. А что изменилось?
Тема про бета 2.0 закрыта, хотел отписать там.
Я так понял версия Owen Logic сменилась с 1.23 на 2.0 и 2.1 впоследствии. Судя по установщику, проект перевели на новую платформу, полностью (или частично) переписав. Но ведь в пользовательском плане не изменилось ничего, кроме смены расширения файлов!
Огромным приятным сюрпризом стало введение языка ST в ОЛ. Но использовать его пока представляется практически невозможно. И как бы хрен с ним с отладчиком. Отладить можно и где-нибудь. Но ведь у функции, у неё один выход! И к тому же функцию нельзя встроить в макрос!!! Программирование в ПЛК в общем, да и в ОЛ в частности, идёт в процедурном стиле. У кодесис, как я понял, есть какие то потуги перевести программирование на ООП, но это лирика, по делу:
Макросы - это и есть красивое решение по разбиению сложной задачи на простые подзадачи. Разбиение сложной функции на простые, складывание этих функций в модули, библиотеки, и вызов их в других функциях это средство структурирования программы. Это основа основ!!! Каким образом можно было додуматься лишить использования функций на ST в макросах!!!??? Заводить их через входы? Создавать и копировать огромные "простыни", чтоб в глазах рябило??? Я бы пожелал разработчикам взять и смешать их весь код от ОЛ в кучу, не используя ни модулей, ни функций, ни процедур (а вот пишите только так, чтобы можно было вернуть лишь один результат!!!!) - сделайте всё в один файл, между { и }, и логику и интерфейс, а я потом на вас посмотрю.
Наверное я слишком категоричен и возможно слишком эмоционально реагирую. Но решив переписать проект по максимуму для себя удобно, столкнулся с простой невозможностью это сделать. Всё будет на главном экране!!! На мой взгляд, первое, что надо сделать - возможность добавлять функции на ST в макросы. Это понятно и логично. Я могу добавить в макрос другой макрос? Могу. Могу добавить в макрос ФБ? Могу. Могу добавить простую функцию в макрос? А почему функцию на ST не могу? Почему она туда не добавляется? Загадка! Какой тогда от неё практический смысл, если её нельзя использовать в проекте? В чём преимущество их существования только на главном экране?
Второй момент, который видел уже тут на форуме, написание ФБ на ST. Я так понимаю, что это как раз попытка реализовать процедуры. То есть то, что может вернуть более одного результата. На мой взгляд, ФБ ничем не отличается от макроса. А чем? Наверное только тем, что ФБ встроены уже. Ну хорошо, пусть макрос написанный полностью на ST называется ФБ, пережить можно. Вообще, моё возмущение по поводу невозможности добавить в макрос функцию на ST и связано, что на ST можно написать только функцию, которая умеет возвращать лишь один результат, но это моя конкретная частность, в итоге, когда пришлось бы смешивать код на FBD и ST и объединять его в логическую единицу - макрос, я бы опять упёрся в невозможность встроить функцию ST в макрос, так как я только начал переработку своего старого проекта и понял, что функции ST - пятая нога зайца, реализованные так, как сейчас это сделано.
Кстати, я не думаю, что отладчик, которые есть в кодесис, который просто идёт по шагам и только показывает значения переменных на каждом шаге, такая уж сложная вещь.
Ну и если пожелать именно развития, если уж не внедрять ООП, объединяя методы и дынные в объект на основе класса, что кстати в детской поделке Ардуино работает!!!! То хотя бы внедрить сложные типы данных, с полями и доступом через точку. Так называемые структуры. Попадалось, что кодесис идёт по этому пути.
Считайте это отзывом на ОЛ 2.1.304, которая скачалась сейчас.
В итоге:
1. Нет добавления функций на ST в макросы. Делает использование ST в проекте не то что "сомнительным", а невозможным.
2. Функция на ST -функция, то есть возвращает только один результат. Создание ФБ на ST, это было бы правильным шагом, ну или макрос на ST (одно и то же). Или возможность менять глобальные переменные хотя бы (не знаю правильно ли), в рамках какой нибудь void -функции, или что было бы правильно в стиле ST - procedure. Не знаю, нужен ли доступ к глобальным переменным прям из программы, спорно, private и public же придумали зачем-то.
3. Нет отладчика. Извернувшись - можно пережить, но некрасиво уж сильно. Несерьёзно для IDE.
4. Развитие в сторону ООП было бы замечательным, можно не догонять, а обгонять! Ну а начать конечно с составных типов. TYPE timer {onmin, offmin: integer; onoff: boolean} //// timer.onoff:=true. От балды, поймёт кто надо.
