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

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

Если это всё что там есть, тогда конечно полноценный линух не влезет. А так это вполне могут быть остатки от всей памяти, которые даны пользователю на свои нужды)

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

Тогда вы должны понимать, что пользовательская программа не зависит от версии разводки платы и тому подобного. И пользователь однозначно будет писать программу не под STM-контроллер, а под конкретную среду исполнения.

См. выше. Ресурсов негусто и надеяться на богатую среду исполнения вряд ли придётся.

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

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

Ежу понятно, что сделать "окружение" можно, если очень захотеть. Другое дело, что, если изначально такой цели не стояло, то прикрутить такое окружение пост-фактум непросто.

[starmos]

После прочтения комментариев, у меня вот такой вопрос возник еще: откуда берутся такие специалисты, которые схемы читать умеют, а программировать нет настолько, что для них надо "костыли" придумывать, вроде языков МЭК? Слов нет - МЭК это стандарт для ПЛК, потребность в нем возникла в то время, когда ПЛК встречались не часто, а специалистов по релейно-контактным и логическим схемам было полно. Вот чтобы их вовлечь в процесс и потребовались языки МЭК. Но время-то прошло уже и немало, сейчас языки МЭК имеют смысл потому что устоялись в предметной области, но почему это ограничивает развитие? С 1993 года я 15 лет отработал преподавателем в ВУЗе по специальности "Автоматизация технологических процессов и производств". С 90-х годов студентам давались и программирование на C, в том числе для микроконтроллеров и схемы и логические и релейно-контактные и разработка печатных плат, в том числе микроконтроллерных - все это с практическими занятиями. Как раз ПЛК, что характерно, давались ограниченно, т.к. в ВУЗе современных не было, а новые были дороги, поэтому и был упор на разработку устройств на микроконтроллерах. Но в середине 2000-х появились и ПЛК и при этом С остался, такие задачи, как последовательный интерфейс и работа в сетях TCP/IP - в том числе для микроконтроллеров давались, понятие о работе с базами данных - давалось. Я не думаю что ВУЗ или кафедра в этом отношении уникальны - изучение опыта других вузов, их методичек, скорее говорит о том, что там кое где еще и круче все. Уже 8 лет я в ВУЗе не работаю, но знаю что основные элементы программы остались, за новинками и современными тенденция ми - следят. Очень многие мои студенты работают по специальности (больше чем я ожидал даже), хотя реально немногие сталкиваются с созданием своих микроконтроллерных устройств. Так откуда до сих пор берутся "специалисты", которые тут высказываются на тему - "нам С не нужен, мы в программировании не понимаем, а только в схемах"?

[capzap]

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

[starmos]

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

Про преподавание языка С я сказал - были и практические работы. Например, кроме работы преподавателем, я занимался разработкой систем на микроконтроллерах, у меня постоянно были готовые платы, которые я использовал для отладки софта - их же я использовал и для обучения. Группе выдавалось задание, они писали программу, прошивали в плату, я по индикаторам и кнопкам принимал итоги. Т.е. весь цикл разработки софта люди проходили на практике. Сейчас стендов для разработки/отладки еще больше и они в разы доступнее.
Когда я писал про "инженеров ОВЕНа" - я просто выражал удивление. Вполне возможно множества, вызывающие мое удивление, пересекаются - не вижу тут противоречия.

[capzap]

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

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

[Vyachep]

Позвольте тоже набросить на вентилятор.

Зачем всякие p-code и написание новых функциональных блоков на С?
Даёшь кроссплатформенный тулчейн, который можно прикрутить к любой из распространенных сред разработки, чтобы ни один программист обделенным не ушел...

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

Позвольте тоже набросить на вентилятор.

Не позволю!

Зачем всякие p-code

Я приводил конкретные примеры как это поможет с обычными ОЛ проектами: формулы, итеративные вычисления (==ПИД с автонастройкой), автоматическое тестирование.
И, вполне вероятно, добавление подобного должно быть безболезненным для ОЛ.

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

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

Как это позволит решить что-нибудь из АСУТП области?

Если в Новосибирске, приходи 4-го апреля на https://2017.jbreak.ru/ -- расскажу почему C для ПЛК это боль.

[Eugene.A]

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

[starmos]

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

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

[Eugene.A]

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

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