Не смею оспаривать. Я просто исхожу из соображений минимизации кода.Сообщение от Владимир Ситников
Не смею оспаривать. Я просто исхожу из соображений минимизации кода.
Расскажу о том, как тестируют эти ФБ.
Берём, например, блок для ABZ энкодера.
Из ST сам собой генерируется следущий java код.
Тут и команды для процессора, и вспомогательные методы, чтобы обращаться ко входам-выходам ФБ не через регистры процессора, а в человекопонятной форме setA/setB/getPosition и т.п.
Снимок экрана 2016-10-07 в 13.38.28.png
Потом пишем тест: подаём по очереди значения на входы A/B и смотрим правильно ли блок на них реагирует.
Снимок экрана 2016-10-07 в 13.41.28.png
Так же есть аналогичный тест на вращение в другую сторону.
Запускаем тесты, и видим, что работает:
Снимок экрана 2016-10-07 в 13.46.44.png
Для полноты картины можно добавить тестов, когда крутим туда-сюда, в разные стороны и т.п., но и сейчас уже должно быть хорошо.
Аналогичный тест и для блока "управления мотором":
Снимок экрана 2016-10-07 в 13.53.26.png
Теперь можно хоть как менять сами блоки или компилятор -- тесты сразу покажут, если поведение вдруг сломается.
Последний раз редактировалось Владимир Ситников; 07.10.2016 в 14:33.
Владимир Ситников
Наконец-то появилось время сесть на мой проект. Начал разбираться с PRU. Появились грабли.
Сделал простенький проект чисто для отработки моей темы, и при добавлении библиотеки pru_cutter.lib при компиляции практически пустого проекта получаю ошибку:
PRU_Error.png
Причем при неиспользовании FB PRU в проекте.
Так же не совсем понятно, как конфигурировать Fast Discrete Input и Fast Discrete Output в конфигурации ПЛК. Ставить Direct Control?
Насколько я понял, выходная переменная VALUE FB PRU_ABZ имеет тип WORD. В моей задаче используется энкодер 360имп\об, причем в работе установки есть ситуация, когда показания энкодера могут иметь отрицательные значения. Хотелось бы иметь тип этой переменной INT, что бы не заморачиваться с лишними преобразованиями.
Последний раз редактировалось Sulfur; 10.11.2016 в 14:41.
Ошибки "PRU_FB_GETPARAMETER" означают, что нужно добавить библиотеку pruaccesslib.lib
Сама библиотека находится тут: http://www.owen.ru/forum/showthread.php?t=22169 (pack1.zip)
Без разницы как. Всё равно конфигуратор с этими выходами работать не будет. Вернее, через конфигуратор будут работать только fast out1 и fast out2.
out3 out4 же будут работать только через PRU0 (т.е. через программу)
Пока WORD.
За время пути, PRU программирование успело подрасти, и можно всю программу для управления быстрыми входами-выходами написать в Hardella (ну, это на случай, если логика управления изменится)
Владимир Ситников
Залил все нужные библиотеки во все нужные места, загрузил программу, записал файл PRU0.PRG в ПЛК, разобрался с INT\WORD. Заработало.
Однако не так как ожидалось. Итак, проблемы:
1. Энкодер считает все импульсы по всем фронтам. В результате я имею показания -1440...1440. Решил банальным делением на 4 с отбрасыванием дробной части (TRUNC).
2. Счетчик считает по входу FDI1, т.е. с одного из входов энкодера. А должен считать со входа FDI4 (FDI1=A, FDI2=B, FDI3=Z энкодера).
3. После снятия сигнала enable со входа FB PRU_CUTTER выход FDO3 остается активным. Хотелось бы, что бы этот вход имел FALSE при enable = FALSE в любой ситуации. А так же, чтобы PRU_CUTTER не считал при enable=FALSE.
----------------
По поводу видео - пока еще не готово, но задумал собрать эмулятор сервопривода на шаговом движке, жду комплектующие.
Последний раз редактировалось Sulfur; 22.11.2016 в 12:28.
Ну, можно пообсуждать бага это или фича.
А в целом обработка энкодера устраивает?
Т.е. счётный вход совсем отдельно?
Я почему-то решил, что считать энкодер нужно.
Считать нужно передние фронты?
Да, режим "аварийной остановки" не был предусмотрен.
В коде это видно: http://www.owen.ru/forum/showthread....l=1#post223074 (см. последнюю картинку -- блок PRU_CUTTER)
Оттуда же следует и обходной вариант: если изменить runLength в 0, то блок остановится.
Но, да, логичнее будет, если оно и по сбросу enable будет останавливаться.
Я понемногу делаю сайт с документацией для среды -- можно пример использовать как "стандартный пример", если не возражаете.
Ну, с фотографией установки и т.п. По-моему, хороший пример. А "реальность" объекта сильно улучшит качество самого примера.
Да. Мои опасения только в том, что насколько мне известно, операция деления занимает много процессорного времени. Именно поэтому я стараюсь свести к минимуму всю арифметику в главном цикле.
Счетный вход именно отдельно, т. к. на него идет сигнал с другого устройства.
Без разницы. Главное, что бы не было пропусков.
runLength в процессе работы меняться будет крайне редко, и поэтому лучше сделать останов счета и гашение выхода по сигналу enable.
Не возражаю. Готов даже предоставить весь проект модернизации термоформовочной машины Meaf серии BMS600, естественно, когда он будет готов. Однако с реальным "воплощением в железо" не могу назвать даже примерных сроков, т. к. работа ведется по остаточному принципу на перспективу.
Считать надо фронты и срезы сигналов А и В энкодера.
Не про энкодер речь. А про "сигнал с другого устройства". Раз "без разницы", то сделаю по переднему фронту.
А какой смысл останавливать счёт по остановке enable?
Я думал, что продолжение счёта будет отражать фактический выбег.
Но, конечно, ничто не мешает останавливать счёт.
Ваши права
Ответить с цитированием