Skip to content
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

Merged
merged 9 commits into from May 18, 2019
Merged

BLTOUCH Tweaks and V3.1 new command #14015

merged 9 commits into from May 18, 2019

Conversation

ghost
Copy link

@ghost ghost commented May 14, 2019

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:

  • 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

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:

  • M119 cleanup BLTOUCH reset SW mode

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:

  • Honor a BLTOUCH_HS_MODE if enabled

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

@Bob-the-Kuhn
Copy link
Contributor

Bob-the-Kuhn commented May 14, 2019

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:

  • Pulse width is much longer: 150mS – 500mS longer
  • S120 test now stops at 10 deploy/stow cycles.
  • The weak driver is back
  • Output voltage is now 3.1V

The longer pulse breaks the M43 S command. Please add this to the PR:
Line 189 in M43.cpp change the 50 to 350 (100mS max pulse width to 700mS)
~FROM ~
for (probe_counter = 1; probe_counter < 50 && deploy_state != READ(PROBE_TEST_PIN); ++probe_counter)
TO
for (probe_counter = 1; probe_counter < 350 && deploy_state != READ(PROBE_TEST_PIN); ++probe_counter)

@ghost
Copy link
Author

ghost commented May 14, 2019

@Bob-the-Kuhn I haven't ever looked at M43 yet - how would that change hit users with a non-V3.1 probe?

@ghost
Copy link
Author

ghost commented May 14, 2019

@Bob-the-Kuhn Probably need to modify some more:

         if (probe_counter == 50)
            SERIAL_ECHOLNPGM("Z Servo Probe detected"); // >= 100mS active time

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.

@ghost
Copy link
Author

ghost commented May 14, 2019

S120 test now stops at 10 deploy/stow cycles.

The endless S120 was a bug and they fixed it to correspond to their "manual".

Pulse width is much longer: 150mS – 500mS

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

The weak driver is back
Output voltage is now 3.1V

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. 👎

@InsanityAutomation
Copy link
Contributor

InsanityAutomation commented May 14, 2019

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....

@ghost
Copy link
Author

ghost commented May 14, 2019

@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.

@ghost
Copy link
Author

ghost commented May 14, 2019

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.

@Roxy-3D
Copy link
Member

Roxy-3D commented May 14, 2019

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?

@ghost
Copy link
Author

ghost commented May 14, 2019

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

@Roxy-3D
Copy link
Member

Roxy-3D commented May 14, 2019

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.

@ghost
Copy link
Author

ghost commented May 14, 2019

we can't pull the pin

@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

@InsanityAutomation
Copy link
Contributor

Maybe ill join Marcio as a tomato farmer.....

@ghost
Copy link
Author

ghost commented May 14, 2019

Tomatoes are not viscous enough to catch the pin, or are you contemplating using ketchup?

@Bob-the-Kuhn
Copy link
Contributor

I've been scratching my head over what to do with the M43 S command.

Part of it might be:

  • 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.

@ghost
Copy link
Author

ghost commented May 14, 2019

@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

@ghost
Copy link
Author

ghost commented May 14, 2019

I'll be testing the M43 with this new code tomorrow

@Bob-the-Kuhn
Copy link
Contributor

As I understand it there are three output modes:

  • Strong 5V output. Manual activation sequence rquired. This remains in effect until the manual deactivation sequence is performed. The active/inactive state is stored in the EEPROM and is restored on power up.
  • Open drain output. This is the default mode when shipped from the factory. On power up this is the mode unless the EEPROM says it should be the strong 5V.
  • Weak 3.3V output. This can be enabled by issuing S140 when in the open drain mode. The S140 must be done after every power cycle.

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.

@ghost
Copy link
Author

ghost commented May 14, 2019

If I read the 3.1 data sheet correctly the minimum pulse width is 60mS.

Trigger signal rise: From that point: our latency + STOW command recognized (60ms)

Yup. I concur.

?650? mS

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

Weak 3.3V output. This can be enabled by issuing S140 when in the open drain mode. The S140 must be done after every power cycle.

I haven't seen that and also don't really know of what use it would be for now. Time will tell I suppose.

We'll need to mount one of these to a printer and do some custom coding to determine the pulse width limits.

Definitely, yes. Meanwhile I will unmount mine and check some stuff on the older models.

@Bob-the-Kuhn
Copy link
Contributor

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:

git fetch origin
git checkout bugfix-2.0.x-BLTOUCH-0514
git reset --hard origin/bugfix-2.0.x-BLTOUCH-0514

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:

  • Moved bool deploy_state, stow_state; near the beginning of the routine to fix a "not defined" compiler error.
  • Moved the return at the end of the four deploy/stow cycle section so that it exits only if a mechanical switch is found. This allows clones to fail the first two tests and pass the pulse width test.
  • Removed an extra "}" to fix a compiler error.

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.

@thinkyhead
Copy link
Member

#13988 is now merged.

@thinkyhead
Copy link
Member

thinkyhead commented May 15, 2019

I made some minor changes to M43.cpp and it doesn't show up as a review.

A review is a comment that is saved as a Review. All you did was add a commit.


if (probe_counter == 0) SERIAL_ECHOLNPGM("trigger not detected");
if (probe_counter == 0) SERIAL_ECHOLNPGM("ERROR: Trigger not detected");
Copy link
Member

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.

Copy link
Author

@ghost ghost May 15, 2019

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
grafik

@thinkyhead
Copy link
Member

thinkyhead commented May 15, 2019

@Bob-the-Kuhn — I squashed your commit into mine (oops!) so if you need get the latest into your working copy you can just…

git remote add FanDjango git@github.com:FanDjango/Marlin.git
git fetch FanDjango
git checkout my_copy_of_14015
git reset --hard FanDjango/bugfix-2.0.x-BLTOUCH-0514

If you're not working on it within your working-copy then nevermind!

FanDjango and others added 4 commits May 15, 2019 10:55
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)?
@ghost
Copy link
Author

ghost commented May 15, 2019

Ok, looking good now. My printers are running with this.

Another thing: There is a new #define BLTOUCH_HS_MODE in the BLTOUCH section of configuration.h.

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 BLTOUCH_HS_MODE on your machine(s) and you won't see any need to shave off more on the delays.

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 configuration.h the comment

/**
   * BLTouch V3.0 and newer smart series
   * For genuine BLTouch 3.0 sensors. Clones may be confused by 3.0 command angles. YMMV.
   * If the pin trigger is not detected, first try swapping the black and white wires then toggle this.
   */
  //#define BLTOUCH_FORCE_5V_MODE

needs changing. Only BLTouch V3.0 smart series in my opinion.

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
@ghost
Copy link
Author

ghost commented May 16, 2019

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).
@thinkyhead thinkyhead merged commit 85fb33a into MarlinFirmware:bugfix-2.0.x May 18, 2019
@ghost ghost deleted the bugfix-2.0.x-BLTOUCH-0514 branch May 19, 2019 08:29
ozgunawesome pushed a commit to ozgunawesome/Marlin that referenced this pull request May 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants