И это послужило тому, что ST основан на Pascal?Сообщение от Игорюня
Вот уж вряд ли.
Где Pascal и где C сейчас.
И это послужило тому, что ST основан на Pascal?
Вот уж вряд ли.
Где Pascal и где C сейчас.
В те времена его очень плотно учили в институтах.
Совсем нет.
Сделайте 3-ю и последнюю попытку.
Если не удастся, я объясню.
P.S. Доп намек дал Игорюня.
Structured Text is a very powerful highlevel modern programming language with its roots in Ada, Pascal and “C”
Вот такая фраза копипастой переходит из одной книги в другую.
Получается, что в основу положен и Pascal и C.
Давайте свою теорию.
Повторяю еще раз. Никогда не приводите цитаты и фамилии "авторитетов". Это не прилично. Приводите свои мысли. Учитесь рассуждать, размышлять.
А теперь по делу.
Один мой знакомый профессиональный программист сказал хорошую фразу. "На Паскале можно писать откинувшись в кресле одной левой. С, если писать на С в стиле С, а не Паскаля, что глупо, заставляет всегда быть в стойке." Я с ним полностью согласен. Так, для справки, я когдато писал и на Паскале (DOS, Win16) и С (DOS, Netware), так что не совсем дилетант.
Системы программирования ПЛК и ПР разрабатываются не для профессиональных программистов (они пишут сами системы, драйвера, обработчики....) а для инженеров-прикладников. Специалистов в конкретной предметной области. И проще научить прикладника какомуто программированию, чем из программиста сделать прикладника. Поэтому вот так.
Поэтому Паскаль в КДС (МЭК ******)
Поэтому ФБД для ПР и КДС - схемотехнику и прочему инженеру, работающему со схемами он ближе.
Поэтому и LD в ПР - он близок специалистам-релейщикам (релейная защита и автоматика и подобные специальности)
Поэтому для них чужд С и все ваши изыски. Поэтому они будут править текст в ручную, а не пользоваться регулярными выражениями при поиске-замене.
Конкретно Вам могу посоветовать написать в ОВЕН с просьбой открыть протокол заливки проги и прошивки в конкретное ПР. Схему ПР. И т.п. Естественно, под договор о нераспространении. И создавайте свою среду. Почему нет? Были (а может и остались) у ОВЕНа ПЛК с линуксом для ОЕМщиков. Но это решается не на форуме.
Я бы сказал, что вы тут сами ссылаетесь "на авторитета", но не суть
Это вообще-то мутная фраза.
Я не буду защищать C (без проблем могу писать на нём, сильно не люблю этот язык за море "undefined behavior"), но и ST недалеко ушёл.
Например, текущий ST вообще невозможно тестировать. Вернее, можно, но для этого нужно заплатить 1500 евро за их test manager (или как он у КДС называется). Жаба не позволяет.
Каким бы плохим C не был, для программ на C можно написать автотесты, и это будет хоть какая-то опора.
В ST всё пишется на интуитивном уровне, и фактически в голове приходится держать все краевые случаи.
Нет возможности просто взять, и проверить что выдаст код на конкретных входах.
http://mbeddr.com/ делают систему программирования микроконтроллеров на подмножестве C.
И не просто делают, а ей активно пользуются.
Из интересного, у них есть механизмы формальной верификации кода: https://vimeo.com/78422792
Например, указываешь, что "после помещения элемента в стек он должен оказаться непустым", и система сама (без написания тестовых методов) находит случай, когда это правило нарушается (если нарушается).
Это я не к тому, что "надо продвигать C программирование в массы", а к тому, что и на C можно ого-го какую штуку сделать.
Тут вы несомненно правы.
Помесь Ada, Pascal, и С.
Разница FBD vs LD это разница школ. В США все запали на LD, у нас на FBD, не более.
Вот неужели y0+(y1-y0)/(x1-x0)*(x-x0) записать в виде блоков проще, чем в виде одного блока и упомянутого текста внутри?
В текстовом виде править гораздо проще: скобку переставил, слагаемые переставил и т.п. В схемном виде менять расстановку скобок это ад.
Вот специально не хотел linux, т.к. надёжность linux непойми какая. Ну, вернее, надёжность коробочки с linux'ом.
Тут скорее дело в целевой аудитории, на которую направлен продукт.
К примеру обсуждал я этот вопрос с разработчиками ЗБВ, так вот исходят, вкладываясь в ФБД,
из того, что большей части юзеров и блоки-то соединить под силу с огромным трудом..
А ST- вообще темный лес.
Свою среду ,не зная особенностей железа ,не будучи инженером прикладником ???? что то страшное может получится ,да же если реализовать ST ,без фдб на ПР...Че то я сочкую (С)
электронщик до мозга костей и не только
Не угадали. У меня специальность "прикладная математика и физика". Диплом не красный, так что всё норм будет.
Ближе к народу надо быть!
Здесь Вы не поняли человека. Под прикладником - он имел ввиду реального инженера с опытом работы на действующем оборудовании.
Только человек знакомый с проблематикой промышленного производства (полевой уровень), с правилами безопасного ведения работ и т.п., может корректно написать программное для ПЛК, и всего что с этим связано!
Дилетанты от "МГУ" и прочих Вузов - могут лишь выступать консультантами, или выполнять часть работ по конкретным тех.заданиям. Не дай боже, они станут писать программное для ПЛК, и всего что с ними связано!
Оторванные руки, упавшие грузоподъёмные, взрывы на предприятиях и смертельные случаи нам гарантированны. А простые инженера, не являются гениями языков программирования высокого уровня. Вот для них и существуют такие языки, что так не нравятся истинным программистам. Ближе к народу надо быть!
Ваши права
