New Type BLTOUCH - Githubissues

MagoKimbra commented 7 years ago

@thinkyhead I wanted to alert you this thing, I had a lot of people who reported to me a problem with the bltouch. It seems that there is a version, do not know if a clone or a new one that has a very different operation from the one we know.

The first thing is the logic inverted with respect to the classic this is not a problem, but I noticed you fixed Conditional_LCD.h logic false and that's a problem because you cannot vary from Configuration.h.

The other problem is that it does not work like the classic that when retracted or extended it's always not triggered and only when pressed on the bed by the impulse of triggered, but is triggered when it is retracted and not triggered when it is extended, when press comes into a position from which the triggered. It also does not have the automatic retraction.

This problem of the state control in the bltouch

if (TEST_BLTOUCH()) {// If it still claims to be triggered
 stop();

because the test is true when it is retracted. You must be done the first to extend and then do the test. I just wanted to alert you in the meantime I'm finding a solution to... Hello!

Sorry for my bad english!!!

Roxy-3D commented 7 years ago

Yes.. There are counterfeit BL-Touch probes out there. And my suspicion is there are two different counterfeit BL-Touch probes. The legitimate probe has a capital 'BL' with a Red Probe Symbol that looks like a 'T' and then lower case 'ouch' printed on the side of it. The fake ones have other lettering.

It is causing a bunch of problems for us. But if your BL-Touch isn't working... It probably is FAKE.

MagoKimbra commented 7 years ago

Yeah I think so too, but it's not mine. I have bought it during the campaign on indiegogo, so original.

Bob-the-Kuhn commented 7 years ago

Can you provide a link to where we can buy one of the counterfeit units?

I'd really like to see how they operate & if we can somehow make them functional.

Maybe making them functional isn't a good idea. That would encourage the counterfeit.

Maybe the thing to do is to test for the counterfeit and, if one is detected, 1) send a message to the user and 2) don't use it.

MagoKimbra commented 7 years ago

Yes, it would be fair .. But since repetier fw does not implement any control over bltouch because it considers a probe as another of repetier works without any problem. So people think that the problem is the fw Marlin or in my case MK4duo wrong.

Roxy-3D commented 7 years ago

@MagoKimbra I don't understand. Can you re-explain in different words why Repetier does not have a problem with the fake BL-Touch probes?

MagoKimbra commented 7 years ago

repetier makes no test if the sensor works or not. In Marlin function set_probe_deployed:

if (TEST_BLTOUCH()) {              // If it still claims to be triggered...
  stop();

This test with normal BLTOUCH function, but with FAKE BLTOUCH not function and stop the printer.

Because this test read the pin in retracted probe. In normaly BLTOUCH the status of the pin is not triggered, while with fake bltouch the status is triggered.

Roxy-3D commented 7 years ago

OK. I think I understand. However... The real BL-Touch always reports the end stop as triggered if it is in the error state. That is really what that code is trying to deal with. It is trying to get the probe out of the error state. I think they are reporting a 'triggered' condition in the error stat to help protect the printer. If you are probing a grid (or homing for that matter), if the probe goes into the error state, it keeps the nozzle from crashing into the bed.

If the fake probes are not reporting a triggered state when they go into an error condition, they might be causing the extruder to crash into the bed when a probe is being done.

Because this test read the pin in retracted probe. In normaly BLTOUCH the status of the pin is not triggered, while with fake bltouch the status is triggered.

@Bob-the-Kuhn I wonder if we could use this difference to detect fake BL-Touch probes???

@MagoKimbra Do you get a feeling the Repetier group is feeling the pain caused by these fake BL-Touch probes? Or does everything work correctly in their firmware whether the probe is real or fake?

MagoKimbra commented 7 years ago

No .. the fake BLTOUCH in the state of retracted always triggered status. So when check test the printer go in stop mode.

STATE	Normal-BLTOUCH	Fake-BLTOUCH
RETRACTED	NOT TRIGGERED	TRIGGERED
EXTRACTED	NOT TRIGGERED	NOT TRIGGERED
TOUCH PLANE	TRIGGERED	TRIGGERED
ERROR	TRIGGERED	NOTHING

I hope you understand more

Roxy-3D commented 7 years ago

When you say 'Retracted', do you mean by giving it the 90 degree signal (M280 P0 S90) ? Or do you mean by pushing the pin to the fully depressed state?

I actually think we can use that table to detect fake BL-Touch probes. What if we did:

Home X & Y
Move to center of the bed
Home Z
Move Z to a height such that the BL-Touch probe is 1mm above bed
Deploy probe (which should force the BL-Touch into an error state)
Read the Z-Min endstop status. BL-Touch would say Triggered, Fakes say Not Triggered
Raise Z 15mm
Clear Error State.

No .. the fake BLTOUCH in the state of retracted always triggered status. So when check test the printer go in stop mode.

I wonder if this is what has been causing all the problems? We now have end stop controls to handle the case of a Z-Probe that is not deployed but saying 'Triggered'. We had to put that in place for the Delta Allen Key probes. We have the ENSTOPS_ONLY_FOR_HOMING feature... I wonder if turning that on makes the fake BL-Touch probes work?

MagoKimbra commented 7 years ago

Yes retracted is stow M280 P0 S90... In Black original BLTOUCH, in red Clone BLTOUCH...

bltouch

Roxy-3D commented 7 years ago

In Black original BLTOUCH, in red Clone BLTOUCH...

Is it true the clone BL-Touch probes put out a much longer than 5ms pulse? That is the original issue that was causing us so much trouble with the real BL-Touch probes. 5ms is very short and it was possible to miss the pulse. If it is true the fake BL-Touch probes put out a much longer signal, that makes their use much better!!!

MagoKimbra commented 7 years ago

The clone does not impulse, until it is press on plane it exit with 1, when the probe go up it exit with 0. You can see this video https://www.facebook.com/marco67/videos/10210347805963174/

Roxy-3D commented 7 years ago

The video is not available. But that is the behavior we asked Antclabs to do! So, the clones are actually doing things in a way that is easier for us to handle.

@MagoKimbra THANK YOU for the help understanding this! It maybe we can make it so the clones don't cause any more problems. I think what we need to do is modify TEST_BLTOUCH() to factor in a Z_MIN_PROBE_ENDSTOP_INVERTING condition. And we probably need to document that may be necessary for clone BL-Touch probes at the place where BLTOUCH is turned on.

If we do that... Both the real and the fake BL-Touch probes should work correctly, right?

      if (deploy && TEST_BLTOUCH()) {                   // if it still claims it is triggered
    stop();                                         // we punt! 
    return true; 
      }
    #elif ENABLED(Z_PROBE_SLED)

Update: Maybe not... TEST_BLTOUCH() already does factor in the inverting flag:

    #define _TEST_BLTOUCH(P) (READ(P##_PIN) != P##_ENDSTOP_INVERTING)
      #define TEST_BLTOUCH() _TEST_BLTOUCH(Z_MIN)
      #define TEST_BLTOUCH() _TEST_BLTOUCH(Z_MIN_PROBE)

thinkyhead commented 7 years ago

The test for the BLTouch already being triggered might be safe to remove. It's an extra precaution.

I seem to recall we discussed how the BLTouch shows up as triggered when it's in an error state, and this is (as I fuzzily recall) the only way that we could actually test for an error state. This is why the "Reset BLTouch" menu item is shown when the probe is inactive but also triggered.

So, it sounds like this counterfeit BLTouch has no way for us to check for an error state.

thinkyhead commented 7 years ago

Ref: #5705

Roxy-3D commented 7 years ago

The test for the BLTouch already being triggered might be safe to remove. It's an extra precaution.

No. I needed that on my machine to handle the case where the BL-Touch powered up in an error state. That happens some times. Having the first check with the automatic BL-Touch reset is a very nice convenience for BL-Touch owners. But I think having a little more information about what kind of BL-Touch is on the machine would help the developers do the right thing.

Instead of removing the second check, Can we wrap the second check of the BL_Touch with a:

#ifdef I_HAVE_A_KNOWN_REAL_BLTOUCH_PROBE
      if (deploy && TEST_BLTOUCH()) {   // if it still claims it is triggered
    stop();                                            // we punt! 
    return true; 
      }
#endif
    #elif ENABLED(Z_PROBE_SLED)

I don't want to compromise the real BL_Touch behavior just because there are clones that don't exactly emulate the real one. And if it is true there are at least two different counterfeiters in operation, we are going to need some more controls to guide us through the different behaviors.

crncrussell commented 7 years ago

Non-developer perspective: The fake BLTouches should still be useable by manual defining them rather than configuring as a BLTouch, correct? If this is the case, would it be possible for you guys to determine if the BLTouch is a fake, show something on the LCD and/or spit something back on the serial channel telling the user that they have a fake and it needs to be defined manually rather than using the BLTouch settings? This would show solidarity for Paris and ANTCLABS by supporting the original BLTouch, but just make it a little bit of a PITA (but still usable) for someone who bought a fake.

Roxy-3D commented 7 years ago

Yes... That does make sense. But the big problem is we don't even have a way to get in touch with the makers of the fake BL-Touch probes. If we have questions or are seeing problems, who do we contact? Right now... We are guessing how the various fakes will handle this or that.

emartinez167 commented 7 years ago

Why such a big effort to support counterfeit goods?

Regards,

Ernesto.

Blue-Marlin commented 7 years ago

The mess with the many different BLTouch lookalikes is a direct consequence of BLTouch is not open source. If BLTouch wouldn't be patented it would be easy to make and support functional clones. Moreover - because BLTouch is patented (or at least wannabe) there is no way to make legal functional clones - they have to be different, to be legal.

Roxy-3D commented 7 years ago

Perhaps Antclabs should have trade marked 'BL-Touch'. That would have solved the problem. If anybody claimed to be selling a BL-Touch probe when it was a fake, it would be easy to crucify them.

emartinez167 commented 7 years ago

I doubt it. Chinese government is very lax prosecuting copyright infringement.

Regards,

Ernesto.

On 16 Feb 2017, at 12:03, Roxy-3D notifications@github.com wrote:

Perhaps Antclabs should have trade marked 'BL-Touch'. That would have solved the problem. If anybody claimed to be selling a BL-Touch probe when it was a fake, it would be easy to crucify them.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

Roxy-3D commented 7 years ago

I doubt it. Chinese government is very lax prosecuting copyright infringement.

That is true. But it is not the Chinese people buying the fake probes. (And in fact, I'm not sure we know where the counterfeit probes are being made. China is high up on the list, but I'm not sure we have any evidence to prove that.)

There are 3 different areas involved to protect intellectual property. There are patents, copyrights and trademarks. Right now... The big problem is the fake probes are claiming to be BL-Touch probes when they are not. If BL-Touch was trademarked, Antclabs could go to eBay and Amazon and show them who is authorized to distribute the real BL-Touch probes and anybody not on that list will have their auctions deleted. It is almost that easy. My guess is eBay and Amazon account for 95% of the fake BL-Touch probe sales. It would just make sense to get the legal protection in place to shut down that channel.

Bob-the-Kuhn commented 7 years ago

Just got my BLTouch clone. Just above Antclabs it says "based on"

It'll be a few days before I can test it.

20170215_230023

crncrussell commented 7 years ago

Geeetech seems to be the other biggest distributed clone, but they are now branding it as a "3D Touch." However the discriptions on many of the listings I have seen still say "BLTouch" in the writeups.

https://www.geeetech.com/geeetech-3dtouch-auto-bed-leveling-sensor-for-3d-printer-p-1010.html?zenid=8pqg6jufp45jmk5vm9921e7n23

emartinez167 commented 7 years ago

I didn't mean the Chinese people were buying them, but rather Chinese companies making the clones. If Marlin does not support the clones, then we could be putting a bit into stopping the cloning. Not that I am particularly loyal to the original as I don't even have one, but rather trying to stop the problem of supporting a myriad of different clones. Development effort should go into more advanced stuff, IMHO.

Regards,

Ernesto

On 16 Feb 2017, at 13:04, crncrussell notifications@github.com wrote:

Geeetech seems to be the other biggest distributed clone, but they are now branding it as a "3D Touch." However the discriptions on many of the listings I have seen still say "BLTouch" in the writeups.

https://www.geeetech.com/geeetech-3dtouch-auto-bed-leveling-sensor-for-3d-printer-p-1010.html?zenid=8pqg6jufp45jmk5vm9921e7n23

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

m600x commented 7 years ago

Problem is that sometime people think they bought the real one. Like me.

I paid nearly 50€ in a local shop that advertise it as BLTouch. Not "3D auto leveling sensor". That's a whole different thing. And when you try to legitimately use it as what you just think it is: a BLTouch, it doesn't.

So even if Marlin should or shouldn't support counterfield product is not relevant. It's a matter of determining if the sensor is a legit one or not and tell the user to stop or propose an alternative. That's imo the way Marlin should handle them. Supporting them or not is out of this scope and is up to the dev.

I ended using my counterfield by manually setting it after hours of struggling because I thought Marlin was bugged. Truth is that Marlin wasn't the one to blame but I didn't know that and I was about to give up and turn to Repetier.

Relevant to the counterfield sensor for manual operation:

#define ENDSTOPPULLUPS
#define Z_MIN_ENDSTOP_INVERTING true
#define Z_MIN_PROBE_ENDSTOP_INVERTING true
#define Z_ENDSTOP_SERVO_NR 0
#define Z_SERVO_ANGLES {10,90}
#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
#define AUTO_BED_LEVELING_BILINEAR

The repetability is good (around 0,005mm if I remember correctly) but there's a deviation on my X max axis (might open an issue). And this time I'm pretty sure it's Marlin's fault, not the counterfield sensor (M48 give consistant result accross the bed).

ghost commented 7 years ago

Very SIMPLE !! You want the clone and unfunctionnal one , buy it at halfPRICE, you want waste time and flood github with repeated thread , use PAYPAL USER PROTECTION and waste one or two month added to one week of failed tests , BUY IT !!!

You want , all works immediatly ' take care of feedrate of homing , too much feedrate and detection fails ' , IF YOU WANT A FUNCTIONNAL ' that have the 5 ms pulse and and ability of alarm when something wrong ', then buy it at least 50$ or 40€ , on ' geeteech.com ' or ' antclabs.com' , and i promise you , NO PROBLEMS and , you will continue to work on the pleasure of your printer

The codebase for counterfeit will never exist ,if we never make it!

I can suggest to use the BLTOUCH CLONES just like a endstop switch , but .... a very bad switch... a mechanical true switch will be better and will works perfect ALL TIME !

two weeks LOST just for this SHIT , i was refunded , but not my two wasted weeks of WAR with my printer !

Ps: BOB THE KUHN have made a code to give priority of bltouch detection success , please , insert this code , with the new RCbugfix , and if not , explain in the firmware to slow down the homing and probing to avoid probe detection fails .... Because when a fucking bltouch failed , the buildplate crush the proble , crush the nozzle , i have 2 Z axis and i need to make a new ' setting ' of each height ! Damned !!!! and all if i stay close to the printer and i see this , but , if not , the machine will brake the glass and some mechanicals !

Thk you very much to this communauty ! :-)

Roxy-3D commented 7 years ago

and if not , explain in the firmware to slow down the homing and probing to avoid probe detection fails .... Because when a fucking bltouch failed , the buildplate crush the proble , crush the nozzle , i have 2 Z axis and i need to make a new ' setting ' of each height ! Damned !!!

Careful here! We need to make sure somebody doesn't reference this thread in the future and do the wrong thing. The problem with the 5ms pulse is if the Feed Rate is too low... It will come and go before the Stepper Motor ISR can see it. Setting too slow of a Feed Rate (for example during the second half of a double bump probe) can cause the pulse to be missed.

But Bob's changes are well tested now and fix the problem!

Bob-the-Kuhn commented 7 years ago

And they are in the latest RCBugFix.

Bob-the-Kuhn commented 7 years ago

I think it's time to design a utility to test BLTouch candidates and recommend that users run it before homing/probing with it.

First pass at pseudo code

Clone type A test

issue stow command
issue deploy command
issue stow command
if active when stowed then inform user and recommend settings

BLTouch test (and compatibles)

deploy probe - ask user if deployed (how to get user response?)
stow probe - ask user if stowed
deploy probe & start temperature ISR monitoring BLTouch signal
ask user to push probe pin up
wait 30 seconds
if measure 3mS - 6mS pulse then inform user and recommend settings
if nothing inform user and repeat test

Clone type B test

Is there a second type that we know of?

Maybe we should instead create a general servo probe test and report the results.

Roxy-3D commented 7 years ago

Clone type B test Is there a second type that we know of?

Is the Geeetech probe identical to the knock off you got? If not, that is a second example.

If we were to do this... I'm presuming we would make it such that it was normally turned off. But the user could turn it on if they had problems to help them diagnose the issues they are facing.

ghost commented 7 years ago

I have one Geetech , i have not made mesurement with pulse recorder ' loll' , but , i just tell you that it works without tweaking or anything else , just by uncomment the BLTOUCH DEFINE ! I have a clone/counterfeid or hybrid ' with label ' BASED ON ANTCLABS' , and just written ' TOUCH' and not ' 3dtouch or BLTOUCH' I think that antclabs is very agressive for anyone who wants to copy the sensor , at this time the only two sensors that have worked on my printer are only expensive and original OEM 'antclabs and geeteech' So , don't waste time to create code for hybrid , or a big family of clones all differents Make just a solid firmware for an universal diagram bltouch sensor and it's perfect for the moment 20170217_214440

Bob-the-Kuhn commented 7 years ago

Please see PR #5864 for a Z servo probe test that can tell the difference between a BLTouch, a clone & a standard Z servo probe.

Testing, comments, changes & upgrade requests are all ENCOURAGED.

Bob-the-Kuhn commented 7 years ago

I've had some time to do a first test my GEEETECH probe and my clone.

As expected, the GEEETECH probe acts the same as a BLTouch.

The clone acts as @MagoKimbra describes:

DEPLOYED state: HIGH (logic 1)
STOWED (triggered) state: LOW (logic 0)

I still need to look at things like error state, self test & M119 mode on the GEEETECH & the clone.

Roxy-3D commented 7 years ago

I still need to look at things like error state

Yes! Especially if we are going to try to detect the error state and reset it. But I've been thinking about the suggestion that we have various levels of BL-Touch 'compatibility'. I think it is going to be too much clutter in the code. but we should probably discuss it and see if that is where we land. If the GeeeTech probe is compatable even with the error state declaring the probe is triggered.... That might take away some of the motivation to have various levels of compatibility because at that point GeeeTech and Antclab's probes are going to be the bulk of the market. It might be good at that point to force the clones to make their probes behave the same.

Roxy-3D commented 7 years ago

@Bob-the-Kuhn Oh! One more thing. Antclabs has changed the BL-Touch probes to do a 10ms pulse instead of a 5ms pulse. I think that is going to help make sure the various firmware's don't miss a pulse. If you are willing to put the 10 ms probe on your printer and stress it... I can send you one. I'm sure Antclabs will appreciate the effort!

Bob-the-Kuhn commented 7 years ago

I don't see any value in testing the 10mS version. 5mS is what we'll have to support for the foreseeable future.

Roxy-3D commented 7 years ago

I don't see any value in testing the 10mS version. 5mS is what we'll have to support for the foreseeable future.

Yeah. I want to argue, but you are right....

Bob-the-Kuhn commented 7 years ago

Attached are the logs of my testing with the three sensors

CONCLUSIONS

In normal operation it's hard to find any differences between the BLTouch and the Geeetech.
Error recovery (when not in S120 mode) is respectable. BLTouch recovers by just issuing S160 but sometimes the Geeetech also needs an S10.
Don't put BLTouch or Geeetech into the S120 self test mode. They both quickly error out. Sometimes the S160 command clears it out. Sometimes manual intervention along with the S160 command is needed.
The Clone operates as expected until the probe is obstructed. Error recovery is miserable.

BLTouch (rev B) and Geeetech behaved the same in normal operation and in M119 test mode.

There is a difference in clearing the error state between the two;

If you trigger the unit but don't let the probe fully re-deploy they go into the error state (the light flashes, the signal goes high, the probe stays deployed). They both clear the error state when the S160 is issued (probe retracts, light goes on steady & the signal goes low). .If you trigger the unit but don't let the probe re-deploy at all they go into the error state (the light flashes, the signal goes high, the probe stays retracted). BLTouch clears the error state when the S160 is issued (probe stays retracted, light goes on steady & the signal goes low). With Geeetech the S160 results in the probe staying retracted, light goes on steady BUT the signal stays high. The signal goes low if you issue a S10 to deploy the Geeetech.

The above behavior was repeated 10 times each with no deviations in the results.

The M120 self test mode was a disappointment. Both would deploy, retract, deploy, retract , ... but would go into the error state after 1 to 20 cycles. On both sometimes the S160 command would result in normal operation. Sometimes you needed to push the probe back up to the retracted point, along with issuing the S160 before normal operation was restored.

The clone acts as @MagoKimbra describes in normal operation.

It also has a S120 self test mode that actually ran for 60+ minutes before going into the error state.

Clearing the error state is inconsistent. Sometimes S160 by itself will do the job. Sometimes you need to manually pull the probe down to the deployed position, sometimes you have to push the probe up to the retracted position. When manual intervention is needed, it's inconsistent if the S160 needs to be issued before or after the intervention and if S10 and/or S90 commands need to be issued.

I never was able to find a consistent manual intervention method of clearing the error state.

Also, there's two different blink rates for the error state. No idea what they mean or if it impacts clearing the error state.

testing BLTouch rev B.txt testing geeetech.txt testing clone.txt

Roxy-3D commented 7 years ago

Clearing the error state is inconsistent. Sometimes S160 by itself will do the job. Sometimes you need to manually pull the probe down to the deployed position, sometimes you have to push the probe up to the retracted position. When manual intervention is needed, it's inconsistent if the S160 needs to be issued before or after the intervention and if S10 and/or S90 commands need to be issued.

Does our algorithm work on it? Where we do a S160, then a deploy, and then a stow ??? Does that get it into a consistent state?

Bob-the-Kuhn commented 7 years ago

"S160, then a deploy, and then a stow" doesn't work reliably on the clone.

Roxy-3D commented 7 years ago

Does it work some times on the clone? It might be something that could be used as a validation test that a 'clone' was attached to the system and not a real BL-Touch. Please correct me if I'm wrong, but I think we can put all of the BL-Touch like probes into an error state by putting the BL-Touch pin very close to the glass and deploying it so it raps into the glass. And then we see if the S160, deploy, stow works some times but not other times.

Bob-the-Kuhn commented 7 years ago

You can tell if it is a clone by monitoring the signal when you deploy & stow. When stowed the clone's signal is low and when deployed it's high.

Roxy-3D commented 7 years ago

You can tell if it is a clone by monitoring the signal when you deploy & stow.

So my guess would be that particular clone requires the 'invert' flag to be set.

Bob-the-Kuhn commented 7 years ago

For the clone the invert flag would need to be set to "true".

Roxy-3D commented 7 years ago

I'm wondering if we should search for a different word than 'clone'. Because if more companies reverse engineer the BL-Touch probe, I think it is likely they will try harder to duplicate as much of the behavior as they can. And we will end up with 'clone' probes that do and do not need inversion.

Arrrrgghhhhh....

Bob-the-Kuhn commented 7 years ago

Is there an already defined probe that is active when stowed? If yes then maybe a variation on that name.

or Z_SERVO_TYPE_2

or ROXY'S_NIGHTMARE

or ...

ghost commented 7 years ago

The day you will have a creating company ... you will better understand what must be named clone. Same plastic.. same design ... same wires .. same function. ..same labelling .. same target customer.. and just a different out diagram .....clone is quickly used when you are the factory of the original part when all the families of the trisomic copies. It's a clone.... not for the law...but just for the law

And the day someone tweak the code to make it functional . You can be sure antclabs will dye. But i love clones and i love cheap prices too 😊😊

robustini commented 7 years ago

Here the video of my "BL-Touch" clone, with Repetier... As @MagoKimbra said after the probing not retract like the original, basically he works as an optical probe with the only chance to get him retracted or not through gcode. I think in some cases it is also useful.

https://www.youtube.com/watch?v=MPdJW-fVP-E

MarlinFirmware / Marlin

New Type BLTOUCH #5817