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 clone BLTOUCH_FORCE_MODE_SET . إنها ليست "ذكية".

ولا ، ليس لدي وصول إلى 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 الخاص). يجب أن تعمل SERVOS مثل الماكينات.

لكنني أعتقد أنه يجب إصلاح هذه المشكلة على أي حال ، لأنني أعتقد أنه حتى المؤازرة الفعلية يمكن أن تتفاعل مع هذا النبض بهزة قصيرة أو أي سلوك غريب آخر.
(من تعليق mlehnhoff )

لا ينبغي إلقاء اللوم على أجهزة التحقيق. الإشارة الصادرة من اللوحة غير صحيحة ، وتم التحقق منها باستخدام راسم الذبذبات. يجب إصلاح ذلك.

يمكنني أيضًا أن أؤكد أن السلوك المُبلغ عنه مشابه جدًا لأجهزة BLTouch الأصلية عندما كنت أقوم بتصحيح كل تعارضات المؤقت التي تسبب مشكلات مماثلة على لوحات SKR Mini E3. يبدو أن أطوال النبض غير الصالحة تسببت في أن تنسى BLTouch ببساطة ما كانت تفعله وتسببت في الفشل.

mlehnhoff ، هل التقطت أي صور من مرسمة الذبذبات توضح المشكلة ، والتي يمكنك إرفاقها بهذه المشكلة؟

لا أعتقد أنني أحب الحل الحالي كحل كامل ، لكنني أقدر حقًا مستوى التفاصيل المقدمة من mlehnhoff التي تصف المشكلة والحل البديل الذي يوضح أن النبض هو السبب الجذري للمشكلة على ما يبدو.

عذرًا ، لم أقم بتقديم لقطة شاشة على الفور. اعتقدت أنني قمت ببعضها ، لكن حدث خطأ ما. لكني لم أدرك حتى أعادت النطاق (ليس لي).
لكن الآن قمت بعمل واحد جديد:

في الصورة ترى الانتقال من 1472 إلى 544 درجة ، ولكن الأول جديد

النبض هو 20544 μs.

بالإضافة إلى أنني جربت مؤازرة فعلية وإليك الدليل ، أن هذه المشكلة لا تقتصر فقط على 3dtouch أو النسخ الأخرى.

IMG_4677.zip

يجب أن يتحول المؤازر من 90 درجة (رافعة في المنتصف) إلى 0 درجة (رافعة لأسفل) ، ولكن عندما يحدث النبض الخاطئ ، فإنه يظهر بالفعل في البداية ، قبل أن ينخفض.

بالمناسبة ، هناك ما لا يقل عن ثمانية إصدارات مختلفة من bltouch الأصلي (كلاسيكي 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 فولت. يوجد محول باك بجهد 5 فولت متصل بمصدر طاقة بجهد 12 فولت يعمل على تشغيل BLTouch ، لذلك لا تحصل BLTouch على الطاقة حتى يتم تشغيل مزود الطاقة 12 فولت.
عندما يتم تشغيل اللوحة ، يومض BLTouch باللون الأحمر - يبدو هذا طبيعيًا إلى حد ما إذا تلقت BLTouch إشارة قبل تشغيلها ، لذلك لست قلقًا بشأن ذلك.
ومع ذلك ، فإن أي محاولة لإعادة تعيينه باستخدام M280 P0 S160 ليس لها أي تأثير على الإطلاق. كما أنه لا يسحب الدبوس إذا تم نشره.
ومع ذلك ، يتحول M280 P0 S60 بنجاح إلى وضع SW ويوقف أيضًا الوميض.
بخلاف الوميض و S160 الذي يتم تجاهله على ما يبدو ، يبدو أن BLTouch يعمل بشكل مثالي. حتى عند الوميض ، يتم نشره وتخزينه وتحقيقاته بشكل صحيح - لقد قمت بإجراء تحقيقات سرير كامل ولم أر قط فشلًا في المسبار وإمكانية التكرار ممتازة.
هذا V3.1 BLTouch أصلي - وليس نسخة.

نسيت أن أذكر أنني تحققت من النبضات باستخدام كل من DSO الصغير الرخيص وجهاز الذبذبات CRT الكبير الخاص بي ويبدو أن أطوال النبضات تبدو جيدة. لقد جربت أيضًا قيم S مختلفة (من 155 إلى 165) دون العثور على قيمة تؤدي إلى إعادة التعيين.

لم أبحث عن كيفية عمل مكتبة المؤازرة الخاصة بـ LPC - لكن:
إشارة المؤازرة هي PWM. إذا تم تحقيق ذلك باستخدام مؤقت أجهزة STM32 ، فمن المحتمل أن يكون سبب هذا الخطأ هو تحديث العدادات مقارنة التسجيل مباشرةً ، بدلاً من تحديث القيمة الجديدة إلى سجل التحميل المسبق لسجل المقارنة. في حالة تغيير سجل المقارنة من قيمة عالية إلى قيمة منخفضة بينما يكون العداد بين القيمة المنخفضة والقيمة العالية ، يتم تخطي المقارنة (المتساوية) ، ولا يتم تغيير الدبوس حتى تجاوز العداد ثم يصل إلى القيمة الجديدة . إذا تم استخدام سجل التحميل المسبق ، فسيتم تحديث سجل المقارنة إما عند تجاوز العداد ، أو عندما تكون قيمة المقارنة (القديمة) متطابقة. هذا لا ينطوي على خطر حدوث نبض طويل ، فقط تأخير محتمل بحد أقصى حوالي PWM-periode (20 مللي ثانية).
تحرير: ستكون فرصة الخطأ 5٪ لكل تخطي 1 مللي ثانية للخلف.
أفترض ، هنا لدينا شيء مشابه.

هذا لأن إطار عمل lpc لا يقوم بتشغيل pwm للأجهزة في وضع الإغلاق ، (حيث يتم تظليل سجل النطاق النبضي وإغلاقه في كل فترة) ، يجب أن يكون من الممكن القيام بذلك باستخدام وضع بسيط .. ولكن للأسف لا أستطيع اجعله يعمل بشكل موثوق به ، فالاختيار بين فترة خلل محتملة لفترة واحدة ، أو عرض النبضة عشوائيًا (ولكن بشكل متكرر اعتمادًا على عدد مرات تحديثه) لا يتغير على الإطلاق.

يمكن إجراء مزيد من البحث حول هذه المسألة ، لكنها في الحقيقة ليست طرفيًا معقدًا ، فقد أهدرت وقتًا طويلاً في هذا الخلل وفي النهاية احتاجت أشياء أخرى إلى الاهتمام.

mlehnhoffkockockockoc كيف موانئ دبي تطبيق التصحيح من فضلك؟

mlehnhoffkockockockoc كيف موانئ دبي تطبيق التصحيح من فضلك؟

لأكون صادقًا ، أنا جديد تمامًا على git وأنا سعيد للغاية ، لأنني تمكنت من إنشاء هذا التصحيح عبر "git diff". أنا متأكد من أنه يجب أن يكون هناك أمر git مختلف لتطبيق هذا التصحيح مرة أخرى. ربما يستطيع kockockoc المساعدة ...
ولكن بالنسبة لهذا الجزء الصغير جدًا من التعليمات البرمجية ، يمكنك القيام بذلك يدويًا. الأمر سهل مثل إضافة الأسطر الأربعة التي تبدأ مع "+" إلى ملف "Marlin / src / HAL / HAL_LPC1768 / Servo.h" (بالطبع بدون "+") في الموضع المعروض ...

مرحبًا ، لدي نفس اللوحة Bigtreetech SKR v1.3 و 3D Touch لكن 3D Touch لا يعمل. لقد اختبرت 3dTouch باستخدام بعض التعليمات البرمجية في Arduino Mega وتعمل بشكل مثالي. لذلك ، لقد جربت أي اقتراح وجدته وأيضًا التصحيح mlehnhoff ولكن ما زلت أواجه نفس المشكلة = 3D Touch
أنا قلق حقًا بشأن ذلك لأنني لا أعرف ما يجب علي فعله لحل هذه المشكلة. أهلا وسهلا بأي اقتراح.

أظن أن هذا الخطأ هو نفسه الذي أبلغت عنه هنا: https://github.com/MarlinFirmware/Marlin/issues/15370

ما زلت أقوم بتشغيل التزام إصلاح الأخطاء من 22/6/19 بدون مشاكل. لقد جربت أحدث التزام لإصلاح الأخطاء اليوم وما زالت مشكلة المؤازرة موجودة.

@ Reywas62 والجميع ، لقد وجدت هذه المقالة http://fightpc.blogspot.com/2019/08/testing-skr-13-board-with-marlin-20x.html التي يمكن أن تحل المشكلة. يمكن أن تحتوي بعض لوحات SKR على إشارة خرج ذات مقاومة منخفضة (حوالي 200 أوم) تتطلب قدرًا كبيرًا من التيار للعمل بشكل صحيح (ولا يحدث ذلك على لوحات Arduino ، وهذا هو السبب في أن مسبار اللمس ثلاثي الأبعاد الخاص بي يعمل بشكل صحيح على Arduino) لذلك ، يبدو أنه لا يتعلق بالبرامج الثابتة.

حسنًا ، سأشتري هذا التفسير باستثناء أن لوحتي تعمل بشكل جيد مع التزام سابق لـ Marlin bugfix 2.0.x (6/22/19).

أستطيع أن أؤكد أن الحل "السريع القذر" من mlehnhoff يعمل. لقد قمت بفحص 9x9 UBL-Mesh باستخدام BLTouch Clone. عادةً ما تفشل نقطة أو نقطتان من شبكة 81 نقطة عند تشغيل إنشاء الشبكة. ولكن مع "الإصلاح" كل شيء يعمل بشكل جيد. لذلك سأستمر في استخدام هذا الحل. وفي حالتي ، أعتقد أنها مشكلة في نبضة المؤازرة الطويلة لأن دبوس الدفع الخاص بي يتم نشره ولا يتم تشغيل المستشعر.

أود أن أؤكد أن مشكلتي مع 3D Touch قد تم حلها. المشكلة هي التيار المنخفض لدبابيس SKR 1.3 Servo. لقد صنعت الدائرة واختبرتها بنجاح. لقد تلقيت الآن هذه المعلومات بعد تشغيل 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 pre V3.1 (أو متوافق)

سأقوم بتجربة الإعداد الخاص بي هنا ، لكن لدي محرك مؤازر SG90 و MG90 يتحرك بشكل متقطع مرة أخرى عند التعطيل. نظرًا لأنه يمسك بمفتاح Z-Probe ، فإن هذا النوع من الموت يقتل الجهاز عندما يصطدم بالسرير. بلغ إجمالي الانهيار الأخير حوامل عجلة Creality CR10 S5. > _

عندما تسنح لي الفرصة ، سأجرب الحلبة وأرى ما إذا كانت ستفرز ذلك. ولكننا سنحاول أيضًا اختراق البرامج الثابتة. :)

بعد تجربة اختراق البرامج الثابتة ، لم يكن هناك أي تغيير بالنسبة لي (كما كنت أظن ، حيث أن الاختراق يعمل على إصلاح نسخ bl-touch ، وليس بالضرورة حركة مؤازرة). سيظل المؤازر في بعض الأحيان يتحرك للخلف بعد إكمال الحركة.

بالنظر إلى ذلك ، قمت بفك الاختراق وأخبرت مارلين بعدم تعطيل المؤازرة ويبدو أن مشكلة التراجع قد ولت. يبدو كما لو أن تعطيل المؤازرة يؤدي إلى مشكلتي. لحسن الحظ ، لا يُظهر MG90 الذي أستخدمه أي اهتزاز / اهتزاز على الزوايا التي حددتها. :)

أود بالتأكيد أن أشكر mlehnhoff على كودهم لاختباره. في كل مرة أقوم بتشغيلها ، كانت المؤازرة تعمل 3 أو 4 مرات ، وعندما أخبرت مارلين بإبقاء المؤازرة ممكّنة ، كان البرنامج النصي يعمل بشكل جيد 3 مرات على التوالي. بالنظر إلى تقارير التيار المنخفض ، أجريت أيضًا الاختبار مع السخانات لوضع PSU تحت الحمل. :)

لا أعرف ما إذا كان ذلك مهمًا ، لكن زوايا المؤازرة الخاصة بي هي 172 (منتشرة) و 35 (مخزنة) ويبدو أنها ستحرك المؤازرة للخلف ، بنفس المقدار في كل مرة. المؤازرة لم تتحرك إلى الأمام.

لم يُصلح اختراق البرامج الثابتة مشكلتي ، لكن ترك المؤازرة ممكّنة يوقف السيرفو عن سوء التصرف ، كما حدث في DarkAlaranth. ليس حلاً حقًا ، ولكنه حل مقبول.

خلفية إضافية قليلاً لقد جربت هذا على عدة منصات على مدار اليومين الماضيين واعتقدت أنني ربما كسرت كل من AntLab BLtouch الخاص بي ، لذلك طلبت الثالثة.

هذا ما لاحظته في الأنظمة الأساسية التالية
فشل SKR Pro V1.1 في العمل
فشل SKR v1.3 في العمل
RAMPS 1.4 فشل في العمل
SKR v1.4 فشل في العمل
فشل RAMPS 1.6 في العمل

قراءة الأعراض قبل التحقيق على M119
الإبلاغ عن حالة endstop
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 أصلية.

هل تغير شيء ما في التكوين؟ يحتوي config_adv.h الآن على مجموعة من إعدادات طاقة BL touch.

هل يجب أن يكون هناك تقرير عن درجة الحرارة عند توجيه المحور 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
تختلف الأسلاك الخاصة بـ skr1.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 ، لأنه لا يعمل بشكل صحيح. لذلك ، طالما لم يتم إصلاح هذا ، يجب على كل شخص يريد أن يكون لديه bltouch يعمل بشكل موثوق أن يستخدم الحل القبيح ولكن العملي.
في الوقت الحالي ، للأسف لا يمكنني الوصول إلى Oscilloscope ، وإلا أود دعم 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.

أتساءل عما إذا كانت مشكلة إغلاق PWM مرتبطة بأخطاء LPC176x التالية:

3.13 PWM.1: عند تحديث دورة العمل لـ PWM1.1 من 100٪ ، في
في بعض الحالات ، يمكن أن يظل الناتج منخفضًا لفترة PWM كاملة قبل
التحديث ساري المفعول
المقدمة:
على الطرفية LPC176x PWM ، يمكن استخدام سجلين مطابقة لتقديم واحد
إخراج PWM المتحكم فيه. يتحكم سجل المباراة الواحدة (PWM1MR0) في دورة PWM
المعدل ، عن طريق إعادة العد عند المباراة. يتحكم سجل المباراة الآخر في حافة PWM
موضع. على سبيل المثال ، يتحكم سجل المطابقة PWM1MR1 في موضع حافة PWM1.
سيكون لكل من مخرجات PWM المتعددة التي يتم التحكم فيها من خلال حافة واحدة حافة صاعدة في بداية
كل دورة PWM ، عندما تحدث مباراة PWM1MR0.
مشكلة:
فقط في وضع الحافة الواحدة ، إذا كانت دورة العمل لـ PWM1.1 (Pulse Width Modulator 1 ، channel
خرج 1) من 100٪ (PWM1MR1 = PWM1MR0) ، ثم خرج PWM1.1
يمكن أن تظل منخفضة بشكل غير متوقع لفترة PWM كاملة قبل دورة العمل الجديدة المطلوبة
ساري المفعول. تؤثر هذه المشكلة فقط على إخراج PWM1.1. قنوات PWM الأخرى
(PWM1.2 إلى PWM1.6) لا تتأثر بهذه المشكلة.
عمل حول:
يمكن تنفيذ إصلاح البرنامج حيث يمكن للمستخدم تحميل PWM1MR1 معها
PWM1MR0 + 1 (على الأقل 1) لتجنب أي تأخير في تحديث إخراج PWM1.1.

أتوقع أنه ليس كذلك ، لأنني لا أعتقد أننا وضعنا دبوسًا مؤازرًا في وضع PWM بنسبة 100٪.

ثم مرة أخرى ، على 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.
نظرًا لأنه لم يكن لدي أي إخفاقات أثناء التحقيقات التي لا حصر لها خلال هذه الأسابيع (كل من M48 والعديد من المطبوعات الفعلية) ، يجب أن أعتبر هذا الحل نجاحًا واضحًا في حالتي. سأقوم بالطبع بتحديث نتائجي إذا تغيرت النتائج.
لقد اختبرت أيضًا أنه يعمل بشكل مستقل عن سرعة مسبار XY (تجربة 6-8-10000 مم / ثانية) ، وسرعة مسبار Z وبدون تعطيل السخانات / السائر أثناء التحقيق. في الأساس ، يبدو أن إعداد الفحص في Marlin لم يعد عاملاً لتجنب الفشل (ولكن قد يظل يؤثر على الدقة ، على الأقل سرعة Z).
المشكلة الوحيدة هي أن الإضاءة الخلفية لشاشة LCD (5 فولت) يومض مؤقتًا أثناء التحقيق إذا تم سحب 5 فولت من SKR ، مما يشير على الأرجح إلى انخفاض الجهد بسبب الاستهلاك الحالي للمسبار (ولكن لم يرغب في عزل كل شيء والتحقيق فيه من خلال النطاق الخاص بي) . وبالتالي ، قمت بتوصيل 5 فولت إلى Pi بدلاً من ذلك (ولكن يمكن أيضًا أن يكون أي مصدر خارجي 5 فولت) مع سلكين GND مقسمين بالقرب من المسبار ، أحدهما يمتد إلى SKR والآخر يمتد إلى Pi (لأرض نجم فقير) .

تضمين التغريدة
الرجاء اختبار فرع bugfix-2.0.x لمعرفة مكانه.

سأختبر هذا قريبًا على BLTouch الأصلي ، وأعتقد أن لدي نفس المشكلة.

تحرير: ليست نفس اللوحة (STM32F103RC) ولكن مشاكل متطابقة! أحاول معرفة ما إذا كانت مشكلة توقيت أم شيء آخر! ولكن عند إجراء 91 شبكة UBL ، ربما أحصل على تحقيق واحد أو اثنين فاشلين بنفس الطريقة الموضحة هنا؟

حسنًا ، اكتشفت أن لوحي يبدو أنه يستخدم رمز المؤازرة "المشترك". لقد أضفت ما يلي بعد بعض التجارب والخطأ ويبدو أنه تأخر آمن قدره 6 مللي ثانية / لنا؟ يعمل! يبدو أن المستشعر يعمل بشكل أسرع إذا كان ذلك منطقيًا؟ وقد تمكنت الآن من الحصول على شبكتي الأولى دون فشل أي جهاز استشعار؟ سوف تراقبها وتجري المزيد من الاختبارات ولكن في البداية تبدو واعدة! هذا مع BLTouch حقيقي ، كنت قد طلبت الثاني معتقدًا أنه كان معيبًا! لا أعتقد أن أجهزتها الأخرى لأن هذا الإعداد كان يعمل بشكل جيد على لوحة الأسهم الأصلية ، فقط منذ الانتقال إلى BTT V2.0 وحدثت Marlin هذه المشكلة. في السابق كنت أدير كليبر بدون مشاكل.

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

@ aslater3 كيف يمكنني معرفة ما إذا كان

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 هو فقط ما تخبرني به قائمة LCD

لكن هذا لا يهم على أي حال ، لأن الخطأ ليس داخل كود MarlinFw بل هو داخل pio-framework-arduino-lpc176x

من المعروف جيدًا أي جزء من الكود يسبب المشكلة: تعطيل قفل HW-PWM.

تكمن المشكلة في إيجاد طريقة لإعادة تمكين الإغلاق دون مواجهة مشاكل أخرى. لهذا السبب تم تعطيل الإغلاق.

كنت أتحدث مع @ p3p حول هذا الأمر ، لأنني كنت أقوم بالتحقيق في مشكلات مماثلة على الأنظمة الأساسية الأخرى. لا أعتقد أن هناك أي فرصة لتغيير هذا السلوك ، ولا يستحق الأمر حقًا بذل جهد لإعادة الاختبار في الوقت الحالي ، إلا إذا كان ذلك جزءًا من التنفيذ الفعلي لحل دائم.

2.0.5.4 هو فقط ما تخبرني به قائمة LCD

فأنت لا تستخدم أحدث إصلاح للأخطاء. ستظهر شاشة LCD الخاصة بك bugfix-2.0.x .

إنني على علم بخلل الفترة الأولى عند تعيين دورة عمل أقصر بعد تجاوز قيمة المطابقة الجديدة بالفعل ، ولست متأكدًا حاليًا من كيفية تخفيف المشكلة. لا يبدو أن الجهاز يقوم بما يفترض به القيام به عند تمكين سجلات الظل pwm.

2.0.5.4 هو فقط ما تخبرني به قائمة LCD

فأنت لا تستخدم أحدث إصلاح للأخطاء. ستظهر شاشة LCD الخاصة بك bugfix-2.0.x .

حسنًا ، يا سيئ ، لقد قمت باستنساخ الفرع 2.0.x بشكل غير مقصود بدلاً من bugfix-2.0.x ... الآن أصلحت ذلك -> لا فرق (بالطبع)

إنني على علم بخلل الفترة الأولى عند تعيين دورة عمل أقصر بعد تجاوز قيمة المطابقة الجديدة بالفعل ، ولست متأكدًا حاليًا من كيفية تخفيف المشكلة. لا يبدو أن الجهاز يقوم بما يفترض به القيام به عند تمكين سجلات الظل pwm.

@ p3p هل يمكن أن تخبرني ، ما هي المشكلات التي واجهتها ، عندما تم تمكين الإغلاق؟

مما أتذكره (لقد مر وقت طويل منذ أن كنت أقوم بتصحيح هذا) ، مع تمكين سجلات الظل ، لن يتم تحديث عرض النبض بشكل متقطع على الإطلاق ، كما يمكنك أن تتخيل أنني اخترت فترة خلل الفترة الأولى بدلاً من ذلك. يبدو أنه من المحتمل أن يكون سبب ذلك هو تحديث عرض النبضة أكثر من مرة في نفس الفترة ولكني لم أكن متأكدًا.

يجب أن تظل زاوية المؤازرة الموجهة 20 مللي ثانية على الأقل لتكون مرئية على الإخراج كعرض نبض متغير.
لجعل عرض النبضة الجديد يمكن التعرف عليه بواسطة الجهاز / المؤازرة ، من المحتمل أن يحتاج إلى عدة نبضات.
لذلك يجب حظر تغيير الزاوية في غضون 20 مللي ثانية على الأقل.
من ما اكتشفهsjasonsmith لـ BL_Touch وأشار في https://github.com/MarlinFirmware/Marlin/issues/18598#issuecomment -657406598 بشكل أفضل حول 60 مللي ثانية.

تحديث سجل الظل في كثير من الأحيان لا معنى له. لا ينبغي كتابة السجل أكثر من تغيير قيمة الزاوية. (متغير الظل لسجل الظل؟)
من المحتمل أنه يحتاج إلى تصحيح إضافي على مستوى أعلى من مكتبة المؤازرة لمنع التغييرات المتكررة للغاية. لدينا بالفعل شيء مشابه لـ SERVO_DELAY ، يجب في الأصل منع إيقاف تشغيل إشارة المؤازرة قبل وصول المؤازرة (ميكانيكيًا) إلى هدفها.

AnHardt أعلم أن تغيير سجلات الظل عدة مرات في كل فترة لا طائل من ورائه ، لكنني لا أرى سبب تغييرها عدة مرات قبل أن يتم دفع القيم إلى السجلات الحقيقية في نهاية الفترة من شأنه أن يسبب مشكلة ، لست متأكدًا مما سيكون الحل لإيقاف تطبيق العميل لتحديث PWM للأجهزة كثيرًا (إذا كانت هذه هي المشكلة حقًا) ، دون حدوث أداء كبير بطريقة أو بأخرى على أي حال.

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 ، تجنبت بحذر تحريك المؤازرة و steppers في نفس الوقت باستخدام المزامنات - لكنني دائمًا اختبرت بـ DEACTIVATE_SERVOS_AFTER_MOVE ، لأنني تراجعت الماكينات الخاصة بي عندما كان السائر يتحرك ، مما أدى إلى توقف مؤقت SERVO_DELAY (بضع مئات من مللي ثانية) بعد ضبط servo_angle. بالمقارنة مع ذلك ، فإن التأخيرات الأقصر التي أقترحها الآن هي فوز في الأداء.

إذا حاول رمز BL-Touch تحريك المؤازرة والسيارات في نفس الوقت الذي لا أشعر فيه بالكرة التي يجب أن ألعبها.

لأن BL-Touches تريد الحصول على إشارة مؤازرة باستمرار DEACTIVATE_SERVOS_AFTER_MOVE غير ممكن. بالنسبة لمكتبات المؤازرة المدفوعة بالمقاطعة ، أصبحت المقاطعة المتأخرة كارثية ، مما أدى إلى إفساد إشارة المؤازرة. سيكون جهاز PWM مدفوعًا بالأجهزة محصنًا. عادة لدينا مؤازرة واحدة فقط.

ومع ذلك ، أنا متأكد تمامًا من أن set_servo(0); set_servo(180); set_servo(0); بدون توقفات لن يسبب أي رد فعل على الإطلاق - لا على أجهزة حقيقية ولا على BL-Touch.

آسف. من المحتمل أن تركز أفكاري كثيرًا على PWM للأجهزة ، في الوقت الحالي ، حيث يجب أن يتم تحديث أجهزة ضبط الوقت فقط بين الحين والآخر.

آسف. من المحتمل أن تركز أفكاري كثيرًا على PWM للأجهزة ، في الوقت الحالي ، حيث يجب أن يتم تحديث أجهزة ضبط الوقت فقط بين الحين والآخر.

هذه المشكلة تتعلق بـ Hardware PWM ، وأنا أتفق مع كل ما قلته ، لقد كنت أفكر فقط في المشكلة على مستوى إطار العمل ، مثل كيفية جعل الأجهزة تعمل بشكل موثوق حتى عندما يقوم تطبيق العميل بإجراء قدر هائل من التحديثات (Marlin ) في نفس الفترة. يتوقع العميل أن يسري التحديث الأخير بدلاً من الأول ، وليس لدي أي وسيلة لمعرفة أنه لن تكون هناك تحديثات لاحقة قبل نهاية الفترة.

يجب أن أعيد النظر في المشكلة لمعرفة ما إذا كان حل جديد يتبادر إلى الذهن ، وما إذا كان هذا التشخيص صحيحًا بالفعل ولم أكن مجرد غبي.

سأحاول
متى يمكن حذف المواقف قصيرة الأمد:

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-fly من المحتمل أن يتم حذف المواقع الوسيطة. في حالة تخزين BL-Touch ، النشر ، إعادة الضبط ، تغيير الأوضاع ، ... كلها مهمة بنفس القدر. ملاحظة هذا يمكن حذفه ، كل أمر يجب أن يبقى لفترة كافية ليتم التعرف عليه. لا يوجد حل صحيح عالمي لمكتبة مؤازرة عالمية.

بالإضافة إلى ذلك ، بالنسبة لـ BL-Touch ، يجب أن تكون جميع الأوامر متزامنة مع حركات السائر. يجب حذف سحب المسبار أثناء النزول للمسبار. :-)
لذا من وجهة نظري ، يجب أن يكون مارلين مسؤولاً عن عدم تحديث الزاوية إلى التكرار.

تعديل:
من المحتمل أن تكون مقاطعة المقارنة هي المقاطعة الصحيحة لتحديث سجل مقارنة الظل. يمكن بعد ذلك تأجيل المقاطعة بسبب المقاطعات ذات الأولوية الأعلى بحوالي 17 مللي ثانية وستظل في الوقت المناسب لجعل سجل التحديث جاهزًا للنسخة إلى سجل المقارنة عند حدوث تجاوز السعة.
يجب أن يكون من الممكن إيقاف المقاطعة إذا كان العداد أعلى من 3. يمكن إعادة تشغيله عند تحديث inter_angle.

أواجه نفس المشكلة مع SKR mini 1.1.
بغض النظر عن الموضع الذي أضعه ، فإن المؤازرة تذهب دائمًا إلى نفس النقطة.

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

Matheusschmitz ، يستخدم SKR mini

إذا كنت لا تزال تواجه مشكلات ، فيرجى الانتقال للمناقشة في أحد أماكن الدعم مثل 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 أيام.

أعتقد أن هذه القضية يجب أن تبقى مفتوحة.