как будет работать эта IDE с codesys?
как будет работать эта IDE с codesys?
В нулевом приближении, нажимаем "экспорт проекта" и оно генерирует CS проект (ну или несколько CS проектов).Сообщение от Scream
А так, у CS, вроде, есть возможность загрузить проект с командной строки и залить его в устройство. Можно автоматизировать.
Ну и, если Овеновцы (или как правильно?) помогут/не будут против, то можно организовать более прямую связь, в обход CS.
OwenLogic же как-то работает с ПР?
ЭЭ.. и как назовем? препроцессором языка ST++ ? ))
IDE выглядит круто. Но работы по увязыванию с кодесисом там же дофигищи: без импорт-экспорта тоскливо, без поддержки библиотек тоже невесело, а там и дебажить захочется..
Вот это будет офигенчик )) Кстати, ваш проект кросс-платформенный?
Ага. Всё что я назвал тривиально преобразуется в простой CS код. Например, те же переменные просто нужно вынести "в область объявления", переименовать чтобы различались и убрать begin/end.
Код пишем "с блоками begin/end", а при экспорте в CS оно преобразует код к "совместимому с CS виду". Сделать extends/implements посложнее, но тоже решаемо.
Если в режиме "экспорт в CS", то от библиотек будет достаточно описания типов и входных/выходных переменных (т.е. сам код не нужен). В lib файлах описания прямо в текстовом виде.
Для создания эмулятора, конечно, нужно понять в каком формате хранится код внутри *.lib хранится. А тут, глядишь, до декомпилятора недалеко.
Возможно, для этого будет проще эмулятор сделать. Но, конечно, отладка на живом устройстве интереснее, чем на эмуляторе.
Ну, да. Windows/Mac/Linux.
Скриншоты из MacOS, но выглядеть примерно одинаково будет.
Не ожидал что так быстро и красиво получится у вас, успеха, подпишусь на тему.
Синтаксический сахар+поддержка библиотек+заливка в ПЛК -- набор функционала, с которым проект _на_мой_взгляд_ может иметь смысл. Возможно, даже без дебага, если отладку в консоль прокинуть.
Я, впрочем, не очень активный пользователь платформы. У меня свои аберрации восприятия.
Весело. Как там нынче с копи-пастом в проекционных редакторах?И как?Аккуратнее с этой фигнёй. BYTE, WORD и DWORD вообще не являются числами по стандарту 61131-3. Для них не определены арифметические операции и прочая числовая семантика. Это битовые поля. Если уж взялись, то рекомендую открыть стандарт и попробовать сделать по нему, а не как в кодесисе (для которого INT#TRUE является числом, например).Error: type DWORD is not a subtype of BYTEЯ думаю, отдельным блоком переменные сделаны не просто так. Это часть поддержки редактирования программ на работающем контроллере и часть единообразия с графическими языками. Мне б тоже хотелось анонимные функторы типа IF TON#(IN := x, PT := y).Q THEN ..., но это уже совсем другой язык получается.Т.е. добавляем отдельный блок "BEGIN ... END;", разрешаем объявлять локальные переменные/константы прямо посреди кода (или только сразу после begin/if/while, чтобы уж совсем говнокод не плодить), добавляем возможность наследования структур, объявления методов в них и получится норм?А чего мелочиться? Прикрутить сюда кодогенерацию через тот же LLVM, а там и до отладчиков недалеко.Возможно, для этого будет проще эмулятор сделать. Но, конечно, отладка на живом устройстве интереснее, чем на эмуляторе.
Последний раз редактировалось Yegor; 06.01.2016 в 11:04.
Своеобразно, но норм: https://www.youtube.com/watch?v=o4PN...=youtu.be&t=90
Ну, в стандарте так и сказано, что "результат приведения типов, не описанных явно отдаётся на откуп производителю".
Но INT#TRUE, это, безусловно, жесть.
А неявное преобразование BYTE -> WORD, скорее норма.
Аналогично и неявные преобразования между USINT <-> BYTE. Чего в этом плохого?
А чего плохого в том, чтобы в WORD переменную можно было записать BYTE значение?
Не на ассемблере же пишем.
Мне, на самом деле, не нравится, что в CS результат сложения BYTE и BYTE получается BYTE (в стандарте, к слову, так же). Мне бы больше по душе было получать WORD (т.е. чтобы не терять данные). А уж если нужно в конце концов в BYTE получить, то явное преобразование.
Вроде, тот же самый язык. Но, конечно, тут семантически тонко будет в операциях вида IF TON#(...).Q OR TON#(...). "до второй части выполнение может не дойти и т.п."
Т.е. легко ошибиться, что, конечно, нехорошо.
Воообще, я пока не пойму каким образом идёт обмен данными с контроллером.
Делать runtime с нуля немного странно.
Вот если можно в каком-то "стандартном" формате скармливать скомпилированный проект в контроллер (например, прикидываемся CoDeSys'ом, и кормим бинарник в овен), то, конечно, интересно.
И ещё: если сохранить похожесть на 61131, то есть простой и понятный переход со старых проектов на новые. Или постепенно заменять блоки.
А если целиком с нуля runtime делать, то, может, вообще проще взять mbeddr ide и фигачить на C? Но C это другая история.
Ну, обмен ещё можно попытаться¹ разобрать. Я больше всего застрял на формате бинарника. Конечно, теоретически, можно найти способ протолкнуть программу на готовый контроллер, но я бы не стал рассматривать это всерьёз, т.к. по моему опыту пуско-наладочных работ без возможности отладки всё это теряет смысл. Сделать бы более-менее развитую среду, а железо какое-нибудь найдётся. Вон у Овна вроде как под мастер скаду версии контроллеров есть. «Делать с нуля»... Ну, давайте честно, редактор вы тоже не с нуля делали. Точно так же не с нуля можно делать и рантайм. Сначала интерпретатор шоб поиграться, потом байт-код свой какой-нибудь (да хоть даже в кодесисе свой мелкий рантайм сваять), потом машинный код попробовать... Не так уж сложно вроде бы. Хотя это уже гораздо больше, чем автодополнение, о котором тут вроде шла речь.Воообще, я пока не пойму каким образом идёт обмен данными с контроллером.
Делать runtime с нуля немного странно.
Вот если можно в каком-то "стандартном" формате скармливать скомпилированный проект в контроллер (например, прикидываемся CoDeSys'ом, и кормим бинарник в овен), то, конечно, интересно.Определённо не стоит фигачить на С, плюсах и других паскалях. Все они делались под другую модель исполнения.фигачить на C
Последний раз редактировалось Yegor; 06.01.2016 в 12:06.
Ваши права
Ответить с цитированием