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

[Филоненко Владислав]

Владимиру Ситникову - Существует много ПЛК (в т.ч. и у нас) с Линуксом. Стреляет почему то только у крупных фирм-системных интеграторов, и то конечному пользователю поставляется CoDeSys-подобная или ещё более упрощенная среда разработки. Потому что кривая вхождения в профпрограммирование реального времени нереально крута. И никто не хочет пол года своей жизни тратить только на обучение этому. А потом еще и алгоритм писать! Все хотят соединить вход с выходом через логику, добавить мастеров/slave парой щелчков и не углубляться в написание драйверов, прерываний, нюансов межпроцессного и межпроцессорного обмена, ловить неописанные "фичи" оборудования, отлаживаясь по миганию светодиода и т.п.
А на ПР любой читавший в детстве справочник по радиоэлектронике после 2 дней обучения может писать нужные ему программы.
Причем что в ПР, что в ПЛК собственно среда разработки - это даже не 50% труда. А процентов 20-30 в коде и 5-7 в стоимости конечного продукта.

Если Вам хочется творить - приходите в крупную компанию-разработчик ПО для автоматизации, благо их много теперь.
И если Вы сумеете не перегореть за 1,5 года типичного цикла разработки нового изделия - Вы прочитаете свои теперешние посты с улыбкой.

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

Владимиру Ситникову - Существует много ПЛК (в т.ч. и у нас) с Линуксом

Уже говорил, но повторюсь: я осознанно выбрал вариант без Linux, т.к. надёжность Linux решений для меня под сомнением.
Судить о КДС runtime, конечно, тоже приходится "на веру". Но стабильность/предсказуемость Linux под вопросом. Масса примеров, когда "внезапно взбесившийся modbus драйвер занимает 100% CPU и ПЛК шлёт пламенный привет временам отклика".

Все хотят соединить вход с выходом через логику, добавить мастеров/slave парой щелчков и не углубляться в написание драйверов, прерываний, нюансов межпроцессного и межпроцессорного обмена, ловить неописанные "фичи" оборудования, отлаживаясь по миганию светодиода и т.п

Во во. Именно по-этому и прошу чего-нибудь типа ST или IL в составе OwenLogic.
Так, чтобы можно было создавать программы для ПР, чтобы при этом не приходилось заниматься непотребством квадратиками ОЛ и с драйверами.

Обратите внимание: я не просил возможность заливать бинарный код.
Речь именно о промежуточном p-code (IL, ASM, без разницы как называть). Так, чтобы особенности железа решались прошивкой ОЛ/интерпретатором этого самого p-code, и чтобы при этом не приходилось заниматься непотребством при программировании в ОЛ. Например, чтобы можно было генерировать код в сторонних инструментах.

А на ПР любой читавший в детстве справочник по радиоэлектронике после 2 дней обучения может писать нужные ему программы.

Да, так, всё верно.

Обсуждаемая проблема в текущей теме состоит в том, что тому, кто читал книги чуть более двух дней, в рамках ОЛ будет тесно.
Могут быть проекты (и встречаются), где ограничивающим звеном будет не железо/время/мозги, а именно ОЛ. Именно это печально.

Например, я осознанно не стал выбирать ОЛ, т.к. программировать одними квадратиками это печаль.

Вы прочитаете свои теперешние посты с улыбкой.

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

Для ST, например, кто-то вообще в Excel программы генерирует по шаблону. В ОЛ такое никак, ведь в ОЛ можно только мышкой рисовать.