Компилятор

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

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

Второе.

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

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

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

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

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

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

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

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

[rovki]

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

[petera]

Может и удобно ,но не наглядно ,когда стоит инвертор виднее и читается схема легче (привычка)

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

[rovki]

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

Так и я сказал -привычка .20 лет схемы рисовал без кружочков (по Госту) ,поэтому восприятие схемы на лету будет ограничено у меня .Не было ни где ,кроме буржуйских схем ввиде треугольников ,а не прямоугольников ,меня до сих пор коробит их начертание резисторов ввиде зигзага -привычка (школа).
Это так же как переменные вместо связей - для себя вроде нагляднее и пока помнишь что значит ПУН ,ПС ,АВРСТл, КН1,стр2 идд ,вроде хорошо .А для стороннего пользователя вся это абракадабра только усложняет понимание схемы ,нужно глядеть в таблицу и на схему и искать взглядом где может еще есть переменная с таким именем ....Пока найдешь ,потеряешь ход мыслей ..

[Владимир Ситников]

без кружочков (по Госту), поэтому восприятие схемы на лету будет ограничено у меня

http://aquagroup.ru/normdocs/5122#i171219
ОБОЗНАЧЕНИЯ УСЛОВНЫЕ ГРАФИЧЕСКИЕ В СХЕМАХ. ЭЛЕМЕНТЫ ЦИФРОВОЙ ТЕХНИКИ
ГОСТ 2.743-91

Кружочки на инверсных входах-выходах это самый обычный ГОСТ, стандарт уже больше 20-и лет назад приняли.
Снимок экрана 2016-07-01 в 18.09.09.png

Ограничивайтесь и дальше.

[rovki]

Когда рисовали схемы то руководствовались справочниками и паспортами на ИС .И забота соответствия ГОСТу лежала на производителях ИС ,а не потребителях .Естественно ,что самые популярные элементы были 2И-НЕ ,2ИЛИ-НЕ .(с кружочками на выходе) .Память ,воображение настроено на них .Я лишь против ставить по усмотрению инверсию по входам в виде кружочков ,хотя повторю это дело привычки .Нас не будет ,придет новое поколение ,которые научатся по другому и будут воспринимать по другому .Вы что ж думаете почему я любую схему рисую в течении часа (при понятном ТЗ) ,потому что мозг настроен на нужное восприятие .Сейчас гляжу ,например на FLProg для ардуино и не могу врубится в схему простую с ходу (на лету) ,требуется доп.время на трансляцию в голове (перевод) ,а все потому ,что немного изменено начертание элементов (как в кодесис элементы) .

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

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

Боюсь, язык "Дракон" затруднит продажи продуктов в странах Европы ... европейские пользователи не поймут.

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

Боюсь, язык "Дракон" затруднит продажи продуктов в странах Европы ... европейские пользователи не поймут.

Он удобнее чем CFC. И понятнее.

[sdy]

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

Интересно выпустить (получить) такое в массы... А-ля русский реле-андурино :-).

Я Просто с огромным удовольствием бы писал на Ассемблере, а не на FDB (ну а лучше на С).
Как показала практика - если задача чуть посложнее чем включать/выключать лампочку по внешнему датчику - писать на FDB - просто мука! Особенно если не все детали сразу проработаны.
А уж про сетевой обмен даже говорить не хочется. Кодесис в этом плане (освоения и привычек пользоваться) кажется внешне (врать не буду - не пользовался) не лучше.
Ну а про обновление документации ОВЕНА - я молчу.