Возможность программирования на более низком, чем ОЛ схемы уровне

[starmos]

Файл прошивки для ПР200 занимает 156 КиБ

Я утверждал, что "добавить в ПР поддержку заливки написанных на C функций непросто". Возражения есть? Есть хотя бы пример "вон, у таких-то контроллеров легко совмещаются FBD и C программирование"?

Раз у них есть в ОЛ графический редактор, то они в итоге должны генерировать то, что в схемотехнических САПР называется netlist - список цепей, который описывает какая цепь от какого вывода и к какому идет. Имена выводов известны, какие из них входы, какие выходы - тоже и все это в списке цепей. Макросы уже есть - на одном уровне иерархии вы видите макросы с входами/выходами, а глубже - содержимое макроса, при этом видите те же всходы/выходы. И в итоге все это транслируется в машинные коды. Так в чем проблема обозвать макрос как "написанный на С" и откомпилировать его отдельно, а редактор связей свяжет его по именам переменных (входов/выходов)? Это все уже делается сейчас, только макросы (подпрограммы, модули) сейчас представляются в виде схемы, а не текста. Это просто вы так видите программу в процессе разработки, а на самом деле она в итоге однородна, хоть на чем макросы пиши.

[capzap]

Группе выдавалось задание, они писали программу, прошивали в плату, я по индикаторам и кнопкам принимал итоги. Т.е. весь цикл разработки софта люди проходили на практике.

да здесь на форуме каждую сессию обращаются студенты за помощью в написании программ, им только остается залить готовый проект в контроллер, не кажется Вам что это ложное ощущение что есть практика у всех студентов?
Говорить о поголовном знании Си людьми приходящими в промавтоматику совершенно не стоит, ни о каком возрастании в разы потребления продукции оснащенной макросами на ЯВУ не произойдет, кто умеет пользоваться тот будет, кто нет тот и ни разу не откроет вкладку с такими макросами. Появление текстового языка в ОЛ сведется к дублированию элементов графического языка, стоит только надеятся что этих элементов будет гораздо больше чем сейчас

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

Так в чем проблема обозвать макрос как "написанный на С" и откомпилировать его отдельно, а редактор связей свяжет его по именам переменных (входов/выходов)?

Блин. Такое ощущение, что вы вообще не сталкивались с разработкой компилятора.

Приведу пример: сложно будет поддержать этот "написанный на C" в режиме "симуляции".
Допустим, с помощью лома получилось из C текста получить бинарный код. Внимание, вопрос: как тестировать этот макрос? Как тестировать программу, использующую этот макрос?
Не забываем, что online режима у ПР нет, т.е. возможности "залить в ПР" для теста тоже нет.


Но и сама задача "скомпилировать" непростая. Разрабатывать свой C-компилятор это неблагодарное дело, а прикручивать сторонние непросто.

[starmos]

Блин. Такое ощущение, что вы вообще не сталкивались с разработкой компилятора.
Внимание, вопрос: как тестировать этот макрос? Как тестировать программу, использующую этот макрос?
Но и сама задача "скомпилировать" непростая. Разрабатывать свой C-компилятор это неблагодарное дело, а прикручивать сторонние непросто.

Вы никогда не сталкивались с системами схемотехнического моделирования, Proteus то же? Нарисованная схема моделируется в "реальном" времени, при этом модели могут быть макро (содержать в себе тоже схему) или выполненными в текстовом виде, а микроконтроллер на схеме может моделироваться с учетом его программы, написанной на С. Как они это делают - для меня тоже загадка, но сам факт несомненен. Но такого даже и не надо вовсе.
"Прикрутить" к среде разработки тот или иной компилятор - обычное дело, например софт для микроконтроллеров Atmel можно разрабатывать на С с помощью нескольких компиляторов, это вообще обычно для микроконтроллеров, а что и как компилировать - задается в командных файлах. Сперва видится проход компилятора из схемы в C, макросы на С - пропускаются, а затем проход компилятора С уже полностью. Как вариант.

[Eugene.A]

Почему бы сишникам просто не использовать ПЛК, программируемые на С, и не лезть со свиным рылом в калашный ряд? Их ведь есть! Если тренд в программировании движется к графическим средам программирования во всех отраслях, попытки развернуть его обратно тщетны. Одна Rational Rose чего стоит - любо дорого - те же функциональные блоки, только в профиль.
Самый ценный в наше время ресурс - интеллектуальный труд. Человеко-час стоит дорого. И если разработка с отладкой ПИД-регулятора с автонастройкой + Modbus для ПР на С займёт месяц - нафига это кому нужно? Это ведь обойдётся дороже любого контроллера, для которого соответствующий функциональный блок просто есть в библиотеке.
Конечно, если вы собираетесь сделать 100500 контроллеров с этим ПИД-регулятором, можно и потрахаться с дешёвым ПР, и написать алгоритм хоть в машинных кодах. Сэкономите на железе, а стоимость разработки размажется тонким слоем на всю партию. Но много ли здесь таких разработчиков? Да и решаются такие задачи совсем по другому, железо используется заказное, вплоть до чипов и дисплеев, со всякими картинками в виде снежинок, краников, батарей отопления и насосов. Получается в итоге какой-нибудь ECL-310, E8, RVD. Никто для таких партий не использует свободно программируемые ПЛК и ПР.

[starmos]

Почему бы сишникам просто не использовать ПЛК, программируемые на С, ...

Наверное потому что я в итоге так и не понял - в чем проблема ДОПОЛНИТЬ ОЛ новой возможностью? Вот даже в ОВЕН обещали подумать. Все эти ваши графические языки прекрасны, пока у вас есть функциональный блок, но если его нет, то вы ни за месяц программу не напишете, ни за сколько. А если он есть, но чуть-чуть не подходит, то вы потратите тот же месяц, но не на то чтобы сделать хороший алгоритм, а на то, чтобы приколхозить кривую заплатку для связи этого ФБ с вашей программой. даже если писать чисто на С - ничто не мешает иметь набор отлаженных модулей и использовать их в проектах. Причем это уже сейчас так - все эти прямоугольники, которые вы называете ФБ - существуют только на экране, а в реальности - это те же подпрограммы на С.

[Eugene.A]

в чем проблема ДОПОЛНИТЬ ОЛ новой возможностью?

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

[AI!]

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

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

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

PS жду очередную порцию камней... яиц.... помидоров....

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

Для полноты картины тут нужен комментарий Максима:

...тема будет закрыта. Очень много флюда и оскорблений... команда OWEN Logic сейчас уделяет бОльшую часть времени на реструктуризацию существующего продукта...

Ещё раз подтвердилось, что связка ПР-ОЛ по идеологическим причинам должна быть как электромагнитное реле и ни граммом лучше.
Очень точно ситуацию передаёт фраза "не жили хорошо, нечего и начинать".
Верхи не хотят, низы ничего дальше схем не понимают и боятся.

Флаг в руки командам ОЛ-ПР, создавшим столь высококлассный продукт. Ну и специальный флаг в руки "электронщикам", чтобы с тем же рвением накладывали вето на добавление в ПР-ОЛ любой функции, которая испортит гордое название Реле.

[игорь68]

Цитата Сообщение от starmos Посмотреть сообщение
в чем проблема ДОПОЛНИТЬ ОЛ новой возможностью?
Да в том что нужна стабильная рабочая версия без глюков и косяков. Откройте немецкий софт пятилетней давности и откройте версию за 2016 год. Удивитесь что нечего не поменялось только добавились новые ФБ. А все остальное как было так и есть . Сменили железо вот новые ФБ и новые функции (сеть модем и тд и тп). Больше нечего не меняют и не добавляют. У овен такая же история поменяли железо. Добавили "плюшкию" . Все косяки и баги уберите и достаточно. Мы же не заводи в гараже 250 тонный Белаз для поездки в магазин за булкой хлеба. И не грузим в Акушку 4 стиральных машинки и два холодильника. Каждому продукту свое применение.
Правильно сказали выше если у вас нет нужного ФБ под ваш проект то просто выбрали не тот продукт.