qСообщение от vladimirisitnikov
1. Почему FSEL невозможно сделать в ОЛ? И Вы сами когда нибудь в машинных кодах работали?
2. Как вы себе представляете условный переход FBD?
3. Подцепите панель и отлаживайте.
q
1. Почему FSEL невозможно сделать в ОЛ? И Вы сами когда нибудь в машинных кодах работали?
2. Как вы себе представляете условный переход FBD?
3. Подцепите панель и отлаживайте.
2. Именно ровно так, как он реализован в КДС - через метки. Я использую и в FBD и в CFC.
Ближе к народу надо быть!
Здесь Вы не поняли человека. Под прикладником - он имел ввиду реального инженера с опытом работы на действующем оборудовании.
Только человек знакомый с проблематикой промышленного производства (полевой уровень), с правилами безопасного ведения работ и т.п., может корректно написать программное для ПЛК, и всего что с этим связано!
Дилетанты от "МГУ" и прочих Вузов - могут лишь выступать консультантами, или выполнять часть работ по конкретным тех.заданиям. Не дай боже, они станут писать программное для ПЛК, и всего что с ними связано!
Оторванные руки, упавшие грузоподъёмные, взрывы на предприятиях и смертельные случаи нам гарантированны. А простые инженера, не являются гениями языков программирования высокого уровня. Вот для них и существуют такие языки, что так не нравятся истинным программистам. Ближе к народу надо быть!
а я лично за, если бы можно было писать FBD на C# например, раз ОЛ на нем писан.
Я не говорю про основную программу, а именно блоки для библиотеки элементов.
Ведь внутри там все так же, есть переменные внутренние для его работы, есть внешние. да и внутри все одинаково. И он и в африке И и т.д.
А я согласен с автором темы.
Тот же мультиплексор вещественных чисел - четыре строчек кода на си.
В плане программных блоков мне нравится набор у сегнетика. У ПР200 легче с экраном работать, хотя возможности реагировать на клавиши в теле программы не хватает. Сброс аварий приходится делать через запись параметра в меню, и паралельно кнопку вешать для удобства.
Так и не понял в чем собственно сложность предусмотреть возможность программирования не через OL. В ядре ПР200 - STM32, эта штука например поддерживается средой Arduino и соответственно разработанными под Arduino совместимыми оболочками с программированием на релейной логике и FBD. Кому на чем удобнее, как говорится. Возможности у того же ПР200 очень неплохие, а среда программирования ограничивает его использование на уровне управления воротами или заполнения бака. Возьмешься что посложнее делать и потрахаешься. Вместо того чтобы написать пару строк, надо всякие хитрости придумывать.
Когда мне в первый раз попал в руки ПР200, я про себя возмутился тем, что вместо пары строчек ST приходится городить паутину из блоков и связей, произвольным образом расползающихся по экрану. А когда немного с ПР повозился, нашёл объяснение, в чём состояла авторская задумка. Период исполнения программы строго 1 мсек и программа выполняется линейно, оператор за оператором. Если дать пользователю ST, в программе могут появиться циклы и периодичность исполнения окажется под вопросом. А вот почему целочисленные переменные только беззнаковые я понять не смог.
ОЛ макрос "очередь на N элементов" содержит столько операций, что даже в текущем ОЛ длительность выполнения цикла будет ого-го какая.
На ST это был бы массив, и количество операций от длины массива не зависело бы.
Более того, вычисления плавающей точки (fADD, fSUB, fGT) эмулируются (процессор ПР200 не умеет работать с дробными). Наверняка что-нибудь в духе 1мкс на пару операций с плавающей точкой.
Т.е. тысяча-две fADD и всё. В 1мсек программа уже не уложится.
Если вспомнить, что вместо fSEL любители создают макрос с двумя fMUL и fGT, то один только такой макрос уже отъедает 1мкс.
Уверен, если этот аргумент и был, то он явно где-то на последнем месте.
Владимиру Ситникову - Существует много ПЛК (в т.ч. и у нас) с Линуксом. Стреляет почему то только у крупных фирм-системных интеграторов, и то конечному пользователю поставляется CoDeSys-подобная или ещё более упрощенная среда разработки. Потому что кривая вхождения в профпрограммирование реального времени нереально крута. И никто не хочет пол года своей жизни тратить только на обучение этому. А потом еще и алгоритм писать! Все хотят соединить вход с выходом через логику, добавить мастеров/slave парой щелчков и не углубляться в написание драйверов, прерываний, нюансов межпроцессного и межпроцессорного обмена, ловить неописанные "фичи" оборудования, отлаживаясь по миганию светодиода и т.п.
А на ПР любой читавший в детстве справочник по радиоэлектронике после 2 дней обучения может писать нужные ему программы.
Причем что в ПР, что в ПЛК собственно среда разработки - это даже не 50% труда. А процентов 20-30 в коде и 5-7 в стоимости конечного продукта.
Если Вам хочется творить - приходите в крупную компанию-разработчик ПО для автоматизации, благо их много теперь.
И если Вы сумеете не перегореть за 1,5 года типичного цикла разработки нового изделия - Вы прочитаете свои теперешние посты с улыбкой.
Тролль-наседка, добрый, нежный и ласковый
Уже говорил, но повторюсь: я осознанно выбрал вариант без Linux, т.к. надёжность Linux решений для меня под сомнением.
Судить о КДС runtime, конечно, тоже приходится "на веру". Но стабильность/предсказуемость Linux под вопросом. Масса примеров, когда "внезапно взбесившийся modbus драйвер занимает 100% CPU и ПЛК шлёт пламенный привет временам отклика".
Во во. Именно по-этому и прошу чего-нибудь типа ST или IL в составе OwenLogic.
Так, чтобы можно было создавать программы для ПР, чтобы при этом не приходилось заниматься непотребством квадратиками ОЛ и с драйверами.
Обратите внимание: я не просил возможность заливать бинарный код.
Речь именно о промежуточном p-code (IL, ASM, без разницы как называть). Так, чтобы особенности железа решались прошивкой ОЛ/интерпретатором этого самого p-code, и чтобы при этом не приходилось заниматься непотребством при программировании в ОЛ. Например, чтобы можно было генерировать код в сторонних инструментах.
Да, так, всё верно.
Обсуждаемая проблема в текущей теме состоит в том, что тому, кто читал книги чуть более двух дней, в рамках ОЛ будет тесно.
Могут быть проекты (и встречаются), где ограничивающим звеном будет не железо/время/мозги, а именно ОЛ. Именно это печально.
Например, я осознанно не стал выбирать ОЛ, т.к. программировать одними квадратиками это печаль.
Если бы я писал: "покажите формат прошивки, и я сделаю свою более лучшую", то я бы понял где нужно было смеяться.
В теме же вопрос про p-code / IL, и оно никак не связано с программированием реального, нереального или какого там ещё времени.
Вопрос просто про возможность интеграции ОЛ со сторонними генераторами программ.
Для ST, например, кто-то вообще в Excel программы генерирует по шаблону. В ОЛ такое никак, ведь в ОЛ можно только мышкой рисовать.
Последний раз редактировалось Владимир Ситников; 07.03.2017 в 20:16.
Ваши права
