Аргументы в пользу и против IL, LD, FBD, ST...

[san]

[Alexander]

Ну, если оболочка нормальная (и контроллер нормальный), индексируйте, и берите следующую порцию данных. В чем проблема?

[san]

В продолжение темы. То что я вверху наваял в LAD для UNITY, не означает что это удобно. Для этой задачи (слишком громкое название) логичнее и удобнее и компактнее было бы использовать ST.

For counter:=1 to 10 do
A[counter]:=A[counter]+1.0;
end_for;

Я всего лишь хотел показать, что возможности и ограничения очень платформозависимые.

[san]

Ну, если оболочка нормальная (и контроллер нормальный), индексируйте, и берите следующую порцию данных. В чем проблема?

Вот и я об этом. Хорошие среды дают 5 языков с возможнстью миксования. Как то не поленюсь и попробую привести два скриншота для сравнения LD и ST, FBD и ST, в пользу графических языков. Прелести ST уже выплывают с верхнего скриншота. Повторюсь уже н-й раз: каждый язык хорош для своей задачи, если у выбраной платформы эти языки нормально реализованы.

[Alexander]

Странно, ведь давал уже сообщение, Буквально 15 минут назад. И по поводу того, что циклы элемкентарно обеспечиваются, и реализация индексации элементарно обеспечивается, в зависимости от воли производителя. И куда это делось? К кому претензии, модератор? Может я там кого-то матом назвал?

[Alexander]

Ничего не понял.

[san]

...цикл...индексации...

Может я там кого-то матом назвал?

:-)

[Alexander]

Каюсь :D

[san]

Вот, например, задача с концевиками. Найдите, почему не сработал result:
Вот онлайн режим на LD

И онлайн на ST,

Где проще и быстрее найти причину?
зелень в переменных - "TRUE"
красные - "FALSE"
П.С. Уже допустил одну ошибку в ST, вечер...блин. Исправил.

[Barsik]

ИМХО, тема выеденного гроша не стоит.. Когда я трудился на одну весьма известную европейскую компанию, там в качестве стандарта был FBD, но там где требовалась косвенная адресация и прочие ништяки, использовался IL. И надо сказать, ничего страшного, все весьма адекватно и понимаемо человеком который "только зашел".
С точки зрения наладчика главная проблема как найти то, что работает не правильно. Вот предыдущий оратор скриншот показал, на котором ясно видно, как не любят наладчиков программисты. Больше скажу, за такие имена переменных я пару раз бил морду некоторым программистам.. Потому что разобратся в проекте, в котором имена перемнных ограничены тремя символами (так было у меня, про один символ сказать даже нечего), абсолютно невозможно..
Короче, проблема не в языках, а в общей культуре разработки. Язык это только инструмент, и с учетом правил и ограничений каждый выберет то, что наиболее ему подходит.
Языки типа SCL может кому то нравятся, но для написания компактного эффективного кода ни разу не подходят. В IL я могу, скажем, прочитать байт, а потом манипулировать с отдельными битами, в SCL ничего подобного не получится..
А вообще тема из серии - кто сильнее кит или слон..

[san]

Вы мне уж морду то не бейте. :-) Я предстваляю как один человек юьет в ЛИЦО другого с криками: "бушь нормально переменные называть"!
Пример я наваял очень быстро, а то что переменные a и b...., Вы что хотели, если задача абсолютно не конкретная. Вы, Barsik, наверное с тех, которые LD, FBD и даже ST считают недоязыками.
Это Вы меня назвали программистом, аль наладчиком? Вам проще найти пробелму в тексте чем в графике? Да, причем в IL! Ну что ж, уверяю Вас, не все такие как Вы. По крайней мере один - точно не такой.

[Владимир Кузнецов]

Не забывайте также о том, что во многих (по райнгей мере всех мне известных) ПЛК крутится интерпритатор, который дает вам возможность в онлайн режиме менять программу.

Хотелось бы заметить, что возможность менять программу "на лету" не является прерогативой интерпретируемых сред. При должном подходе это возможно и для компилируемых. Например в Linux есть технология Ksplice, позволяющая применять обновления ядра без перезагрузки.

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

Можно ли повторить показанный вами пример с циклом в LAD у Сименса или получается что он плохо реализован?
Лично я тоже за миксование - структуру алгоритма лучше делать в графическом языке, а сложные моменты реализовывать на IL или ST и прятать внутрь блоков.
Но есть оголтелые любители LAD, которые призывают полностью отказаться от "неправославных" языков.
Кстати, Сименс со мной согласен - системные блоки сделаны на STL/SCL.

Вот, например, задача с концевиками. Где проще и быстрее найти причину?

Да я и не спорю, что в LD удобно наблюдать работу алгоритма в простых случаях.
Я к тому, что заявлять о 100% успехе такого подхода не корректно.
Есть ситуации, когда на экране кроме мельтешения ничего не увидишь.
Кстати, в ST тоже можно повысить наглядность онлайн режима, если грамотно подсвечивать код.
Просто разработчики не стали с этим заморачиваться.

[Владимир Кузнецов]

Больше скажу, за такие имена переменных я пару раз бил морду некоторым программистам. Потому что разобратся в проекте, в котором имена перемнных ограничены тремя символами (так было у меня, про один символ сказать даже нечего), абсолютно невозможно.

Это как раз пример некачественного программирования.
Одно из основополагающих требований в программировании - программа должна быть самодокументируемой. Алгоритм (и имена переменных) должен быть четким и понятным, а не таким, что бы приходилось постоянно обращаться к справочникам и таблицам.

[san]

Это как раз пример некачественного программирования.

А вот тут я первый раз обиделся. :-) Уважаемый Владимир. Для той задачи, которая используется в этом примере, это самое удачное название переменных, так как они сами по себе ничего не означают, а означает их состояние. А для того, чтоб показывать некачественное, покажите пожалуйста качественное. Давайте я придумаю для Вас задачку, а Вы ее наваете на CИ в любой удобной Вам платформе. Возможно посмотрев это решение я полностью поменяю свое мнение и о стиле программирования и о используемых языках. Пока это только слова, ничем не подтвержденные.

[san]

Хотелось бы заметить, что возможность менять программу "на лету" не является прерогативой интерпретируемых сред. При должном подходе это возможно и для компилируемых. Например в Linux есть технология Ksplice, позволяющая применять обновления ядра без перезагрузки.

Не буду спорить, но это тема не этого топика.

Можно ли повторить показанный вами пример с циклом в LAD у Сименса или получается что он плохо реализован?

Да при чем тут Сименс! (По моему я эту фразу уже где то писал). Как тема-то называется?

Но есть оголтелые любители LAD, которые призывают полностью отказаться от "неправославных" языков.
Кстати, Сименс со мной согласен - системные блоки сделаны на STL/SCL.

Есть сугубо "православные задачи" для которых очень подходят сугубо "православные языки". Кроме того, сами "православные служители" пользуются этими языками, дабы проще заниматься "чтением молитв". Как-то вспомнил наладчика, который приехал налаживать гомогенизатор какой-то немецкой конторы. Моя фраза "мы программы для ПЛК сами пишем" повергла его в легкое недоумение. В ихней конторе программеры пишут только один екзмепляр программы, а наладчики эту программу подстривают на объекте. Все наладчики должны это уметь. В другой фирме, в которой довелось подрабатывать, использовали только концептовский ФБД. Задачи там совсем другие, но они очень хорошо ложатся именно под ФБД.
Язык LD и FBD проще для наладчиков? - Конечно, но в очень большом круге задач он абсолютно достаточен. Кроме того, он в этих задачах удобнее в отладке.

Да я и не спорю, что в LD удобно наблюдать работу алгоритма в простых случаях.
Я к тому, что заявлять о 100% успехе такого подхода не корректно.
Есть ситуации, когда на экране кроме мельтешения ничего не увидишь.
Кстати, в ST тоже можно повысить наглядность онлайн режима, если грамотно подсвечивать код.
Просто разработчики не стали с этим заморачиваться.

Это Вы заявляли, что графические языки проигрывают текстовым, а я говорю, что все завист от задачи. Ваши частные случаи не говорят о правилах. Да, кстати, покажите пример грамотно подсвеченого кода в ST.

[Alexander]

"Да, кстати, покажите пример грамотно подсвеченого кода в ST."

Хотелось-бы тоже взглянуть. Заодно и понять, чем это поможет в отладке....

[Владимир Кузнецов]

А вот тут я первый раз обиделся.

Я говорил про те случаи, когда программисту "морду били", у вас же академический пример и к нему это не применимо.

а я говорю, что все завист от задачи

Да я тоже так говорю :)

Да, кстати, покажите пример грамотно подсвеченого кода в ST

Ну вот если бы среда подсветили код примерно так, то стало бы понятнее что мешает:

[san]

Непонял логику подсветки. В Юнити как-то понятно с 1-го раза, что и почему подсвечивается. Да, и я думал, что у Вас на примете какая-то конкретная среда есть, где ST подсвечиватеся так, что все станет на свои места.

[Владимир Кузнецов]

Непонял логику подсветки.

Я попытался подсветить зеленым не только переменные, но и операции, результат которых так же TRUE (главная причина, почему в примере с ST сразу не понятно что происходит).
Тогда становится сразу видно какие цепочки схлопнулись, а где застряло.
Реализации подобного я не видел (видимо в этом нет нужды), но мы ведь и не о конкретных средах говорим.
Вообще в текстовых языках не принято такие конструкции так городить - становится нечитаемо.
Я бы переписал хотя бы так:

Код: Выделить всё

result = 0;
if(b)
{
   if(!o && p)
   {
      if(h && b_int>2000 && !k && l && m) result = 1;
      if(e && a_int>1000 && n)
         if((c && !d) || (f && !g)) result = 1;
   }
}

и уже бы стало вполне понятно.

[san]

Такую же конструкцию и в ST можно сделать, но скорость нахождения точек разрыва для этой задачи ... думаю в LD все равно больше.
Вобще, конечно откровенно говоря для меня ST самый универсальный язык. Но есть вещи, которые лучше делать в LD, в FBD или в SFC. Так что сам спор какой язык лучше может быть только в контексте:
- конкретной задачи;
- конкретной платформы;
- персонала учавствующего в разработке;
- персонала учавствующего в пусконаладке;
- фирменного стиля;
- и ряда других криетриев.
Иначе, этот спор как то терятет смысл. ИМХО.

[Владимир Кузнецов]

Полностью поддерживаю :)
(и если посмотреть первое сообщение, то можно увидеть, что обратного я и не утверждал)