Возможность программирования на более низком, чем ОЛ схемы уровне

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

т.е. Вы поддерживаете, что была эта самая проверка на корректность записи формулы это не просто пофиксить ба

Разумеется, делать язык с нуля это непростая задача. Разумеется, простых + - будет недостаточно. Даже потом вкрячить "приведние int-float-int-bool-date-..." уже не так просто. Вкрячить "вызов макросов" (куда же без этого?) -- тоже непросто (даже чисто технически, без оглядки на маркетологов).
Разумеется, если захотеть, то вкрячить можно что угодно куда угодно, но тут мы обсуждаем не несущую зубочистку, а решение которое можно было бы поддерживать хотя бы 5 лет.

Я и говорил, что, если делать, то не блок-формулу, а p-code блок (IL блок). С p-code таких проблем нет. Там проверки правильности гораздо проще, т.к. каждая команда уже почти готова к выполнению. С расширяемостью гораздо проще и т.п.
Да, на IL гораздо сложнее писать (возможно, в большинстве случаев будет сложнее, чем на FBD), но это не страшно, т.к. кому надо те напишут. А уж конверторов в этот самый IL потом можно всех мастей сделать (хоть внутри ОЛ, хоть вне ОЛ).

а вполне серьезная работа которая за день не делается

Я уже приводил свои оценки, сколько займёт прикручивание p-code блока в ОЛ:

Итого 7 мифических человеко-недель = 1.5 (формат) + 0.6 (блок) + 1 (чтение) + 1 (запись) + 1 (компилятор) + 1 (симуляция) + 1 (документация)

[melky]

capzap ОЛ вроде как написан на C#, а там как и во многих языках все математические функции уже присутствуют.
А исходники самого ОЛ мне никто не даст, так что осталось дело за самими разработчиками, имея на руках то, что есть, сделать плагин формул для макросов при их создании.

По мне, пусть хотя бы начнут с + - * и / с учетом типа int и float применительно к ОЛ. Если что-то начнет получаться, дать исходники плагина людям, авось и косинусы с тангенсами прикрутят.

[pop70]

capzap ОЛ вроде как написан на C#, а там как и во многих языках все математические функции уже присутствуют.
А исходники самого ОЛ мне никто не даст, так что осталось дело за самими разработчиками, имея на руках то, что есть, сделать плагин формул для макросов при их создании.

По мне, пусть хотя бы начнут с + - * и / с учетом типа int и float применительно к ОЛ. Если что-то начнет получаться, дать исходники плагина людям, авось и косинусы с тангенсами прикрутят.

Тут всё не так просто.
Функции языка, на котором написан ОЛ тут непричём.
C# получит формулу в виде строки символов. А считаться эта формула должна функциями, заложенными в контроллер.
Т.е., строку нужно будет "распарсить" (прочитать и перевести в последовательность команд, понятную уже софту контроллера).
Задача не то чтобы суперсложная, но и не простая.
А поддержку функций необходимо будет добавлять в прошивку ПР.
То, что умеет c# - он умеет только на компьютере, но не на контроллере.

[melky]

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

Было бы желание как говорится. Банально символы можно проверять на этапе ввода для простых мат функций. чекбокс предусмотреть на будущее (с проверкой/без проверки) ввода. Останется только скобки проверить, что все пары на месте. Писал уже выше, саму логику проверять не надо, это останется на совести писателя.
А при добавлении функций в дальнейшем, проверить текст cos, tan, pi и так далее тоже не составит труда

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

pop70 наверное я вас удивлю, но программу вы РИСУЕТЕ на обычном ПК, а уж распарсить строку ему под силу и перевести макрос в понятный вид согласно последовательности математических действий, выделенных скобками и записать это в прибор думаю тоже под силу.

А теперь сравните это с тем, что вы говорили выше:

ОЛ вроде как написан на C#, а там как и во многих языках все математические функции уже присутствуют.

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

Вот вам свежий пример. Есть язык программирования Ceylon. Язык появился в 2011, и его продвигает RedHat. В 2016-ом нашли ошибку, что в этом языке неправильно распознаются float значения. Значение 1.01 обрабатывается как 1.1.
Ага, это в 21-ом веке. И над языком работал более чем 1 программист. И всё равно такую ошибку пропустили.

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

А при добавлении функций в дальнейшем, проверить текст cos, tan, pi и так далее тоже не составит труда

Ну, да, конечно. Пользователи все как один начнут писать "sin(tan)" или "sin*pi" или "sin(true)". Проверка правильности и выдача вразумительного сообщения об ошибке это не такая простая задача как вам кажется.

Некая аналогия -- запрет циклов в ОЛ схемах. В 1.9 запретили, и всё равно возникают вопросы "а чего это у меня ОЛ ругается?".
Т.е. сделать ошибку "у вас программа кривая" мало. Нужно делать вразумительные сообщения.

[capzap]

вообще я пытался добиться от мелкого, чтоб он на мое предложение не высказал позицию: моя хата с краю, пусть овен сделает, а условный Ситников добавит туда функционал, а сам скажет не вопрос, вот сделал, тестируй.
Во вторых, предложил я задачу, чтоб осмыслить масштаб такой самостоятельной работы, потому что у каждой среды разработки есть свой FindBugs и любой текст гипотетически можно обработать не изобретая велосипед
Только вот следующим встанет вопрос, как этому тексту эволюционировать в исполняемый код, на данный момент есть интерпретатор из графического языка в код понимаемый процессором, В.Ситников об этом много написал. И даже если формула будет банальной, простой или еще как то там, всёравно придется писать абстракцию, переводящую текст в некий п-код

[pop70]

pop70 наверное я вас удивлю, но программу вы РИСУЕТЕ на обычном ПК, а уж распарсить строку ему под силу и перевести макрос в понятный вид согласно последовательности математических действий, выделенных скобками и записать это в прибор думаю тоже под силу.

ПК сам ничего не делает. Делает программист.

[pop70]

Как верно заметил capzap, подобным "распарсиванием" можно заниматься "вплоть до выхода на пенсию"

Не нагнетайте. Эту задачу уже множество раз решали. Есть и в сети примеры. Не боги горшки обжигают. У программиста, написавшего ОЛ, на это мозгов уж точно хватит. Было бы желание.

[melky]

Владимир Ситников и чего ? в C# тоже до сих пор есть ошибки, никто же не ноет, просто обходит их, нарвавшись.

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

[capzap]

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

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