-
-
Notifications
You must be signed in to change notification settings - Fork 19.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] SKR v1.3 (or any other LPC1768): problem with servo signals that cause issues with bltouch #16171
Comments
Are you able to try a genuine BLTouch? |
Also, have you tried adjusting BLTouch settings in |
Oh, sorry, i forgot to mention. Of course i did try different combinations of And no, i don't have access to an genuine BLTouch. For me and my old clone the above mentioned hack works just fine, so personally i don't need a proper fix for this issu. But i think, that this issue should be fixed anyhow, because i think that even an actual servo could possibly react on this pulse with a short shake or any other weird behavior. |
Wow, @mlehnhoff, your patch ease my pain. SKR v1.3 + (not sure about an older version or not) triaglelab 3d touch - same troubles. My own 8/10 working condition: BLTOUCH_FORCE_SW_MODE + BLTOUCH_DELAY 1000. But your patch works 10/10 without SW_MODE and DELAY. Tnx! |
i tested a servo based touch probe on a re-arm (same MCU) and i had no issues, but i used the deactivate after movement feature. i have not tried without it, juse made logic sense to deactivate the servo when not needed |
I have a handful of genuine BLTouches and they all work fine on an SKR 1.3 which is also |
so jumping the gun here, is it most likely a hardware issue (wire, noise connection) or a user config issue? |
Same reason for most of the extra BLTouch code/config options, it's a BLTouch clone issue. Keep in mind that 3DTouch != BLTouch. There are a lot of closed issues related to these copies. |
i would call it a hardware issue then, yep i now 3dtouch (and others) are not a BLtouch the big Q for me is whatever marlin supports the clones or if we only care about the genuine products? |
giving a bit of thought personal i dont think its fair that marlin should support the clones but i could be wrong, thoughts? |
My two cents, no matter what the name of XXtouch. Any of them connects to SERVOS pin (not BLtouch special pin). The SERVOS should work like a servos.
|
This shouldn't be blamed on the probe hardware. The signal being produced from the board is incorrect, and was verified using an oscilloscope. That should be fixed. I can also confirm that the reported behavior is very similar to genuine BLTouch hardware when I was debugging all those timer conflicts causing similar issues on SKR Mini E3 boards. Invalid pulse lengths seemed to cause the BLTouch to simply forget what it was doing and caused failures. @mlehnhoff, did you capture any images from your oscilloscope that demonstrate the problem, that you could attach to this issue? I don't think I like the current workaround as a complete solution, but I really appreciate the level of detail mlehnhoff provided describing the issue and the workaround demonstrating that pulse apparently is the root cause of the issue. |
Sorry, that i did not provide scope screenshot immediately. I thougt i had had made some, but something went wrong. But i did not realize until i had given the scope back (it is not mine). pulse is 20544µs. Plus i tried an actual servo and here is the prove, that this problem is not only limited to 3dtouch or other clones. The Servo should turn from 90° (lever in the middle) to 0° (lever down), but when the faulty pulse occurs, it actually turns up at first, before turning down. By the way there are at least eight different versions of genuine bltouch (classic v1.0, v1.2, v1.3, smart v1.0, v2.0, v2.2, v3.0, v3.1) and no one knows, if all of them will work correctly ;-) Here is another hint: When you send the M280 command manually it is very unlikely, that the issue occurs. I wrote a script to toggle the servo (used in the video) which increases the likeliness a lot: |
I wonder if this is related to an issue I'm seeing with my BLTouch. |
I forgot to mention that I checked the pulses with both my cheap mini DSO and my big CRT oscilloscope and the pulse lengths seem fine. I've also tried different S values (from 155 to 165) without finding one that will trigger the reset. |
I haven't looked up how the servo library for the LPC works - but: |
This is because the lpc framework is not running the hardware pwm in latching mode, (where the pulsewidth register is shadowed and latched in on each period), it should be possible to do that with a simple mode bit .. but unfortunately I can not get it to work reliably, its a choice between a possible 1 period duration glitch, or the pulse width randomly (but quite frequently depending on how often it is updated) not changing at all. Further research on the matter could be done, but it's really not a complicated peripheral, I wasted a long time on that glitch and in the end other things needed attention. |
This comment was marked as off-topic.
This comment was marked as off-topic.
To be honest, i am pretty new to git and i am just glad, that i could create this patch via "git diff". I am sure, there must be a different git command to apply this patch back. Maybe @kockockockoc can help out... |
Hi, I have same board Bigtreetech SKR v1.3 and 3D Touch but the 3D Touch doens't work. I've tested the 3dTouch using some code in an Arduino Mega and does work perfect. So, I've tried any suggestion I found and also the @mlehnhoff patch but I'm still having the same problem = 3D Touch is freeze. When Marlin start the 3D Touch does a self-test and then the pin is stow and stays in this state forever without any change (throught M43 S or from the Marlin menu) |
I suspect that this bug is the same one I reported here: #15370 I am still running a bugfix commit from 6/22/19 with no issues. I tried the latest bugfix commit today and the servo issue is still present. |
@Reywas62 and all, I found this article http://fightpc.blogspot.com/2019/08/testing-skr-13-board-with-marlin-20x.html that could solve the problem. Aparently some SKR boards could have an output signal that has a low impedance (around 200 ohms) that would require a significant amount of current to work properly (and it not happens on Arduino boards, that is the reason why my 3D touch probe works propertly on the Arduino) So, apparently it is not related to firmware. |
Well I'd buy that explanation except that my board works fine with an earlier commit of Marlin bugfix 2.0.x (6/22/19). |
I can confirm that the "quick an dirty" solution from mlehnhoff is working. I probing a 9x9 UBL-Mesh with a BLTouch Clone. Normally 1 or 2 points of the 81 point mesh are failing when i run the meshgeneration. But with the "fix" everything works fine. So i will continue to use this solution. And i my case i think it is a problem with the long servo pulse because my push-pin is deployed an the sensor doesn't trigger. |
I'd like to confirm that my problem with the 3D Touch has been solved. The problem is the low current of the SKR 1.3 Servo pins. I made the circuit and test it sucessfully. Now I've received this information after running M43: |
Going to experiment with my setup here, but I have both a SG90 and a MG90 servo motor that intermittently moves back on disable. As it's holding the Z-Probe switch this kinda kills the machine when it crashes into the bed. Last crash totaled the Creality CR10 S5's wheel mounts. >_<It actually bent the x-axis roller frame! O_O When I get a chance I'll try the circuit and see if it sorts that out. but also going to try the firmware hack. :) |
After trying the firmware hack, there was no change for me (as I suspected, as the hack fixes bl-touch clones, not necessarily servo movement). The Servo would occasionally still move backwards further after completing a move. Considering that, I undid the hack and told marlin NOT to disable the servo and it seems the move back issue has gone. Seems as though disabling the servo triggers my issue. Fortunately the MG90 I'm using doesn't show any vibration/shaking on the angles I have selected. :) I would definitely like to thank mlehnhoff for their gcode to test with. Every time I ran it the servo would play up 3 or 4 times, and when I told marlin to keep the servo enabled, the script ran fine 3 times in a row. Considering reports of low current, I also ran the test with the heaters on to put the PSU under load. :) Don't know if it matters, but my Servo angles are 172(deployed) and 35(Stowed) and it looked like it would move the servo backwards, by the same amount each time. The servo never moved forward. |
The firmware hack did not fix my issue but leaving the servo enabled stops the servo from misbehaving, as it did for DarkAlaranth. Not really a fix, but an acceptable workaround. |
A little extra background I've tried this on several platforms over the past couple of days and thought I might have broken both of my AntLab BLtouch, so I ordered a third. Here is what I've observed for the following platforms The symptom before probing read on a M119 I've adjusted the pins file as well with same results. Here is the process I used in several video of various marlin vintage I could post more videos, but my point is it's not working on any of them with 3 genuine BL touch(s). Has something changed in the configuration? The configuration_adv.h now has a bunch of BL touch power settings. |
I switched from a v2.1 (which i damaged) to a v3.1 yesterday and facing the same issue. Both are genuine BLTouch. I've read about the issue and tried to reduce XY Probing Speed, as well as the stated workaround., played with delay and switching off servo while moving etc. Nothing worked for me. Tried GRID sizes from 3x3 to 10x10 and it randomly fails. |
I switched to Klipper firmware and never had a leveling issue again, if you have a raspberry pi it's very much worth it |
From HardwarePWM.h of framework-arduino-lpc176x
// update the match register for a channel and set the latch to update on next period
} Obviously this is the reason we have intermittent issues with BLTouch, clones or any servo on the NXP MCU's using Arduino lib. PWM mode causes the shadow |
Each time the detach call is made the PWM is disabled. e.g. TERN_(DEACTIVATE_SERVOS_AFTER_MOVE, detach()); The issue can occur when attach is called as set_match does not reload reload LER for MR1 which is the duty match reg. |
Thats too low level for me, however I am more than happy to test any changes with my skr pro 1.1 👍 |
i have got an GTR here and just got myself a modern scope. if you give some instruction i can test some things. |
Thanks, Will consider that option, really hoping we see some manufacturing support for it e.g. they should send a board to work on it. Remote hands and eyes are much more time intensive. |
From a code change perspective it would require using MR0 as the period and MR1 as the duty. Then it should all work with latching. |
Nether the SKR Pro V1.1 nor the GTR have a LPC-processor. They do not use the library under discussion here! =8O |
Also, p3p indicates above that he attempted to use the latching mode and it resulted in more problems than it solved... |
Yes, the question is why was it inconsistent, I cannot see what was tried but there are elements I see that would be an issue. For example, when a reattach is done we need to reset the count to ensure the common period latch is updated and that is MR0. With multi channel there needs to be a process to update each channel MR. I don’t see one in that code. |
When using a BL-touch 'DEACTIVATE_SERVOS_AFTER_MOVE' is unwise and switched OFF by default. Please look up the BL-touch manual. |
'DEACTIVATE_SERVOS_AFTER_MOVE' was made to avoid servo jitter when using the AVRs software timers. For hardware times it makes absolutely NEVER any sense. EDIT: Sorry hardware PWM |
Do you know if this issue occurs on a BL-touch without DEACTIVATE_SERVOS_AFTER_MOVE. |
Read the manual, there is no mention of DEACTIVATE_SERVOS_AFTER_MOVE. |
https://5020dafe-17d8-4c4c-bf3b-914a8fdd5140.filesusr.com/ugd/f5a1c8_a8cd142ffd2f42089c78883f2bb172b7.pdf Later Marlin had a BLTOUCH option, automatically setting this. So they did not go into that much detail in later manuals. |
Ok, thanks, that on v1.0 with Marlin 1.1.x(1.1.9), nothing in the current mentions it (v3.1), also what if you have a mega2560? |
See edited comment above. A real check for this would only be to look up, the reaction when the signal is missing, in the BL-touch firmware - what is closed source - what is my main problem with that shit. (And the problem to make 'real' clones) |
There is no other option when in PWM mode and it is using latching in the current code but only for MR0. https://www.nxp.com/docs/en/user-guide/UM10360.pdf page 527 |
If you want to try adding LER for MR1 give this a go: // update the match register for a channel and set the latch to update on next period |
FYI |
I have just tested the new Release 0.2.7 of pio-framework-arduino-lpc176x So as soon as this package is integrated to Marlin this issue should be solved. |
platform_packages = framework-arduino-lpc176x@^0.2.6 |
Fixed in #22333 |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Bug Description
Recently i have upgraded my 3d printer to a Bigtreetech SKR v1.3. Unfortunatly i had some troubles with my bltouch clone (an older version of triaglelab 3d touch).
Every now and than on a G28 or G29, the bltouch does not trigger and the printhead continues to drive down into the bed.
At first i tried to find a solution in the inernet, but only found a forum article where someone said, that the SKR v1.3 has a bad 5V supply. Some additional Capacitors or an external 5V Supply should help. I tried both, but nothing helped! The 5V supply was not the problem!
I did some investigations myself and with the help of an Oscilloscope i found the actual issue:
It seems there is problem in the HAL of the LPC1768 (and maybe others) which can produce a wrong signal on the servo output. When the servo pulse should change from 1472µs (M280 P0 S90; stowed bltouch pin) to 647µs (M280 P0 S10;deployed pin) sometimes for one cycle the pulse is 20650µs long instead.
This long pulse seems to confuse the bltouch (clone) and even though the pin is deployed, under these circumstances the sensor will not trigger the endstop when it touches the bed.
I believe this happens every time, when the "M280 P0 S10" command is issued right in the small window where the servo pin is high for more than 647µs, but less than 1472µs. Than the falling edge for this cycle is already over and it is not executed until the next 20ms cylce (Just a guess, i have no evidence...).
But I found a quick and dirty solution that work's for me:
It simply checks the current status of the servo pin. If it is high, the change of the signal is delayed by 3ms. This ensures, that the pin is definitely low when the change is applyed, because the servo pulse can not be longer than 2.4ms.
But this is only a quick and dirty hack and it should be fixed in the HAL. And it should also be checked, if this issue can happen on other Controllers too.
My Configurations
Marlin_Configuration.zip
Steps to Reproduce
Expected behavior: [What you expect to happen]
A clean transition from signals with 1472µs pulse width to 647µs.
Actual behavior: [What actually happens]
Every now and than you will see a pulse width of more than 20ms on the first cycle after the command.
Additional Information
Maybe it is more likely to see, if you use "M280 P0 S180" and "M280 P0 S0" instead. (greater difference -> bigger window for the issue)
The text was updated successfully, but these errors were encountered: