bed keeps lowering at random

[marco-fabteam]

@daniel-fabteam bed keeps lowering probe by probe (as if contact is registered at the beginning of a probing plunge) after a successful row despite the fact that the probe contacts are correctly positioned.
(restarting the probe without touching the contacts or the stylus resumes with a normal probing procedure). this last behaviour tells me that the contacts are correctly placed and this is not a false hit due to vibration etc.

It looks like the script is trying to adjust for a slope with dynamic Z hopping, but it keeps going up...

Also: when the print is aborted a final G38 is still executed before returning to the original Z=0 position
With @simone-fabteam we have determined a series of extrernal probe logic level initialization issues but they should not be an issue.

Not sure about origin and nature of the issue at this stage.
Can't proceed with further testings

[daniel-fabteam]

@marco-fabteam Could you check the following things:

Are you using the latest fabui versions?
Is the fw you'r using the development fw?
Is the head set to digitizer.json ?

In the JOG view initialize the probe manually

M746 S2
M733 S0
M747 E1

Then execute M119 to see it the External probe is open.
Then push the probe and run M119 again to see if it is TRIGGERED

When the bed starts going down, could you try to move the probe to see if it recovers?
If that helps then it's a HW issue (probably)

Have tried it now and it does go into "back off" mode but when I touch the probe it stops doing that.

[daniel-fabteam]

@marco-fabteam When aborting during and ongoing G38 totumduino has to be reset but that is not done at the moment. It's handled for printing but not for scanning. Has to be fixed in fabui.

[daniel-fabteam]

The G38 abort issue should be fixed in the lastest fabui commit.

[marco-fabteam]

@daniel-fabteam
yes the unit has been updated by Krios and Simone beforehand.
It's running on a Totumduino V3 experimental revision with 1/8th of microstepping but should not affect the tests.

The head is installed as per profile provided and I use the custom startup code:

M43 R-21 S1 P20
M746 S2
M747 E1
M999

M747 E1 is because the logic is inverted (see latest 2 open issues at dev-fablin https://github.com/FABtotum/dev-FABlin/issues )
And M999 because of a temperature reset error misfire.

When the issue occur it keeps going even if the stylus is forced in place or moved. it does nothing to change the movement.
As expected with the above config M119 reports Open when idle and Triggered when the hub is moved.

On the contrary the problem should not be hw as after the reset normal functionality is recovered without manually and physically touching the probe or the metal hub or any part of the digitizer.

At this point I can't be sure of the nature of the issue , could be a FW bug or PCB HW as well, but I'm sure it's not about the hub position/mechanical behaviour of the head.

[daniel-fabteam]

@marco-fabteam
the inversion should be configured correctly. The probe script initializes the config on every scan and then undoes it at the end.

The code can be found here.

Could you attach your digitize.json here? Mine has no initialization gcode.

[marco-fabteam]

@daniel Here is the Json, forgot to reply yesterday.

digitizer_head.json.txt

[marco-fabteam]

We noticed that the logic of the digitizer head casually inverted during the scanning procedure of the plugin.
we initialize the head with M747 E1 regardless but it later looses the config and starts rising again during the task...
Any Ideas?