[BUG] M119 deploys BLTouch(clone)

[spazwart]

I have a SKR 1.4 with TMC2209 and a BLTouch clone on my Sidewinder X1 When I do a m119 the BLTouch deploys and the status is open and stays open. Only a M280 P0 S90 will stow the pin again.

A other issue that might be related: When my nozzle is heated/heating and the partcooling fan is on, the BLTouch quickly deploys and stows. This happens even when the printer is doing nothing, just nozzle heating and fan on. This offcourse also happens during the print and that is a big problem. It just keeps probing and stowing very quickly with intervals, sometimes seconds, sometimes minutes.

I tried every possible BLTouch config in Marlin, tried switching to a other fan, changed FAN0 with HE1, nothing helped.

All the normal things the probe should do is working fine, it makes a nice 5x5 mesh with g29, during printing it uses the mesh, all the M280 commands work fine, when homing it stops when touching the bed.

Red/Yellow/Brown wires are connected to the Servo pins on the SKR1.4 and the z_min(white wire) is connected to the z_min endstop on the SKR1.4

Is this clone broken? Is my motherboard broken? Is this EMI? or PWM related? Is my config wrong or is this a bug in Marlin (highly doubt it)

I have attached my config and configadv files, every change I have made is commented with //SZ

Marlin.zip

[InsanityAutomation]

This is a known issue with clones. Its related to the V3.0 bltouch feature additions. At some point the genuine check fandjango did will likely be used to determine some flags for blocking breaking commands from clones but there has been no incentive to put effort into illegal clones of a patented device.

[boelle]

this to me looks more like questions than a bug, am i right?

[GMagician]

@boele depends on point of view. I still have the same issue with a mega2560 and a bltouch clone. As stated by @InsanityAutomation this is due to some "bad" understanding of some 3.0 commands on clones. This has already be reported by me some times ago, but since mine is a clone I can only agree with @InsanityAutomation.

[boelle]

i also agree with him, if the bl touch is in fact patented we should not bother with clones great if they work but if they dont we should not put effort in it

[StefanHamminga]

A quick search shows there is indeed one patent looking to describe the mechanical workings of the BLTouch:

https://patents.google.com/patent/WO2017007244A1/en

It doesn't describe the API and of course there could be more patents.

If the clones do infringe on the patent I can understand not aiding adoption of the clones. If they don't it's more a matter of user demand vs loyalty to BLTouch, imho.

[boelle]

loyalty to BLTouch,

or just loyalty towards those that put the work and effort in to creating

[StefanHamminga]

or just loyalty towards those that put the work and effort in to creating

I didn't mean anything less than that. But if you want to be pedantic, who created the idea might not be BLTouch either according to the patent examiner:

https://patentscope.wipo.int/search/en/detail.jsf?docId=WO2017007244&tab=PCTDOCUMENTS

In particular "English Translation of the Written Opinion of the International Searching Authority", page 5.

Also noted there is that the PCT application (which is more or less unenforceable because of lack of 'inventive step') is only converted to national patent in the US (and maybe Korea, but it's not noted). That besides the question if the 'clones' even infringe on the (US) patent or simply reimplement the API with a mechanism which doesn't infringe.

Anyway, what I was trying to get at is that policing between product manufacturers may not be as easy and black / white as implied above.

Maybe split the BLTouch support to 'official' / 3.x and clones? Or add 'quirks', similar to how the Linux kernel deals with this?

[boelle]

there is also the GPL issue, not many printer makers care about it and there is not much we can do as most of them are located in china,

so yes we need to pick our fights with care, its most likely the end user that will suffer in the end

[StefanHamminga]

GPL is more clear-cut, as you and the other authors are the rights holder and using source code without respecting the conditions for doing so is a clear breach. Different from picking a fight for a third party who may not even have the right to pick this fight themselves.

Side note: If the BLTouch creators are looking: Have a look at how the Raspberry Pi (IMXxxx) camera module solves this (without patents) with seemingly good success.

[boelle]

@InsanityAutomation @Vertabreak @shitcreek @thinkyhead

any thoughts on this one? if its not working because its a clone could this not be called a FR to support them?

or can we fit it in a another box?

[Vertabreak]

FR seems fitting if you ask me.

[boelle]

oki, if none of the others chime in by tomorrow that will be it

@spazwart if you cant wait for support/fix for the odd way clones work then go get the real thing

[Vertabreak]

But i could also support just out right denying the request due to the legality we would be supporting the clone makers by adding the feature. again this is just my opinion and you asked. i would defer to the higher ups then my self.

[boelle]

that is why the higher ups are mentioned/pinged above

if they take longer to respond the worst that can happen is that the title goes back to what it is now

the most i will do is change title and slam a label on it

[Vertabreak]

i think we need thinkyhead to make this kind of call on if we should support illegal clones or not.

[boelle]

again that is why he is mentioned above

he can say fine we will support it and let it stay, if not he will close it

[InsanityAutomation]

My viewpoint is simple. Antclabs donated probes to several developers at each major version as an incentive for proper support. None of the vendors who support my effort use clones, they all use original hardware. We had reason to put in work. The clones need additional work but absolutely no reason to move it anywhere near the front of the list given the massive list I have anyway.

Compound that with I refuse to buy one and support the practice of cloning patented devices, and nobody has sent me one, I don't even have a way to test.

If someone submits a PR for it, it'll get used but quite simply nobody has a reason to go out of their way to resolve a minor issue on clone probes.

[boelle]

that is the same way i think

convert it to a FR, it might sit arround for a LOOOOOONG time, none is obligated to make the PR

thinky might even agree and close the issue

but its by no way a bug hence my idea of making it at FR

[thinkyhead]

Someone would have to essentially submit a fix declaring this clone probe as a different kind of probe. There's nothing we can do differently in the BLTOUCH setup to accommodate an unknown probe which has not been adequately described. Has @spazwart tried every possible combination of BLTOUCH sub-options to see how the probe is affected? Would that be a good idea? I think it has to be up to whomever has the device to figure out how to make it work, or to demand support from the manufacturer. Perhaps the maker of this device can help us to support it.

[GMagician]

If someone submits a PR for it, it'll get used but quite simply nobody has a reason to go out of their way to resolve a minor issue on clone probes.

@InsanityAutomation really sure?

I faced this issue a long time ago and I also knew what code was offending, at least, my clone. Why do you think I may not be interested to fix it? And have a native supported working Marlin on my printer?

I never posted a fix in respect to all persons involved in development. And sincerely I still think that, this is why I will not proceed that way

[thinkyhead]

what code was offending, at least, my clone

@GMagician — Please compare notes with @spazwart and let's try to ignore the extraneous conversation from the usual suspects.

[GMagician]

When I do a m119 the BLTouch deploys and the status is open and stays open

This is what happens to me too and cause is some of the bltouch 3.0 new commands

A other issue that might be related: When my nozzle is heated/heating and the partcooling fan is on, the BLTouch quickly deploys and stows.

this is probably emi or not good 5V. I also had this and it was pwm, he needs to check wires routes

[thinkyhead]

This is what happens to me too and cause is some of the bltouch 3.0 new commands

So, maybe BLTOUCH_FORCE_SW_MODE would be something to try…? Or increase BLTOUCH_DELAY perhaps…?

this is probably emi or not good 5V. I also had this and it was pwm, he needs to check wires routes

I seem to remember at one point there was advice around to "disconnect it from the servo plug after use." But that's no solution. And as I understand it you should not disconnect real servos during operation or it can hurt your board.

[GMagician]

So, maybe BLTOUCH_FORCE_SW_MODE would be something to try…? Or increase BLTOUCH_DELAY perhaps…?

it's not a "delay" issue. I think the new command, don't remember which one, is misinterpreted and result is "deploy probe". Since I want to test servo on AGCM4, I'll check it again and maybe propose a PR for it adding a "BLTOUCH_VERSION" that defaults to 3 and when < 2.1 bypasses some commands.

I seem to remember at one point there was advice around to "disconnect it from the servo plug after use." But that's no solution. And as I understand it you should not disconnect real servos during operation or it can hurt your board.

of course disconnecting it will prevent issues. I reduced issues adding flyback diodes on mosfet output and fixed using a dc-dc converter for 5V (lcd + mega + probe is too much for mega 5V generator), changed gnd routing.

[GMagician]

Confirmed. I have 2 clones from 2 different manufactures. Oldest works perfectly (2.1 commands are ignored) Newest react only to M280 Px S60, it simply deploy probe (same as P10) @spazwart can you test all M280 commands? M280 P0 S10 should deploy M280 P0 S90 should stow M280 P0 S120 should start self test

M280 P0 S60 should reset alarm (only >2.1) usually this command should be sent when probe is down, not sure if it should lower pin or not M280 P0 S160 should stow and reset alarm (only >2.1)

[spazwart]

@GMagician

All M280 commands work fine, only M280 P0 S160 doesn't do anything

My other problem looks solved by replacing the radial fan with a other brand, had 2 of the stock fans from Artillery, both had the stow/deploy/PWM problem, other fan no more random stows/deploys

Only the m119 "bug"/problem exists

[GMagician]

@spazwart What happens with M280 P0 S60?

[spazwart]

@GMagician It deploys the pin

[GMagician]

@spazwart this is the problem I think. Don't know if original bltouch does the same or just set the switch mode

[github-actions[bot]]

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.