Массивы в TIA Portal

[Star4e]

у нас даже стандарт принят - программы должны быть на LAD, т.к. у дежурных специалистов много разнотипных объектов, разные ПЛК, разные стили ПО .... но все равно не получается сохранить прозрачность даже цепочках формирования команд и опроса датчиков. причина - у всех фирм свои отработанные стили программирования .... недавно сдали проект - 90% на SCL .. и что делать для диагностики, только выводить все необходимые переменные в watch table

[Nicolayy]

Star4e, на SCL и должно быть всё. Или на STL. Всё остальное - это порнуха.

[VADR]

С чего вдруг? А по мне так всё по маrсимуму должно быть на CFC, LAD, FBD. SCL и STL - только по необходимости, то есть почти никогда.

[Nicolayy]

VADR, лично для меня это тоже самое, что мне предложили бы написать компьютерную программу не на С++ или С#, а в виде каких-то диаграмм или блоков нарисованных. Хотя я знаю людей, кто не был знаком с компьютерным программированием до того, как начал постепенно разбираться с ПЛК, вот у них STL и SCL вызывают отторжение. А был наоборот случай: в одной конторе программист такой был, который вообще с ПЛК не дружил, писал какое-то прикладное ПО и всё, его отправляли на объекты с одной задачей - прийти к шкафу автоматики, подключить ноут и настроить TeamViewer. А программы на LAD были. В 2015 году он съездил на объект с моей программой, написаной на SCL, пару раз по скайпу чо-то спросил у меня, и всё - дальше сам наладкой занимался, вносил изменения, т.е. он увидел знакомый паскалевский синтаксис и понял, что программы для ПЛК могут иметь вполне понятный вид, похожий на программы для ПК. По-моему, так оно и должно быть. Я могу предположить, зачем придуманы были FBD и LAD. Сомневаюсь, что это сделано от большой любви к электрикам, чтобы они что-то там программировали. Думаю, что это связано с тем, что реализация ST (SCL) при создании среды разработки просто сложнее, его для многих ПЛК нет, а написание на IL далеко не всегда такое приятное как на STL в Step7. Взять хотя бы контроллеры Delta, у них там IL - это просто сплошной текст как в "блокноте". Если между таким IL выбирать и LAD, то я выберу LAD, конечно.

[Star4e]

я по поводу наших дискуссий по языкам ПО вспомнил такой интересный язык, как LabView.... у нас есть довольно сложный проект на нем, простые вещи в этой среде понятны и даже красивы, но вот сложная программа это что-то типа программы на Делфи или Си, переложенная на блок-схемную реализацию ..... одни циклы вложенные один в другой в виде прямоугольников, закрывающих собой предыдущие, чего стоят .... :(

[Михайло]

Не стоит программистов сюда звать, здесь зарплаты не такие высокие, а циклы и массивы не так часто применяются. Не для них тут сфера. Поэтому LD и изредка SCL.
Как раз скоро буду писать нетипичную для АСУТП программу оптимальной укладки прямоугольников в полубесконечную полосу заданной ширины (некий подкласс задачи о рюкзаке)... Тут и алгоритмы сортировки понадобятся... Вот это для SCL.

[Nicolayy]

Не стоит программистов сюда звать... Не для них тут сфера...

Ужас какой. Программирование, которым занимаются не программисты...

[VADR]

Ужас какой. Программирование, которым занимаются не программисты...

Я вам больше скажу. В наши сети обычных ИТшных сетевиков тоже лучше не пускать. У них психология другая: отказ ЛВС на 3-5 минут - ничего страшного. А у нас иногда секунда недопустима. Оффтоп, конечно.
Антиоффтоп.
Я сам работаю в эксплуатации, большинство программ в контроллерах написаны не мной, но я обслуживаю объекты, где эти системы установлены. Работа с программами в основном заключается в поиске неисправностей/косяков/и т.п. Так вот мне удобнее открыть нужный модуль, перейти в режим онлайн-диагностики, и сразу увидеть приходящие/уходящие данные, их взаимосвязь и поведение в реальном времени. А вот ковыряться в циклах и искать, в каком месте в каком проходе была нужная цифирька, чему она была равна и куда теперь подевалась - это как-то... ну, была у нас пара разработчиков, которые, наверное, очень от икоты страдали, когда я их SCL разбирал.

[Nicolayy]

VADR, я Вам так скажу: любой программист знает, что разбираться в чужом коряво написанном коде порой сложнее, чем переписать всё с нуля. Если человек не заморачивается хорошим стилем программирования, читабельностью кода, не утруждает себя добавлением комментариев - то это не вопрос к языку программирования SCL

[Михайло]

Специалисты по разработке релейных и прочих логических схем круче всякого программиста. Представляешь, начертил схему, отдал ее в изготовление и потом она безошибочно работает?


А вы "программисты, программисты". Это люди, которые напишут некий код, потом еще сто раз перепишут, перекомпилируя и запуская каждый раз заново. У программистов постоянная работа над ошибками, а у электриков ошибок не бывает.

[Nicolayy]

Михайло, "программист" в инженерии - это смежная профессия. Программист не существует в вакууме, не понимая что он программирует и зачем. Если вы программируете на LAD или на чем угодно - значит, Вы тоже программист, даже если это и не основной род Вашей деятельности.

Программирование через нарисованные на экране линейные диаграммы - это не разработка реальных релейных схем, а просто абстракция, - ведь по факту весь этот псевдорелейный алгоритм после трансляции программы в машинный код превращается в тоже самое, во что превращается SCL - некий набор по-очереди выполняющихся команд, дизассемблируй его - и вот тебе STL в чистом виде. Настоящие релейные схемы работают совсем не так, там нет такой последовательности выполнения: по-простому говоря, если вы подключите две лампочки к источнику питания и подадите напряжение, то они загорятся вместе, а не так, как это происходит в алгоритме контроллера, который включит их обязательно по-очереди. Разница лишь в том, что SCL будет выполняться построчно, т.е. сначала слева направо, а затем сверху вниз, а релейные диаграммы - наоборот (не считая разбиения на network'и в Step7). Это такая квазиреальность, где эти полосочки между блоками превращаются в якобы связующий проводник для подобия электрического сигнала, вот только это не такой сигнал, и ведёт он себя иначе.

Помню, давно еще, когда мы на контроллерах LOGO на FBD программировали, у одного нашего товарища алгоритм неправильно выполнялся: релейный выход замыкался на какое-то мгновение, хотя была блокировка. Потом выяснилось, что сигнал блокировки "доходил" чуть позже просто из-за неправильной расстановки блоков на экране. Тоже самое было, когда я исправлял косяки в алгоритме чудо-контроллера Segnetics (который, кстати, можно программировать на С++, но производитель систем вентиляции решил, что FBD круче и тоже накосячил с расстановкой блоков на экране, из-за чего чуть не спалил контакторы при переключении звезда-треугольник).

Соответственно, когда Вы программируете на LAD или FBD, Вы всё равно получаете в итоге набор последовательно выполняемых команд. Так лучше писать эти команды в явном виде (STL) или хотя бы в явной последовательности на SCL.

[Михайло]

Я помню на одном из форумов вылез один программист: ему надо было некий подъемник запрограммировать на LOGO. Он в итоге просто обосрался и начал ругать все, но не себя. Си ему подайте или Паскаль, видите ли. А вы "полосочки, полосочки". Мышление тут другое.

[Nicolayy]

Мышление тут другое

Особое "мышление", чтоб LOGO запрограммировать? Это точно! Некоторые вещи, которые элементарно в пару строк реализуются на STL, на LAD приходится реализовывать прям-таки проявляя фантазию. Тут уже начинается не программирование, а прохождение квеста. ))

[Михайло]

Некоторые вещи да. И это циклы. Дело в том, что циклы в функциональном программировании (читай аналог FBD, а там и LD рядом) делаются через Map-Reduce-Filter, а в контроллерах этого нет. И не будет, так как далеко не каждый программист суется в функциональщину, а куда уж электрикам.

Я и программист, и электрик. Я люблю LD, у меня мышление позволяет на нем делать очень сложные вещи. Только не циклы. Они есть, но реализованы громоздко и как-то не в функциональном стиле, выбиваются.

[Nicolayy]

Я и программист, и электрик.

>>>>

"программист" в инженерии - это смежная профессия. Программист не существует в вакууме, не понимая что он программирует и зачем.

ч.т.д.

И да, циклы - это не есть хорошо, потому что это притормаживает время выполнения общего цикла программы. Это, кстати, тоже самое, что и в обычном прикладном программировании, где громоздкий цикл запросто "подвесит" программу. Поэтому в обоих этих случаях надо найти компромиссное решение. Т.е. если надо перебирать какой-то большой массив данных, то нужно уйти от цикла в его классическом представлении. И решение примерно одинаковое что для ПЛК, что для ПК. На ПК можно задействовать параллельные (поточные) вычисления или таймер (т.е. прерывание по времени по сути), на ПЛК можно использовать прерывания или же использовать просто сам основной цикл программы для перебора элементов (что еще проще в реализации). По большому счёту, это всё - одно и тоже.

P.S>
На самом деле, я не имел ввиду циклы, когда говорил о том, что LAD на LOGO заставляет порой осуществить "прохождение квеста". Я имел ввиду более простые даже вещи. Например, многократные присвоения. На LD, который представлен в LOGO (не говорю про Step7) у нас есть только один элемент на экране, который обозначает результат этой логической операции - бит (M) или (Q), мы не можем сколько угодно раз его дублировать на экране. Про FBD я вообще молчу - там нельзя дублировать даже входные величины - т.е. есть вот на экране квадратик {I1} - и тяни от него хоть тысячу линий, если тебе надо, но второго создать нельзя. Код усложняется. Именно код. Потому что, повторяю, это никакая не релейная схема - в LOGO там вообще классический интерпретатор, который всё превращает опять же в самый обычный машинный код, который не выполняется так, как выполняется настоящая релейная схема.


P.S2>
Да, я не спорю, что приезжая на объект, это очень удобно бывает порой: я быстро взламываю всем известными программами флешку контроллера S7-300, вытаскивая оттуда пароль, быстро делаю upload, быстро запускаю online - там в 90% случаев какой-то косяк в логических цепочках, их прекрасно видно что на LAD, что на FBD, минут 10 - и проблема решена. Деньги в кармане - я поехал. А местные операторы и руководство хлопают глазами, что заплатили столько денег за полчаса моей работы. В этом смысле я прекрасно пониманию, о чем вы все говорите, в том числе участник VADR. Но это не значит, что само по себе использование этих языков программирования в качестве некого стандарта оправдано. Это совсем не так. Для некоторых функций они удобны в использовании могут быть, это да. Как только начинаются математические вычисления, а иногда и из-за них косяки происходят, то ты видишь, что LAD и FBD - это всё, крах. Детские картиночки с контактиками, годящимися для систем вентиляции, загазованности или насосных станций (да и то, достаточно примитивных) заканчиваются и начинаются сложные технологические процессы, связанные с расчётами с кучей формул как по учебнику по физики, там эти блоки функциональные или этот LD - это просто смех вызывает.

[VADR]

Детские картиночки с контактиками, годящимися для систем вентиляции, загазованности или насосных станций (да и то, достаточно примитивных) заканчиваются и начинаются сложные технологические процессы,

И начинается CFC.

[Andreywys]

Контроллер - это входы и выходы. По сути, контроллер должен взять состояние входов, их обработать и отдать состояние выходов. Для этого как нельзя лучше подходит LAD\FBD. Для пошаговых операций лучше будет SFC, т.к. в LAD это будет выглядеть ужасно. Также пошаговые операции можно сделать и на STL. В STL удобно работать с данными, использовать косвенную адресацию. На SCL удобно писать математику, работать с данными, но когда нужно проверить состояние входов и на основании этого выдать состояние выходов - использовать SCL очень неудобно. Все эти if then else будут выглядеть громоздко, их отладка будет сложнее и в итоге скомпилируется это в более сложный и объемный код.
Подход, когда в контроллере не пишут программу, а программируют электросхему в случае с обработкой сигналов входов\выходов имхо более правильный. Программист же будет писать программу для обработки сигналов.

[Михайло]

Для пошаговых операций лучше будет CFC, т.к. в LAD это будет выглядеть ужасно.

SFC, а не CFC. CFC - это расширенный FBD у S7-300/400. Конечные автоматы (SFC) я прекрасно реализую в LD.

Также пошаговые операции можно сделать и на STL. В STL удобно работать с данными, использовать косвенную адресацию.

В S7-1200 несколько другие реалии. Абсолютно не вижу места для STL среди языков программирования. Есть LD/SCL, не хватает хорошего SFC (только не в том виде, что в Step7 Classic!).

[Andreywys]

SFC, а не CFC.

Опечатался. Имел ввиду SFC, как один из пятерки МЭК языков, S7-Graph у сименса.

Абсолютно не вижу места для STL среди языков программирования

Я, как раз считаю существенным недостатком отсутствие STL в 1200 линейке. На STL, как и на SCL, можно написать все, в отличие от LAD/FBD. Но на SCL это будет монстр. И если нужно сделать что-то простое и быстрое, что невозможно реализовать на LAD, то STL - лучший выбор.

[UNTK_RAA]

По мне так STL менее удобный, чем SCL. Просто раньше, в Step7 v5, он был опциональный, а поэтому не такой распространенный.
А сейчас, когда SCL входит в комплект языков TIA Portal, математику на нем и делаю. А LAD - для битовых операций.

Вообще "плохих" языков нет. Надо выбирать язык под конкретную задачу.

[Nicolayy]

На STL, как и на SCL, можно написать все, в отличие от LAD/FBD. Но на SCL это будет монстр.

Угу. Сразу вспомнил, как мы делали имитацию Instance DB на контроллерах S7-200. Ну, там же один общий Data Block и функциональных блоков (FB) как таковых нет, поэтому приходилось создавать простую функцию и резервировать области памяти под, скажем там, "условные DB", ну а потом указатели на эти области передавать в функцию при вызове, в начале функции копируя со смещением от этого указателя все рабочие параметры, а в конце обновляя текущие значения (которые как бы "static"). Получалось что-то типа FB - функция с квазиэкземплярными Data Block'ами. Представляю, как это всё "замечательно" выглядело бы на LAD/FBD )) Проще, наверно, застрелиться было бы, чем понять, что это и зачем сделано ))

[Михайло]

SCL в S7-1200 конфетка, а не монстр.

[VADR]

Вот читаю и думаю: это холивар или изящный троллинг? :)

[Nicolayy]

Вот читаю и думаю: это холивар или изящный троллинг? :)

+1

[Михайло]

Просто опыт работы в Step7 Classic никак нельзя распространять на TIA Portal. Здесь все по-другому! Я ж вижу, что вы не имели опыта.
Classic - это не Portal, S7-200 - это не S7-1200.