Pull to refresh

Comments 36

По вашему, страница текста хуже воспринимается, чем пара ватманов со связями? ЛИЧНО ДЛЯ МЕНЯ — весьма сомнительно
Большая проблема в том, что более простая программа на C++, на самом деле, требует знать больше. Чтобы вместо трёх строк
MyBuffer = MyPyatn[15-i];
MyPyatn[15-i] = MyPyatn[MyRand];
MyPyatn[MyRand] = MyBuffer;
написать одну
swap(MyPyatn[MyRand], MyPyatn[15-i]);
нужно как минимум знать о существовании алгоритма swap. А чтобы не дублировать кусок кода, выводящий поле — нужно знать о существовании функций… с другой стороны мне тяжело представить себе человека способного разобраться с тем, как работают макросы в FBD и не способного понять как устроены функции в C++ — но, возможно, в этой разнице и есть какая-то тайна…
Да, про swap(a,b); не знал. Теперь буду знать. И на самом деле таких вот тонкостей полно.
Что касается функций — опять таки вопрос синтаксиса. Чтобы ее прописать, нужно знать как ее объявить, что ей передать, что она возвращает и как ее вызвать. А на FBD это точно такой же блок как и операция ИЛИ. Поставил на поле, привязал «веревки» и все работает.
Возможно. Каждому свое.
Но уточним пару моментов:
1. В данном примере явно не «пара ватманов со связями». Вся программа умещается на А3.
2. Программа на «пару ватманов со связями» в текстовом виде будет явно не один лист. И даже не два. И не три.
3. Еще хотелось бы обратить внимание, но в данном примере на FBD вся программа это фактически повторение один в один 16 раз связки из одного макроса и семи простейших (сравнение, память, ИЛИ) блоков плюс еще полтора десятка простейших блоков обвязки.

Поэтому ваш вопрос касается явно утрированной ситуации.

Главное преимущество FBD — возможность по связям быстро проследить логику работы программы. Вот в подобной вещи я например разберусь без комментариев за пятнадцать минут. С комментариями минут за пять.

Ну и кроме того (в этом посте я в отличие от предыдущих не акцентировал на этом внимание), написать программу на FBD может любой человек, знакомый с основами логики (операции И, ИЛИ, НЕ) и примерно представляющий как работает счетчик и триггер. А чтобы написать подобную же программу на том же С нужно потратить кучу времени на гугленье основ синтаксиса, возможностей языка, реализаций тех или иных конструкций и т.д. и т.п. Т.е. решить эту задачу с ходу не получится.
Ну и кроме того (в этом посте я в отличие от предыдущих не акцентировал на этом внимание), написать программу на FBD может любой человек, знакомый с основами логики (операции И, ИЛИ, НЕ) и примерно представляющий как работает счетчик и триггер.
Да, но ведь это — весьма небольшой процент от всего населения. Вот и возникает вопрос: а много ли вообще в природе людей способных понять «как работает счетчик и триггер», но неспособных изучить «нормальный» язык программирования?
Главное преимущество FBD — возможность по связям быстро проследить логику работы программы.
Всё зависит от размеров оной программы. FBD, насколько я вижу, неплохо соотносится с «железом», он близок к тому же Verilogу. Ну отлично — возьмите небольшую программу, реализацию какого-нибудь 68k где-то на 50-100 тысяч элементов. Вы точно уверены, что в ней будет проще разобраться если это будет диаграмма на уж-не-знаю-сколько-ватманов, чем если это будет записано в текстовом виде?
По-моему мы с вами говорим о разных вещах совершенно. FBD это один из пяти языков программирования МЭК 61131.
Эти языки используются для так называемого «технологического» программирования микроконтроллеров.

Для каждой задачи один язык подходит больше, другой меньше. И конкретно в программировании в АСУ ТП я считаю, что FBD проще и нагляднее и удобнее всего остального. Это просто я делаю всякую ерунду типа игрушек т.к. узкоспециализированные алгоритмы управления техпроцессами вообще никому кроме пары десятков человек не интересны и непонятны.

Что касается понимания как работает счетчик или триггер или что значит сложение двух сигналов по И. Могу поспорить, что это за 15 минут можно объяснить это любому школьнику, после чего он из таких блоков сможет писать полноценные технологические программы. А вот основам того же языка С (или ST как что то похожее из МЭК 61131) за 15 минут вы никого не научите.
Могу поспорить, что это за 15 минут можно объяснить это любому школьнику,
В это — верю.
после чего он из таких блоков сможет писать полноценные технологические программы
А вот в это, извините — но не верю. Особенно в свете вот этого:
узкоспециализированные алгоритмы управления техпроцессами вообще никому кроме пары десятков человек не интересны и непонятны
Кобол со своими «x IS GREATER THAN y» тоже преследовал цель «быть понтяным всем и каждому», но оказалось, что это просто никому не нужно.
И конкретно в программировании в АСУ ТП я считаю, что FBD проще и нагляднее и удобнее всего остального.
Ну как раз тут всё просто: «в связке» есть ведь разные языки. Нужно просто посмотреть — как часто разные подходы используются. Если использование FBD растёт, а ST падает — значит вы правы, если наоборот — то неправы. Если вы этим занимаетесь, то, может быть, у вас есть статистика?
А вот в это, извините — но не верю. Особенно в свете вот этого:

Почему же? «Реализовать на FBD алгоритм» и «изучить технологию для дальнейшего написания алгоритмов» это совсем разные вещи. Второе нереально, а вот первое — без проблем.

Если вы этим занимаетесь, то, может быть, у вас есть статистика?

По моему личному опыту (возможно если сюда заглянут люди, непосредственно занимающиеся внедрением АСУ ТП в различных областях и на разных системах то они поправят/дополнят) процентов 80 всех программ АСУ ТП в области энергетики пишется на FBD. Еще 15% на ST. Остальные 5% на оставшиеся 3 языка.

И FBD популярен именно потому, что даже если кто-то другой наворотил в контроллере черт знает что, то разобраться что и как там работает при использовании FBD гораздо проще и быстрее, чем на каком-либо другом языке.
По моему личному опыту (возможно если сюда заглянут люди, непосредственно занимающиеся внедрением АСУ ТП в различных областях и на разных системах то они поправят/дополнят) процентов 80 всех программ АСУ ТП в области энергетики пишется на FBD. Еще 15% на ST. Остальные 5% на оставшиеся 3 языка.
Вот это — уже серьёзно. И показывает что у программистов — таки мозги реально в чём-то другие.
И FBD популярен именно потому, что даже если кто-то другой наворотил в контроллере черт знает что, то разобраться что и как там работает при использовании FBD гораздо проще и быстрее, чем на каком-либо другом языке.
Вот это-то и странно. Потому что у меня — впечатление ровно противоположное: когда я вижу все эти «безумные схемы», то у меня по первости никаких словей, кроме матерных в голове не возникает, а когда первое впечатление проходит и кроме «за что?», «им что — реально так удобнее?» в голове возникают другие мысли и я быстренько превращаю весь этот ужас в нормальный, «удобочитаемый» текстовый вид, после чего обычно проходит «понимание»: «ага… тут они гланды… автогеном… через жопу… но зачем?»…
«Реализовать на FBD алгоритм» и «изучить технологию для дальнейшего написания алгоритмов» это совсем разные вещи. Второе нереально, а вот первое — без проблем.
Ну не знаю. Я могу себе придумать примерно как реализовать какой-нибудь алгоритм на ST, но даже представить себе не могу нетривиальный алгоритм, который бы реализовывался на FBD. Ну то есть я представляю себе как на FBD реализовать, скажем, Жизнь, а поскольку та полна по Тьюрингу, то, понятно, там и любой другой алгоритм реализуется, но реализовывать алгоритм напрямую на FBD? Как он выглядеть-то должен, чтобы его «любой школьник» мог реализовать?

Ну вот, к примеру, если мы уж о пятнашках говорим: вот как на FBD можно реальзовать алгоритм, который бы не требовал нажимать на кнопки, а, скажем, просто нажал бы сколько-то кнопок и раcпутал бы исходную конфигурацию. Написать это на С или там на ST — я смогу, не проблема. Но на FBD?

И FBD популярен именно потому, что даже если кто-то другой наворотил в контроллере черт знает что, то разобраться что и как там работает при использовании FBD гораздо проще и быстрее, чем на каком-либо другом языке.
Вы это серьёзно? Если я сейчас через А* решу описанную выше задачку и переведу это решение на FBD — вы в нём разберётесь??? Это же жуть будет!
В том то и проблема. Когда рассматриваются примеры типа Hello World (а на FBD — элементарная логическая схема) то и там, и там все предельно просто. Когда же дело доходит до действительно сложных задач, в классических подходах к программированию возникает понимание, что одного знания языка недостаточно, человек узнает такие слова как «библиотека», «парадигма», «паттерн программирования» и т. д. Да все это требует времени на понимание, но в итоге затраты окупаются. В FBD же и подобных «языках» вместо всего этого возникают упомянутые «N листов ватмана», потому как на экране обозревать это — как наблюдать жизнь через замочную скважину.

К сожалению, имея некоторый опыт программирования, был вынужден 4 года заниматься программированием ПЛК «Siemens». Мне безумно жаль те годы, вычеркнутые из моей жизни.
Когда рассматриваются примеры типа Hello World (а на FBD — элементарная логическая схема) то и там, и там все предельно просто. Когда же дело доходит до действительно сложных задач...

Тут есть два момента:
1. Действительно сложную задачу нужно стараться сделать так, чтобы она получилась, образно говоря, из кучи маленьких кусочков типа «Hello, World». У нас сотрудники делали алгоритмы автоматического розжига котла целиком на FBD. Там контроль сотен параметров и управление сотней арматуры. Задача реально большая и сложная. Однако при рассмотрении она разбирается на много маленьких простых кусочков с основой из элементарных функций типа логики, триггеров и таймеров.
2. Важен порог вхождения стороннего человека. Есть на объекте технолог и в какой то момент что то в технологии поменялось. Этот технолог — он не гуру в программировании. Более того, он вообще никак с программированием не связан. Однако нужно обеспечить ему возможность влезть в программу контроллера и подправить ее в соответствии с изменившейся технологией. И сделать это нужно оперативно. Как вы считаете, что будет проще: ковыряться в текстовых исходниках, правя константы, ветки if и т.п. или найти несколько блоков проверки условий и задать на них новые значения?
У нас сотрудники делали алгоритмы автоматического розжига котла целиком на FBD. Там контроль сотен параметров и управление сотней арматуры. Задача реально большая и сложная.
Стоп. Откуда там взялась «сотня разнотипных параметров»? Или это были, условно говоря, сто датчиков температуры, сто датчиков давления и ещё десяток других датчиков? Сколько видов данных в обработке участовало? Потому что ведь только это влияет на сложность задачи: в задаче может быть вообще пяток датчиков, но при этом над ними будет строиться такая математическая модель, что для её обсчёта потребуются гигабайты памяти, а может быть и миллион датчиков, которые просто усредняются — тогда задача, в общем и целом — тривиальна.
Как вы считаете, что будет проще: ковыряться в текстовых исходниках, правя константы, ветки if и т.п. или найти несколько блоков проверки условий и задать на них новые значения?
Зависит от размеров задачи. Я когда говорил про небольшую программу, реализацию какого-нибудь 68k где-то на 50-100 тысяч элементов — это не было сарказмом. Программа подобного размера действительно программистами обычно воспринимается как «небольшая». Большая программа — это миллионы строк кода. Но судя по описанному выше, где задача с «сотнями параметров и с сотней арматуры» считается «большой и сложной» возникает ощущение, что мы вообще о задачах разных масштабов говорим…
возникает ощущение, что мы вообще о задачах разных масштабов говорим…

Конечно. Я с самого начала сказал что в технологическом программировании в АСУ ТП есть своя специфика. Просто в посте я не написал подробнее т.к. писал в предыдущих статьях и не хотел повторяться.
Откуда там взялась «сотня разнотипных параметров»?

Нет никакой сотни разнотипных параметров. Обычно это температура, давление, расход, уровень, положение и остальные по мелочи. Исполнительных механизмов тоже несколько видов: двигатель, задвижка да несколько разных типов клапанов. Однако количество датчиков и исполнительных механизмов напрямую влияет на сложность программы. И программа с несколькими сотнями датчиков и сотней арматурин уже довольно сложная штука.
Помимо порога вхождения важен еще и верхний порог, характеризующий возможности инструмента: управление тачкой освоить проще, чем управление автомобилем, но как бы Вы не совершенствовались в дальнейшем в виртуозности владения тачкой, производительность Вашего труда расти не будет.

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

Согласен. Поэтому когда мы разрабатывали эту систему, то все время присутствовала обратная связь в лице специалистов по проектированию и эксплуатации. И вот этот верхний порог подгонялся под их нужды и в итоге всех устраивал.
Разумеется при грамотной организации исходных текстов.

Вот оно, то самое «если». Если текст будет нормально написан. Если везде будут комменты. Если будут использованы стандартные приемы. Если (при большом проекте) будет более или менее логичная и понятная архитектура. И т.д.

А если нет?
А если нет?
А если нет — то людей, которые «это» сотворили нужно уволить и нанять других.

Собственно сама постановка задачи очень странная: зачем заставлять людей делать то, чего они делать не умеют и учиться не хотят? Вроде как у нас уже не СССР, принимать на работу тех, кого вам «распределили» не нужно.

Поэтому когда мы разрабатывали эту систему, то все время присутствовала обратная связь в лице специалистов по проектированию и эксплуатации. И вот этот верхний порог подгонялся под их нужды и в итоге всех устраивал.
Что очень и очень грустно. Это значит что вся система разрабатывалась не для того, чтобы успешно создать что-то, что будет конкурировать с пресловутыми «лучшими мировыми образцами», а для того, чтобы с ней могли работать существующие кадры.

Спасибо за то, что пояснили лично мне за что именно заплатил миллиарды пару лет назад Гугл — после ваших объяснений мне, наконец, стало ясно, что разработчики в огромном количестве отраслей искренне верят, что им дадут «досидеть до пенсии» на том багаже, который они получили много лет назад и который им и не очень хочется обновлять…

Интересно будет посмотреть как ситуация будет в будущем развиваться. Если IoT будет развиваться похожим на развитие мобильников курсом, то ещё несколько лет производители «позолоченных тачек» смогут устанавливать вам «планку» (как руководители разработки в Ericcson'е, Nokia, Siemens'е, и прочих всяких Sony и Panasonic'ов), а потом… потом их просто переподчинят. Людям со стороны, скорее всего. Впрочем большую часть — просто уволят.
А если нет — то людей, которые «это» сотворили нужно уволить и нанять других.

Экий вы шустрый. Всех уволить, набрать хороших. Очень напоминает высказывание наших чиновников, которые супер компетентные, супер эффективные и вообще профи. Просто с народом им не повезло. И надо всех уволить и набрать других.
Что очень и очень грустно.

Сколько патетики. Конечно хорошо, что люди переживают за будущее нашей страны. Но так трагично заламывать руки все же не стоит. Везде есть свои плюсы и минусы. Везде есть своя специфика работы. И не разбираясь серьезно в этом делать поспешные выводы неразумно т.к. высока вероятность ошибиться.
И показывает что у программистов — таки мозги реально в чём-то другие.

FBD пишется в основном для технологов. Но кстати и отладка проекта на объекте при непрерывных процессах на FBD гораздо проще чем на том же ST.
когда я вижу все эти «безумные схемы», то у меня по первости никаких словей, кроме матерных в голове не возникает

Это именно первое впечатление. Достаточно поковыряться минут 15-20 и все становится легко и понятно. Просто вы возможно привыкли к тому же С. Чувствуете там себя как рыба в воде. Разумеется первая реакция на совершенно другую непривычную вещь будет именно такой.
вы в нём разберётесь??? Это же жуть будет!

Это будет жуть, но в ней при правильном подходе будет несложно разобраться. И при хорошей структурированности программы думаю даже далекие от таких сложных алгоритмов люди, владеющие только азами логики и базовых алгоритмов, посидев и поковырявшись в программе поймут что к чему.
Это будет жуть, но в ней при правильном подходе будет несложно разобраться.
Вы это серьёзно? Вы сможете понять, где у меня в «мешанине проводов» находится очередь с приоритетами и как именно в ней кодируются позиции? Надо будет попробовать — но я не верю даже в то, что я сам смогу разобраться в том, что сотворю (вы что — думаете что я реально планирую писать что-то на FBD? конечно нет: если будет время то, разумеется, напишу генератор программ на FBD — а уж что он там нагенерит меня мало волновать будет), а вы хотите «разобраться в алгоритме» глядя на эту кашу.
Как пример — посмотрите мой самый первый пост. Там (внезапно) 9000 блоков. И что? Разве такое количество вызывает какие-то непреодолимые проблемы? В той программе можно минут за 20 разобраться от и до.

С другой стороны бывает «мешанина» из какой нибудь полусотни блоков. И сделаны они так, что там сам черт ногу сломит, пытаясь разобраться что к чему.

Т.е. все зависит от качества написания программ. Хотел программист сделать их удобными и понятными для всех или лепил как получится. И от языка это не сильно зависит. Вот вам пример из С:
Мешанина кода
if ((MyButton==48)||(MyButton==72)||(MyButton==75)||(MyButton==77)||(MyButton==80)){if (MyButton ==48)return 0;if((MyButton==72)&&(y>1)){MyBuffer=MyPyatn[(y-1)*4+x-1];MyPyatn[(y-1)*4+x-1] = MyPyatn[(y-2)*4+x-1];MyPyatn[(y-2)*4+x-1]=MyBuffer;y=y-1;MyChange=true;}if ((MyButton==80)&&(y< 4)){MyBuffer=MyPyatn[(y-1)*4+x-1];MyPyatn[(y-1)*4+x-1]=MyPyatn[y*4+x-1];MyPyatn[y*4+x-1] = MyBuffer;y =y+1;MyChange=true;}if ((MyButton==75)&&(x>1)){MyBuffer=MyPyatn[(y-1)*4+x-1]; MyPyatn[(y-1)*4+x-1] = MyPyatn[(y-1)*4+x-2];MyPyatn[(y-1)*4+x-2]=MyBuffer;x=x-1; MyChange = true;}if ((MyButton==77)&&(x<4)){MyBuffer=MyPyatn[(y-1)*4+x-1]; MyPyatn[(y-1)*4+x-1] = MyPyatn[(y-1)*4+x];MyPyatn[(y-1)*4+x]=MyBuffer;x=x+1;MyChange = true;}}

Ужасно, правда? И представьте что вам нужно в этом разобраться но при этом вы не можете форматировать текст, поставить отступы, пробелы, нет подсветки синтаксиса и т.п.
Там (внезапно) 9000 блоков. И что? Разве такое количество вызывает какие-то непреодолимые проблемы? В той программе можно минут за 20 разобраться от и до.
Да какая, нафиг, разница — сколько там блоков? Важно сколько там уникальных конфигураций! Там макросы использовались, если мне память не отшибло — то есть реально-то программа совсем небольшая. Да и даже если бы это было просто 9000 блоков без макросов… это как-то ну совсем не внушает. Откуда взяться проблемам в столь небольшой программе? Даже если специально попробовать запутать — это не так-то просто сделать будет… Хотя есть умельцы, они могут и программу в 100 строк запутать так, что в ней разобраться непросто будет…
Хотел программист сделать их удобными и понятными для всех или лепил как получится. И от языка это не сильно зависит.
Зависит, ой как зависит. Попробуйте реализовать мало-мальски нетривиальный алгоритм — и вы это сразу поймёте. Попробуйте сделать, к примеру, «решатель» для тех же пятнашек. Боюсь, правда, что полноценное поле 4x4 в микроконтроллер просто не влезет (там 10 триллионов возможных позиций, так что для решения требуется вполне приличное количество памяти), ну так проблем-то: возьмите поле 3x3, там позиций всего лишь 181 440, самое длинное решение — 31 ход (24 «длинных» хода), это даже в калькулятор можно упихать! Но — придётся как-то всё-таки реализовывать нетривиальные стурктуры данных. А сделать это на FBD — это как «автогеном через жопу», я извиняюсь, гланды вырезать…
И представьте что вам нужно в этом разобраться но при этом вы не можете форматировать текст, поставить отступы, пробелы, нет подсветки синтаксиса и т.п.
А кто мне запретит-то? Откуда такие странные ограничения?
Зависит, ой как зависит.

Я чуть выше неточно выразился. Имеется ввиду популярные и распространенные языки. А то тут есть статья когда человек «Hello, World» писал примерно вот так:
 ++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++
 .>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.
 ------.--------.>+.>. 

Можно программу написать так, чтоб она была понятной, а можно и запутать так, что нихрена не разберешься даже с поллитрой.
А кто мне запретит-то? Откуда такие странные ограничения?

Специфика АСУ ТП. Работает объект, управляемый контроллером с такой вот программой. Там все приемосдаточные испытания проведены, протоколы подписаны и т.д. И никто не даст вам лезть и что то сильно менять. Только маленький кусочек или вообще несколько констант. Т.е. любое форматирование того что есть исключено.
А сделать это на FBD — это как «автогеном через жопу», я извиняюсь, гланды вырезать…

Конечно. Просто в вашем примере и в моем решаются принципиально разные задачи. И если в вашем примере это выглядит как вырезание гланд, то в моем — очень органично.
Можно программу написать так, чтоб она была понятной, а можно и запутать так, что нихрена не разберешься даже с поллитрой.
Да, конечно. Но как тут уже говорилось: для того, чтобы реализовывать реально сложные алгоритмы требуются реально сложные же и языки программирования. А FBD… торетически на нём можно реализовать всё, что угодно, а практически — максимальная сложность алгоритов, которые прямо на нём можно реально реализовать катастрофически низка.
Специфика АСУ ТП. Работает объект, управляемый контроллером с такой вот программой. Там все приемосдаточные испытания проведены, протоколы подписаны и т.д. И никто не даст вам лезть и что то сильно менять. Только маленький кусочек или вообще несколько констант. Т.е. любое форматирование того что есть исключено.
Да уж. Напомнило историю с Google Maps. Её лет 10 назад представители BMW хотели получить к себе в авто. Пришли с примерно такими же требованиями: вы нам типа — передайте исходники, мы их три года будем тестировать, а потом только в машину поставим. Каждое изменение — через новую сертификацию. Их с этими идеями послали, после чего они ушли, полностью уверенные в своей правоте — ждать пока Гугл «прогнётся». Дождались того, что их поделием люди перестали пользоваться, их отдел сократили, а люди таки пользуются Google Maps.

Вы уж меня извините, но FBD — это тупик. Задачи, жёстко завязанные на безопасность (какое-нибудь аварийное отключение атомного реатора) лучше всего делать вообще без всякого ПО (простейшая аппаратная схема), но их, в общем, не так много — а задачи где использовать программного управления позволяет что-то выгадать рано или поздно перерастут сложность того, что комфортно реализуется на FBD.

P.S. В Tesla S обновление прошивки — уже штатная операция, случающаяся регулярно. И меняются там далеко не «несколько констант».
Но как тут уже говорилось: для того, чтобы реализовывать реально сложные алгоритмы требуются реально сложные же и языки программирования.

Ну так МЭК 61131 описывает пять языков. Выбирайте тот, что вам по вкусу.
И еще раз повторюсь — сложные алгоритмы и красивая их реализация на чем-нибудь хитровывернутом это хорошо. Вот только обратной стороной медали является полное закрытие технологической программы от эксплуатации из-за высокого порога вхождения. Что полностью убьет конкурентноспособность вашего изделия. Хотя никто не запрещает писать на том же ST.
Да уж.

Да не вопрос. Хотите менять алгоритмы и переделывать программы на объекте — пожалуйста. Только перед этим бумагу подпишите, что принимаете на себя все риски, связанные с ошибками в программе (причем не только в той части, которую будете править, т.к. сложно разделить единый технологически связанный объект на куски). И вперед. Вот только готова ли будет ваша компания пойти на это?
Задачи, жёстко завязанные на безопасность (какое-нибудь аварийное отключение атомного реатора) лучше всего делать вообще без всякого ПО (простейшая аппаратная схема)

Звучит как призыв: «Вперед в прошлое!». От релейных схем все уходят. Аппаратные защиты в ответственных узлах уже не используются. Все перенесено на микроконтроллеры. Причем эта тенденция наблюдается во всем мире.
Насчет генератора программ — тоже не все так хорошо, а точнее совсем плохо, во всяком случае у Siemens STEP7. В свое время тоже пошел по этому пути: у Сименса имеется возможность импорта/экспорта в текст и само собой напрашивалось сгенерировать исходники своими средствами и подсунуть, но в базе данных проекта у них помимо программных блоков, хранятся еще и их зависимости. В итоге получилось следующее: проект, после N попыток, собирается без ошибок (10<N<100), при этом между попытками никаких правок не вносится, просто в ответ на ворох сообщений об ошибках повторно запускаем сборку и получаем уже ворох поменьше. Причем этот цирк в дальнейшем повторялся при любом малейшем изменении, даже внесенном штатными средствами. Повторюсь, что речь идет именно о Siemens, других подобных поделок не пробовал, но не думаю что там все шоколадно.
Забавно. А фраза «язык FBD это простой и понятный язык» — это сарказм или нет?

Так-то всё напоминает историю Начал в которых Ньютон тщательно избавлялся от «флюксий», чтобы книга стала «понятнее», а в результате добился того, что современному читателю через неё продраться почти нереально.

Вот лично для меня программа на C — вполне понятна, более-менее логична (не без косяков, конечно, ну да ладно — автор сам сказал, что он не спец в C) и, в общем, вопросов при её чтении особо не возникает. А программа на FBD вызывает острое ощущение забивания гвоздей микроскопами.
А фраза «язык FBD это простой и понятный язык» — это сарказм или нет?

Учитывая что статья в хабе "Ненормальное программирование" — все же сарказм.

«Забавно. А фраза «язык FBD это простой и понятный язык» — это сарказм или нет?»

В каждой фразе есть доля сарказма. Но тут его немного.

Я в следующем посте, когда сойдутся звезды, желание и свободное время, попробую сделать одну и ту же программу на FBD и ST. И можно будет сравнить, что проще. Хотя подозреваю, что любое мнение тут будет субъективным.
А что за среда использовалась для разработки?
Приложение для программирования контроллеров в ПТК «Квинт 7». Там внизу тег стоит «Квинт».
Все-таки программа написана на С++, в Си нет bool, namespace, using и т.п.
Ну т.к. я вообще в этом не разбираюсь, то гуглил нужные мне функции. В итоге получилась мешанина из функций С и С++.
Почему то не могу отредактировать свой коммент.
В общем т.к. ничего от объектно ориентированного программирования в тексте нет, то как то совестно было говорить о плюсах :D
есть как минимум cout <<
Позволю маленький нюанс, связанный с правилами игры :)
В оригинальных, «теплых, ламповых» пятнашках можно за один ход перемещать более одной кости, если в конце ряда есть пустышка.
Здесь, как я посмотрю, этот момент не учтен?
Да. Вы правы. Упустил этот момент из вида. (а я думал что эти квадратики и описание к ним вообще никто не смотрит :) )

В принципе эта функция реализуется легко. Если с минимальными переделками, то нужно на каждую клетку заводить не только ближайших соседей, но и весь ряд вообще. И при клике на клетку просматривать весь ряд и каскадом сдвигать по очереди все (в пределе 3) плитки.

Т.к. функция уже займет не 2 цикла как сейчас, а шесть, придется еще наружу блокировку вывести, чтобы подстраховаться от наложения команд.

В целом же алгоритм не изменится.
Only those users with full accounts are able to leave comments. Log in, please.