Компилятор

[Devoter]

Ой, все )))

А если серьезно, то, так как ОВЕНовцы не раскрывают внутренний формат программ для ПР, то могу лишь предполагать, что внутри реле записывается именно как связи и логические элементы, которые обрабатываются виртуальной машиной (прошивкой). Так что вставить ST-блок может оказаться невозможным. Другое дело, что есть еще несколько моментов:
1. Можно взять или придумать какой-нибудь мнемоязык, который позволит писать те же самые логические схемы в текстовом виде, что, зачастую, упростит понимание, ибо схема наглядна только до того момента, пока она вся вмещается на один экран монитора. И тут должен отметить, что да, для расширения возможностей мнемоязыка (например, доступа к регистрам), нужно поддержку такой операции реализовать в виртуальной машине, и это потребует усилий от разработчиков, так как исходниками прошивки они делиться не готовы - и это - их право. Так что сейчас просто хочется иметь возможность описывать те же схемы текстом.
2. Вне зависимости от языка, использование мощностей ПР должно быть полноценным, так, например, обработка массивов - полезная вещь. И не надо мне говорить, что в схемах массивов нет. В обычных электронных схемах и переменных, как таковых нет, но могут быть регистры в памяти запоминающих устройств, и можно использовать смещения регистров, что, собственно, и является массивом.
3. Выполнение программы так или иначе - линейно (давайте не станем углубляться в принципы работы таймеров), потому и есть возможность расставлять приоритеты выполнения, что, к слову сказать, выглядит весьма коряво, ибо я уже, чисто по схеме, не могу понять - что же у меня происходит, если не наблюдать заданный порядок выполнения.

А пока все выглядит так, как если компьютер использовать исключительно в целях калькулятора.

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

[Николаев Андрей]

Вот текущая тема про конкретную возможность: импорт программы в ОЛ из какого-нибудь псевдо-языка.
Или так: возможность управлять ОЛ из сторонних приложений, например, по REST/Thrift (ну, чтобы сторонний софт мог управлять ОЛ и добавлять блоки/связи и т.п.)
Тема годится как "обсуждение новой функции ОЛ"?

Какой формат "обсуждения" предлагается? Голосование где-то? JIRA?

Очень хорошая тема для обсуждения.
Голосование можно организовать и на форуме ОВЕН, но конечно достоверность не та, не та ))))))))))

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

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

Очень хорошая тема для обсуждения.
Голосование можно организовать и на форуме ОВЕН, но конечно достоверность не та, не та ))))))))))

Возможность "автоматизировать ОЛ" мне кажется даже более полезной, чем возможность "программировать на ASM для ПР" (хотя, конечно, для написания нормального fSEL всё равно нужен ASM).
Как раз в таких случаях (когда голосуют за приоритеты) Шульце и помогает: все выбирают "желаемый приоритет", а потом подсчитывают что же реально самое важное.
На форуме, вроде, нельзя при голосовании указать "самое важное -- это, затем -- то, и т.п."

Правда финальное определение опций которые появятся \ появятся в других версиях \ не появятся вовсе, как Вы понимаете, ОВЕН оставляет за собой.

Это само собой.

[capzap]

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

[rovki]

И да стоимость проекта в целом настолько весома, что цена между ПР и плк пустячок

Как пить дать .если заниматься реализацией проектов ,а не абстрактно хотеть в потенциале .Уже все средства есть в Овен ,бери и делай ,на любой вкус .И среда заработки есть кодесис (покупная) и своя -ОЛ- на любой вкус .Зачем еще мешаниной заниматься ,напрягать разрабов ради экономии 5-10тыс для поиграться .В цене системы управления или технологического оборудования цена ПР,ПЛК менее 10%.Хочешь сэкономить на разнице ПР-ПЛК изучай ОЛ. Не нравиться ОЛ купи ПЛК63 и любимый кодесис ....Из пустого в порожнее уже несколько месяцев обсуждаем хотелки любителей (кто не использует и не продает) .

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

Можете свою мысль понятно выразить?

создавать интерпретатор ради использования того языка которым владеет конечный пользователь это смешно

Вот вам пример: OwenLogic. Там разработчиками ОВЕН создан язык FBD (или как там называются эти квадратики, на которых программируется ПР). Это как раз пример языка (и интерпретатора), которым владеет "конечный пользователь" == rovki/capzap/и т.п.
Вы говорите, что "это смешно". Я ни разу не соглашусь. Смысл создания нормального языка как раз и есть в том, чтобы этим языком владел пользователь.

давай настаивать что лучше именно так как они советуют и самое главное только они умеют

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

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

А если серьезно, то, так как ОВЕНовцы не раскрывают внутренний формат программ для ПР, то могу лишь предполагать, что внутри реле записывается именно как связи и логические элементы

Разумеется, никаких логических связей внутри там нет. Простой процессор, с простыми инструкциями.
Подсказывать почему "ОВЕНовцам может быть тяжело/неудобно раскрыть формат" не буду (можно в личке), иначе ПРщики сразу станут на эти аргументы напирать.
Могут быть реальные причины (как технические, так и нет), поэтому я и говорю, что "возможность управлять OwenLogic'ом по протоколу thrift" выглядит более перспективной. Она позволит с одной стороны "залить любую программу" (ну, внешний транслятор может превратить ST язык в ОЛ блоки), и, с другой, система останется достаточно гибкой. Но, конечно, скудность базовых блоков надо отдельно решать.

Другое дело, что есть еще несколько моментов:
1. Можно взять или придумать какой-нибудь мнемоязык

Идеального языка нет. Сила в использовании наиболее подходящего под задачу языка.
Бывает, 2-3 квадратика проще, чем те же самые 3-4 строки ST (просто виднее откуда куда связи идут).

Вне зависимости от языка, использование мощностей ПР должно быть полноценным, так, например, обработка массивов - полезная вещь

Про массивы спорное утверждение. Не в каждом языке массивы будут логично смотреться.
Полезны ли массивы? -- полезны
Нужны ли в виде "блок записи значения в массив"? -- вопрос (может, нужны, а может, и нет), ведь, так можно докатиться и до функционального блока на каждую ассемблерную команду, и это уж точно жесть.

А пока все выглядит так, как если компьютер использовать исключительно в целях калькулятора.

Да, так и есть.

[rovki]

Не ,ну двое это уже перебор

[capzap]

Можете свою мысль понятно выразить?


Вот вам пример: OwenLogic. Там разработчиками ОВЕН создан язык FBD (или как там называются эти квадратики, на которых программируется ПР). Это как раз пример языка (и интерпретатора), которым владеет "конечный пользователь" == rovki/capzap/и т.п.
Вы говорите, что "это смешно". Я ни разу не соглашусь. Смысл создания нормального языка как раз и есть в том, чтобы этим языком владел пользователь.


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

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

советы тех кто умеет, как правило, лучше, чем советы тех, кто "понаслышке"

еще раз повторю, я не буду писать на АСМ, придуманном интерпретаторе или чем то еще, поэтому и советы бывалых мне не понадобятся

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

я не писал на ассемблере, дальше вузовского курса

Во-первых, ассемблер и не планируется для "написания людьми". Ассемблер -- как средство интеграции программ. Никак не для человека.
Ещё раз: если ОЛ сможет загружать ФБ, написанные на ASM, то можно отдельно от ОЛ сделать программу, которая хоть ST, хоть "более лучший" FBD будет в asm превращать и в ОЛ/ПР загонять.

я не буду писать на придуманном интерпретаторе

Во-вторых, к сожалению, сейчас все пользователи ПР вынуждены писать на придуманном ОВЕН интерпретаторе. Любой, кто пользуется ОЛ, по факту, пишет на придуманном интерпретаторе. Так что ваш аргумент мимо.

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

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