Ответ не правильный.При наличии макросов остается хорошая читаемость проекта с чилом элементов и ФБ более 100.Любым инструментом нужно хорошо владеть ,а это приходит с опытом ,а не бесконечной говорильней .
Для исключения гонок и наоборот для их пременения (в сдвигающих регистрах ,стеках) используются явные связи.
электронщик до мозга костей и не только
Ага, значит сначала нам говорят, что ПР - это реле и предназначено для замены релейных схем, а как только прибегает релейщик и говорит, что здесь был бы уместен язык описания релейных схем, тут-же оказывается что оно предназначено для электронщиков))
А электронщики в свою очередь, крайне редко используют реле, предпочитая транзисторы, симисторы, оптопары, операционные усилители и микроконтроллеры, которые они программируют на си.
Концепция "программируемого реле" - это какой-то самообман). Сколько вообще тем на форумах ОЛ-ПР посвящены замене релейных схем?)
Стоит всерьез задуматься, для чего-же на самом деле предназначены эти приборы, либо для чего их применяют в большинстве случаев и сделать упор на поддержку их реального применения.
Сейчас я так подозреваю, ПР занимает нишу бюджетных ПЛК, где они замечательно смотрятся. Возможно серьезные улучшения с привлечением финансов не имеют смысла, ибо ударят в конечном итоге по цене и прибор вылетит из бюджетного сегмента.
У меня тот же номер (по старому классификатору, потом перешли на 5-ти значную нумерацию), но специальность - инженер-системотехник.
Давным-давно один мой знакомый профессиональный программист сказал следующее. "На Паскале пожно писать откинувшись в кресле одной левой. С, если писать на нем в стиле С, а не Паскаля, заставляет всегда быть в тонусе" И я с ним согласен.
Я начинал программировать на Паскале, потом переключился на С, т.к. он больше распространен для микроконтроллеров. Не помню никаких проблем с освоением или размещением тела в кресле. На самом деле существует некий алгоритм программы, который более или менее удобно реализовать на том или ином языке. В этом вопросе Паскаль и С практически не отличаются, только синтаксисом, главным образом. Причем даже тот факт что С вроде имеет больше возможностей по работе с "железом", не так очевиден, на фоне того, что например язык VHDL, применяемый для программирования ПЛИС по синтаксису ближе к Паскалю (правда есть подобный язык Verilog - этот ближе к С). Как вам кстати VHDL? Тоже вполне себе стандарт, предназначен для описания аппаратуры - необязательно именно С.
Инженерный образец ПР200 -- конец декабря 2014: http://www.owen.ru/forum/showthread....l=1#post157505
Тогда же и очередные обсуждения о необходимости online режима:
Воз, очевидно, никуда не ездил.
Раньше (с апреля 2016) я предлагал возможности "автоматического тестирования программ" и ST через интеграцию ОЛ со сторонними программами (эта тема, и смежная про "экспорт-импорт самих ОЛ программ в машиночитаемом виде").
Но сейчас стало видно, что "электронщики" протестуют, а верхи либо не понимают, либо осознанно игнорируют.
Я теперь тоже буду поддерживать тех, кто говорит, что развитие ОЛ вредно. Как-никак, есть шанс испортить шикарный и идеальный почти во всех отношениях софт.
Последний раз редактировалось Владимир Ситников; 17.03.2017 в 10:30.
Для этого нужно найти первую версию ОЛ и посмотреть её возможности. Потом у пользователей появились свои хотелки, которые разработчики стали выполнять, ну и как говорится в поговорке, "Аппетит приходит во время еды", дальше больше, то дайте аналоговые входы, то дайте макросы, теперь дайте другие языки программирования.
Раньше помимо ОЛ была облегчённая версия программы, для составления самых простых алгоритмов, вся программа словами описывалась, вот это жесть была, но я успел и на ней несколько программ сделать, короче кто хочет программу буквами составлять эту программу воскресить, сразу все разговоры стихнут!
Последний раз редактировалось Сергей0308; 17.03.2017 в 10:51.
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.