Почему я не буржуин.. толстый, в цилиндре...
Наверно форум не тот.
Вид для печати
Почему я не буржуин.. толстый, в цилиндре...
Наверно форум не тот.
Уважаемые господа специалисты - предлагаю топикстартеру тему с флудом перенести в курилку... самостоятельно... :)
Если кому интересно - мои 5 копеек:
Очень люблю и рекомендую читать старый русский фольклор и сказки.
Например: "каждый кулик свое болото хвалит".
На курсах преподается на CFC так как большинство обучающихся начинают программировать "с нуля", а не приходя из софтверных компаний, где писали на C#, Delfi и остальных "мегапафосных" системах. "Програмеры" обычно учаться сами, но именно от них в начале пути работы с ПЛК слышится: "херня эти ваши контроллеры - не правильно они циклы выполняют", по тому как не разобрались в принципах работы ПЛК, который КАРДИНАЛЬНО отличается от принципов работы программ на ПК.
CODESYS создан универсальным, чтобы удовлетворить всех возможных специалистов, которые будут с ним работать.
Программист Вы изначально - ну так удачи - пишите на st (pascal). И структуры и массивы, case Вам в помощь.
Если Вы от электрики - милости просим - LD (релейная схема).
Если получили базовое образование (как я) АСУ ТП - так понятнее и удобнее всего CFC (FBD) и SFC. Поверьте мне - я на SFC за 1,5 минуты опишу "машиносостояние, условия переходов и пр." без всяких IF, case и прочих "ужасных и непонятных слов". И не понадобится 2 месяца на отладку, как это требуется классическим программистам :)
И уже при определенном опыте и приобретенных навыках начинаешь в проекте комбинировать программы на разных языках. Математику на st. Система безопасности котла оптимально и сильно быстрее пишется и отлаживается на LD. Условия состояний установки лучше всего на SFC. Все это пишется в виде "программ" или "функциональных блоков", которые уже собираются в финальную программу на CFC (для наглядности). Это и называется мастерством, которым, к сожалению обладают единицы.
Ну а тем, кто пока умеет работать и оптимально использовать только один язык - CODESYS представляет выбор из 5 языков.
Можно считать вопрос закрытым, или еще пофлудим? :)
З.Ы.: Обычно следующим шагом в таких спорах становится обсуждение "а зачем мне CODESYS - я и так хорош - дайте мне Linux и оставьте меня в покое" :)
Вот обидели сейчас про пафос и два месяца на др.языке,отличном от sfc
Если обидел кого - прошу прощения. Понятно, что для профессионала все гораздо быстрее. :)Цитата:
Сообщение от capzap
Ну утрировал немного для того, чтобы в полной мере дать представление о возможностях :)
Ох нифига себе... Был бы я троллем, гадко хихикал бы :D Название темы конечно попахивает холиваром, но тема заключалась всего в 2 конкретных вопросах (см 1й пост), на которые пока так никто и не ответил.
В курсе. Скажу больше, не только ПЛК, а вообще любая программа которая должна долго работать и на что-то реагировать - это непременно какой-то цикл. Не принимайте меня за школьника. Я из чистого энтузиазма писал программы по 8 тысяч строк (но для компа, игру), и всё работает без единого глючка. Так что с циклами как-нибудь слажу :o Давайте не будем флудить, остаются только 2 конкретных вопроса о графических языках: 1) как сделать цикл и 2) как быстро вставить условие на набор команд.Цитата:
А Вы в курсе, что ПЛК работает в цикле? Поэтому использовать FOR-NEXT или REPEAT-UNTIL надо очень аккуратно. Если в цикле программа задержится слишком долго произойдет перезагрузка ПЛК.
Ну я старался подробно объяснить. Продолжаем с цитатами: "...имеющий слух - услышит...". Хорошо, что Вы не троль. За это на форуме принято наказывать.
По существу вопросов.
Ну если в курсе, то должны понимать, что:
1. "Выполнить несколько раз в цикле" в разрезе ПЛК: надо использовать не for, а if. По тому как цикл уже организован. И Ваша задача не организовывать его, а включать и выключать из него нужные Вам вычисления. if uslovie<> ustavka then a:=a+1; end_if;
2. Для удобства ветвлений (организации условий перехода) можно использовать разные варианты. Это как реализация на st. Кто против? Тем более если Вам так удобнее. Это SFC - быстро и наглядно. Это операторы выбора при программировании на CFC, такие как sel, mul и другие операторы выборки и сравнения.
Вся прелесть, что выбор за Вами.
Напишите цикл на ST, конвертируйте в графический язык FBD и воссоздайте полученный результат в CFC , в чем проблема то?Цитата:
Сообщение от Boris_K
Слух имеется.Цитата:
Продолжаем с цитатами: "...имеющий слух - услышит..."
Нет, это не катит, это плохо. Это "канает" только для совсем уж простых программ. А в общем, в одном большом цикле (без вложения других циклов) всё не обработаешь.Цитата:
Выполнить несколько раз в цикле" в разрезе ПЛК: надо использовать не for, а if. По тому как цикл уже организован. И Ваша задача не организовывать его, а включать и выключать из него нужные Вам вычисления.
С помощью sel, mul и подобными можно обработать только одну выходную переменную. А если надо "заусловить" блок из 30 выражений, это придётся для каждого sel хреначить. Вот только и остаётся ST родимый.Цитата:
Это как реализация на st. Кто против? Тем более если Вам так удобнее. Это SFC - быстро и наглядно. Это операторы выбора при программировании на CFC, такие как sel, mul и другие операторы выборки и сравнения
Спасибо за совет, попробую. Конвертацию ещё не приходилось делать. Интересно будет увидеть результат. Вангую, что будет что-то страшное ;)Цитата:
Напишите цикл на ST, конвертируйте в графический язык FBD и воссоздайте полученный результат в CFC , в чем проблема то?
Ну так без фанатизма, если знаете досконально графические языки, адаптируете любой дикий кодЦитата:
Сообщение от Boris_K
Контроллер это не ПК. Тут мышление при программировании должно работать по-другому. Программу надо оптимизировать. Надо стараться не тормозить работу контроллера циклами, а наоборот разносить код по разным циклам, чтобы время цикла контроллера было по возможности минимальным.Цитата:
Сообщение от Boris_K
В плане оптимизации вы конечно правы. Но есть огромная куча примеров, когда обязательно нужен вложенный цикл. Чаще всего он прост и до тормозов ему далеко, но без него не обойтись. Чтобы не "квакать" бестолку, вот простой пример, "от балды":Цитата:
Контроллер это не ПК. Тут мышление при программировании должно работать по-другому. Программу надо оптимизировать. Надо стараться не тормозить работу контроллера циклами, а наоборот разносить код по разным циклам, чтобы время цикла контроллера было по возможности минимальным.
Допустим есть входная целочисленная переменная, и есть массив целочисленных элементов. Нам надо узнать количество элементов в этом массиве, которые больше этой входной переменной. И найденное их количество уже используется в следующих шагах программы, и требуется оно в каждом цикле ПЛК. Без цикла FOR-NEXT не обойтись. Как сами понимаете, примеры могут быть самые разные, и возникают они очень часто.
Поконвертировал тут из ST в другие языки цикл FOR и условный оператор с набором нескольких команд в теле. Получилось неплохо, правда в CFC конвертить нельзя, а интересовал именно он. По идее на нём цикл можно сделать с помощью обратной связи, но как тогда заставлять программу выйти из этого кольца, к следующим конструкциям?
есть джамп для этого, писал же нужно досканально знать CFC, если это не так то перейти на удобный языкЦитата:
Сообщение от Boris_K
ОК, я протупил немного, закольцовывая ничего хорошего не получишь. Там в CFC есть оператор перехода, на нём конечно можно. Хотя в обычных языках аналогичный оператор (GOTO) использовать не рекомендуется т. к. при злоупотреблении им код получается трудно читаемым, т. е. дурным тоном считается.
"Качество программного кода обратно пропорционально количеству операторов GOTO в нём"
Эдсгер Дейкстра
Да, именно так :) Чем меньше ГОУТУ, тем меньше "спагетти-кода". Хотя некоторые известные кодеры с этим не согласны.Цитата:
"Качество программного кода обратно пропорционально количеству операторов GOTO в нём"
Эдсгер Дейкстра
незнаю, что Вы понимаете под этим, собственно цикл for и подразумевает некоторое количество использований goto, а Ваш перебор цикла у меня получился минут за пять, восновном время потрачено на расположение элементовЦитата:
Сообщение от Boris_K
Моделирую ситуацию:
15 дискретных входов и 15 дискретных выходов.
Программа все входы перебирает и соотв что то пишет в выходы.
Алгоритм расхода времени:
Чтение всех входов;
Выполнение одного цикла программы;
Запись в выходы.
Итог!: программа обработает 15-й вход только спустя 15 циклов алгоритма расхода времени при отсутствии оператора For (то есть только использовав If), а на 15-м входе срабатывание уже в начале 1го цикла.
Время выполнения тела программы может быть существенным, плюс время на чтение запись входов выходов.
For же на первом цикле программы(да, затратив время контроллера на перебор всех данных с входов) обработает ВСЕ данные с входов.
Мне кажется, по времени, For !в данном случае! будет выгоднее. ИМХО)
Так то 15 выходов можно и ручками прописать)
Шашлык делали ? Так же все 30 выражений насаживаете на ENЦитата:
Сообщение от Boris_K
Можно изящней. Весь блок в макрос. В макросе, в начале, делаете вход (IF) и (IF)---o< RETURN>
А ничего что условие перехода - логическое ?Цитата:
ОК, я протупил немного, закольцовывая ничего хорошего не получишь. Там в CFC есть оператор перехода, на нём конечно можно.
Выходы здесь указаны просто для примера, на самом деле ситуация может быть самая разная.Цитата:
Сообщение от Amko
Я про то, что предлагают отказываться от FOR и переходить на что-то, вроде (пользуясь циклом самого ПЛК):
" if uslovie<> ustavka then a:=a+1; end_if; ".
Вот и представьте:
к примеру, есть 15 дискретных датчиков, они образуют массив.
Нужно в программе перебрать состояния всех 15-ти датчиков ( теперь уже элементов массива) и выполнить затем какие-либо операции в зависимости от их состояния.
Теперь задумайтесь:
в каком случае быстрее выполнится сама программа:
- если я в каждом цикле буду перебирать по одному элементу массива (на это уйдёт 15 циклов ПЛК);
- или же если я использую FOR и с его помощью я ЗА ОДИН ЦИКЛ ПЛК переберу ВСЕ элементы массива?
Это только один простенький примерчик насчет FOR.
А если элементов не 15, а 115?
Если датчиков 15 штук и требуется с ними сделать одинаковые действия - напишу ФБ, вызову ФБ 15 раз подряд. Не сломаюсь, и в дальнейшем проще разбираться.
Если датчиков 150 штук, в екселе макросом сделаю себе ST код на вызов всех 150 ФБшек, кину в отдельный блок и забуду ваще про их существование. Это если надо все за раз обрабатывать и прям в каждом цикле. Если можно обойтись, буду вызывать один ФБ в каждом цикле, на входе менять адрес датчика, за 150 вызовов ПЛК пройдусь по всем.
И смысл всех этих действ?Цитата:
Сообщение от Amko
Если все просто:
FOR I:=1 TO 115 DO
И всё.
Что такого ужасного в FOR?
И зачем, если он такой плохой и ужасный - его ввели в ST?
Видимо вопрос по поводу целесообразности введения FOR был риторическим? Я понятия не имею, зачем его ввели :)
Может у меня какая то forофобия, не знаю. Просто не вижу смысла останавливать работу ПЛК на некоторое время, если это не требуется процессом. В своей практике не сталкивался с тем, чтобы мне требовалось обрабатывать несколько сотен датчиков именно в каждом цикле, потому не боюсь размазывать их обработку на несколько циклов. Все таки про остальной код тоже не стоит забывать, надо и ему дать выполняться :)
Не пойму, что за формулировки "останавливать работу ПЛК"????? -> Сколько тактов тратит процессор на организацию цикла?
"остальное код, надо и ему дать выполняться" мне казалось все выполняется по шагам(определенный оператор занимает определенное количество тактов процессора), а сколько там в секунду тактов у проца, не подскажете...наверно я ошибаюсь:)
Для каждой конкретной задачи берется соотв оборудование и код! Может мне показалось, но по вашему, дисковая операционная система это гуд а винда масдай.
зы !Редко! комфорта удается добиться принципом все гениальное - просто. спс.
Да что ж спорит!Цитата:
Для каждой конкретной задачи берется соотв оборудование и код!
Показалось)Цитата:
Может мне показалось, но по вашему, дисковая операционная система это гуд а винда масдай.
Я хотел высказать, что запихивая много логики в цикл FOR мы увеличиваем цикл, тем самым снижаем быстродействие других процессов.
И поэтому вопрос - а оно надо? Стоит оно того, чтобы загружать ПЛК именно в каждом цикле?
Главное, не нарваться на пса времени!
Я говорил только про то, что GOTO в обычном понимании это просто переход к произвольной метке в программе, и именно поэтому его рекомендуют избегать. А цикл же FOR чётко обособлен в коде между словами FOR и END_FOR, и программа воспринимается легко и понятно.Цитата:
незнаю, что Вы понимаете под этим, собственно цикл for и подразумевает некоторое количество использований goto, а Ваш перебор цикла у меня получился минут за пять, восновном время потрачено на расположение элементов
Цикл ваш посмотрел. А теперь представьте как это будет на ST: 3 простых строки! И на написание - не 5 минут а секунд 30.
Есть же модуль статистики, где спокойно смотрится свободное время процессора в каждом такте ПЛК. Да и не так уж и грузит его среднестатистический цикл FOR, ибо работает он шустро.Цитата:
Я хотел высказать, что запихивая много логики в цикл FOR мы увеличиваем цикл, тем самым снижаем быстродействие других процессов.
И поэтому вопрос - а оно надо? Стоит оно того, чтобы загружать ПЛК именно в каждом цикле?
Ппц.
Википедия: Декларативное_программирование — LD, FBD, CFC
Википедия: Императивное_программирование — IL, SFC, ST
Когда хочется сказать глаголом, надо говорить глаголом. Когда хочется назвать существительным, надо называть существительным. Остальное — канцеляризм и косноязычие.
У меня всё.
В общем согласен. Только мне было бы очень интересно глянуть какой-нибудь пример, где графический язык (CFC например) оказывался бы реально удобнее текстового ST, то есть что-то, что делалось бы на графическом в разы быстрее чем на ST...Цитата:
Когда хочется сказать глаголом, надо говорить глаголом. Когда хочется назвать существительным, надо называть существительным. Остальное — канцеляризм и косноязычие.
в оскат посмотрите сетевую бибку, там в разделе демо все примеры на cfc, очень быстро накидать связи между различными блоками получится в графическом виде, чем писать текстовку и определять что куда вставить в качестве аргументаЦитата:
Сообщение от Boris_K
Он может читаться в разы быстрее, если программа и/или способности читателя к этому располагают. Что бы такое вспомнить... Ну, например, самосбрасывающиеся таймеры видно в CFC за километр. Или какие-нибудь каскадные структуры, где в графическом представлении сразу видно цепочки. Или распределение одного множества переменных по другому множеству. Да хоть что, у чего есть быстро узнаваемый визуальный паттерн, который не просвечивается в текстовом виде. См. также подпись capzap'а.Цитата:
где графический язык (CFC например) оказывался бы реально удобнее текстового ST, то есть что-то, что делалось бы на графическом в разы быстрее чем на ST...
Не знаю - посмотрел пример capzap'а. Пост #57.
Неудобочитаемо, ИМХО. Хотя, сам с CFC начинал.
ST - есть ST. Там читаешь - и всё сразу понятно.
Видимо, поэтому, Русский язык не стали в виде блоков реализовывать))). (Сравнение неудачное, но всё же).