Не ожидал что так быстро и красиво получится у вас, успеха, подпишусь на тему.
Не ожидал что так быстро и красиво получится у вас, успеха, подпишусь на тему.
Весело. Как там нынче с копи-пастом в проекционных редакторах?И как?Аккуратнее с этой фигнёй. 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Сообщение от Yegor
Ну, в стандарте так и сказано, что "результат приведения типов, не описанных явно отдаётся на откуп производителю".
Но 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 это другая история.
Я наоборот, скорее не понимаю смысла такого сложения. BYTE явно пришел нам из железа, и ничего кроме битовых операций я бы к нему не применял. Даже если это АЦП, в нашей реалии на него надо навернуть калибровку датчика и получить real.
А если надо, то сперва явно кастовал бы BYTE к нужному типу. Но то дело вкуса, во многом.
эксепшенами пахнет?
Фиг знает. Я в текущем проекте пишу на CoDeSys только потому, что нашелся у Овена сносный контроллер -- пром. исполнения, умеренно безглючный, быстро покупаемый и с живым саппортом/форумом. Смог бы купить промышленного исполнения встраиваемую плату - все было бы иначе. Втолкаться в готовое железо мне казалось бы хорошей идеей.
Другое дело, что рантайм можно спросить у фирмы 3S, я бы на их месте обрадовался и отдал бы что-нибудь типа кодесис-ядра под линукс. Спросив сперва NDA возможно. Как проект это все было бы круто, интересно и молодежно, карма на хабре вверх и все дела))
Но в суровой промышленной жизни разнообразные RPi и проч. недорогие ардуины не выживут. Разве что сделать под них отдельный бокс с фильтрацией питаний, развязкой входов-выходов и так далее. Кстати, может быть это коммерческая ниша?..
Последний раз редактировалось rapucha; 06.01.2016 в 13:54.
Какой смысл иметь два разных беззнаковых типа?
Чем USINT принципиально отличается от BYTE?
Честное слово, не понимаю.
Да и сами по себе беззнаковые типы не нужны. От них только проблемы: http://www.nayuki.io/page/unsigned-i...rmful-for-java
Т.е. знаковые типы + явные операции для того, чтобы работать "как будто с беззнаковыми" и всего делов.
Нет. Речь о том, что при вычислении FALSE AND ... вторую половину AND'а можно и не вычислять -- всё равно понятно что суммарно false будет.
семантика, извиняюсь, разная. byte это набор бит, отражающий состояние железа. делать над ним арифметику -- нет смысла.
мне строгая типизация как-то больше по душе. Меньше шансов налажать, особенно при работе с чужим кодом/библиотеками.
прошу прощения, убегаю, буду рад продолжить вечером
Ну, обмен ещё можно попытаться¹ разобрать. Я больше всего застрял на формате бинарника. Конечно, теоретически, можно найти способ протолкнуть программу на готовый контроллер, но я бы не стал рассматривать это всерьёз, т.к. по моему опыту пуско-наладочных работ без возможности отладки всё это теряет смысл. Сделать бы более-менее развитую среду, а железо какое-нибудь найдётся. Вон у Овна вроде как под мастер скаду версии контроллеров есть. «Делать с нуля»... Ну, давайте честно, редактор вы тоже не с нуля делали. Точно так же не с нуля можно делать и рантайм. Сначала интерпретатор шоб поиграться, потом байт-код свой какой-нибудь (да хоть даже в кодесисе свой мелкий рантайм сваять), потом машинный код попробовать... Не так уж сложно вроде бы. Хотя это уже гораздо больше, чем автодополнение, о котором тут вроде шла речь.Воообще, я пока не пойму каким образом идёт обмен данными с контроллером.
Делать runtime с нуля немного странно.
Вот если можно в каком-то "стандартном" формате скармливать скомпилированный проект в контроллер (например, прикидываемся CoDeSys'ом, и кормим бинарник в овен), то, конечно, интересно.Определённо не стоит фигачить на С, плюсах и других паскалях. Все они делались под другую модель исполнения.фигачить на C
Последний раз редактировалось Yegor; 06.01.2016 в 12:06.
Ну, делать среду под "мифический" контроллер тоже непонятно как.
Да и среду я не то чтобы "ради среды" делать хотел.
Ко мне ПЛК110 скоро приехать должен. Поэтому вариант "сделать среду, и сангажировать ОВЕН на выпуск ПЛК777 с её поддержкой" как-то не очень греет.
Рапуча, есть BYTE, а есть SINT и USINT. Все они по 8 бит, но тип BYTE это как бы 8 отдельных бит, не число. BYTE по стандарту вообще складывать нельзя; только поразрядная логика: AND, OR, XOR, NOT.
Расширять/обходить готовую среду разработки ради своих проектов греет разве? Я понимаю, что MPS для этого и создавалась, но в ПЛК я ещё не встречал таких объёмов кода, чтобы это было оправдано. Проще тупо набить код, с подсказками или без них. Хз, мне остаётся пожать плечами в этой теме.Ко мне ПЛК110 скоро приехать должен. Поэтому вариант "сделать среду, и сангажировать ОВЕН на выпуск ПЛК777 с её поддержкой" как-то не очень греет.
Ваши права
Ответить с цитированием