Компилятор

[capzap]

заметили, что для меня нет разницы ассемблер или ASM, я в этом ни чего не понимаю. Я знаю только пару команд: ./configure, make, потом только наблюдаю в консоли что то сишное или асмовское
по поводу второго, он похож и/или стремиться к CFC. С Вашей точки зрения, да тоже придуман, но я еще на бумажных чертежах с ним знаком и принимаю правила разработчиков ПО изучая их продукт, а не требую от них написать языковое дополнение к среде на котором пишу в последнее время
еще раз про привлекательность. Не надо подменять понятия улучшение среды разработки и дополнение для отдельной группы пользователей. У меня нет желания переходить на ПР, когда у меня покупают семена, даже если и первое подойдет по характеристикам. Тут либо Вы знакомы с какими то неправильными программистами либо требуете от ОВЕНа, что то добавить для себя, чтоб побольше в собственный карман отстегнуть, за счет дешевого железа

[rovki]

capzap ,не тратьте время ,он "чистый программист" ,уверен ни одной системы управления ТП не реализовал и не продал .Спорт ради спорта

[Devoter]

Честно говоря, не ожидал, что будет такое упорство в виде: "нам ничего не нужно, FBD - наше все". Но, каждому свое. Я вижу абсолютное непониманию спорящих людей с одной стороны, и с другой.
Собственно, сам столкнулся с таким проектом, где бюджет, действительно ограничен, и ПР туда очень хорошо вписывается, а вот ПЛК с эквивалентным количеством портов стоит уже в 5 раз дороже. Рассусоливать свои мысли не вижу смысла, так как одни упорно сетуют за схемы, а Ситников, как мне кажется, не вполне представляет - как же выполняется программа внутри ПР. Что касается интерпретаторов - то, по сути, именно он и используется, возможно, виртуальная машина с определенным набором команд (что более вероятно). Но сути это не меняет. И да, внедрение ST-блоков - это вообще было бы похоже на бальзам на душу, но потребует от разработчиков серьезных усилий, которые они сейчас, пожалуй, не готовы тратить на конкретную задачу. А что касается массивов, то, как бы, конечные автоматы их, в общем-то, никак не отвергают. И меня не напрягало бы использовать смещения регистров вместо "облагороженных" массивов, да только нет такой возможности, нельзя сохранить адрес одной переменной внутри другой, нельзя, соответственно, и разыменовать указатель. В общем, все, что хотел узнать, создавая эту тему - узнал. Спасибо всем за участие. Но, если хочется еще пообсуждать, то лучше используйте объективную аргументацию.

[rovki]

А чем Вас не устраивает ПЛК 63(73) ?

[capzap]

такое упорство в виде: "нам ничего не нужно, FBD - наше все".

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

ЗЫ не смог закончить мысль,ПНР всётаки, так вот где гарантия того, что всякий вопрошающий и требующий нововведений получит наконец свою хотелку и не разочаруются если в неё будет не меньше косяков чем в штатном ОЛ. Кто дал утвердительный ответ, что овеновские разработчики легко и без ошибок пишут дополнения и плагины. Вот когда в рабочее время надоест гонять кофеи и играть в иргушки, а это как показатель что версия ПО стабильная, тогда и займутся персональными запросами

[melky]

Автор, выбирите другого производителя, есть аналоги, программы на которые надо писать на С.

[Евстигнеев Максим]

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

Второе.

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

Это так.
Хотя мы и не открещиваемся от внедрения ST. Но это не приоритетная задача.
Скорее это будет дополнение к существующей концепции. Например, выбор языка при написании макроса.
Есть идея (если честно, пока только моя лично), посмотреть в сторону Blockly https://developers.google.com/blockly/ чтобы оставаться продуктом "с низким уровнем вхождения"...

Но пока в основной стратегии - это расширить список ФБ.
Видится, что при этом у пользователей нивелируется желание переходить на более понятные им языки программирования.

[игорь68]

Максим полностью с вами согласен с тем что нужны новые ФБ. А если компания Овен выделит под это небольшие человеческие ресурсы (1-2 человека может даже удаленные) которые занимались бы тем что делали новые ФБ. Пусть это будет 1 ФБ в месяц но главное что бы он РАБОТАЛ.

[Алексей Геннадьевич]

Это так.
Хотя мы и не открещиваемся от внедрения ST. Но это не приоритетная задача.
Скорее это будет дополнение к существующей концепции. Например, выбор языка при написании макроса.
Есть идея (если честно, пока только моя лично), посмотреть в сторону Blockly https://developers.google.com/blockly/ чтобы оставаться продуктом "с низким уровнем вхождения"...

При выборе языка советую обратить внимание на ДРАКОН.

Но пока в основной стратегии - это расширить список ФБ.
Видится, что при этом у пользователей нивелируется желание переходить на более понятные им языки программирования.

Желательно сделать ФБ с расширяемыми и инвертируемыми входами, как в FBD Codesys. Просто удобно.

[rovki]

[QUOTE=Алексей Геннадьевич;213764
инвертируемыми входами, как в FBD Codesys. Просто удобно.[/QUOTE]
Может и удобно ,но не наглядно ,когда стоит инвертор виднее и читается схема легче (привычка)