Джиттер можно легко рассмотреть на хорошем осциллографе. В.Филоненко, дайте вашим тестировщикам задание капитально проверить ФБ для ШД, разработанный В.Ситниковым, и всем спорам конец. Во многих практических случаях, например при управлении ШД, джиттер не страшен, что и подтвердилось при натурных испытаниях.
В.Филоненко, а когда появится ваш правильный ФБ для управления ШД ?
Последний раз редактировалось Вольд; 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.
Не совсем понятно какие проблемы в варианте 1.
В варианте 2 во время генерации импульсов период постоянно будет увеличиваться на 0,25...0,5 мкс ?
Проблемы варианта 1 в том, что "ппограммировать сложнее". Грубо говоря, у многих проблемы с пониманием цикла плк, а тут основной цикл придётся вручную целиком писать. Не домохозяйки, конечно собрались, но все же.
В варианте 2 будет рваный ритм. То туда, то сюда в зависимости от того, сколько каждый блок занял. ШД на разгоне и ШД во время основного хода занимает разное время.
Как разновидность 2го, можно всегда дополнять цикл, скажем, до 1 мкс. Выполнили все блоки, обменялись данными с хостом, и, если 1мкс ещё не прошла, то крутим пустой цикл (но с фильтрацией входов). Тут минус в том, что реакция будет привязана к этой самой "длительности цикла"
Последний раз редактировалось Владимир Ситников; 12.10.2016 в 21:52.
Может вы объясните чем грозит наличие джиттера в ФБ для управления ШД. Этот микроскопический джиттер, если он есть, ШД вообще не заметит.
Последний раз редактировалось Вольд; 12.10.2016 в 20:16.
Ваши права
Ответить с цитированием