Для этого надо понимать полную структуру ОЛ.
Лично для меня будет очень удивительно, если ОЛ код преобразует в графику, потом при записи в ПР графику опять преобразует в код, это тогда не программа, а какой-то горе продукт получается....
Для этого надо понимать полную структуру ОЛ.
Лично для меня будет очень удивительно, если ОЛ код преобразует в графику, потом при записи в ПР графику опять преобразует в код, это тогда не программа, а какой-то горе продукт получается....
Вы не обращали внимание что простые проекты с расширением owl занимают мегабайты, проект хранится , как вы написали в виде картинки, возможно с сеарилазцией, а компиляция в машинный код идет в ОЛ параллельно или вообще только при заливкеСообщение от melky
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Обращал, вот это то и пугаетидиотский подход....
А кого сейчас волнует объем? Вот в КДС 3 то же самое.
И то, что у вас "всё просто", всего-навсего, нужно сделать парсер, компилятор, симулятор. Всего-навсего нужно обойти ошибки в C#. Всего-навсего нужно добавить операции +-/* и скобки, а потом всего-навсего нужно добавить функции, ведь найти sin вообще не составляет труда. А потом всего-навсего добавить поддержку даты, времени, знаковых чисел, битовых операций, массивов. В чём сложность-то вообще?
Так не работает. По сути, вы игнорируете все аргументы, и остаётесь при своём мнении "и так далее тоже не составит труда".
У меня в таком случае 2 вопроса:
1) Готовы сами сделать то, что по-вашему "не составляет труда"? Ну, парсер, валидатор, симулятор, поддержку обратной совместимости (так, чтобы в будущих версиях ОЛ старые формулы открывались и работали), понятные сообщения об ошибках. Потом, наверное, не составит труда добавить формулы и знаковые типы.
Сколько фактического времени у вас это займёт? Неделя? Месяц? Год?
2) Сколько денег по-вашему стоит пункт #1? Грубо говоря, если делать будете не вы, то сколько вы готовы заплатить программисту и за какой срок вы ожидаете от него реализацию?
Возможно, у нас просто разные понимания слов "не составляет труда". Если что-то занимает год, то для меня это уже "составляет труд". А, возможно, для вас 10млн руб и 2 года работы это "не составляет труда".
Судя по прошлому обсуждению, в ОВЕН существует внутренний язык типа IL для ПЛК/ПР. Там фиксированный набор инструкций, псевдо-ассемблер такой, а в каждом конкретном ПЛК/ПР стоит интерпретатор. ОЛ преобразует графику в программу в виде последовательности этих инструкций. Потом эта программа по протоколу заливается в прибор. При проектировании каждого нового ПЛК/ПР, для его железа разрабатывается системный софт, в который входит интерпретатор и поддержка загрузки-выполнения. Поскольку они пишут этот софт на С - перенести на другой контроллер проблема небольшая. Получается в итоге удобная ситуация, когда железо и инструментальную среду можно разрабатывать/менять независимо - их объединяют только система команд и протокол загрузки. Однако попытки изменить/расширить эту систему приводят к большим проблемам. Стоит изменить систему команд, возникает проблема с поддержкой ранее выпущенных устройств. Каждый ПЛК/ПР должен уметь распознавать код команды, который он не может интерпретировать, но даже если так - чем он её заменит? Поэтому инструментальная среда должна учитывать особенности конкретной модели и генерировать итоговый код, содержащий или не содержащий какие-то определенные команды. А это значит что система перестает быть аппаратно независимой, а именно для этого её и создавали. Единственной проблемой, для того чтобы вставить в макросы тот же С, является тот факт что нужен будет компилятор с С на специфический IL, а использовать распространенные компиляторы из С сразу в коды микроконтроллера нельзя - там нет С, пригодного для этого компилятора. Единственным дешевым решением, было бы отказаться от IL и организовать построение софта так, как это сделано для Arduino - формируется единый проект, компилируется и прошивается. Но тогда придется включать в состав инструментальной среды образы системного софта для каждого ПЛК/ПР или организовать процесс так, чтобы компилировалась только пользовательская часть софта и прошивалась в контроллер с фиксированного адреса. Последнее вполне возможно. Конечно при этом потерялась бы аппаратная независимость, но существенно повысилась бы мощь и гибкость использования контроллера. Для поддержки прежних устройств можно было бы оставить одну из версий ОЛ. Но скорее всего на это никто не пойдет. Возможно попытаются все же приколхозить компилятор с С на IL, а может ничего делать и не будут в итоге.
Владимир Ситников извините, чем отличается РИСУНОК в макросе ADD (на вход 1 подаем int 33, на вход 2 подаем int 55) и на выходе получаем 88.
от записи int Выход = 33+55 ?????????
Ну вот объясните русским понятным языком чем отличается долбанная кртинка в теле макроса ОЛ от такой же картинки, но записанной текстом ?
1. симулятор в ОЛ уже есть
2. компилятор так же есть
не достает только парсера текстового представления злосчастного ADD или fADD
з.ы. давайте исходники ОЛ, будем посмотреть что можно сделать.
А писать самостоятельные варианты не имеет смысла, так как нет привязки непосредственно к продукту.
з.з.ы. тут все упирается в то, что нет понимания чем можно оперировать, чтобы это потом можно было потом интегрировать в ОЛ.
Например если в SCADA системах есть скриптовые языки, либо можно писать непосредственно на языке программирования то в документации отражено какие методы, классы можно использовать, как создавать свои методы, классы, функции, что можно вызвать из системных функций и т.д. Где посмотреть логи ошибок и так далее, чтобы найти ошибку в коде. И все это документировано и РАБОТАЕТ.
Почему это не может работать в ОЛ или ином другом продукте ?
не понимаю...
Последний раз редактировалось melky; 27.07.2017 в 14:37.
Вот я не понимаю, как вы сначала говорите "не составит труда", а потом "зависит от исходников ОЛ".з.ы. давайте исходники ОЛ, будем посмотреть что можно сделать.
Разумеется, зависит. Разумеется, если там говнокод, то уже ничего не добавить. Но давайте будем более оптимистичными, и предположим, что там какой-то средне-статистический код.
Так вот. Сколько денег по-вашему стоит разработка формул? Или вы без понятия, и для ответа нужно посмотреть исходники?
Если вы без понятия, то как же так лихо утверждаете, что "не составляет труда добавить"?
Ни я ни capzap не говорили, что невозможно добавить формулы. Но крайне странно слышать "не составляет труда", и потом тут же "ой, давайте исходники ОЛ, будем посмотреть что можно сделать".
Объясняю: запись 33+55 не говорит ничего о типе данных. По-вашему, это сложение целых или дробных? Если целых, то знаковое или беззнаковое сложение? Это сложение байт или WORD'ов? И так далее.
Немного проще на примере 33-55. Сколько должно получиться? -22? -22.0? 4294967...?
А, если 33.0-55? А 33-55.0? А 33+(-55) ?
(33+55)/100 сколько должно получиться? 0? 0.88?
В картинке "ADD" и "fADD" как раз неоднозначности нет, т.к. блок fADD, ясен пень, работает с float'ами, а ADD с целыми.
Готов поставить 100р, что разные блоки ADD/fADD сделали как раз для того, чтобы не решать проблему типов данных в ОЛ, а заставить пользователя явно указывать какой тип должен быть в каждой точке схемы. Можно сколь угодно долго говорить про "так надёжнее, видно, что тут ADD, а тут fADD", но это всё ересь. Если складываем два аналоговых входа, то, очевидно, операция сложения выполняется над float'ами и результат тоже float. А, если мы подключаем целочисленное значение на дискретный выход, то там должна произойти операция "int_to_bool". Сейчас ОЛ эти все to_bool заставляет вручную расставлять.
Поэтому, для обработки текстовой формулы нужно изобретать правила, которые будут говорить какого типа выражение и как должен вычисляться конкретный оператор "+". Сейчас таких правил в ОЛ нет, и там название блока жёстко завязано на типы входов и входов.
Или вы предлагаете вместо "33 + 55" записывать "33 ADD 55" / "33 fADD 55"? Дичь же.
Можно, конечно, играться с вариантами "если есть дробная точка, то это float", но со знаковыми-безнаковыми гораздо сложнее. Например, в выражении "33 - 55" и 33 и 55 это "как бы беззнаковые целые".
На следующем уровне вопрос типизации будет только сложнее. Например, должна ли работать операция 2 OR -2?
Тут некоторые любят приводить C как пример. Так вот, в C сложение целых сопряжено с "неопределённым поведением" при переполнении. Да, в стандарте прямо так и сказано, что в случае переполнения компилятор может сделать вообще всё, что ему вздумается (undefined behavior). Например, вообще остановить работу программы.
Подходит такое поведение для ОЛ-ПР? Едва ли.
А вы спрашиваете чего такого сложного из "33+55" сделать блок ADD.
1. Да, симулятор текущих ADD/fADD блоков уже есть, но наверняка для того, чтобы "блок-формула" хоть как-то показывался в симуляции (не падал, показывал значения входов-выходов) нужны какие-нибудь доработки. Даже, если блок-формулу "за кадром" превращать в макрос из ADD/fADD, то всё равно в симуляторе нужно будет немного допилить, чтобы у него не сносило крышу от нового блока.
2. Ну и в компиляторе наверняка нужно будет тоже доработку, чтобы у него не сносило крышу от блока-формулы. Как-никак, сейчас компилятор только известные ему квадратики разбирать умеет, а нужно, чтобы он не падал от блока-формулы.
3. Ну и нужно делать часть сохранения-загрузки
4. Не устану повторять об "ошибках". Например, если в формуле возникнет "цикл", то ОЛ должно выдать предупреждение о необходимости "линии задержки".
Так я не прошу писать. Я прошу просто оценить длительность написания. Грубо говоря, "я бы такое сделал за X дней и Y денег".
Владимир Ситников "не составит труда" для разработчика, потому что у него все тузы в рукаве (код).
Ессно прикрутить со стороны да еще чтобы работало в некоем ПО без исходников не представляется возможным.
а int ВЫХОД - ЯСЕН ПЕНЬ РАБОТАЕТ С ЦЕЛОЧИСЛЕННЫМИ. Кроме которых в ОЛ есть еще только bool переменные и float переменные - ЧТО ТУТ НЕПОНЯТНОГО ?
Вы создаете макрос в ОЛ и указываете макросу ТИП входа - тут тоже непонятно с чем работать ?
Так вот в чем неоднозначность между ADD со входами int и + со входами int ?????
Куда вы все время съезжаете то ?
Знаковые, беззнаковые. Нарисуйте SUB 33 и 55 и посмотрите что в ОЛ будет на выходе, его интерпритатор работает так. Почему он должен работать иначе, если будет запись 33-55 ? да пусть так же и работает, вот вам и совместимость....
Что меня и удивляет, что компилятор разбирает рисунки, а не кодовое представление этих квадратиков с учетом связей.
Если это так, то мне очень жаль компанию Овен...
Последний раз редактировалось melky; 27.07.2017 в 15:24.
Потише, потише.
Блок-формулу же предлагается не для одной операции делать?
Вот, допустим, запись "int выход = (33-55+80.0)/100". Вполне резонный вопрос: минус это SUB или fSUB? Аналогично, деление это DIV или fDIV?
Вы предлагаете по типу выхода анализировать смысл всех операций в формуле?
Обратите внимание на то, что сейчас смысл операции в ОЛ задаётся самим блоком, а не типом его входов-выходов.
Грубо говоря, если есть операция fADD, то она по-любому будет выполнять float сложение, вне зависимости от того, куда её подключать.
Вы же внезапно предлагаете, чтобы тип выхода как-то влиял на происходящее внутри макроса. Да, так бывает, но сейчас в ОЛ такое не встречается.
Последний раз редактировалось Владимир Ситников; 27.07.2017 в 15:24.
Ваши права
