Небольшая игрушка «Сапер» не в 30 строк

    Здравствуйте.


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

    Однако от людей, не понаслышке знакомых с работой оперативного персонала на электростанциях, я получил важное замечание о том, что «змейка» категорически не подходит для АСУ ТП по объективным причинам. Во-первых, несмотря на то, что со всей автоматикой на станции управляется система АСУ ТП и она же занимается регулированием и защитами, реалии жизни таковы, что от оператора также требуется следить за технологическим процессом для оперативного вмешательства в него по мере необходимости. Поэтому игрушка должна быть такой, чтобы (в отличие от ранее представленной) не занимать полностью внимание оператора, позволять ему без ущерба для игры переключаться между приложениями и делать что-нибудь. А во-вторых, сама игрушка «змейка» весьма динамичная и требует быстрого (а на высоких уровнях вообще мгновенного и ювелирного) нажимания на кнопки, что может легко привести скажем к небольшой ошибке: например вместо управления игрушкой можно случайно поуправлять каким-нибудь важным технологическим оборудованием, которое при данном режиме работы трогать было ну никак нельзя. Разумеется ничего страшного не произойдет т.к. в любом случае отработает защита, но останов турбины или отключение котла защитой, это вещи, приводящие к солидным финансовым потерям и лишнему труду по запуску их обратно в работу.

    Все это наводить на очевидную мысль, что реализовывать нужно спокойные игрушки на логику. Как вариант — всевозможные пасьянсы или всем известный «Сапер». Ввиду того, что пасьянсы всех видов требуют изображения карт, который не были сходу найдены в интернете (разумеется рисунки карт найти легко, но у меня были особые требования к размеру и качеству а так же оформлению карт) было решено реализовать игрушку «Сапер».

    Помимо этой есть еще одна важная причина в реализации именно этой игры. А именно желание еще раз наглядно показать как легко и весело программировать на языке FBD.

    Несколько вступительных слов


    Но для начала несколько вступительных слов (для тех кто еще не слишком устал читать).

    Наверное каждый, кто прочтет этот пост до конца, скажет (или подумает): «Фигня! Да я то же самое на С (С++, Delphi, JS, и т.д.) напишу в 30 строчек кода». И я с этим согласен. Но есть одно но. Прежде чем написать что нибудь на языке высокого уровня в 30 строчек кода нужно всего-навсего
    Не удержался
    изучить этот язык высокого уровня.
    А писать программы на FBD может начать любой. Более того, основные навыки программирования на FBD прививают детям дошкольного возраста.
    Думаю многие вспомнят как в детстве...
    … под видом развивающих игр из кубиков с буквами собирали слова:
    Например из букв...

    Собирали слово...


    Другими словами, программирование на языке FBD просто и понятно на интуитивном уровне.
    Небольшая ремарка
    Тут я по старой привычке говорю FBD, хотя по словам одного из главных разработчиков всего этого:
    Deranged, 20 декабря 2013 в 12:25
    Это и не FBD. Там есть поддержка типов данных, в том числе структур. Так же данные делятся на потенциальные (мгновенное значение) и команды (буферизуемые значения). Так же имеется встроенная поддержка качества значений. Можно проводить обратные связи, они выделяются зеброй. При этом в качестве начальных значений берутся значения типа данных по умолчанию (прописывается в самом типе).
    В общем там вагон всего, еще я планировал впилить туда контроль порядка выполнения в виде связей и поддержку условий. Тогда был бы полный Франкенштейн из FBD, SFC и обычных блок-схем.


    Разумеется и для этого языка есть серьезные алгоритмы, борьба за ресурсы контроллера, оптимизацию выполнения техпрограммы, оптимизацию памяти и быстродействия в целом. Умные люди ломают головы над тем, как создать идеальные алгоритмы из простейших блоков. Но т.к. эта статья носит чисто ознакомительный характер, то мы опустим все эти тонкости и перейдем наконец непосредственно к самому программированию.

    Но перед этим небольшой вопрос на сообразительность. Кто сам догадается — «респект и уважуха», для нетерпеливых же — ответ в спойлере ниже.
    Так вот — игра «Змейка» и игра «Сапер» это одна и та же игра с точки зрения программирования на FBD. Почему? И что у них общего, что позволяет сделать такое утверждение?
    Ответ
    Все очень просто. И в игре «Змейка» и в игре «Сапер» присутствует поле, состоящее из ячеек. Просто ячейки в этом поле принимают разные значения и по разному отображаются. Т.е… другими словами мы можем взять программу игры «Змейка», ее графический интерфейс, и за полчаса-час работы переделать это все в игру «Сапер», ведь по сути нам придется изменить только один алгоритм и перерисовать одну ячейку поля..

    Начинаем программировать


    Итак, начинаем программировать нашу задачу.
    Лично мое мнение заключается в том, что 80% программирования на языке FBD заключается в том, чтобы четко себе представить, а что же такое мы хотим получить в конечном итоге. И так только мы добиваемся такого понимания, то 80% задачи решены и остается буквально немного работы по наброске кода и его причесыванию. Сейчас попробую продемонстрировать этот принцип на практике.

    Предположим что поле для «сапера» у нас будет по аналогии со «змейкой» 20х20 клеток. Следовательно нам понадобится 400 ячеек памяти, в каждой из которых будет обрабатываться каждая клетка поля. Чтобы структурировать программу — разобьем все ячейки на строки. Таким образом нам понадобится двадцать алгоритмов строк, каждый из которых будет состоять из 20 алгоритмов ячеек. Т.е. мы пришли к пониманию основы программы.

    Алгоритм «Строка»


    Рассмотрим подробнее алгоритм строки. А точнее то, какие данные нам нужно иметь на входе и какие — на выходе этого алгоритма. Предлагаю начать с конца — т.е. с выходных данных.

    Выходы алгоритма

    — Во-первых, нам понадобится выходная строка данных, определяющая состояние каждой ячейки для отрисовки ее в человеко-машинном интерфейсе (или проще говоря в операторской станции).
    — Во-вторых, нужен вектор, показывающий в каких ячейках находятся бомбы, а какие ячейки безопасны.
    — В-третьих, нужен признак того, что игрок «наступил» на поле с бомбой и игра проиграна, назовем этот выход «Big_Bada_Boom».
    — В-четвертых, для удобства в «сапере» заложена фишка, что при попадании на клетку не имеющую соседства с бомбой, автоматически открываются все пустые клетки, граничащие с ней. Т.е. нам понадобится выход, посылающий обратную команду «открыть клетку» самой программой.
    — В-пятых, для алгоритма установки бомб нам понадобится выход, показывающий, сколько бомб находится в данной строке. Разумеется это значение можно получить напрямую из вектора, описанного в пункте 2, достаточно просто сложить все ненулевые биты. Но для удобства внесем эту функцию внутрь макроса.
    — В-шестых, для ведения статистики нам понадобится знать, сколько еще закрытых клеток осталось в строке.
    Вот и все, что нам нужно для полного функционала игры «сапер».

    Всего 6 выходов с данными.

    Теперь подумаем, что же нам нужно иметь на входе, чтобы суметь сформировать требуемые нам выходы.

    Входы алгоритма

    — Логично предположить, что главный вход алгоритма это команда от игрока «Открыть ячейку». Ведь это основной смысл игры.
    — Для наглядности программирования задействуем еще один вход — «Поставить на клетку флаг», помечающий что там бомба и не дающий случайно нажать на эту клетку и взорваться.
    — Для формирования статуса каждой ячейки (а мы то с вами помним, что если в ячейке нет бомбы, то она показывает сколько бомб находится в клетках, граничащих с ней) понадобится завести вектора со строки выше и строки ниже. Сделаем алгоритм универсальным и добавим три входа: вход для вектора с бомбами в строке выше текущей, вход для вектора с бомбами в текущей строке и вход для вектора с бомбами в строке ниже текущей.
    — Для запуска новой игры и переписывания значений ячеек добавим логический вход «Новая игра».
    — Как уже упоминалось ранее, если клетка пустая и рядом нет клеток с бомбами, то должны автоматически открываться соседние с ней клетки. Добавим для этого вход «Открыть программой».
    — Ну и разумеется какая же это игра без заминированного поля. Значит нам понадобится вход «Установить бомбы».

    Всего получилось 8 входов.

    Вот собственно и все, что нам нужно от главного алгоритма программы.
    Набиваем быстро макрос с нашими входами и выходами и получаем вот такой алгоритм:
    или если раскрыть его:
    Теперь наполним наш алгоритм смыслом. Как я уже говорил — основа наполнения нашего главного алгоритма это макрос «Ячейка памяти», которых будет 20 штук.

    Алгоритм «Ячейка памяти»


    Попробуем продумать, что нам может понадобиться от каждой ячейки поля игры «сапер», и что мы должны для этого подавать на вход макроса. Начнем опять с конца, т.е. с выходов. А когда сформулируем все данные, что нам нужны, то станет понятно, что нужно иметь на входе, чтобы их получить.

    Выходы алгоритма

    — Для начала у ячейки должен быть выход, показывающий статус этой ячейки. Вы никогда не задумывались, сколько состояний может принимать каждая ячейка поля в игре «сапер»?
    Состояния ячеек поля
    Ответ 12. именно так — 12 состояний, соответствующих 12-ти различным отображениям ячейки.
    Я закодировал их следующим образом:
    -1 — ячейка закрыта.
    0-8 — ячейка открыта и показывает количество бомб в соседних ячейках.
    9 — ячейка открыта и в ней оказалась бомба.
    10 — ячейка закрыта и на ней установлен флаг.

    — Отдельно для подсчетов и прочей обработки вынесем логические выходы «Ячейка закрыта» и «В ячейке установлена бомба».
    — Как уже говорилось — если открыта пустая ячейка, то она должна автоматически открыть соседние с ней ячейки. соответственно нам нужнен еще логический признак «Открыть соседей».
    — Ну и в конце-концов если игрок ошибся и «наступил» на поле с бомбой, то нужно сформировать логический признак того, что игра проиграна. назовем его «Bada_Boom».
    Итого всего 5 выходов.

    Входы алгоритма

    Попробуем определиться, что же нам нужно для того, чтобы сформировать требуемые выходы.
    — Прежде всего алгоритм должен принимать команду от игрока «Открыть поле».
    — Для простоты отдельной командой заводим сюда еще и команду «Поставить флаг».
    — Как я уже говорил ранее — каждая клетка в поле должна знать, сколько заложено бомб в соседних клетках. заведем для этого отдельный вход «Соседи».
    — Для того, чтобы случайным образом установить вначале бомбы нужен логический признак «Здесь бомба» по которому клетка будет минироваться.
    — Ну и разумеется для начала новой игры должен быть признак сброса, который обнуляет всю информацию в клетках.

    Набиваем и этот макрос получая следующий алгоритм:

    Теперь запрограммируем сам алгоритм «Ячейка памяти». Он предельно простой:

    Краткое пояснение принципа работы алгоритма
    — На алгоблок «БитДешифр1» приходит вектор, сформированный из состояния соседей, который распаковывается на этой алгоритме и далее на алгоблоке «Слож1» подсчитывается количество единичек (бомб) в векторе. Сразу возникает вопрос: почему здесь 9 бит, когда у клетки всего 8 соседей максимум. Отвечаю: для универсальности. Дело в том, что как видно будет позже, я написал еще один макрос для нахождения соседей у каждой клетки. И для того, чтобы макрос получился универсальный для всех случаев (а клетка может иметь не только 8 соседей, когда она находится в центре поля, но и всего 3, когда она стоит в углу, или 5, когда она стоит на краю поля) пришлось задействовать девять бит.
    — Триггер «RSтриг1» служит для установки и сброса «флажка» на клетке. Первая команда взводит триггер, а повторная команда сбрасывает. Как видно из схемы, взведенный триггер, блокирует прохождение команды «Открыть» на алгоблоке «И2» т.к. значение с выхода триггера заведено на вход алгоритма «И» с инверсией. Т.е. пока триггер взведен, на второй вход алгоритма «И» поступает «False» и выход алгоритма «И» тоже равен «False» независимо от значения на первом входе. Получается, что команда «Открыть» не может сбросить триггер «RS2» и мы застрахованы от случайного открытия клетки, которую не хотим открывать.
    — Триггер «RS2» служит для формирования статуса ячейки: закрыта она или открыта. Как видно из схемы триггер взводится командой «Сброс» (начало новой игры) и сбрасывается только по приходу команды «Открыть».
    — Триггер «RS1» служит для индикации наличия бомбы в этой ячейке. Он взводится при поступлении от программы команды «Здесь бомба», которая устанавливает бомбы в ячейку и сбрасывается с началом новой игры.
    — Алгоритм «И3» один из самых важных в этой схеме. на нем по И складывается значение триггера «RS1» (тут установлена бомба) и прихода команды «открыть» в эту ячейку. Если оба условия выполнились, то на выходе формируется «True», означающее, что игрок наступил на поле с бомбой. Это значение подается на выход «Bada_Boom», которые потом со всех ячеек собираются на выходе «Big_Bada_Boom» и означают проигрыш.
    — Три алгоритма «Выбор», расположенные каскадом, формируют статус ячейки. На алгоритме «Выбор1» формируется, что подавать на выход в случае открытия ячейки: числа «0-8», соответствующие количеству бомб в ячейках по соседству, или число «9» соответствующее заминированной клетке. Если поле у нас еще закрыто (Триггер «RS2» взведен), то на алгоритме «Выбор2» устанавливается значение "-1", которое, как мы договорились ранее, соответствует статусу закрытой ячейки. Если поле закрыто (Триггер «RS2» взведен) и одновременно (алгоритм «И4») взвелся триггер «RSтриг1», то на алгоритме «Выбор3» значение подменяется принудительно на «10», соответствующее установленному флагу.
    — Последний алгоритм сравнения служит для автоматического открытия соседних клеток. Если на выходе «Выбор3» мы получили ноль, значит игрок открыл клетку, рядом с которой нет бомб. Тогда отправляется команда на открытие соседних клеток.

    Вот этот примитивный алгоритм и есть основа всей игры. остались только некоторые причесывания программы и допиливание функционала.

    Теперь приступим к макросу «Строка», состоящему из 20 «Ячеек памяти».

    Сам макрос и описание. Рисунок большой.

    Сам макрос предельно простой. 20 алгоритмов «Ячейка памяти» связанные со своими входами и выходами общего макроса. Для статуса ячейки эта связь идет напрямую, для остальных — либо через алгоритмы «БитШифратор» для упаковки логических значений в вектор, либо через сумматоры для подсчета количества нужных элементов в строке, либо через алгоритм «ИЛИ» для формирования выходной команды открытия соседних клеток или окончания игры («Big_Bada_Boom»).
    Отдельного внимания заслуживают только блоки «Открыть», «Преобразование вектора» и «Открыть соседей».
    Рассмотрим каждый такой блок по отдельности.
    Начнем с блока: Открыть

    Как несложно заметить, здесь просто складываются по «ИЛИ» команды от игрока и от программы, когда она открывает соседей пустой клетки.

    Рассмотрим блок: Преобразование вектора

    Идея очень проста. К нам приходит три вектора и нужно посчитать, сколько же мин окружают каждую клетку на конкретной позиции. Для этого я намеревался просто сдвинуть вектор вправо на (позицию — 2) и посчитать количество единичек в первых трех битах каждого вектора после сдвига. Но тут я наткнулся на забавную вещь. А что делать если позиция клетки первая? тогда по аналогии с остальными я должен сдвинуть вектор на отрицательную величину (т.е. не вправо, а влево). Разумеется все передвинутые слева биты будут нулевые, но зато общий принцип подсчета будет сохранен. Однако тонкости реализации алгоритма не позволили это сделать, поэтому пришлось ставить проверку на позицию клетки и для первой позиции клетки проводить отдельную обработку. Собственно говоря эта обработка заключается только в обработке второго бита в текущей строке и третьих битов во всех строках. Помните, я писал о том, что для стандартного макроса мне понадобилось формировать 9 бит соседей, а не 8, как того требует логика. Это связано именно с этой ситуацией.

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

    Рассмотрим блок: Открыть соседей

    Тут вообще все очень просто. Если клетка пустая, то она должна открывать не одну, а целых 8 клеток-соседей. Для унификации и упрощения жизни пусть она открывает не 8 соседних клеток, а 9 (да-да и саму себя тоже. В языке FBD порой даже простейшее допущение, никак не сказывающееся ни на работе программы ни на ресурсах, сильно упрощает жизнь). Таким образом алгоритм работы макроса прост. Мы проверяем позицию клетки. Если клетка стоит на второй и более позиции — формируем вектор из первых подряд идущих битов и сдвигаем их (помните по аналогии с обработкой вектора, только уже не вправо, а влево, т.к. мы не приводим какой то участок вектора к началу, а наоборот, начальный вектор сдвигаем на нужный нам участок) на (позиция -2). Если же клетка у нас первая, то мы формируем начальный вектор из двух битов и сдвигаем его на (позиция -1) = 0 т.е. никуда не двигаем на самом деле.
    Далее нам остается только сложить все подготовленные вектора по «ИЛИ» и выдать на главный выход.


    Отдельно хотел упомянуть про еще один макрос. Перед стартом игры нам нужно случайным образом расположить в поле мины. Но что делать, если нет генератора случайных числе и команда «Random» недоступна. Разумеется в интернете есть множество алгоритмов формирования псевдослучайных последовательностей. Но они довольно сложные и их реализация сама по себе заслуживает отдельной статьи. Поэтому пришлось пойти привычным путем и сделать макрос «Генератор Random».

    Краткое описание принципа работы макроса
    Итак, генератора случайных чисел у нас нет. Ну что ж. сделаем его сами!
    Идея примитивна и уже применялась мной в предыдущей программе, просто тут она получила некоторое развитие.
    На интеграторе формируется очень быстро меняющееся по пиле значение с настраиваемым диапазоном (за диапазон отвечают входы «Верхний порог» и «Нижний порог»). Далее на алгоритме «Секунды» у нас подсчитывается время работы контроллера с момента старта, которое так же непрерывно нарастает. Делим время работы контроллера на наше быстро меняющееся число, при этом берем остаток от деления. Далее выделяем из остатка нужные нам разряды (для пущей случайности я взял 4-5 знаки после запятой для координаты Х, и 6-7 знаки после запятой для координаты У). Выделяются разряды очень просто. Умножаем остаток от деления на 1000000 и делим с остатком на 100. В результате в остатке получаем значение [0..100). При этом нужно понимать, что это значение может сколь угодно близко подходить к 100, но никогда не будет ему равно. Требуемое нам случайное значение лежит в диапазоне [1..20], следовательно делим наш остаток на 5 (алгоритм «ДелОст3»), берем целочисленную часть от деления и преобразовываем в целое число с помощью конвертера типов. Как уже говорилось — делимое никогда не будет равно 100, а значит наше частное лежит в интервале натуральный чисел [0..19]. Проблему решаем просто добавив к результату единичку. Вот и готово наше случайное число. Ввиду того, что неизвестно в какой момент игрок нажмет на кнопку «Новая игра» и какое значение на интеграторе будет в этот момент, а так же то, что мы берем значения в 4-7 знаке после запятой, то можно с уверенностью утверждать, что у нас получился хороший генератор случайных чисел.

    Соединяем все части вместе и добавляем красоты


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

    Небольшое пояснение
    Как видно из рисунка — самый главный действующий алгоритм тут — «РучСелектор1» который выдает на выходе логическую единицу на один цикл и запускает новую игру. Запуск новой игры заключается в том, что сигнал подается на все макросы «Строка» на вход «Новая_игра» и по этому сигналу происходит установка триггера «SR2» в макросе «Ячейка_памяти» и сброс всех остальных триггеров, отвечающих за наличие бомб и флагов в ячейке.
    Одновременно этот же выход алгоритма «РучСелектор1» сбрасывает триггера «RS1» («Game_over» — этот триггер взводится в случае открытия игроком клетки, в которой пряталась бомба, и триггер «RS3» («Victory»), который взводится в случае победы игрока, т.е. обнаружении всех спрятанных в поле бомб. Одновременно тот же самый сигнал посылается на вход алгоритма «Память1» для записи в память количества устанавливаемых бомб в текущей игре (игрок моет менять количество бомб в поле в любой момент, но вот в программу эти настройки попадут только с началом новой игры).
    Далее с задержкой на цикл (алгоритм «Задержка1») (который нужен чтобы сбросить все триггера в ячейках памяти) взводится триггер «RS2» («Ставим_бомбы»), который включает процедуру установки бомб. Т.е. передачи наших случайных координат, сформированных на выходах макросов «Генератор_Random» на алгоритмы «Столбец» и «Строка», посылающие по заданным координатам команду на взвод триггера «RS1» в «Ячейке памяти».
    Контроль количества установленных бомб простой. Подсчитывается общее количество установленных бомб и как только оно сравнивается с числом, заданным на алгоритме «Память1», сбрасывается триггер «SR2» тем самым прекращая установку новых бомб.

    Алгоритмы 36-40 служат для проверки корректности заданного числа бомб игроком. Здесь я для отладки ограничил минимальное и максимальное количество бомб в 0 и 400 штук соответственно. При задании числа, выходящего за этот диапазон, оно автоматически приравнивается к ближайшей границе.

    Проверка на выполнение условий победы предельно простая. Считаются все закрытые клетки. Как только их количество станет равным заданному количеству бомб и триггер «RS1» («Game_over») не взведен, взводится триггер «RS3» («Victory»).

    Нам осталось рассмотреть всего 2 алгоритма:
    Алгоритм «ИЛИ2». На нем по логическому ИЛИ собираются выходы всех трех триггеров. И по выходу алгоритма «ИЛИ2» (когда он равен единице) выставляется блокировка на действия игрока. Т.е. пока хоть один из триггеров взведен (Т.е. или игрок уже победил, или он уже проиграл, или идет установка мин для новой игры) игроку запрещаются любые нажатия в поле. Он не может ни открывать ячейки, ни ставить флажки.
    Алгоритм «Секундомер1» служит секундомером для отсчета времени, затраченного на игру. Подсчитываем количество закрытых ячеек. В начальный момент каждой игры оно равно 400. Как только число закрытых ячеек становится меньше чем 400, запускается таймер, который останавливается по взведению одного из трех триггеров.

    Вот собственно и вся программа.

    Прикручиваем графический интерфейс


    Делается это буквально за пару минут. Рисуется 12 картинок для клетки (я для этого использовал paint) и ставится их отображение в зависимости от статуса ячейки. Далее эта клетка копируется 400 раз (тут пугаться не надо, т.к. 400 клеток это всего навсего девять операций Ctrl+c — Ctrl+v) и получается минное поле. Находим в интернете первую же попавшуюся подходящую по смыслу картинку для логотипа «сапера». Прикручиваем отображение таймера и кнопку «Новая игра».
    А теперь осталось самое сложное — выбрать картинки для победы и поражения в игре. Тут я взял первые же попавшиеся в поисковике картинки по запросам «атомный взрыв» и «Victory». И все — игра готова.
    Начальная позиция:

    Играем:

    Проигрываем

    Предупреждая вопросы: да, вон та черная штука, похожая на букашку с ножками, это бомба так нарисована.

    И побеждаем!

    Подводим итоги


    Тот, кто смог осилить этот пост целиком наверняка заметил, что мы написали пусть и простую, но все-таки не уровня «Hello, World!» программу, и при этом нам не потребовалось абсолютно никаких справочников, хелпов, сидений на форумах программистов, курения мануалов и т.п. Все что было нужно мы реализовали за пару часов (и то лично у меня большая часть времени ушла на красивую расстановку алгоблоков для картинок), при этом использовав понятные даже школьнику алгоритмы сложения, вычитания, умножения и алгоритмы логики «И», «ИЛИ». Плюс задействовали несколько простейших RS-триггеров. Самый сложный алгоритм, использованный в программе, это «Интегратор». И то мы с вами использовали его просто как сумматор с обратной связью и проверкой границ. Т.е. фактически можно заменить интегратор на алгоритм «Сложение» и два алгоритма «Сравнение».
    Другими словами, программировать на FBD просто и весело, и на начальном уровне не требуется вообще никаких знаний и навыков кроме понимания элементарной логики. Главным при этом является четкое представление себе конечного результата. Если оно имеется, то сама программа является его логическим довершением. Если же представить «А что же мы хотим в итоге получить» пока не получается, то возможно стоит четче сформулировать задачу. Сразу оговорюсь, что все вышесказанное применимо не ко всем проектам, реализованным на FBD, а к простым маленьким задачкам, вроде той, что приведена в нашем примере. Т.к. для огромных проектов на десятки тысяч сигналов соединить это все в голове наверное не получится ни у кого. Но и в этом случае огромный проект разбивается на небольшие подзадачи, где наш подход уже становится вполне применим (разумеется с учетом общих требований к проекту).
    Т.к. язык FBD универсальный и мы в программе задействовали простейшие алгоритмы, являющиеся базовыми для любых реализаций, то данную программу можно с минимальными усилиями воспроизвести на любом контроллере, как отечественной разработки, так и иностранных (например на контроллерах фирмы Siemens или ABB).

    Из того, что осталось нереализованным

    Нереализованными остались три функции классической игры сапер.
    Первая, это возможность в настройках задавать размер поля. Делается это несложно. Собственно говоря просто алгоритмы «Ячейка памяти» копируются столько раз, сколько клеток должно быть в поле. Проблема тут одна: отсутствие динамической памяти, т.е. невозможности «на лету» добавлять или убирать какие либо данные. А из этого следует простой вывод — сделать изменяющиеся размеры поля очень просто — нужно сначала запрограммировать задачу под максимальный размер поля, а потом просто выставлять логический признак на незадействованные ячейки, которые по этому признаку не будут отображаться в графическом интерфейсе и не будут обрабатываться при игре.
    Вторая — это подмена ячейки при первом клике, если в ней изначально находилась бомба. Т.е. в нашей программе в отличие от «сапера» в Windows есть шанс проиграть на первом же клике. Это делается тоже легко, достаточно проверять пришедший сигнал на триггер «Game_over» и количество закрытых клеток. Если у нас число закрытых клеток 399 и пришел сигнал на взведение триггера «Game_over», то нужно заблокировать этот сигнал, сбросить ту ячейку, на которую был произведен клик и запустить алгоритм случайной установки еще одной мины, при этом заблокировав возможность установки мины в уже открытую ячейку.
    Ну и как видно из описания — не реализована функция сбора статистики. Т.е. не запоминается лучший результат, имя человека, поставившего рекорд. Соотношение побед и поражений и т.п. Но это все настолько тривиально, что делается буквально парой щелчков мыши, поэтому эту функцию оставляю на реализацию всем желающим.

    Спасибо всем, кто дочитал этот пост до конца. Надеюсь было интересно.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 38

      +2
      Вагон — это пять!
      По рзелульаттам илссеовадний одонго анлигйсокго унвиертисета, не иеемт занчнеия, в кокам пряокде рсапожолены бкувы в солве. Галвоне, чотбы преавя и пслоендяя бквуы блыи на мсете.
      • UFO just landed and posted this here
          0
          А с чем вы не согласны?
          С тем что легко? Так этот пример как раз показывает, что это не так трудно как кажется на первый взгляд.
          С тем что весело? Так это чисто субъективное отношение к самому процессу. Можно конечно сидеть с угрюмым лицом и кодить, проклиная весь мир. Но это как-то скучно.
          • UFO just landed and posted this here
            0
            Да уж, действительно, легко и весело :) Примерно, как сложить слово «вечность» из приведённых кубиков :))

            Основная проблема — совсем уж бедность такого языка. Высокоуровневый язык с богатыми библиотеками даёт богатые возможности, но требует длительной подготовки. Бедный язык (такой, как FBD) даёт богатые возможности заново переизобрести колесо, велосипед и многое другое :))) И потрахаться на ровном месте с проблемой, о существовании которой даже не догадался бы, работая со старым добрым трубо паскалем или С++.

            Короче, золотая середина между богатыми и бедными языками таки есть.

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

            Кстати, в какой среде это написано? На классический FBD не очень похоже, больше похоже на то, что горячо любимый сименс называет CFC (Continuous function chart).

            PS Cлово «вагон» — просто супер :))
              0
              Про среду.
              Это и не FBD. Там есть поддержка типов данных, в том числе структур. Так же данные делятся на потенциальные (мгновенное значение) и команды (буферизуемые значения). Так же имеется встроенная поддержка качества значений. Можно проводить обратные связи, они выделяются зеброй. При этом в качестве начальных значений берутся значения типа данных по умолчанию (прописывается в самом типе).
              В общем там вагон всего, еще я планировал впилить туда контроль порядка выполнения в виде связей и поддержку условий. Тогда был бы полный Франкенштейн из FBD, SFC и обычных блок-схем.

              Вот слова одного из главных разработчиков среды.

              Ну а так это отечественный ПТК «КВИНТ 7». Соответственно скада для технологического программирования, в которой написана программа и приложение для подготовки мнемокадров, в которой сделана визуальная часть.

              Что касается мысли о бедных и богатых языках. Все верно. В «богатых» языках реализована куча всего. Есть готовые решения под множество задач. Причем даже не надо ничего придумывать — можно взять готовую библиотеку и использовать ее как черный ящик. Однако все это требует глубокого понимания самого процесса программирования. Уж не говоря о том, что нужно для начала хотя бы синтаксис языка изучить и основные принципы. ну и первая картинка хоть и шутка (там где С++ за 21 день), но в каждой шутке как известно есть доля шутки.

              С другой стороны язык FBD не настолько и «беден». Есть простейшие (и не очень) математические операции. Есть вся основная логика. Есть разные виды триггеров. А циклы реализуются самим принципом работы контроллера, который с заданной периодичностью прокручивает программу. Т.е. можно образно сказать, что все написанное — написано внутри одного большого цикла от единицы и до бесконечности. Этого в теории достаточно для написания программы под нужды технологов. Ведь это я просто балуюсь такой ерундой. В реальности же все это сделано для технологического программирования, а оно по большей части по сложности куда как проще чем пример. Ну и разумеется если есть какая то стандартная задача (например управление задвижкой), то разработчик комплекса не настаивает на создании объекта управления задвижкой на триггерах, таймерах и логике. С технологам согласуется и потом предоставляется готовый алгоритм. В результате программировать становится совсем просто.

              Ну а по поводу алгоритмической подготовки. Я бы сказал, что основное это скорее логическая подготовка. Т.е. нужно натренироваться прослеживать передачу сигналов по цепочке от одного алгоблока к другому, представлять как работают параллельные цепочки, ну и разумеется не путаться в главном цикле. При этом четко осознавать, как работают алгоритмы «И», «ИЛИ», Триггера, и какие сигналы приходят к ним на входы. Вот собственно и все.
                0
                Насчёт бедности (или нет) FBD.

                Мне относительно недавно надо было реализовать пересчёт уровня в объём. Ёмкость — цистерна, т.е. горизонтально лежащий цилиндр. Короче, формула получается чуть сложнее, чем 2 х 2. В языке высокого уровня достаточно написать оператор присвоения и формулу справа от него, а на FBD (ну или IL — он же STL по-сименсовски) это реализуется немного заморочнее: загрузить операнды в регистры, выполнить операцию, сохранить результат, следующее действие…

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

                мне это можно не рассказывать, я достаточно хорошо знаком с принципом работы PLC. Не первый год уже… Однако, отечественных изделий побаиваюсь — то, что мне попадалось, было несколько кривым.

                А картинки ваши, коллега, очень напоминают мне PCS7 и CFC от Siemens — знакомая штука?
                  0
                  В понедельник покажу, как за 5 секунд реализовать пересчет уровня в объем на нашей системе.

                  А по поводу похожести. Во-первых, если разработчики заглянут сюда, то смогут конкретнее ответить. А во-вторых, развитие АСУ во всем мире движется в одном направлении. Если присмотреться, то все делают одно и тоже и все друг друга «напоминают». «Дьявол» разумеется в деталях и нюансах, но в общем и целом все похоже. И принципы везде одни и те же. А уж если система делается с учетом общепринятых стандартов, то тут и говорить не о чем.
                    0
                    Ну вот то, что я увидел на картинках, напоминает сименс до такой степени, что будь это Apple и Samsung — уже была бы парочка исков :))
                    0
                    Беру свои слова обратно.
                    Вот реализация алгоритма расчета объема воды в баке по уровню:

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

                    Но это уже скорее расчетная задача.
                    Но для технологического программирования все таки я уверен, что язык FBD проще и понятнее и нагляднее.

                    Кстати в нашей среде программирования можно комбинировать языки FBD и ST в любом сочетании. Это я пишу примеры на FBD просто потому, что на языке ST это скучно.
                      0
                      Что и требовалось доказать :)

                      Кстати, приведённая картинка — это не FBD в стантарте IEC (МЭК) 61131-3.

                      Это самый натуральный CFC (Continuous Function Chart). Он похож на FBD, и, в сущности, это его дальнейшее развитие, но это уже другой, более мощный язык.

                      На ST (Structured Text, SCL по-сименсовски) это, действительно, реализуется проще всего. Но, при компиляции, это превращается в IL (по-сименсовски ST :) и выглядит примерно так:

                      L #Radius
                      L #Level
                      -R // Radius — Level
                      A OV // error check in substraction operation
                      JC err

                      TAK // Preparation to divide: swap ACCUs

                      /R // (Radius — Level)/Radius
                      A OV // error check in division operation
                      JC err

                      ACOS // Arccosinus
                      A OV // error check in ACOS operation
                      JC err

                      L 2.000000e+000
                      *R // 2*ACOS((Radius — Level)/Radius)
                      A OV // error check in multiplication operation
                      JC err

                      PUSH // store value in ACCU2

                      SIN // calculating sinus
                      A OV // error check in SIN operation
                      JC err

                      -R // 2*ACOS((Radius — Level)/Radius) — SIN(2*ACOS((Radius — Level)/Radius))
                      A OV // error check in substraction operation
                      JC err

                      L 2.000000e+000
                      /R // Divide by 2
                      A OV // error check in division operation
                      JC err

                      L #Radius
                      SQR // Square, power 2
                      A OV // error check in power operation
                      JC err

                      *R // R*R*(2*ACOS((Radius — Level)/Radius) — SIN(2*ACOS((Radius — Level)/Radius)))/2
                      A OV // error check in multiplication operation
                      JC err

                      L #Length
                      *R // L*R*R*(2*ACOS((Radius — Level)/Radius) — SIN(2*ACOS((Radius — Level)/Radius)))/2
                      A OV // error check in multiplication operation
                      JC err
                      // Final volume

                      L 1.000000e+003
                      /R
                      A OV // error check in conversion operation
                      JC err

                      T #Volume

                      BEU // if no error stop here

                      err: L -1.000000e+000 //L#-1 // Returns -1 on error
                      T #Volume


                      Это текст программного блока, который написал я. Естественно, компилятор выдаст что-то, читаемое значительно менее и содержащее большее количество инструкций: немного подумав, я написал этот расчёт так, что мне даже ни разу не пришлось сохранять промежуточный результат расчёта. Для этого пришлось воспользоваться командой TAK, которая выполняет обмен значений между первым и вторым регистрами, а всего регистров два.

                      Реализовывать подобный расчёт на CFC через кучу блоков совершенно нерационально — куда рациональнее создать отдельный блок на ST (ваш вариант) или IL (мой) и уже его вставить в диаграмму, привязав входные и выходные параметры.

                      Насчёт того, что
                      я пишу примеры на FBD просто потому, что на языке ST это скучно

                      CFC (который вы упорно называете FBD) в ряде случаев намного проще в отладке (и наладке). Как правило, к моменту написания программы есть готовая библиотека типовых блоков (или допиливается в процессе :), таких, как мотор, клапан и т.д. Соответственно, если на запуске объекта всплывают ошибки в работе какого-то конкретного клапана или мотора, по «верёвкам» логических связей довольно просто отследить, откуда что берётся.
                        0
                        Я называю FBD по привычке т.к. в предыдущих 6 поколениях КВИНТа язык был куда более похож на FBD, нежели текущая реализация. Но теперь готов поставить везде замену на CFC, хотя это нельзя отнести и к чистому языку CFC.

                        По поводу вашей реализации расчета объема воды в баке: переходите на нашу разработку! будете делать то же самое, только проще и быстрее. Хотя по идее я тут должен выражать абсолютно нейтральное мнение, но результат сравнения налицо. Даже на алгоблоках расчет делается куда проще, чем у вас. А на ST так вообще в одну строку.
                          0
                          Пусть это не CFC в чистом виде, но от FBD это уже значительно дальше.

                          В остальном же… Во-первых, не вода, а солярка :) Во-вторых, это не так сложно при наличии некоторого опыта ;)
                          Siemens предоставляет и IL, и LAD/FBD, и ST, и графические языки. Просто в ряде случаев есть причины ограничиться первыми тремя.
                          1. они входят в базовый комплект поставки.
                          2. они не требуют компиляции. А это значит, что в дальнейшем можно сделать upload из контроллера и получить программу в том же виде, а не фарш после компилятора.
                          Ну и ещё некоторые.

                          Насчёт реализации расчёта формулы на графике — на сименсе так точно делать не стоит :) И реализация в IL однозначно проще и быстрее для контроллера ;)

                          А уж переходить с сименса на что-либо другое — это фантастика. Я совершенно не уверен, что израильских заказчиков устроит совершенно незнакомая им российская разработка.
                            0
                            Насчёт реализации расчёта формулы на графике — на сименсе так точно делать не стоит :) И реализация в IL однозначно проще и быстрее для контроллера ;)

                            Не буду говорить ничего про конкурентов, скажу только что у меня выполнение программы с 200 датчиками и 100 механизмов плюс разумеется всевозможная логика в виде блокировок, пересчетов и т.д. укладывается в 5 мсек.
                            А если «помухлевать» со вставками на ST то можно смело снимать еще 30-40% с времени выполнения.

                            В общем как показывает практика — стандартный цикл для типового контроллера (разумеется набитого программой) — 10 мсек. Поэтому на счет экономии ресурсов в этом случае даже заморачиваться не стоит.

                            С Сименсом мы плотно работали (в рамках стыковки систем) на Рязанской станции. И честно скажу — и в плане удобства, и в плане простоты и быстроты реализации проекта, и в плане характеристик (по моему «непредвзятому» мнению) он сильно нам уступил. Что касается надежности, то тут ничего сказать не могу, т.к. жалоб на наше оборудование со станции не поступало, а по Сименсу мне информация недоступна. Так что будем считать примерно на равных пока.
                            Про стоимость проектов вообще даже приблизительно сравнить не могу.
                            Хотя с другой стороны — всяк кулик свое болото хвалит. Не удивлюсь, если у них аналогичное мнение на счет преимущества их системы над нашей.

                            А уж переходить с Сименса на что-либо другое — это фантастика. Я совершенно не уверен, что израильских заказчиков устроит совершенно незнакомая им российская разработка.

                            Пока не попробуешь — не узнаешь. Хотя с другой стороны я тоже предпочитаю проверенные временем привычные решения, правда при этом все время смотрю на соотношение: риск/выигрыш.
                            Т.е. если от использования чего то нового выигрыш составляет пару процентов, то действительно игра не стоит свеч. Если что то посущественнее, то уже есть повод задуматься.
                              0
                              Не стоит так делать не потому, что система не уложится в требуемое время цикла. Уложится. Просто не следует делать шаляй-валяй.
                              С Сименсом мы плотно работали (в рамках стыковки систем) на Рязанской станции. И честно скажу — и в плане удобства, и в плане простоты и быстроты реализации проекта, и в плане характеристик (по моему «непредвзятому» мнению) он сильно нам уступил.

                              Сименс делает системы крупные, а потому довольно сложные. С наскока не разберёшься. Скорее, наоборот: с наскока совершенно непонятно, какого лешего так сложно нагорожено. Понятно становится после пары-тройки проектов. Но и косяков хватает, спору нет.
                              Что касается надежности, то тут ничего сказать не могу, т.к. жалоб на наше оборудование со станции не поступало, а по Сименсу мне информация недоступна. Так что будем считать примерно на равных пока.

                              Не скажу про надёжность, а вот с доступностью информации ситуация диаметрально противоположная. По сименсу информации вагон и вся она доступна. По Квинту… ;) Один из показателей надёжности — MTBF (mean time before fault, среднее время наработки на отказ) и у сименса есть таблица MTBF по всем модулям.

                              Насчёт пробовать — повторюсь, сейчас я делаю проекты в Израиле. Это совершенно ничего не меняет для продукции Siemens и существенно усложняет для Квинта. Хотя бы, потому, что выбор системы далеко не всегда зависит от меня. Да и я к российским системам отношусь с некоторым недоверием: то, с чем сталкивался, пока не впечатлило. Возможно, Квинт лучше :)
                                0
                                Просто не следует делать шаляй-валяй.

                                Золотые слова!
                                Сименс делает системы крупные, а потому довольно сложные. С наскока не разберёшься. Скорее, наоборот: с наскока совершенно непонятно, какого лешего так сложно нагорожено. Понятно становится после пары-тройки проектов.

                                Так это не я разбирался. Там со стороны Сименса свои специалисты были. Я думаю они то уж должны разбираться в системе, на которой делают проекты.
                                Не скажу про надёжность, а вот с доступностью информации ситуация диаметрально противоположная.

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

                                Что касается информации и ее доступности — ответил в другой ветке. Ответ такой: я не знаю кто и как формирует политику продвижения, пиара и т.п. системы.
                                  0
                                  Так это не я разбирался. Там со стороны Сименса свои специалисты были. Я думаю они то уж должны разбираться в системе, на которой делают проекты.

                                  Повторюсь: у сименса столько всего, что заблудиться можно. Из этого есть неприятные следствия:
                                  1. далеко не каждый, кто делает что-то на сименсе — специалист. Я — тоже :)))
                                  2. проекты часто сделаны таки шаляй-валяй… По причине п.1.
                                  У нас тоже есть расчеты надежности, наработки на отказ и т.д. Правда мое мнение заключается в том, что это чисто теоретические цифры типа сферического коня в вакууме.

                                  В случае с сименсом это не только расчёты, но и практические данные тоже. Они ж собирают данные по тем же гарантийным заменам, а S7-300/400 существует уже около 20 лет.
                                    0
                                    И КВИНТ тоже существует уже 20 лет. Правда за эти двадцать лет сменилось 3 принципиально разных поколения. Но есть проекты, реализованные в конце девяностых, которые работают до сих пор.
                                      0
                                      Сименс тоже неоднократно обновился за это время. Самые первые железки уже сняты с производства, но практически всё железо в рамках линейки совместимо между собой.

                                      PS А Step5 уже совсем ветхозаветный, но в некотором объёме поддерживается до сих пор.
                    0
                    PS «КВИНТ 7» как-то напоминает про STEP 7 и PCS7 :)))
                      0
                      Так это для Ремиконтов? Неплохо развиваются, оказывается, железки. Где про них почитать можно, не подскажете?
                        0
                        Почитать наверное на официальном сайте: www.niiteplopribor.ru
                        Да — это развитие линейки ремиконтов. В частности программа написана для ремиконта Р-400.
                          0
                          Что-то технической документации не нашел, только рекламные брошюры. Все засекречено?
                            0
                            Не думаю, что все засекречено. Единственное — я не работаю с официальной документацией, поэтому имею доступ только ко внутренней рабочей документации. А она скорее всего является коммерческой тайной.

                            Поэтому по вопросам документации лучше обратиться либо в техподдержку с сайта, либо если кто из имеющих доступ сюда заглянет.
                            0
                            Даже название похоже: Р-400 и S7-400 :)) Посмотрел на сайте — там про КВИНТ 7 совершенно нет информации.
                              0
                              Это чисто совпадение.
                              Первое поколение контроллеров было Р-100. (сюда входит и легендарный контроллер Р-130)
                              Потом в КВИНТе 1-4 использовалось второе поколение контроллеров: Р-200.
                              В КВИНТе 5-6 использовалось третье поколение контроллеров: Р-300.
                              А сейчас в КВИНТе 7 используется соответственно четвертое поколение контроллеров: Р-400.
                              Вот и весь секрет в названии.
                                0
                                Да шучу я :)
                                Просто я довольно давно и плотно работаю на сименсовской технике, а сименс таки в лидерах (думаю, никто не будет спорить).
                                А у сименса вся система называется PCS7/Step7 (сравниваем КВИНТ 7) и контроллеры S7-300/400 (сравниваем Р-300, Р-400) :)) А уж скриншоты CFC редактора так совсем напоминают.

                                И, что характерно, совершенно точно Siemens не копировали Ремиконт :)
                                  0
                                  И, что характерно, совершенно точно Siemens не копировали Ремиконт :)

                                  А вот это уже бооооольшой вопрос!
                                  Шутка.

                                  Хотя с тем, что Сименс в лидерах я спорить точно не буду.
                                  Но вместе с тем мы работаем и с Сименсом. Т.е. можно к сименсовским модулям прикрутить нашу голову, скаду, возможности отображения и архивирования информации. И будет некий КВИНТоСименс!
                                    0
                                    Прикрутить можно, но не нужно. По одной простой причине…

                                    Допустим, я пишу на сименсе программу в CFC. После того, как я её напишу, я запускаю такую штуку, которая у Siemens называется AS-OS Engineering. Суть в том, что эта программа вытягивает всё, что нужно, из контроллерного проекта и забрасывает его в WinCC — это SCADA от Siemens.

                                    Что это даёт?
                                    В настройках, как вы выразились, алгоблока устанавливаются атрибуты у каждого параметра: задействован ли он в SCADA, требуется ли его архивировать, измеренному значению можно задать единицу измерения.
                                    В общем, 5 минут компиляции и база переменных готова, конфигурация архива готова, аварийные/предупредительные сообщения готовы :)
                                      0
                                      Ну это уже совсем беспредметный спор.
                                      Я тоже могу в красках описать, как получив от генпроектировщика EXCEL-евский файлик с кксами просто импортирую его в систему и у меня готов набор всех объектов с атрибутами, единицами, диапазонами, архивируемостью и т.д. Короче база готова менее чем за 30 секунд. Остается только красиво расставить алгоблоки в задачах и обвязать «веревками».

                                      В общем везде есть свои плюсы и свои минусы.
                                        +1
                                        Это не спор, а описание работы. На сайте, который вы привели, про вашу систему документации нет совершенно. А на тот же сименс — её тонны.
                                          0
                                          Полностью с вами согласен. Проблема в том, что я не в курсе, кто занимается сайтом и какая политика в продвижении системы.
                                            0
                                            Применительно к сименсу — у них любой мануал и даташит можно найти на сайте, если хорошо поискать. Практически всё, что надо, расписано в документации. Есть даже по-русски. На их сайте есть форум (живой), где можно найти ответы на разные странные вопросы. Есть форум (тоже живой) на сайте российского представительства (по-русски). Есть техподдержка в представительстве и в головной конторе по телефону и e-mail. В головной конторе даже круглосуточно.

                                            А косяки — они у всех есть, и у Сименса тоже. Плюшка в том, что у Сименса хорошо работает техподдержка — следовательно, проблемы решаются.
                                              0
                                              Документация у нас есть полная. Вопрос просто в доступе к ней. Я думаю что она ничуть не хуже сименсовской как по полноте, так и по удобству использования.
                                              Техподдержка также в наличии. Правда на счет круглосуточности ее я не уверен. Но в любом случае — все вопросы оперативно решаются.

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

                                              Везде есть свои плюсы и свои минусы, а все остальное — работа маркетологов или познается на собственном опыте.
                                                0
                                                А кто меряться начал? Кто мне написал
                                                переходите на нашу разработку! у нас есть печеньки!
                                                ;)

                                                PS Недоступная документация/поддержка = отсутсвию оной. Чтобы это стало понятно, достаточно один раз на объекте в жопе мира в выходные натолкнуться на какой-либо баг, который, на самом деле, фича. Это первое. Второе — исходя из той документации, что есть на сайте, я бы в жизнь не заложил такое оборудование в проект. Ибо чёрный ящик, чернее некуда :)
                                                  0
                                                  Секундочку! По поводу «начал» и «печеньки». Предложение было только в контексте простоты программирования.
                                                  Если меня не подводит память и копипаста:
                                                  По поводу вашей реализации расчета объема воды в баке: переходите на нашу разработку! будете делать то же самое, только проще и быстрее. Хотя по идее я тут должен выражать абсолютно нейтральное мнение, но результат сравнения налицо. Даже на алгоблоках расчет делается куда проще, чем у вас. А на ST так вообще в одну строку.

                                                  Т.е. суть в том, что программировать проще и быстрее. Причем даже не просто про абстрактное программирование, а конкретно для реализации задачи с баком.

                                                  PS...
                                                  Критика это хорошо! Я всегда за конструктивную критику т.к. она является сильным подспорьем на пути движения к светлому будущему.

                                                  Что касается документации: заказчику передается полный пакет документации в электронном виде. Плюс в бумажном виде еще стопка книг высотой в метр. Так что никто не уходит обиженным.

                                                  А вот про отсутствие открытой для всех желающих документации на сайте — еще раз повторю. По этому вопросу ничего сказать не могу т.к. это вне моих компетенций. Возможно все дело в том, что мы сами реализуем проекты на нашей системе, а не продаем отдельно железки и ПО сторонним проектным организациям как это делает тот же Сименс. В связи с этим и нет особой необходимости в горах документации в открытом доступе. Но все течет, все меняется. Кто знает как в будущем жизнь повернется.
                                                    0
                                                    Как говорится, «оправдываешься — значит, виноват» :)))
                                                    Т.е. суть в том, что программировать проще и быстрее.

                                                    Сименс даёт такую возможность. Но, по совокупности факторов (включая опыт), одну, отдельно взятую функцию мне было удобнее написать на IL.
                                                    Что касается документации: заказчику передается полный пакет документации в электронном виде.

                                                    Вот это и есть проблема. Лично я (как интегратор, т.е. разработчик проектов по автоматике) не хочу строить автоматику на «чёрном ящике», возможностей, проблем и ограничений которого я не представляю. А получается, что единственный способ познакомиться с вашей техникой — только купить её.
                                                    По этому вопросу ничего сказать не могу т.к. это вне моих компетенций.

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

                                                    И этим компания себя сильно ограничивает. Единственный успешный пример подобной закрытости, который я с ходу припоминаю — Apple. Но это совсем другая история :)
                                                      0
                                                      И этим компания себя сильно ограничивает.

                                                      Не факт. Это просто разные модели развития бизнеса в разных средах. Вы наверное лучше меня знаете о трех основных направлениях в бизнесе. B2B, B2C и B2G.
                                                      И если в B2C закрытость действительно является серьезным ограничительным фактором, то в B2G и B2B это не столь критично, т.к. там принципиально другие источники получения информации.
                                                      Не буду давать оценку нашей политике в этом направлении просто потому, что не владею необходимой для составления обоснованного собственного мнения информацией.

                  Only users with full accounts can post comments. Log in, please.