Здесь у кого-то в подписи есть хороший ответ на Ваши "проблемы".Сообщение от Владимир Ситников
Здесь у кого-то в подписи есть хороший ответ на Ваши "проблемы".
Хмм.. странный вопрос, по крайней мере для меня. Вы соц. опрос делаете?
Допустим я вам дам 100к и вы сделаете, овен продаст, все будут пользоваться, мне это зачем?
Это наверное вопрос к ОВЕН, как предложение.
А вы уже готовы приступить к реализации есть всё для этого?
Вопрос насколько же странный, насколько было ваше "Всё написанное не имеет смысла".
Написанное имеет очень простой смысл: я пытался объяснить melky то, что парсинг формул это непростая задача. Вы же в ответ пишете, что я "учёный" и всё не имет смысла. Где логика-то?
Ок, уже что-то.
Это, конечно, мешает оценивать. Ну, кто знает. Вдруг будете делать какой-нибудь "самописный ПИД".
Печально то, что некоторые пишут "сделать легко", а на вопрос "а за сколько рублей вы такое сделали бы" молчат.
Ну, одно дело, когда народ описывает абстрактные хотелки, а другое, когда они хоть как-то понимают или пытаются понять сложность этих хотелок.
Очень правильный вопрос. Но я не знаю, что тут можно ответить. Если накопить финансирование, то можно будет сказать, что "есть всё".
Если же средств не будет, то и соблазнить ОВЕН едва ли получится.
Моя мысль была в том, что вариант с p-code проще в реализации по сравнению с "блоком-формулой", и этот самый p-code откроет больше новых возможностей.
Например, p-code откроет возможность "автоматического тестирования" программ. Например, Алексей Геннадьевич много раз говорил, как он "любит" "выводить ОЛ-схему на режим", чтобы проверить как она работает.
ОВЕН, судя по всему, идут по пути "макросов на языке C". С одной стороны интересно что (не)получится, а с другой несколько печально.
Пока реализовывал свой первый контроллер управления ТА и БКН от ТТ котла на ПР200, с большим удовольствием читал эту ветку и осознавал что не зря взял ПР.
По сути, то, чем идет дискуссия уже реализовали чехи из rexcontols. FBD+блоки, внутри которых код на С/Java подобном языке. Правда платформа - малина. Вот описание FBD https://www.rexcontrols.com/media/do.../BRef_ENG.html
Вот собственно описание блока https://www.rexcontrols.com/media/do...#x262-26100015
С учетом того, что они используют статическую типизацию, проблем с выводом типа результата не возникает.
А потомучто ответить на вопрос "за сколько" может только ОВЕН.
Вот поэтому, "всё написанное бессмысленно". И те, кто пишет "легко", и те, кто пишет "очень трудно", основывают свои "оценки" на своих же фантазиях. Больше не на чем, т.к., ни то что "исходников", но и внутренней идеологии ОЛ никто не знает.
Есть там в явном виде p-код, льющийся в ПР или как "промежуточный этап" в ОЛ, или нет его вообще, а есть "набор функций" в прошивке, и ОЛ собирает сразу исполняемый код.
"Макросы на С" отдавать пользователю - это вообще бессмысленно. Во-первых, это "более высокий уровень пользователя", во-вторых, в таких макросах пользователю можно давать доступ только к конкретным, стандартным "пользовательским функциям". Т.е., "более низкого уровня программирования" не получится - доступ к железу каждого "говнокодера"- это смерть "промышленной" идеологии. И при даче в руки пользователю С, хрен отсечёшь его от того, что "давать нельзя". Это если полноценный С, непосредственно компилируемый в исполняемый код, а в противном случае - это не С, а С-подобный костыль - тот же скрипт на языке "низкого уровня" для "высокоуровневого пользователя" - вобщем, бессмыслица.
На "низком уровне" берёшь ПР, смотришь потроха, и льёшь свой код для СТМ-ки. К идеологии "промышленного ПР" это никакого отношения не имеет.
Просто адаптированная к промприменению железка в качестве "конструктора на СТМ". Оно кому-то надо? Да никому.
^^^ это ваши фантазии.
А вот производитель подтверждает мои "фантазии"
Молодца. Всё именно так.
Грубой оценки достаточно. Не корову продаём.
Когда народ просит доработок в ОЛ, они всё равно интуитивно прикидывают "насколько сложно" для ОВЕН это будет.
Например, сложность "добавления ST редактора в ОЛ" слабо зависит от текущих исходников ОЛ. И так и сяк уйма времени.
Так и тут. Блок-формула сопряжена с дополнительными расходами ресурсов (по сравнению с p-блоком) вне зависимости от текущей архитектуры ПР-ОЛ.
Тем и интереснее смотреть за тем, что за "С-подобный костыль" получится.
Владимир Ситников еще раз, формулы НЕ НАДО парсить, надо всего лишь определить, что нет ошибок в ее записи.
Если поставили переменные int, не должно быть точек (тупо не давать вводить точку или запятую при вводе), что человек установил парные скобки
Хотя опять же, все зависит как сейчас сделаны FBD блоки в ОЛ и как они интерпретируются им в код ПР.
Любой язык высокого уровня запись формулы выполняет на раз два без вашего участия, кроме как ее записать, тем более если она будет ограничена типами переменных.
з.ы. еще раз скажу, не надо делать парсинг "А вы уверены, что эта скобочка здесь? а знак умножить тут ?"
И как вы без парсинга собрались определять отсутствие ошибок?
Да ладно? Сколько будет "два плюс два умножить на два"? Восемь? Или все-таки шесть? По каким правилам Вы это определили?
Что нельзя запрограммировать- приходиться паять.
вот цитата, она относится ко всему
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Ваши права
