-
-
Notifications
You must be signed in to change notification settings - Fork 19.2k
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
BLTOUCH Tweaks and V3.1 new command #14015
Conversation
Please point us to the info on the new V3.1 functionality. UPDATE: There's more to the story so a lot of the following will be updated later. When I looked at it I found the following:
The longer pulse breaks the M43 S command. |
@Bob-the-Kuhn I haven't ever looked at M43 yet - how would that change hit users with a non-V3.1 probe? |
@Bob-the-Kuhn Probably need to modify some more:
I'll look at it in detail. When asked to "trigger the probe", with the V3.1, the trigger will be there as long as you push the pin up, and then it will actually go into "ALARM" mode (because it was expecting a STOW in reaction to the trigger), prolonging the signal (which now signifies ALARM) even more. You will get maximum signal time in that loop, but the conclusion this is a "Z Servo Probe" is wrong in this case. But if you now were to do single deploy and stow sequence, this sequence would not fail for ANYTHING OTHER than a BLTouch V3.1. Testing some code here and I'll post further down. |
The endless S120 was a bug and they fixed it to correspond to their "manual".
Yup. And its not a pulse anymore, its more like a switch. They reacted to some of the conversations we had in the epic issue #13345
As we communicated offline, SET_5V_MODE (and SET_OD_MODE) no longer work as before. We are in OD mode relentlessly until we use the new command to manually store the desired mode into eeprom. 👎 |
That is absolutely terrible news.... |
@InsanityAutomation Makes life difficult for CR users, whom you "preconfigured" their probes to go to 5V mode in the sample configs. I used the instructions in the manual (try it, you'll have fun). I needed a second try before I got it right. Also I cheated because I had my scope on the signal and could literally "see" the success. But a user who is doing this "blind", will need to do that sequence, and then to "test the" probe to see if his efforts changed anything. |
Please also do some testing to confirm my (I am a one sample statement right now) observation of this fact. I would be mortified if I were wrong. |
I'm confused... Does the BL-Touch v3.1 now have the capability to update its own EEPROM to remember if it is in Open Drain Mode or 5 volt logic mode? |
Yes |
I would prefer it was a jumper that the user could strap across two pins... I don't suppose the Marlin firmware can set it. Besides the fact we can't pull the pin... If we were to set the pin output mode too many times, we would wear out the EEPROM inside the AVR part in the BL-Touch. |
@InsanityAutomation and I were hoping in the beginning, it would be "push the pin". Then we could have finagled it by pressing against the bed, but.... 👎 I joked that we could place a jar of peanut butter somewhere to catch the pin and then go up |
Maybe ill join Marcio as a tomato farmer..... |
Tomatoes are not viscous enough to catch the pin, or are you contemplating using ketchup? |
I've been scratching my head over what to do with the M43 S command. Part of it might be:
If all of that passes then declare it a BLTouch and call it quits. If any of it fails then do some deploy & stow cycles to see if the Z signal follows. If it follows then declare it a ?mechanical switch? and quit. If that also fails then do the pulse measurement test. If its in the 4 - 30mS range then declare it a BLTouch/clone. If that also fails then declare failure. |
@Bob-the-Kuhn That looks good. I'll try it tomorrow, if you like. If that's what comes out when you itch, then please keep scratching |
I'll be testing the M43 with this new code tomorrow |
As I understand it there are three output modes:
The other big change is the output will go active if the probe is pushed up for less than ?650? mS. Longer than the ?650? puts the probe into alarm (which keeps the output active until S160 is issued). I know it's at least 625mS because I saw a pulse of that length when manually pushing the probe up. If I read the 3.1 data sheet correctly the minimum pulse width is 60mS. We'll need to mount one of these to a printer and do some custom coding to determine the pulse width limits. BTW - the new pull down power FET has some muscle. A 100 Ohm resistor to +5V only shifted the output level from 7.5mV to 12.5mV. |
Trigger signal rise: From that point: our latency + STOW command recognized (60ms) Yup. I concur.
My measurements came out to be somewhere under 1s just by doing a hundred, using a stopwatch and dividing. So I concur. It also correlates to my observation that going into an alarm after a blocked STOW or DEPLOY also takes "about 750ms". I would say that to be safe, if you want to know that an ALARM is coming, you need to wait about 750ms after ANY command that might cause an ALARM. Of course, triggering is not a command, but it would not surprise me if internally in the BLTouch firmware the same path is taken - therefore after about 650, 750ms, the ALARM can be seen
I haven't seen that and also don't really know of what use it would be for now. Time will tell I suppose.
Definitely, yes. Meanwhile I will unmount mine and check some stuff on the older models. |
Apparently I don't know how to do a proper review. I made some minor changes to M43.cpp and it doesn't show up as a review. I've tested the file with the changes. Works nicely on old BLTouches, 3.1 and on clones. @FanDjango - before making more edits, please pull in my edits by doing the following:
This will set your branch to the current state of the PR. If you've made changes since your last commit to the PR then those changes will be wiped out. Changes I made:
I like your idea to use the pulse width to determine if it is a 3.1 or if it is an earlier one. FYI - after a reset the clone does one deploy/stow cycle while the 3.0 and 3.1 units did not. I changed the BLTouch delay to 2000 but it didn't change anything. |
#13988 is now merged. |
A review is a comment that is saved as a Review. All you did was add a commit. |
Marlin/src/gcode/config/M43.cpp
Outdated
|
||
if (probe_counter == 0) SERIAL_ECHOLNPGM("trigger not detected"); | ||
if (probe_counter == 0) SERIAL_ECHOLNPGM("ERROR: Trigger not detected"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remember that this will cause OctoPrint to disconnect by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@thinkyhead That's a good point, but Gina has made OctoPrint be a little more discerning nowadays. I tested this with a bogus "ERROR:" message, see below. Still she laments rightly the lack of standardisation for fatal error messages, therefore I agree with you totally that "FAIL:" is better
@Bob-the-Kuhn — I squashed your commit into mine (oops!) so if you need get the latest into your working copy you can just…
If you're not working on it within your working-copy then nevermind! |
bltouch.cpp: * init() no longer deploy (unless PR # 13998 is merged - then remove this) * An untrue comment removed * A discovery that _set_SW_mode() resets alarms is documented * _reset() does not turn off the SW mode and is not needed. In fact there is also no ALARM in SW mode bltouch.h: * New BLTOUCH V3.1 command MODE_STORE * New BLTCOUCH function RESET_SW_MODE (for M119) language_en.h, menu_configuration.cpp: * New BLTOUCH V3.1 command MODE_STORE G28.cpp: * Move the BLTouch activation to where Z homing is done BLTouch activation (whatever it may consist of) need not be done until immediately before Z is homed. Without this change, it would be done even if someone is homing only X and/or Y. endstops.h: * M119 cleanup BLTOUCH reset SW mode The _reset() will not clear the SW Mode. It is also not needed as in SW Mode, there are no "alarms". On the other hand, the _stow() is what actually resets the SW Mode. The only other command that can do that would be a _deploy. If the enabled_globally is not true, SW mode will never be reset. Better to do the _stow() unconditionally Even more better is to query pin status and to deploy or stow accordingly. motion.cpp, probe.cpp: * Honor a BLTOUCH_HS_MODE if enabled BLTOUCH High Speed Mode, use the normal rectratable probe code for a probing mode that avoids STOWs and DEPLOYs in a multiple probing sequence (G28) or in G34, G29 probing sequences.
This was the original suggestion: Issue stow issue reset just in case Check that z signal is inactive issue S140 followed by S60 check that Z signal is active issue deploy check that Z signal is inactive issue stow and then a reset If all of that passes then declare it a BLTouch and call it quits. If any of it fails then do some deploy & stow cycles to see if the Z signal follows. If it follows then declare it a ?mechanical switch? and quit. If that also fails then do the pulse measurement test. If its in the 4 - 30mS range then declare it a BLTouch/clone. If that also fails then declare failure. I modified a little but it's more or less the same idea.
Compiler error ECHOLNPAIR needed Spacing on output "We" are not tolerated Could it be that travis doesn't use #IF ENABLED(BLTOUCH)?
Ok, looking good now. My printers are running with this. Another thing: There is a new Let's keep it secret for now. On the question of perhaps adjusting any timing parameters in this, @InsanityAutomation kind of set the standard for now by saying: Let's keep it conservative in the defaults so as to avoid more unexpected problems. It's up to the user to go down to 200ms BLTOUCH_DELAY. Mine works even at 100ms, but we have capped that at 200ms in sanity check. So that's ok, conservative. Our default is now 500ms. Also Ok. And those commands that require a longer check are forced to be long enough, so we are safe there also. Perhaps finalizing real close timing parms would mean measuring these for each kind of probe and making a table by probe type and.. and.. and.. I don't think this effort pays off if one remembers how little gain is to be had in terms of time spent probing vs. time spent printing overall. My 2 cents. Test the Are we too close in timing anywhere? Currently only our wait after setting 5V mode on a 3.0 should be longer, but it has not caused a failure yet. In
needs changing. |
If the measured pulse width is 30ms, the it is 30ms OR MORE (maybe even a lot more)
Setting 5V mode here is downright dangerous in case the controller board is not 5V tolerant and the probe happens to be a BLTouch V3.0. All others would ignore this command but this one does not. More detailed comments and execute Phase 1 (check for BLTouch) only if BLTOUCH actually defined in configuration.h
An interesting development concerning the CR10s Pro : Look at the May 15, 2019 post about the CR10s Pro breakout board and its influence on the ZMIN input pin. Might help a few of the users still struggling with their BLTOUCH V3.0. Here's the link: <-> |
This was not visibile to the user - only when DEBUGGING(LEVELLING) is on. Changed the text to be compatible with the text at the beginning of G29 (i.e. There it is "Home XYZ first")
When G34 travels in BLTOUCH HS Mode, the probe is deployed. To get some more clearance, add the stroke length of the pin to the Z position before moving. When G34 finishes, if successful, it will execute a G28 (Home). In BLTOUCH HS Mode, the G28 travel would be with a deployed probe (a bit disconcerting to users).
This PR supesedes #13959, as ANTClabs have released a BLTouch V3.1.
This consolidates needed changes accumulated after the recent #13814 PR merge with support for the new V3.1 commands and the BLTOUCH HIGH SPEED mode.
For even more information please refer to PR's #13959 (closed, superseded by this PR) and (if you've got lot's of time, the epic issue #13345)
Code changes:
bltouch.cpp:
bltouch.h:
language_en.h, menu_configuration.cpp:
G28.cpp:
Reason:
BLTouch activation (whatever it may consist of) need not be done until immediately before Z is homed. Without this change, it would be done even if someone is homing only X and/or Y.
endstops.h:
Reason:
The _reset() will not clear the SW Mode. It is also not needed as in SW Mode, there are no "alarms".
On the other hand, the _stow() is what actually resets the SW Mode. The only other command that can do that would be a _deploy. If the enabled_globally is not true, SW mode will never be reset. Better to do the _stow() unconditionally. Even more better is to query pin status and to deploy or stow accordingly.
motion.cpp, probe.cpp:
Reason:
BLTOUCH High Speed Mode, means use the normal retractable probe code for a probing mode that avoids STOWs and DEPLOYs in a multiple probing sequence (G28) or in G34, G29 probing sequences.
New V3.1 video