leon78 писал(а): 1. ST выполняется быстрее FBD. Если не предусматривать специальных мер, постоянно выполняются все блоки FBD, даже если по алгоритму в данный момент времени они не нужны. В ST выполняются только те части программы, которые должны выполниться по алгоритму.
2. Память данных для ST меньше, чем для FBD. Дело в том, что в ST один экземпляр функционального блока можно вызвать сколько угодно раз. В FBD для каждого вызова надо делать свой экземпляр.
То что вы описываете это особенности "железки" конкретного производителя (а иногда даже и серии контроллера),без указания которого ваши советы "тень на плетень". Я например знаю несколько разных контроллеров в которых программа на ST занимает больше места, чем на LD, а использование FB одинакого влияет на объем программы. Ну, и про быстродействие тут тоже много чего интересного бывает, но в привязке к конкретной железке.
leon78 писал(а): 3. В FBD нельзя сделать нормальные циклы.
Задачи в плк и так циклические.
leon78 писал(а):4. В ST намного легче реализовать многие вещи, чем в FBD.
А какие-то в FBD (или мы CFC говорим?)... Старый спор какой из 5 языков лучше, стал сродни спору кто лучше: блондинки, шатенки или рыжие.
Авторы ТЗ, с которыми я работаю, не имеют права жаловаться на дороги, ЖКХ, бюрократию и правительство.
Просто leon оказался очередным программистом и не представляет простоту языка LD. Я знаю много языков, в том числе объектно-ориентированные, но в дискретно-логических задачах лучше LD ничего нет! :) LD формирует особое мышление, которое облегчает программирование.
Конечно все зависит от конкретной реализации системы программирования. У нас на эту тему написано не так много книг. Найдите пожалуйста книгу Петрова и посмотрите то место, где один и тот же алгоритм написан на разных языках. Вы будете очень удивлены :).
Михайло писал(а):LD формирует особое мышление, которое облегчает программирование.
Давно уже заметил, что и ФБД и ЛД одевает на программистов шоры и им тежело решить даже простую задачу под которую этот язык не заточен.
PS. Для тех кому лень читать: после компиляции на разных языках обьем программы получился одинаков и выполнялся за одно время. (Это кроме SFC).
Циклы кстати реализованы в ФБД у Круга.
cde писал(а): PS. Для тех кому лень читать: после компиляции на разных языках обьем программы получился одинаков и выполнялся за одно время. (Это кроме SFC).
Предложение надо было начать с фразы: В Codesys... Или у вас есть такие данные хотя бы по ПЛК 5 крупнейших производителей контроллеров?
Авторы ТЗ, с которыми я работаю, не имеют права жаловаться на дороги, ЖКХ, бюрократию и правительство.
Точно по Сименсу (были моменты экспериментов): На первом месте, конечно STL. На втором, как не странно, SCL. Причем, если СЕРЬЕЗНО не заняться оптимизацией, то SCL выигрывает! Остальные безнадежно отстают с примерно одинаковым результатом. Только версии программ после SR4 надо брать...
Но это только по объему кода. Т.к. компилятор очень любит использовать косвенную адресацию где не надо, то по скорости, думаю, STL будет лучше.
З.Ы. Прошу прощения за использование симановских обозначений языков.
З.З.Ы. Прения и мерения длинны языка - ИМХО очередной бесконечный холивар...
cde писал(а):Данных нет и искать мне их как то лень. Кривые ручки могут замедлить контроллер значительно сильнее.
Кстати, вы могли бы привести данные по Омрон
Вам лень искать, а у меня нет времени писать доклад под сотню страниц об особенностях использования языков плк. У меня, кстати, не только по Омрону данные имеются. Только вот без структирирования и четкого описания выкладывать эти данные в открытую это "кормить горе продавцов".
Авторы ТЗ, с которыми я работаю, не имеют права жаловаться на дороги, ЖКХ, бюрократию и правительство.
Механизм выдачи команд верхим уровнем контроллеру можно сделать многими способами. Предлагаю следующий вариант (упрощенно):
1. Договариваемся, что команда - эта 16-ти битный регистр.
2. Договариваемся о кодировке, например:
биты 15-8 - число 16#00 - 16#FF - код технологического объекта (задвижка №10.5.4, насос №18, ...)
биты 7-4 - число 16#0 - 16#F - код команды (открыть, закрыть, пустить, ...)
биты 0-3 - число 16#0 - 16#F - код "источника команды", т.е. номер АРМа или панели, откуда выдана команда
3. Заводим в контроллере 16 регистров, в которые "источники команд" 16#0 - 16#F могут писать команды.
4. Заводим кольцевой буфер размером например 16 регистров.
5. Заводим переменную типа WORD, в которой храниться код команды, исполняемой программой на данном скане контроллера. Эта переменная подается на все DFB-блоки или куски программы, где должна выполняться какая-то команда. Они по битам 15-8 должны определять, их эта команда, и выполнять ее.
6. Пишем в ПЛК обработчик команд:
При появлении новой команды она переписывается в кольцевой буфер, значение в регистре команды обнуляется;
При появлении в кольцевом буфере команд самая первая пришедшая забирается из буфера и записывается в переменную из п.5.
Хард - это то, что можно швырнуть об стенку, а софт - это то, что можно лишь обматерить.
Михайло писал(а):Просто leon оказался очередным программистом и не представляет простоту языка LD. Я знаю много языков, в том числе объектно-ориентированные, но в дискретно-логических задачах лучше LD ничего нет! :) LD формирует особое мышление, которое облегчает программирование.
Вам приходилось иметь дело с программой на LD или FBD, в которой порядка 3000 каналов ввода-вывода?
Хард - это то, что можно швырнуть об стенку, а софт - это то, что можно лишь обматерить.
leon78 писал(а): Вам приходилось иметь дело с программой на LD или FBD, в которой порядка 3000 каналов ввода-вывода?
Мне приходилось/придеться разбираться с программами на LD c ~2000 вх/вых. Ни чего страшного, бубен не требуется, умение читать электро схемы приветствуется. Программа разбита на задачи, внутри задач идет деление LD секциями по узлам системы. На узел получается LD стр 5 А4 макс.
Хотя я не поклонник решений, где "3000 каналов" запихиваются в один процессор.
leon78 писал(а):А как же Переменная "i"! 26 лет на рынке счётчиков!???
А? Вы о чем?
Авторы ТЗ, с которыми я работаю, не имеют права жаловаться на дороги, ЖКХ, бюрократию и правительство.
Я не имел дела с такими большими программами. Но не уверен, что каждый бит влияет на значение остальных 2999 бит! Такое мозгу человека непостижимо!
Группу из 3000 битов, можно разбить примерно на 1000 групп примерно по 3 бита в каждой, и они не взаимосвязаны, а значит могут легко запрограммированы в LD. :)
Зачем переменные i, команды while, for и прочее, если есть счетчики (counters)?
Представьте: заниматься наладкой 3000 датчиков и исполнительных механизмов единовременно... Один датчик выйдет из строя - придется останавливать остальные 2999 микрообъектов...
Михайло писал(а):
Группу из 3000 битов, можно разбить примерно на 1000 групп примерно по 3 бита в каждой...
Как-то в институте нам преподаватель вывел формулу и считал подставив значения. Глядя на доску он вслух говорил: "... таааак, это сокращается, остаётся дробь, в числителе... ага.... получаем 60 поделить на 3, это будет приблизительно 20, ну а (восторженно) бОльшей точности нам сейчас и не требуется!"
:)
По вопросам работы Форума можно обратиться по этим контактам.
leon78 писал(а):Да я о том, что цикл сканирования контроллера и циклы FOR или WHILE это несколько разные вещи
А для чего вы используете циклы, которые должны выполняться за 1 скан контроллера? И сколько повторений нужно? И как это у вас влияет на скан контроллера?
Авторы ТЗ, с которыми я работаю, не имеют права жаловаться на дороги, ЖКХ, бюрократию и правительство.
leon78 писал(а):Да я о том, что цикл сканирования контроллера и циклы FOR или WHILE это несколько разные вещи
А для чего вы используете циклы, которые должны выполняться за 1 скан контроллера? И сколько повторений нужно? И как это у вас влияет на скан контроллера?
Я бы переформулировал вопрос: А для чего Вы используете циклы?
По вопросам работы Форума можно обратиться по этим контактам.
Вот и напишите это как совет, противоречаший совету 16#0000
Действительно спорное, только не совсем в поддержку Вам. Уже лет 7 использую язык С для программирования контроллеров (правда - это B&R описание, если интересно есть на http://www.sensorlink.ru). Соглашусь с Вами что ST читабельнее LD. В свое время на Сименсе приверженцу LD показал, что код на ST раза в 3 меньше места занимает. И если LD занял 3 экрана, то LD - только 1. Но надо признать, что все зависит от образования, если вы инженер, то схемы Вам читать намного проще, чем мне как прграммисту код на С. Насчет памяти и функций, для серьезных и "мощных" контроллеров нет особой разницы. Если даже на слабеньких мотороллах B&R справлялся на ура с 30 и более ПИД регуляторами на С и кучей своих функций, то с появлением Интела такие вопросы даже не возникают. Насчет документирования отвечу, практически у всех при внесении изменений в код добавления в документацию сильно опаздывают и, соответственно, другому разобраться может быть даже сложнее с несоответствующей документацией, чем без нее.
leon78 писал(а):Никто не хочет меня поддержать, продолжаю сам. Буду стараться дополнять список советов при наличии времени.
5. Не храните булевские переменные для чтения ЧМИ - храните биты в регистрах. Помните, что 2 булевские переменные занимают целый 16-битный регистр!
6. Если есть флаги состояния или режима работы оборудования, не храните их поотдельности. Пример:
хранить сочетание бит 00 - закрыта, 01 - промежуток, 10 - открыта, 11 - неисправность намного лучше, чем хранить 4 независимых бита на каждое состояние.
5. - это видимо особенность Вашего PLC.
6. Исходя из 5 я бы посоветовал уже сразу ввести состояния 0, 1, 2, 3, 4, ... Причем каждое состояние описать в виде констант Close, Open и т.п. Тогда код будет более читабельный.
Можно, только я там разделов кучу наделал. Хочу, чтобы не форум в полном смысле слова получился, а учебник для начинающих с куче разных мнений и методов. Чтобы человек смог взвесить все "за" и "против" какого-то варианта решения.
Хард - это то, что можно швырнуть об стенку, а софт - это то, что можно лишь обматерить.
leon78 писал(а):Можно, только я там тем кучу наделал. Хочу, чтобы не форум в полном смысле слова получился
Да, но технически ведь сделано на том же самом PHPbb, что и здесь :) Стало быть всё зависит только от оформления. На torrents.ru или на 4pda.ru - видели как F.A.Q. оформлены? А там - движки с тем же функционалом.
В общем, смотрите сами. Отдельный форум создать можно, в нём - те же подфорумы и темы как обычно, а дальше - только руки. Нет - так нет, дело Ваше, мы на Вас ссылку дадим тогда. Просто наш форум уже довольно раскрученный (смотрю по посещаемости).
По вопросам работы Форума можно обратиться по этим контактам.
это все конечно прелесть спорить какой язык удобнее, каждому свое не все блоки удобно писать в STL, главно не забывать оставлять коменты,для тех кто придет после вас.еще бы не забыть продублировать.
это все конечно прелесть спорить какой язык удобнее, каждому свое не все блоки удобно писать в STL, главно не забывать оставлять коменты,для тех кто придет после вас.еще бы не забыть продублировать.