PDA

Просмотр полной версии : Компилятор



Devoter
28.06.2016, 02:44
Здравствуйте, поискал - не нашел такой темы на форуме, потому, в случае чего - сильно не бейте. В общем, пишу проект для ПР200. И выявил ряд существенных недостатков среды. Писать нормальные программы, пусть даже и с учетом ограничений принципа работы ПР, достаточно сложно. Мне понадобился массив из 56 элементов, в результате пришлось делать 56 переменных + работа с таким количеством однотипных переменных просто ужасна и трудоемка, что никак не отвечает концепции "легкой разработки". Не хватает оператора СТОП, чтобы остановить вычисления при FALSE, например; также очень хотелось бы, кроме макросов, получить еще и функции, отличие которых заключалось бы в привязке к конкретному проекту без возможности экспорта, но с доступом к глобальным переменным проекта - это существенно упростит некоторые этапы разработки. Конечно, не хватает классических ветвлений и аналога switch, хотя ограниценную реализацию последнего я уже сделал. В общем, хотелось бы выразить огромную просьбу разработчикам: опубликовать компилятор отдельно от OWEN Logic. Просто многие операции, в том числе - работа с массивами, условные переходы и т.п. я гораздо быстрее написал бы на ассемблере.
Даже не знаю, как правильно выразить свою мысль. Я прекрасно понимаю, что код программы генерируется посредством разбора схемы и трансляции токенов в машинный или объектный код. Собственно, мне даже не обязательно иметь ассемблер, пусть это был бы транслятор из токенов - транслятор в какой-нибудь язык я напишу сам, но было бы очень удобно иметь возможность писать программу на императивном языке, пусть даже на асме.
Есть еще одна задумка: конвертер из схем в исходный код и обратно, но это - уже совсем другая история. Здесь уже потребуется описание отличий owl от обычных диаграмм nevron.
Полагаю, компилятор + мой транслятор позволили бы большему кругу людей писать программы для ПР, причем, гораздо быстрее во многих случаях.
С уважением, и надеждой на понимание, ваш пользователь и клиент.

Алексей Геннадьевич
28.06.2016, 07:06
http://www.owen.ru/forum/showthread.php?t=23740

http://www.owen.ru/forum/showthread.php?t=23557

http://www.owen.ru/forum/showthread.php?t=23754

http://www.owen.ru/forum/showthread.php?t=23707

rovki
28.06.2016, 07:09
Очень вас жаль "...в результате пришлось делать 56 переменных..".ОЛ это совсем не то что вы умеете и хотите .ОЛ для тех кто пишет и читает СХЕМЫ .Есть ПЛК63 ,73 там среда разработки именно та ,что вам подходит -стопы ,ветвления ,,,то что вы любите и воспринимаете - кодесис , зачем еще ПР200 туда подтягивать .Раз есть разные специалисты пусть будут и разные среды ...
Вы случайно не двойник Ситникова :confused:

Devoter
28.06.2016, 12:17
Прошерстил темы, указанные в ссылках - теперь знаю - кто такой Ситников ) . Понятное дело, что есть ПЛК, но многие задачи вполне себе корректно решаются и без оного, а цены "немного так" отличаются. Там где нет необходимости в скоростных точных вычислениях - ПР более чем достаточно. Да, возможно, что тут больше подошел бы какой-нибудь функциональный язык, нежели императивный. Да и вообще, пусть хоть свой запилят, только, боже упаси, без русских ключевых слов. Просто реально, устройство хорошее, вычислительных мощностей более, чем достаточно, но средство разработки тупо бьет по рукам. Остается только спросить: правильно ли я понимаю, что никакого стандарта импорта/экспорта проектов в/из OL нет и не будет, и что тоже самое касается конечного формата программы для ПР - его тоже никто не раскроет? Врочем, меня больше интересует импорт/экспорт все же. Если все так, то остается два выхода:
1. Забыть, забить и жить дальше.
2. Взяться за usb-сниффер.

Алексей Александрович
28.06.2016, 12:24
Есть еще один выход "НАЧАТЬ УЧИТЬСЯ"

Владимир Ситников
28.06.2016, 12:54
Да и вообще, пусть хоть свой запилят, только, боже упаси, без русских ключевых слов. Просто реально, устройство хорошее, вычислительных мощностей более, чем достаточно, но средство разработки тупо бьет по рукам.
Тут, кстати, не только ОЛ по рукам бьёт, но и форумчане тоже не отстают =)
Бывает, забывают, что в правилах запрещены мат (в том числе прикрытый звёздочками) и оскорбления.


Остается только спросить: правильно ли я понимаю, что никакого стандарта импорта/экспорта проектов в/из OL нет и не будет, и что тоже самое касается конечного формата программы для ПР - его тоже никто не раскроет? Врочем, меня больше интересует импорт/экспорт все же.
Вот тут Владислав пока не ответил (шанс ответа, думаю, есть): http://www.owen.ru/forum/showthread.php?t=23013&p=213248&viewfull=1#post213248
Тут Максим пишет среда OwenLogic развивается (http://www.owen.ru/forum/showthread.php?t=23740&p=205320&viewfull=1#post205320)

Но я не особо спрашивал, т.к. ПР меня мало интересуют (неудобность ОЛ это один из факторов).



2. Взяться за usb-сниффер.
Если для себя -- то можно.
Если где-нибудь выкладывать, то это нарушение закона об авторском праве (~ декомпиляция/анализ с целью создания дубликата законом запрещена).

Принимать pull request'ы ОЛ тоже пока не готовы (см. "OwenLogic развивается" выше)

rovki
28.06.2016, 12:54
Экспорт обещали -загрузочный файл без возможности редактировать

Devoter
28.06.2016, 14:59
Есть еще один выход "НАЧАТЬ УЧИТЬСЯ"
А чему учиться-то? Булевой алгебре? Дискретной математике? Проблема не в том, чтоб инструмент освоить, проблема в ограниченности этого самого инструмента.


Тут, кстати, не только устройство по рукам бьёт, но и форумчане тоже не отстают =)
Я говорил не об устройствах, а о средствах разработки.


Экспорт обещали -загрузочный файл без возможности редактировать
Ну вот экспорт меня мало интересует, скорее, импорт. Понятно, что можно поковыряться - разобрать выходной файл, но тратить на это время только потому, что ОВЕНовцы не хотят раскрывать свои форматы смысла не вижу. С тем же успехом можно тогда и ПЛК писать или Ардуино. Просто мне не очень понятно: зачем давать устройству такие технические характеристики, как куча памяти под кучу переменных, если их нет возможности нормально эксплуатировать.

Владимир Ситников
28.06.2016, 15:05
Я говорил не об устройствах, а о средствах разработки.
Точно. Поправил. Разумеется речь о средствах разработки.

игорь68
28.06.2016, 23:07
Автору темы посмотрите на название. Это как вам и говорят выше что ПР это РЕЛЕ. И средства разработки ОЛ тоже делался под РЕЛЕ. Да есть пара вещей которые работаю и ЭТО НЕ ЗНАЧИТЬ ЧТО МОЖНО ТРЕБОВАТЬ ОТ РЕЛЕ ВОЗМОЖНОСТЕЙ ПЛК. И средства разработки нужны для работы с РЕЛЕЙНЫМИ СХЕМАМИ а не с набором математических формул. Вы это понимаете или нет.

Владимир Ситников
28.06.2016, 23:27
Автору темы посмотрите на название. Это как вам и говорят выше что ПР это РЕЛЕ. И средства разработки ОЛ тоже делался под РЕЛЕ. Да есть пара вещей которые работаю и ЭТО НЕ ЗНАЧИТЬ ЧТО МОЖНО ТРЕБОВАТЬ ОТ РЕЛЕ ВОЗМОЖНОСТЕЙ ПЛК. И средства разработки нужны для работы с РЕЛЕЙНЫМИ СХЕМАМИ а не с набором математических формул. Вы это понимаете или нет.

На заборе тоже написано, а там дрова лежат. Аргументация "это вам не ПЛК, а РЕЛЕ", конечно, всё решает.

Нужны нормальные средства разработки -- это факт.

Woolfy
29.06.2016, 06:02
Программируемые РЕЛЕ предназначены для программирования электриками (составление схем). Для себя требуйте от разрабов ОЛ функционального блока "Логический", как в Альфе. 25177 Разумеется, с учётом нынешних реалий. А то они мощу в ПР200 - то воткнули, а вот пользоваться пока не умеют...

Алексей Александрович
29.06.2016, 06:13
На заборе тоже написано, а там дрова лежат. Аргументация "это вам не ПЛК, а РЕЛЕ", конечно, всё решает.

Нужны нормальные средства разработки -- это факт.
Странно. Если Вы возьмете в руки программируемый калькулятор и жалуетесь что такой бедный функционал. Аргумент что это калькулятор а не пк Вас тоже не устроит. Зачем тогда взяли :confused:
Среда ОЛ разрабатывалась для тех кто знает цифровую схемотехнику. Возьмите учебник (есть даже для школьников) и будет Вам счастье.
Видимо вы никогда не паяли на макетках примитивные цифровые автоматы на низкоуровневой логике. Иначе ПР Вам бы показался чудом техники.
Переходите на промышленные ПК и не морочьте голову.

rovki
29.06.2016, 07:59
Переходите на промышленные ПК и не морочьте голову.
Согласен .С таким маниакальным упорством требовать сделать то что кажется одному ,двум пользователям удобным и не видеть тысячи благодарных потребителей, это о чем то говорит .Это элементарный анализ ,даже в википедию не ходи...

Алексей Геннадьевич
29.06.2016, 08:29
На заборе тоже написано, а там дрова лежат. Аргументация "это вам не ПЛК, а РЕЛЕ", конечно, всё решает.
Именно так, решает.
У каждой вещи есть своя область применения.


Нужны нормальные средства разработки -- это факт.
Есть затраты на разработку среды, то что вы хотите - это ПЛК. С большими затратами на среду разработки, итд итп.
ПР с ОЛ может и ПТУшник использовать, который при одном виде кодесиса просто обосрётся со страха.
Или до вас не доходит, что Физтех и ГПТУ№хх дают разный уровень образования, мягко говоря?
И то, что для вас элементарно- другой человек (неплохой спец в своей области) просто не осилит?
Что есть такое понятие как "уровень входа" - в вашу хотелку, супер-среду разработки, не смогут многие инженера?
И защита от ошибок в электроавтоматике имеет больший приоритет, чем скорость создания кода?

Владимир Ситников
29.06.2016, 09:53
Если Вы возьмете в руки программируемый калькулятор и жалуетесь что такой бедный функционал
А вот не надо в другую плоскость уходить.
Калькулятор != ПР.



Среда ОЛ разрабатывалась для тех кто знает цифровую схемотехнику
Вот прямо так? Только для тех, кто "цифровой схемотехник"? А тем, кто знает _и_ схемотехнику _и_ программирование что делать? Страдать? Или переплачивать в 5-50 раз за ПЛК/пром ПК?


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

Николаев Андрей
29.06.2016, 10:05
Господа, хватит срач устраивать во всех ветках.
Позиция и одних и других понятна и имеет место быть.
Одни занимаются больше прикладными задачами и им нужна стабильность.
Вторые двигают науку и технику вперед, пытаясь расшатать сложившиеся устои. Это тоже нужно.

Делать CODESYS из OL в ближайшей перспективе не планируется. Добавлять новые функции - давайте обсуждать. В соответсвующих темах. Сейчас как раз самое время обсуждать что добавить в OL, что бы он оставался удобрым и понятным для практиков, но имел новые полезные функции. Но без шапкозакидательства, типа "да на этом железе спутник можно запустить, а вы мне не даете построить базовую модель на сетях Петри".

Владимир Ситников
29.06.2016, 10:11
Именно так, решает.
У каждой вещи есть своя область применения.
Некоторые, вон, на ПР делают полив теплицы. Как это связано с цифровой схемотехникой ума не приложу.
В общем: не нужно путать ПР и ОЛ. Мы говорим здесь исключительно про ОЛ.
Уместность применения ПР это отдельный вопрос. Управлять космическим кораблём на ПР неуместно (сами понимаете, ионизируют там всякие). А поливать теплицы -- вполне. При этом, крайне неприятно, когда "уместность применения ПР" ограничивается рамками ОЛ. Не исключаю, что мне самому ПР хватило бы. Но, нет, рисовать квадратики не моё, поэтому приходится платить за КДС.

Заметьте: когда я плачу за КДС, деньги идут в 3S. Когда я покупаю ПР -- деньги идут в ОВЕН. Второе мне больше нравится.




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



С большими затратами на среду разработки, итд итп.
Во-вторых, тоже нет.
См. предыдущий пункт -- там вообще минимальные затраты на доработку ОЛ.


ПР с ОЛ может и ПТУшник использовать, который при одном виде кодесиса просто обосрётся со страха.
В-третьих, про "ST-подобные" конструкции есть отдельная тема, но раз уж вы упомянули КДС, то замечу, что от наличия "блока ST" в ОЛ этому самому ПТУшнику ни тепло ни холодно.
Этот самый ПТУшник как использовал 2-3 блока в ОЛ, так и продолжит. Для ряда задач будет удобнее ST-блок -- его и будут использовать те, кому нужно в задаче, где ST реально больше подходит.

Порог вхождения никак не меняется. Вообще никак. Всё остаётся ровно так, как сейчас.


Что есть такое понятие как "уровень входа" - в вашу хотелку, супер-среду разработки, не смогут многие инженера?
И защита от ошибок в электроавтоматике имеет больший приоритет, чем скорость создания кода?
Если вы про Hardella IDE (http://www.owen.ru/forum/showthread.php?t=23013), то давайте продолжим в теме про Hardella IDE (http://www.owen.ru/forum/showthread.php?t=23013).

Владимир Ситников
29.06.2016, 10:25
Делать CODESYS из OL в ближайшей перспективе не планируется. Добавлять новые функции - давайте обсуждать. В соответсвующих темах. Сейчас как раз самое время обсуждать что добавить в OL, что бы он оставался удобрым и понятным для практиков, но имел новые полезные функции. Но без шапкозакидательства, типа "да на этом железе спутник можно запустить, а вы мне не даете построить базовую модель на сетях Петри".

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


Какой формат "обсуждения" предлагается? Голосование где-то? JIRA?
Для голосования есть такая платформа: https://modernballots.com/ (там используется метод Шульце подсчёта голосов (https://ru.wikipedia.org/wiki/%D0%9C%D0%B5%D1%82%D0%BE%D0%B4_%D0%A8%D1%83%D0%BB% D1%8C%D1%86%D0%B5), что правильнее, чем просто считать голоса)

Алексей Александрович
29.06.2016, 10:32
Стоит пьяный в луже и держится за столб. В луже мальчик пускает кораблик. Мальчик "дяденька подай кораблик". "Вот сейчас все брошу и подам"

Devoter
29.06.2016, 11:30
Ой, все )))

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

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

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

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

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


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

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

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


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

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

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

Владимир Ситников
30.06.2016, 17:13
Можете свою мысль понятно выразить?


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


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

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


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


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


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

rovki
30.06.2016, 18:34
Не ,ну двое это уже перебор ;)

capzap
30.06.2016, 19:00
Можете свою мысль понятно выразить?


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


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

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

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


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


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

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

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

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

rovki
01.07.2016, 08:18
А чем Вас не устраивает ПЛК 63(73) ?

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

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

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

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

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

Второе.

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

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

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

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

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

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

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

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

Евстигнеев Максим
01.07.2016, 14:33
При выборе языка советую обратить внимание на ДРАКОН.

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

Алексей Геннадьевич
01.07.2016, 14:55
Боюсь, язык "Дракон" затруднит продажи продуктов в странах Европы ... европейские пользователи не поймут.
:o
Он удобнее чем CFC. И понятнее.

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

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

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

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

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

rovki
01.07.2016, 18:28
мастак вы по википедиям (теоретик).Кружочки ставились только по выходам , на входах нет .Откройте любой справочник по ИС на элементы .
Поэтому инверсию по выходу приветствую ,потому как она одна в элементах ,а не в куче входов.Активный уровень сигнала по входам обычно оговаривался в описании ,но иногда на обозначении ,например входа R,S на триггерах .

Владимир Ситников
01.07.2016, 18:38
мастак вы по википедиям (теоретик).Кружочки ставились только по выходам , на входах нет .Откройте любой справочник по ИС.
Поэтому инверсию по выходу приветствую ,потому как она одна в элементах ,а не в куче входов

Если у вас какие-то свои ГОСТ'ы, что ж, жаль вас.

Во-первых говорилось про выходы.

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

Во-вторых, по ГОСТу предусмотрено инвертирование как входов, так и выходов.
Не я первый про ГОСТы заговорил. А сейчас уже "справочник по ИС". А что, если и в справочнике по ИС будет сказано про инверсию как входов, так и выходов?
О где тогда "искать" будем?

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

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


мастак вы по википедиям (теоретик).Кружочки ставились только по выходам , на входах нет .Откройте любой справочник по ИС на элементы .
Поэтому инверсию по выходу приветствую ,потому как она одна в элементах ,а не в куче входов.Активный уровень сигнала по входам обычно оговаривался в описании ,но иногда на обозначении ,например входа R,S на триггерах .

А я вот 35 лет схемы рисую.:rolleyes:
Анатолий, кружочки на входах и выходах - это по госту. И в справочниках по МС, к стати, так и есть.
Вот пару штук советских МС.
25231

игорь68
01.07.2016, 19:13
ROVKI было несколько ИС где есть инверсия входа. Вот к155ид4 входа А1 А2 А3 А4 инверсный вход.

petera
01.07.2016, 19:26
И тут никак без кружочков
25232

rovki
01.07.2016, 20:34
В логике не помню что бы были ,а по цепям управления были ,уже запамятовал ,точнее ОЛ перевнущило за 5 лет ;).А ведь когда то помнил все номера ножек на память ...Даже забыл что рисую их уже с 73 года - это получается 43 года :eek:

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

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

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