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

[игорь68]

Это по моему некогда не закончиться. Да не нужны здесь СИ и тому подобная дребедень. ЭТО РЕЛЕ. И все ваши внешние редакторы отладчики компиляторы и прочие в ОЛ НЕНУЖНЫ. Если не умеешь читать однолинейные схемы или не можешь отличит ТМ2 от ЛА3 то это не для тебя . Если я не хочу себе забивать голову ПЛК или СПК и разбираться в коде то я не лезу с советами на ветку по кодесис. Вон команда-аппарат на реле и кулачковых контактах начиная с ФАУ -2 и посей день в космос летает без всяких СИ. Потому что надежно.
От себя. Сделает ОВЕН как у немцев возможность сохранить прошивку в PDF формате с возможностью обратной конвертации замечательно. Не сможет ну что будем ездить на объекты или через ROVKIны железки будем делать это удаленно.
Сделает Овен как у француза всплывающие окошко где буду кнопочки (входа ) и лампочки (выхода) для режима симулятор хорошо. Нет сможет будем тыкать мышкой по экрану.
А если Овен в помощь Ревака Юрию посадит еще одного человека который будет за маленькую денежку при четком и нормальном ТЗ делать макросы для пользователя это будет вообще замечательно.

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

Это по моему некогда не закончиться. Да не нужны здесь СИ и тому подобная дребедень. ЭТО РЕЛЕ. И все ваши внешние редакторы отладчики компиляторы и прочие в ОЛ НЕНУЖНЫ.

Вот на это ответьте, пожалуйста:

Не пойму вашей логики - "поскольку ЗАЯВЛЕНО что это реле, то онлайн отладка по рангу не положена"? Существует какой-то список возможностей, которые реле должно иметь, а которые ни в коем случае не должно, а если аппаратно такая возможность есть, то её надо задушить? Всего лишь хочется взять по максимуму от архитектуры и да за вдвое меньшую чем у ПЛК63 цену...

starmos верно сказал.
Сейчас же получается, что "политика партии" состоит в том, чтобы ОЛ было унылым. Хозяин-барин.

Если не умеешь читать однолинейные схемы или не можешь отличит ТМ2 от ЛА3 то это не для тебя

Перефразирую: если только и умеешь, что читать однолинейные схемы, то нечего говорить за архитектуру ПР-ОЛ.
Или так: создайте систему, которой сможет пользоваться дурак, и только дурак захочет ею пользоваться.

[ASo]

Или так: создайте систему, которой сможет пользоваться дурак, и только дурак захочет ею пользоваться.

Для удобства можете считать и так.
Именно поэтому и появились "языки МЭК" как инструмент для инженера-ТЕХНОЛОГА, а не программиста.
Тем не менее, в той же промэлектронике во всю используют стандартные одноплатные компьютеры (начиная от ушедшего, но до сих пор используемого в нашей нефтянке micro PC == IBM/PC-XT, продолжая PC/104 и т.д.) но они программируются профессиональными программистами.
И что?

[anthrwpos]

И чем дело с ним закончилось? что взорвать успел? Или не дали поля для деятельности, и уволился?

Уволился по общей несовместимости с остальным персоналом)
Взорвать ничего не успел, несмотря на то, что чего-то там даже понакрутил на котельной.

Не путаю.

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

32KiB RAM, 128KiB ROM и embedded linux?
Не верю (tm)

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

Именно поэтому и появились "языки МЭК" как инструмент для инженера-ТЕХНОЛОГА, а не программиста.

Я не знаю, конечно разные бывают предприятия, но по-моему, весьма маловероятно, чтобы ТЕХНОЛОГ занимался автоматизацией.
Он даст задачу АСУшнику, а АСУШник уже скажет, что нужно для этого купить и сам будет всё программировать.
У нас например, технологи вообще компьютером пользоваться не умеют)

[Алексей Геннадьевич]

ASo
starmos
Сей спор ведётся ещё со времён Фон-Неймана, который шпынял и троллил коллег которые пользовались новомодным языком-ассемблером. "Что это за математики-программисты такие, что машинный код в голове удержать не могут?
Моё мнение - если на написание программы на FBD и её отладку+ПНР уйдёт неделя, а на то-же самое на С - месяц, то выбор очевиден даже при равных зарплатах инженера АСУ и программиста.

Так откуда до сих пор берутся "специалисты", которые тут высказываются на тему - "нам С не нужен, мы в программировании не понимаем, а только в схемах"?

Оттуда-же, откуда и электрики не знающие закон Ома. И приводчики, которые на привод смотрят как баран на новые ворота.

Уволился по общей несовместимости с остальным персоналом)
Взорвать ничего не успел, несмотря на то, что чего-то там даже понакрутил на котельной.

Считал себя самым умным при нулевом опыте?

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

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

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

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

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

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

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

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

[starmos]

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

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

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

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

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

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

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


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