[BUG] Multiple HW platforms with BLTouch read triggered #16643
Comments
|
Does anyone know the correct new steps to configure or possible other connected HW needed such as stepper boards, Hotends, thermistors, etc? |
|
Updating instructions, as the appear to be missing commented out, "#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN" |
|
Connecting...
|
|
Marlin-bugfix-2.0.x.zip |
|
This also occurs on SKR 1.4 with z-min pins. |
|
@ebraiman is |
|
On my printers that are working with BLTouch I have Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN enabled. If I turn one the printers and connect Z will show as triggered when issuing an M119. If I stow the probe issuing which is the way that it is working in Marlin 2.0.x |
|
You mean @ebraiman that you are worried because the probe shows triggered status when the probe pin is stowed? But the homing/auto-leveling itself works for you? I personally much prefer that it's triggered while stowed as it should actually make detecting the probe touch more reliable because instead of short signal the state change is "latching". This shouldn't affect functionality except probably if one would enable ENDSTOPS_ALWAYS_ON_DEFAULT and SD_ABORT_ON_ENDSTOP_HIT. My two BLTouch probes, both v3.1 have always behaved like this. Always triggered in stowed position and open when deployed. This is at least while using the default BLTouch open drain mode which needs pull-up resistors enabled. This behavior of the probe state being reported always triggered in stowed position is result of the pull-up resistor. It also works as a safety feature if the probe would get disconnected then the state is triggered and the carriage doesn't hit the bed if you would try to home or do auto-leveling. Haven't tried with the 5V mode as the endstop signal lines on my boards have 3.3V logic but possibly in 5V mode without pull-up sensors would show the triggered status only momentarily while the probe actually touches the bed. But again I think current "latching" behavior is better at least in my use case. So if your probe actually works for auto-leveling/homing then I would say everything is OK. If really want to see the trigger state as open while probe pin is stowed then if you have 5V logic board you can go around playing with pull-up/pull-down resistor settings. |
|
Originally it appeared open in the several tutorials ive created. Now user needs to do the following:
|
|
Understand a thermistor was not always present in the past tutorials. And if you ask why one might not use a thermistor think about what may be other functionality the marlin firmware may be used for? For instance a laser cutter, router cutter, water cutter, etc. |
|
Going back in time I always seen 'open' with bltouch, when stowed and when deployed... |
|
That is strange as on my two printers with Marin 2.0.x one ReARM and one SKR E3 Mini DIP the BLTouch stays deployed when I do a M119 after asking it to be deployed with M280 P0 S10. Here are my configurations that are working:- Ender3Pro_SKRE3MiniDIP_Marlin2.0.x_config.zip |
|
@ebraiman regardless of what the state is when the probe pin is stowed does the probe work for homing/auto-leveling? I think the functionality with homing and auto-leveling is the main point. If the probes don't work with homing and auto-leveling, then there could also be the possibility that the two probes of yours have been damaged and are now misbehaving with the boards you are connecting them to. @GMagician for me the probes have always (about 3 months in use now) reported the M119 status as triggered while stowed and open while deployed. I have seen others tell the same as did @AmiSMB just above. And because this way of functionality seems to work reliably with homing and auto-leveling I'm happy with it although I don't mind even if it was open after it was triggered as long as everything works. Newer had the probes fail during probing so far with this "latching" behavior. But certainly the fact that your probe is deploying with the command M119 is strange. Have you by any change had the BLTouch in 5V mode and the pull-up/-down resistor settings together with signal inverting in some other state previously when it reported open while stoved? In any case M119 doesn't make the pin stove or deploy on my systems with skr e3 mini v1.2 boards, probe connected to z-min and the servo port with BLtouch v.3.1 default open drain mode. I'll have to see how the SKR 1.4 behaves when it arrives. What's the course of action here? @ebraiman check if the probes work with homing/leveling and we ask around if the "latching" behavior was introduced by some code change along the way and whether it can be made as an option if some prefer it and others don't? |
|
@tatusah mine is a 2.0 clone, installed on a ramp with mega2560 so 5V is the only choice I have. Mine is working not perfectly but I can do G28 and G34 without any issues |
|
Ok @GMagician does it have option to change between fixed 5V and the open drain mode? That open drain mode is convenient as it works both in 3.3 and 5 V systems and as such based on BLTouch documentation there shouldn't even be the need to change the mode to fixed 5V mode in most cases. Anyway perhaps the probe pin deploying with M119 on the clone could possibly be a reliability issue and not a bug in Marlin. |
|
I think it has no 3.3 option nor drain mode (that is present on 3.0 AFAIK). |
|
Previous behavior observed in my case was probe was in non-deployed mode when M119 was used to check endstop state. I've recorded several tutorials with this state of open for Z-min. Now it appears we need to add a deploy command to have a opened state on z-min. One would think the previous observed behavior deployed on homing of z axis. Here is an example with SKR 1.3 using z-min endstop for signal pin. https://www.youtube.com/watch?v=5cSzFCv7K4Q&t=5s Around 11:09 into video you'll see the test. |
|
Setting those isolated tabletop test aside do you have some problem with the probe while homing or auto-leveling in actual use? |
|
Yes, a M999, which seems related to thermistor. I'll be placing in a setup to check if it works soon. |
|
@ebraiman any news? anyone else been able to reproduce this one and can confirm it? |
|
Just ordered a new MEGA2560/RAMPS and BLtouch to test. I'll make a video from box opening to test on video to verify. |
|
If we are talking about the probe being reported triggered by M119 while the probe pin is in stowed position I think anyone with BLTouch and up to date bugfix branch Marlin can report the same behavior. Even if this seems to be changed at some moment based on @ebraiman videos this doesn't seem to cause any problems. If anything it could possibly make the probing action more reliable as the system reads latching signal instead of a short pulse. There are the videos showing the board alone connected to the probe showing the M119 reporting the status for BLTouch as triggered while stowed. And M119 documentation https://marlinfw.org/docs/gcode/M119.html mentions that the BLTouch signal is brief and that triggered state indicates error but this documentation might be outdated and might also not take into consideration the possible pull-up resistors affecting the behavior. My complete printers also show this behavior but it doesn't seem to affect the functionality of using the BLTouch for homing or auto-leveling. Actually it has been 100% reliable with sensing the probe pin touching the build plate. And at least personally I haven't seen any reports of this causing problems. I think the question still remaining is what would @ebraiman suggest to be done for this and if the M999 problem he mentioned was actually unrelated to this. |
|
I have a recorded uploading to YouTube in two parts because the camera may have powered down or froze. It's a bit scatter brained of a videos, but get the point across as to the odd functionality across HW/SW platforms. |
|
Just tested a 5v Inductive sensor https://www.amazon.com/gp/product/B073XDCR2F/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1 |
|
Unless there is a fully build printer with some issues related to this matter I don't see value in continuing. There isn't currently any reported issues indicating that the current way of M119 reporting probe status would cause some actual problems on fully built machines. The provided videos show USB powered bare boards on the table having just BLTouch or some other probe connected. This kind of testing is prone to display other unrelated issues as the USB might not power the board properly and the board is lacking the feedback from temp sensors and endstops unless these things are taken into consideration. |
|
i agree with @tatusah testing has to be done on a fully build/working printer that is assembled correctly |
|
Just to mention i reported a similar issue with a built printer |
|
So with the built printer is the homing failing using the probe? |
|
@ebraiman can you provide pictures of how its connected? EDIT: and the pics need to be of connection on a build printer and not a test setup |
PNP sensor? sure it shouldn't be NPN? if your board has a pullup resistor a PNP sensor will never work |
|
Was able to get this working by fliping white and black cables on my jst 2 pin connector. As original wiring loom was made for crealities melzi board |
|
hehe, hence we need to see pictures from @ebraiman prob did the same mistake and it does matter how its connected to endstop |
|
The first wiring I tried was per the Manual. The second was connected via ground for black and white for signal on z-Min using SKR 1.4. I'll try reversing cable for both to see if any change occurs. |
|
Lack of Activity |
|
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
After configuring Marlin bugfix 2.0.x for BLTouch M119 reads Triggered before homing z-axis.
Marlin-bugfix-2.0.x_SKR1_4.zip
My Configurations
Required: Please include a ZIP file containing your
Configuration.handConfiguration_adv.hfiles.Steps to Reproduce
Hardware:
Acer Nitro 5 with Windows 10 64 bit
SKR 1.4 (LPC1768)
BLTouch v2.0/v3.1
USB cable
Software:
VScode with platofrmIO IDE plugin
Marlin Bugfix 2.0.x
Hardware configuration:
https://github.com/bigtreetech/BIGTREETECH-SKR-V1.3/blob/master/BTT%20SKR%20V1.4/BTT%20SKR%20V1.4%20Instruction%20Manual.pdf
Marlin Changes
Configuration.h:
change to, “#define SERIAL_PORT -1”
change to, “#define MOTHERBOARD BOARD_BIGTREE_SKR_V1_4”
remove comment for, “define BLTOUCH”
remove comment for, “#define NUM_SERVOS 3”.
change to, “#define NUM_SERVOS 1”.
PlatformIO.ini changes:
default_envs = LPC1768
Click upload in VSCode
After upload checked drive for firmware.bin
PO/PO USB cable
Open Pronterface and connected to SKR 1.4 (LPC1768)
Entered, “M119”, in Pronterface.
Expected behavior: [What you expect to happen]
SENDING:M119
Reporting endstop status
x_min: TRIGGERED
y_min: TRIGGERED
z_min: open
Actual behavior: [What actually happens]
SENDING:M119
Reporting endstop status
x_min: TRIGGERED
y_min: TRIGGERED
z_min: TRIGGERED
Additional Information
This occurs on the following platforms:
MEGA2560/RAMPS 1.4
MEGA2560/RAMPS 1.6
SKR 1.3 (LPC1768)
SKR 1.4 (LPC1768)
SKR 1.4 (LPC1769)
SKR PRO v1.1
using the following touch sensors:
BLTouch v3.1
BLTouch v2.0
3D Touch
The text was updated successfully, but these errors were encountered: