А пост #11 в этой теме внимательно прочли ?
Вид для печати
В Посте 11 ответ на пост 10 ,что вам еще надо ?В догадки играть нет времени .
В посте #10 Н. Андрей пишет, что "Человек завел хорошее дело. В любом случае полезно собрать обратную связь с коллег", "Тем более, что в предложениях он не пытается продвигать свое решение, а помогает собирать наши."
Вы, rovki, пишете такое и не краснеете:
Андрей прекрасно понял зачем я завёл _эту_ тему, и чем _эта_ тема полезна ОВЕНу.
Никто вас не принуждает голосовать в "моём" голосовании, но если вы до сих пор не поняли, что смысл темы в сборе обратной связи _для ОВЕН_, подумайте. Возможно, вам, наконец, придёт в голову такая мысль. Если она-таки придёт, то, возможно, придёт и мысль, что перечислить _текущие актуальные_ проблемы в одном месте важнее, и проще в последующей обработке для ОВЕН, чем ваше предложение "штудировать весь срач на форуме за последние 5 лет".
На вопрос:
Вы, rovki, отвечаете:
Снова невпопад. Перечитайте _эту_ тему (достаточно 1-е и 10-е сообщение), и, возможно, вам, станет ясно, что смысл _этой_ темы не в том, чтобы реализовать все-все-все возможные хотелки.
Я позволю себе переспросить: что именно неудачного я предложил в этой теме?
Для тех, кто в танке: в этой теме я предложил собирать предложения для ПР/ОЛ/МВ/ПЛК. Другие мои темы и сообщения в других темах к данной имеют весьма опосредованное отношение.
Понимаете ли в чем дело...
Вопрос даже не возрасте. Ваша проблема в том, что Вы - "рафинированный программист". И бесконечно далеки от потребностей любого производства.
Во оправдание могу сказать, что в определенной мере я подобное проходил, сразу после ВУЗа. По образованию я системотехник (конструктор ЭВМ), не АСУТПшник. И особенно во времена "слабых" ПК (начало-середина 90-х) бил себя тяпкой в грудь со словами - "нафига СКАДА, это медленно и дорого. Зачем среды а-ля КДС вообще..." Но быстро понял, почему именно так все работают.
И?
Это как-то меняет тот факт, что компании ОВЕН нужна обратная связь?
Это как-то меняет тот факт, что предложения в виде "одного списка, с внятными формулировками" гораздо проще для понимания/анализа инженерами ОВЕН?
Если оба факта остаются на своих местах, то "какой из меня программист" никак не меняет сути текущей темы.
Какой из меня программист можно обсуждать в других (подходящих) темах, но текущая явно не про это.
Я же и предлагаю, чтобы те, кто, якобы, "близки к потребностям" взяли и добавили одно-два рац. предложения.
По сути, я упрощаю "сбор потребностей". Некоторые хотелки я дописываю со слов других. Некоторые мне непонятны (например, я предполагал, что когда просили "ПР в щитовом исполнении" имелось ввиду "с экраном на крышке щита", но я не был уверен), но как раз в таких случаях пусть авторы и добавляют свои предложения в понятной (для тех, кто в теме) форме.
Да не нужны Ваши предложения именно для ПР, которое не ПЛК. И не по причине вычислительной мощности.
ПР заменяет релейную автоматику и минимальным добавлением ПИД-подбных функций а-ля ТРМ1.
P.S. Я тут както предлагал ОВЕНу продавать ПЛК с принципиальной схемой и простейшей мониторной программой. Но что мне Николаев(?) ответил, что ОВЕН не настолько богат, чтобы обеспечить поддержку этого. И на Вашем примере я вижу, что он был прав.
При чём тут мои предложения?
Простой вопрос: компании ОВЕН обратная связь (не только от меня, а от форумчан) нужна или нет?
Т.е. предлагали продавать ПЛК вообще без среды разработки? Можно побольше деталей что значит "простейшей мониторной программой"?
Понятно...
Вы просто не электронщик, не понимаете элементарных вещей.
Грубо - иметь возможноть залить код в ЭСПЗУ и вызвать его на исподнение при пуске. Плюс ряд стандартных библиотек под архитектуру. Собственно, с этого начиналась микропроцессорная техника.
Ну, т.е. это предложение "а давайте сделаем свой runtime для ПЛК" (набор библиотек, прошивку ПЛК)?
Простите, но не думал, что именно это вы имели ввиду под "простейшей мониторной программой". В моём мозгу ПЛК runtime ни коем образом с "простейшей программой" не клеится.
Сделать runtime непросто. Там кучу всего отлаживать придётся: Ethernet/TCP/RS-232/Modbus/GPIO/файловая система/task scheduler/simulation/on-line visualization. В конце концов, библиотеки делать под это добро (чтобы пользователи пользовались, а продукт при этом мог развиваться).
Какую часть можно переиспользовать из opensource (или из имеющихся прошивок для ПР) -- фиг знает. Я не знаком с тем, что есть в opensource на тему embedded.
Потом всё это документировать.
И потом отвечать на вопросы пользователей, которые "неправильно" используют, и жалуются что "не работает".
Я соглашусь, что это немалые ресурсы. На это большие ресурсы нужны.
Более того, без среды разработки создавать runtime по-моему тоже смысла нет. В чём пользователь будет программы составлять/отлаживать/визуализировать? В блокноте что-ли?
Меня на эту тему Владислав пытался троллить:
С оценкой 40-50 человеколет я не согласен (на мой взгляд, всё гораздо быстрее можно сделать, если делать среду для устройства класса ПЛК110[М02]), но, на текущий момент, предложение "создать свой компилятор ПЛК и использовать его _вместо_ КДС" я рассматриваю исключительно как троллинг.
На мой взгляд, правильный подход это создать среду-редактор, и, если реально пойдёт, то на базе этой среды уже смотреть в сторону runtime. Ещё раз: в создании языка (ST/CFC/IL) проблем почти нет. А разработка прошивки для "Ethernet/TCP/RS-232/Modbus/GPIO/файловая система/далее по списку" это непросто.
Например, сделать runtime для PRU -- вполне по силам компании ОВЕН. В соответствующей теме есть прогресс: http://www.owen.ru/forum/showthread.php?t=22169
В подтверждение тому -- у ОВЕН _уже_ есть runtime для PRU. Вот среды разработки для PRU нет, это да (на мой взгляд, её довольно просто сделать). Но сам принцип работы PRU именно такой, как вы описываете: создаётся файл, и он загружается контроллером при старте. КДС используется исключительно для того, чтобы залить файл с программой в память ПЛК.
Сделать PRU runtime проще, т.к. по сути там нет внешних коммуникаций. Всё сводится к арифметическим операциям и работой с памятью.
Я же говорю - Вы бесконечно далеки от микропроцессорной техники.
Рантайма в этом случае нет! То есть вообще нет. Программист в этом случае сам разрабатывает программу на ассеблере, чаще на Си, компилит и через монитор заливает в ПЗУ. Собственно, этим занимаются "эмбедовцы". Подобное делает и ОВЕН для ТРМов и рантаймов ПР/ПЛК.
Просто пробежитесь по http://www.phyton.ru/ как пример.
А как по-вашему будет работать modbus?
"пользователь сам на ассеблере, чаще на Си будет программировать modbus"?
Такое (заставлять каждого программировать свой modbus на ассемблере) не взлетит.
А, если говорить, что "modbus будет сделан инженерами ОВЕН как часть библиотеки, поставляемой с прибором", то это то же самое, что "в runtime входит библиотека modbus".
А можно пример проекта/потребителя, которому реально нужно только голое железо, без библиотек modbus/tcp/filesystem/gpio и т.п.?
Раз уж говорите, что вам нужен "ПЛК без рантайма", то скажите кому нужно голое железо. Даже наладить общение ПЛК и модуля ввода далеко не каждый сможет, если "рантайма вообще нет"
Библиотеки прилагаются в объектниках или прошиты в аналоге BIOS.
Ну, это я и называю runtime'ом (по факту, это же и есть runtime library)
Библиотеки в вашем предолжении кто должен писать?
ОВЕН с нуля? Это, на мой взгляд, непросто.
Или предлагаете базироваться на http://www.phyton.ru/ или чём-то таком?
Чем тогда http://www.phyton.ru/ кардинально отличается от КДС? Разве что языком (ну, в phyton пишем на C, а в КДС на ST/CFC/IL).
Понятно....
Не лезьте в эту тему, Вам не хватает фундаментальных знаний!
Ничего, что ОВЕН пишет драйвера для обвязки рантайм КДС? И билиотеки МОДБАС/ПИД/etc?
Кто будет пользоваться такой "болванкой"? Да подобные Вам писатели на Си.
Ну, да, гораздо проще сказать "сам дурак", чем посмотреть правде в глаза.
Сначала вы утверждаете, что "Рантайма в этом случае нет! То есть вообще нет", а потом внезапно оказывается, что всё-таки ОВЕН должен сделать реализацию библиотек для всего-всего (сеть, файлы, 485, и т.п.)
Одно дело делать библиотеку ПИД, когда среда/tcp/task scheduler/ethernet/modbus и т.п. берётся готовое (переиспользуется многое из КДС).
Не знаю какой сейчас объём наработок у ОВЕН, но полагаю, что даже сейчас им нужны немалые вливания, чтобы сделать "свою прошивку" (==runtime library) с поддержкой базовых библиотек (файлы, сеть, modbus).
А давайте пример реального проекта?
Для моего проекта (своей квартиры) я рассматривал разные варианты:
1) Разбираться с голым железом меня желания нет. Да, я люблю программировать, но не до такой степени, чтобы для управления электрикой в квартире изучать голое железо.
2) Да, можно было бы рассмотреть мини-ПК с linux на борту, но я уверен, что оно рано или поздно зависнет.
3) Да, можно было бы сделать на ПР/Siemens logo, но программировать квадратиками я не люблю
4) В итоге, я остановился на ПЛК110.
Поэтому, меня не стоит рассматривать как желающего пользоваться болванкой.
Да, могут быть желающие пользоваться голым железом, но, по-моему, эти желающие слабо пересекаются с областью применения приборов ОВЕН: ЖХК, пром. автоматика.
Вот именно поэтому в ПР используется FBD.
О, случилось чудо и мы поняли друг друга?
Т.е. по сути вы говорили о следующем:
1) выкинуть КДС
2) сделать набор библиотек, и среду на базе FBD
3) для нежелающих пользоваться FBD сделать возможность программирования на C
?
Хорошо, с этим предложением понятно. Можно добавлять в список "предложений для ПЛК".
Попробуем тогда вернуться к исходной теме: собирать предложения нужно?
Если что, я не питаю ложных иллюзий, что сейчас мы пообсуждаем, и ОВЕН к осени выпустит ПР100500-ЯЗЬ (ПР моей-мечты).
Тут успехом, скорее, будет "вспомнить" одно-два давно забытых и нужных предложения, и сделать их.
Предложение по ПР - оставит идеологию, как есть. Кардинально переработать среду, ибо редактор - ужасный
Скажем так, это самый ужасный в плане работы редактор фбд из всех, которые я встречал более чем за 20 лет. Ну и иные мелочи на этом фоне.
Звучит как в анекдоте.
-- Точность прогноза погоды достигла 40%
-- Они бы наоборот предсказывали -- точнее бы было
Если честно, я не понимаю как можно сделать "все наоборот", чтобы из самого худшего получился лучший.
Я, конечно, понимаю, что общее ощущение строится из кучи мелких деталей, но, может, всё-таки есть что-то конкретное?
Лично мне было бы тяжело работать с пожеланием "переделать всё с нуля". Даже отдаленная, но более конкретная цель лучше, чем "Миша, давай по новой"
Проводите по человечески линии связи. Чтобы гарантированно не "слипались". Что бы шли "со сетке".
Пусть будет произвольный порядок линий связи, даже без возможности редактирования, но такое поведение - за пределами нормальной работы.
Как пример - редактор САС из КДС.
Скажем так, уже одно это приводит к тому, что при прочих равных я выбираю иное ПР.
Вложение 25319
Вас именно это напрягает?
Вот сделать возможность выделения связи в симуляторе (как в редакторе) сделает отладку более удобной.
Разводка связей "по отдельности" как в Кодесис приведёт к необходимости увеличения размеров холста, и что лучше?
Вложение 25318
Я вас понимаю, менять привычки это трудное занятие.
Евстигнеев Максим если вторая (третья) связь идет из того же выхода, она должна "прилипать" к уже проведенной на равнозначном пути следования.
з.ы. посмотрите поведение LOGO, там даже жирные точки ставятся на чертеже...
Нужно ОЛ научить обновляться через прокси с авторизацией. Сейчас он только жалуется на невозможность соединения, не предлагая авторизоваться.
Вложение 26415
Можно ли сделать возможность начинать связь не от выхода, а от узловой точки уже имеющейся выделенной линии связи (например от поворота)? ИМХО это было бы удобно, когда из одного выхода делается несколько связей и частично решает проблему "прилипания". Например, привязать эту функцию к клавише "Alt".
И еще одна хотелка из разряда "Было бы удобней...", с картинкой для пояснения.
Вложение 26416
Если имя входа/выхода в макросе отличается от канонических "Ix" и "Qx", то каким-либо образом отображать их (имена) на (возле) пиктогремме соответствующего входа/выхода. Сейчас я пользуюсь комментариями (на картинке они желтенькие), но при внесении изменений в макрос, могут случиться недоразумения, когда вход/выход не соответствует коментарию, ведущие к ошибке.
Отпуска закончились, вспоминаем активнее. Пишем сюда: http://goo.gl/forms/8U4B86d9szlti8XH3
Через какое-то время пробегусь -- соберу в кучку.
Я ещё парочку вспомнил:
1) возможность "заходить внутрь макроса" и смотреть что с ним происходит непосредственно в момент отладки внешнего.
В случае "макрос в макросе", на холст выводятся входы/выходы вложенного макроса, но невозможно зайти внутрь и посмотреть почему он вернул именно такое значение.
2) Каким-то образом подкрашивать обновлённые значения на схеме при пошаговом выполнении.
Например, если значения входов/выходов какого-то элемента изменились (по отношению к прошлому шагу, то подкрашивать). Как вариант, подкрашивать саму связь.
Речь об этом? Вложение 26457
Поддерживаю!!! ПР200 - уже готовое решение для встройки в дверь шкафа управления.
Я лично уже так сделал в одном проекте. Однако, в существующем конструктиве это порнография.
Если появиться версия ПР200 в щитовом корпусе, как например ИП320, то продажи ПР200 однозначно вырастут.
Я не понимаю, почему сами разработчики этого не видят!
Можно это использовать: http://tdmelectric.ru/collection/katalog-1-1425326898
Что же касается ОЛ, то действительно графический редактор ужасен. Провести связь - это целое искусство!
Забыл!
В местах соединения связей обязательно должна быть точка!