Вот на это ответьте, пожалуйста:Сообщение от игорь68
starmos верно сказал.
Сейчас же получается, что "политика партии" состоит в том, чтобы ОЛ было унылым. Хозяин-барин.
Перефразирую: если только и умеешь, что читать однолинейные схемы, то нечего говорить за архитектуру ПР-ОЛ.
Или так: создайте систему, которой сможет пользоваться дурак, и только дурак захочет ею пользоваться.
Для удобства можете считать и так.
Именно поэтому и появились "языки МЭК" как инструмент для инженера-ТЕХНОЛОГА, а не программиста.
Тем не менее, в той же промэлектронике во всю используют стандартные одноплатные компьютеры (начиная от ушедшего, но до сих пор используемого в нашей нефтянке micro PC == IBM/PC-XT, продолжая PC/104 и т.д.) но они программируются профессиональными программистами.
И что?
Уволился по общей несовместимости с остальным персоналом)
Взорвать ничего не успел, несмотря на то, что чего-то там даже понакрутил на котельной.
Тогда вы должны понимать, что пользовательская программа не зависит от версии разводки платы и тому подобного. И пользователь однозначно будет писать программу не под STM-контроллер, а под конкретную среду исполнения.Если это всё что там есть, тогда конечно полноценный линух не влезет. А так это вполне могут быть остатки от всей памяти, которые даны пользователю на свои нужды)32KiB RAM, 128KiB ROM и embedded linux?
Не верю (tm)
Я не знаю, конечно разные бывают предприятия, но по-моему, весьма маловероятно, чтобы ТЕХНОЛОГ занимался автоматизацией.
Он даст задачу АСУшнику, а АСУШник уже скажет, что нужно для этого купить и сам будет всё программировать.
У нас например, технологи вообще компьютером пользоваться не умеют)
После прочтения комментариев, у меня вот такой вопрос возник еще: откуда берутся такие специалисты, которые схемы читать умеют, а программировать нет настолько, что для них надо "костыли" придумывать, вроде языков МЭК? Слов нет - МЭК это стандарт для ПЛК, потребность в нем возникла в то время, когда ПЛК встречались не часто, а специалистов по релейно-контактным и логическим схемам было полно. Вот чтобы их вовлечь в процесс и потребовались языки МЭК. Но время-то прошло уже и немало, сейчас языки МЭК имеют смысл потому что устоялись в предметной области, но почему это ограничивает развитие? С 1993 года я 15 лет отработал преподавателем в ВУЗе по специальности "Автоматизация технологических процессов и производств". С 90-х годов студентам давались и программирование на C, в том числе для микроконтроллеров и схемы и логические и релейно-контактные и разработка печатных плат, в том числе микроконтроллерных - все это с практическими занятиями. Как раз ПЛК, что характерно, давались ограниченно, т.к. в ВУЗе современных не было, а новые были дороги, поэтому и был упор на разработку устройств на микроконтроллерах. Но в середине 2000-х появились и ПЛК и при этом С остался, такие задачи, как последовательный интерфейс и работа в сетях TCP/IP - в том числе для микроконтроллеров давались, понятие о работе с базами данных - давалось. Я не думаю что ВУЗ или кафедра в этом отношении уникальны - изучение опыта других вузов, их методичек, скорее говорит о том, что там кое где еще и круче все. Уже 8 лет я в ВУЗе не работаю, но знаю что основные элементы программы остались, за новинками и современными тенденция ми - следят. Очень многие мои студенты работают по специальности (больше чем я ожидал даже), хотя реально немногие сталкиваются с созданием своих микроконтроллерных устройств. Так откуда до сих пор берутся "специалисты", которые тут высказываются на тему - "нам С не нужен, мы в программировании не понимаем, а только в схемах"?
ASo
starmos
Сей спор ведётся ещё со времён Фон-Неймана, который шпынял и троллил коллег которые пользовались новомодным языком-ассемблером. "Что это за математики-программисты такие, что машинный код в голове удержать не могут?
Моё мнение - если на написание программы на FBD и её отладку+ПНР уйдёт неделя, а на то-же самое на С - месяц, то выбор очевиден даже при равных зарплатах инженера АСУ и программиста.
Оттуда-же, откуда и электрики не знающие закон Ома. И приводчики, которые на привод смотрят как баран на новые ворота.
Считал себя самым умным при нулевом опыте?
Последний раз редактировалось Алексей Геннадьевич; 15.03.2017 в 08:33.
даже сименс беря неплохие деньги за обучение, выдает лишь бумажку прослушал курс лекций, какое преподование в ВУЗах языка? Прямо все досконально изучают, как Вы это определяли, каждым персонально сидели в общяге и репетиторствовали, если всё сводилось к сбору рефератов то у Вас ложно представление о своем курсе. Просто поражает слышать от одного и того же человека, что инженеры ОВЕНа не могут создать идеальный продукт, но в ВУЗах у нас выпускают каждый год гениев, вроде и те и те обычно заканчивают одни и те же институты
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Позвольте тоже набросить на вентилятор.
Зачем всякие p-code и написание новых функциональных блоков на С?
Даёшь кроссплатформенный тулчейн, который можно прикрутить к любой из распространенных сред разработки, чтобы ни один программист обделенным не ушел...
Файл прошивки для ПР200 занимает 156 КиБ
Файл прошивки для ПР110 занимает 32 КиБ
См. выше. Ресурсов негусто и надеяться на богатую среду исполнения вряд ли придётся.
Ещё раз повторю свою мысль: едва ли сейчас прошивки ПР заточены под то, чтобы к ним можно было легко подключать самописные функции на C. Можно ли сделать такую "среду окружения"? Конечно, сделать можно почти что угодно, но сделать это непросто.
Я утверждал, что "добавить в ПР поддержку заливки написанных на C функций непросто". Возражения есть? Есть хотя бы пример "вон, у таких-то контроллеров легко совмещаются FBD и C программирование"?
Ежу понятно, что сделать "окружение" можно, если очень захотеть. Другое дело, что, если изначально такой цели не стояло, то прикрутить такое окружение пост-фактум непросто.
Про преподавание языка С я сказал - были и практические работы. Например, кроме работы преподавателем, я занимался разработкой систем на микроконтроллерах, у меня постоянно были готовые платы, которые я использовал для отладки софта - их же я использовал и для обучения. Группе выдавалось задание, они писали программу, прошивали в плату, я по индикаторам и кнопкам принимал итоги. Т.е. весь цикл разработки софта люди проходили на практике. Сейчас стендов для разработки/отладки еще больше и они в разы доступнее.
Когда я писал про "инженеров ОВЕНа" - я просто выражал удивление. Вполне возможно множества, вызывающие мое удивление, пересекаются - не вижу тут противоречия.
Не позволю!
Я приводил конкретные примеры как это поможет с обычными ОЛ проектами: формулы, итеративные вычисления (==ПИД с автонастройкой), автоматическое тестирование.
И, вполне вероятно, добавление подобного должно быть безболезненным для ОЛ.
Вариация же "добавить C" и более сложна в реализации, и менее надёжна, и непонятно какую задачу решает.
Как это позволит решить что-нибудь из АСУТП области?Даёшь кроссплатформенный тулчейн, который можно прикрутить к любой из распространенных сред разработки, чтобы ни один программист обделенным не ушел...
Если в Новосибирске, приходи 4-го апреля на https://2017.jbreak.ru/ -- расскажу почему C для ПЛК это боль.
Ваши права
