Marlin: [BUG] SKR v1.3 (или любой другой LPC1768): проблема с сервосигналами, которая вызывает проблемы с bltouch

Вы можете попробовать настоящий BLTouch?

Вы можете попробовать настоящий BLTouch?

Кроме того, пробовали ли вы настроить параметры BLTouch в Configuration_adv.h ?: Вы можете настроить такие параметры, как BLTOUCH_DELAY , BLTOUCH_FORCE_SW_MODE , BLTOUCH_FORCE_MODE_SET и т. Д.

Ой, извините, я забыл упомянуть. Конечно, я пробовал разные комбинации BLTOUCH_DELAY , BLTOUCH_FORCE_SW_MODE и даже DELAY_BEFORE_PROBING раньше. Безуспешно.
Теперь, когда я узнал, в чем проблема, стало ясно, что более длительные задержки не помогают. Потому что неправильный импульс 20 мс, который приводит bltouch в это состояние ошибки, происходит уже за пару секунд до касания рабочей пластины.
BLTOUCH_FORCE_MODE_SET не поддерживается этой старой версией bltouch clone. Он не "умный".

И нет, у меня нет доступа к подлинному BLTouch. Для меня и моего старого клона вышеупомянутый прием работает нормально, поэтому лично мне не нужно исправлять эту проблему. Но я думаю, что эта проблема должна быть исправлена ​​в любом случае, потому что я думаю, что даже настоящий сервопривод может отреагировать на этот импульс коротким встряхиванием или любым другим странным поведением.

Вау, @mlehnhoff , твой патч облегчит мою боль. SKR v1.3 + (не уверен, более старая версия или нет) triaglelab 3d touch - тоже беды. Мое собственное рабочее состояние 8/10: BLTOUCH_FORCE_SW_MODE + BLTOUCH_DELAY 1000. Но ваш патч работает 10/10 без SW_MODE и DELAY. Tnx!

Я тестировал сенсорный датчик на основе сервопривода при повторном включении (тот же MCU), и у меня не было проблем, но я использовал функцию отключения после перемещения.

я не пробовал без этого, juse логично деактивировать сервопривод, когда он не нужен

У меня есть несколько подлинных BLTouches, и все они отлично работают на SKR 1.3, которая также стоит LPC1768 .

Так что, прыгая с пистолета, это, скорее всего, проблема с оборудованием (провод, шумовое соединение) или проблема конфигурации пользователя?

По той же причине для большинства дополнительных параметров кода / конфигурации BLTouch, это проблема клона BLTouch.

Имейте в виду, что 3DTouch! = BLTouch. С этими копиями связано много закрытых вопросов.

Тогда я бы назвал это аппаратной проблемой,

да, теперь 3dtouch (и другие) не BLtouch

Большой вопрос для меня - это то, что марлин поддерживает клонов, или мы заботимся только о подлинных продуктах?

немного подумав, я не думаю, что это справедливо, что марлин должен поддерживать клонов

но я мог ошибаться, мысли?

Мои два цента, как ни назови XXtouch. Любой из них подключается к контакту SERVOS (не специальный контакт BLtouch). Сервоприводы должны работать как сервоприводы.

Но я думаю, что эта проблема должна быть исправлена ​​в любом случае, потому что я думаю, что даже настоящий сервопривод может отреагировать на этот импульс коротким встряхиванием или любым другим странным поведением.
(из комментария @mlehnhoff )

Это не должно быть связано с оборудованием датчика. Сигнал, поступающий с платы, неверен и был проверен с помощью осциллографа. Это должно быть исправлено.

Я также могу подтвердить, что описанное поведение очень похоже на подлинное оборудование BLTouch, когда я отлаживал все эти конфликты таймеров, вызывающие аналогичные проблемы на платах SKR Mini E3. Недопустимая длина импульса, казалось, заставляла BLTouch просто забывать, что он делал, и вызывать сбои.

@mlehnhoff ,

Я не думаю, что мне нравится текущий обходной путь как законченное решение, но я действительно ценю уровень детализации, предоставленный mlehnhoff при описании проблемы, и обходной путь, демонстрирующий, что импульс, по-видимому, является основной причиной проблемы.

Извините, я не сразу предоставил снимок экрана. Я думал, что сделал несколько, но что-то пошло не так. Но я не осознавал этого, пока не вернул прицел (он не мой).
Но теперь я сделал новый:

На картинке вы видите переход от 1472µs к 544µs, но первые новые

импульс составляет 20544 мкс.

Кроме того, я попробовал настоящий сервопривод, и вот доказательство того, что эта проблема не ограничивается только 3dtouch или другими клонами.

IMG_4677.zip

Сервопривод должен повернуться с 90 ° (рычаг посередине) до 0 ° (рычаг вниз), но когда возникает ошибочный импульс, он фактически сначала поворачивается вверх, а затем вниз.

Кстати, существует как минимум восемь различных версий подлинного bltouch (classic v1.0, v1.2, v1.3, smart v1.0, v2.0, v2.2, v3.0, v3.1) и нет один знает, правильно ли все они будут работать ;-)

Вот еще один совет: когда вы отправляете команду M280 вручную, очень маловероятно, что проблема возникнет. Я написал сценарий для переключения сервопривода (использованного в видео), который сильно увеличивает вероятность:
servo_toggle.gcode.txt

Интересно, связано ли это с проблемой, которую я наблюдаю с моим BLTouch.
Я запитываю Re-ARM через USB и использую M80 для включения источника питания 12 В. К источнику питания 12 В, который питает BLTouch, подключен понижающий преобразователь 5 В, поэтому BLTouch не получает питание, пока не сработает питание 12 В.
Когда плата включается, BLTouch мигает красным - это, по-видимому, несколько нормально, если BLTouch получает сигнал перед включением, поэтому меня это не беспокоит.
Однако любая попытка сбросить его с помощью M280 P0 S160 имеет абсолютно никакого эффекта. Он также не втягивает штифт, если он развернут.
Однако M280 P0 S60 успешно переключается в режим SW и также перестает мигать.
За исключением мигания и игнорирования S160 похоже, BLTouch работает отлично. Даже при мигании он правильно развертывается, укладывается и исследует - я делал датчики со сплошным слоем и никогда не видел сбоев датчика, а воспроизводимость отличная.
Это настоящий BLTouch V3.1, а не клон.

Я забыл упомянуть, что я проверил импульсы как с помощью моего дешевого мини-DSO, так и большого осциллографа с ЭЛТ, и длины импульсов кажутся нормальными. Я также пробовал разные значения S (от 155 до 165), но не нашел ни одного, которое вызовет сброс.

Я не смотрел, как работает библиотека сервоприводов для LPC, но:
Сервосигнал - это ШИМ. Если бы это было реализовано с помощью аппаратного таймера STM32, эта ошибка, скорее всего, была бы вызвана обновлением регистра сравнения счетчиков напрямую, вместо обновления нового значения в регистре предварительной загрузки регистра сравнения. Если изменить регистр сравнения с высокого значения на низкое значение, в то время как счетчик находится между низким и высоким значением, (равное) сравнение пропускается, вывод не изменяется до тех пор, пока счетчик не переполнится, а затем достигнет нового значения . Если используется регистр предварительной загрузки, регистр сравнения обновляется либо при переполнении счетчика, либо при совпадении (старого) значения сравнения. Это не имеет риска появления длинных импульсов, только возможная задержка максимум на один период ШИМ (20 мс).
РЕДАКТИРОВАТЬ: вероятность ошибки составляет 5% при пропуске 1 мс назад.
Полагаю, здесь что-то похожее.

Это связано с тем, что инфраструктура lpc не запускает аппаратный pwm в режиме фиксации (где регистр ширины импульса затеняется и фиксируется в каждом периоде), это должно быть возможно сделать с помощью бита простого режима ... но, к сожалению, я не могу заставить его работать надежно, его выбор между возможной ошибкой длительности 1 периода или шириной импульса случайным образом (но довольно часто в зависимости от того, как часто она обновляется) не меняется вообще.

Можно было бы провести дальнейшие исследования по этому вопросу, но на самом деле это несложное периферийное устройство, я потратил много времени на этот сбой, и, в конце концов, другие вещи потребовали внимания.

@mlehnhoff @kockockockoc Как dp вы применяете патч, пожалуйста?

@mlehnhoff @kockockockoc Как dp вы применяете патч, пожалуйста?

Если честно, я новичок в git и просто рад, что смог создать этот патч с помощью "git diff". Я уверен, что должна быть другая команда git, чтобы применить этот патч обратно. Может, @kockockockoc поможет ...
Но для этого очень маленького фрагмента кода это можно сделать даже вручную. Это так же просто, как добавить четыре строки, начинающиеся со знака «+», в файл «Marlin / src / HAL / HAL_LPC1768 / Servo.h» (конечно, без «+») в указанном месте ...

Привет, у меня такая же плата Bigtreetech SKR v1.3 и 3D Touch, но 3D Touch не работает. Я тестировал 3dTouch, используя некоторый код в Arduino Mega, и он отлично работает. Итак, я пробовал любое предложение, которое нашел, а также патч @mlehnhoff, но у меня все еще та же проблема = 3D Touch зависает. При запуске Marlin 3D Touch выполняет самопроверку, а затем штифт вставляется и остается в этом состоянии навсегда без каких-либо изменений (через M43 S или из меню Marlin).
Меня это действительно беспокоит, потому что я не знаю, что мне нужно сделать, чтобы решить эту проблему. Любое предложение приветствуется.

Я подозреваю, что это та же ошибка, о которой я сообщил здесь: https://github.com/MarlinFirmware/Marlin/issues/15370

Я все еще выполняю фиксацию ошибок от 22.06.19 без проблем. Я попробовал последнее исправление ошибок сегодня, и проблема с сервоприводом все еще присутствует.

@ Reywas62 и все http://fightpc.blogspot.com/2019/08/testing-skr-13-board-with-marlin-20x.html, которая может решить проблему. По сути, некоторые платы SKR могут иметь выходной сигнал с низким импедансом (около 200 Ом), который потребует значительного количества тока для правильной работы (и этого не происходит на платах Arduino, поэтому мой трехмерный сенсорный датчик работает правильно. на Ардуино) Так что видимо к прошивке не имеет отношения.

Что ж, я бы купил это объяснение, за исключением того, что моя плата отлично работает с более ранней фиксацией исправления Marlin 2.0.x (22.06.19).

Могу подтвердить, что «быстрое грязное» решение от mlehnhoff работает. Я исследовал UBL-Mesh 9x9 с помощью BLTouch Clone. Обычно 1 или 2 точки сетки из 81 точки не работают, когда я запускаю генерацию сетки. Но с "фиксом" все нормально работает. Так что я буду продолжать использовать это решение. И в моем случае я думаю, что это проблема с длинным сервоимпульсом, потому что мой нажимной штифт развернут, а датчик не срабатывает.

Подтверждаю, что моя проблема с 3D Touch решена. Проблема в малом токе штырей серво SKR 1.3. Я сделал схему и успешно ее протестировал. Теперь я получил эту информацию после запуска M43:
ОТПРАВКА: M43 S
Тест сервопривода
. индекс: 0, угол раскрытия: 10, угол складывания: 90
. Зонд Z_MIN_PIN: 57
. Z_MIN_ENDSTOP_INVERTING: ложь
. Проверить на BLTOUCH
= Обнаружен BLTouch Classic 1.2, 1.3, Smart 1.0, 2.0, 2.2, 3.0, 3.1.
* Пожалуйста, активируйте зонд в течение 30 секунд *
. Ширина импульса (+/- 4 мс): 10
= Обнаружен BLTouch до V3.1 (или совместимый)

Я собираюсь поэкспериментировать с моей настройкой, но у меня есть серводвигатель SG90 и MG90, который периодически возвращается в исходное состояние при отключении. Поскольку он удерживает переключатель Z-Probe, это как бы убивает машину, когда она врезается в кровать. Последняя авария касалась крепления колес Creality CR10 S5. > _

Когда у меня будет возможность, я попробую схему и посмотрю, разрешит ли она это. но тоже собираюсь попробовать прошивку взломать. :)

После попытки взлома прошивки для меня не было никаких изменений (как я и подозревал, поскольку взлом исправляет клоны bl-touch, не обязательно движение сервопривода). Сервопривод иногда все еще двигался назад после завершения движения.

Учитывая это, я отменил взлом и сказал Марлину НЕ отключать сервопривод, и, похоже, проблема с перемещением назад исчезла. Кажется, что отключение сервопривода вызывает мою проблему. К счастью, MG90, который я использую, не показывает вибрации / тряски при выбранных мной углах. :)

Я определенно хотел бы поблагодарить mlehnhoff за их gcode для тестирования. Каждый раз, когда я запускал его, сервопривод включался 3 или 4 раза, и когда я сказал Марлину, чтобы сервопривод был включен, скрипт работал нормально 3 раза подряд. Учитывая сообщения о низком токе, я также провел тест с включенными нагревателями, чтобы поставить блок питания под нагрузку. :)

Не знаю, имеет ли это значение, но мои углы сервопривода составляют 172 (развернутый) и 35 (сложенный), и казалось, что сервопривод перемещается назад, каждый раз на одну и ту же величину. Сервопривод никогда не двигался вперед.

Взлом прошивки не устранил мою проблему, но если оставить сервопривод включенным, сервопривод не будет работать неправильно, как это было с DarkAlaranth. Не совсем исправление, но приемлемый способ обхода.

Небольшая дополнительная информация. Я пробовал это на нескольких платформах за последние пару дней и подумал, что, возможно, сломал оба AntLab BLtouch, поэтому я заказал третью.

Вот что я наблюдал для следующих платформ
SKR Pro V1.1 не работает
SKR v1.3 Не работает
RAMPS 1.4 Не работает
SKR v1.4 Не работает
RAMPS 1.6 Не работает

Симптом перед зондированием читается на M119
Сообщение о состоянии конечной остановки
x_min: TRIGGERED
y_min: TRIGGERED
z_min: TRIGGERED

Я также скорректировал файл контактов с такими же результатами.

Вот процесс, который я использовал в нескольких видео, посвященных марлину разного урожая.
https://www.youtube.com/watch?v=5cSzFCv7K4Q&t=14s
https://www.youtube.com/watch?v=R0HeFV9nKCM
https://www.youtube.com/watch?v=HR-zn4dv1fY&t=2s
https://www.youtube.com/watch?v=-4o6-8TgpNM

Я мог бы опубликовать больше видео, но я хочу сказать, что он не работает ни с одним из них с 3 подлинными прикосновениями BL.

Что-то изменилось в конфигурации? В файле configuration_adv.h теперь есть несколько настроек мощности сенсорного экрана BL.

Должен ли быть отчет о температуре при наведении оси Z?
Вот отладка:
ОТПРАВЛЕН: G28 Z0
ОТПРАВЛЕНО: M114
ОТПРАВЛЕНО: M105
RECV: Ошибка: !! STOP вызван из-за ошибки BLTouch - перезапустите с M999
[ОШИБКА] Ошибка: !! STOP вызван из-за ошибки BLTouch - перезапустите с M999

M119 на RAMPS 1.6 / MEGA2560
Считывает правильно для открытия на z-min
Кажется, что зондирование не работает.

Есть эта проблема.
Ender 3, SKR Mini E3 v1.2, подлинный BLTouch v3.1

У меня отлично работает с V2
Распайка скр1.3 отличается от стоковой ориентацией. Я использую релизную версию Marlin 2.0.1

Можете ли вы попробовать другой BLTouch? Чтобы убедиться, что зонд не поврежден?

Нет извините. У меня только нормальный BLTouch. Неисправность происходит только один раз из ~ 200 или около того.

@mlehnhoff, когда у вас будет время, пожалуйста, повторите тест

а так как bugfix 2.0.x обновляется ежедневно, пожалуйста, повторите проверку каждые 14 дней или около того

Перекомпилировал последнюю сборку с исправлением ошибок [2020.01.24.]
Провели два теста на повторяемость по 150 датчиков.

1. Подогрев кровати выключен, завершено успешно, стандартное отклонение: 0,003928.
2. Подогрев кровати включен, зондирование не выполнено, ошибка 137.

Я наблюдал подобное поведение при использовании bugfix 2.0.x на плате SKR1.1 (LPC1768) с клоном BLTouch (3DTouch).
Я пробовал разные обходные пути, но из 25 точек измерения, по крайней мере, для одной точки измерения, штифт освобождается слишком рано (например, развертывание, сразу за которым следует складывание).

@mlehnhoff, когда у вас будет время, пожалуйста, повторите тест

@boelle : повторное тестирование не требуется, потому что, как упоминалось ранее в @ p3p , проблема на самом деле находится не в самом Marlin, а в структуре LPC. Он сказал, что ему пришлось раскомментировать режим PWM Latching Mode, потому что он не работал должным образом. Итак, пока это не исправлено, каждый, кто хочет иметь надежно работающий bltouch, должен использовать мой уродливый, но рабочий обходной путь.
В настоящий момент у меня, к сожалению, нет доступа к осциллографу, иначе я хотел бы поддержать P3P в устранении этой проблемы. Если кто-то еще захочет разобраться в этом, не стесняйтесь: https://github.com/p3p/pio-framework-arduino-lpc176x/blob/master/system/lpc176x/HardwarePWM.h

Есть эта проблема.
Ender 3, SKR Mini E3 v1.2, подлинный BLTouch v3.1

SKR Mini E3 v1.2 использует микроконтроллер STM32, а не LPC1768.

Интересно, связана ли проблема с фиксацией ШИМ со следующими ошибками LPC176x:

3.13 PWM.1: При обновлении рабочего цикла для PWM1.1 со 100% в
в некоторых случаях выходной сигнал может оставаться низким в течение всего периода ШИМ перед
обновление вступает в силу
Введение:
На периферийном устройстве LPC176x PWM два регистра соответствия могут использоваться для обеспечения одного
выход ШИМ с контролем фронта. Один регистр совпадения (PWM1MR0) управляет циклом ШИМ
рейтинг, обнуляя счетчик матча. Другой регистр соответствия управляет фронтом ШИМ.
должность. Например, регистр совпадения PWM1MR1 управляет положением края PWM1.
Все выходы PWM с одним фронтом управления будут иметь нарастающий фронт в начале
каждый цикл PWM, когда происходит совпадение PWM1MR0.
Проблема:
Только в однонаправленном режиме, если рабочий цикл для PWM1.1 (широтно-импульсный модулятор 1, канал
1 выход) обновляется со 100% (PWM1MR1 = PWM1MR0), затем выход для PWM1.1
может неожиданно оставаться на низком уровне в течение полного периода ШИМ перед новым желаемым рабочим циклом
вступает в силу. Эта проблема влияет только на вывод для PWM1.1. Другие каналы ШИМ
(PWM1.2 - PWM1.6) не подвержены этой проблеме.
Обход:
Может быть реализовано программное исправление, при котором пользователь может загрузить PWM1MR1 с помощью
PWM1MR0 + 1 (минимум 1), чтобы избежать задержек в обновлении вывода PWM1.1.

Я полагаю, что это не так, поскольку я бы не подумал, что мы когда-либо переводим серво штырь в режим 100% PWM.

Опять же, в PWM 1.1 используется P2_0, который является серво штифтом на SKR 1.3 ...

Я изучал аналогичную проблему (с подлинным BL Touch 3.1 и SKR PRO 1.1).
Я задокументировал то, что нашел в # 16986, но в основном я обнаружил, что мое было связано с XY_PROBE_SPEED. Цифра 10000 приводит к тому, что сигнал BL Touch изменяется с импульсного на уровень постоянного тока в точке 15 зондирования (которая также является первой после первого движения Y), цифра 6000 для меня не показала никаких проблем.

Я тестировал этот обходной путь более месяца на двух Ender 3 с SKR v1.3 и 3D Touch v2 (и Pi 3B). Раньше у меня всегда были регулярные отказы при выполнении ABL (по крайней мере, 1 из 3-5 отпечатков), когда датчик не срабатывал (но сразу мигал красным) и сопло врезалось в кровать, если бы не механический конец Z -стоп Я уехал специально. И я перепробовал большинство, если не все, перестановок конфигураций зондирующего / BL Touch в Marlin 2.0.x.
Поскольку в течение этих недель у меня было 0 отказов во время бесчисленных проверок (как M48, так и многие фактические отпечатки), я должен считать этот обходной путь очевидным успехом в моем случае. Я, конечно, обновлю свои выводы, если результаты изменятся.
Я также проверил, что он работает независимо от скорости зонда XY (пробовал 6-8-10000 мм / с), скорости зонда Z и без отключения нагревателей / шаговых двигателей во время зондирования. По сути, настройка зондирования в Marlin больше не кажется фактором для предотвращения сбоев (но все же может влиять на точность, по крайней мере, скорость Z).
Единственная проблема заключается в том, что подсветка ЖК-дисплея (5 В) временно мигает во время зондирования, если его 5 В поступают из SKR, что, вероятно, указывает на падение напряжения из-за потребления тока зондом (но я не хотел изолировать и исследовать все это с помощью моего прицела) . Таким образом, вместо этого я подключил 5 В к Pi (но с таким же успехом может быть любой внешний источник 5 В) с двумя проводами GND, соединенными рядом с датчиком, один идет к SKR, а другой - к Pi (для звездного заземления бедняка) .

@mlehnhoff
Пожалуйста, проверьте ветку bugfix-2.0.x, чтобы узнать, где она находится.

Вскоре я буду тестировать это на своем подлинном BLTouch, думаю, у меня такая же проблема.

Изменить: не та же плата (STM32F103RC), но одинаковые проблемы! Пытаюсь выяснить, проблема ли это в сроках или что-то еще! Но при выполнении сетки 91 UBL я получаю, возможно, 1 или 2 неисправных зонда, как описано здесь?

Я понял, что моя плата, похоже, использует «общий» сервокод. Я добавил ниже после некоторых проб и ошибок, и кажется safe_delay 6 мс / нас? работает! Кажется, что датчик срабатывает быстрее, если в этом есть смысл? И мне удалось получить свою первую сетку без сбоев датчика? Будем следить за ним и проводить больше тестов, но поначалу выглядит многообещающе! Это настоящий BLTouch, я заказал второй, думая, что он неисправен! Я не думаю, что это другое оборудование, поскольку эта установка работала нормально на исходной стандартной плате, только после перехода на BTT V2.0 и Marlin возникла эта проблема. Раньше я без проблем запускал Klipper.

if ( (servoIndex == 0) && ( extDigitalRead(SERVO0_PIN) == 1 ) ) { safe_delay(6); }

@ aslater3 Как я могу узнать, имеет ли моя плата (SKR Mini E3 v1.2) «общий» сервокод?

@boelle, извини, я был очень занят разными вещами. Я только что протестировал последнюю версию bugfix-2.0.x (которая выглядит как 2.0.5.4). Проблема все еще существует. Это потому, что это все еще не исправлено в pio-framework-arduino-lpc176x.
Но теперь у меня есть доступ к осциллографу, и я готов исследовать его дальше (и в конечном итоге исправить) ...

2.0.5.4 ( 2.0.x ) и bugfix-2.0.x - две разные ветки. Пожалуйста, попробуйте последнюю версию bugfix-2.0.x и сообщите нам, если у вас по-прежнему возникает эта проблема.

2.0.5.4 ( 2.0.x ) и bugfix-2.0.x - две разные ветки. Пожалуйста, попробуйте последнюю версию bugfix-2.0.x и сообщите нам, если у вас по-прежнему возникает эта проблема.

Да, я знаю, и я использовал последнюю версию bugfix-2.0.x! 2.0.5.4 - это только то, что мне говорит ЖК-меню

Но это в любом случае не имеет значения, потому что ошибка находится не внутри кода MarlinFw, а внутри pio-framework-arduino-lpc176x

Хорошо даже известно, какая часть кода вызывает проблему: отключенная фиксация HW-PWM.

Проблема в том, чтобы найти способ снова включить фиксацию без других проблем. По этой причине фиксация отключена.

Я болтал об этом с @ p3p , так как я исследовал подобные проблемы на других платформах. Я не думаю, что есть шанс, что это поведение было изменено, и на самом деле не стоит предпринимать усилия для повторного тестирования прямо сейчас, если только это не является частью фактической реализации более постоянного решения.

2.0.5.4 - это только то, что мне говорит ЖК-меню

Значит, вы не используете последнее исправление. На ЖК-дисплее отобразится bugfix-2.0.x .

Мне известно о сбое с периодом 1 при установке более короткого рабочего цикла после того, как уже было передано новое значение соответствия, в настоящее время я не уверен, как решить эту проблему. Аппаратное обеспечение, похоже, не выполняет то, что должно делать, когда включены теневые регистры pwm.

2.0.5.4 - это только то, что мне говорит ЖК-меню

Значит, вы не используете последнее исправление. На ЖК-дисплее отобразится bugfix-2.0.x .

хорошо, моя проблема, я случайно клонировал ветку 2.0.x вместо bugfix-2.0.x ... теперь я исправил это -> без разницы (конечно)

Мне известно о сбое с периодом 1 при установке более короткого рабочего цикла после того, как уже было передано новое значение соответствия, в настоящее время я не уверен, как решить эту проблему. Аппаратное обеспечение, похоже, не выполняет то, что должно делать, когда включены теневые регистры pwm.

@ p3p Не могли бы вы рассказать мне, с какими проблемами вы столкнулись, когда у вас была включена фиксация?

Из того, что я помню (прошло много времени с тех пор, как я это отлаживал), при включенных теневых регистрах ширина импульса иногда вообще не обновлялась, как вы можете себе представить, я выбрал 1-периодный сбой, а не этот. Возможно, это было вызвано обновлением ширины импульса более одного раза за тот же период, но я не был уверен.

Заданный угол сервопривода должен оставаться не менее 20 мс, чтобы его можно было увидеть на выходе в виде измененной ширины импульса.
Чтобы устройство / сервопривод могло распознать новую ширину импульса, вероятно, потребуется выдержать несколько импульсов.
Поэтому изменение угла в течение как минимум 20 мс должно быть запрещено.
Из того, что @sjasonsmith обнаружил для BL_Touch и указал в https://github.com/MarlinFirmware/Marlin/issues/18598#issuecomment -657406598, лучше примерно на 60 мс.

Чаще обновлять теневой регистр не имеет смысла. Регистр не следует записывать чаще, чем изменяется значение угла. (Теневая переменная для теневого регистра?)
Скорее всего, потребуется дополнительный патч на более высоком уровне библиотеки сервопривода, чтобы предотвратить слишком частые изменения. У нас уже есть нечто подобное с SERVO_DELAY , изначально предназначенное для предотвращения отключения серво сигнала до того, как сервопривод (механически) достигнет своей цели.

@AnHardt Я знаю, что изменение теневых регистров несколько раз за период бессмысленно, но я не понимаю, почему изменение их несколько раз до того, как значения будут помещены в реальные регистры в конце периода, вызовет проблему, я не уверен, что решение остановить клиентское приложение, слишком часто обновляющее аппаратный ШИМ, могло бы быть (если это действительно проблема) без значительного снижения производительности тем или иным образом.

@AnHardt Я знаю, что изменение теневых регистров несколько раз за период бессмысленно, но я не понимаю, почему изменение их несколько раз до того, как значения будут помещены в реальные регистры в конце периода, вызовет проблему,

Я также не знаю, почему и есть ли проблема. Но если вы сообщите нам, что это вызывает проблемы, мы должны постараться избежать этого.
Конструкция вроде:

static float last_servo_angle = 0.0f;
if (servo_angle != last_servo_angle) {
  set_servo(sevo_angle);
  last_servo_angle = servo_angle;
}

по крайней мере, предотвратит многократную запись в теневой регистр одного и того же значения.

Если я правильно помню, в последний раз, когда я касался кода SERVO_PROBE, до появления BL-Touch, я тщательно избегал одновременного перемещения сервопривода и шаговых двигателей с синхронизацией, но я всегда тестировал с помощью DEACTIVATE_SERVOS_AFTER_MOVE , потому что мои сервоприводы дрожали, когда шаговый двигатель двигался, создавая паузу SERVO_DELAY (несколько сотен мс) после установки servo_angle. По сравнению с этим гораздо более короткие задержки, которые я предлагаю сейчас, являются выигрышем в производительности.

Если код BL-Touch пытается перемещать сервопривод и шаговые двигатели одновременно, это не кажется мне мячом, в который я должен играть.

Поскольку BL-Touch хотят иметь постоянно включенный серво сигнал, DEACTIVATE_SERVOS_AFTER_MOVE невозможно. Для библиотек сервоприводов, управляемых прерываниями, отложенное прерывание стало катастрофическим, испортив сервосигнал. Аппаратно управляемый ШИМ будет невосприимчивым. Обычно сервопривод один.

Однако я совершенно уверен, что set_servo(0); set_servo(180); set_servo(0); без пауз не вызовет абсолютно никакой реакции - ни на реальном сервоприводе, ни на BL-Touch.

Сожалею. Скорее всего, мои мысли в большей степени сосредоточены на аппаратном ШИМ, на данный момент, когда регистр сравнения таймеров должен обновляться только время от времени.

Сожалею. Скорее всего, мои мысли в большей степени сосредоточены на аппаратном ШИМ, на данный момент, когда регистр сравнения таймеров должен обновляться только время от времени.

Эта проблема связана с аппаратным ШИМ, и я согласен со всем, что вы сказали, я просто думал о проблеме на уровне фреймворка, например, о том, как заставить оборудование работать надежно, даже когда клиентское приложение выполняет сумасшедшее количество обновлений (Марлин ) в тот же период. Клиент будет ожидать, что последнее обновление вступит в силу, а не первое, и я не могу знать, что до конца периода не будет последующих обновлений.

Мне нужно еще раз взглянуть на проблему, чтобы увидеть, придет ли мне в голову новое решение, и действительно ли этот диагноз верен, и я не просто был глупцом.

Я бы попробовал
когда на короткие длительные позиции можно не указывать:

servo_update(angle) only updates a volatile variable lets say inter_angle.

an interrupt, either overflow or compare could be:
{  
  static uint32_t counter = 0;
  static uint16_t last_inter_angle = 0;
  if (counter++ > 3) { // if counter should overflow there is a small risk of delaying another 3*20 ms. Every ~55min if 16 bit.
    if (inter_angle != last_inter_angle) { // if counter above 3 the update will be immediate when inter_angle changed.
      update_shadow_compare_register(inter_angle);
      counter = 0;
      last_inter_angle = inter_angle;
    }
  }
}

работает примерно каждые 20 мс.
Это должно поддерживать постоянную длину выходных импульсов не менее 3 * 20 мс, а затем вводить только последний заданный угол. Однако он не будет знать, какой угол будет следующим, и последует ли обновление вообще - это невозможно знать - иногда вам придется начать. Это гарантирует, что отправляемые импульсы могут быть прочитаны, а теневой регистр не обновляется очень часто.

Чтобы гарантировать, что каждое обновление выполняется хотя бы в течение этого времени, изменчивая переменная должна быть заменена очередью.

В RC-полете промежуточные положения, вероятно, можно не использовать. В случае BL-Touch установка, развертывание, сброс, change_modes, ... все одинаково важны. Об этом можно не говорить, ведь каждая команда должна оставаться достаточно долго, чтобы ее можно было распознать. Универсального правильного решения для универсальной библиотеки сервоприводов не существует.

Кроме того, для BL-Touch все команды должны быть синхронизированы с шаговыми движениями. Лучше не убирать зонд при спуске для зонда. :-)
Так что, с моей точки зрения, Марлин должен нести ответственность за то, чтобы не обновлять угол до частого.

Редактировать:
Вероятно, прерывание сравнения является правильным для обновления регистра теневого сравнения. Тогда прерывание может быть задержано прерываниями с более высоким приоритетом примерно на 17 мс, и все еще будет время, чтобы регистр обновления был готов для копирования в регистр сравнения, когда произойдет переполнение.
Должна быть возможна остановка прерывания, если счетчик выше 3. Может ли быть перезапущен при обновлении inter_angle.

У меня такая же проблема с SKR mini 1.1.
Независимо от того, какое положение я поставил, сервопривод всегда идет в одну и ту же точку.

https://www.youtube.com/watch?v=HVyaKdpJsP0

@Matheusschmitz SKR mini использует другую платформу и будет уникальным в этом выпуске. Некоторые изменения были внесены чуть больше недели назад для повышения надежности BLTouch для плат STM32F1 (например, вашей). Попробуйте использовать ветку bugfix-2.0.x, чтобы узнать, решит ли она вашу проблему.

Если у вас все еще есть проблемы, обратитесь к одному из центров поддержки, например в Discord. Эта конкретная проблема должна оставаться в центре внимания плат LPC176x.

Я также столкнулся с этой проблемой с моим клоном SKR1.3 и BLTouch.
Мне удалось запечатлеть это на видео, примерно на отметке 1:54:
https://www.youtube.com/watch?v=wF0Mia49ECI&t=114s
(видео 1080p YouTube должен его обработать)

Вот также изображение, показывающее, что он делает, когда это происходит во время UBL.

Я пробовал, как и другие, различные настройки, которые могли помочь, но они не помогли.
Я использую последнюю ветку bugfix-2.0.x

Та же проблема с моей стороны.
Я также протестирую обходной путь

Эта проблема не использовалась в течение последних 30 дней. Добавьте ответ, если вы хотите, чтобы проблема оставалась активной, иначе она будет автоматически закрыта в течение 7 дней.

Я думаю, что это стоит держать открытым, пока не будет найдено постоянное решение.

Я согласен с этим мнением

Эта проблема не использовалась в течение последних 30 дней. Добавьте ответ, если вы хотите, чтобы проблема оставалась активной, иначе она будет автоматически закрыта в течение 7 дней.

Думаю, этот вопрос следует оставить открытым.