Просмотр полной версии : Возможность программирования на более низком, чем ОЛ схемы уровне
Что то не густо .Вот статистика Каскады :cool:
Это не капец, а незнание архитектуры ПО ПР. Нет там никакого транслятора в машинные коды. Добавить макросы на С===переделать ПР полностью, включая и прошивку и среду разработки.
А вот это гениально, значит нет трансляции в машинные коды? А позволю себе спросить - что там есть? Какова же эта таинственная архитектура ПО ПР, которая не совпадает видимо со всеми известными архитектурами ПО, с момента создания вычислительных систем? В каком виде ПО ВАШЕМУ существует программа, выполняемая микроконтроллером семейства STM32, который по слухам является ядром ПР200?
Я небольшую байку расскажу, если позволите. Шесть лет назад я делал свой контроллер для линейки оборудования, предназначенного для производства пластиковых окон. Возможности контроллера были примерно равны ПР200, ядром был микроконтроллер семейства ARM7, исполнение панельное, с графическим ЖКИ 128х64. Поскольку меня интересовало универсальное решение, то я исполнил его в виде программируемого контроллера - основная функция имела вид:
{
Input (); // ввод значений
User (); // пользовательская программа
Output (); // вывод значений
}
При этом функция User() создавалась в отдельном файле и состояла из последовательности макросов, каждый из которых соответствовал функциональному блоку. В отдельном файле были описан набор этих макросов, в виде функций на С.
Линейка оборудования в итоге в производство не пошла, а с ней умер и контроллер, да и я перестал электроникой заниматься - Китай и Турция победили все. Но по итогам в целом все работало, только иногда при старте привода сбрасывался ЖКИ - это я бы победил. И в планах была графическая оболочка для создания программ на FBD, необходимая для написания сложных программ и возможной продажи контроллера отдельно. В качестве такой оболочки планировалось применить редактор схем из любого бесплатного САПР печатных плат, например Kicad. Указанные редакторы позволяют создавать многолистовые иерархические схемы (читай программы), поддерживают библиотеки компонентов (читай ФБ) и имена цепей (читай переменные), на выходе выдают в текстовом виде netlist (список цепей), из которого можно узнать какие компоненты, какими цепями и с чем соединены. Таким образом можно создать библиотеку ФБ, нарисовать программу в виде схемы (прямо бальзам на душу наверное некоторым участникам форума?) и получить эту программу в текстовом виде. Потом написанной заранее утилитой "разобрать" текст и поставить каждому ФБ в соответствие функцию на С, а затем сформировать текстовый же файл, содержащий функцию User(). По окончании прогнать все через компилятор. Получившийся код, средствами контроллера (системная прошивка) залить в память, начиная с указанного адреса. И вуаля.
К чему я это все? К тому что в данной "архитектуре ПО" язык С присутствует ИЗНАЧАЛЬНО, пополнять библиотеки как символов, так и макросов пользователь может сам и в каком ему угодно объеме. И самое главное - во всех средах разработки программ для программируемых контроллеров, подобный подход присутствует так или иначе. Потому что контроллеры не программируются на графических языках, они все должны быть странслированы в один из языков, с которого существует компилятор, позволяющий получить hex-файл, для заливки в контроллер. А таких языков всего два фактически - С и С++. Поэтому я и считаю что С присутствует в ОЛ изначально - еще раз, ОЛ может быть написан на чем угодно, но микроконтроллеры программируются в основном на С и другого я зыка практически не понимают.
Кстати. Вариант "написания" пользовательской программы с использованием схемного редактора - оказывается встречается. Пару месяцев назад, разбираясь с системой ЧПУ под Linux, я столкнулся с подобной возможностью, реализованной на gEDA. Идеи действительно витают в воздухе.
Филоненко Владислав
13.04.2017, 12:09
А вот это гениально, значит нет трансляции в машинные коды? А позволю себе спросить - что там есть? Какова же эта таинственная архитектура ПО ПР, которая не совпадает видимо со всеми известными архитектурами ПО, с момента создания вычислительных систем? В каком виде ПО ВАШЕМУ существует программа, выполняемая микроконтроллером семейства STM32, который по слухам является ядром ПР200?
Я знаю, какая там архитектура, я её создатель. И исполнять код без трансляции вполне возможно, как бы Вам это ни казалось невозможным. Более того, этот метод используется во множестве мест на нашей планете.
Newcomer
13.04.2017, 12:39
Я знаю, какая там архитектура, я её создатель.
А вы хорошо подумали прежде чем создали эту самую гениальную архитектуру ? Может вы ее даже запатентовали ? ;)
Владимир Ситников
13.04.2017, 12:52
А вы хорошо подумали прежде чем создали эту самую архитектуру ? ;)
А какая разница?
По факту: ПР200 пользуется спросом -- значит, цель достигнута.
Гораздо интереснее как обстоит дело с p-code в ОЛ. Раз уж ОЛ не занимается мышиными кодами (что, в целом, было ожидаемо), то наверняка там p-code (значит, p-блок можно добавить без переделки всей среды ОЛ).
Newcomer
13.04.2017, 13:24
А какая разница?
По факту: ПР200 пользуется спросом -- значит, цель достигнута.
Гораздо интереснее как обстоит дело с p-code в ОЛ. Раз уж ОЛ не занимается мышиными кодами (что, в целом, было ожидаемо), то наверняка там p-code (значит, p-блок можно добавить без переделки всей среды ОЛ).
В.Филоненко боится остаться без хлеба, если раскроет все свои "великие секреты" ? Вот и темнит человек, туману напускает. ;) Только все тайное рано или поздно становится явным. Владислав, лучше вам расколоться побыстрее. Стоять на пути технического прогресса весьма чревато. Народ хочет перемен в ОЛ. Вы с народом или нет ?
Владимир Ситников
13.04.2017, 13:41
Вот и темнит человек, туману напускает. ;)
Где туман? Нет тумана. Русским по белому сказано, что ОЛ не занимается мышиными кодами.
Точно так же, Владислав говорит, что "добавление C в ОЛ это полная переделка ОЛ".
Ну, да. Каждому ежу должно быть понятно, что "добавление С потребует полную переделку".
Кому непонятно -- пусть идут и делают своё изделие на С.
лучше вам расколоться побыстрее
Нужно не Владислава раскалывать (он-то наверняка смеётся в голос над попыткам расколоть то, чего нет), а задавать вопросы в духе "когда будет p-блок".
Но и об этом спрашивать Владислава толка нет, ведь Владислав не занимается ОЛ-ПР.
Newcomer
13.04.2017, 14:02
Но и об этом спрашивать Владислава толка нет, ведь Владислав не занимается ОЛ-ПР.
Тогда пусть сообщит явки и пароли. ;)
Владимир Ситников
13.04.2017, 14:05
Тогда пусть сообщит явки и пароли. ;)
Рррр. Это всё мимо темы.
Владислав уже сообщал явки-пароли, но, похоже, подпал под пункт "5.1 правил" в трактовке "создание спроса на работу в ОВЕН".
Филоненко Владислав
13.04.2017, 16:09
А какая разница?
По факту: ПР200 пользуется спросом -- значит, цель достигнута.
Гораздо интереснее как обстоит дело с p-code в ОЛ. Раз уж ОЛ не занимается мышиными кодами (что, в целом, было ожидаемо), то наверняка там p-code (значит, p-блок можно добавить без переделки всей среды ОЛ).
Как я уже писал, добавлять новые ФБ в прошивку можно легко. Так что всё в ваших руках, просите блоки от команды ПР.
Владимир Ситников
13.04.2017, 16:32
Как я уже писал, добавлять новые ФБ в прошивку можно легко. Так что всё в ваших руках, просите блоки от команды ПР.
Так и не нужен новый блок в ПР.
Нужен новый блок в ОЛ: p-code. Наверняка же можно сделать поверх существующей прошивки.
Или это тоже 10 миллионов?
Евгений Багаев
13.04.2017, 17:15
В.Филоненко очень поспешно удалил мой последний пост. Значит я попал в самую точку.
Удалил не Владислав, а я. Очередной оффтоп будет также удален. Соблюдайте правила форума. Если хочется просто выговориться и попиарить господина Ситникова - идите в соответствующую тему.
p-code != C
а есть смысл поднимать и эту тему если нет прокладки между пи-кодом и машинными кодами, всёравно же придется с нуля создавать, чтоб потом обычному пользователю легче было
Прокладка между p-code и мышиными кодами уже есть и называется она "прошивка ПР".
а кто то упоминал, что это пи-система?
Владимир Ситников
14.04.2017, 10:42
Если овен дал бы описание, что и как хранится в .owl, то тот же Ситников (или кто-то другой) мог бы набросать транслятор из текста в .owl макрос, где открыв увидели те же блоки.
Не не не. Формат owl это другая тема (она тоже есть на форуме, и она менее полезна, чем p-code блок).
Николаев Андрей
14.04.2017, 10:50
Господа.
Удалил я. Хватит холивар разводить.
Сколько кто и как разрабатывает и сколько это стоит - нет совершенно никакого смысла обсуждать.
Мы слышим Вас, и слышим других клиентов. И обсуждаем разные варианты.
Но еще раз напоминаю: все мы (у кого не так - тот счастливчик) работаем в условиях ограниченных ресурсов.
И соответственно ранжируются задачи по важности, сложности и загрузке ресурсов.
Очень рады новым идеям и предложениям.
Но темы, а че ОВЕНу - 2 месяца, 2 года, да это дешево - давайте оставим.
Eugene.A
14.04.2017, 11:46
[B]Согласитесь, что написать макрос каких-то математический вычислений куда проще текстом, чем квадратиками.
Ну не скажите. Даже математики широко используют в своём аппарате графические представления математических операций. См. теория графов, например. Или в алгебре - для представления множеств, подмножеств, колец, полей и пр. рисуют всякие кружочки, колечки.
http://www.myshared.ru/slide/959908/
http://mydocx.ru/10-95260.html
Опять же графики, гистограммы. Лучше один раз увидеть, чем сто раз прочитать. Вот вы спидометр какой предпочитаете - стрелочный или цифровой?
Николаев Андрей
14.04.2017, 12:06
Только не надо поспешно удалять мой пост.
Люди потрудились зайти на форум ОВЕН, люди излагают свои идеи и делятся опытом работы, люди высказывают пожелания по улучшению продукции ОВЕН и пытаются аргументировать свою позицию
Согласен, не в первый раз очищают, даже в курилке.
И будут продолжать удалять.
Только давайте быть честными: идеи и пожелания - это всегда хорошо, оценка работы и критика по продуктам конструктивная - тоже хорошо и никогда не удалялась (где вы еще такое видели)...
А круговерть с тем, что я то супер эксперт и я точно знаю как надо работать и вас еще поучу - будет удаляться.
Поймите правильно - Влад или я можем сидеть и смеяться, или не сидеть и не смеяться. Речь не об этом. Речь о том, чтобы уважать других пользователей, которые так же хотят читать и оставлять свои предложения и пожелания, но заходят в тему, видят как несколько человек "меряется" крутизной в 27 страниц, но по сути о нескольких предложениях, и уходят.
Если кто-то может указать какие сообщения ПО ТЕМЕ были удалены - милости прошу.
Отдельную тему Ситникова, как Вы заметили, никто не удаляет, так как она отдельная, и не засоряет другие темы.
Приписка: как Вы заметили - даже сообщения Филоненко удаляются, если они не относятся к теме.
Владимир Ситников
14.04.2017, 14:20
Если кто-то может указать какие сообщения ПО ТЕМЕ были удалены - милости прошу.
Позвольте узнать, куда просите? В пешее? :D
Было моё сообщение такого толка:
1) Вопросы по теме "концептуальности p-code блоков" с точки зрения ОЛ. Если p-code "не концептуален", то есть ли смысл обсуждать дальше?
2) Цитирование лицензии на ОЛ в части того, что само по себе наличие p-code блоков не делает ОЛ "ненадёжным". В лицензии ОЛ и сейчас полный отказ от ответственности. Я к чему: я к тому, что в индустрии используется BPF (https://en.wikipedia.org/wiki/Berkeley_Packet_Filter) -- а там требования по безопасности и гарантированному времени выполнения ого-го какие. И ничего, p-code в полный рост.
Вроде как, абсолютно всё по теме.
И продавать приборы с Предупреждением - ежели чо, виноват С в p-code.
Это (что, якобы, "ОЛ надёжное как лом, а p-code всё сломает") уже проходили. Давайте, пожалуйста, по существу.
Блок p-code нарушает концепцию ОЛ?
Разработка блока p-code это вопрос недель, месяцев или лет?
Откройте РЭ на ПР200 и там увидите на 3-ей странице такое (аналогичная фраза есть и в РП ПР200)...
Ну и/или мой пост с оценками того, сколько времени нужно на добавление p-code блока в ОЛ (там были слова "Итого 7 мифических человеко-недель = 1.5 (формат) + 0.6 (блок) + 1 (чтение) + 1 (запись) + 1 (компилятор) + 1 (симуляция) + 1 (документация)"). Тут разнообразные личности постоянно заявляют "это сложно, долго, невозможно". Я привёл конкретные цифры. Разумеется, они могут быть неточны, но это хоть что-то, и это что-то напрямую относится к обсуждаемой теме.
Обсуждение сложности реализации напрямую относится к обсуждению "идеи". Можно пожелать чего-то экстравагантного, но, если оно потребует 10 человеко-лет, то лучше сразу принять, что в ближайшем будущем этого не появится. Возможно, даже и обсуждать не стоит. И наоборот: если идея не особо сложная, то можно и пообсуждать -- может выгореть. Ещё раз: смысл обсуждения не в том, сколько "ОВЕН наварит", а в "реалистичности самой идеи".
Николаев Андрей
15.04.2017, 17:59
В пешее в самом крайнем случае :)
Если погорячился, и что-то убрал по существу - приношу извинения.
Но надо понимать, что кроме нас четверых - пятерых, 28 страниц никто читать не будет. Из нас четверых вряд ли кто-то, де факто, будет использовать p-code, а остальные просто не дочитают этот триллер. С учетом, что на 26 странице звучит, к стати совершенно справедливо вопрос - а что это. На 24 странице...
А делать прогнозы по срокам реализации, как и любые прогнозы - дело вообще не благодарное, с учетом, что сами мы на них повлиять ну никак не можем :)
Владимир Ситников
16.04.2017, 00:28
Но надо понимать, что кроме нас четверых - пятерых, 28 страниц никто читать не будет.
По факту, читают, делятся мнениями. Зачастую даже по теме, и это при том, что тема действительно неширокая.
Из нас четверых вряд ли кто-то, де факто, будет использовать p-code
И да и нет.
Поднимался вопрос (возможно и не однократно) "дайте хоть какой-нибудь язык кроме квадратиков".
Я не про себя, и не про вопли "сделайте же C в ОЛ".
Использовать p-code можно по-разному. Можно макросы составлять, а можно эти макросы использовать в проектах.
Так вот: соглашусь, желающих составлять макросы на p-code будет меньше, чем общее количество пользователей ОЛ.
Но, если будет макрос, то его смогут использовать все. В том числе и те, кто сам бы такой макрос составить не смог.
а остальные просто не дочитают этот триллер. С учетом, что на 26 странице звучит, к стати совершенно справедливо вопрос - а что это. На 24 странице...
Тема "вопрос-ответ (новичковая)", например, тоже не предназначена для "дочитывания".
Да, многие и не понимают что такое p-code, но:
1) Это слово вполне даёт понять (кому надо) что я имею ввиду
2) Это нормально, когда пользователи ОЛ-ПР не понимают как оно устроено. Вопрос "что такое p-code" в этом плане мало чем отличается от вопроса "что такое прошивка". Многие понятия не имеют как устроена прошивка ПР, но это не мешает им создавать проекты.
3) Если грубо, то для конечного пользователя p-code блок можно сравнить с "макросом, написанным на IL". С точки зрения "обывателя-рисователя квадратиков", язык IL ущербен, непонятен, и непонятно зачем нужен. Но, с точки зрения взаимодействия систем, подобие языка IL это как раз то, что нужно. IL легко реализовать, и в нём сохраняется вся мощь. "Тот самый ST" можно можно превращать в IL (читай -- в p-code) и таким образом можно получить "ST макросы в ОЛ" и не нагружать ОЛ ST редактором.
4) В пользовательском интерфейсе же отображение этого самого p-code как IL можно и НЕ делать. Формат записи Apache Thrift или Google Protocol Buffers может быть гораздо более удобным в разработке, т.к. текстовое представление IL приходилось бы парсить, а Thrift/protobuf предоставляют готовые средства для чтения и записи сообщений.
Самое замечательное - это не то что "28 страниц никто не будет читать" (по факту - читают), а то что эти 28 страниц вообще существуют. Странно, что вообще приходится убеждать в необходимости макросов на текстовом языке. Наверное действительно архитектура ПО в ПР200 какая-то необычная, потому что я так и не понял - почему добавить указанную возможность нельзя или сильно дорого. Меня бы вообще не волновал этот вопрос, будь аппаратные возможности ПР200 хуже, процессор например 8-разрядный дохлый или что. Но на сегодняшний день я вижу, что расширить функционал ПР200 буквально ничего не стоит, относительно всех других усилий, уже затраченных на его проектирование и постановку производства. Я не являюсь экспертом, но имею все же не маленький многолетний опыт в автоматике и электронике, в том числе и в проектировании и создании микропроцессорных систем, поэтому все же могу судить.
Вы создавали микропроцессорные системы, которые программировались ИХ ПОТРЕБИТЕЛЕМ на разработанной вами инструменталке не на АССЕМБЛЕРЕ или С?
Использовать p-code можно по-разному. Можно макросы составлять, а можно эти макросы использовать в проектах.
Так вот: соглашусь, желающих составлять макросы на p-code будет меньше, чем общее количество пользователей ОЛ.
Но, если будет макрос, то его смогут использовать все. В том числе и те, кто сам бы такой макрос составить не смог.
именно об этом чаще всего и идет речь...
Вы создавали микропроцессорные системы, которые программировались ИХ ПОТРЕБИТЕЛЕМ на разработанной вами инструменталке не на АССЕМБЛЕРЕ или С?
Я делал встроенные системы, они не программировались, а работали по написанному мной софту. Последний из созданных мной контроллеров должен был программироваться, в том числе с использованием С, но я его не закончил на этапе графической оболочки для программирования (железо и текстовые программы - работали) - тема умерла.
Не понимаю вашего вопроса - я за то чтобы С был как вариант, для написания макросов. Чем это помешает тем, кто мыслит "кубиками" - мне не понятно, т.к. "кубики" в любом случае останутся.
Использовать p-code можно по-разному. Можно макросы составлять, а можно эти макросы использовать в проектах.
Так вот: соглашусь, желающих составлять макросы на p-code будет меньше, чем общее количество пользователей ОЛ.
Но, если будет макрос, то его смогут использовать все. В том числе и те, кто сам бы такой макрос составить не смог.
именно об этом чаще всего и идет речь...
Кстати да, может кому и не надо сразу создание макросов на текстовом языке, но получив такой макрос в готовом виде от кого-нибудь, он его может посмотреть/изменить и в дальнейшем может написать и свой. В итоге человек обучится. А если возможности нет, то и возможного развития тоже нет. Об этом забывают часто.
Владимир Ситников
17.04.2017, 11:09
Не понимаю вашего вопроса - я за то чтобы С был как вариант, для написания макросов. Чем это помешает тем, кто мыслит "кубиками" - мне не понятно, т.к. "кубики" в любом случае останутся.
Само по себе "наличие C" не помешает кубистам.
Но поймите же, наконец. "Сделать C в ОЛ" потребует очень больших затрат. Прямо настолько больших, что и ждать, что ОВЕН реально сделает это самое С нет никакого смысла.
Если очень хочется "С в ОЛ", то открывайте свою тему про это и вперёд. С этим самым Си море проблем: сообщения об ошибках, проверка корректности кода (например, выход за границу массива), симуляция, автодополнение, online и прочее прочее.
С другой стороны, тупой как пробка p-code блок и реализовать в ОЛ несложно, и поддержка для разных моделей ПР должна быть простой. Да и в будущем этот самый p-code блок не будет мешаться: сделать, например, online режим в программе с p-code блоками гораздо проще, чем в программе, где пользовательские блоки написаны на C.
Само по себе "наличие C" не помешает кубистам.
Но поймите же, наконец. "Сделать C в ОЛ" потребует очень больших затрат. Прямо настолько больших, что и ждать, что ОВЕН реально сделает это самое С нет никакого смысла.
Если очень хочется "С в ОЛ", то открывайте свою тему про это и вперёд. С этим самым Си море проблем: сообщения об ошибках, проверка корректности кода (например, выход за границу массива), симуляция, автодополнение, online и прочее прочее.
С другой стороны, тупой как пробка p-code блок и реализовать в ОЛ несложно, и поддержка для разных моделей ПР должна быть простой. Да и в будущем этот самый p-code блок не будет мешаться: сделать, например, online режим в программе с p-code блоками гораздо проще, чем в программе, где пользовательские блоки написаны на C.
Хорошо, я согласен на p-code, если он мне позволит делать то же, что я мог бы делать на С:вычисления, массивы, строки, обработка данных и т.д. Пусть уже что-нибудь будет - какой язык, это не принципиально.
Надо ардуино запилить под пр200))
Да там и С и FBD ,причем в одном флаконе -FLProg .
Newcomer
17.04.2017, 19:50
Да там и С и FBD ,причем в одном флаконе -FLProg .
Странно. А чего тогда В.Ситников пишет, что это очень сложно и плохо. Чем ПР200 хуже Arduino ? FLProg бесплатный. Адаптировать его под ПР200 и тра-та-та. ;)
Как хорошо сказано на сайте проекта FLProg.
Наша миссия
Перевести программирование Arduino в область доступную для не программистов, сделать разработку устройств на нем возможной для тех, кто не владеет языками программирования.
Странно. А чего тогда В.Ситников пишет, что это очень сложно и плохо. Чем ПР200 хуже Arduino ? FLProg бесплатный. Адаптировать его под ПР200 и тра-та-та. ;)
Как хорошо сказано нам сайте проекта FLProg.
Наша миссия
Перевести программирование Arduino в область доступную для не программистов, сделать разработку устройств на нем возможной для тех, кто не владеет языками программирования.
C нуля можно сделать все что угодно ,но в ОЛ была заложена другая архитектура ,идеология .И переделывать ее это значит делать заново .
Именно ОЛ и реализует этот лозунг(миссию)
Владимир Ситников
17.04.2017, 20:24
Да там и С и FBD ,причем в одном флаконе -FLProg .
Рррр. Давайте ближе к теме.
Ну какое отношение имеет FLProg к ОЛ-ПР?
Не имеет оно отношения. Если хотите, чтобы ОВЕН адаптировали прошивку ПР для поддержки в FLProg, пожалуйста, в отдельную тему.
PS. Моё мнение -- без p-code даже и не стоит начинать адаптацию каких-либо внешних сред. Ну, либо это будет "прошивка от FLProg+сама среда FLProg" (по аналогии, как сделали ПЛК110+MS4 без поддержки КДС), но кому такое (в смысле ПР без ОЛ) нужно?
Newcomer
17.04.2017, 20:26
Именно ОЛ и реализует этот лозунг(миссию)
Только на половину.
Newcomer
17.04.2017, 20:31
Рррр. Давайте ближе к теме.
Ну какое отношение имеет FLProg к ОЛ-ПР?
Не имеет оно отношения. Если хотите, чтобы ОВЕН адаптировали прошивку ПР для поддержки в FLProg, пожалуйста, в отдельную тему.
PS. Моё мнение -- без p-code даже и не стоит начинать адаптацию каких-либо внешних сред. Ну, либо это будет "прошивка от FLProg+сама среда FLProg" (по аналогии, как сделали ПЛК110+MS4 без поддержки КДС), но кому такое (в смысле ПР без ОЛ) нужно?
Название темы надо поменять. Предлагаю такое название. Возможность программирования в ОЛ не только на CFC.
Рррр. Давайте ближе к теме.
Ну какое отношение имеет FLProg к ОЛ-ПР?
Ни какого ,только схожесть языка FBD.Сказал о нем только для того ,что бы поняли что предлагаете и на каком этапе,что это повлечет .ОЛ это не начальный этап .В него столько вбухано сил и времени ,что кардинальных переделок ни кто делать не будет ..
Владимир Ситников
17.04.2017, 20:40
Название темы надо поменять. Предлагаю такое название. Возможность программирования в ОЛ не только на CFC.
Я предлагаю начинать с "p-code блока". Это по-прежнему CFC/FBD блок, поэтому не вижу смысла менять название.
Владимир Ситников
17.04.2017, 20:42
Ни какого ,только схожесть языка FBD.Сказал о нем только для того ,что бы поняли что предлагаете и на каком этапе,что это повлечет .ОЛ это не начальный этап .В него столько вбухано сил и времени ,что кардинальных переделок ни кто делать не будет ..
А где я предлагал кардинальные переделки? Полностью поддерживаю, что "добавление языка Си в ОЛ-ПР это огромная перделка". Но я же никогда и не предлагал добавлять Си. Наоборот, я убедил тов. starmos, что "сделать Си" в ОЛ-ПР невозможно.
Ну, реально, где я предлагал кардинальное?
Я говорю об одном-единственном "p-code блоке". Наверняка и прошивку менять не потребуется.
Так не вам эти сообщения адресовались ,я знаю что вы уже согласны ;)
Лучше бы популярно не для программиста поясни ли бы ,что это такое р-код блок...
Владимир Ситников
17.04.2017, 21:03
Так не вам эти сообщения адресовались ,я знаю что вы уже согласны ;)
1) Сообщение "Да там и С и FBD ,причем в одном флаконе -FLProg" было не по теме. Даже если и не мне адресовано, то всё равно не по теме.
dim1987 зря начал про arduino, но зачем было поддерживать флейм?
2) "Ни какого ,только схожесть языка FBD" это был ответ на моё сообщение. Как оно может быть "не мне адресовано" -- ума не приложу.
Лучше бы популярно не для программиста поясни ли бы ,что это такое р-код блок...
Рассказывал же уже. См. пункт под номером "3)" (http://www.owen.ru/forum/showthread.php?t=23754&page=29&p=244492&viewfull=1#post244492)
"Язык IL" это понятное слово или нет?
Если понятное, то можно считать, что p-code блок это "ОЛ-макрос, написанный на языке IL".
rovki, я вас огорчу, но С в FlProg НЕТ. он доступен только разработчикам, самому написать макрос на С возможности нет, по крайней мере ее не было на 10 или 11 версии, сейчас не знаю. Макросы там все так же квадратиками пишутся.
Это я вас огорчу - Блоки на си пишет любой разработчик ,который владеет им ,что бы остальные могли использовать их в своих проектах.
rovki не являясь разработчиком и запустив FlProg вы можете использовать С ? Насколько помню нет. Так и в ОЛ, что там ваяют разработчики, добавляя косяков на С# но вам из всего доступны только кубики...
Владимир Ситников
18.04.2017, 00:50
rovki не являясь разработчиком и запустив FlProg вы можете использовать С ? Насколько помню нет. Так и в ОЛ, что там ваяют разработчики, добавляя косяков на С# но вам из всего доступны только кубики...
1-ая ссылка в Google и 2ая в Яндексе по запросу "flprog c" рассказывают именно про то, как создавать пользовательские FLProg блоки на C: https://geektimes.ru/company/flprog/blog/270862/
В целом, можно было бы повторить "FLProg не относится к теме", и "макросы на Си в ОЛ всё равно не сделают никогда", но процитирую фрагмент из этой статьи:
Я решил дать им соответствующий инструмент. Таким образом, в версии 1.10.3 появилась возможность создавать пользовательские блоки с интегрированным кодом на С. Это привело к довольно неожиданным результатам. Этим инструментом заинтересовались не только разбирающиеся в программировании пользователи, но и те, кто до этого ни писал не сточки кода. Они начали писать сначала простенькие блоки (например, получение логарифма – среди стандартных у меня такого блока не было), заканчивая уже серьёзными блоками с применением библиотек
Опыт "этим инструментом заинтересовались и те, кто до этого ни писал не сточки кода" весьма любопытен. Одно дело когда я говорю "давайте сделаем p-code блок, это полезно", а другое, когда в FLProg реально сделали, и реально оказалось полезно.
1-ая ссылка в Google и 2ая в Яндексе по запросу "flprog c" рассказывают именно про то, как создавать пользовательские FLProg блоки на C: https://geektimes.ru/company/flprog/blog/270862/
В целом, можно было бы повторить "FLProg не относится к теме", и "макросы на Си в ОЛ всё равно не сделают никогда", но процитирую фрагмент из этой статьи:
Опыт "этим инструментом заинтересовались и те, кто до этого ни писал не сточки кода" весьма любопытен. Одно дело когда я говорю "давайте сделаем p-code блок, это полезно", а другое, когда в FLProg реально сделали, и реально оказалось полезно.
Собственно почему это FLprog не относится к теме? Тема называется: "Возможность программирования на более низком, чем ОЛ схемы уровне" - И? Я читаю и понимаю, что речь здесь идет об уровне программирования, более низком, чем предоставляется в ОЛ. Т.е. речь как раз о той возможности, которую ОЛ в настоящее время не предоставляет. Т.е. сюда подходят не только возможности, реализованные в FLProg, но и сам FLProg целиком. Потому что, хотя раздел форума и называется "Среда программирования OWEN Logic", но само название ОЛ - есть условность. Если бы ОВЕН обратился (как я советовал и советую) к разработчику FLProg и предоставил бы ему информацию об аппаратной начинке ПР200, то я думаю что через месяц-другой под названием ОЛ уже фигурировал бы FLProg, только И с FBD И c LD (вроде там есть?) и с С, а название бы осталось - ОЛ и все это соответствовало бы форуму.
Вы не убедили меня в том, что сделать С в ОЛ невозможно, но только в том, что ввиду необъяснимого сопротивления, делать это никто не будет.
Но тут же поднялась тема FLProg, в котором это сделано энтузиастом и явно не за дорого.
Мое мнение - пусть будет хоть что.
Моя рекомендация, либо:
1. приблизить прошивку ПР200 к Arduino (с учетом конечно промышленной специфики ПР200), что даст возможность использовать любые средства программирования Arduino;
2. адаптировать тот же FLProg к ПР200, если уж с ОЛ возникли такие неразрешимые проблемы.
Аппаратных препятствий к любому варианту - нет.
Держаться только за названия типа ОЛ или "программируемое реле" - не конструктивно, т.к. сами по себе они никакой ценности не имеют. Если надо менять ОЛ, даже вплоть до неузнаваемости - надо менять, если вместо ПР вышел малый ПЛК - надо смириться и порадоваться открывшимся возможностям. Догматизм = вреден.
спасибо, увидел, давно туда не забредал....
starmos не нада пытаться скрестить ужа с ежом, ОЛ и flprog, слишком внутренности разные
спасибо, увидел, давно туда не забредал....
starmos не нада пытаться скрестить ужа с ежом, ОЛ и flprog, слишком внутренности разные
Вот вам зачем их внутренности? Вам нужно средство на котором удобно программировать ПР200? Какая разница как оно будет выглядеть внутри - работать удобно, требуемый код генерирует - что еще от него надо?
Владимир Ситников
18.04.2017, 10:27
Собственно почему это FLprog не относится к теме? Тема называется: "Возможность программирования на более низком, чем ОЛ схемы уровне" - И? Я читаю и понимаю, что речь здесь идет об уровне программирования, более низком, чем предоставляется в ОЛ.
Есть название, а есть содержание.
Если почитаете тему, то увидите, что много раз говорилось о бесполезности-невозможности программирования ПР на Си.
Считаете, что Си/FLProg полезно -- создавайте отдельную тему про это.
Текущая тема именно про p-code/IL в рамках текущей программы ОЛ.
Вот сейчас снова придёт Филоненко, и вместо того, чтобы что-нибудь дельное сказать про p-code он снова скажет капитанские вещи про "бесполезность FLProg и/или Си в ПР".
Если надо менять ОЛ, даже вплоть до неузнаваемости - надо менять
Создавайте свой продукт, и потом полностью меняйте его. А мы похохочем над тем, что скажут пользователи, у которых "теперь нужно переписывать все программы" и прочее прочее.
ОВЕН это не Apple и вариант "развитие ОЛ остановлено, новые ПР только под FLProg" никто не оценит.
Вы не убедили меня в том, что сделать С в ОЛ невозможно, но только в том, что ввиду необъяснимого сопротивления, делать это никто не будет.
Ещё раз: создавайте тему -- там обсудим. Не нужно мусорить в этой.
Подсказка: вы почему-то смотрите только на "плюсы" от "замены ОЛ на FLProg", от "добавления Си в ОЛ", но при этом совершенно игнорируете минусы. Так эти минусы там всё перевешивают. Дело не в "необъяснимом сопротивлении", а в банальных минусах от подобных решений.
Моя рекомендация, либо:
1. приблизить прошивку ПР200 к Arduino (с учетом конечно промышленной специфики ПР200), что даст возможность использовать любые средства программирования Arduino;
2. адаптировать тот же FLProg к ПР200, если уж с ОЛ возникли такие неразрешимые проблемы.
Аппаратных препятствий к любому варианту - нет.
В FLProg ни симуляции, ни online режима нет. Сейчас в ОЛ программу можно хоть как-то проверить. А в FLProg вообще никак.
Промышленный прибор без возможности тестирования. Браво!
Это далеко не единственный минус FLProg по сравнению с ОЛ.
В FLProg ни симуляции, ни online режима нет. Сейчас в ОЛ программу можно хоть как-то проверить. А в FLProg вообще никак.
Промышленный прибор без возможности тестирования. Браво!
Это далеко не единственный минус FLProg по сравнению с ОЛ.
А вы не лукавите? Чтобы говорить о flprog вам надо хотяб его запустить может?
Владимир Ситников
18.04.2017, 12:42
А вы не лукавите? Чтобы говорить о flprog вам надо хотяб его запустить может?
Я вполне серьёзно говорю.
Считаете, что в FLProg есть симуляция FBD?
Или, считаете, что в FLProg нет ведра минусов по сравнению с ОЛ?
Симуляции в FLProg нет:
http://flprog.ru/forum/10-1704-1#17827: ...2017.01.30: Автор уже писал что это достаточно сложно и пока реализовано не будет.
В очередной раз призываю не отклоняться от темы. FLProg это совершенно отдельная тема, и, очевидно, что там всё плохо с точки зрения ПР, промышленной автоматики и т.п.
Я вполне серьёзно говорю.
Считаете, что в FLProg есть симуляция FBD?
Или, считаете, что в FLProg нет ведра минусов по сравнению с ОЛ?
Симуляции в FLProg нет:
В очередной раз призываю не отклоняться от темы. FLProg это совершенно отдельная тема, и, очевидно, что там всё плохо с точки зрения ПР, промышленной автоматики и т.п.
Это достаточно удобно - высказать тезис, а всех несогласных призывать "не отклоняться от темы". Я например был удивлен, когда внезапно всплыл FLProg. И я не согласен что он не по теме - он наглядно иллюстрирует, что все возражения на тему "этого нельзя сделать в ОЛ" не стоят выеденного яйца, потому что вот наглядный пример где сделано. Это просто пример. Невозможно ничего предметно обсуждать про программирование низкого уровня в ОЛ, потому что в ОЛ этого нет - нет почвы для обсуждения. А FLProg позволяет провести наглядную аналогию - раз сделано в одном месте, значит можно и в ОЛ сделать, плюс можно уже изучить опыт внедрения - оказывается написание макросов на С востребовано.
Что касается отладки - отладки нет в FLProg, но сама платформа Arduino позволяет легко скидывать по COM порту информацию о ходе выполнения программы, т.е. каждый разработчик, если ему надо, сможет запросто организовать себе подобие онлайн-отладки.
Никаких других минусов FLProg я так и не увидел. Отдельно хотелось бы узнать что же там плохо с точки зрения ПР (?) и промышленной автоматики? Чтобы было проще - можно рассказать что же сравнительно хорошо в ОЛ, с этих позиций.
Это достаточно удобно - высказать тезис, а всех несогласных призывать "не отклоняться от темы". Я например был удивлен, когда внезапно всплыл FLProg. И я не согласен что он не по теме - он наглядно иллюстрирует, что все возражения на тему "этого нельзя сделать в ОЛ" не стоят выеденного яйца, потому что вот наглядный пример где сделано. Это просто пример. Невозможно ничего предметно обсуждать про программирование низкого уровня в ОЛ, потому что в ОЛ этого нет - нет почвы для обсуждения. А FLProg позволяет провести наглядную аналогию - раз сделано в одном месте, значит можно и в ОЛ сделать, плюс можно уже изучить опыт внедрения - оказывается написание макросов на С востребовано.
Что касается отладки - отладки нет в FLProg, но сама платформа Arduino позволяет легко скидывать по COM порту информацию о ходе выполнения программы, т.е. каждый разработчик, если ему надо, сможет запросто организовать себе подобие онлайн-отладки.
Никаких других минусов FLProg я так и не увидел. Отдельно хотелось бы узнать что же там плохо с точки зрения ПР (?) и промышленной автоматики? Чтобы было проще - можно рассказать что же сравнительно хорошо в ОЛ, с этих позиций.
Да, складывается впечатление "ребята, тема моя, этого не говорите, это не пишите, создайте себе свою..." Писать можно что угодно, всё равно удалят, их цепляет это обсуждение и нервирует явно.
Добавлю что flprog написал один человек, бесплатно, в свободное время. Компиляция С кода и и отловка синтаксических ошибок на этапе компиляции всё же есть тоже.
И еще одно замечание, flprog всё таки транслятор, он преобразует графический блок в текст и подсовывает этот текст оригинальной программе для arduino, где делается основная работа компиляции и загрузки.
Этот вариант для ОЛ я думаю тоже имеет право быть, если ОВЕН немного посодействует, совсем немного.
Василий Кашуба
18.04.2017, 20:54
Да, складывается впечатление "ребята, тема моя, этого не говорите, это не пишите, создайте себе свою..." Писать можно что угодно, всё равно удалят, их цепляет это обсуждение и нервирует явно.
Добавлю что flprog написал один человек, бесплатно, в свободное время. Компиляция С кода и и отловка синтаксических ошибок на этапе компиляции всё же есть тоже.
И еще одно замечание, flprog всё таки транслятор, он преобразует графический блок в текст и подсовывает этот текст оригинальной программе для arduino, где делается основная работа компиляции и загрузки.
Этот вариант для ОЛ я думаю тоже имеет право быть, если ОВЕН немного посодействует, совсем немного.
Ну да, а потом все ранее написанные программы в помойку и всё пиши заново.
Ну да, а потом все ранее написанные программы в помойку и всё пиши заново.
Почему Вы сделали такой вывод? С ОЛ такое помню, с flprog нет :)
Василий Кашуба
18.04.2017, 22:06
Почему Вы сделали такой вывод? С ОЛ такое помню, с flprog нет :)
Программы, написанные в ОЛ, будут работать в flprog? Нет. Отсюда и вывод такой.
Программы, написанные в ОЛ, будут работать в flprog? Нет. Отсюда и вывод такой.
Да не, их соединять никак не надо, просто идею рассказал.
что интересно,
В flprog человек работает сам, для себя, бесплатно, идеи хорошие, поддержка, реализация не плохая, linux даже поддерживается.
А тут промышленное, требуются сразу миллионы (Владислав просил), и пару человеко лет.
Василий Кашуба
18.04.2017, 22:33
Почему Вы сделали такой вывод? С ОЛ такое помню, с flprog нет :)
Лично у меня не было ни одного случая, чтобы программы, написанные в старых версиях ОЛ, не работали в новых версиях ОЛ.
Лично у меня не было ни одного случая, чтобы программы, написанные в старых версиях ОЛ, не работали в новых версиях ОЛ.
вот например файл, не открывается вообще нигде, так потерял несколько проектов, не сказать что прям серьёзных, один раз оказалось насколько помню из-за немецкого языка, случайно, но не в этом суть и это уже всё таки другая тема.
Владимир Ситников
18.04.2017, 23:50
Это достаточно удобно - высказать тезис, а всех несогласных призывать "не отклоняться от темы"
Я полностью соглашусь с модераторами, если они потрут всё, начиная с сообщения "Это достаточно удобно - ...".
Я уже говорил, что "Си в ОЛ" к текущей теме не относится:
Если очень хочется "С в ОЛ", то открывайте свою тему про это и вперёд...
Вроде, русским языком сказал: хотите обсуждать "Си в ОЛ" -- создавайте свою тему. Хотите обсуждать "flprog для ПР" -- в отдельную тему. Чего непонятного?
Невозможно ничего предметно обсуждать про программирование низкого уровня в ОЛ, потому что в ОЛ этого нет - нет почвы для обсуждения
:D "Я знаю точно: невозможное -- возможно" (с) Дима Билан. А, если подумать? Я привёл конкретное предложение для ОЛ (p-code блок), оценил сложность реализации, оценил потенциальное влияние на поддержку ОЛ. И где обещанная невозможность?
Я наоборот скажу: при обсуждении доработок ОЛ нужно обсуждать именно то, как оно будет работать с имеющимися проектами на базе ОЛ, как повлияет на развитие ОЛ, как повлияет на текущие и будущие ПР.
А FLProg позволяет провести наглядную аналогию - раз сделано в одном месте, значит можно и в ОЛ сделать
О, просто гениальные слова.
"Раз в программе X это сделано, значит и в Y это можно сделать".
Браво! Ура, товарищи! Просто гений программирования и маркетинга.
Все слова, касающиеся "flprog это сделано" -- сразу в лес. Если непонятно почему -- создавайте отдельную тему. Здравомыслящему человеку должно быть сразу понятно, почему flprog в лес.
Никаких других минусов FLProg я так и не увидел. Отдельно хотелось бы узнать что же там плохо с точки зрения ПР (?)
Между строк читаете или как? Интересно -- заводите свою тему про это. Ну какого лешего "интересоваться", когда и я и модераторы (аж 2 раза!) просили-предупреждали, что сообщения "не по теме" будут удаляться? <-- это риторические вопросы, не нужно на них отвечать.
Я полностью соглашусь с модераторами, если они потрут всё, начиная с сообщения "Это достаточно удобно - ...".
Я вам больше скажу - я соглашусь даже если они потрут всю тему целиком. Потому что действительно сказано уже достаточно много - разумные люди уже давно все услышали бы. Приведено достаточно примеров возможной реализации. На самом деле не важно что будет использоваться как текстовый язык для создания макросов. Но С предпочтительнее, потому что его синтаксис многие знают, так же как и умеют создавать на нем программы. А p-code придется отдельно изучать. Вики определяет p-code как ассемблер для условного процессора. Вы много программировали на ассемблере? Не самый удачный язык для написания сложных программ, а простые - можно и квадратиками нарисовать. Тем более - чтобы написать оптимальную программу на ассемблероподобном языке (если угодно IL), необходимо хорошо знать ВЕСЬ набор команд и уметь их использовать. ЭТОТ язык - точно не будет иметь популярности. Но для вас p-code/IL уже видимо стал самоцелью - вот это уже и есть "священная война".
Если разработчики ОВЕНа извлекут из этого многостраничного общения какие-то полезные для себя идеи - будет хорошо, а нет - ну будет так как есть.
Раз уж стирания все одно не избежать - ссылку приведу для примера:
http://www.digital-loggers.com/plchw.html
Люди ищут и пытаются делать. И снижают цены, уже до 89 баксов. ПР200 - хороший прибор и даже сейчас имеет преимущества, но так будет не всегда - как только один из подобных приборов пойдет в серию - со всеми ОЛ будет покончено в момент и придется таки переписывать программы.
Хочется конечно отметить действительно демократичную политику ОВЕНа на форуме - в других местах потерли бы тему давно уже. Но я считаю что знать мнение критиков и оппонентов полезно.
Если ПР200 можно бы было программировать на C, то никакие макросы были бы вообще не нужны. В С есть все, что необходимо для разработки программ любой сложности.
Но С, как я понял, никогда для ПР200 не будет. Кому нужен текстовый, язык будьте добры приобрести ПЛК с CoDeSys. По техническим характеристикам ближайший аналог ПР200 - это ПЛК63. Правда цена в 2 раза больше. Если ПР200 будет с С, то ПЛК63 перестанут покупать. Зачем фирме ОВЕН это надо. По этой причине в ПР200 только CFC.
Вот и вся подноготная истории про то, почему в ПР200 нет и не будет языка С. Представителям фирмы ОВЕН надо об этом честно и открыто заявить и вопрос о С в ПР200 будет закрыт.
Павел Братковский
19.04.2017, 10:12
Если ПР200 можно бы было программировать на C, то никакие макросы были бы вообще не нужны. В С есть все, что необходимо для разработки программ любой сложности.
Но С, как я понял, никогда для ПР200 не будет. Кому нужен текстовый, язык будьте добры приобрести ПЛК с CoDeSys. По техническим характеристикам ближайший аналог ПР200 - это ПЛК63. Правда цена в 2 раза больше. Если ПР200 будет с С, то ПЛК63 перестанут покупать. Зачем фирме ОВЕН это надо. По этой причине в ПР200 только CFC.
Вот и вся подноготная истории про то, почему в ПР200 нет и не будет языка С. Представителям фирмы ОВЕН надо об этом честно и открыто заявить и вопрос о С в ПР200 будет закрыт.
если ПР200 будет программироваться при помощи С, то много потребителей, таких как я откажутся от ПР200......ОВЕН это надо?
если ПР200 будет программироваться при помощи С, то много потребителей, таких как я откажутся от ПР200......ОВЕН это надо?
Если в ОЛ будет доп. возможность писать на текстовом языке, то никто не откажется, даже вы.
если ПР200 будет программироваться при помощи С, то много потребителей, таких как я откажутся от ПР200......ОВЕН это надо?
Никто не писал, что ПР200 должен программироваться только на C. Многие пишут про то, что надо бы иметь возможность программировать ПР200 не только на CFC, но и на C.
Если в ОЛ будет доп. возможность писать на текстовом языке, то никто не откажется, даже вы.
как вы себе представляете дополнение Си. Вы пробовали перенести проект на Си с одной архитектуры на другую. Добавление всего необходимого под процессор ПР-ки, будет полностью отдельным продуктом от текущего ОЛ и графический язык вновь будет перестраиваться со всеми проблемами которые уже проходили раза три на настоящее время
Владимир Ситников
19.04.2017, 10:48
как вы себе представляете дополнение Си.
Си != "текстовый язык". Разумеется, "дополнение ОЛ на Си" и не стоит пытаться делать. Но сделать текстовый язык можно и без этого самого Си.
Добавление всего необходимого под процессор ПР-ки, будет полностью отдельным продуктом от текущего ОЛ и...
p-code блок может вполне быть частью текущего ОЛ без каких-либо глобальных переделок.
p-code блок может вполне быть частью текущего ОЛ без каких-либо глобальных переделок.
в живую это где то есть, кто перешел на p-коды без глобальных переделок или овен должен будет быть первым
Владимир Ситников
19.04.2017, 11:16
в живую это где то есть, кто перешел на p-коды без глобальных переделок или овен должен будет быть первым
Я более чем уверен, что ОЛ уже основано на p-code. Поэтому и говорю, что добавление "p-code блока" в ОЛ не потребует глобальных переделок.
как вы себе представляете дополнение Си. Вы пробовали перенести проект на Си с одной архитектуры на другую. Добавление всего необходимого под процессор ПР-ки, будет полностью отдельным продуктом от текущего ОЛ и графический язык вновь будет перестраиваться со всеми проблемами которые уже проходили раза три на настоящее время
Вы опять что-то напутали, я не говорю что надо добавить С, для меня С не интересен, мне бы хотелось ST.
Вы опять что-то напутали, я не говорю что надо добавить С, для меня С не интересен, мне бы хотелось ST.
так тема об более низком уровне, чем языки МЭК или снова напутал
Владимир Ситников
19.04.2017, 13:34
так тема об более низком уровне, чем языки МЭК или снова напутал
Всё правильно. Это тема про низкий уровень в ОЛ, но именно это и позволит сделать ST без кардинальных переделок ОЛ-ПР.
Разумеется, ST будет за пределами ОЛ, и с точки зрения ОЛ всё будет выглядеть как p-code блок.
низком уровне, чем языки МЭК
Если точнее, то про уровень, сравнимый с МЭК IL. Сейчас такого в ОЛ нет, поэтому это "более низкий чем в текущем ОЛ".
так тема об более низком уровне, чем языки МЭК или снова напутал
да, немного.
...,чем ОЛ схемы.
Я считаю ST как раз там.
--
Всё, читать про этот p-code больше не могу, у Владимира пена изо рта уже, starmos по этому поводу правильно написал.
вобщем не знаю кого вы все хотите подтянуть к пользованию ПР-ками с помощью низкоуровневых языков, давайте с детей начнем, кто за скретч (http://www.oracle.com/technetwork/topics/newtojava/youngdevelopers/index.html)?
вобщем не знаю кого вы все хотите подтянуть к пользованию ПР-ками с помощью низкоуровневых языков, давайте с детей начнем, кто за скретч (http://www.oracle.com/technetwork/topics/newtojava/youngdevelopers/index.html)?
Знаю такую штуку от гугла, Blockly называется. Добавил такое в ОЛ ;) и дадим детям
Владимир Ситников
19.04.2017, 16:16
вобщем не знаю кого вы все хотите подтянуть к пользованию ПР-ками с помощью низкоуровневых языков
Забавно, забавно.
Есть много желающих на текстовые языки в ОЛ. Кому просто case (http://www.owen.ru/forum/showthread.php?t=26579), кому ST (http://www.owen.ru/forum/showthread.php?t=23754&p=244964&viewfull=1#post244964), кому очередь, кому вообще хоть что-то помимо квадратиков.
Прихожу я, предлагаю рабочий вариант.
И получаю в ответ такое:
* вобщем не знаю
* читать больше не могу
* пена изо рта уже
* этого не говорите, это не пишите
* "священная война"
* Вы много программировали на ассемблере?
* ПЛК63 перестанут покупать. Зачем фирме ОВЕН это надо
* кардинальных переделок ни кто делать не будет
* Название темы надо поменять
* оказывается написание макросов на С востребовано
* сделать С в ОЛ, ввиду необъяснимого сопротивления, никто не будет
Куда деваются все те, кому "было нужно"? Надо чтобы "Великий ОВЕН" снизошёл и разродился?
А мозгами пошевелить и хотя бы просто поддержать инициативу?
Да читать нужно не между строк! Разумеется, ассемблер (он же p-code, он же IL) нужен не для того, чтобы на нём люди программировали. Разумеется, ассемблер нужен, чтобы в него преобразовывать человекопонятные языки (ST, SFC, Дракон в конце концов). Неужели сложно понять, что сами ОВЕН текстовые языки никогда не сделают?
Но нет, на шаг вперёд мало кто думает, и всё скатывается в пошлости типа "а чего сложного сделать Си?", "а кого вы собрались заманивать на ассемблер?", "да у него вообще пена". И после этого доблестно разбираются в очередной теме "доколе, case, EN/ENO, eprom".
Забавно, забавно.
Ах, да, был комментарий от Владислава:
Никто ничего ни на какой IL язык не компилирует. Точка. ПринцЫп работы ПР радикально иной. :cool:
Но, тут у меня есть основания не доверять Владиславу.
И вот почему: тот же самый Владислав утверждал, что добавить Си в ОЛ-ПР стоит "несколько миллионов".
Добавление функционала макросов на С (чтобы клиент сэкономил 5к) стоит несколько миллионов - либо увеличиваем цену, либо кто-то выступает спонсором.
Принципов работы ОЛ может быть только 2: либо ОЛ генерирует машинный код ("опровергнуто" словами "стоит несколько миллионов"), либо ОЛ генерирует промежуточный код ("опровергнуто" словами "ПринцЫп работы ПР радикально иной").
Оба варианта Владислав как бы "опроверг". Но как же тогда работает это самое ОЛ? Не на магии же!
Неужто принцЫп ОЛ заключается в передаче *.owl файла напрямую в ПР?
Поэтому я и считаю, что ОЛ работает по принципу промежуточного кода, а Владислав лишь вводит в заблуждение.
В конце должен быть какой-то вывод. И вывод будет следующий: нужно чтобы кто-то ногами дошёл до офиса ОВЕН и узнал что думают там.
Вот и сделайте эти шаги сами ,прежде чем предлагать.Ибо нужно не просто придти ,а умные вопросы задать и получить еще более умные ответы, и понять их.
Владимир Ситников
19.04.2017, 16:29
Вот и сделайте эти шаги сами
К сожалению, от Кирова до Москвы почти 1000км.
Ночь на поезде ;) или 10часов на машине ;)
в жизни вобще много забавного, например контроллеры uPac-7xxx программируются на Си, у них конечно есть свой покупатель, но чтоб все массово ринулись менять свои КДС и ТИА, такого я не видел. Запускал я и сишные проекты, которые писались человеком, уже уволившимся из компании, поднимать это направление нет желания, надо полностью перестраиваться на другое мышление, вспоминать забытые навыки если они были, а тут начнуть "гореть" текущие проекты, которые хоть и штампуются почти, но индивидуальные особенности всегда присутствуют. Думаю жаждущих сделать противоположный переход, тоже крайне мало, потому что перейти на устройства, которые не ясно будут или нет работать, хоть как нибудь, не говоря уже о стабильной фазе не перевесит чашу уже проверенных инструментов. Что же касается всяких п-кодов, настораживает фраза
ассемблер нужен, чтобы в него преобразовывать, значит кто то должен написать перевод из чего угодно в понятный код для ПР, другими словами наличие п-системы, говорить что этой системой является прошивка ПР только из своих предположений это одно, что там на самом деле пока всё в "тумане"
К сожалению, от Кирова до Москвы почти 1000км.
нука напомните где проходила JPoint2017 или Вы принципиально только за Урал летаете :) какая то не солидная отмазка
Вот и сделайте эти шаги сами ,прежде чем предлагать.Ибо нужно не просто придти ,а умные вопросы задать и получить еще более умные ответы, и понять их.
А с чего вы взяли, что ходока с этими вопросами встретят в фирме ОВЕН с распростертыми объятиями ? Хотели бы рассказать то, что нужно В.Ситникову для реализации его идеи давно бы рассказали. Был прецедент с быстрыми входами/выходами. Там В.Филоненко предлагал всем желающим свой фирменный инструментарий для тестирования. Но при этом надо было подписать какие-то документы о неразглашении каких-то корпоративных секретов. В.Ситников получил это добро, ознакомился с ним и сделал заключение, что инструментарий сложен и неудобен. Свои мысли о том, каким должен быть инструментарий он публично изложил. Началось бурное обсуждение темы. Насколько я помню, подавляющее большинство было против предложений В.Ситникова. Одним из ярых противников был В.Филоненко. Несмотря на все препоны В.Ситников весьма успешно реализовал свою идею. Я пользуюсь его инструментарием и могу подтвердить, что все там хорошо.
Сегодня все мы являемся свидетелями новой эпопеи. Картина примерно та же, но В.Филоненко извлек урок из того первого случая. Он прекрасно понимает, что если предоставить всю необходимую информацию по ПР200, то В.Ситников легко реализует свои предложения. Можно только гадать что мешает В.Филоненко раскрыть свои “секреты”. Да и В.Ситников, как я понимаю, не будет за бесплатно впрягаться в это дело. Свое технико-коммерческое предложение он озвучил. Мяч на стороне фирмы ОВЕН.
Посмотрим чем закончится этот триллер. ;)
Лично у меня не было ни одного случая, чтобы программы, написанные в старых версиях ОЛ, не работали в новых версиях ОЛ.
У меня был, пресловутые значения по умолчанию в сетевых переменных, кому-то руки отбить, поломали, а починить забыли, просто закрыли такую возможность...
Свое технико-коммерческое предложение он озвучил.
сколько в попугаях?
Ситникову плюсую однозначно за быстрые выхода, не ожидал такой простоты, этот человек умеет делать вещи.
Аргуинщики катаются от смеха над веткой я про уровень мек.
Что за мек-бек ? Ты давай по русски изъясняйся.
Глубокое заблуждение про тексты и кубики .Одно дело создание инструмента (например , ОЛ,кодесис, тут свои языки) и другое дело автоматизация производства,технологического процесса - тут должны быть совсем другие языки и специалисты ...
тут должны быть совсем другие языки и специалисты ...
Не земные что ли ? Или вы о тех специалистах, которые матерными словами изъясняются. ;)
Они должны быть визуальными,прикладными,специализированными ,...как то так .может таким https://ru.wikipedia.org/wiki/%D0%93%D0%B8%D0%B1%D0%BA%D0%B0%D1%8F_%D0%BC%D0%B5% D1%82%D0%BE%D0%B4%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1 %8F_%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1% 82%D0%BA%D0%B8
Владимир Ситников
20.04.2017, 01:00
Ситникову плюсую однозначно за быстрые выхода, не ожидал такой простоты, этот человек умеет делать вещи.
Спасибо. Здесь, конечно, не совсем в тему, но всё равно спасибо.
Ситников видимо прав, когда говорит что ОЛ работает с p-code/IL. Потому что это допущение многое объясняет. IL - это "ассемблер для ПЛК". Т.е. если учесть что по заявлению представителя ОВЕН - "ОЛ не работает с машинными кодами", то выходит что в ядре ПР200 имеется интерпретатор, который получает программу на IL. Сам интерпретатор конечно писался на С, сам ОЛ - или на С или на родственном языке, с большой вероятностью. Но поскольку ОЛ и ПР200 используют между собой промежуточный язык IL, то встроить в эту связку С действительно или очень геморройно (нужен отдельный транслятор С -> IL) или вообще нельзя. Применение IL обосновано совместимостью - если все ПЛК семейства имеют один язык IL, то добавление нового устройства - это перенос прошивки, написанной на С на новое железо = не сложно делается, один раз компилируется и прошивается в любое количество устройств. Точно так же как и замена микроконтроллера например в ПР200, на более мощный например - переписали прошивку и все. При этом сам язык IL приносит как вышеописанные выгоды, так и накладывает ограничения: во-первых, потому что любой "ассемблер" неудобен в программировании, а во-вторых, потому что интерпретатор = ограничивает возможную оптимальность пользовательского кода фиксированным набором команд. В Ардуино-подобных системах имеется компилятор С -> машинный код конкретного микроконтроллера, т.е. необходимо знать модель этого микроконтроллера перед компиляцией. На сегодняшних платах это видно визуально, а когда плата стоит в корпусе - это проблема, тут помогло бы автоопределение - плевая вещь, но пока таких стандартов нет, насколько я знаю. Код, генерируемый для Arduino-подобных систем, по определению оптимальнее по быстродействию и меньше по объему, чем написанный с использованием IL. Но при текущем состоянии дел, если я правильно предположил, использование С просто невозможно и ОВЕН никогда на это не пойдет, т.к. это означает не "доработать ОЛ", а просто выкинуть его, вместе с прошивкой ядра и разработать новую связку. Предоставление же пользователям доступа к IL, видимо с точки зрения ОВЕН не рационально и тут я согласен - популярности этот язык иметь не будет. Ситникову он видимо нужен, чтобы написать свой транслятор "любой язык -> IL" и в крайнем случае вообще без ОЛ обходиться или более вероятно - встроиться в ОЛ. В последнем случае будет вариант - "заказать" макрос Ситникову, или "заказать" макрос разработчикам ОВЕН, больше наверное никто связываться с IL не станет. Разница невелика и разработчики настаивают на том, чтобы заказывали им - можно даже согласиться, т.к. сделают может не быстрее, но качественнее и безошибочнее - просто потому что они знают особенности реализации IL, а больше никто не знает. Так что да - версия о встроенном IL объясняет собственно все. Тем не менее, мое мнение - применение IL, это ошибочный и тупиковый шаг в современных условиях.
Поскольку понятно, что просить С при подобном состоянии = действительно бессмысленно, то может ОВЕН рассмотрит возможность выпуска отдельной серии устройств, заточенных на С изначально? Можно разработать Arduino-совместимую прошивку под ПР200 и продавать эти приборы, как свободно программируемые, скажем под индексом ПР201? Как говорится - "всем сестрам по серьгам" - поклонники традиционных языков будут покупать свое семейство и программировать его на ОЛ, а "экстремалы" - свое и программировать "на чем сердце успокоится". В производстве "железа" = никакой разницы, поэтому начать можно с ограниченных серий. По тем же ценам (или меньше - не надо будет отчислять с этого на разработчиков ОЛ).
Поскольку понятно, что просить С при подобном состоянии = действительно бессмысленно, то может ОВЕН рассмотрит возможность выпуска отдельной серии устройств, заточенных на С изначально? Можно разработать Arduino-совместимую прошивку под ПР200 и продавать эти приборы, как свободно программируемые, скажем под индексом ПР201? Как говорится - "всем сестрам по серьгам" - поклонники традиционных языков будут покупать свое семейство и программировать его на ОЛ, а "экстремалы" - свое и программировать "на чем сердце успокоится". В производстве "железа" = никакой разницы, поэтому начать можно с ограниченных серий. По тем же ценам (или меньше - не надо будет отчислять с этого на разработчиков ОЛ).
Так есть же kit платы? не?
Владимир Ситников
20.04.2017, 10:36
Так есть же kit платы? не?
kit платы никому не нужны:
2016.02.21: ПР-КИТ уже был, и уже был убран, так как за несколько год не нашел своего потребителя.
Эти КИТы были на базе PIC18 (ПР110) , с очень ограниченным функционалом .А вот другие КИТы очень даже имеют спрос -ардуино ,например .
Между PIC18 и STM32 разница в популярности. Если предлагать PIC18, то его будут брать очень мало,или никто. А если предлагать STM32, да еще сделать его совместимым с Arduino (уже есть платы на STM32 совместимые с Arduino), то можно предсказать больший интерес покупателей - все те, кто сейчас пытается "приколхозить" на проводках ардуиновксие платы для "дома и семьи" - будут иметь возможность купить нормальный прибор. Т.е. люди освоившие автоматику через Arduino - смогут получить возможность развития. Купить ПР200 можно и сейчас, но немалое количество пользователей не знает зачем он им и не знает языков ПЛК.
Филоненко Владислав
20.04.2017, 14:54
... ОЛ работает с p-code/IL. Потому что это допущение многое объясняет. IL - это "ассемблер для ПЛК". Т.е. если учесть что по заявлению представителя ОВЕН - "ОЛ не работает с машинными кодами", то выходит что в ядре ПР200 имеется интерпретатор, который получает программу на IL. ...
Молодца. Всё именно так.
А почему IL:
- переносимость (Ядро не правилось уже десяток лет, несмотря на кучу платформ)
- расширяемость (float-ы и доп. ФБ добавились без вреда для остального кода) И др. ФБ вставятся так же.
- стабильность и предсказуемость - ФБ протестировать легко, ФБ друг на друга не влияют, время выполнения и ресурсы константны.
А С никому не интересен, кроме гиков и ОЧЕНЬ крупных системных интераторов. Сложный язык с кучей side effect, крутой кривой обучения, затрудненной отладкой, проблемами с симуляцией на кросплатформенных приложениях, БОЛЬШИМИ проблемами с совместимостью кода на разных платформах и слабой (для непрофессионала) переносимостью.
А тут квадратиков накидал, в симуляции проверил и вперед.
Приборы с программированием на С у нас продаются, ПЛК100, 110, 304-323 - можно купить с Линукс. И кодь себе до посинения. Покупают КРУПНЫЕ интеграторы, к-е знают зачем и как применить.
Филоненко Владислав
20.04.2017, 16:18
По ценам промолчу, но с чего бы им быть дороже? А что не рекламируем - да никому не нужны с улицы. А так - 100, 323 ЛЕГКО купить. 110 - немного сложнее, но некритично. Обращайтесь. При 1000+ в год - большие скидки.
Владимир Ситников
20.04.2017, 17:00
А С никому не интересен
Про Си всё давно было ясно.
Всё именно так. А почему IL
Расскажите что-нибудь на тему p-code / IL блока в ОЛ.
Реально?
Филоненко Владислав
20.04.2017, 20:59
Сделать блок, который будет в себе содержать пользовательский код?
Мы это уже проходили с ПРУ - вся программа вырождается в 1 блок, потом все бегают по кругу - а почему у меня при ХХХ YYY работает не так. Оттестировать "суперблок" невозможно в принципе.
время выполнения скачет как кенгуру, ОВЕН, спасите, проект горит.
Зачем такие сложности?
Владимир Ситников
20.04.2017, 23:57
Сделать блок, который будет в себе содержать пользовательский код?
Ну, да, пользовательский код.
Вот сейчас в ОЛ есть такая штука как макрос. Там содержится пользовательский код.
И ничего, многим нравится. Многих выручает.
Какая-то проблема с этим?
Повторюсь, код не бинарный, а p-code.
Оттестировать "суперблок" невозможно в принципе.
А что называется словом "оттестировать"?
Вот "макрос ОЛ" можно оттестировать?
Если можно, то и "p-code блок" тоже можно оттестировать.
Суперблок это будет или нет зависит от того, будет ли в p-code инструкция "CALL macro".
Надеюсь, если не в первой версии p-code блока, то следующих эта инструкция появится (ну, чтобы можно было вызывать проектные макросы).
А значит, можно будет вызывать и один p-code блок из другого.
А значит, "оттестирование" p-code блока будет несильно сложнее, чем "оттестирование обычного ОЛ макроса".
Можно же сложные p-code блоки составлять из более простых. Всё в порядке. Где "невозможность в принципе"?
Про возможность тестирования p-code за пределами ОЛ я пока не буду распространяться.
Тестирование PRU блока вполне возможно (pru-emulator прекрасно работает).
Мы это уже проходили с ПРУ - вся программа вырождается в 1 блок, потом все бегают по кругу - а почему у меня при ХХХ YYY работает не так
Есть реальные примеры, когда пользователи берут и раскручивают ШД на ПЛК110 буквально за день. С разгоном и торможением, без мутоты с прерываниями.
Сами качают среду, заливают PRU0.prg и всё такое.
И никто не бегает как кенгуру. Оно просто работает.
Наоборот, кто-то вообще взял и с нуля сделал свою PRU программу на ST. Да, с точки зрения КДС это получился "один блок", но с точки зрения пользователя это нормальные ФБ и понятный ST код.
В этом плане p-code блок в ОЛ будет смотреться гораздо более органично, ведь по сути он не будет отличаться от имеющихся макросов. А PRU программа хочешь-не-хочешь выполняется на другом ядре процессора, и там даже передача данных это непростая задача.
Владимир Ситников
21.04.2017, 00:02
время выполнения скачет как кенгуру, ОВЕН, спасите, проект горит
Не знаю как в ПР, но в PRU программах, которые создаёт Hardella, время выполнения не скачет. Там есть погрешность в 5-10 наносекунд, но называть это "скачет как кенгуру" явное лукавство.
Если у вас есть достаточно точный осциллограф -- можете взять и убедиться.
Вернее даже наоборот: если пользовательский код заканчивается раньше, то больше времени остаётся на служебные задачи (RS-485, экран и т.п.).
anthrwpos
21.04.2017, 06:34
Ну, да, пользовательский код.
Вот сейчас в ОЛ есть такая штука как макрос. Там содержится пользовательский код.
И ничего, многим нравится. Многих выручает.
Какая-то проблема с этим?
Макрос легко отлаживается за счет его опять-же, "чистоты".
Каждый макрос тестируется подачей на него тестовых последовательностей входов. Если он на все тестовые последовательности отвечает правильным выводом, вы можете вставлять макрос куда угодно и будете на 100% уверены, что он будет работать.
Если же добавить туда возможность доступа к любым внешним сущностям, вот тогда и начнется "спасите, ничего не работает"=)
Таким образом всё будет зависеть от того, какой доступ будет предоставляться пользовательскому коду.
Филоненко Владислав
21.04.2017, 11:57
Давайте посчитаем.
ФБ AND - 2 бинарных входа - 4 варианта состояний входов - протестировать легко
Самоё большое кол-во входов в ФБ 5, внутренних переменных в ФБ - 3. Логика простая и понятная. Циклов нет, сложных переходов нет, отладка проста.
И сравним с:
Условный ФБ "Супер P-code" (например управление ШД) 9 входов, 6 внутр. состояний - число комбинаций 2^15. И это без учёта плавающей точки и использования времени.
Ну а если писать всю программу на 1 ФБ (к чему тов. Ситников и продвигает свой продукт), т.к. сделать нормальную фрагментацию кода, как и планировалось на PRU это сложно, лучше всё впихнуть внутрь - число входов и вн. состояний зашкаливает и проверить все комбинации в принципе невозможно.
Филоненко Владислав
21.04.2017, 11:59
И правильно тут отметили про права доступа для "внешнего кода".
Будьте любезны процессор (уже не микроконтроллер!) с MMU с внешней ОЗУ и Flash, да побольше, защищённый режим, RTOS полноценную и все прелести.
Иначе любой чих приводит ПР в неработоспособность + контроль доступа куда не надо.
Покупайте ПЛК100 с линуксом и кодьте.
Владимир Ситников
21.04.2017, 12:08
И правильно тут отметили про права доступа для "внешнего кода".
Владислав, перестаньте, пожалуйста, скатываться в "бинарный код", в "программы на Си".
Я говорю исключительно про p-code. Никаких MMU, RTOS и прочей ереси на уровне p-code не должно быть видно и не должно быть доступно.
Только понятные операции типа "сложить два числа", "вызвать ФБ", "вызвать макрос", "сравнить" и т.п.
Ну каким боком тут ПЛК с линуксом? Он мне не впился. Ровно как никому не впилось программирование ОЛ-ПР на Си.
Владимир Ситников
21.04.2017, 12:22
Ну а если писать всю программу на 1 ФБ (к чему тов. Ситников и продвигает свой продукт), т.к. сделать нормальную фрагментацию кода, как и планировалось на PRU это сложно, лучше всё впихнуть внутрь - число входов и вн. состояний зашкаливает и проверить все комбинации в принципе невозможно.
Владислав, тут я буду вынужден призвать модератора и обратить внимание на то, что текущая тема не имеет отношения к PRU.
Чего это вы постоянно скатываетесь на PRU?
Вспомните, что тут мы обсуждаем ПР и ОЛ.
Вспомнили?
Тогда вспомните, что я предлагаю создавать на p-code отдельные блоки и их использовать в финальной ОЛ программе.
Разумеется, при составлении p-code блоков будет удобно использовать имеющиеся ОЛ блоки, имеющиеся ОЛ макросы и другие p-code блоки.
Иными словами, я никого не призываю составлять ОЛ программу в виде одного единого ФБ. Ни в коей мере. Я за разделение кода на понятные фрагменты.
Поэтому сравнивать "простой SR триггер" и "суперсложный p-code блок" совершенно неправильно. Как вообще язык поворачивается сравнивать две совершенно разные вещи? Понятно, что на p-code можно сделать говнокод. Но говнокод можно сделать и в текущем ОЛ макросе. Значит ли это, что нужно срочно запрещать ОЛ макросы?
Правильно сравнивать "ОЛ макрос" и аналогичный по существу блок, написанный на p-code.
Например: "макрос вычисления синуса" и аналогичный "p-code вычисления синуса".
Если уж захотелось управлять ШД на ПР-ОЛ, то, милости прошу. Давайте сравним сложность составления ОЛ макроса для управления ШД (с разгоном, торможением, аварийным остановом и прочим). И сравним возможность протестировать этот самый "ШД макрос", написанный в ОЛ с макросом, написанным на p-code.
Что, ОЛ макрос для ШД это "Логика простая и понятная. Циклов нет, сложных переходов нет, отладка проста"? Едва ли.
Newcomer
21.04.2017, 13:36
Владислав, тут я буду вынужден призвать модератора и обратить внимание на то, что текущая тема не имеет отношения к PRU.
Владислав, сам себе модератор. ;)
Филоненко Владислав
21.04.2017, 14:56
Это как оценка работы бригады таджиков по результатам предыдущих ремонтов.
Если раньше крепили розетки вверх ногами, как не просил заказчик, то и потом будут крепить.
Так что не надо звать маму-модератора!
https://habrahabr.ru/company/everydaytools/blog/327070/ наверное чтение этой темы и подобных навеяло написать на хабре
Владимир Ситников
25.04.2017, 18:07
https://habrahabr.ru/company/everydaytools/blog/327070/ наверное чтение этой темы и подобных навеяло написать на хабре
А какое отношение имеет "конвертация с языка X на язык Y" к текущей теме?
А какое отношение имеет "конвертация с языка X на язык Y" к текущей теме?
к тому что, кто надеется на появление другого языка, после начнут сетовать на глючность созданного, вот они бы сделали лучше и т.п.
Кто задавался вопросом способен ли программист в штате овена, передалать на что то близкое к низкоуровневому языку. Для всех почему то это выгладит как "пустячок", но непременно выскажутся в теме что лоджик глючит. Делов то нанять команду программистов, которая обеспечит и легкость интерфейса и разнообразие языков и сервис по обратной связи по поводу ошибок, все же надеются что овен сделает подарок и не бдет вкладывать в цену прибора оплату наемников
Владимир Ситников
26.04.2017, 11:06
к тому что, кто надеется на появление другого языка, после начнут сетовать на глючность созданного, вот они бы сделали лучше и т.п.
Разумеется. Может, например, оказаться, что в первой версии p-code не будет команды "вызвать макрос". Будет ли полезен IL без команды "вызвать макрос"? Будет. Будет ли полезна сама команда вызова других макросов? Будет.
Кто задавался вопросом способен ли программист в штате овена, передалать на что то близкое к низкоуровневому языку. Для всех почему то это выгладит как "пустячок", но непременно выскажутся в теме что лоджик глючит.
Слова "переделать на" неправильные. ОЛ уже переводит схему в низкоуровневый язык (не машинный, а IL). Поэтому тут вопрос лишь в том, чтобы сделать ОЛ-блок, в котором можно эту самую IL программу писать без ОЛ схемы.
ОЛ уже компилирует схему в IL. Откуда берутся фразы "нанять команду программистов" -- вообще непонятно. Там нужно не с нуля новое создавать, а использовать имеющееся.
каким бы восхитительным не был какой либо блок, его возможности не раскроются в полном объеме если в системе в целом есть другие слабые звенья. Говорите не с нуля создавать, разве есть какое то подобие симуляции текстового языка в лоджике, когда самого текствого языка нет, это уже с нуля?
То же самое касается объявлений входов/выходов, применят концепцию для сфцешных смем? Опять придется создавать подобие КДС-ого направления.
Все же хотят низкий уровень не для того чтоб "лепить" имеющиеся квадратики, только в текстовом виде, нужно же управление памятью, чтоб организовать такой желанный перебор массива данных, если интерпретатор с ИЛ в машинные коды этого не умеет, значит тоже надо будет переделывать подход и не факт что делать это придется из имеющегося
Вы то надеюсь не думаете, что один программист это сделает за пару месяцев
Владимир Ситников
26.04.2017, 12:25
каким бы восхитительным не был какой либо блок, его возможности не раскроются в полном объеме если в системе в целом есть другие слабые звенья.
Если штаны восхитительные, то и блок восхитительный.
Говорите не с нуля создавать, разве есть какое то подобие симуляции текстового языка в лоджике, когда самого текствого языка нет, это уже с нуля?
А в первой версии я предлагаю IL симулировать "только целиком". Например, текущий блок BLINK. Он как-то работает, как-то симулируется, но ОЛ не показывает внутренности.
Так и с p-code блоком: его можно симулировать, но отображать только значения входов-выходов.
Даже отображение-редактирование IL в текстовом формате не особо нужно.
То же самое касается объявлений входов/выходов, применят концепцию для сфцешных смем? Опять придется создавать подобие КДС-ого направления.
Ну, да, разумеется нужно будет как-то "объявлять входы-выходы". Но в ОЛ уже есть механизм объявления входов-выходов. При создании макроса как раз и нужно указать входы выходы.
Нет нужны делать именно так, как в КДС.
Вполне рабочий вариант "создать макрос", указать входы-выходы, и через какую-нибудь галочку отметить, что это "IL макрос", а не "FBD".
нужно же управление памятью, чтоб организовать такой желанный перебор массива данных, если интерпретатор с ИЛ в машинные коды этого не умеет, значит тоже надо будет переделывать подход и не факт что делать это придется из имеющегося
Зависит от того, как сейчас устроен ОЛ-IL. Гораздо важнее не "поддержка массивов" (её наверняка в текущем наборе команд нет), а поддержка условных переходов.
Вы то надеюсь не думаете, что один программист это сделает за пару месяцев
А я и не говорил, что можно сделать "идеальный IL за пару месяцев". Всю эту "поддержку массивов" и т.п. можно будет обсуждать, если исходная концепция пойдёт. А начальный уровень (и вполне пригодный!) за пару месяцев -- вполне. И это не "программировать пару месяцев", а вместе с документированием и прочим.
Так и с p-code блоком: его можно симулировать, но отображать только значения входов-выходов.
Даже отображение-редактирование IL в текстовом формате не особо нужно.
так блинк (как реализацию в виде квадратика) ни кто и не отлаживает, а если самому реализовывать генератор импульсов (на текущий момент в виде макросов) то очень даже понадобится именно онлайн режим для тестирования. И для какого тогда уровня пользователей добавлять подобные блоки (читай черный ящик), явно не для массового потребителя
в ОЛ уже есть механизм объявления входов-выходов. При создании макроса как раз и нужно указать входы выходы.что имеете ввиду, с левой стороны окна р-блока входа, с правой выхода? А еще есть сетевые переменные, внутренние, а куда константы девать, у нас так то четыре стороны у прямоугольника
а поддержка условных переходовв КДС это есть и на cfc схемах, так нужен ли тогда доп.язык, когда проще исключать из работы не активные ветки уже в имеющейся среде
И это не "программировать пару месяцев", а вместе с документированием и прочим.вышла поддержка экранов в ПР200, мало того что подход в ИП320 не стал использоваться, так и всё осталось без изменений по настоящее время, а работать с ними попржнему проблематично для большинства пользователей
Владимир Ситников
26.04.2017, 13:47
так блинк (как реализацию в виде квадратика) ни кто и не отлаживает, а если самому реализовывать генератор импульсов (на текущий момент в виде макросов) то очень даже понадобится именно онлайн режим для тестирования. И для какого тогда уровня пользователей добавлять подобные блоки (читай черный ящик), явно не для массового потребителя
Отлаживать блоки можно в той среде, где и составляется сам p-code (компилируется из ST и т.п.). Да, в ОЛ это будет как чёрный ящик, но сейчас любой макрос "PID с автонастройкой" это почти чёрный ящик. Фиг знает что там хотел автор и что как (не)работает.
что имеете ввиду, с левой стороны окна р-блока входа, с правой выхода? А еще есть сетевые переменные, внутренние, а куда константы девать, у нас так то четыре стороны у прямоугольника
Хоть с чего-то начать надо. Хоть без сетевых, хоть без констант.
вышла поддержка экранов в ПР200, мало того что подход в ИП320 не стал использоваться, так и всё осталось без изменений по настоящее время, а работать с ними попржнему проблематично для большинства пользователей
Это лишь подтверждает инертность каких-либо доработок-разработок ОЛ.
Но я, заметьте, и предлагаю p-code блок делать так, чтобы на стороне ОЛ потребовалось минимум каких-либо работ.
Это лишь подтверждает инертность каких-либо доработок-разработок ОЛ.
это означает, что человек что знает, на том и пишет, строит свою модель разработки среды. Например я не знаю, что такое p-code и как его встроить в свою среду, означает ли это что я ринусь переделывать свою программу, потому что большинство моих пользователей проглосовало за, наделав ошибок в незнакомой области, шансов больше потерять потребителя, чем дорабатывая "классический" вариант
это означает, что человек что знает, на том и пишет, строит свою модель разработки среды. Например я не знаю, что такое p-code и как его встроить в свою среду, означает ли это что я ринусь переделывать свою программу, потому что большинство моих пользователей проглосовало за, наделав ошибок в незнакомой области, шансов больше потерять потребителя, чем дорабатывая "классический" вариант
Как то не правильно, если не знаете как это делать, а пользователи просят, то найдите кто это сделает за Вас, все останутся довольны.
А ошибки есть много где, вот например есть ошибки в ПЛК 160 и 110, по вашему для ОВЕН это не знакомая область??
Можно приводить ряд еще других устройств, но явно тут Вы не правы.
Как то не правильно, если не знаете как это делать, а пользователи просят, то найдите кто это сделает за Вас, все останутся довольны.
"нанять команду программистов" -- вообще непонятно. Там нужно не с нуля новое создавать, а использовать имеющееся.
А ошибки есть много где, вот например есть ошибки в ПЛК 160 и 110, по вашему для ОВЕН это не знакомая областьА Вы про это много знаете? Под старые образцы была написана своя ОС, возможно наемником, под новые взята уже апробированная на других контроллерах. На старой ошибки известны и не переделываются из-за перехода на новую, на новой, еще прошло мало времени чтоб прошивку довести до ума. Вашт проблемы вообще относятся к схемотехнике прибора, а не программного обеспечения,т.ч. правых/неправых тут нет
А Вы про это много знаете? Под старые образцы была написана своя ОС, возможно наемником, под новые взята уже апробированная на других контроллерах. На старой ошибки известны и не переделываются из-за перехода на новую, на новой, еще прошло мало времени чтоб прошивку довести до ума. Вашт проблемы вообще относятся к схемотехнике прибора, а не программного обеспечения,т.ч. правых/неправых тут нет
Тоесть если не шаришь в схемотехнике - вперёд! А если в программировании, то надо не потерять клиентов?
О цитатах, я и Ситников - разные люди, значит разные мнения...
Могу привести примеры когда ПРОГРАММНАЯ ошибка на купленных приборах овен, бывает.
Лично с Вами спорить не хочу, сказал своё имхо, да и в целом эта тема развиваться не будет, из овен это сказали, зачем тут столько писать???
Владимир Ситников
26.04.2017, 15:29
Например я не знаю, что такое p-code и как его встроить в свою среду
А я и не прошу вас встраивать p-code в вашу среду.
означает ли это что я ринусь переделывать свою программу, потому что большинство моих пользователей проглосовало за, наделав ошибок в незнакомой области, шансов больше потерять потребителя, чем дорабатывая "классический" вариант
Вы не поняли главного: IL (p-code) в ОЛ уже есть. Это не какая-то новая область, а это то, как ОЛ работало со времён своего сотворения.
Если ОВЕН реально не понимает что такое p-code, могут спросить/уточнить.
я пока не понимаю только одного, где тот инструмент, который превратит мой код в код на IL. От Вас слышал варианты и написать его где то, добавить какими то путями в проект, так же было сказано, создавать как макрос с пометкой что это будет IL и я так понимаю писать его в самом лоджике, в любом случае нужен интерпретатор, того что я набрал пальцами в код которой переработается в машинные коды
Владимир Ситников
26.04.2017, 16:04
я пока не понимаю только одного, где тот инструмент, который превратит мой код в код на IL. От Вас слышал варианты и написать его где то, добавить какими то путями в проект, так же было сказано
Кто-кто, а вы-то уж инструмент знаете. Легко-понятно, что научить Hardella компилировать ST код в ОЛ-IL особого труда не составит.
создавать как макрос с пометкой что это будет IL и я так понимаю писать его в самом лоджике
Создавать макрос -- да. Писать вне ОЛ, а в ОЛ вставлять через copy&paste или ссылкой на файл.
в любом случае нужен интерпретатор, того что я набрал пальцами в код которой переработается в машинные коды
А зачем интерпретатор в машинные коды?
компилировать ST код в ОЛ-ILт.е. овен должен раскрыть набор инструкций
А зачем интерпретатор в машинные коды? интерпретаор в IL, который в свою очередь сформирует машинные коды
Владимир Ситников
26.04.2017, 16:30
т.е. овен должен раскрыть набор инструкций
Ну, да. В этом есть какая-то проблема?
интерпретаор в IL, который в свою очередь сформирует машинные коды
Вы не понимаете смысл слова интерпретатор. Прошивка ПР выполняет IL команды непосредственно. Грубо говоря, в прошивке заложено то, какие машинные команды соответствуют каждой IL команде. Поэтому "формировать машинные коды" из IL программы уж точно не нужно. В ПР передаётся непосредственно IL, и оно как-то выполняет. Как именно -- мне не так интересно, и этот момент я не предлагаю менять.
Вы не понимаете смысл слова интерпретатор. Прошивка ПР выполняет IL команды непосредственно
мне тоже безразлично как IL обрабатывается в ПР, я говорю про преобразование из, например, javascript в IL для одного пользователя, для другого из VB, третьему сишарп потребуется. Дав набор инструкций, к примеру Вам, для какого языка Вы сделаете преобразование, для всех или только с кем знакомы, хотя бы поверхностно
Владимир Ситников
26.04.2017, 17:23
мне тоже безразлично как IL обрабатывается в ПР, я говорю про преобразование из, например, javascript в IL для одного пользователя, для другого из VB, третьему сишарп потребуется. Дав набор инструкций, к примеру Вам, для какого языка Вы сделаете преобразование, для всех или только с кем знакомы, хотя бы поверхностно
Если кому-то нужно javascript/VB/C# -- пущай делают. Если будет IL, то как раз будет возможность сделать разнообразные языки без изменения прошивки ПР.
Но, на мой взгляд, языки javascript/VB/C# мало кому нужны (да и сделать их непросто будет). Достаточно будет ST -> IL.
ну во первых, скриптовые языки во всех скадах используются, те кто пишет чаще пользуются контроллерами чем кто бы то еще со стороны. Предположим, появился конвертер хотя бы из ST, я не соглашусь что будет достаточно проверок в начальном языке, консистентность данных все равно нужно проверять перед заливкой в пр. поэтому в лоджике работа все равно неизбежна
Владимир Ситников
26.04.2017, 20:12
ну во первых, скриптовые языки во всех скадах используются, те кто пишет чаще пользуются контроллерами чем кто бы то еще со стороны. Предположим, появился конвертер хотя бы из ST, я не соглашусь что будет достаточно проверок в начальном языке, консистентность данных все равно нужно проверять перед заливкой в пр. поэтому в лоджике работа все равно неизбежна
Об'ективно, сделать трансляцию javascript/vb/c# в IL непросто, т.к. в ОЛ-IL нет сборщика мусора.
По поводу работ в ОЛ: разве кто-нибудь говорил, что можно сделать вообще без работ в ОЛ? Разумеется, работы по добавлению p-code блока потребуются.
Но вот работы по ST можно делать без ОЛ.
И, да, я крайне надеюсь, что ОЛ уже проверяет корректность IL кода перед заливкой в ПР.
Проверка это не что-то специальное для p-code блока, а то, что и так должно быть, поэтому и не должно потребовать много времени на поддержку p-code блока.
Владимир Ситников
26.04.2017, 20:22
А вы сами уверены в этом. Прошивка ПР это часть загрузчика и условного ядра ОЛ. А команды все в даташите на MCU прописаны.
Разумеется, когда я пишу про то, "как устроено ОЛ,ПР", то эти слова основаны на сообщениях представителей ОВЕН на форуме и на моих догадках.
Как именно устроен интерпретатор IL в прошивке ПР неважно. Смысл IL блока и состоит в том, чтобы составлять программы без оглядки на устройство конкретной прошивки.
Замечу, что у меня есть опыт программирования, создания сред программирования, поэтому считаю, что мои догадки весьма близки к реальности.
так то в КДС есть конвертер из ST в IL, поэтому что там можно сотворить для ПР смысла нет обсуждать. По поводу корректности, но добавлять же нужно язык не ради наличия языка,а для увеличения функционала и не факт что проверки всего нового имеются. кроме того в соседней теме начинает формироваться мнение, что компиляция происходит на лету, тоже встает вопрос а есть ли тогда конечная проверка перед заливкой
Владимир Ситников
27.04.2017, 09:45
так то в КДС есть конвертер из ST в IL, поэтому что там можно сотворить для ПР смысла нет обсуждать.
Не понимаю. Если речь о том, что "можно использовать КДС как конвертер ST->IL", то тут я не соглашусь. Наверняка ОЛ-IL отличается от КДС IL. Я всё время говорю, что отталкиваться нужно не от МЭК IL, а от того, что уже по факту реализовано в ОЛ-ПР. Так и реализовывать проще, и меньше шансов что-нибудь сломать.
Рассматривать КДС как редактор уж точно не стоит, ведь расширять его и адаптировать под нужды ПР-ОЛ никто не сможет.
И уже был пример использования КДС как редактора (http://www.owen.ru/forum/showthread.php?t=22169&p=180471&viewfull=1#post180471) для железа ОВЕН, со всеми вытекающими "то запускай, это не запускай". В общем, КДС без КДС runtime это точно не вариант.
По поводу корректности, но добавлять же нужно язык не ради наличия языка,а для увеличения функционала и не факт что проверки всего нового имеются. кроме того в соседней теме начинает формироваться мнение, что компиляция происходит на лету, тоже встает вопрос а есть ли тогда конечная проверка перед заливкой
Если честно, то ничего не понял. Тут две фразы по поводу корректности, но уже договорились, что проверка не имеет отношения к p-code блоку. Либо ОЛ уже выполняет проверку кода (надеюсь, что это так), либо не выполняет.
в соседней теме начинает формироваться мнение, что компиляция происходит на лету, тоже встает вопрос а есть ли тогда конечная проверка перед заливкой
Про постоянную компиляцию говорил wal79: http://www.owen.ru/forum/showthread.php?t=25870&page=4&p=233718&viewfull=1#post233718, но к текущей теме это не относится. Можно и так и сяк делать.
Ребят, что реально нужно - это ФБ "формула" с проверкой на переполнение (выход "error"), с поддержкой хотябы минимального набора функций.
Будет внутри возможность ветвления (if-then-else, case и т.п) - ещё лучше.
Чем нравится подход "функциональных блоков" и "макросов" - тем, что результат предсказуем, и базовых блоков этих нужно минимум (надёжность). На булевских схемах ничего большего и не нужно.
Чем не нравится то же на целочисленных и флоатах - нарваться на "переполнение" и прочие артефакты этих арифметик - как 2 пальца. Тем более, даже поддержки отрицательных целых нет.
Если уж введены эти типы, то как-то недоделано, без обработки "исключений".
Если "реле", то всё на логике, если арифметика-математика, то она не должна порождать многочисленных граблей и костылей, выливающихся в паутину ФБ и в плохопредсказуемое поведение программы, нарисованной "релейщиками".
Владимир Ситников
24.07.2017, 14:23
Ребят, что реально нужно - это ФБ "формула" с проверкой на переполнение (выход "error"), с поддержкой хотябы минимального набора функций.
Будет внутри возможность ветвления (if-then-else, case и т.п) - ещё лучше.
Смотрите:
1) Есть условный rovki, который ставит по 100-1000 ПРок на разнообразные объекты в месяц
2) Этот самый rovki издревле паял микросхемы, и ОЛ как раз похоже на эти самые микросхемы
Теперь приходите вы, или я с предложением "сделать блок-формулу (http://www.owen.ru/forum/showthread.php?t=23707)" или "возможность текстового представления блоков (http://www.owen.ru/forum/showthread.php?t=23754)".
Надо ли это условному rovki?
Разумеется, нет:
2.1) rovki уже настолько сросся с микросхемами, что новое ему учить смысла нет. Какой смысл-то? Нарисовать 1000 связей? Да не проблема это. Как представил в голове, остаётся только мышкой пощёлкать и всего делов. Вы только представьте сколько можно нащёлкать за час-два-три. А в обычных программах гораздо меньше 1000 связей, поэтому и вопрос "нащёлкать" вообще не стоит.
2.2) Заказчику без разницы сколько занимает написание программы. Если rovki сказал, что нужно 2 дня мышкой щёлкать, то заказчик заплатит за эти 2 дня.
Если rovki сказал, что "для переделки программы нужна неделя", то он и получит эту неделю. Других вариантов-то нет. Да, тут реальный rovki наверняка заметит, что любая переделка его программы занимает не более 5-15 минут, но, во-первых, не каждый так умеет, а во-вторых, не в конкретных цифрах вопрос.
2.3) Этому самому rovki не нужны конкуренты. Если сделают блок-формулу (if, ещё то-нибудь), то часть программ будет создавать гораздо проще. Разумеется, это сразу подрывает незаменимость. Как же так? Раньше можно было показывать "блок вычисления синуса" на весь экран, и заказчик кивал головой "да, много работы".
Ещё сейчас можно написать PID регулятор (на несколько экранов), и заказчик уж точно поймёт, что это немало работы. Если сделать формулы, то как будет? ПИД регулятор в 10 строк? И кому это нужно?
2.4) Условный rovki реально видел развитие ОЛ. Он на своей шкуре увидел, что даже незначительные доработки ОЛ могут приводить к непредсказуемым последствиям. Если грубо, то "при доработке блока сложения перестали работать сетевые переменные" (конкретную проблему я придумал, но смысл примерно такой).
Вы такие: "давайте добавим блок-формулу". Как это видит rovki: "100% из-за этого сломается что-нибудь старое. Нафиг нужно?"
2.5) У условного rovki свои хотелки в отношении ОЛ. Разумеется, они более важны, чем разнообразные текстовые языки.
2.6) Условному rovki ни отладка, ни online режим не нужен. Во-первых, любую программу можно в голове представить и понять как она будет работать, а где сломается. Во-вторых, есть же симуляция. Запустили схему, пощёлкали, всё поняли. В третьих, есть СКАДА системы, куда можно выгружать данные и рисовать графики.
Поэтому этот условный rovki и будет на подобные предложения отвечать, что "вы не умеете готовить схемы", "текстовые программы невозможно читать-писать", "с графическими программами нет абсолютно никаких проблем" и так далее. С их колокольни это действительно так (см 2.1...2.5).
Теперь со стороны ОВЕН. Им-то вообще нужны эти текстовые языки?
Попробуйте догадаться. Сколько ПР в месяц покупаете вы? Сколько ПР в месяц покупают те, кто просят эти самые текстовые языки для ПР? 1? 0.1?
3.1) Кто платит, тот и заказывает музыку. Т.е. либо прямо много реальных потребителей ПР должны просить текстовые языки, либо просто руководитель ПР на своём энтузиазме решит "а давайте попробуем". И кому надо пробовать, если можно не пробовать и получать ту же прибыль?
3.2) Условный rovki может обидеться и сказать "раз вы так, уйду к другим ПР"
3.3) Доработка ОЛ это деньги на разработку, тестирование, документирование и т.п. См. 3.1
3.4) Как в любой доработке, есть риски, что "сделаем одно, сломается другое". Выкатывать обновления ОЛ, которые будут работать неправильно крайне опасно. Ведь несколько таких обновлений и инженеры станут вообще обходить ПР стороной.
3.5) Если сделать редактор типа "блокнот", то будет 100500 дурацких вопросов от пользователей "у меня программа не работает", когда на самом деле просто пропущена точка с запятой или что-нибудь в этом духе. Сделать же нормальный редактор -- непростая задача.
3.6) Может, есть конкуренты? Ну, море конкурентов, у которых есть эти самые текстовые языки программирования ПР, и на которые народ из-за этого переходит толпами? Да нет таких.
3.7) Может, ОВЕНу нужна конкуренция между ПР и ПЛК? Безусловно нужно сделать так, чтобы ПР было сравнимо по возможностям с ПЛК. Чтобы было сложнее продавать ПЛК за 20 т.р., когда то же самое умеет ПР за 5 т.р.
В итоге, спроса на "блок-формулу" нет, и этот самый блок не появится.
Если "реле", то всё на логике, если арифметика-математика, то она не должна порождать многочисленных граблей и костылей, выливающихся в паутину ФБ и в плохопредсказуемое поведение программы, нарисованной "релейщиками".
На это тоже есть ответ "ПР это реле, а в реле никогда не было формул". Можно смеяться, можно плакать, но на полном серьёзе так говорят.
Владимир вот вы просите ФБ "Блок-Формулу" . Как она конкретно выглядеть по вашему. Предложите свой вариант. У немецкой 8 есть такой блок Блок аналоговых вычислений рассчитывает значение AQ по уравнению,сформированному из определенных пользователем операндов и операторов. 4 типа действий +: - : *(умножить): /(делить). Но я не вижу где мне его использовать в станции управления насосом. Я просто осушаю резервуар по 4 датчика и сообщаю о поломках через облако на телефон. Приведите конкретный пример где это нужно массово. И я уверен Овен скажет да это нужно и выделит на это ресурсы. Овен запускает второй прибор на базе ПР200 без "кодесисовских " примочек. И я думаю что это не последняя разработка.
Владимир вот вы просите ФБ "Блок-Формулу" . Как она конкретно выглядеть по вашему. Предоите свой вариант. У немецкой 8 есть такой блок Блок аналоговых вычислений рассчитывает значение AQ по уравнению,сформированному из определенных пользователем операндов и операторов. 4 типа действий +: - : *(умножить): /(делить). Но я не вижу где мне его использовать в станции управления насосом. Я просто осушаю резервуар по 4 датчика и сообщаю о поломках через облако на телефон. Приведите конкретный пример где это нужно массово. И я уверен Овен скажет да это нужно и выделит на это ресурсы. Овен запускает второй прибор на базе ПР200 без "кодесисовских " примочек. И я думаю что это не последняя разработка.
Это я прошу :)
Как выглядеть?
Элементарно.
Количество и тип входов, количество и тип выходов.
В теле - скрипт, в котором допускается использовать только константы и входные/выходные переменные. Поддержка мат. Функций, проверка на переполнение при расчёте формул из скрипта и установка "спецвыхода" "OW" в случае обнаружения такового в 1 (для возможности обработки в схеме этих ситуаций).
Возможность примитивного ветвления по условию.
"If i1=1
Then q1:=sqrt(i2^2 +i3^2); q2:=2*sin(i4)
Else if i1=2
Then q1:=sqrt(i2^2-i3^2); q3:=log(i4)/3
Else q1:=1; q2:=0
"
А теперь возьмите и нарисуйте то же самое из ФБ, даже имея ФБ мат. Функций, организуйте проверку переполнения...
Смотрите:
1) Есть условный rovki,"...
Теперь со стороны ОВЕН. ....
У вас раз троение личности батенька ...За всех всю решил ..И мания величия, однако .
Владимир Ситников
24.07.2017, 18:49
...
У вас раз троение личности батенька ...За всех всю решил ..И мания величия, однако .
rovki, диагнозы ставить не ваш конёк. Если по существу есть что -- не стесняйтесь.
Я давно веду пропаганду, что "Флаг в руки командам ОЛ-ПР, создавшим столь высококлассный продукт (http://www.owen.ru/forum/showthread.php?t=23754&page=14&p=240933&viewfull=1#post240933)", и что "ничего нового добавлять в прошивку ПР не нужно (http://www.owen.ru/forum/showthread.php?t=23754&page=18&p=241232#post241232)"
Тут появляется pop70 и хочет странного, которое явно идёт в разрез с ПР-ОЛ. Вот я наглядно и объяснил почему от введения блока-формулы / блока-скрипта / блока-текстовой-программы одни только минусы как для ОВЕН, так и для текущих массовых потребителей.
игорь68, раньше я предлагал и ОЛ-формулы, и ОЛ-IL (конкретные варианты обсуждались), но сейчас моё понимание в том, что "связка ПР-ОЛ по идеологическим причинам должна быть как электромагнитное реле и ни граммом лучше (http://www.owen.ru/forum/showthread.php?t=23754&page=14&p=240933&viewfull=1#post240933)"
связка ПР-ОЛ по идеологическим причинам должна быть как электромагнитное реле и ни граммом лучше (http://www.owen.ru/forum/showthread.php?t=23754&page=14&p=240933&viewfull=1#post240933)"
Как эм реле, нужно убрать аналоговые входы-выходы, убрать все встроенные ФБ, кроме одного элемента ИЛИ-НЕ и "линии задержки" и отключить все макросы.
Один ИЛИ-НЕ и линия задержки позволяет создать все имеющиеся логические элементы, триггеры и счётчики-генераторы-таймеры прямо на холсте проекта. А на "эм реле" большего и не сделать.
Так что, что-то не так с "идеологией". :)
Инты и флоаты, кстати, тоже можно организовать через двоичную "шину данных".
Если постараться - хоть коре i7 нарисовать можно из 1 логического элемента и линии задержки. А потом на нём линукс запустить... Да хоть винду... И запустить ОЛ :)
rovki, диагнозы ставить не ваш конёк. Если по существу есть что -- не стесняйтесь.
Я давно веду пропаганду, что "Флаг в руки командам ОЛ-ПР, создавшим столь высококлассный продукт (http://www.owen.ru/forum/showthread.php?t=23754&page=14&p=240933&viewfull=1#post240933)", и что "ничего нового добавлять в прошивку ПР не нужно (http://www.owen.ru/forum/showthread.php?t=23754&page=18&p=241232#post241232)"
Тут появляется pop70 и хочет странного, которое явно идёт в разрез с ПР-ОЛ. Вот я наглядно и объяснил почему от введения блока-формулы / блока-скрипта / блока-текстовой-программы одни только минусы как для ОВЕН, так и для текущих массовых потребителей.
игорь68, раньше я предлагал и ОЛ-формулы, и ОЛ-IL (конкретные варианты обсуждались), но сейчас моё понимание в том, что "связка ПР-ОЛ по идеологическим причинам должна быть как электромагнитное реле и ни граммом лучше (http://www.owen.ru/forum/showthread.php?t=23754&page=14&p=240933&viewfull=1#post240933)"
По существу - пропагандируйте от своего имени ,не преплетая ни меня ни Овен,вас в пресс секретари не нанимали.У кого какие коньки не вам судить .
По существу - пропагандируйте от своего имени ,не преплетая ни меня ни Овен,вас в пресс секретари не нанимали.У кого какие коньки не вам судить .
Да ладно Вам. Не обращайте внимания. Владмир просто пытается взять овен "на понял" ;)
Понятно, что некоторые хотелки МОГУТ не вписаться в идеологию ПО, разработанную под "реле с логикой", и потребовать либо заново переосмыслить и переделать ОЛ с нуля, либо костылей, которые не добавят стабильности и "обслуживаемости" самому ОЛ.
Согласен, что промышленную серию просто так не остановишь и не переделаешь безболезненно, что, при смене "идеологии", возрастут затраты на поддержку (и старое тащить, и новое). Как разруливать эту ситуацию - решать производителю и только ему - ему виднее. Просто, не надо за него додумывать, и на основании этих выдумок самим отказываться от функционала, который ПРИНЦИПИАЛЬНО ВОЗМОЖЕН.
Вообще, конечно, развитие мк (микросхем) сейчас дают возможность сближать функциональность контроллеров и простоту программирования ПР, но это требует новых "идеологических решений". Как сможет овен разрулить "новое, сохранив старое" - так и будет.
Наше дело маленькое - просить то, чего "хочется" (формировать спрос) и выбирать тех, чья продукция лучше соответствует хотелкам (выбирать предложения). Не будем формировать спрос мы - производитель сам его сформирует как удобнее ему и предложит "походить по базару".
Это я прошу :)
Как выглядеть?
Элементарно.
Количество и тип входов, количество и тип выходов.
В теле - скрипт, в котором допускается использовать только константы и входные/выходные переменные. Поддержка мат. Функций, проверка на переполнение при расчёте формул из скрипта и установка "спецвыхода" "OW" в случае обнаружения такового в 1 (для возможности обработки в схеме этих ситуаций).
Возможность примитивного ветвления по условию.
"If i1=1
Then q1:=sqrt(i2^2 +i3^2); q2:=2*sin(i4)
Else if i1=2
Then q1:=sqrt(i2^2-i3^2); q3:=log(i4)/3
Else q1:=1; q2:=0
"
А теперь возьмите и нарисуйте то же самое из ФБ, даже имея ФБ мат. Функций, организуйте проверку переполнения...
Возможно задам самый глупый вопрос ДЛЯ ЧЕГО ЭТО ВЕТВЛЕНИЕ НУЖНО? Где в контроле датчика уровня резервуара я это буду использовать. Или это ветвление мне нужно для отключения аварийного насоса и подключения резервного. Я тут открыл один станок для производства пластиковых окон одно известной фирмы. Скажем 7
из 10 заводиков с объёмом до 20 окон в смену это заводы этой фирмы.Так внутри стоит зарубежный аналог ПР114( регулирует температуру тена ). Производитель как то смог написать софт для реле без математических блоков. Пока мне удобно делать КНС на ПР я и буду делать. Не будет ПР соберу схему на компараторе и трех четырех микросхемах простой логики и получу такой же блок управления КНС. Что вы будете делать с блоком ветвления я не знаю.
Возможно задам самый глупый вопрос ДЛЯ ЧЕГО ЭТО ВЕТВЛЕНИЕ НУЖНО? Где в контроле датчика уровня резервуара я это буду использовать. Или это ветвление мне нужно для отключения аварийного насоса и подключения резервного. Я тут открыл один станок для производства пластиковых окон одно известной фирмы. Скажем 7
из 10 заводиков с объёмом до 20 окон в смену это заводы этой фирмы.Так внутри стоит зарубежный аналог ПР114( регулирует температуру тена ). Производитель как то смог написать софт для реле без математических блоков. Пока мне удобно делать КНС на ПР я и буду делать. Не будет ПР соберу схему на компараторе и трех четырех микросхемах простой логики и получу такой же блок управления КНС. Что вы будете делать с блоком ветвления я не знаю.
Я вообще не понимаю зачем Вам для управления КНС ПР за 5000р, если то же самое можно сделать на релюшках за 100 рублей.
Насосную станцию на даче от одного российского производителя, влюблённого в "мигающие лампочки" я уже переделал после того, как увидел ценник на датчик давления от неё (сдохший), а до того ремонтировал электронный блок (сам). Механическое РД и никаких заморочек.
Это я к тому, что если изделие позволяет больше, то и обоснованных сфер применения его становится больше.
А уж где какие вычисления и условия понадобятся - это вопрос чисто риторический.
Можно, конечно, и суперкомпьютер использовать в качестве печатной машинки или для колки орехов (Ваш пример про КНС), но возможностей его применения гораздо больше.
Ещё один пример.
Вас в школе (а потом, наверное, в ВУЗе) учили физике, математике... пению даже и рисованию...
А зачем? Где в Вашей КНС это всё использовать? ;)
Воот! Вот где-то так же вчглядит и вопрос про ПР "а зачем нам в КНС формулы?"
рор70 просто приведите пример где это нужно . Хотя бы в единичном случае.
рор70 просто приведите пример где это нужно . Хотя бы в единичном случае.
Самый простой пример в соседней ветке - мультиплексор целых (а почему бы и не с плавающей точкой?).
Зачем? Ну, например, для резервирования датчиков, или сбора информации с множества датчиков.
Это условия.
А синус вычислять нужно, например, чтобы расчитать время восхода и захода Солнца.
В станках со сложной геометрией движения может и не то понадобиться.
А синус вычислять нужно, например, чтобы расчитать время восхода и захода Солнца.
Вы знаете сколько занимает процессорного времени вычисление синуса? ОЛ еще до заливки проекта может сказать сколько миллисекунд будет занимать цикл, с введением формул, которые могут использоваться рекурсивно, а это обязательно случиться с появлением такого функционала, длительность цикла подсчитать будет не возможно, это вряд ли приемлемо в системах реального времени
Вы знаете сколько занимает процессорного времени вычисление синуса? ОЛ еще до заливки проекта может сказать сколько миллисекунд будет занимать цикл, с введением формул, которые могут использоваться рекурсивно, а это обязательно случиться с появлением такого функционала, длительность цикла подсчитать будет не возможно, это вряд ли приемлемо в системах реального времени
А что? Процесс вычисления синуса через макрос как сейчас занимает меньше времени?
Ну и насчёт "систем реального времени" - это Вы явно погорячились. Ни одно ПР и близко не лежало... Сам принцип "посмотрел входы, посчитал, включил выходы" в корне противоречит архитектуре "систем реального времени".
И оптимизация вычислений - это-таки "право и головная боль" разработчика системы.
Странно когда "из заботы о чужой головной боли" эту чужую голову предлагают просто срубить под корень.
И Вы, наверное, знаете что-то, что не знаю я, раз говорите о возможности рекурсии в скриптах.
Вы знаете сколько занимает процессорного времени вычисление синуса?
Задался вопросом, поискал.
Для STM32, при точности е-6 порядка 15-20 тактов. Или, при 100Мгц, 200 НАНОсекунд. :)
Владимир Ситников
25.07.2017, 16:46
Задался вопросом, поискал.
Для STM32, при точности е-6 порядка 15-20 тактов. Или, при 100Мгц, 200 НАНОсекунд. :)
Вы какой именно STM32 смотрели?
В ПР200 softfloats, т.е. вообще все float вычисления эмулируются.
И за 20 тактов вряд ли уложится.
200 НАНОсекунд. :)
относительно чего Вас веселят 200 нс?
Вы какой именно STM32 смотрели?
В ПР200 softfloats, т.е. вообще все float вычисления эмулируются.
И за 20 тактов вряд ли уложится.
В STM32 начиная с серии f3 FPU есть у всех.
Чем "эмулируются" float-ы в ПР, и главное - зачем, я понятия не имею.
Какой там stm32 стоит в ПР200?
Насчёт тактов
http://forum.ixbt.com/topic.cgi?id=48:10872
За что купил, за то продал. Даж округлил вверх.
относительно чего Вас веселят 200 нс?
Относительно цикла в 1милисекунду, который Вы так боитесь сломать вычислением синуса.
Самый простой пример в соседней ветке - мультиплексор целых (а почему бы и не с плавающей точкой?).
Зачем? Ну, например, для резервирования датчиков, или сбора информации с множества датчиков.
Это условия.
А синус вычислять нужно, например, чтобы расчитать время восхода и захода Солнца.
В станках со сложной геометрией движения может и не то понадобиться.
У ПР физически 2 порта аналоговых. Возьму простой ФБ "преобразователь сопротивления в температуру (NTC)" и по его сигналу АВАРИЯ сделаю переключение на второй преобразователь. И выдам сообщение в скаду или облако. Я справился с задачей резервирования датчиков без применения матеметического блока формул или нет
Владимир Ситников
25.07.2017, 17:17
В STM32 начиная с серии f3 FPU есть у всех.
Чем "эмулируются" float-ы в ПР, и главное - зачем, я понятия не имею.
В ПР200 STM32F103VCT. Т.е. это F1 серия, в которой FPU нет.
Относительно цикла в 1милисекунду, который Вы так боитесь сломать вычислением синуса.
внимательно вникните в слова, чего я противлюсь в добавлении скриптов. В плк цикл while(true) приведет к перезагрузке контроллера. В ОЛ пока ни кто не встречался с подобным явлением, потому что на стадии редактирования проекта известно время его работы, добавление математики в скриптах лучше ПР не сделает, а для тех кто считает, что разработчик легко и непринужденно к скриптам добавит всевозможные проверки на переполнения и чего то там еще, у меня предложение самим попробовать создать приложение для продакшена, ну или хотя бы попытаться
внимательно вникните в слова, чего я противлюсь в добавлении скриптов. В плк цикл while(true) приведет к перезагрузке контроллера. В ОЛ пока ни кто не встречался с подобным явлением, потому что на стадии редактирования проекта известно время его работы, добавление математики в скриптах лучше ПР не сделает, а для тех кто считает, что разработчик легко и непринужденно к скриптам добавит всевозможные проверки на переполнения и чего то там еще, у меня предложение самим попробовать создать приложение для продакшена, ну или хотя бы попытаться
А где я просил циклы в скрипты?
И где писал, что "легко" добавить?
Кому что будет легко или нелегко - пусть решает тот, кто знает существующую систему.
Почему Вы решаете за них, что это "трудно, аж невозможно"?
А флаг переполнения процессор сам прекрасно выставляет при арифметичесеих операциях. Уж обработать и передать готовое...
А где я просил циклы в скрипты?
Вы просили формулу, какова формула например для множества Мандельброта
легко или нет добавить не решаю, а объясняю Вам что заниматься надо насущными проблемами, а не http://www.owen.ru/forum/showthread.php?t=23754&p=253266&viewfull=1#post253266 пункты 3.4-3.5
В ПР200 STM32F103VCT. Т.е. это F1 серия, в которой FPU нет.
Хреново. Но, учитывая "pin-to-pin" совместимость стм-ок, решаемо. Цена вопроса 150 руб.
Вы просили формулу, какова формула например для множества Мандельброта
легко или нет добавить не решаю, а объясняю Вам что заниматься надо насущными проблемами, а не http://www.owen.ru/forum/showthread.php?t=23754&p=253266&viewfull=1#post253266 пункты 3.4-3.5
Нет. И ещё раз нет. Я против циклов в "пользовательском коде" для промышленных решений. И не прошу "высшей математики". Только примитивные линейные формулы и скрипты с условным присвоением. А всё, что требует вычислений в цикле, только в виде готовой функции.
Чем заниматься в первую очередь, чем во вторую, а чем никогда - пусть решает ПРОИЗВОДИТЕЛЬ.
Ещё раз повторю - наше дело "щенячье" - озвучить "хотелки", и не заниматься придумыванием отговорок от лица производителя.
Нет. И ещё раз нет. Я против циклов в "пользовательском коде" для промышленных решений. И не прошу "высшей математики". Только примитивные линейные формулы и скрипты с условным присвоением. А всё, что требует вычислений в цикле, только в виде готовой функции.
Т.е. ради плюс, минус, деление и умножение, добавить в ОЛ интерпретатор языка, интерфейс ввода примитивных формул
Т.е. ради плюс, минус, деление и умножение, добавить в ОЛ интерпретатор языка, интерфейс ввода примитивных формул
Да. Ради "плюс-минус" и прочих "синусокосинусов", позволяющих вместо паутины из сотен связей, сделать арифметику проекта читабельной, писабельной, отлаживаемой, а значит, и более надёжной. Существующая недоарифметика, не поддерживающая отрицательных чисел, не контролирующая переполнение - это как "российская ОС", годящаяся только для "пишущих машинок", и самоудовлетворения "фрилансеров" и "свободного сообщества" "ардуинщиков".
Повторяю - это ПР, а не ПЛК.
Хоте все это, + онлайн отладку, + псевдомногозадачность, + еще ряд плюшек - доплатите 10круб и купите ПЛК63.
Да. Ради "плюс-минус" и прочих "синусокосинусов", позволяющих вместо паутины из сотен связей, сделать арифметику проекта читабельной, писабельной, отлаживаемой, а значит, и более надёжной. Существующая недоарифметика, не поддерживающая отрицательных чисел, не контролирующая переполнение - это как "российская ОС", годящаяся только для "пишущих машинок", и самоудовлетворения "фрилансеров" и "свободного сообщества" "ардуинщиков".
ну для таких же как Вы есть другие контроллеры, с нормальной арифметикой. Мир многообразен, паутина из сотен связей появляется не только из-за отсутствия косинуса, мультиплексора и чего то еще из математики, в большинстве задач для применения ПР они совершенно не нужны, да и сам подход применения сложных расчетов обычно приходит у тех, кто переходит с контроллеров высокого уровня по отношению к ПР
Владимир Ситников
25.07.2017, 19:02
Т.е. ради плюс, минус, деление и умножение, добавить в ОЛ интерпретатор языка, интерфейс ввода примитивных формул
Ага, и ещё не стоит забывать про https://xkcd.com/1205/
Отрезвляет в плане того, когда автоматизация экономит время.
Гораздо проще и надёжнее просто добавить нужный макрос в ОЛ, чем городить блок-формулу и остаться без макроса, но с потенциальными проблемами в ОЛ и потраченным временем на блок-формулу.
пусть решает ПРОИЗВОДИТЕЛЬ
Во-первых, тема создана более года назад. Производитель уже всё сказал.
Во-вторых, ответ производителя:
Основная логика OL - простая система для широкого круга пользователей. Знакомых с релейкой и работой с шрафическим представлением ФБ. И этого мы, в ближайшее время, менять не планируем.
Основной язык бесспорно останется FBD.
В третьих, ещё ответ производителя. Если что, то Владислав и в ПР и в ПЛК рубит, он-то как никто другой знает где отговорки, а где бесперспективные темы.
Давайте уже закроем эту абсолютно бесперспективную тему.
Вот с этим согласен (в третьих).
Появляются новые пользователи ,не хотят читать форум ранее ,создают аналогичные темы ,задают старые вопросы....
Повторяю - это ПР, а не ПЛК.
Хоте все это, + онлайн отладку, + псевдомногозадачность, + еще ряд плюшек - доплатите 10круб и купите ПЛК63.
Нет не хочу. Хочу простое в программировании даже для "релейщика" устройство, не экономя на надёжности и безопасности, используя его в максимальном числе случаев. Поэтому, мне не нужен ПЛК, не нужен С, но и "псевдоарифметика на ФБ"fadd"" - это не то, что мне нужно.
Для "управления КНС" обойдусь парой эм релюшек, для колки орехов - молотком, вместо "высокотехнологического" "микроскопа с заклеенными "чтобы не поцарапались" линзами".
Все о чем вы говорите закладывается в начале разработки .Лет пять назад,вы опоздали ,когда только пр110 появились без целочисленной арифметики .Ни кто не будет все перелапачивать ,текущих дел выше крыши .Вас услышали и на этом надо заканчивать ...FBD так FBD и ни каких мутантов(одноязычных) -мое мнение .Для остального есть ПЛК с кодесис (не СИ, вы что их не использовали?)
ну для таких же как Вы есть другие контроллеры, с нормальной арифметикой. Мир многообразен, паутина из сотен связей появляется не только из-за отсутствия косинуса, мультиплексора и чего то еще из математики, в большинстве задач для применения ПР они совершенно не нужны, да и сам подход применения сложных расчетов обычно приходит у тех, кто переходит с контроллеров высокого уровня по отношению к ПР
"Уровень" - понятие относительное.
Спросите у разработчика ОЛ почему он писал его на С# в VisualStudio, а не на "более высоком"(по Вашим понятиям) уровне С и asm-е.
Вот так и с контроллерами. Железо растёт, и stm32f103 уже перерос "уровень" ПР в том виде, в котором Вы его хотите видеть. Иначе, к ОЛ и ПР не стали бы прикручивать костыли в виде "softFPU", чтобы приподнять уровень ПР чуть выше, чем "управление КНС".
Всё это напоминает историю "телефон-коммуникатор-компьютер".
Результат известен - большинство повседневных (потребительских) функций компьютера теперь выполняется на смартфонах.
Так и с ПР. Если их искуственно не ограничивать, то различий возможностей с ПЛК через несколько лет и не увидите. А разработка промавтоматики перестанет быть уделом "искушённых в С и asm-e", и станет делом "местного электрика", задолбавшегося чистить контакты релюшек, и такого же "киповца".
Для этого и нужно всего-то дать им ВЫСОКОУРОВНЕВЫЙ инструмент, позволяющий использовать железо ПР на 100%, не лазя в дебри и не наступая на грабли и костыли "псевдоарифметики".
ОЛ и ПР так и задумывались наверняка. Но вот "запас на рост железа" оказался маловат.
ПР200 перерос сегодняшний ОЛ на 2 головы.
...
Тогда мне не понятен Ваш бесконечный троллинг на эту тему с поддеванием и овена и rovki.
Сергей0308
25.07.2017, 20:35
Тогда мне не понятен Ваш бесконечный троллинг на эту тему с поддеванием и овена и rovki.
Что тут непонятного, помните шутки товарища Сталина: когда ему сказали что вероятность предсказания прогноза погоды 40%, он ответил, что тогда вы лучше говорите наоборот и вероятность предсказания прогноза сразу увеличится с 40 до 60%!
Уважаемый рор70. Не стал долго лазить по инету да простит меня ОВЕН что указал производителей других реле. Вот сименс лого8; зелиологик от шнайдер электрик; любимый М3 софт от краузет. Этих трех марок достаточно. У всех этих трех реле есть ФБ блок математики. Вы вот прежде чем что то предложить установите себе на комп эти программы. Они все в свободном доступе. Разберитесь с этими математическими модулями и попробуйте написать то что вы хотели выше. Думаю что вы не станет это делать. Потому что не выйдет.
PS Овен вам на заметку. Французский краузет имеет ФБ управления ориентации панелей солнечных батарей по 2 осям(Х/У).
Французский краузет имеет ФБ управления ориентации панелей солнечных батарей по 2 осям(Х/У).
Такое сделать на ОЛ не сложно ,с привязкой к местности и ориентации на солнце ,не намного сложнее чем солнечные часы в виде макроса.
ROVKI Ваш макрос ПЗУ он же кулачковый переключатель что вы делали пару лет назад можно сказать "Устарел" Французы в самой последней версии кроме 8 выходов добавили числовой выход который позволяет выводить на экран номер позиции( ячейки ) что сейчас на выходах.
Когда достаточно табличного представления данных(не большая точность) ,то макроса ПЗУ за глаза .Когда нужно знать значение Y в каждой точке Х ,то нужно вычислять или применять интерполяцию.
Про второе не совсем понял про номер позиции .Если речь о состоянии выходов ,то и в ОЛ можно вывести на экран их состояние (0,1)
Про ПЗУ. Ячейка номер 1 Данные 01010101. Ячейка номер 2 Данные 10101010. Ячейка 3 Данные 11011011. Если у меня на выходе сейчас 11011011 то на числовом выходе если подключить экран будет НОМЕР ЯЧЕЙКИ 3. Если сдвину на шаг НАЗАД то НОМЕР ЯЧЕЙКИ будет 2 а выхода 10101010. Это я так для примера написал. Если интересно могу завтра выложить ТЗ на новый макрос ПЗУ, кулачковый переключатель.
Так адрес ячейки в ПЗУ (номер ячейки) на входе макроса ,на выходе данные(в десятичном формате ,если нужен булевом ,то ставьте экстракт ) .Если нужен адрес ,то пошлите его на экран В чем проблема ??????
Владимир Ситников
26.07.2017, 00:21
Тогда мне не понятен Ваш бесконечный троллинг на эту тему с поддеванием и овена и rovki.
Так передёргивать же прикольно.
Особенно весело, когда приводят технические аргументы, хотя корень проблемы явно не технический, а организационный.
Вот возьму и процитирую Андрея ещё разок (то же самое сообщение, но немного другой фрагмент):
Но добавление редактора для создания макросов на Си подобных языках обдумаем. Большое спасибо за идею.
Я говорю вот о чём: да, скорее всего, технических препятствий сделать "формулы" в ОЛ нет. Я в ОВЕН не работал, но нужную часть информации по ОЛ-ПР представители ОВЕН на форуме рассказали, поэтому считаю, что достаточно точно вижу картину.
Всё упирается лишь в организационно-материальные вопросы.
"Озвучивание хотелок" не булькает. Если кто-нибудь придёт в ОВЕН с 20 миллионами денег, то, возможно, ОВЕН послушает хотелку.
А так, любая "непонятная хотелка" просто отсеивается на входном фильтре, т.к. денег не принесёт, а ресурсы потребует.
Вот вы лично сколько готовы заплатить за блок-формулу?
Надеяться на то, что "именно эта хотелка окажется самой приоритетной для ОВЕН", конечно, можно, но это уж слишком оптимистично.
Есть гораздо более простые задачи как то "сделать доступ к клавишам из ОЛ схемы", "эмулятор экрана" и т.п.
Поэтому едва ли стоит тратить время на красочные описания того, как блок-формула решит кучу проблем КНС, как живительная формула переманит инженеров с других реле и т.п. Это всё вилами по воде.
Ежу понятно, что польза от формулы есть. Но тут дело в том, что и без формулы тоже как-то работает. Зачем делать ещё что-то, если и так работает?
Поэтому варианта два:
1) Просто забить. Да, нету в мире этого, как его - счастья. Да, уродские fADD в ОЛ, и только беззнаковые целые. Ну и пофиг. Я, возможно, повесился бы, если бы меня в ОЛ заставляли программировать, но я на такую работу и не устраиваюсь, поэтому и проблем нет.
2) Попробовать постучаться к какому-нибудь другому производителю ПР/ПЛК с идеей. Возможно, они отреагируют. Если взлетит, то и остальные производители подтянутся. МЗТА, например, без проблем идут на контакт, и не требуют подписывать разнообразные "соглашения о неразглашении". Но у меня ОВЕН ПЛК, поэтому тему МЗТА я не особо прорабатываю на текущий момент.
3) Организовать своё производство "правильных ПР".
Хотя, конечно, второй вариант может и не сработать. Например, производитель С* для своего реле не делает режим симуляции, т.к. считает, что симуляция никогда не сможет повторить реальное железо, поэтому даже и не стоит пытаться симулировать. У ОВЕН симуляция есть. Да, она неидеальна, но по-моему, наличие даже такой симуляции это гораздо лучше, чем совсем без неё. Тем не менее, производитель С* не чешется над добавлением симуляции.
Так и тут: если кто-то добавит блок-формулу, то не факт, что и ОВЕН последует.
я вот тут немного не допонял, Вы по образованию, кто, гуманитарий? Ничего не перепутали, имеете представление о различиях МК и ПЛК? Какой С, какой асм? В чем суть понятия, которое Вы озвучиваете, псевдоарифметика? Знаю про псевдослучайные числа, вроде совсем не плохо что они есть, а здесь в каком смысле употребляется этот термин псевдо? Еще с понтов про систему реального времени закралась мысль, что не из "наших" Вы
Не :) Я не из "Ваших". Не из "гуманитариев-маркетолухов", точно знающих чем ПР отличается от ПЛК, и вворачивающих "системы реального времени" в разговор о ПР. :)
Поэтому, что такое "псевдоарифметика" на "логических элементах", и почему это - явный костыль, "Вам" объяснять бесполезно.
Тем не менее, во многих системах программирования ПЛК только с языком FBD именно так. Люди пользуются и не жалуются. Это нормально. Это ПЛК/GH, а не числодробилка.
Я говорю вот о чём: да, скорее всего, технических препятствий сделать "формулы" в ОЛ нет. Я в ОВЕН не работал, но нужную часть информации по ОЛ-ПР представители ОВЕН на форуме рассказали, поэтому считаю, что достаточно точно вижу картину.
Всё упирается лишь в организационно-материальные вопросы.
"Озвучивание хотелок" не булькает. Если кто-нибудь придёт в ОВЕН с 20 миллионами денег, то, возможно, ОВЕН послушает хотелку.
А так, любая "непонятная хотелка" просто отсеивается на входном фильтре, т.к. денег не принесёт, а ресурсы потребует.
Вот вы лично сколько готовы заплатить за блок-формулу?
Надеяться на то, что "именно эта хотелка окажется самой приоритетной для ОВЕН", конечно, можно, но это уж слишком оптимистично.
Есть гораздо более простые задачи как то "сделать доступ к клавишам из ОЛ схемы", "эмулятор экрана" и т.п.
Поэтому едва ли стоит тратить время на красочные описания того, как блок-формула решит кучу проблем КНС, как живительная формула переманит инженеров с других реле и т.п. Это всё вилами по воде.
Ежу понятно, что польза от формулы есть. Но тут дело в том, что и без формулы тоже как-то работает. Зачем делать ещё что-то, если и так работает?
Поэтому варианта два:
1) Просто забить. Да, нету в мире этого, как его - счастья. Да, уродские fADD в ОЛ, и только беззнаковые целые. Ну и пофиг. Я, возможно, повесился бы, если бы меня в ОЛ заставляли программировать, но я на такую работу и не устраиваюсь, поэтому и проблем нет
Да я именно это и говорю.
Моя задача - озвучить то, чего мне не хватает. Без истерик "дайте завтра, а то я от вас уйду и не приду". А ПРОИЗВОДИТЕЛЬ пусть сам занимается "маркетингом" - это его изделие, его бизнес.
Удивляет другое. Такие же пользователи как я, начинают меня учить маркетингу овеновских продуктов, выпучив глаза рассказывают "сколько процессорного времени отнимет sin(x) от "системы реального времени", которую они каждый день строят на ПР для управления КНС, где этот синус нафиг не впёрся", и устраивают истерики "не надо нормальной арифметики в ПР, а то нам станет скушно без fadd, и мы от овена уйдём". :)
Уважаемые коллеги! Занимайтесь своими КНС так, как считете нужным. Овен пусть занимается своим бизнесом, Вы - своим, а я своим. Не надо их учить. И мне не надо рассказывать как нужно делать на ПЛК за 20т.р. то, чему и ПР за 5т.р. МНОГО. Тренируйтесь на своих заказчиках ;).
Тем не менее, во многих системах программирования ПЛК только с языком FBD именно так. Люди пользуются и не жалуются. Это нормально. Это ПЛК/GH, а не числодробилка.
Т.е. вы подгоняете возможности устройств под свои понятия о них, а не исходя из их реальных технических характеристик?
Что Вы называете "техническими характеристиками"?
Да я именно это и говорю.
Моя задача - озвучить то, чего мне не хватает. Без истерик "дайте завтра, а то я от вас уйду и не приду". А ПРОИЗВОДИТЕЛЬ пусть сам занимается "маркетингом" - это его изделие, его бизнес.
Удивляет другое. Такие же пользователи как я, начинают меня учить маркетингу овеновских продуктов, выпучив глаза рассказывают "сколько процессорного времени отнимет sin(x) от "системы реального времени", которую они каждый день строят на ПР для управления КНС, где этот синус нафиг не впёрся", и устраивают истерики "не надо нормальной арифметики в ПР, а то нам станет скушно без fadd, и мы от овена уйдём". :)
Уважаемые коллеги! Занимайтесь своими КНС так, как считете нужным. Овен пусть занимается своим бизнесом, Вы - своим, а я своим. Не надо их учить. И мне не надо рассказывать как нужно делать на ПЛК за 20т.р. то, чему и ПР за 5т.р. МНОГО. Тренируйтесь на своих заказчиках ;).
Пять баллов! Лучше не скажешь просто.
Что Вы называете "техническими характеристиками"?
Производительность процессора например? В частности объем памяти, быстродействие, разрядность? То что еще сравнительно недавно было сложно реализовать на том железе, что имелось и на котором разрабатывались первые ПР, которые в свою очередь и определили само понятие ПР и его характеристики, теперь вполне возможно сделать на современных контроллерах. В первую очередь математику ту же. Но мы ведь не пойдем таким еретическим путем, не так ли? Если первые ПР были на 8-разрядных микроконтроллерах, то мы и имея 32-разрядный, с арифметическим сопроцессором, все равно сэмулируем 8-битную архитектуру и напишем под неё арифметические подпрограммы? А потому что это ПР, что делать.
Вы допускаете типичную "советскую" ошибку. Железо все, остальное - ничто, особенно когда за это не берут деньги.
Только вот без инструментальной среды ПР/ПЛК - ничто. Единицы будут программировать их на стандартных программистских языках.
P.S. Производительность процессора ПР можно сравнить с производительностью i80286. Предлагаете сделать их ПР PC-AT???
Вы допускаете типичную "советскую" ошибку. Железо все, остальное - ничто, особенно когда за это не берут деньги.
Только вот без инструментальной среды ПР/ПЛК - ничто. Единицы будут программировать их на стандартных программистских языках.
P.S. Производительность процессора ПР можно сравнить с производительностью i80286. Предлагаете сделать их ПР PC-AT???
Наверное потому что я материалист и не молюсь на Бога в виде ОЛ. Если возможности железа превышают возможности инструментальной среды, то это конец для ЭТОЙ инструментальной среды, в моем понимании. Какая будет новая, с нуля или модернизированная - это можно обсуждать. И да, если железо позволяет вводить новые возможности - их надо вводить. Кстати, первые персональные компьютеры вовсе не походили на современные и это потому, что разработчики компьютеров не следовали вашей логике - "ПК должен быть только такой ...".
Не совсем так.
Каждаой системе - своя ниша. У ПР200 и аналоговые входы эээээ оставляют желать лучшего. И много чего еще. И это нормально.
Повторяю - все Ваши хотелки есть в ПЛК63/КДС. Покупайте и пользуйтесь.
А среды... Оцените стоимость ее разработки, прикиньте время окупаемости процесса.
Не совсем так.
Каждаой системе - своя ниша. У ПР200 и аналоговые входы эээээ оставляют желать лучшего. И много чего еще. И это нормально.
Повторяю - все Ваши хотелки есть в ПЛК63/КДС. Покупайте и пользуйтесь.
А среды... Оцените стоимость ее разработки, прикиньте время окупаемости процесса.
Вам выше человек ответил про советы "покупайте ПЛК". А про "стоимость разработки" я уже слышал тут =100500 миллионов. Но вот человек взял и сделал например FLProg на энтузиазме, явно не столько потратил? Я понимаю - при ОВЕН образовалась некая группа разработчиков, которые нагрели себе место, стригут бабки и не хотят шевелиться - "народ же и так покупает". У них сложились неадекватные ценовые запросы и они стращают руководство ОВЕН большими издержками и огромной сложностью. И тут разработчики железа подложили им "свинью" в виде ПР200, в котором количество явно перешло в качество. Уютный мирок начал трещать по швам - усилим накал разоблачения "хотелок пользователей"?
Я занимался электроникой и микропроцессорной техникой без малого 20 лет. Делал именно устройства с уровнем сложности ПР200. Сам проектировал, сам паял, программировал и отлаживал. И с учетом своего опыта я вам откровенно могу сказать: если разработчик не понимает уровня и возможностей ПР200 и того чем это устройство отличается от предыдущих ПР, то этот разработчик просто глуп. Это диагноз. Чем это вызвано - биологией, ленью или профессиональной деформацией - мне уже не интересно. но как специалист я могу предложить лечение - ГНАТЬ В ШЕЮ всю эту компанию, завязанную на ОЛ и системный софт ПР. Потому что будущее уже сейчас проезжает мимо ОВЕН и "огромные" затраты на модернизацию софта, которымы пугают адепты ОЛ, обернутся значительными реальными потерями. Хотя кто-то конечно будет покупать и то что есть еще долго, ведь до сих пор наверное есть те, кто на кульмане чертит. Я считаю своим долгом, как специалиста, предложить наилучший вариант решения проблемы, а решать ОВЕН конечно - хотят они создать уютный заповедник для своих программистов и обеспечить им ненапряжную жизнь - их дело, их деньги.
Только вот без инструментальной среды ПР/ПЛК - ничто. Единицы будут программировать их на стандартных программистских языках.
Правильно. Вот поэтому я считаю, что для этого железа необходим инструментарий работы с арифметикой БОЛЕЕ ВЫСОКОГО УРОВНЯ, чем "fadd" и "беззнаковые целые". Не "низкого" с ковырянием на С в регистрах процессора, а ВЫСОКОГО, с нормальным, человеческим представлением формул, и обработкой исключений.
Я занимался электроникой и микропроцессорной техникой без малого 20 лет. Делал именно устройства с уровнем сложности ПР200.
Я тоже этим когда то занимался. Только вот есть большая разница между единичным экземпляром для себя и массовой серией. То же и с ПО.
Ну и прочитайте эту тему с самого начала.
У меня только одна претензия к ПР - нет отрицательных целых. Это решаемо без перехода на real, но неудобно.
А что у ПР200 целочисленные вычисления беззнаковые только? Это же капец граждане? Ладно я как-то пока не столкнулся с проблемами, но я даже подумать не мог, что так может быть. Если это так, то ВСЮ команду разработчиков софта и ПР и ОЛ надо построить и гнать пинками, быстро. Они что действительно существуют в природе - эти люди? Бог ты мой...
Пинка дать можно, а вот построить не получится.;) А.Николаев недавно написал, что ОЛ в настоящее время занимается 1 (один) человек. Тут уж, как говорится не до жира.
Я тоже этим когда то занимался. Только вот есть большая разница между единичным экземпляром для себя и массовой серией. То же и с ПО.
И тоже правильно!
Но! Разве не в том СМЫСЛ массового выпуска ПЛК/ПР, чтобы сделать доступнее для "всех" технологии, доступные для "единиц", и максимально снизить "стоимость разработки" КОНЕЧНОГО УСТРОЙСТВА для любого применения.
Противоречия в этом желанию "много зарабатывать" я не вижу.
Есть противоречие только с "много зарабатывать, ничего не делая" - маркетингу в чистом виде, не заботящемуся о реальной цели. Таким маркетологам важно иметь возможность показывать заказчику "простыни с футбольное поле", чтобы обосновывать свои аппетиты, вместо того, чтобы иметь больше заказчиков.
Сравнивая ОЛ, Zelio Soft и Logo (ну и по мелочи ПО для ПР от ABB) могу сказать что ОЛ на голову выше по математике даже в FBD варианте.
Программе не хватает просто качества, чтобы не было глюков, тормозов и т.д.
з.ы. Ну и таки да, блок математики в текстовом представлении очень бы не помешал, просто чтобы не городить целую кучу FBD на поле программы, так как даже завернутое в макрос не очень удобно для целей расчетов в FBD языке.
з.ы. Ну и таки да, блок математики в текстовом представлении очень бы не помешал, просто чтобы не городить целую кучу FBD на поле программы, так как даже завернутое в макрос не очень удобно для целей расчетов в FBD языке.
Только об этом и идёт речь.
Целую - это сколько?
И определите прямо тут, в чем отличие ПЛК от ПР?
Целую - это сколько?
И определите прямо тут, в чем отличие ПЛК от ПР?
Вы как Конфуций прямо, со своей страстью к определениям. ПР - это "недоделанный" и поэтому более дешевый ПЛК. Нет никаких отдельных ПР - это подвид ПЛК. Раньше это разделение имело смысл, т.к. ресурсы ядер у них сильно отличались. А сейчас, с появлением дешевых и производительных микроконтроллеров, это различие размывается. И остаются дорогие и дешевые ПЛК. В подвид ПР устройства попадали с ограничениями по железу, а сейчас (ПР200) попадают с ограничениями по софту, а это уродство уже.
Владимир Ситников
26.07.2017, 10:45
Моя задача - озвучить то, чего мне не хватает. Без истерик "дайте завтра, а то я от вас уйду и не приду". А ПРОИЗВОДИТЕЛЬ пусть сам занимается "маркетингом" - это его изделие, его бизнес.
Если без истерик, тогда с чем?
Ну, реально, над чем таким должен задуматься ОВЕН, если один-два пользователя в год просят формулы.
Удивляет другое. Такие же пользователи как я, начинают меня учить маркетингу овеновских продуктов, выпучив глаза рассказывают "сколько процессорного времени отнимет sin(x) от "системы реального времени"
Если читать внимательно, то capzap писал не про то, что sin(x) сожрёт весь процессор, а про то, что "sin(x) в виде FBD" занимает всегда одинаковое время, т.к. каждый блок всегда выполняется, а "sin(x) в виде мат формул с if'ами" будет выполняться за разное время в зависимости от того, чему равно x.
Т.е. проблема не в самой длительности, а в предсказуемости.
При этом, справедливо замечено, что, если разрешить циклы и/или рекурсию, то вообще невозможно предсказать закончится ли работа этого блока.
И мне не надо рассказывать как нужно делать на ПЛК за 20т.р. то, чему и ПР за 5т.р. МНОГО. Тренируйтесь на своих заказчиках ;).
Если научить ПР формулам, то зачем тогда нужен будет ПЛК? Его продажи упадут и превед-медвед.
Николаев Андрей
26.07.2017, 10:51
Какая живая тема, и провокаторы подтянулись :)
Как бы всё уже обсудили. Все выяснили и определили.
Тему не закрываю, так как понял, что есть интерес к занятиям, рекламируемым Портосом: "Я дерусь, просто по тому, что я дерусь"
Мы слышим и учитываем все мнения. Что-то планируем внедрить, а что-то нет. Что то уже ставим в планы, а что-то оставляем на перспективу.
При этом у нас, у маркето(как там было написано) есть четкое понимание, чем ПЛК будет отличаться от ПР. :)
Если есть замечательные специалисты, которые готовы взяться, и хоп, развить среду - милости просим к нам на собеседование :)
Мы слышим и учитываем все мнения. Что-то планируем внедрить, а что-то нет. Что то уже ставим в планы, а что-то оставляем на перспективу.
При этом у нас, у маркето(как там было написано) есть четкое понимание, чем ПЛК будет отличаться от ПР. :)
Если есть замечательные специалисты, которые готовы взяться, и хоп, развить среду - милости просим к нам на собеседование :)
Адекватно. Спасибо.
Видно, что есть понимание необходимости развивать среду.
А оценивать приоритеты и возможности - это Ваше "внутреннее дело".
И не обижайтесь за "маркетолухов". Это о другом "классе" специалистов.
Если читать внимательно, то capzap писал не про то, что sin(x) сожрёт весь процессор, а про то, что "sin(x) в виде FBD" занимает всегда одинаковое время, т.к. каждый блок всегда выполняется, а "sin(x) в виде мат формул с if'ами" будет выполняться за разное время в зависимости от того, чему равно x.
Т.е. проблема не в самой длительности, а в предсказуемости.
При этом, справедливозамечено, что, если разрешить циклы и/или рекурсию, то вообще невозможно предсказать закончится ли работа этого блока.
Если почитать внимательно, то нигде я не просил "циклов и рекурсий". Предсказуемость sin(x) зависит только от низкоуровневой реализации этой функции специалистом овена. Пользователю отдаётся готовая функция на высоком уровне. Как при этом реализуется обсчёт пользовательских ветвлений - нужно ли их все просчитывать в каждом цикле ради предсказуемости длительности, или каждый раз идёт только по актуальному пути для оптимизации времени - тоже закладывается "свыше" на "низком уровне", недоступном пользователю.
Проблема абсолютно надуманная. С предсказуемостью времени, а тем более со скоростью работы, при реализации нормальной математики, всё ничуть не хуже (как минимум) сегодняшней реализации.
Если научить ПР формулам, то зачем тогда нужен будет ПЛК? Его продажи упадут и превед-медвед.
Если новое ПР займёт нишу старого ПЛК, то и ресурсы на поддержку и развитие старого ПЛК, можно перекинуть на новое ПР. А низкая стоимость нового ПР сделает всю линейку конкурентнее. Туда, где ни за что не поставят ПЛК за 20т.р., поставят ПР за 5т.р. В итоге, вместо 5 ПЛК, продастся 100 ПР. (Просто пример как это МОЖЕТ работать) "медвед" с голоду не помрёт.
Николаев Андрей
26.07.2017, 11:49
Тема, конечно, ушла в сторону.
Дабы окончательно вернуть ее в лоно - немного спойлеров:
1. Есть мысли и по обновлению базовой линейки ПР100. Все просто и бюджетно.
2. Продолжать развивать существующую платформу ПР200 (там много мыслей).
3. Прорабатываем идею следующей платформы "ПР300". В ней уже будут использоваться, в том числе, новые ресурсы. Платформу ПР200 "прямо сейчас", на лету, менять не планировали пока.
OL. Развитие есть такиическое - 3 релиза уже запланировано. Стратегическое - есть мысли и по Си, и по изменению полей и по добавлению новых функций. Именно по отношению к нему мы оцениваем все предложения. И, если видим интересные - немного изменяем стратегию.
Как тут было верно замечено - мы как производитель серийных изделий, со сроком службы более 5 лет не можем позволить себе резких рывков, и в первую очередь - оказывать поддержку уже существующим клиентам.
Ну и параллельно добавляем новые интересные фичи, как например ведение архива, работа по Ethernet, интеграция в OwenCloud, работа с ЖК дисплеями и т.д.
И мы очень рады любым конструктивным предложениям. И честно говорим - что не можем реализовать их все. Будем сверять со стратегией.
Зачем зачинать ПР300, лучше сначала доведите до ума ПР200.
Николаев Андрей
26.07.2017, 12:16
Зачем зачинать ПР300, лучше сначала доведите до ума ПР200.
Именно в такой последовательности и идем, видимо не совсем однозначно выразился.
Существующую платформу ПР200 доводим до ума и добавляем функции, не переводя на новые истории.
Новая платформа пока на уровне идей :)
Именно в такой последовательности и идем, видимо не совсем однозначно выразился.
Существующую платформу ПР200 доводим до ума и добавляем функции, не переводя на новые истории.
Новая платформа пока на уровне идей :)
Не единственно возможная стратегия.
"Крупные игроки" обычно играют иначе. Просто пример, не пытаясь "учить жить".
Берётся топовый микропроцессор активно развивающейся линейки, и на нём создаётся максимальная платформа топового продукта (супер-пупер ПЛК), собрав все сегодняшние и завтрашне-послезавтрашние идеи от "малинщиков-ардуинщиков" в том числе.
По мере разработки, выясняются подводные камни и возможности/методы "обрезания" для удешевления ограниченных изделий. На рынке появляются изделия с самыми завершёнными фичами, начиная с того, что уже готово. А дальше - единая стратегически основа доводится и "вверх", и "вниз".
Максимально унифицированный софт под железки и под разный уровень конечных пользователей.
Это не просто и есть много рисков. Но и отдача в случае успеха гораздо больше, чем линейное развитие через добавление всё новых и новых костылей чтобы приподняться на пару милиметров над имеющимся, и трудный выбор "всё сломать и сделать заново" или ещё пару костылей прикрутить - авось не рухнет.
Ещё раз.
Не хочу "учить бобра тонуть".
Просто, сейчас лично я бы собирал идеи для ПР500, на уровне ПЛК 110 м2 и выше, с ВЫСОКОУРОВНЕВОЙ средой разработки "для дошкольников". А ПР300 уже родился бы сам или как этап построения ПР500, или как результат его обрезания.
Извините за многослов.
з.ы. замечу что в некоторых других ПР есть математические функции ОДНИМ блоком FBD, блок имеет 4 входа например, выбор математической функции для входа и соответственно выход. Это упрощает немного жизнь...
А чтобы ОЛ не повторялся и шла речь о том, чтобы формулу можно было написать текстом. Например это можно сделать на основе макроса, так как у него реализовано удаление/прибавления входов и выходов. Просто нужен некий модуль в ПО, который будет проверять формулу на ошибки и реализация активирования макроса именно как текстового блока формул.
У меня иногда складывается впечатление, что разработчики ОЛ ни разу не смотрели на ПО Сименс, ни Шнайдер, поэтому и удивляются просьбам людей.
Но сделать надо не как у других, а лучше и гибче ессно.
У меня иногда складывается впечатление, что разработчики ОЛ ни разу не смотрели на ПО Сименс, ни Шнайдер, поэтому и удивляются просьбам людей.
а кто удивляется, разве wal79, когда высказывал не приятие озвученных здесь идей. Самый быстрый способ внедрить скриптовый язык это добавить имеющиеся, например vba, он используется и в скадах и панелях у других, но в них присутсвуют и рекурсия и циклы. Есть путь по какому идет Ситников, использовать JetBrains MPS и третий вариант, изобретать что то самому, вплоть до выхода на пенсию
Не обязательно что-то использовать, типа vba и прочего. Можно просто добавить данный функционал в редакторе макросов, и в справке указать какие арифметические функции доступны, пусть это будут даже банальные + - * /. А так же чтобы в редакторе макросов была эта самая проверка на корректность записи формулы.
Речь не идет о проверке правильности логического расчета формулы, просто банальная поверка на отсутствие скобок или если они лишние.
Типа (а+b*c=q или (a+b)*c)=q1 - это будут ошибки. a, b соответственно входы, q1 выходы.
имхо, получился бы классный макрос, который можно создавать кому какой удобно без рисования квадратиков.
Не обязательно что-то использовать, типа vba и прочего. Можно просто добавить данный функционал в редакторе макросов, и в справке указать какие арифметические функции доступны, пусть это будут даже банальные + - * /. А так же чтобы в редакторе макросов была эта самая проверка на корректность записи формулы.
Речь не идет о проверке правильности логического расчета формулы, просто банальная поверка на отсутствие скобок или если они лишние.
Типа (а+b*c=q или (a+b)*c)=q1 - это будут ошибки. a, b соответственно входы, q1 выходы.
имхо, получился бы классный макрос, который можно создавать кому какой удобно без рисования квадратиков.
так какие проблемы, помогите разработчику, составте программку, на вход которой будете подавать текстовую формулу, а на выходе она будет выдавать список ошибок, все с удовольствием потестят и когда дело дойдет до внесения функционала в ОЛ, предложите свои наработки уже отлаженные, будете героем дня
Владимир Ситников
26.07.2017, 14:07
так какие проблемы, помогите разработчику
Вы тут сделали 15 опечаток в слове "устройтесь в ОВЕН" )
capzap вы предлагаете еще более усовершенствовать C# ?, в нем все это и так есть и нет необходимости что-то придумывать. А исходники ОЛ мне никто не даст.
Вы тут сделали 15 опечаток в слове "устройтесь в ОВЕН" )
т.е. Вы поддерживаете, что была эта самая проверка на корректность записи формулы это не просто пофиксить баг, а вполне серьезная работа которая за день не делается
capzap вы предлагаете еще более усовершенствовать C# ?, в нем все это и так есть и нет необходимости что-то придумывать. А исходники ОЛ мне никто не даст.
на чем умеете писать на том и напишите, хоть в кдс, хоть на питоне, хоть на любом из Си. Неужели такое же мнение как тут у некоторых, что разработчик не в состоянии понять концепцию из другого языка
Владимир Ситников
26.07.2017, 15:02
т.е. Вы поддерживаете, что была эта самая проверка на корректность записи формулы это не просто пофиксить ба
Разумеется, делать язык с нуля это непростая задача. Разумеется, простых + - будет недостаточно. Даже потом вкрячить "приведние 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 (документация)
capzap ОЛ вроде как написан на C#, а там как и во многих языках все математические функции уже присутствуют.
А исходники самого ОЛ мне никто не даст, так что осталось дело за самими разработчиками, имея на руках то, что есть, сделать плагин формул для макросов при их создании.
По мне, пусть хотя бы начнут с + - * и / с учетом типа int и float применительно к ОЛ. Если что-то начнет получаться, дать исходники плагина людям, авось и косинусы с тангенсами прикрутят.
capzap ОЛ вроде как написан на C#, а там как и во многих языках все математические функции уже присутствуют.
А исходники самого ОЛ мне никто не даст, так что осталось дело за самими разработчиками, имея на руках то, что есть, сделать плагин формул для макросов при их создании.
По мне, пусть хотя бы начнут с + - * и / с учетом типа int и float применительно к ОЛ. Если что-то начнет получаться, дать исходники плагина людям, авось и косинусы с тангенсами прикрутят.
Тут всё не так просто.
Функции языка, на котором написан ОЛ тут непричём.
C# получит формулу в виде строки символов. А считаться эта формула должна функциями, заложенными в контроллер.
Т.е., строку нужно будет "распарсить" (прочитать и перевести в последовательность команд, понятную уже софту контроллера).
Задача не то чтобы суперсложная, но и не простая.
А поддержку функций необходимо будет добавлять в прошивку ПР.
То, что умеет c# - он умеет только на компьютере, но не на контроллере.
pop70 наверное я вас удивлю, но программу вы РИСУЕТЕ на обычном ПК, а уж распарсить строку ему под силу и перевести макрос в понятный вид согласно последовательности математических действий, выделенных скобками и записать это в прибор думаю тоже под силу.
А еще учитывая, что прошивку нельзя скачать из ПР нет необходимости заниматься извращением опять из "квадратиков" создавать текстовое представление.
Было бы желание как говорится. Банально символы можно проверять на этапе ввода для простых мат функций. чекбокс предусмотреть на будущее (с проверкой/без проверки) ввода. Останется только скобки проверить, что все пары на месте. Писал уже выше, саму логику проверять не надо, это останется на совести писателя.
А при добавлении функций в дальнейшем, проверить текст cos, tan, pi и так далее тоже не составит труда
Владимир Ситников
27.07.2017, 00:36
pop70 наверное я вас удивлю, но программу вы РИСУЕТЕ на обычном ПК, а уж распарсить строку ему под силу и перевести макрос в понятный вид согласно последовательности математических действий, выделенных скобками и записать это в прибор думаю тоже под силу.
А теперь сравните это с тем, что вы говорили выше:
ОЛ вроде как написан на C#, а там как и во многих языках все математические функции уже присутствуют.
Да, "распарсить, перевести, согласно, скобками" под силу. Но одно дело "всё уже присутствует", а совсем другое, когда нужно мало того, что распарсить, так нужно ещё и ошибки показать, и в ПР-понятный вид привести, и симуляцию поддержать и так далее. Как верно заметил capzap, подобным "распарсиванием" можно заниматься "вплоть до выхода на пенсию"
Вот вам свежий пример. Есть язык программирования Ceylon (https://ru.wikipedia.org/wiki/Ceylon). Язык появился в 2011, и его продвигает RedHat. В 2016-ом нашли ошибку, что в этом языке неправильно распознаются float значения (https://github.com/ceylon/ceylon-sdk/issues/631). Значение 1.01 обрабатывается как 1.1.
Ага, это в 21-ом веке. И над языком работал более чем 1 программист. И всё равно такую ошибку пропустили.
Если перенести на ПР реалии, где "распарсиванием" будет заниматься один-единственный программист, то шанс, что он не накосячит с парсингом стремится к нулю. Тут дело не только в самом программисте, как и в том, что проверять "свой" код гораздо сложнее. Что знал, то проверил, а что не знал, то и пробакланилось.
А при добавлении функций в дальнейшем, проверить текст cos, tan, pi и так далее тоже не составит труда
Ну, да, конечно. Пользователи все как один начнут писать "sin(tan)" или "sin*pi" или "sin(true)". Проверка правильности и выдача вразумительного сообщения об ошибке это не такая простая задача как вам кажется.
Некая аналогия -- запрет циклов в ОЛ схемах. В 1.9 запретили, и всё равно возникают вопросы "а чего это у меня ОЛ ругается?".
Т.е. сделать ошибку "у вас программа кривая" мало. Нужно делать вразумительные сообщения.
вообще я пытался добиться от мелкого, чтоб он на мое предложение не высказал позицию: моя хата с краю, пусть овен сделает, а условный Ситников добавит туда функционал, а сам скажет не вопрос, вот сделал, тестируй.
Во вторых, предложил я задачу, чтоб осмыслить масштаб такой самостоятельной работы, потому что у каждой среды разработки есть свой FindBugs и любой текст гипотетически можно обработать не изобретая велосипед
Только вот следующим встанет вопрос, как этому тексту эволюционировать в исполняемый код, на данный момент есть интерпретатор из графического языка в код понимаемый процессором, В.Ситников об этом много написал. И даже если формула будет банальной, простой или еще как то там, всёравно придется писать абстракцию, переводящую текст в некий п-код
pop70 наверное я вас удивлю, но программу вы РИСУЕТЕ на обычном ПК, а уж распарсить строку ему под силу и перевести макрос в понятный вид согласно последовательности математических действий, выделенных скобками и записать это в прибор думаю тоже под силу.
ПК сам ничего не делает. Делает программист. :)
Как верно заметил capzap, подобным "распарсиванием" можно заниматься "вплоть до выхода на пенсию"
Не нагнетайте. :) Эту задачу уже множество раз решали. Есть и в сети примеры. Не боги горшки обжигают. У программиста, написавшего ОЛ, на это мозгов уж точно хватит. Было бы желание.
Владимир Ситников и чего ? в C# тоже до сих пор есть ошибки, никто же не ноет, просто обходит их, нарвавшись.
capzap вы таки думаете, что в ПР зашиваются картинки ? картинка всего лишь графическое отображение кода для пользователя ОЛ, а там банальные функции и их вызов.
Еще раз, нет там графического языка внутри ОЛ, графический язык сделан для пользователей ОЛ, не более. Так называемое UI или GUI как хотите обзовите.
capzap вы таки думаете, что в ПР зашиваются картинки ? картинка всего лишь графическое отображение кода для пользователя ОЛ, а там банальные функции и их вызов.
Еще раз, нет там графического языка внутри ОЛ, графический язык сделан для пользователей ОЛ, не более. Так называемое UI или GUI как хотите обзовите.
Вот как раз я то думаю о противоположном, именно в ОЛ происходит интрпретация в машинные коды для ПР и именно там нужно добавлять интерпретатор для формул, раз они будут не графического типа
Для этого надо понимать полную структуру ОЛ.
Лично для меня будет очень удивительно, если ОЛ код преобразует в графику, потом при записи в ПР графику опять преобразует в код, это тогда не программа, а какой-то горе продукт получается....
Для этого надо понимать полную структуру ОЛ.
Лично для меня будет очень удивительно, если ОЛ код преобразует в графику, потом при записи в ПР графику опять преобразует в код, это тогда не программа, а какой-то горе продукт получается....
Вы не обращали внимание что простые проекты с расширением owl занимают мегабайты, проект хранится , как вы написали в виде картинки, возможно с сеарилазцией, а компиляция в машинный код идет в ОЛ параллельно или вообще только при заливке
Обращал, вот это то и пугает :) идиотский подход....
А кого сейчас волнует объем? Вот в КДС 3 то же самое.
Владимир Ситников
27.07.2017, 11:55
Владимир Ситников и чего ? в C# тоже до сих пор есть ошибки, никто же не ноет, просто обходит их, нарвавшись.
И то, что у вас "всё просто", всего-навсего, нужно сделать парсер, компилятор, симулятор. Всего-навсего нужно обойти ошибки в C#. Всего-навсего нужно добавить операции +-/* и скобки, а потом всего-навсего нужно добавить функции, ведь найти sin вообще не составляет труда. А потом всего-навсего добавить поддержку даты, времени, знаковых чисел, битовых операций, массивов. В чём сложность-то вообще?
Было бы желание как говорится.... А при добавлении функций в дальнейшем, проверить текст cos, tan, pi и так далее тоже не составит труда
Так не работает. По сути, вы игнорируете все аргументы, и остаётесь при своём мнении "и так далее тоже не составит труда".
У меня в таком случае 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 системах есть скриптовые языки, либо можно писать непосредственно на языке программирования то в документации отражено какие методы, классы можно использовать, как создавать свои методы, классы, функции, что можно вызвать из системных функций и т.д. Где посмотреть логи ошибок и так далее, чтобы найти ошибку в коде. И все это документировано и РАБОТАЕТ.
Почему это не может работать в ОЛ или ином другом продукте ?
не понимаю...
Владимир Ситников
27.07.2017, 15:08
з.ы. давайте исходники ОЛ, будем посмотреть что можно сделать. :) все упирается именно в это, нет исходников, нет реализаций пердложений со стороны других участников.
Вот я не понимаю, как вы сначала говорите "не составит труда", а потом "зависит от исходников ОЛ".
Разумеется, зависит. Разумеется, если там говнокод, то уже ничего не добавить. Но давайте будем более оптимистичными, и предположим, что там какой-то средне-статистический код.
Так вот. Сколько денег по-вашему стоит разработка формул? Или вы без понятия, и для ответа нужно посмотреть исходники?
Если вы без понятия, то как же так лихо утверждаете, что "не составляет труда добавить"?
Ни я ни capzap не говорили, что невозможно добавить формулы. Но крайне странно слышать "не составляет труда", и потом тут же "ой, давайте исходники ОЛ, будем посмотреть что можно сделать".
Владимир Ситников извините, чем отличается РИСУНОК в макросе ADD (на вход 1 подаем int 33, на вход 2 подаем int 55) и на выходе получаем 88.
от записи int Выход = 33+55 ?????????
Ну вот объясните русским понятным языком чем отличается долбанная кртинка в теле макроса ОЛ от такой же картинки, но записанной текстом ?
Объясняю: запись 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 сложение целых сопряжено с "неопределённым поведением" (https://stackoverflow.com/a/37488541/1261287) при переполнении. Да, в стандарте прямо так и сказано, что в случае переполнения компилятор может сделать вообще всё, что ему вздумается (undefined behavior). Например, вообще остановить работу программы.
Подходит такое поведение для ОЛ-ПР? Едва ли.
А вы спрашиваете чего такого сложного из "33+55" сделать блок ADD.
1. симулятор в ОЛ уже есть
2. компилятор так же есть
1. Да, симулятор текущих ADD/fADD блоков уже есть, но наверняка для того, чтобы "блок-формула" хоть как-то показывался в симуляции (не падал, показывал значения входов-выходов) нужны какие-нибудь доработки. Даже, если блок-формулу "за кадром" превращать в макрос из ADD/fADD, то всё равно в симуляторе нужно будет немного допилить, чтобы у него не сносило крышу от нового блока.
2. Ну и в компиляторе наверняка нужно будет тоже доработку, чтобы у него не сносило крышу от блока-формулы. Как-никак, сейчас компилятор только известные ему квадратики разбирать умеет, а нужно, чтобы он не падал от блока-формулы.
3. Ну и нужно делать часть сохранения-загрузки
4. Не устану повторять об "ошибках". Например, если в формуле возникнет "цикл", то ОЛ должно выдать предупреждение о необходимости "линии задержки".
А писать самостоятельные варианты не имеет смысла, так как нет привязки непосредственно к продукту.
Так я не прошу писать. Я прошу просто оценить длительность написания. Грубо говоря, "я бы такое сделал за X дней и Y денег".
Владимир Ситников "не составит труда" для разработчика, потому что у него все тузы в рукаве (код).
Ессно прикрутить со стороны да еще чтобы работало в некоем ПО без исходников не представляется возможным.
а int ВЫХОД - ЯСЕН ПЕНЬ РАБОТАЕТ С ЦЕЛОЧИСЛЕННЫМИ. Кроме которых в ОЛ есть еще только bool переменные и float переменные - ЧТО ТУТ НЕПОНЯТНОГО ?
Вы создаете макрос в ОЛ и указываете макросу ТИП входа - тут тоже непонятно с чем работать ?
Так вот в чем неоднозначность между ADD со входами int и + со входами int ?????
Куда вы все время съезжаете то ?
Знаковые, беззнаковые. Нарисуйте SUB 33 и 55 и посмотрите что в ОЛ будет на выходе, его интерпритатор работает так. Почему он должен работать иначе, если будет запись 33-55 ? да пусть так же и работает, вот вам и совместимость....
Что меня и удивляет, что компилятор разбирает рисунки, а не кодовое представление этих квадратиков с учетом связей.
Если это так, то мне очень жаль компанию Овен...
Владимир Ситников
27.07.2017, 15:21
а int ВЫХОД - ЯСЕН ПЕНЬ РАБОТАЕТ С ЦЕЛОЧИСЛЕННЫМИ
Потише, потише.
Блок-формулу же предлагается не для одной операции делать?
Вот, допустим, запись "int выход = (33-55+80.0)/100". Вполне резонный вопрос: минус это SUB или fSUB? Аналогично, деление это DIV или fDIV?
Вы предлагаете по типу выхода анализировать смысл всех операций в формуле?
Вы создаете макрос в ОЛ и указываете макросу ТИП входа - тут тоже непонятно с чем работать ?
Обратите внимание на то, что сейчас смысл операции в ОЛ задаётся самим блоком, а не типом его входов-выходов.
Грубо говоря, если есть операция fADD, то она по-любому будет выполнять float сложение, вне зависимости от того, куда её подключать.
Вы же внезапно предлагаете, чтобы тип выхода как-то влиял на происходящее внутри макроса. Да, так бывает, но сейчас в ОЛ такое не встречается.
Владимир Ситников
27.07.2017, 15:32
"не составит труда" для разработчика, потому что у него все тузы в рукаве (код).
Вот здесь, похоже, можно прекращать дискуссию. Вы считаете, что "разработчик с кодом" это ниндзя, который может всё, и решение любой задачи у него займёт не больше дня.
К сожалению, мир устроен не так, и одного только наличия кода и кучи библиотек не достаточно, чтобы каждую хотелку реализовывать на раз.
Ессно прикрутить со стороны да еще чтобы работало в некоем ПО без исходников не представляется возможным.
А мне почему-то естественно, что для оценки +-километр эти самые исходники не нужны. Да, с ними проще, но и без них можно прикинуть (см. мою оценку по p-code блоку).
Вот, допустим, запись "int выход = (33-55+80.0)/100". Вполне резонный вопрос: минус это SUB или fSUB? Аналогично, деление это DIV или fDIV?
Вы предлагаете по типу выхода анализировать смысл всех операций в формуле?
Делать так, как в codesys? Такое не прокатит, codesys по идее должен вынудить сказать явно о IntToFloat (x to F в ОЛ), так и в ОЛ сделать. А как будет понимать парсер, дело разработчика.
Надо сказать как должно быть, а как оно там будет устроено, дело не наше, не ваше и повлиять на код можно только отправив резюме.
Вот что значит изначально не правильно выбранная концепция при разработке ОЛ.
Владимир Ситников
27.07.2017, 15:50
Делать так, как в codesys? Такое не прокатит, codesys по идее должен вынудить сказать явно о IntToFloat (x to F в ОЛ), так и в ОЛ сделать.
По-научному нужно говорить не "как в КДС", а "по стандарту МЭК 61131". Я не говорил, что в КДС хорошо сделано.
Более того, на стыке знаковых-беззнаковых в КДС тоже вакханалия.
А как будет понимать парсер, дело разработчика.
Надо сказать как должно быть, а как оно там будет устроено, дело не наше
Я лишь детально показал, что с "формулами" не всё гладко и не всё просто. Тов. melky постоянно говорит, что "всё просто". А, на самом деле, вовсе не так. И для этого исходники ОЛ читать не нужно -- и так ясно.
не ваше и повлиять на код можно только отправив резюме.
Ещё вариант -- это объяснять другим, что "блок-формулу" сделать непросто, и таким образом, её вообще не сделают. Так сказать, влияем без отправки резюме.
Владимир Ситников кто мешает для совместимости указывать тип макроса с формулой что он int или он float ?
Я не говорю сразу написать скриптовый язык чтобы умел все и вся, хотя бы пусть сделают плагин для целочисленных, укажут какие доступны средства для расширения плагина и возможности и уже исходники плагина дадут в массы для написания новых функций.
Включение плагина в ОЛ на совести разработчика после проверки результатов сообщества.
без исходников ничего нельзя определить... вот я писал формулу в scada, не нет у нее using System.IO и хоть что делай а все из этого недоступно.
Хорошо автор предусмотрел прямой вызов функций, но был бы using строка была бы короче.
Так и тут, если неизвестно чем можно оперировать, можно хоть сотню раз на месте попрыгать, а ничего не изменится.
я не говорил о дне, не передергивайте.
откровенно лень рисовать в картинках.
1. есть входы макроса, указали тип, обозначили переменную (собственно они и так обозначены I1, I2, I3), в том числе обозначены и выходы и их тип.
2. Q1=(I1+I2)*I3
3. сделать в макросе подстановку I1, I2, I3, Q1 без возможности редактирования в строке думаю не составит очень уж большого труда
4. функционал в языке для невозможности ввода каких либо символов, кроме ( ) + - и цифр есть, хоть по всей клаве бей, а больше этого не введешь
5. проверить наличие парных скобок тоже не трудно, как писал выше сама формула, ее результат на совести пользователя ОЛ, да и проверяется банально в Exel
6. последовательность выполнения согласно математики, собственно это язык проверит.
Сделайте в таком виде вариант, дайте исходники этого варианта в массы и посмотрим что из этого выйдет дальше
Потише, потише.
Блок-формулу же предлагается не для одной операции делать?
Вот, допустим, запись "int выход = (33-55+80.0)/100". Вполне резонный вопрос: минус это SUB или fSUB? Аналогично, деление это DIV или fDIV?
Не придумывайте проблем на ровном месте.
Операция определяется операндами. Деление по умолчанию имеет формат float.
В данном случае, очевидный единственно правильный вариант - это SUB, FADD и FDIV.
Преобразования типов легко ставятся автоматом.
Т.е. делается TOINT(FDIV(FADD(ToFloat(SUB(33,55),80.0)))
Владимир Ситников
27.07.2017, 16:05
Не придумывайте проблем на ровном месте.
Если место ровное, то
2) Сколько денег по-вашему стоит пункт #1? Грубо говоря, если делать будете не вы, то сколько вы готовы заплатить программисту и за какой срок вы ожидаете от него реализацию?
По-научному нужно говорить не "как в КДС", а "по стандарту МЭК 61131". Я не говорил, что в КДС хорошо сделано.
Более того, на стыке знаковых-беззнаковых в КДС тоже вакханалия.
Один вы тут "ученый" видимо, а все остальные не правы, это мы давно поняли.
Всё написанное не имеет смысла пока не появится тут программист ОЛ, он или читает и хихикает или не читал ни одного поста, а может под другим ником сидит, по крайней мере какой смысл придумывать и спорить если обратки как таковой нет?
Владимир Ситников
27.07.2017, 16:52
мы давно поняли.
Если поняли, то
2) Сколько денег по-вашему стоит пункт #1? Грубо говоря, если делать будете не вы, то сколько вы готовы заплатить программисту и за какой срок вы ожидаете от него реализацию?
Если место ровное, то
Здесь у кого-то в подписи есть хороший ответ на Ваши "проблемы".
Если поняли, то
Хмм.. странный вопрос, по крайней мере для меня. Вы соц. опрос делаете?
Допустим я вам дам 100к и вы сделаете, овен продаст, все будут пользоваться, мне это зачем?
Это наверное вопрос к ОВЕН, как предложение.
А вы уже готовы приступить к реализации есть всё для этого?
Владимир Ситников
27.07.2017, 18:02
Хмм.. странный вопрос, по крайней мере для меня. Вы соц. опрос делаете?
Вопрос насколько же странный, насколько было ваше "Всё написанное не имеет смысла".
Написанное имеет очень простой смысл: я пытался объяснить melky то, что парсинг формул это непростая задача. Вы же в ответ пишете, что я "учёный" и всё не имет смысла. Где логика-то?
Я лишь детально показал, что с "формулами" не всё гладко и не всё просто. Тов. melky постоянно говорит, что "всё просто". А, на самом деле, вовсе не так.
Допустим я вам дам 100к
Ок, уже что-то.
и вы сделаете, овен продаст, все будут пользоваться, мне это зачем?
Это, конечно, мешает оценивать. Ну, кто знает. Вдруг будете делать какой-нибудь "самописный ПИД".
Печально то, что некоторые пишут "сделать легко", а на вопрос "а за сколько рублей вы такое сделали бы" молчат.
Это наверное вопрос к ОВЕН, как предложение.
Ну, одно дело, когда народ описывает абстрактные хотелки, а другое, когда они хоть как-то понимают или пытаются понять сложность этих хотелок.
А вы уже готовы приступить к реализации есть всё для этого?
Очень правильный вопрос. Но я не знаю, что тут можно ответить. Если накопить финансирование, то можно будет сказать, что "есть всё".
Если же средств не будет, то и соблазнить ОВЕН едва ли получится.
Моя мысль была в том, что вариант с p-code проще в реализации по сравнению с "блоком-формулой", и этот самый p-code откроет больше новых возможностей.
Например, p-code откроет возможность "автоматического тестирования" программ. Например, Алексей Геннадьевич много раз говорил, как он "любит" "выводить ОЛ-схему на режим", чтобы проверить как она работает.
ОВЕН, судя по всему, идут по пути "макросов на языке C". С одной стороны интересно что (не)получится, а с другой несколько печально.
exzerodivide
28.07.2017, 02:25
Пока реализовывал свой первый контроллер управления ТА и БКН от ТТ котла на ПР200, с большим удовольствием читал эту ветку и осознавал что не зря взял ПР.
По сути, то, чем идет дискуссия уже реализовали чехи из rexcontols. FBD+блоки, внутри которых код на С/Java подобном языке. Правда платформа - малина. Вот описание FBD https://www.rexcontrols.com/media/doc/ENGLISH/MANUALS/BRef/BRef_ENG.html
Вот собственно описание блока https://www.rexcontrols.com/media/doc/ENGLISH/MANUALS/BRef/REXLANG.html#x262-26100015
С учетом того, что они используют статическую типизацию, проблем с выводом типа результата не возникает.
Печально то, что некоторые пишут "сделать легко", а на вопрос "а за сколько рублей вы такое сделали бы" молчат.
Ну, одно дело, когда народ описывает абстрактные хотелки, а другое, когда они хоть как-то понимают или пытаются понять сложность этих хотелок.
Очень правильный вопрос. Но я не знаю, что тут можно ответить. Если накопить финансирование, то можно будет сказать, что "есть всё".
Если же средств не будет, то и соблазнить ОВЕН едва ли получится.
Моя мысль была в том, что вариант с p-code проще в реализации по сравнению с "блоком-формулой", и этот самый p-code откроет больше новых возможностей.
Например, p-code откроет возможность "автоматического тестирования" программ. Например, Алексей Геннадьевич много раз говорил, как он "любит" "выводить ОЛ-схему на режим", чтобы проверить как она работает.
ОВЕН, судя по всему, идут по пути "макросов на языке C". С одной стороны интересно что (не)получится, а с другой несколько печально.
А потомучто ответить на вопрос "за сколько" может только ОВЕН.
Вот поэтому, "всё написанное бессмысленно". И те, кто пишет "легко", и те, кто пишет "очень трудно", основывают свои "оценки" на своих же фантазиях. Больше не на чем, т.к., ни то что "исходников", но и внутренней идеологии ОЛ никто не знает.
Есть там в явном виде p-код, льющийся в ПР или как "промежуточный этап" в ОЛ, или нет его вообще, а есть "набор функций" в прошивке, и ОЛ собирает сразу исполняемый код.
"Макросы на С" отдавать пользователю - это вообще бессмысленно. Во-первых, это "более высокий уровень пользователя", во-вторых, в таких макросах пользователю можно давать доступ только к конкретным, стандартным "пользовательским функциям". Т.е., "более низкого уровня программирования" не получится - доступ к железу каждого "говнокодера"- это смерть "промышленной" идеологии. И при даче в руки пользователю С, хрен отсечёшь его от того, что "давать нельзя". Это если полноценный С, непосредственно компилируемый в исполняемый код, а в противном случае - это не С, а С-подобный костыль - тот же скрипт на языке "низкого уровня" для "высокоуровневого пользователя" - вобщем, бессмыслица.
На "низком уровне" берёшь ПР, смотришь потроха, и льёшь свой код для СТМ-ки. К идеологии "промышленного ПР" это никакого отношения не имеет.
Просто адаптированная к промприменению железка в качестве "конструктора на СТМ". Оно кому-то надо? Да никому.
Владимир Ситников
28.07.2017, 08:54
но и внутренней идеологии ОЛ никто не знает.
^^^ это ваши фантазии.
А вот производитель подтверждает мои "фантазии"
Ситников видимо прав, когда говорит что ОЛ работает с p-code/IL...
Молодца. Всё именно так.
А потомучто ответить на вопрос "за сколько" может только ОВЕН.
Грубой оценки достаточно. Не корову продаём.
Когда народ просит доработок в ОЛ, они всё равно интуитивно прикидывают "насколько сложно" для ОВЕН это будет.
Например, сложность "добавления ST редактора в ОЛ" слабо зависит от текущих исходников ОЛ. И так и сяк уйма времени.
Так и тут. Блок-формула сопряжена с дополнительными расходами ресурсов (по сравнению с p-блоком) вне зависимости от текущей архитектуры ПР-ОЛ.
"Макросы на С" отдавать пользователю - это вообще бессмысленно.
Тем и интереснее смотреть за тем, что за "С-подобный костыль" получится.
Владимир Ситников еще раз, формулы НЕ НАДО парсить, надо всего лишь определить, что нет ошибок в ее записи.
Если поставили переменные int, не должно быть точек (тупо не давать вводить точку или запятую при вводе), что человек установил парные скобки
Хотя опять же, все зависит как сейчас сделаны FBD блоки в ОЛ и как они интерпретируются им в код ПР.
Любой язык высокого уровня запись формулы выполняет на раз два без вашего участия, кроме как ее записать, тем более если она будет ограничена типами переменных.
з.ы. еще раз скажу, не надо делать парсинг "А вы уверены, что эта скобочка здесь? а знак умножить тут ?"
Владимир Ситников
28.07.2017, 16:06
формулы НЕ НАДО парсить, надо всего лишь определить, что нет ошибок в ее записи.
И как вы без парсинга (https://ru.wikipedia.org/wiki/%D0%A1%D0%B8%D0%BD%D1%82%D0%B0%D0%BA%D1%81%D0%B8%D 1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%B0%D0%BD%D0 %B0%D0%BB%D0%B8%D0%B7) собрались определять отсутствие ошибок?
Владимир Ситников еще раз, формулы НЕ НАДО парсить, надо всего лишь определить, что нет ошибок в ее записи.
Да ладно? Сколько будет "два плюс два умножить на два"? Восемь? Или все-таки шесть? По каким правилам Вы это определили?
надо всего лишь определить, что нет ошибок в ее записи.
вот цитата (http://si-sv.com/board/kalashnikov/7-1-0-149), она относится ко всему
Powered by vBulletin® Version 4.2.3 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot