да, увидел.Сообщение от Владимир Ситников
запутала меня винда, вывод version говорит 1.8, а в %JAVA_HOME% 1.7, спасибо, ждите вопросов по IDE
да, увидел.
запутала меня винда, вывод version говорит 1.8, а в %JAVA_HOME% 1.7, спасибо, ждите вопросов по IDE
Пока ничего не удалось запустить. вылезло вопросов несколько.
Скажу сразу, пока мне PRU не нужен, хочу удобно писать проект под ПЛК 100 КМ, таргет увидел, вроде можно писать.
1) Создал пустой проект, PLC Project, PLC model: 3S Codesys PLCWinNT V2.4, ok
2) Создался с lamp и TOF, ок, нажимаю run->Edit Configurations-> add Codesys, Configuration = RunConfiguration, ok
3) Run -> открылся codesys с такими ошибками
Ошибка: Ошибка при выполнении команды 'project build'
что не так?
- - -
Запустил с таргетом ПЛК 100 КМ, потом run-> ... так же как и выше
Codesys с ошибкой, но потом еще раз перекомпилировал, оказалось lamp не определён нигде.
Или надо обладать некой магией, которой я не обладаю или ...
- - -
Боже, минут 5 не мог создать переменную.
объявляю
b:bool;
матюкается hardella, чего-то не так ей
пишу b:BOOL; -> пропустила
Меня даже codesys 2.3 поправляет с bool на BOOL, а hardella не знает.
Всё, спасибо за труды, может в другой раз.
Последний раз редактировалось Scream; 24.01.2017 в 13:16.
Дело в следующем:
1) В демо-проекте переменные lamp и button объявляются "в plc configuration"
2) Да, для 3S Codesys PLCWinNT V2.4 таргет не импортируется, поэтому в результирующем КДС проекте переменные lamp и button нигде не объявляются, и проект не компилируется. Наверное, стоит добавить сообщение "неизвестно куда в вашем таргете прописывать discrete inputs/outputs"
3) Для ПЛК 100 КМ нужно проверить. Я проверял только на таргетах ПКЛ110. У вас вообще PLC Configuration симпортировалось нормально? (слева в дереве проектов модуль cds. Там дожно быть plc configuration)
3) В том то и дело, button есть, а lamp нигде нет.
Тоесть часть переменных.
Выпустил Hardella 1.6.2.
Можно скачать с сайта, а можно через автообновление.
Новые возможности:
- Регистронезависимый ввод типов, имён переменных. Например, если ввести bool, то среда заменяет на BOOL
- PRU: обмен данными с PRU был доработан, и теперь вместо одной программы MemoryTransfer создаются две (MemoryRead и MemoryWrite). Старая MemoryTransfer тоже пока создаётся (чтобы не ломать текущие проекты).
Исправлено:
- Убраны лишние скобки после операции NOT
- Подключать библиотеку pruAccessLib.lib больше не требуется (ранее она использовалась для определения online режима)
- CoDeSys: поддержка PLC100 таргетов в демо проекте (демо проект не работал, т.к. не мог найти discrete output)
Это и про "невозможность написать bool" решено в 1.6.2
Ого, вот это скоростьтак бы в ОВЕН
Ну, про регистронезависимость capzap ещё в прошлом году писал:Ого, вот это скорость
Поэтому, где-то месяц задержка получилась.
На самом деле, там большая проблема это как сделать понятную и удобную систему типов. Если кто подскажет -- буду рад
b : BYTE
b := b + 1;
Должен ли такой код работать?
А такой?
b : BYTE
w : WORD
b := 0;
w := b - 1; (* должно ли получиться 16#ffff или 16#00ff? *)
С технической точки зрения это дребедень, а не код, ведь, в BYTE и WORD являются наследниками типа ANY_BIT, а для этого типа не определены операции сложения и вычитания.
Тем не менее, подозреваю, что у всех в проектах есть сложение, вычитание, и, возможно даже умножение.
Поэтому остаётся либо запретить вообще подобные типы (ну прямо запретить сложение WORD'ов), либо ещё что-то.
Если посмотреть как сделана система типов, например, в java, то там любое сложение даёт int. Т.е. даже byte+byte складываем -- сразу получается int (это 4 байта).
Ещё есть особенный случай когда складывается long с чем-нибудь (там тоже получается long).
С одной стороны, конечно, странно всё время "добавлять приведения назад к байту", с другой, это снимает кучу головной боли.
Например, при таком подходе w окажется именно 16#ffff, а никак не 16#00ff.
В CoDeSys 2.3 работает, значит у вас то же так должно быть.
В CoDeSys w получается 16#ffff
Зачем вообще думать. Делайте по аналогии с CoDeSys.
Казалось бы, но нет.
Должно работать так, чтобы можно было писать программу и не задумываться.
В случае с CoDeSys каждый второй раз удивляются "откуда берётся fffff в энкодерах", слёзно просят DINT значение энкодера и прочее.
Тема "signed vs unsigned" возникает и в C/C++ -- там это тоже огромный источник ошибок, опечаток и головной боли.
Хорошо бы, конечно, вообще запретить беззнаковые типы.
В том-то и проблема с CoDeSys, что никакой последовательности нет. Там нет общего правила, а есть лишь куча исключительных случаев.
Собственно, вопрос: какого типа является константа 1 в выражении b - 1?
Это BYTE? SINT? USINT? INT?
А, ведь, от этого сильно зависит, например, результат b XOR -1. Если правильно помню, то b XOR -1 в КДС не компилируется.
Ваши права
Ответить с цитированием