да, но не забывайте, что время реакции на входы будет связано с текущей частотой выдачи импульсов ШД ))Сообщение от Newcomer
Фантастика. Все решается быстро и просто. Hardella IDE рулит.А.Приходько и В.Филоненко, а вы что скажите ? Может вам объединить свои усилия с В.Ситниковым ? От этого выиграют все и это главное о чем надо думать.
Это смотря как программу написать )
Раз уж вы, Дмитрий, Ящик Пандоры раскрыли, то теперь PRUграммирование это дело техники, и вопрос PRU0.prg/pruAccessLib больше не стоит.
Джиттер можно легко рассмотреть на хорошем осциллографе. В.Филоненко, дайте вашим тестировщикам задание капитально проверить ФБ для ШД, разработанный В.Ситниковым, и всем спорам конец. Во многих практических случаях, например при управлении ШД, джиттер не страшен, что и подтвердилось при натурных испытаниях.
В.Филоненко, а когда появится ваш правильный ФБ для управления ШД ?
Последний раз редактировалось Вольд; 12.10.2016 в 11:51.
а что тут исследовать? Ситников прямо написал что время цикла выполнения зависит от текущей частоты выдачи шага, плюс язык высокого уровня принципиально не будет выравнивать время выполнения разных ветвей алгоритма... исследовать имеет смысл наличие случайной составляющей, а при заявленной принципиальной несовместимости - о чем речь? Поэтому использовать можно все что угодно, но не забывая что там внутри и чем это грозит в случае вроде бы применения в аналогичном случае.
Предлагаю на это не отвлекаться. Уже все поняли, что Владислав и Дмитрий считают, что джиттер обязан быть.
Считают -- их право.
Интереснее обсуждать как должно выглядеть "task configuration" в случае PRU.
Есть идеи/предложения?
А какая связь между Task configuration и PRU ?
Последний раз редактировалось Вольд; 12.10.2016 в 20:23.
У PRU ядра всего один поток команд.
Т.е. В каждый момент времени PRU берет следующую команду и выполняет. Никаких прерываний нет.
До этого я составлял программы, в которых было все-все-все. И чтение входов, и обмен данными и
ожидания, и запись выходов.
Мне, конечно так проще, да и всё равно никто другой черепахой не программировал.
Но есть "незадача". Например, для управления ШД нужно мигать выходом с разной частотой. Например, на разгоне вообще частота с каждым импульсом меняется.
В результате, пока "ждём момент для очередного ШД импульса, опрашивать энкодер все равно нужно".
Напомню: прерываний нет, и единственный вариант "переключить выход ровно через 1мкс" это "выполнить 200 каких-нибудь команд" (на частоте 200МГц как раз так получается, что 200 простых команд занимают 1 мкс".
Опрос входа -- 1 команда. Проверка "менялось ли значение за последнюю микросекунду" -- это ещё штук 5-6 команд.
В итоге, 4 входа с примитивной фильтрацией займут ~ 4*7 == 30 тактов == 30/200 мкс == 3/20 = 0.15мкс.
Ещё может случиться "обмен с HOST'ом" (он, ведь, каждую миллисекунду случаться будет?) Это ещё команды непредвиденные.
В итоге, чтобы всё успеть, нужно делать фарш из опросов входов-выходов, фильтрации, и т.п.
Я вижу как минимум следующие варианты:
1) Оставить как есть и "в первой версии PRU среды" сделать режим, когда программист пишет полную программу (включая while true). Так сказать, отложить решение проблемы. При желании всё равно можно будет и ШД и энкодер в одной программе обслуживать, но придётся в правильные моменты добавлять опрос энкодера.
2) Вынести ожидание из ШД программы, и сделать так, чтобы основной цикл всегда вызывал все действия. Тогда в ШД блоке нужно будет добавить проверку "пора ли уже". Казалось бы, вот решение, но при этом точность упадёт. выход будет не "когда нужно" переключаться, а тогда, когда дойдёт управление до ШД блока. Это может оказаться 50-100 команд, т.е. 0.25...0.5 мкс.
3) При создании PRU программы указывать: "вот этот код нужно вызывать раз в 1мкс, вот этот раз в 20мкс, а у этого расписание плавает и он сам будет говорить когда надо". Вроде, подобное в КДС называется task configuration.
4) Ещё можно подумать над тем, что PRU программы будут не сразу входы изменять, а будут говорить "через какое время вход должен измениться".
В случаях 3 и 4 код "основного цикла" будет формироваться из фрагментов, предоставленных программистом и разбавляться проверками времени.
Возможно, есть ещё варианты.
Последний раз редактировалось Владимир Ситников; 12.10.2016 в 21:08.
Может вы объясните чем грозит наличие джиттера в ФБ для управления ШД. Этот микроскопический джиттер, если он есть, ШД вообще не заметит.
Последний раз редактировалось Вольд; 12.10.2016 в 20:16.
Казалось бы, вот решение. Просто указываем "длину мин цикла и радуемся". Но, нет.
На частоте 200кГц (нормальная такая частота для работы ШД) цикл нужен порядка 2.5мкс (2.5мкс единица, потом ещё столько же ноль).
Даже если умудриться сделать "минц=0.5мкс" (там сложность в том, что ШД на разгоне потребляет как раз примерно 0.5мкс), то всё равно получаемые частоты будут кратны 0.5мкс. Т.е. либо 2.5мкс (5 циклов), либо 3.0мкс (6 циклов), либо 3.5мкс, .... В частотах это:
1/(2*2.5e-6) == 200кГц, 1/(2*3.0e-6) == 167кГц, 1/(2*3.5e-6) = 143кГц, 1/(2*4.0e-6) == 125кГц.
Нехилый такой шаг. Особенно перескок 167кГц -> 200кГц. Вот если бы была возможность менять минц по ходу, то можно было гораздо точнее сделать переход.
Текущая моя ШД программа обеспечивает длительность импульса с точностью ~5-10нс (наносекунд!). И переходить от такой точности к точности "0.5мкс" как-то не по себе.
Хотя, для небольших частот, возможно, вариант с "мин ц порядка нескольких микросекунд" будет достаточным и весьма понятным для типичных инженеров (ну, тех, кто понимает что такое минц=1мс в ПЛК).
Длительность импульса с точностью 5...10 нс ни к чему. Для ШД поддерживать длительность импульса с точностью 0.5мкс вполне достаточно.
Ваши права
Ответить с цитированием